Бухгалтерская отчетность а AX 4.0 и выше

[AlexSD]

Цитата:

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

Народ вы чего?
ГФО написано в 2002г и с тех пор не переписывалось, в сп2 для ах4 дописали сверху (сверху, а не рефвакторинг) выборку из произвольной таблицы (хоть ИнветТранс).

По моим данным, все расчетные классы ГФО полностью переписаны в четверке. Выборка данных из произвольной таблицы существовала еще в трешке.
С пятеркой выходили и еще будут со следующим RU обновления в генераторе.

Так что рекомендую на досуге все-таки заглянуть внутрь, "кто давно уже туда не смотрел". А то кругом неправда получается.

[mazzy]

Сегодня у меня день подчищения хвостов.

Цитата:

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

Так что рекомендую на досуге все-таки заглянуть внутрь, "кто давно уже туда не смотрел". А то кругом неправда получается.

Заглянул. Такая же фигня - считает от начала времен.

Запрос тупо делается по LedgerTrans.
Причем запрос тупо создается, а не берется из AOT - следовательно любая оптимизация range'й может выполняться только программным кодом, а не администратором в АОТ


затем тупо отбираются все проводки с типом периода - обычный (1). Никаких начальных, никаких заключительных... ГФО по прежнему тупо не знают о таких типах проводок

А затем тупо делается цикл по всем проводкам (2).
Никаких промежуточных итогов, никакой оптимизации - тупо суммирует.
Даже никаких попыток сделать group by на сервере. Тупо выбрать все проводки, тупо просуммировать на AOS.


Хотелось бы также обратить внимание на то, как добавляются range.
сперва в query добавляется счет (по этому полю есть индекс), затем тип периода, признак коррекции, тип налога, тип движения, тип коррекции, аналитика... и только в самом конце дата.

во-первых, в LedgerTrans есть только один индекс, который содержит AccountNum - это ACDate.
во-вторых, оптимизатору запроса нужно серьезно постараться, чтобы догадаться использовать этот индекс среди кучи полей в range. Блин, ну хоть бы range с датой наверх поставили что ли?
в-третьих, даже этот индекс как правило предельно неселективный, поскольку даты для сальдо от начала времен до заданной даты. Поэтому оптимизатор с достаточно большой вероятностью выберет Table scan (и это заложено на этапе проектирования!!!)

А что бесит больше всего - никаких попыток сделать группировки и отдать хоть часть работы на SQL...

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

=====================
Если интересно, то сравните с
LedgerBalanceSheetCol_CurMST.buildQuery
LedgerBalanceSheetCol_CurMST.sumUpTrans

Где четко начальные берут из промежуточных итогов, текущие берут из LedgerTrans.
Но обратите внимание, помимо того, что там выбираются небольшие периоды, там в запрос вставлен group by и AOS самостоятельно занимается суммированием очень небольшого количества записей. В основном, всю работу выполняет SQL.

Или взять тот же тупой LedgerBalanceCur_Current
Хоть и он на промежуточные итоги плевать хотел, но хотя бы группировку делает на стороне SQL и пытается хоть какой-то кэш сделать...

=====================
В общем, AlexSD, при всем моем уважении - принципиально в RRG нихрена и ничего не поменялось.

[mazzy]

Цитата:

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

Сегодня у меня день подчищения хвостов.
...
А что бесит больше всего - никаких попыток сделать группировки и отдать хоть часть работы на SQL...

Ага!!! Был неправ. Извините. Есть суммирование. Без группировки. Как раз между range'ами. И в 4ке было.

    queryBuildDataSource.addSelectionField(amountFieldId, SelectionField::Sum);
    queryBuildDataSource.orderMode(OrderMode::GroupBy);

В 3ке было по-другому.
Что ж, и на этом спасибо. Теперь бы от начала времен не суммировать, теперь бы не делать отдельный запрос на каждую формулу... покэшировать и прочую оптимизацию...

[mazzy]

Цитата:

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

По моим данным, все расчетные классы ГФО полностью переписаны в четверке.

Цитата:

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

В 3ке было по-другому.

Смотрю в 3ку и 4ку. Осознал объем доработок.
В целом локализаторы поработали много и хорошо. Согласен с AlexSD.
Жаль, что об этом никто не написал в свое время доходчивую статью. Жаль, что не посмотрел в свое время.

Но все равно еще работать и работать над производительностью ГФО.