The daily Axapta WTF

[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 не такие жесткие).