The daily Axapta WTF

[Ivanhoe]

У него от скорости печатания работает ветряк, который питает ноутбук?

[Stitch_MS]

Или ветряк охлаждает клавиатуру, чтобы дым от быстрого печатания не мешал смотреть в монитор.

[TasmanianDevil]

2009 SP1 5.0.1500.6491 (хотя оно вполне справедливо и для старших/младших версий)

Уже давненько замечал, что есть такая практика в различных обработчиках модульных движений по части использования методов lastAmountCur()/lastAmountMST() от доступного в тех краях объекта LedgerVoucher для наполнения суммовых полей своих родных модульных проводок.

До сих пор отношение к этому далее и конкретнее, чем "чую бесовщину, но обосновать не могу", не шло...

Однако на днях коллеги в "песочнице" попытались разнести накладную по заказу на продажу, в которой было две строки с разными знаками (-/+) в качестве исправления ранее сделанной (изменялась цена продажи одной строки).
Все красиво и хорошо, склад и налоги -/+ прошли как и ожидалось, только вот проводка по клиенту сформировалась на сумму последней строки накладной вместо суммы всех строк.

Исследования показали, что эта "радость" возникает при сложении двух обстоятельств:

1. Накопление разнознаковых частей и разбивка по ним в российской функциональности проводок ГК по клиенту в CustVendVoucher'е при наличии в дебете или кредите позиций с разным знаком (наполняется в SalesFormLetter_Invoice.createCustTrans(), будущие проводки ГК разбиваются далее в CustVendVoucher.postMultipleBalances_RU, вызываемом из post() этого же класса)
2. Использование в инициализации суммы проводки по поставщику/клиенту в CustVendVouchere.initCustVendTrans() вышеозначенных методов, lastAmountCur()/lastAmountMST(), из LedgerVoucher'а

Есть мнение, что вышеозначенные методы небезопасны и их использование за пределами LedgerVoucher'а суть есть зло и рытье ямы самому себе.

P.S. <GEUU> в комментах тамошнего кода, наполнявший разбиение и поклавший на оное в своем же коде - это же наш здешний EVGL, если не ошибаюсь ?

[belugin]

Цитата:

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

P.S. <GEUU> в комментах тамошнего кода, наполнявший разбиение и поклавший на оное в своем же коде - это же наш здешний EVGL, если не ошибаюсь ?

Это страновые теги. EU - это Eвропа.

[TasmanianDevil]

Цитата:

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

EU - это Eвропа.

Виноват, возвел на Евгения напраслину

Нет счас под рукой 2012-й (и тем более 365FO) - там оно как, радости сии остались ?

[belugin]

Как-то так:

custVendTrans.ReasonRefRecId = reasonRefRecID;

        // If the amount, which is the total invoice amount, is zero, then the amountMST and amountCur also must be zero
        if (amountCur)
        {
            if (_useSubLedger)
            {
                // <GIN>
                if (TaxWithholdParameters_IN::checkTaxParameters())
                {
                    amountCur += taxWithholdAmount;
                }
                // </GIN>

                custVendTrans.AmountMST = CurrencyExchangeHelper::mstAmount(amountCur, currencyCode, transDate, Currency::noYes2UnknownNoYes(triangulation), exchRate, exchRateSecondary);
            }
            else
            {
                // <GEERU>
                if (ledgerBalances)
                {
                    custVendTrans.AmountMST = CurrencyExchangeHelper::amount(postedAmountMST, Ledger::accountingCurrency());
                }
                else
                {
                    // </GEERU>
                    custVendTrans.AmountMST = CurrencyExchangeHelper::amount(ledgerPostingReference.lastAmountMST(), Ledger::accountingCurrency());
                    // <GEERU>
                }
                // </GEERU>
            }
        }
        else
        {
            custVendTrans.AmountMST = 0;
        }

 /// <summary>
    /// Calculates the total of the multiple posted balance amount based on
    /// the specific currency code and the object of <c>CurrencyExchangeHelper</c>.
    /// </summary>
    /// <param name = "_curencyCode">The transaction currency originating the conversion.</param>
    /// <param name = "_currencyExchangeHelper">The <c>CurrencyExchangeHelper</c> class which manages calculations between currencies.</param>
    /// <returns>A container of AmountCur and AmountMst.</returns>
    private container calculatePostedMultipleBalanceAmounts_RU(CurrencyCode _curencyCode, CurrencyExchangeHelper _currencyExchangeHelper)
    {
        int i;
        boolean correction;
        AmountCur balanceValue;
        AmountCur retAmountCur;
        amountMST retAmountMst;
        for (i = 1; i<=conLen(ledgerBalances); i++)
        {
            [correction, balanceValue] = conPeek(ledgerBalances, i);
            retAmountCur += balanceValue;
            retAmountMST += _currencyExchangeHelper.calculateTransactionToAccounting(
                    _curencyCode,
                    balanceValue,
                    true
            );
        }
        return [retAmountCur, retAmountMst];
    }

