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

[Raven Melancholic]

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

[newSalesParmLine.DeliverNow, newSalesParmLine.RemainBefore      , newSalesParmLine.RemainAfter]        = this.qtySales  (_salesLineOrig, this.interCompanyParmLineQty(_salesLineOrig));
[newSalesParmLine.InventNow , newSalesParmLine.RemainBeforeInvent, newSalesParmLine.RemainAfterInvent]  = this.qtyInvent (_salesLineOrig, this.interCompanyParmLineQty(_salesLineOrig));

То есть, и для количества в единицах заказа на продажу и для количества в единицах складского хранения используется один и тот же метод interCompanyParmLineQty. В результате расчет недопоставки / перпоставки идет неверно если складские единицы и единицы в заказе отличаются.
Решение проблемы: для второго вызова interCompanyParmLineQty результат необходимо пересчитать в складские единицы.

[JeS]

Есть такое дело. Тоже исправлял. Вообще в Intercompany я много косяков в свое время нарыл. Такое ощущение, что эту функциональность плохо тестировали.

[kashperuk]

Raven, а расскажите плз, как именно вы исправляли эту ошибку. Передачей true при втором вызове метода interCompanyParmLineQty?
И, если будет время, было бы здорово привести сценарий, с помощью которого можно воспроизвести это поведение в стандартном функционале.

Спасибо

[JeS]

Лично я исправлял как Вы сказали:

Цитата:

Передачей true при втором вызове метода interCompanyParmLineQty

Как воспроизвести точно не помню, но вроде так:
создать цепочку заказов (внутрихолд заказ продажи - внутрихолд заказ покупки - исходный заказ) типа прямая поставка. И разнести ее.

[kashperuk]

Цитата:

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

Лично я исправлял как Вы сказали:

Как воспроизвести точно не помню, но вроде так:

Тогда уже исправили. Спасибо

[JeS]

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

...
while (qr.next())
{
     fromInventTrans = qr.get(tablenum(InventTrans));
     fromInventDim   = qr.get(tablenum(InventDim));
     ...
     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;
        ....

Обратите внимание на третий параметр в макросе #inventDimJoin, и что этот запрос исполняется уже в другой компании. В случае, если стоит настройка, при которой происходит синхронизация складов между компаниями через внешние коды, то последний запрос будет всегда возвращать ноль. То есть лечить надо примерно так: сначала сконвертировать значение fromInventDim.InventLocationId, и только потом использовать его в запросе.

P.S.: надеюсь понятно пояснил, как-то сумбурно получилось, млин

[JeS]

Забыл добавить: DAX 4.0 SP2

[Raven Melancholic]

Цитата:

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

Raven, а расскажите плз, как именно вы исправляли эту ошибку. Передачей true при втором вызове метода interCompanyParmLineQty?

Нет, Иван, это вариант не для всех ситуаций. Как бы мы не написали метод interCompanyParmLineQty, он работает по данным компании-продавца и даст данные по единицам складского учета компании-продавца. Однако, складские единицы могут различаться в компаниях. Например, наш случай: в закупочной компании складские единицы тонны, а в компании-покупатели килограммы. Если единицы продажи/покупки механизм интеркомпани заставляет делать одинаковыми (какой-бы метод согласования в настройках конечных точкек мы не выбрали, пересчета на стыке компаний не будет), то складские единицы могут различаться. Если метод interCompanyParmLineQty вернет мне тонны, а у меня в покупающей компании складскими единицами являются килограммы, то проблема остается.
Поэтому лучше получить данные методом interCompanyParmLineQty для единиц закупки/продажи и приводить к складским уже в компании-покупателе.

[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 независимо от типа кэширования.