AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.04.2007, 23:47   #1  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от Михаил Андреев
...
Ты же хорошо ковывял эти отчёты. Расскажи, какие там весёлости есть. Что работает хорошо, а что плохо.
Я уже отметил: при расчётах в корреспонденции диапазоны работают медленно, плюс реально делается перебор всех проводок (!).
...


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

Давно было. Полигоном была 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®
За это сообщение автора поблагодарили: Laura (1).
Старый 17.04.2007, 00:14   #2  
Михаил Андреев is offline
Михаил Андреев
Участник
Компания АМАНД
Лучший по профессии 2009
 
1,296 / 239 (10) ++++++
Регистрация: 09.11.2001
Адрес: Химки, Московская область
Цитата:
Сообщение от glibs Посмотреть сообщение
Все, что связано с корреспонденцией не трогал.
Э-э-э. Ты самое интересное пропустил Там ещё круче.
На первом шаге делается перечисление всех комбинацией счетов дебет-кредит. Включая все типы счетов, заголовки тоже
Далее - то, что ты написал (прикольно было наблюдать в логе запросы типа Дебет счета типа Заголовок и Кредит счета типа Итого), но плюс фильтр на корреспонденцию. Скорости в работе корреспонденция не добавляет (из серии "Старые валенки стояли на полу и воздух тоже не озонировали" (с) "12 стульев").

Из любопытного я бы добавил повальную связь таблиц российских отчётов по RecId, в результате чего нельзя перенести ОДИН отчёт из одной базы в другую. Только все сразу.
__________________
Михаил Андреев
https://www.amand.ru
Старый 17.04.2007, 00:28   #3  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от Михаил Андреев
...
Э-э-э. Ты самое интересное пропустил Там ещё круче.
...
Я уже обратил внимание на многоэтажность запроса, который там выбирает проводки.

Не исключено, что что-то путевое и хитрое (пипа п.3 моего предыдущего поста) можно попробовать сделать и с ним. Но на энтузиазме я сейчас этого не потяну. Да и недолюбливаю я корреспонденцию, если честно.
Цитата:
Сообщение от Михаил Андреев
...
Из любопытного я бы добавил повальную связь таблиц российских отчётов по RecId, в результате чего нельзя перенести ОДИН отчёт из одной базы в другую. Только все сразу.
...
Один отчет целиком точно можно. Я делал стандартным экспортом-импортом. Правда, потом джоб написал...
__________________
С уважением,
glibs®
Старый 17.04.2007, 01:03   #4  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от glibs Посмотреть сообщение
...
Преамбула. Русские финотчеты работают специфически. Для КАЖДОЙ ОПЕРАЦИИ в КАЖДОЙ ЯЧЕЙКЕ происходит следующее:
1. Строятся временные таблицы по всем условиям (список допустимых финансовых аналитик, список допустимых типов операций, список допустимых типов учета и т.д.). С учетом наследования по трем уровням.
2. Перебираются поштучно ВСЕ проводки, которые удовлетворяют диапазону дат, заданному на одном из уровней настройки отчета. При этом нужно понимать, что для операций "оборот" перебираются проводки с начальной даты по конечную, а для сальдо — с начала времен по конечную.
...
Совсем забыл написать. Еще строится табличка-список всех счетов плана счетов, по которым считаются проводки. Со злополучным дублированием в том числе. И уже для каждого счета из списка в рамках каждой операции для каждой ячейки Эксельки перебираются проводки.
__________________
С уважением,
glibs®
Теги
ax3.0, faq, отчет

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Генератор финансовых отчетов Umi DAX: Функционал 1 29.10.2010 16:13
Загрузка Российских Финансовых Отчетов в Аксапту GLU DAX: База знаний и проекты 1 15.12.2006 01:13
Генератор российских финансовых отчетов sev DAX: Функционал 1 28.11.2005 12:26
ИТОГИ для строк финансовых отчетов AlexR DAX: Программирование 2 31.05.2004 12:00
Исправление ошибок стандартного конструктора финансовых отчетов Evgeny DAX: Программирование 0 11.01.2002 13:57

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 08:09.