fed: Ledger Balance Data in DAX

[fed]

Цитата:

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

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

Проблема в том, что на внедрениях обычно выявляется куча дополнительных учетных объектов, которые в Аксапте никуда не засунуть. Надо, например, вести учет маркетинговых затрат в разрезе компаний и продуктовых линеек - их в аналитику засовывать. Надо затраты на обучение персонала вести в разрезе продуктовых линеек - их в аналитику засовывают и так далее.
Просто проблема в том что все эти *Trans таблицы они очень хороши для учета активов и пассивов. А для учета затрат, ничего умнее ledgerTrans не придумали.
Можно конечно пытаться клиентов нагнуть на реструктуризацию статей затрат, но на практике проще аналитик побольше завести, чем клиента пытаться жизни учить. Так что да - в идеальном мире - табличка балансов должна быть небольшой. В реальном - она почти всегда сопоставима по размерам с таблицей транзакций ГК.

[fed]

Цитата:

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

Ой. Тогда будет лучше 1Сом заниматься.

Лично я считаю, что идеальным вариантом было бы: единый инструмент разработки как для самих разработчиков в MS, так и для клиентов.

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

А то получается фигня какая-то, типа Райкинского "К гульфику претензии есть?"
Выборка данных через AOS vs SQL Server

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

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

[mazzy]

Цитата:

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

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

продуктовые линейки - суть ГРУППЫ.
их вполне можно засовывать в аналитики. группы исчисляются максимум сотнями.

беда начинается, когда в фин.аналитику засовывают тысячи элементов: номенклатуры, контрагенты, партии, ГТД (то, что в Аксапте хранится в других справочниках)

Цитата:

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

Можно конечно пытаться клиентов нагнуть на реструктуризацию статей затрат, но на практике проще аналитик побольше завести, чем клиента пытаться жизни учить.

Мы о разном говорим. Я говорю о автоматически синхронизируемых с фин.аналитикой (больших) справочниках.

Ты говоришь о статьях затрат.
Во-первых, их вряд ли будет больше нескольких сотен. Это не так критично.
"нагнуть" - а куда деваться.
Ведь человеку придется каким-то образом указывать эту аналитику. Во время разработки правил заполнения и происходит "нагибание" и "реструктуризация".

Цитата:

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

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

Согласен.

Цитата:

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

В принципе - можно было бы организовать собственный нормальный консалтинг, который...

Ну... сразу что-то радикальное.
Улучшать можно и более точечными решениями.

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

А еще лучше, чтобы не только знали, но и учитывали эти знания при разработке

[mifi]

Цитата:

Сообщение от Blog bot

Источник: http://fedotenko.info/?p=167
==============

I remembering the first time when our team was developing a solution which was supposed to quickly calculate the GL balance for specific GL Account/Dimension combination. It was 2001 and we were developing the cost allocation functionality.

...

Although, as I said, I have never seen any actual implementations of Dynamics AX 3-4 which really suffered from ledger balance data related bottlenecks, It might be that these problems would arise in 3000-4000 user implementation. (Never have seen personally implementations with more then 700-800 users). Overall, the whole history of changing approach to balance data in DAX looks like a good example of software design and engineering.



Источник: http://fedotenko.info/?p=167

Думаю, что не открою большого секрета, если скажу, что наши западные коллеги рассматривают многострочные проводки в качестве основного сценария для тестирования чего угодно, в том числе и производительности. А с точки зрения практики российских внедрений это зверь очень редкий.
От этого все и идет. Это, в принципе, и к вопросу про "знание о внедрениях". Уверяю, что знания более чем достаточно, просто то, как систему используют в России/Восточной Европе очень сильно отличается от тех же Штатов. А далее это уже вопрос приоритетов этих самых сценариев и т.д.

[fed]

Цитата:

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

Думаю, что не открою большого секрета, если скажу, что наши западные коллеги рассматривают многострочные проводки в качестве основного сценария для тестирования чего угодно, в том числе и производительности. А с точки зрения практики российских внедрений это зверь очень редкий.
От этого все и идет. Это, в принципе, и к вопросу про "знание о внедрениях". Уверяю, что знания более чем достаточно, просто то, как систему используют в России/Восточной Европе очень сильно отличается от тех же Штатов. А далее это уже вопрос приоритетов этих самых сценариев и т.д.

Если честно - я вообще не понимаю всех этих проблем с производительностью рассчета баланса/оборотов по ГК. Потому как используется это только для рассчета баланса и отчета о прибылях и убытках, которые раз в месяц строяться и особой производительности не требуют. Если же ты пытаешься какие-то более детальные отчеты по ГК получить, то все равно проще проводки в OLAP загнать и там крутить.
Мне кажется что у mazzy такое внимание к этим остаткам - это следствие глубинной психологической травмы от работы с 1c в 90ых

