DAX 2009 связь скл. проводки со строкой накладной по заказу

[Murlin]

Обнаружил что теперь в DAX 2009 связи между проводкой складской и строкой накладной(custinvoicetrans) не прописаны, каким образом устроена связь между проводкой и накладной и почему от этой связки отказались?
Необходимо посчитать маржу в OLAP.

[d&m]

для расчета маржи уже есть методы прям на таблице CustInvoiceTrans (ContributionMargin и ContributionMarginMST).

там же и связь прописана

InventTrans::invoiceCostAmount(this.InventTransId,this.InvoiceDate,this.InvoiceId);

другими словами на вопрос:

Цитата:

Сообщение от Murlin

... каким образом устроена связь между проводкой и накладной ...?
Необходимо посчитать маржу в OLAP.

ответ: по номуру лота, номеру накладной и дате накладной.

[Murlin]

Цитата:

Сообщение от d&m

для расчета маржи уже есть методы прям на таблице CustInvoiceTrans (ContributionMargin и ContributionMarginMST).

там же и связь прописана

InventTrans::invoiceCostAmount(this.InventTransId,this.InvoiceDate,this.InvoiceId);

другими словами на вопрос:

ответ: по номуру лота, номеру накладной и дате накладной.

но уникальности нет по этим полям в накладных.

[Logger]

Цитата:

Сообщение от Murlin

но уникальности нет по этим полям в накладных.

Все правильно. Это косяк аксапты. Вылезает если разрешены дубликаты по номерам накладных.
Можно порекомендовать вам сделать какое-то поле идентифицирующее однозначно накладную. И протаскивать его в строку и в проводку.
Мы таким полем назначили ваучер. В строку его протаскиваем. В проводке он и так есть.

[Владимир Максимов]

Цитата:

Сообщение от Murlin

Обнаружил что теперь в DAX 2009 связи между проводкой складской и строкой накладной(custinvoicetrans) не прописаны, каким образом устроена связь между проводкой и накладной и почему от этой связки отказались?

А можно уточнить, что Вы вкладываете в термин "теперь"? Насколько я вижу, все те индексы, которые были на таблице CustInvoiceTrans в Ax2.5 и Ax3.0 так и остался в Ax2009. Один-в-один. Relations также совпадают для версий Ax3.0 и Ax2009. Вообще НИКАКИХ изменений.

Вы как раньше-то связывали? В какой версии?

[Murlin]

Цитата:

Сообщение от Владимир Максимов

А можно уточнить, что Вы вкладываете в термин "теперь"? Насколько я вижу, все те индексы, которые были на таблице CustInvoiceTrans в Ax2.5 и Ax3.0 так и остался в Ax2009. Один-в-один. Relations также совпадают для версий Ax3.0 и Ax2009. Вообще НИКАКИХ изменений.

Вы как раньше-то связывали? В какой версии?

Я точно не помню но помню смутно что связь была прописана через метод или через relation. возможно в 4ке. Я брал оттуда связку и связывал. По мойму это даже было в стандарте, могу ошибатся

[Владимир Максимов]

Вообще-то, однозначная связь между строками фактур и складскими проводками невозможна "по определению". Так сказать, by-design

По самой "природе" строки фактур создаются на основе строк заказа. А складские проводки выступают лишь как некий дополнительный фактор контроля. Дополнительные проверки. Причем "интегральный" (суммовой) фактор контроля (сумма по разным складским аналитикам).

Ну, а поскольку на основании одной строки заказа может быть как много строк фактур, так и много складских проводок, то и связь между этими таблицами будет много-ко-многим.

Собстенно, код на однозначную связь и не рассчитывает. Если посмотреть, что делает метод InventTrans::invoiceCostAmount(), то видно, что он суммирует складские проводки. Причем InvoiceId и InvoiceDate - это всего-лишь контроль частичной фактуровки, а вовсе не попытка создать уникальный идентификатор.

Другими словами, сделать "исторический" анализ - не получится. Даже в том случае, если Вы добавите уникальные идентификаторы. Может банально не оказаться складской проводки с таким идентификатором (удалили после сторнирования).

PS: А вот "проклятием рода Баскервилей" я считаю отсутствие однозначной связи между шапками и строками фактур (CustInvoiceJour - CustInvoiceTrans). Но это уже другая история

[S.Kuskov]

Владимир Максимов, а почему вы накладные называете фактурами?

[Murlin]

Цитата:

Сообщение от Владимир Максимов

PS: А вот "проклятием рода Баскервилей" я считаю отсутствие однозначной связи между шапками и строками фактур (CustInvoiceJour - CustInvoiceTrans). Но это уже другая история

Пипец

[Logger]

Цитата:

Сообщение от S.Kuskov

Владимир Максимов, а почему вы накладные называете фактурами?

Кстати, да. Если говорить именно о строках CustInvoiceTrans то однозначную связь построить все же можно. У нас даже для просмотра маржи дисплей методы в строках накладных висят.

[Владимир Максимов]

Цитата:

Сообщение от S.Kuskov

Владимир Максимов, а почему вы накладные называете фактурами?

Потому что я все еще работаю в Ax2.5. А там эта таблица называлась "Строки счетов-фактур", а CustInvoiceJour - соответственно "Счета-фактур"

[Владимир Максимов]

Цитата:

Сообщение от Logger

Кстати, да. Если говорить именно о строках CustInvoiceTrans то однозначную связь построить все же можно. У нас даже для просмотра маржи дисплей методы в строках накладных висят.

Можно. Если принять некоторые организационные ограничения.

Например, запрет удаления строк заказов. Ведь после сторнирования никто не мешает удалить строки заказов, при этом строки накладных "провиснут". Будут ссылаться на не существующие лоты. Ну, и весьма специфическим способом придется организовывать связку складских проводок с разной складской аналитикой. Также надо добавить контроль уникальности на значение InvoiceId.

Может, еще чего надо сделать. Т.е. работать будет, если постоянно "пальцем придерживать"