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

[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 нихрена и ничего не поменялось.