|
16.11.2005, 12:00 | #1 |
Участник
|
SalesIdBase & SalesId
Интересное наблюдение.
в таблицах SalesTable и SalesLine используются для полей SalesId расширенные типы SalesIdBase, хотя по логике должны быть SalesId (по аналогии с PurchLine & PurchTable, кроме того таблицы типа SalesParmLine или CustInvoiceTrans наследуют поле SalesId именно от EDT SalesId). Как результат - невозможно делать выборки в форме SalesTable, дрил даун на полях SalesId выбрасывает на совершенно "левую" форму. Кто нибудь может предложить разумное объяснение по теме? Ошибка или так задумано? Причем такое наблюдается и в 2.5 и в 3.0 |
|
16.11.2005, 12:08 | #2 |
Модератор
|
Думаю, так задуманно.
Дело в том (предположения), что salesId - слишком на многих формах зюзано. И при открытии нескольких форм будет формроватся диковенный запрос по (linkActive). И все записи на связанных формах будут отфильтрованы. Возможно, есть еще нюансы... Почему я так думаю - сам рисовал таблицу. Пришлось поле от salesId переписывать на SalesIdBase - по тем же соображениям. С Уважением, Георгий |
|
16.11.2005, 12:14 | #3 |
Участник
|
Таким образом разработчики сознательно пошли на усложнение. А как же связка PurchLine & PurchTable?
Не думаю, так как фильтрация на связанных формах отключается без особого труда. |
|
16.11.2005, 12:27 | #4 |
Модератор
|
Хм. Если приглядеться, то расчеты с клиентами и расчеты с поставщиками не так похожи, как кажется на первый взгляд. РП - гораздо проще о "легче". РЗ - довольно обширный модуль, много связанных форм/таблиц. Легче отключить в одном месте, чем перекрывать linkActive или чистить диналинки во всех формах, связанных с продажами. <Строго имхо!>
С Уважением, Георгий |
|
16.11.2005, 12:45 | #5 |
Участник
|
То, что разница есть м модулях закупок и продаж и разница достаточно большая - бесспорно, но!
SalesTable - это основная форма по работе с заказами (причем если организачия торговая - то именно через эту форму водится бОльшая часть информации), соответственно отключать описанные в первом посте возможности - по меньшей мере странно. Георгий, в Вашей реализации возможно связка мешала, но не могу предположить в чем пойдет перекос на SalesTable. Все таки склоняюсь к варианту с ошибкой. |
|
16.11.2005, 13:22 | #6 |
Модератор
|
Да нет как раз... Как-то писал контур, в котором были задействованны продажи. Основное поле в одной из ключевых таблиц было SalesId. Как только унаследовал его от SalesId - полезли проблемы в запросах во всех формах, гда таблицы имели поле от SalesId. Пришлось переделать на SalesIdBase. Возможно, именно этим и руководствовались разработчики системы... Я как раз склоняюсь к тому, что это было сделано специально.
С Уважением, Георгий. P.S. Хоть опрос устраивай: "Это бага или так и было задуманно" |
|
|
Похожие темы | ||||
Тема | Ответов | |||
jinx: Drag & Drop in Masken | 0 | |||
Issues concerning X++: Operator precedence of && and || | 0 | |||
Как в range на одно и тоже контейнерное поле поставить условие: "исключ." && like | 15 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|