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

[longson]

Кто-нибудь из вас уже активно использовали эту функциональность системы (генератор финансовых отчётов) на Ax 3.0 SP5 ?

У меня несколько вопросов по ней, попробовал найти в форуме но не удалось, может быть кто-нибудь мне подскажет

У меня в шаблоне Excel есть несколько листов, как с помощью генератора отчётов заполнять сразу несколько этих листов (в одной книге). В настройке я нашёл только адрес ячейки, а не лист ....

[glibs]

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

Добавлено: Вообще используем, конечно. С доработками различного рода.

[longson]

Вы что работаете ночью субботы - воскресенье ? А я думал что я один.

Случайно нашёл что можно делать так, там в поле для заполнения ячейки можно прописать axapta!A1 (если этот лист называется axapta)

[glibs]

Да, ваш вариант лучше и работает не смотря на то, что в генераторе прошит первый лист Эксельки.

[longson]

Второй вопрос у меня такой: Для фильтрации типа проводки, периода расчёта и аналитики можно задавать соответствующие критерии как минимум в 3 местах: в форме "Генератор финансовых отчётов" для каждого отчёта (вкладки Разное, Проводки и Аналитика), в форме "Настройка" для каждого отчёта, там можно задавать критерии в верхней части формы или в нижней. Так, если задавать значение для какого-нибудь критерии сразу в 3 местах, то какое из них "выиграет" ? Если я правильно думаю что значение в нижней части формы "Настройки" сильнее всех остальных ?

Ещё, какой смысл параметра "Базовая дата" при печати отчёта ? Если я задавал параметр "Период" конкретным значением например 01 Январь то что значит здесь Базовая дата ?

В документации Финансы об этом уже читал и не нашёл ответа, поэтому вас спрашиваю на форуме Спасибо за ответы.

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

Цитата:

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

Ещё, какой смысл параметра "Базовая дата" при печати отчёта ? Если я задавал параметр "Период" конкретным значением например 01 Январь то что значит здесь Базовая дата ?

В документации Финансы об этом уже читал и не нашёл ответа, поэтому вас спрашиваю на форуме Спасибо за ответы.

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

[glibs]

Цитата:

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

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

Приоритет имеет более нижний уровень (уровень операции).

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

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

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

С остальными настройками, по-моему, дела в этом плане обстоят нормально. Но есть бага, когда тип операции не анализируется для операций "Оборот...".

С периодом расчета все ОК. Более низкий имеет приоритет.

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

Цитата:

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

...
Ещё, какой смысл параметра "Базовая дата" при печати отчёта ? Если я задавал параметр "Период" конкретным значением например 01 Январь то что значит здесь Базовая дата ?
...

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

Однако указание фиксированной даты в интервалах дат не есть удобным. Обычно так не делают.

[longson]

Понял, спасибо. Только вот немного противоречий

Цитата:

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

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

Цитата:

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

Интервалы дат указываются для самого отчёта и для каждой ячейки в отдельности. Если в ячейке не указан интервал дат, берётся из настроек отчёта.

Попробую на реале, результаты обязательно описать

Цитата:

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

Однако указание фиксированной даты в интервалах дат не есть удобным. Обычно так не делают.

Цитата:

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

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

Да, в документации почти ничего не описано об этом, нашёл полезные материалы по этой теме только здесь http://axapta.mazzy.ru/lib/ledgerperiodcode/

Ещё вопрос у меня такой: Если в настройке операции указать тип диапазона Диапазон счётов и настроить этот диапазон, например с 01.001 по 01.005, то в данной операции будет вычисляться сумма по этим счётам ?

Если да, то интересно почему не даёт указать в качестве отдельного счёта итоговой счёт...

[glibs]

Цитата:

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

...
Ещё вопрос у меня такой: Если в настройке операции указать тип диапазона Диапазон счётов и настроить этот диапазон, например с 01.001 по 01.005, то в данной операции будет вычисляться сумма по этим счётам ?
...

Ну да.

Цитата:

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

...
Если да, то интересно почему не даёт указать в качестве отдельного счёта итоговой счёт
...

А почему не дает? Если вы укажете в поле Диапазон счетов "Счет", то в поле Счет можете указать хоть "1*".

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

Эту особенность я тоже отключал для однообразия с международной функциональностью.

[longson]

Цитата:

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

А почему не дает? Если вы укажете в поле Диапазон счетов "Счет", то в поле Счет можете указать хоть "1*".
.

Если так то туда суммируются и итоговой счёт ? Допустим что у нас 01.0000 - итоговой счёт, а субсчёта есть 01.0001 .. 01.0005. Тогда при настройке 01*, сумма будет дублироваться ?

Я говорил "не даёт...." потому что в списке не показывают итоговые счёта

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

Цитата:

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

Ещё вопрос у меня такой: Если в настройке операции указать тип диапазона Диапазон счётов и настроить этот диапазон, например с 01.001 по 01.005, то в данной операции будет вычисляться сумма по этим счётам ?

Если да, то интересно почему не даёт указать в качестве отдельного счёта итоговой счёт...

Не надо использовать диапазон счетов.

[Tihonya]

страницу можно задать точто так же как это делается в Excel. Ссылкой на страницу является указательный знак.
Фотмат таков:
![название страницы]'[номер ячейки]'

[glibs]

Да.

[longson]

А почему ? Просто какой-то глюк там ?

Если счёт имеет 9 субсчётов то мне придётся настроить 9 операции для получении суммы ?

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

Цитата:

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

А почему ? Просто какой-то глюк там ?

Если счёт имеет 9 субсчётов то мне придётся настроить 9 операции для получении суммы ?

Нет, там не глюк. Там такой весёлый алгоритм расчёта, закачаешься Правда, медленно работают только расчёты с корреспонденцией. Если без корреспонденции, нормально. Потому диапазоном лучше не пользоваться.
Лучше ставить правильные фильтры в счетах, при чём не звёздочками, а перечислением. Так работает быстрее.
А 9 счетов просто перечислить через запятую в поле "Счёт" и всего делов. Или интервал указать, так тоже можно.

[longson]

А вообще такой отчёт быстро выводится ?

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

Отчёт следующий (в приложении).

Если настроит чётко: например, в ячейке D5 - операция исходящего остатка счёта 01.0010 в период января... тогда получается, что я должен настроить 48 ячеек, да это и только первая - самая простая часть общего отчёта. Можете подсказать как-то можно обойти ?

Если по моему подходу, то каждый месяц запускаем отчёт и будут снова вычисляются все данные с начала года, как то не красиво

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

Цитата:

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

Отчёт следующий (в приложении).

Если настроит чётко: например, в ячейке D5 - операция исходящего остатка счёта 01.0010 в период января... тогда получается, что я должен настроить 48 ячеек, да это и только первая - самая простая часть общего отчёта. Можете подсказать как-то можно обойти ?

Такой отчёт лучше сделать в международном генераторе. Будет просто летать по сравнению с российским.

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

Не понял. Что обойти?

2 glibs:

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

[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, в результате чего нельзя перенести ОДИН отчёт из одной базы в другую. Только все сразу.