[mifi]

Цитата:

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

Если честно - я вообще не понимаю всех этих проблем с производительностью рассчета баланса/оборотов по ГК. Потому как используется это только для рассчета баланса и отчета о прибылях и убытках, которые раз в месяц строяться и особой производительности не требуют. Если же ты пытаешься какие-то более детальные отчеты по ГК получить, то все равно проще проводки в OLAP загнать и там крутить.
Мне кажется что у mazzy такое внимание к этим остаткам - это следствие глубинной психологической травмы от работы с 1c в 90ых

Видишь, какие разные у всех людей представления о внедрениях. Кто-то не понимает проблем с закрытием склада: а что, делается раз в месяц, в чем проблема-то? Кто-то не понимает проблем расчета баланса/оборотов по ГК...

[glibs]

Цитата:

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

...
После того как в DAX2009 они вообще стали балансы складывать тупым суммированием оборотов по счету+аналитика внутри ваучера (то есть - даже не по схеме 20 записей в день по счет+аналитика)
...

Прошу уточнить о чем именно речь.

[glibs]

Цитата:

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

...
по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans.
...

Готов подтвердить.

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

Проблема была в активном использовании нескольких сот статей затрат (и доходов) в комбинации с несколькими десятками ЦФО да и еще в почти с десятке компаний в одной базе. Широковат был еще справочник ДДС.

Однако в плане счетов проводилась очень жесткая оптимизация, чтобы на счета не писались лишние аналитики. Например, на 51-х счетах разрешался только ДДС, на 60-х и 62-х ЦФО, и т.п., а на большинстве счетов все или почти все аналитики вообще безжалостно терлись (например, счет ввода начальных сальдо, счета курсовой разницы), чтобы не было лишних ненужных для анализа сальдо на счетах по комбинациям аналитик.

Но...

Автоматизирован был финансовый учет (учет расходов, дебиторка и кредиторка, та же реформация баланса, движение ДС). Логистики и складских проводок не было. Количество проводок в ГК получалось... не маленьким, но и не очень грандиозным.

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

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

Длина записи в LedgerTrans по статистике у меня сопоставима с длиной записи в таблице LedgerBalancesDimTrans. Но я предполагаю, что просто не был настроен текст проводки. Под индексы в LedgerBalancesDimTrans занято в 5 раз меньше места в пересчете на одну запись таблицы. LedgerBalancesDimTrans можно пытаться дополнительно индексировать для ускорения определенных выборок.

[glibs]

Цитата:

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

...
проблем с производительностью рассчета баланса/оборотов по ГК. Потому как используется это только для рассчета баланса и отчета о прибылях и убытках, которые раз в месяц строяться и особой производительности не требуют.
...

Это какой-то вырожденный теоретический случай.

А управленческая отчетность оперативная? Исполнение бюджета план-факт. Хоть раз в час могут хотеть смотреть для принятия управленческих решений. Прогноз ДДС. Оперативный анализ затрат. Оперативный анализ ДДС. Оперативный прогноз ДДС. Да полно управленческих отчетов.

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

[glibs]

Цитата:

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

...
проще с самого начала не заморачиваться и написать запросы по ledgerTrans. Ну проиграем 20-30 процентов в производительности запроса, да и хрен с ним по большому счету. Все-таки в Аксапте данные ГК не принято использовать ни для каких других целей кроме ограниченного круга запросов, нет смысла особо париться по поводу падения производительности на 20-30 процентов в отчетах, которые строит один человек один раз в месяц
...

Да кто придумал этого одного человека в месяц???

Сколько будет строиться финансовый (не ГФО, а международный) отчет с двадцатью колонками (желательно с данными из нескольких периодов или с разбивкой по какой-то финансовой аналитике) и несколькими сотнями строк (с детализацией по аналитикам по двум уровням, например), если его пустить по проводкам ГК?

В ГФО (разумеется после его модернизации, когда он начал отправлять на сервер БД запросы с агрегированием) такие отчеты строятся часами на базе с промышленными данными даже в пределах календарного года. В финотчетах минуты.

Обратите внимание как индексированы проводки ГК и как индексирована та же LedgerBalancesDimTrans.

