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

[Alexx7]

В итоге.
1. Стоит ли тратить время на расширение модуля, добавив дополнительные таблицы промежуточных итогов?
2. Сколько это может занять времени (вопрос тем, кто уже делал или начинал делать)?
3. Решит ли это вопрос производительности системы и на сколько процентов (примено)?

Спасибо.

[Михаил Андреев]

Цитата:

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

В итоге.
1. Стоит ли тратить время на расширение модуля, добавив дополнительные таблицы промежуточных итогов?

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

Цитата:

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

2. Сколько это может занять времени (вопрос тем, кто уже делал или начинал делать)?

Не начинал, не знаю.

Цитата:

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

3. Решит ли это вопрос производительности системы и на сколько процентов (примено)?

Смотря что. Ведение таблицы промежуточных итогов по корреспонденции плюс добавление "лишних" полей (в LedgerTrans, например, поля по корреспонденции, в Cust/VebdTrans поля по счетам и т.п., детали надо смотреть) может ускорить работу специализированных отчётов по корреспонденции (ГФО и ОСВ) даже не в разы, а на порядки, всё зависит от объёма данных по проводкам. Если таблицы маленькие, результат будет просто незаметен.
Или, как уже предлагали, перетащить всё в OLAP. Тогда ломать ничего не придётся.

[mazzy]

Цитата:

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

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

дополнительные таблицы? - ни в коем случае!
расширять можно. Но по-моему, не стоит.

Технологичнее смотреть в OLAP. Тут правильно посоветовали.

Цитата:

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

2. Сколько это может занять времени (вопрос тем, кто уже делал или начинал делать)?

Очень много времени.
Начинали многие. Доведенного до конца решения ни разу не видел.

Цитата:

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

3. Решит ли это вопрос производительности системы и на сколько процентов (примено)?

Процентов?
Решит кардинально - с Аксаптой можно будет работать. Сейчас через год-полтора-два российские отчеты (включая ГФО) встают колом и тупо не работают.

[ALES]

Цитата:

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

Сейчас через год-полтора-два российские отчеты (включая ГФО) встают колом и тупо не работают.

Кто-то предъявлял претензии к "производителю"? Денег требовал обратно? Может потому и не хотят понимать суть проблемы в MS?

[mazzy]

Цитата:

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

Кто-то предъявлял претензии к "производителю"? Денег требовал обратно? Может потому и не хотят понимать суть проблемы в MS?

Да. Да. Нет.

[ALES]

Цитата:

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

Да. Да. Нет.

И каковы результаты? Отдали денежки?

[BOAL]

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

Функционал работает же? Да! А работает - не трож!
Все нововведения за 7 лет не отслеживались точно, если предметно доказать неработоспособность ГФО и затребовать что-то обеспечивающее учет по РСБУ, например, то могут и доделать.

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

[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ке было по-другому.
Что ж, и на этом спасибо. Теперь бы от начала времен не суммировать, теперь бы не делать отдельный запрос на каждую формулу... покэшировать и прочую оптимизацию...

[Nick]

Цитата:

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

В итоге.
1. Стоит ли тратить время на расширение модуля, добавив дополнительные таблицы промежуточных итогов?
2. Сколько это может занять времени (вопрос тем, кто уже делал или начинал делать)?
3. Решит ли это вопрос производительности системы и на сколько процентов (примено)?

Спасибо.

Года эдак 3 назад еще в Аксапте 3.0, до MBS-апгрейда отчетности, доработали генератор отчетности для формирования регламентированной отчетности по РСБУ и НУ.
Сколько времени потратили на разработку и отладку точно уже не помню, но не больше недели.
Научили генератор выводить в Excel текстовые значения, даты и значения специальных процедур-функций, для того чтобы консультант или бухгалтер могли определять ячейку в генераторе по нормальному (понятному) имени из списка заранее запрограммированных для этих целей программистом процедур-функций (например, процедуры формирования развернутого сальдо ).
После доработки пользователи на скорость формирования отчетности уже не жаловались
+ добавили еще копирование отчетов - упростив себе сопровождение и тиражирование ...

[AlexSD]

Цитата:

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

Научили генератор выводить в Excel текстовые значения, даты и значения специальных процедур-функций, для того чтобы консультант или бухгалтер могли определять ячейку в генераторе по нормальному (понятному) имени из списка заранее запрограммированных для этих целей программистом процедур-функций (например, процедуры формирования развернутого сальдо ).
После доработки пользователи на скорость формирования отчетности уже не жаловались
+ добавили еще копирование отчетов - упростив себе сопровождение и тиражирование ...

Все выше перечисленное есть в пятерке, а копирование отчетов есть и в четверке.

[Nick]

Цитата:

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

Все выше перечисленное есть в пятерке, а копирование отчетов есть и в четверке.

Я давно просил МБС это сделать (и много еще чего полезного для ведения РСБУ и НУ), так и не дождался тогда, и клиент не захотел так долго ждать
PS они до сих пор на 3-ке работают ...