Подмена аналитик при разноске отборочной накладной

[evv]

Dynamics Ax 4.0 kernel 4.0.2501.116 Application version 4.0.2200.0
Уважаемые коллеги!
Происходит странная вещь - при разноске отборочной накладной иногда (не всегда!) InventDimId из строки отборочной накладной подменяется неким другим, взятым из строки с тем же ItemId из другой отборочной накладной, привязанной к данному производственному заказу. То есть мы имеем в строке prodJournalBOM InvenDimId_1, а в соответствующей ей строке InventTrans - совершенно другой InventDimId_2. Это приводит к путанице серийных номеров и другим неприятным последствиям. В чем может быть причина? Разноска накладной осуществляется стандартными средствами Аксапты, отборочная накладная генерится тоже стандартными средствами аксапты в автоматическом режиме.

    InventDim                       serialNumber, inventDim, inventDimNew;
    InventTrans                     inventTrans;
    ProdJournalProd                 prepack, journalBOM;
    ProdJournalBom                  content, newPickingListLines;
    ProdJournalTable                prodJournalTable, pickingList;
    ProdJournalCheckPost            journalCheckPost, pickingListPost;
    JournalTableData                journalTableData;
    ProdJournalCreateBOM            prodJournalCreateBOM;
    ;

 journalTableData = JournalTableData::newTable(prodJournalTable);
                journalTableData.initFromJournalName(ProdJournalName::find(ProdJournalName::standardJournalName(ProdJournalType::ReportFinished)));

                ttsbegin;
                prodJournalTable.JournalId         = journalTableData.nextJournalId();
                prodJournalTable.Description       = journalTableData.journalTable().Description;
                prodJournalTable.JournalNameId     = journalTableData.journalTable().JournalNameId;
                prodJournalTable.ProdId            = prepack.ProdId;
                prodJournalTable.Posted            = NoYes::No;
                prodJournalTable.PostedDate        = SystemDateGet();
                prodJournalTable.PostedUserId      = '';
                prodJournalTable.NumOfLines        = 1;
                prodJournalTable.ProdAutoPickList  = NoYes::No;
                prodJournalTable.JournalNameIdPickList = ProdJournalName::find(ProdJournalName::standardJournalName(ProdJournalType::Picklist)).JournalNameId;
                prodJournalTable.insert();

                journalBOM.initFromProdJournalTable(prodJournalTable);
                journalBOM.TransDate               = SystemDateGet();
                journalBOM.InventDimId             = inventTrans.InventDimId;
                journalBOM.QtyGood = -1;
                journalBOM.ProdFinished            = NoYes::No;
                journalBOM.ProdPickListJournalId   = '';
                journalBOM.insert();

                prodJournalCreateBOM = ProdJournalCreateBOM::newProdJournalProd(journalBOM);
                prodJournalCreateBOM.run();
                pickingList = ProdJournalTable::find(prodJournalCreateBOM.usedProdJournalTable().JournalId);

                if (pickingList)
                {
                    journalBOM.ProdPickList           = NoYes::Yes;
                    journalBOM.ProdPickListJournalId  = pickingList.JournalId;
                    journalId                         = pickingList.JournalId;
                    journalBOM.doupdate();

                }
                else
                    throw error("@SYS71699");
                    while  select content
                            where content.JournalId == prepack.ProdPickListJournalId
                            join inventDim
                                where content.InventDimId == inventDim.inventDimId
                                   && inventDim.inventSerialId
                    {
                    select forupdate newPickingListLines
                        where newPickingListLines.JournalId == pickingList.JournalId
                           && newPickingListLines.ItemId    == content.ItemId
                            join inventDimNew
                                where newPickingListLines.InventDimId == inventDimNew.inventDimId
                                   && ! inventDimNew.inventSerialId;

                        if (newPickingListLines)
                        {
                            newPickingListLines.InventDimId = content.InventDimId;
                            newPickingListLines.update();
                        }
                    }

                ttscommit;

ТО есть при попытке вернуть некий компонент изделия на склад создается отборочная накладная с отрицательным количеством и в ее строках проставляется та же аналитика, что и в обычной отборочной накладной, созданной и разнесенной при сборке изделия. Но при разноске этой возвратной накладной иногда в InventTrans попадает совершенно другой серийный номер, чем тот, что указан в возвратной накладной. Подскажите, где может происходить такая подмена?

[Logger]

Сразу оговорюсь что у меня Ax3.0 SP5
Поэтому у вас возможны отличия. Но если в 4-ке код несильно поменялся, то

скорее всего работают методы
\Classes\InventUpd_Physical\updatePhysicalReturnedReceipt
или
\Classes\InventUpd_Physical\updatePhysicalReturnedIssue