if (countryRegion_RU)
        {
            custVoucher.parmSalesInvoicePostingType_RU(custInvoiceJour_RU.InvoicePostingType_RU);
            if (this.postBalanceAsManyLedgerTransactions_RU())
            {
                custVoucher.parmLedgerBalances_RU([[false, salesTotals.totalAmountBySign_RU(false)], [this.parmStorno(), salesTotals.totalAmountBySign_RU(true)]]);
            }
        }

[dech]

Смотрю код сделанный предыдущим интегратором и... о божечки!

    switch (jobType)
    {
        case RouteJobType::Process:
            select _prodRoute
                where _prodRoute.ProdId     == prodTable.ProdId
                   && _prodRoute.OprNum     == oprNum
                   && _prodRoute.JobType    == RouteJobType::Process;
            break;

        case RouteJobType::Setup:
            select _prodRoute
                where _prodRoute.ProdId  == prodTable.ProdId
                   && _prodRoute.OprNum  == OprNum
                   && _prodRoute.JobType == RouteJobType::Setup;
            break;
    }

Оно как бы работает, это радует... но нельзя ли было подумать головой, а не плодить условную логику?..

    select _prodRoute
        where _prodRoute.ProdId     == prodTable.ProdId
           && _prodRoute.OprNum     == oprNum
           && _prodRoute.JobType    == jobType;

[trud]

У вас же не тоже самое получилось, значений то в енуме больше

[dech]

Да, действительно! Под вечер уже мозг задеревенел)))
Но все равно можно проще сделать:

    switch (jobType)
    {
        case RouteJobType::Process:
        case RouteJobType::Setup:
            select _prodRoute
                where _prodRoute.ProdId     == prodTable.ProdId
                   && _prodRoute.OprNum     == oprNum
                   && _prodRoute.JobType    == jobType;
            break;
    }

[trud]

Коллеги наткнулись. оказывается кому-то из МС пришла здравая мысль денормализовать DIMENSIONATTRIBUTEVALUECOMBINATION(это AX7.3) - теперь там кол-во столбцов по кол-ву аналитик * 3.
Cделали втихую и никак не анонсировали, по видимому в движке синхронизации(т.е. в АОТ эта таблица имеет 5 полей).

[Vadik]

Цитата:

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

Коллеги наткнулись. оказывается кому-то из МС пришла здравая мысль денормализовать DIMENSIONATTRIBUTEVALUECOMBINATION(это AX7.3) - теперь там кол-во столбцов по кол-ву аналитик * 3.
Cделали втихую и никак не анонсировали, по видимому в движке синхронизации(т.е. в АОТ эта таблица имеет 5 полей).
Вложение 12096

А почему в WTF и почему "втихую" ? Add dimensions to Excel templates довольно давно сделали - мы еще на 1611 это использовали

[trud]

Цитата:

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

А почему в WTF и почему "втихую"

О, как-то пропустил, спасибо
WTF - ибо странно почему бы не дать доступ к этим данным из X++ изначально. т.е. сейчас для получения значения аналитик надо сильно заморочиться(т.е. ссылку на атрибут надо как-то хранить, писать методы). а тут получается альтернативный подход где все уже есть, просто по ID получай конкретную запись где будут все поля(по сути также как было в AX2009 с енумом аналитики)
а каким образом обновляются эти невидимые столбцы в этой таблице DIMENSIONATTRIBUTEVALUECOMBINATION?

[skuull]

Цитата:

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

О, как-то пропустил, спасибо
WTF - ибо странно почему бы не дать доступ к этим данным из X++ изначально. т.е. сейчас для получения значения аналитик надо сильно заморочиться(т.е. ссылку на атрибут надо как-то хранить, писать методы). а тут получается альтернативный подход где все уже есть, просто по ID получай конкретную запись где будут все поля(по сути также как было в AX2009 с енумом аналитики)
а каким образом обновляются эти невидимые столбцы в этой таблице DIMENSIONATTRIBUTEVALUECOMBINATION?

Все на SQL триггерах, смотрите в классы DimensionSQLObjectsDAVCInsertTrigger и ему подобные.

[raz]

Цитата:

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

А почему в WTF и почему "втихую" ? Add dimensions to Excel templates довольно давно сделали - мы еще на 1611 это использовали

