Бухгалтерская отчетность а 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?

Да. Да. Нет.

[BOAL]

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

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

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

[Nick]

Цитата:

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

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

Спасибо.

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

[AlexSD]

Цитата:

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

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

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

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

[AlexSD]

Цитата:

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

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

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

[Nick]

Цитата:

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

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

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

[Raven Melancholic]

Хотя у нас план счетов сделан таким образом, что можно получать многие данные не анализируя обороты между счетами, не смотреть корреспонденцию и т.п., тем не менее мы пользуемся российским генератором финансовой отчетности. На мой взгляд, стандартная финансовая отчетность лучше (по крайней мере, логичнее, чем российская), но ей недостает возможности выводить данные в настроенный шаблон. Для внутренних задач это нормально, но есть такой зверь, как минфин, который хочет иметь отчетность в установленных формах (можно сколько угодно возмущаться этим, но есть такой факт и имея систему, в которую вложено почти лям долларов, заставлять пользователей перебивать из одного отчета в другой данные вручную глупо).
AlexSD говорит, что в DAX2009 много в российский генератор добавлено, но мы-то работаем на четверке (которую, судя по всему, MS просто забросил), поэтому в этот генератор мы сами добавила следующие возможности:

• Работа по нескольким компаниям (список нужных компаний задается в настройках групп компаний).
• Получение остатков не "с начала времен", а с учетом финансового года (как уже говорил, нам корреспонденция не особо нужна из-за того, что план счетов уже предусматривает получение нужных данных и без неё, поэтому эта модификация была несложной).
• Установка параметров не только в настройках генератора, а и при запуске (фильтры по аналитике, по компаниям, по периодам и т.п.).
• Получение данных модулей не через профили разноски, а по счетам, записанным в модульные проводки.

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

[ALES]

Цитата:

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

Да. Да. Нет.

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

[Alexx7]

Ещё вопрос по ГФО. (AX 4.0 sp2)
Период указанный в настройке ГФО на что то влияет? (ГК\Настройка\ГФО\ закладка "Разное" поле "Период:")
Как не старался менять период, данные не меняются.

[Raven Melancholic]

Цитата:

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

Ещё вопрос по ГФО. (AX 4.0 sp2)
Период указанный в настройке ГФО на что то влияет? (ГК\Настройка\ГФО\ закладка "Разное" поле "Период:")
Как не старался менять период, данные не меняются.

Оно используется в том случае ,если в настройках ячейки и в настройках формул не указан свой период. Если же он там указан, то период, настроенный в самом отчете не используется. То же относится и к аналитикам и к большинству прочих настроек.

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

[AlexSD]

Мази, протри глаза. Там есть и группировка и суммирование. И еще перечитай мой пост повнимательнее.

[mazzy]

Цитата:

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

Мази, протри глаза. Там есть и группировка и суммирование. И еще перечитай мой пост повнимательнее.

где? можно метод и цитату из него? в какой версии?

я смотрел ax2009. ядро 5.0.1000.52, приложение 5.0.1000.176

[mazzy]

Цитата:

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

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

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

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

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

[mazzy]

Цитата:

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

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

Цитата:

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

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

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

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