DAX4 Интеркомпани, ошибка разноски внутрихолдинговой накладной

[JeS]

В предыдущем сообщении, где приводил пример кода, я допустил ошибку. Исправляюсь. Код в базовой функциональности должен выглядеть так:

while (fromInventTrans)
{
     ...
     fromQty = -fromInventTrans.Qty;
     if (inventDimParm.InventLocationIdFlag && fromInventDim.InventLocationId)
     {
        convInventLocation = new TradeInterCompanyConv();
        salesInventLocationId = fromInventDim.InventLocationId;
        convInventLocation.axInventLocationId(fromValueMap, fromInventDim.InventLocationId);
     }
     ...
     changecompany(_toDataAreaId)
     {
          toInventTrans = null;
          
          select forceplaceholders sum(Qty) from toInventTrans
                           where toInventTrans.InventTransId == _toInventTransId
                           &&   (toInventTrans.StatusReceipt <= StatusReceipt::Registered
                              || toInventTrans.InterCompanyInventDimTransferred == true)
                           &&    toInventTrans.StatusIssue   == StatusIssue::None
         #inventDimJoin(toInventTrans.InventDimId,toInventDim,fromInventDim,inventDimParm);

         fromQty -= toInventTrans.Qty;
        ....

Но, вобщем, сути дела это не меняет, но сбить столку кого-нибудь может.
Кстати непонятно зачем нужно было писать такую "этажерку" в этом методе до вышеописанного цикла:

if (inventDimParm.InventLocationIdFlag && inventDimParm.InventBatchIdFlag && inventDimParm.InventSerialIdFlag)
            {
                select forceplaceholders sum(Qty) from fromInventTrans
                       where fromInventTrans.InventTransId == _fromInventTransId
                       &&    fromInventTrans.StatusIssue   <= _statusIssue
                       &&    fromInventTrans.StatusReceipt == StatusReceipt::None
                join InventLocationId, InventBatchId, InventSerialId from fromInventDim
                     group by InventLocationId, InventBatchId, InventSerialId
                     where fromInventDim.InventDimId == fromInventTrans.InventDimId;
            }
            else if (inventDimParm.InventLocationIdFlag && inventDimParm.InventBatchIdFlag)
            {
                select forceplaceholders sum(Qty) from fromInventTrans
                       where fromInventTrans.InventTransId == _fromInventTransId
                       &&    fromInventTrans.StatusIssue   <= _statusIssue
                       &&    fromInventTrans.StatusReceipt == StatusReceipt::None
                join InventLocationId, InventBatchId from fromInventDim
                     group by InventLocationId, InventBatchId
                     where fromInventDim.InventDimId == fromInventTrans.InventDimId;
            }
            else if (inventDimParm.InventLocationIdFlag && inventDimParm.InventSerialIdFlag)
            {
            ...

и так далее, перебирая всевозможные комбинации аналитик. Почему нельзя было воспользоваться QueryBuild-классами? Может я чего-то не понимаю. Просто если вдруг понадобится добавить скажем еще 2 аналитики, то становится дурно (одну то точно добавить хочется - ГТД).

[JeS]

Цитата:

К сожалению это не одна ошибка в этом методе

За это спасибо

Цитата:

даже если отбросить тот факт, что про ГТД в этом методе ничего нет

локализация вообще как-то стороной обошла Intercompany. Помимо ГТД добавлю, что и счета-фактуры не синхронизируются, что вобщем-то тоже напрашивается. Более того, если будешь разносить сразу фактуру во внутрихолдинговом заказе на продажу (в цепочке типа прямой поставки) - то просто выкинет ошибку.

[Raven Melancholic]

Еще наткнулись. Ка-то странно работает кэш (я про это уже писал, но тогда было только тестирование и как-то не зациклились на этой теме).
У нас в разных компаниях номенклатура ведет себя по разному (например, в производственной это спецификация с номенклатурной группой "Готовая продукция", в торговых домах это номенклатура с номенклатурной группой Товар, ну и т.п.). Поэтому справочник не общий, а в каждой компании свой (есть доработка по вводу и синхронизации определенных номенклатур, но суть не в этом). Так вот, простой код джоба:

itemId = 'ВентиляторWRW50/40';
intentTable = InventTable::find(itemId);
changeCompany('TRD')
{
   inventTableChg = null;
   select firstOnly inventTableChg where inventTableChg == itemId;
   ...
}

Думаете, что после переключения мы нашли номенклатуру в компании TRD? Сильно ошибаетесь. Возвращена номенклатура компании, в которой запустили джоб! Если в компании запуска не было поиска по этому номенклатурному номеру, то все нормально.
То же происходит если в разных компаниях номера складских лотов совпадают. Если после переключения компании искать складские операции по номеру лота, совпадающему с тем, что был выполнен ранее, то вернется ранее найденный лот.
Помогает включения в код запрет кэша:

itemId = 'ВентиляторWRW50/40';
intentTable = InventTable::find(itemId);
changeCompany('TRD')
{
   inventTableChg = null;
   inventTableChg.disableCash(true);
   select firstOnly inventTableChg where inventTableChg == itemId;
   ...
}

Если по номенклатуре это можно понять (есть кэширование), то по InventTrans что-то невнятное: у этой таблице CashLookup стоит NONE.
Такое впечатление, то кэш игнорирует компании. вобщем-то можно было бы отключить кэш DAX для всех таблиц (кэш MS SQL хорошо справляется со своей работой), но InventTrans не кэшируется DAX!
Так же понятно, что из-за этой проблемы следует стараться иметь для одних и тех же таблиц в разных компаниях разные уникальные идентификаторы. Но, в нашем случае, это возможно для InventTrans, но не интересно для InvntTable. Можно всегда добавлять disableCach, но в наших разработках мы так и делаем, но есть стандартный код!
PS: кстати, без использования disableCash Trasert MS SQL показывает, что к базе данных было только оно обращение, то есть цепочка: поиск в одной компании, changeCompany, поиск в другой компании того же значения обрабатывает DAx независимо от типа кэширования.

[Raven Melancholic]

Еще один момент. Правда это не ошибка, но непонятка.
В SalesLine и PurchLine для механизма Интеркомпани есть поле InterCompanyInventTransId по которому связаны строки заказа на покупки и заказа на продажу Интеркомпани. Но в классах, наследниках от TradeInterCompany поиск связанной строки почему-то происходит не по этим лотам, а по номерам строк.
Я, конечно, понимаю, что индекс, включающий номер строки является кластерным и когда требуется получить все данные строки он работает быстро (тем более, что в интерфейсе поле LineNum не представлено, а в методах InteCompanyMirror оно синхронизируется). Но, все-таки, во всех остальных местах связь идет по полю InterCompanyInventTransId, к тому же, индекс, включающий LineNumне уникальный, что позволяет при работе не из интерфейса, а из кода дублировать номера строк (кстати, в стандартном приложении бывает, что номер строки несколько раз бывает нулевым, правда это относится не к заказам на покупку-продажу, а складским журналам и журналам ГК).
Почему для классов, наследников TradeInterCompany сделано исключение из общего правила?