У меня не работает lookup в excel, что бы выбрать нужное значение. Как это сделать в 8.0?

[skuull]

Цитата:

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

Коллеги наткнулись. оказывается кому-то из МС пришла здравая мысль денормализовать DIMENSIONATTRIBUTEVALUECOMBINATION(это AX7.3) - теперь там кол-во столбцов по кол-ву аналитик * 3.
Cделали втихую и никак не анонсировали, по видимому в движке синхронизации(т.е. в АОТ эта таблица имеет 5 полей).

Оно так года с 2016, с открытием вас!

[raz]

Из DAX они тоже доступны через (fieldName2Id(tableNum(DimensionAttributeValueCombination), identifierStr(MainAccountValue)))

https://community.dynamics.com/ax/f/33/t/222182

[axm2017]

Случайно глянул пару методов Cust/VendTransOpen

Видимо уже давно не смотрел в код стандарта

на update

        ttsbegin;
        //..какие то изменения данных
        if (this.validateWrite())
        {
            super();
        }
        ttscommit;

Что в 12 и в новой версии присутствует

[gl00mie]

PurchLine.update() в D365FO стал просто великолепен: мало того, что метод раздулся до 370 строк (что, PurchLineType.update()? не, не слышали), так он еще и начал пересчитывать налоги по заказу на покупку - видать, какой-то костыль для отображения итогов по заказу в виде FormPart.

if (this.distributionUpdateNeeded(purchLineOrig))
{
    if (purchTable.InclTax &&
        (this.hasAmountChanged(purchLineOrig) || this.hasTaxChanged(purchLineOrig)))
    {
        PurchTotals::newPurchTable(purchTable).calc(false, false, true);
        PurchLine::logMeasure(instrumentation, classStr(PurchTotals), methodStr(PurchTotals, calc), stopWatch);
    }

Конечно, на тестовых данных с 10-ю строками всё прекрасно, а вот в реальных условиях, когда строк эдак под 600 и более, какая-нить отмена недопоставленного количества превращается в десятки минут ожидания, так еще и блокировки на PurchTableVersion вешаются, так что несколько заказов на покупку в параллель штатно не отменишь.

Цитата:

Сообщение от Blog bot

How much telemetry are we collecting? A lot, like, really a lot!

Да, спасибо, в последней версии всё стало работать еще тормознее за счет того, что каждый чих пишется в EventLog, и по нему можно найти проблемное место. Но толку-то? Как вот надо извратиться, чтобы при запрете оверлеинга, одними extension'ами отрубить этот холостой пересчет налогов на каждой строке? Чтоб служба медом не казалась, PurchLine.distributionUpdateNeeded() сделан закрытым (private), так что свой пост-обработчик туда не повесишь.

[SRF]

Цитата:

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

PurchLine.update() в D365FO стал просто великолепен: мало того, что метод раздулся до 370 строк (что, PurchLineType.update()? не, не слышали), так он еще и начал пересчитывать налоги по заказу на покупку - видать, какой-то костыль для отображения итогов по заказу в виде FormPart.

Этот успешный код появился еще в AX 2012, но там он живет в PurchLineType.update() (в котором, к слову, примерно 340 строк, совпадение ? или может они просто всю начинку из него вытянули в purchLine.update() ? ) и пока еще может быть легко изменен. Не думаю, что сделали для расчета итогов, для этого есть еще один вызов в другом классе , в том же методе update.

Скорее всего вызов необходим для корректного пересчета распределений, к тому же название метода как бы намекает, сам пересчет распределения идет ниже в том же методе, вызывается для всей покупки целиком, правда в последних версиях AX2012, ребята поняли или им кто-то подсказал, что бывают проблемы с производительностью. Поэтому они добавили флажок(purchline.SkipDistributionUpdate) для скипа пересчета распределения всей покупки при обновлении строки и его используют при некоторых массовых действиях со строками, а про InclTax возможно забыли, т.к. чек скорее всего не был активирован

Цитата:

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

Как вот надо извратиться, чтобы...

Я так понимаю вопрос больше риторический ? PurchTotals нельзя переопределить разве ?

[fed]

Цитата:

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

Да, спасибо, в последней версии всё стало работать еще тормознее за счет того, что каждый чих пишется в EventLog, и по нему можно найти проблемное место.

Кстати, у меня есть сильное подозрение, что замечательное новое логирование быстро съедает IOT Quote и Azure начинает зажимать дисковые операции. (Aka IOT Throttling.) Возможно из за этого микрософт и вынужден был перевести подписные VM на DS12 (где, как я понимаю, ограничения по IOT не такие жесткие).