Генератор финансовых отчётов

[AlexSD]

В подготавливаемом обновлении к четверке скорость расчета операций генератора российских отчетов значительно повышена.

[glibs]

Цитата:

Сообщение от Михаил Андреев

...
Ты же хорошо ковывял эти отчёты. Расскажи, какие там весёлости есть. Что работает хорошо, а что плохо.
Я уже отметил: при расчётах в корреспонденции диапазоны работают медленно, плюс реально делается перебор всех проводок (!).
...

Это тема для... ну дипломной работы как минимум.

Давно было. Полигоном была 3.0 сп3 еще. MS SQL 2000 sp4. Сразу уточню, что работал только с проводками и бюджетом. В регистры не лазил. Все, что связано с корреспонденцией не трогал.

Преамбула. Русские финотчеты работают специфически. Для КАЖДОЙ ОПЕРАЦИИ в КАЖДОЙ ЯЧЕЙКЕ происходит следующее:
1. Строятся временные таблицы по всем условиям (список допустимых финансовых аналитик, список допустимых типов операций, список допустимых типов учета и т.д.). С учетом наследования по трем уровням.
2. Перебираются поштучно ВСЕ проводки, которые удовлетворяют диапазону дат, заданному на одном из уровней настройки отчета. При этом нужно понимать, что для операций "оборот" перебираются проводки с начальной даты по конечную, а для сальдо — с начала времен по конечную.
3. Каждая проводка сравнивается с рядом условий (сторно-несторно, список допустимых типов учета, список допустимых типов операции, ...) и либо суммируется, либо выбрасывается.

Насколько быстро это может работать, думаю, любой может догадаться.

Причина того, что не используются агрегированные данные таблиц LedgerBalancesTrans и LedgerBalancesDimTrans... Если кто не знает - в них сгруппированы обороты за день в разрезе типа проводки, счета ГК, а во второй еще и по аналитикам. Считать по таким таблицам проще (подробности в поиске).

Так вот причина того, что они не используются заключается в фильтрах по типу операции и сторно. По ним нет никаких агрегаций, и единственным вариантом анализа данных является анализ самих проводок.

Если ограничиться только вопросами производительности, то:
1. Генератор считает данные на клиенте. Судя по всему, автор решил, что раз Эксельку не откроешь на АОСе, то и данные посчитать тоже на клиенте. С учетом описанного выше можно себе представить, какой траффик между клиентом и сервером генерит построение простого российского финансового отчета. Если клиент живет рядом с сервером на хорошей сети, то можно и не ощутить разницу. Но я как-то запустил это чудо на одномегабитной сети по-моему... "О-о-о-о-о," только смог я сказать тогда.

Починить можно быстро. Не очень красиво... но я предпочитаю меньше кодировать на стандартной функциональности, чтобы потом не было мучительно больно при переходе на следующий СП.

С учетом моего тогдашнего невысокого опыта в средствах разработки вся процедура от анализа до исправления заняла мин. 20. Микрософт уже много лет не находит времени уделить этому нюансу внимание.

2. Не то, чтобы радикально, но факт. Как это ни банально, но создание кластерных индексов на таблицах LedgerRRGAccountInterval_RU, LedgerRRGCellTable_RU, LedgerRRGDimensionInterval_RU, LedgerRRGOffsetAccountInterval_RU, LedgerRRGOperationTable_RU повышает скорость выборки данных для отчета. Еще раз повторю, что не радикально. Можно сказать даже не существенно на фоне вышеописанного. Ну и поставить EntireTable кэш на LedgerRRGReportTable_RU равно как и группу таблиц Group какой-нибудь вместо Misc тоже не помешает.

3. Смастерил как-то клиент на моей прошлой работе отчет из более 6000 ячеек (простыню на примерно 180х32 клеток). На нормальном сервере считалось порядка 90 минут на небольшой базе. Только обороты, между прочим. Сильно грузится АОС при этом. Сервер БД отдыхает почти. Нет не то чтобы долгоиграющих запросов... собственно и недолгоиграющих нет. Сплошные вложенные циклы и математика.

Удалось оптимизировать за счет того, что был переписан select. Вместо перебора проводок был организован select с group by по всем полям, которые используются в операциях. Удалось перераспределить нагрузку между АОС (п. 1 уже был реализован тогда) и сервером БД (цифры с лаптопа) с 95% 5% времени процессора на 70% 30%. В результате появляется возможность более оптимального использования железа.

