The daily Axapta WTF - Страница 18 - Курилка

SRF · 23.10.2018, 08:58

Цитата:

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

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

Этот успешный код появился еще в AX 2012, но там он живет в PurchLineType.update() (в котором, к слову, примерно 340 строк, совпадение ?

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

, в том же методе update.

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

Цитата:

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

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

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

PurchTotals нельзя переопределить разве ?

gl00mie · 27.10.2018, 10:43

PurchTotals "переопределить" можно, другое дело, что это нужно делать "иногда". Подобные места все чаще приходится лечить с помощью Option 3. Disposable context, в данном случае: где-то вышле по стеку создать singleton-"флажок", а где-то ниже, скажем, в постобработчике создания PurchTotals, по флажку подпихивать класс-пустышку вместо реального класса расчета итогов. Но выглядит это все очень извратно на фоне нормальных ветвлений в коде, которые можно было делать прежде.

skuull · 27.10.2018, 10:52

Там вообще все плохо с purchline, есть в ГЛ параметрах галка, обрабатывать сабледжер параллельно и из-за нее purchline на апдейте tax сама себя лочит...

**fed** · 13.11.2018, 13:02

Цитата:

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

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

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

dech · 20.11.2018, 15:34

AX 2012 R3. В методе SysDictIndex.showDuplicates() неверно формируется список ORDER BY. Иначе говоря, если подсунуть индекс InventDim.DimIdx, у которого отключены некоторые поля, то неверно составленный запрос вызовет ошибку.
Вместо

X++:

stmtStr += int2str(enabledFields[i]+1);

необходимо указать непрерывную последовательность чисел:

X++:

stmtStr += int2str(i+1);

dech · 21.11.2018, 09:44

Ну и такая же байда с ResultSet, если количество фактических полей не совпадает с описанным, выбирается getString(12) при том, что в SELECT-е участвовало всего 10 полей.

AlexSD · 20.12.2018, 22:07

D365 FO
public class InventItemInventoryDimensionStorageDimConversionTaskInitiatorDelegateHandlers
{
}

В одном имени два раза использованы слова Inventory и Dimension... При Балмере такого не было...
Кто-нибудь натыкался на доку, по каким критериям оценивать таблицы с InventDimId, нужен им конвертер или нет?

axm2017 · 14.01.2019, 10:55

Есть все таки в Ax какие то традиции переходящие имхо из поколение в поколения.
RunBase

X++:

public QueryRun queryRun()
    {
        return null;

    #if.never
        return QR;
    #endif
    }

И в 12 и в 365 соответственно

**sukhanchik** · 14.01.2019, 15:09

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

axm2017 · 14.01.2019, 16:36

Цитата:

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

Хорошие традиции.

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

Stitch_MS · 10.02.2019, 11:02

Logger · 10.02.2019, 11:59

Этот код вывел 16?
Арифметика неверно считает?

**mazzy** · 10.02.2019, 12:43

Цитата:

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

Этот код вывел 16?
Арифметика неверно считает?

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

Stitch_MS · 10.02.2019, 13:48

Цитата:

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

Этот код вывел 16?
Арифметика неверно считает?

При Балмере такого не было.

db · 10.02.2019, 14:16

арифметика не при чем. проблема в реализации case с множественными значениями. если в в такой ветке нет break, то код ветки выполняется столько раз, сколько значений в списке

вот так работает нормально

X++:

    public static void main(Args _args)
    {       
        int i = 1;
        int j = 0;
 
        switch (i)
        {
            case 1:
            case 2,3,4:
                Info("!!");
                j+=8;
                break;
        }
        Info(int2Str(j));
    }

а если убрать break, то выведет 24

а вот так вообще 32:

X++:

   public static void main(Args _args)
    {       
        int i = 1;
        int j = 0;
 
        switch (i)
        {
            case 1, 2,3,4:
                Info("!!");
                j+=8;
        }
        Info(int2Str(j));
    }

где то слышал (так что может и вру) что в IL то ли отсутствует, то ли какая то особенная реализация fall-through - исполнения в switch веток case друг за другом если нет break. Вероятно здесь пытались как то реализовать стандартное X++ поведение switch на особенностях IL и малость перестарались/недосарались в случае с множественными значениями

db · 10.02.2019, 14:26

Цитата:

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

При Балмере такого не было.

да ладно

вот хит на все времена Проверка на RecId

AlGol · 14.02.2019, 10:34

DAX 2012 R3

При переименовании кода складского журнала через паспорт записи не меняется код журнала в InventTransOriginJournalTrans.InventJournalId и в InventTransOrigin.ReferenceId.

В результате, разнести нормально такой журнал не получается.
Плюс - удаление такого журнала оставляет складские проводки Заказано в базе, хотя строки журнала удаляются.

Ivanhoe · 14.02.2019, 10:52

Ну т.е. по факту WTF в данном случае, что эту функцию смены кода оставили. Реально ей пользоваться можно практически никогда.

AlGol · 14.02.2019, 17:23

Цитата:

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

Ну т.е. по факту WTF в данном случае, что эту функцию смены кода оставили. Реально ей пользоваться можно практически никогда.

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

**Vadik** · 27.02.2019, 17:27

Давным-давно, один мальчик установил KB4492562, и все инвойсы стали показывать 4.67. Никто так и не смог разобраться, правильно это было или нет