Блин. Не нужно выкидывать сальдовые таблицы! Не хотите — не пользуйтесь. Флаг вам в руки. Не портите жизнь другим. А то в Микрософте любят что-то, чем уже пользуются, разрушить и построить что-то новое в стиле: "Нате вам здрасьте". Не поломать старый удобный инструмент ради нового, а просто создать еще один чтобы были опции по принципу "на вкус и цвет товарищей нет" им что-то там не позволяет. Подозреваю что "эго" очередной команды, дорвавшейся до руля. Не дай бог к вам прислушаются.

[glibs]

Кстати, насколько я заметил краем глаза в 5.0 убрали 20-кратное раздутие LedgerBalancesDimTrans. Судя по таблице LedgerBalancesTransDelta в таблице итогов без аналитик с блокировками решили бороться тем же способом, как и в InventSum в 4.0.

Кстати, про обороты по счетам ГК без аналитик. Уж точно на несколько порядков быстрее будут работать.

Да... справедливости ради стоит оговориться что тем, кто не может анализировать финансовые операции без корреспонденции счетов, таблицы агрегированных оборотов по проводкам ГК, о которых идет речь, бесполезны.

[glibs]

Цитата:

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

...
Если же ты пытаешься какие-то более детальные отчеты по ГК получить, то все равно проще проводки в OLAP загнать и там крутить.
...

Я обожаю ОЛАП-ки.

Но строить их не так просто. И нужен специалист уровня разработчика. Особенно если нужен план-факт или комбинация плана, факта и прогноза. Ну и приведение к основной валюте того же бюджета и прочие нюансы... И под разные аналитические задачи приходится строить специализированные кубики, а то у ОЛАп-ок тоже производительность имеет тенденцию запарываться драматически, если туда натолкать всю возможную аналитику (движок уже тогда не в состоянии оптимально построить промежуточные итоги).

А финотчеты может строить финансовый аналитик. Я сам видел. Справляются.

В общем, как говорит Маззи, побольше инструментов. Хороших и разных. На вкус и цвет товарищей нет. Чем больше при желании можно использовать опций — тем лучше система.

[fed]

Цитата:

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

Кстати, насколько я заметил краем глаза в 5.0 убрали 20-кратное раздутие LedgerBalancesDimTrans. Судя по таблице LedgerBalancesTransDelta в таблице итогов без аналитик с блокировками решили бороться тем же способом, как и в InventSum в 4.0.

Кстати, про обороты по счетам ГК без аналитик. Уж точно на несколько порядков быстрее будут работать.

Да... справедливости ради стоит оговориться что тем, кто не может анализировать финансовые операции без корреспонденции счетов, таблицы агрегированных оборотов по проводкам ГК, о которых идет речь, бесполезны.

Гы ! Так я о том и пишу. В версии 2009 ОДНУ запись в балансовые таблицы пишут на ОДИН ваучер! Так что эти 20 записей (если ты уж так обеспокоен размером этой таблицы) это еще немного было... Не веришь - попробуй в 2009ой найти команды ОБНОВЛЕНИЯ балансов. Я долго не верил своим глазам - но оказалось что там только ВСТАВКИ.

Кстати к товоему праведному возмущению по поводу того что это мол не только для баланса/отчета о прибылях и убытках нужно. Я в общем-то с тобой согласен. Но все равно это не остатки в наличии которые при каждой складской операции проверяются, а некая информация которая нужна ограниченому кругу лиц (2-3-4 финансиста, наверное еще 3-4-5 менеджеров), не постоянно, а время от времени. И вот получается что эти таблицы балансов пользу приносят небольшому количеству пользователей, а вред (за счет увеличения - пусть небольшого) времени разноски - почти всем пользователям (уж процентов 70 пользователей-то всяко какие-то проводки в системе создают время от времени).
Ну и к слову сказать - учитывая что число записей и размер записи в ledgerTrans и ledgerBalancesDimTrans обычно сопоставимы, выигрыш от использования именно таблицы балансов - он небольшой. Он был большим - до версии 3.0. Но это было давно и неправда

[fed]

Цитата:

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

Прошу уточнить о чем именно речь.

Я пожалуй уточню (по итогам поступивших в оффлайне вопросов): Одна запись в балансы пишется на один объект LedgerVoucher. В принципе - этот объект может включать несколько ваучеров ГК (с разными номерами и датами), но в целом в 95% случаев - один LedgerVoucher==один ваучер ГК. Но, вероятно, из за тех 5% в которых в один ledgerVoucher попадает несколько документов ГК, поле voucher не добавили в балансовые таблицы...
То есть - сначала система считает в памяти (с частичным выносом в квазивременную таблицу в БД) обороты по аналитика+счет+дата ВНУТРИ данного ledgerVoucher, потом все это переносит в одну или несколько записей внутри таблицы балансов. Но никакого суммирования или группировки ЗА ПРЕДЕЛАМИ одного ваучера - не делается...