Кратность прироста производительности зависит от количества финансовых аналитик. Чем их больше, тем меньше будет прирост. В том случае аналитик было очень много. Не меньше трех сотен на 5 кодов аналитики (можно себе представить количество возможных комбинаций). На лаптопе отчеты стали строиться минимум в два раза быстрее, на сервере — минимум в 3. Некоторые более чем в 5 раз (где комбинаций аналитик на операциях было не так много).

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

4. Когда я дорисовывал к русским финотчетам тип операции Прогнозные проводки (LedgerCov), то у меня была идея сделать альтернативный расчет сальдо и оборотов (без корреспонденции, разумеется). Суть идеи была в переходе на стандартный Аксаптовский механизм расчета оборотов и сальдо по таблицам LedgerBalancesTrans и LedgerBalancesDimTrans. При этом потеряются фильтры по типу операции и сторно. Но там, где они не нужны, прирост производительности будет, мягко говоря, очень ощутимый. Но такое я не делал. Только размышлял.

Это только производительность. Есть еще темы про баги (явную багу я упоминал выше), и то, что Микрософт багами не признает, но... Примеры описаны выше, когда речь шла о бюджетных моделях и финансовых аналитиках.

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

Отдельно лишь отмечу... ну очень хочется... что в русских финотчетах нет даже кнопки для копирования настройки ячейки. Строить их очень тяжело в результате. Помнится я как-то нарисовал кнопку копирования ячейки внутри отчета. Выяснилось, что даже этого мало. Очень востребованными оказался джоб по копированию колонок и/или строк (по маске с редактированием кода ячейки) внутри отчетов. Но хитом оказался джоб, который умел копировать ячейки (все или часть — по маске) одного отчета в другой отчет в той же компании или даже в другой компани. Если использовать русские финотчеты в качестве одного из основных движков для построения управленческой отчетности, то это просто необходимо.

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

Цитата:

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

Все, что связано с корреспонденцией не трогал.

Э-э-э. Ты самое интересное пропустил Там ещё круче.
На первом шаге делается перечисление всех комбинацией счетов дебет-кредит. Включая все типы счетов, заголовки тоже
Далее - то, что ты написал (прикольно было наблюдать в логе запросы типа Дебет счета типа Заголовок и Кредит счета типа Итого), но плюс фильтр на корреспонденцию. Скорости в работе корреспонденция не добавляет (из серии "Старые валенки стояли на полу и воздух тоже не озонировали" (с) "12 стульев").

Из любопытного я бы добавил повальную связь таблиц российских отчётов по RecId, в результате чего нельзя перенести ОДИН отчёт из одной базы в другую. Только все сразу.

[glibs]

Цитата:

Сообщение от Михаил Андреев

...
Э-э-э. Ты самое интересное пропустил Там ещё круче.
...

Я уже обратил внимание на многоэтажность запроса, который там выбирает проводки.

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

Цитата:

Сообщение от Михаил Андреев

...
Из любопытного я бы добавил повальную связь таблиц российских отчётов по RecId, в результате чего нельзя перенести ОДИН отчёт из одной базы в другую. Только все сразу.
...

Один отчет целиком точно можно. Я делал стандартным экспортом-импортом. Правда, потом джоб написал...

[glibs]

Цитата:

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

...
Преамбула. Русские финотчеты работают специфически. Для КАЖДОЙ ОПЕРАЦИИ в КАЖДОЙ ЯЧЕЙКЕ происходит следующее:
1. Строятся временные таблицы по всем условиям (список допустимых финансовых аналитик, список допустимых типов операций, список допустимых типов учета и т.д.). С учетом наследования по трем уровням.
2. Перебираются поштучно ВСЕ проводки, которые удовлетворяют диапазону дат, заданному на одном из уровней настройки отчета. При этом нужно понимать, что для операций "оборот" перебираются проводки с начальной даты по конечную, а для сальдо — с начала времен по конечную.
...

Совсем забыл написать. Еще строится табличка-список всех счетов плана счетов, по которым считаются проводки. Со злополучным дублированием в том числе. И уже для каждого счета из списка в рамках каждой операции для каждой ячейки Эксельки перебираются проводки.

[glibs]