На примере
\Classes\InventUpd_Physical\updatePhysicalReturnedReceipt
Там вначале ищется расход (физическое или финансовое движение) по аналитике из строки. Если найден, то на основе него делается возврат, подхватывается аналитика и все такое.

            while select forupdate inventTrans
                Index hint TransIdIdx
                order by inventDimId Desc
                where inventTrans.inventTransId         == movement.transId()       &&
                      inventTrans.statusIssue           == statusIssue              &&
                      inventTrans.statusReceipt         == StatusReceipt::None      &&
                      inventTrans.packingSlipReturned   == 0
                #InventDimJoin(InventTrans.inventDimId,InventDim,inventDimCriteria,inventDimFlags)
            {
                if (inventTrans.InventTransIdReturn)
                    continue;

                addQty = this.updateTransPhysicalReturnedReceipt(_ledgerVoucher, inventTrans, addQty);

Если что-то не получилось. (Скорее всего это и есть ваш случай) В силу каких то причин не нашлась проводка. (Например, проставлен Номер возвращенного лота inventTrans.InventTransIdReturn - т.е. этот лот кто то уже использовал) то тогда она продолжает поиск без учета аналитик, работает такой код :

        while select forupdate inventTrans
            Index hint TransIdIdx
            order by inventDimId desc
            where inventTrans.inventTransId         == movement.transId()       &&
                  inventTrans.statusIssue           == statusIssue              &&
                  inventTrans.statusReceipt         == StatusReceipt::None      &&
                  inventTrans.packingSlipReturned   == 0
        {
            if (inventTrans.InventTransIdReturn)
                continue;

            addQty = this.updateTransPhysicalReturnedReceipt(_ledgerVoucher, inventTrans, addQty);
            if (!addQty)
                break;

и тут может произойти "перескок" аналитик.

Ставьте точки останова и смотрите что реально там у вас происходит.

[evv]

Zitat:

Zitat von Logger

Сразу оговорюсь что у меня Ax3.0 SP5
Поэтому у вас возможны отличия. Но если в 4-ке код несильно поменялся, то

скорее всего работают методы
\Classes\InventUpd_Physical\updatePhysicalReturnedReceipt
или
\Classes\InventUpd_Physical\updatePhysicalReturnedIssue

тут может произойти "перескок" аналитик.

Спасибо за дельный совет, в четверке действительно все несильно поменялось. Я самостоятельно вышел на эти методы по точкам останова, как Вы и предположили. А поняв эту логику, я понял и то, что информация о строке отборочной накладной, вернее, об использованной в ней аналитике, формируется методом самой таблицы InventJournalBOM. там есть такой метод

InventMovement inventMovementChild(Common _buffer)
{
//    if (!this.InventReturnFlag && _buffer.TableId == tablenum(ProdBOM))
    if (_buffer.TableId == tablenum(ProdBOM))
    {
        return new InventMov_ProdLine_JournalBOM(_buffer,this);
    }

    return null;
}

который собственно выдает курсор с текущей аналитикой. В случае, если речь идет о возврате (количество < 0), метод возвращает null, и указанные Вами методы выбирают последнюю отгруженную номенклатуру для возврата. После того, как я закомментировал анализ InventReturnFlag, стала возвращаться на склад именно та номенклатура, которая указана в строках отгрузочной накладной на возврат.

[Logger]

Zitat:

Zitat von evv

После того, как я закомментировал анализ InventReturnFlag, стала возвращаться на склад именно та номенклатура, которая указана в строках отгрузочной накладной на возврат.

Вообще-то я бы не комментировал это место безусловно для всех случаев. Оно дергается из кучи мест. Мне кажется лучше сделать какой-нить управляющий параметр, который меняет поведение только для этого конкретного случая.

[evv]

Zitat:

Zitat von Logger

Вообще-то я бы не комментировал это место безусловно для всех случаев. Оно дергается из кучи мест. Мне кажется лучше сделать какой-нить управляющий параметр, который меняет поведение только для этого конкретного случая.

Насколько я понимаю, этот метод вызывается только для отборочных накладных в модуле "Производство", а заказчик предпочитает точно указывать аналитику (в частности, серийный номер) при возврате на склад, поэтому в данной ситуации это не должно привести к криминальным последствиям. Но можно и параметр сделать, если кастомер не будет возражать...

[Logger]

\Classes\InventUpd_Physical\updatePhysicalReturnedReceipt

или

\Classes\InventUpd_Physical\updatePhysicalReturnedIssue

Эти методы вызываются везде где идет возврат.

Например, при обработке накладной по заказу или закупке через немедленное получение на отрицательное количество. Т.е. когда оформили накладную, а потом возвращаем через немедленное получение.

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

[Vals]

Zitat:

Но при разноске этой возвратной накладной иногда в InventTrans попадает совершенно другой серийный номер, чем тот, что указан в возвратной накладной. Подскажите, где может происходить такая подмена?

Думал я тут над этим вопросом: код может быть ни при чём. Такая штука может происходить, когда аналитика, например, вторичная и при определённых комбинациях настроек разных аналитик. Также для исключения таких ситуаций можно рекомендовать включить регистрацию/комплектацию.
Итого - нужно проверить настройки номенклатуры в части складской аналитики, групп складских моделей а также бизнес-процесса.
То есть я думаю, что в вашей ситуации нужно изменить или добавить настройки.

[Logger]

Регистрация/комплектация не помогает в данном случае.
Если вы посмотрите тот код который приводился - то увидите что система вообще не учитывает проводки в этом статусе. Она ищет проводки со StatusIssue::Sold или StatusIssue:: Deducted и на основе их создает новые проводки с другим знаком. Т.е. в отличие от остальных режимов обработки, система не меняет статусы уже существующих проводок, а создает их с нуля.

[b_nosoff]

Приподниму старую тему... На всякий случай, уточню - при наличии флага InventReturnFlag, movement конструируется не на основе ProdJournalBOM, а на основе ProdBOM, в котором бывает не указывается ни партия ни номер, ну и соответственно, при выборке проводок система не глядит на эти аналитики. Так вот, интересный факт - в пятерке проверку флага на sys слое выключили, но потом обратно включили на gls. Кто знает, к чему это?

[EVGL]

Zitat:

Zitat von b_nosoff

Так вот, интересный факт - в пятерке проверку флага на sys слое выключили, но потом обратно включили на gls. Кто знает, к чему это?

Спасибо за информацию! Это - определенно не к добру. Не верим русским и убираем проверку флага обратно, иначе будет невозможно отсторнировать, скажем, определенную палету или серийный номер!