[mazzy]

Цитата:

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

Одна запись в балансы пишется на один объект LedgerVoucher. В ...
Но никакого суммирования или группировки ЗА ПРЕДЕЛАМИ одного ваучера - не делается...

Не, Денис, ты ошибаешься.
Здесь тебе стоит пересмотреть свои взгляды.

Просто у денежных полей в таблицах LedgerBalancesTrans и LedgerBalancesDimTrans
установлено свойство FieldUpdate = Relative.
http://msdn.microsoft.com/en-us/library/aa577032.aspx

Это значит, что программисту не надо писать Update, не нужно маятся с вилкой (find?update:insert).
Программисту достаточно давать команду Insert.
Система сама сложит, если найдет уже существующую запись.
Это свойство пришло еще из Конкорда.



добавил скриншот хелпа из ax3.0, где специально объяснялось что это такое

[petr]

Не согласен с критикой нового механизма. По-моему в MS в новой версии все прекрасно сделали.

Как я понял идея такая. Во время разноски операции ГК в таблицы LedgerBalance(Dim)Trans идет только вставка (притом очень быстрая) данных заранее уже подготовленных в LedgerBalancesTransDelta. Никаких update и подобных блокировок, плюс ускоряется разноска ваучера.

Действительно на один день может получиться очень много записей в LedgerBalance(Dim)Trans (сопоставимо по кол-ву с legderTrans, даже если аналитики вообще не используются).

Но, раз в день, неделю, месяц можно запускать переодический пересчет балансов, который "просуммирует" все данные в LedgerBalance(Dim)Trans на одну запись в день.

В итоге получаем:
- таблицу сальдо LedgerBalance(Dim)Trans с одной записей на один день (как в версии 2.5 до появления поля Variant)
- при разноске журналов никаких блокировок и лишних Update-ов, только Insert

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

[mazzy]

блин, ребяты, да вы что!!!?

Цитата:

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

Как я понял идея такая. Во время разноски операции ГК в таблицы LedgerBalance(Dim)Trans идет только вставка (притом очень быстрая) данных заранее уже подготовленных в LedgerBalancesTransDelta. Никаких update и подобных блокировок, плюс ускоряется разноска ваучера.

petr, смотрите внимательно на свойство FieldUpdate у полей, которые отвечают за суммы.
там не только вставка.

Цитата:

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

Но, раз в день, неделю, месяц можно запускать переодический пересчет балансов, который "просуммирует" все данные в LedgerBalance(Dim)Trans на одну запись в день.

Не... Ни в коем случае.
Весь цимус как раз в том, что промежуточные итоги актуальны в любой момент.
(ну, только если программист не вызвал где-нибудь хакерские doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete )

[mazzy]

Цитата:

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

Но никакого суммирования или группировки ЗА ПРЕДЕЛАМИ одного ваучера - не делается...

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

И если можно, из уважения к российским читателям - опубликуй текст на русском. Ну, пожалуйста.

[petr]

Цитата:

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

блин, ребяты, да вы что!!!?


petr, смотрите внимательно на свойство FueldUpdate.
там не только вставка.

Посмотрите в таблицы LedgerBalance(Dim)Trans, там несколько записей на одну дату и (комбинацию аналитик).

Цитата:

Не... Ни в коем случае.
Весь цимус как раз в том, что промежуточные итоги актуальны в любой момент.
(ну, только если программист не вызвал где-нибудь хакерские doUpdate, doInsert, doDelete вместо нормальных Update, Insert, Delete )

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

P.S. я имею в виду опрацию из ГК-переодические операции-пересчет промежуточных сальдо (или как там она по-русски называется)

[fed]

Цитата:

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

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

И если можно, из уважения к российским читателям - опубликуй текст на русском. Ну, пожалуйста.

Насколько я помню, fieldUpdate==relative работает только в том случае если выполняется команда: UPDATE. команде INSERT на этот relative глубоко безразлично. Я НИ ОДНОГО UPDATE в системе по ledgerBalances* не нашел.
В принципе - этот relative update штука полезная, поскольку просто заменяет комманду Update Set field=value на update set field=field+value. Но не очень понятно как оно может повлиять на оператор insert в методах LedgerBalancesTransDelta.transferTempDeltaRecsTo* Есть шансы что этот relative просто незаметили и он там остался еще со времен Конкорда.

Вообще - похоже что petr прав. Авторы предполагали что балансы периодически пересчитываются и упаковываются. Вот это надо будет написать отдельной записью в блоге...