Цитата:

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

...
В подготавливаемом обновлении к четверке скорость расчета операций генератора российских отчетов значительно повышена.
...

Интересно, к чему бы это?

Небось Восточная Европа "попробовала" отчеты и пришла в восторг от их производительности?

[AlexSD]

Цитата:

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

Небось Восточная Европа "попробовала" отчеты и пришла в восторг от их производительности?

Да, нет... Просто руки дошли

[glibs]

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

[longson]

А что будет если необходимо вычислить исходящее сальдо с некоторой аналитикой ?

По вашим предыдущим постам для вычисления этой суммы система возьмет все проводки с заданной аналитикой с начального момента функционирования системы.

[glibs]

Если вопрос ко мне, то вы меня недопоняли где-то.

Еще раз.

Для каждой операции в каждой ячейке в настройках отчета происходит следующее.

1. Строиться список счетов ГК, которые указаны в операции (м.б. один, а м.б. и много).
2. Перебираются все проводки за указанный в настройках операции (явно или на верхних уровнях) период по каждому из счетов.
3. Дальше каждая проводка проверяется на соответствие целому ряду условий (аналитики, тип операции, сторно-несторно, тип учета). И либо прибавляется к результату, либо нет.

Подставить все описанные в п.3 критерии в запрос проблематично. Поэтому перебираются проводки. Аналитики и типы учета предварительно вычисляются и содержатся во временной таблице.

[longson]

Я так и вас понял. Вопрос у меня такой. Допустим что в настройках операции для определенного счета настроим аналитику конкретную и тип операции Сальдо, тип сальдо Исходящее, то как система вычисляет эту цифру, если он не видит проводки закрытых периодов ? Или вы имеете ввиду, что будет подставляться сумма исходящих остатков по данной аналитики по данному счету с последнего закрытого счета + оборот по данному периоду ?

[glibs]

Во-первых, не ЗАКРЫТЫХ, а ЗАКРЫВАЮЩИХ. Посмотрите ГК\Настройки\Периоды\Периоды, колонка Тип периода. Есть ощущение, что вы путаете тип периода со статусом.

[longson]

А. да, извините, я неправильно пост читал.

Спасибо, тема очень полезна для меня.

[glibs]

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

Было бы неплохо, если бы на уровне операции или ячейки можно было указать компанию, из которой выбираются данные. Чтобы можно было строить консолидированную управленческую отчетность, как в международных финотчетах.

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

[longson]

А можно сделать так чтобы в строки подтягиваются ни только суммы а ещё и количество ? Это уже не финансовые отчёты, а как генератор екселовских отчётов для разных подразделений

[veps]

LedgerRRGReportTable_RU.xpo

посмотрите проект (в вашем регионе тоже есть плата за негативное воздействие на окружающую среду )

[glibs]

Цитата:

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

...
А можно сделать так чтобы в строки подтягиваются ни только суммы а ещё и количество ?
...

Вы 3.0 сп5 и выше случайно не видели?

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

Цитата:

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

...
Это уже не финансовые отчёты
...

Если вы вели речь о поле Количество в таблице проводок в ГК (LedgerTrans.Qty), то, IMHO, вполне финансовые.

[longson]

Цитата:

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

Если вы вели речь о поле Количество в таблице проводок в ГК (LedgerTrans.Qty), то, IMHO, вполне финансовые.

Я имею ввиду "Не только финансовые отчёты"

Конечне пользователи у нас хотят работать в Excel более чем в Axapta

[glibs]

Вот еще, если интерес не пропал .

Раньше на почти всех таблицах LedgerRRG* свойство TableGroup стояло Miscellaneous. В 4.0 уже стоят преимущественно WorkseetHeader и WorksheetLine.

Лучше, но я с этим все равно не согласен. IMHO — это все-таки настройки. Там должно быть Group. Как на таблицах LedgerTableAlternative, LedgerTableAlternativeTrans, LedgerTableInterval, LedgerBalHeader и LedgerBalColumns.

[Aleks_K]

Цитата:

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

... Русские финотчеты отказываются видеть проводки в закрывающем периоде. Просто тупо их не учитывают...

Вы видимо говорили о 3 версии, и у меня такое впечатление что на 4 то же самое
Не хочет обороты в закрывающем периоде отображать в отчете
Может есть какая-то заплатка или т.п.?