fed: Ledger Balance Data in DAX

[fed]

Цитата:

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

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

Т.е. все эти варианты хранения промежуточных результатов для ускорения расчета остатков - от бедности ?

Вообще-то используемая архитектура, в запаном учете, позволяет, для подсчета сальдо и для подсчета оборотов всегда плясать ТОЛЬКО от начала финансового года. Просто у них в конце одного финансового года все сальдо списывают на некий счет, а потом в начале следующего финансового года все эти сальдо восстанавливают с того же самого счета (а может быть и с другого). Так что в западном учете сальдо равно оборотам с начала финансового года, считать с начала времен - необязательно. Так что это как раз и есть схема "Остаток+обороты".Но все равно - размер ledgerBalances и ledgerTrans а период сопоставим не зависимо то того, как мы считаем - с начала времен или с начала финансового года.
Кстати - я слышал что и в некоторых российских внедрениях используют заключительную ведомость в конце года для списания/приходования остатков. Правда, это не очень вяжется с русскими ПБУ...
А все это до сих пор используют потому что:
1. Во первых так сложилось. Когда авторы догадались о том что с блокировками все нехорошо, вероятно уже поздно было выкинуть эти таблицы.
2. Во вторых - эта архитектура позволяет собрать и дебетовые и кредитовые обороты в одной строке. Не так чтобы это великим достижением было, но иногда приятно.
3. Архитектура позволяет сэкономить немножко на времени доступа к данным. Хотя на мой взгляд, подобная экономия уже не стоит накладняка.

[Raven Melancholic]

Цитата:

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

Кстати - я слышал что и в некоторых российских внедрениях используют заключительную ведомость в конце года для списания/приходования остатков. Правда, это не очень вяжется с русскими ПБУ...

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

[fed]

Цитата:

Сообщение от Raven Melancholic

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

А поподробнее можешь рассказать? Мне просто казалось что реформацией баланса называют процедуру закрытия в конце учетного периода сальдо на 90.09/91.09/99 на счета нераспределенной прибыли (в общем - куда-то на 8x, подзабыл я уже русский план счетов). При этом счета прибылей и убытков закрываются конечно, но во первых в обычном учетном периоде, во вторых -счета активов и пассивов так и переходят на новый учетный период. А в западном учете, как мне казалось, в конце периода закрывают все счета, а потом в новом году их с ноля открывают. То есть - фактически иммитация бумажного учетного журнала, в котором последняя запись старого финансового года закрывает все счета на так называемый счет баланса, а первая запись нового года - открывает все счета со счета баланса...

[mazzy]

Цитата:

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

Правда, это не очень вяжется с русскими ПБУ...

Цитата:

Сообщение от Raven Melancholic

Почему это не вяжется?
... несколько ПБУ... требуют корректировок "вне времени", то есть именно в заключительной ведомости.

Да... хорошо бы иметь проводки по реформации "вне времени", чтобы иметь возможность получать отчеты с учетом по реформации и без них.

И такую возможность вполне можно сделать, создавая закрывающие периоды не только в конце года, но и в конце каждого месяца.

А вот что не соответствует... Закрытие по российским правилам требует многоуровневого закрытия 26-23-20-90-88. А в буржуйских все счета прибылей и убытков сразу закрываются на 88. Поэтому заключительная ведомость не очень подходит в российских условиях. Приходится либо допиливать заключительную ведомость, либо разрешать указывать в журналах тип периода (обычный, закрывающий).

[mazzy]

Цитата:

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

Так что в западном учете сальдо равно оборотам с начала финансового года, считать с начала времен - необязательно. Так что это как раз и есть схема "Остаток+обороты".Но все равно - размер ledgerBalances и ledgerTrans а период сопоставим не зависимо то того, как мы считаем - с начала времен или с начала финансового года.

Не. Тут ты не прав.

Во-первых, в LedgerBalances хранятся начальные остатки на начало финансового года.
Следовательно вместо выборки из LedgerTrans от начала времен
они делают выборку из LedgerBalances от начала фин.года плюс выборка LedgerTrans от начала фин.периода до даты. Что существенно меньше.

Другими словами:
1. от начала времен: LedgerTrans[<DateTo]
2. с оборотами: LedgerBalances[>=StartFinYear, <StartFinPeriod] + LedgerTrans[>=StartFinPeriod, <DateTo]

пример Производительность (в табличном виде)
Обрати внимание, что LedgerTrans - самая большая таблица.
А LedgerBalances не входит даже в первую двадцатку.
И это типичная ситуация.

Кроме того, даже выборка из LedgerBalances ведется не по всему объему, а только по последнему финансовому году. Что здорово сказывается, если база содержит данные за 5-8-10-и-более лет.
Не говоря уже об уменьшении выборки LedgerTrans

это только уменьшение выборки.
а если вспомнить про возможность сегментирование данных (старые скидывать в отдельную файловую группу).
а если еще вспомнить про метод PostLoad...

[fed]

Цитата:

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

Не. Тут ты не прав.

Во-первых, в LedgerBalances хранятся начальные остатки на начало финансового года.
Следовательно вместо выборки из LedgerTrans от начала времен
они делают выборку из LedgerBalances от начала фин.года плюс выборка LedgerTrans от начала фин.периода до даты. Что существенно меньше.

Хочу заметить, что если мы заключительной ведомостью пользовались, то у нас по ledgerTrans тоже можно считать не с начала времен, а с начала финансового года. Во вторых - по моим наблюдениям, размер ledgerBalancesDimTrans (по крайней мере по числу записей) составляет где-то порядка 40-60% от размера самого ledgerTrans. Так что экономия от использования ledgerBalances достаточно небольшая. Учитывая что в ledgerBalances отсутствует некоторая информация которая бывает нужна для запросов (тот же код валюты к примеру или сумма в валюте), то проще с самого начала не заморачиваться и написать запросы по ledgerTrans. Ну проиграем 20-30 процентов в производительности запроса, да и хрен с ним по большому счету. Все-таки в Аксапте данные ГК не принято использовать ни для каких других целей кроме ограниченного круга запросов, нет смысла особо париться по поводу падения производительности на 20-30 процентов в отчетах, которые строит один человек один раз в месяц...

[mazzy]

Цитата:

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

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

не.
1.
это ж принципиальная вещь, о которой давным-давно говорится:
число комбинаций финансовых аналитик (!) должно быть относительно невелико.
иначе LedgerBalancesDim* раздувается и Аксапта начинает работать медленно.

Это значит, попытки затолкать в фин.аналитики всякие номенклатуры, контрагентов (а тем более, ГТД, партии) обречены на тормоза.

2.
В Аксапте 3.0, 4.0 есть галочка "Не учитывать коды аналитики"
которая не переносит значения LedgerBalancesDim на следующий фин.год.
LedgerBalances (сальдо по счетам) - переносится, а аналитика - не переносится.
Что сильно уменьшает размер LedgerBalancesDim


В Аксапте 2009 перенесли эту галочку в периодическую операцию "Открывающие проводки".


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


В общем, когда-то люди об этом думали. Но хотелось бы большего.

Цитата:

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

Учитывая что в ledgerBalances отсутствует некоторая информация которая бывает нужна для запросов (тот же код валюты к примеру или сумма в валюте), то проще с самого начала не заморачиваться и написать запросы по ledgerTrans.

Не так малешко. По-моему.
(Конечно можно подходить по разному к этому вопросу: пессимист скажет, что не подумали, оптимист придумает оправдание )

По-моему, тут важен баланс между скоростью и объемом.
Ведь не ставиться цель избавиться от запросов "от начала времен".
Цель по-моему найти оптимальную скорость.

Если бы я реализовывал эту фичу, то я бы подумал так:
С одной стороны:
= все операции идут в основной валюте. Поэтому запрос к LedgerTrans в основной валюте неизбежно приведет к выборке ВСЕХ ledgerTrans за период
= операций в валюте (скорее всего) будет не так много. Поэтому запрос к LedgerTrans по валюте будет достаточно селективным (выборка будет меньше, чем "все записи за период").

С другой стороны:
= чем больше размер LedgerBalances*, тем меньше смысла в этих таблицах.

Поэтому, возможно, я бы остановился на решении, что сальдо в основной валюте рассчитывается на основании LedgerBalances*, а остальные сальдо - прямыми запросами.

Цитата:

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

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

20-30? При выборке из десятков-милионнов записей?

А самое главное - при выборке "от начала времен" можно забыть о сегментировании данных в SQL. Поскольку эффект будет не сильно заметным (разве что за счет отдельной обработки индексов в разных сегментах).

[glibs]

Цитата:

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

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

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

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

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

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

Но...

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

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

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

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

[glibs]

Цитата:

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

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

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

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

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

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

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

[fed]

Цитата:

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

Другими словами:
1. от начала времен: LedgerTrans[<DateTo]
2. с оборотами: LedgerBalances[>=StartFinYear, <StartFinPeriod] + LedgerTrans[>=StartFinPeriod, <DateTo]

Это ты про алгоритм версий 2.1-2.5 рассказываешь. Там действительно обороты в разрезе периодов в таблицах балансов хранились. А с версии 3.0 - в разрезе дней храняться. Соответственно функция ledgerBalance_sumCurrent() считает просто тупо суммируя ledgerBalancesDimTrans. Никакой схемы Балансы+обороты по ledgerTrans там с 2003 года не используется.
А учитывая что размеры ledgerTrans и ledgerBalancesDimTrans сопоставимы обычно (ну то есть - конечно балансы поменьше, но поменьше раза в два, может в три), то выигрыш от использования информации балансов невелик.
После того как в DAX2009 они вообще стали балансы складывать тупым суммированием оборотов по счету+аналитика внутри ваучера (то есть - даже не по схеме 20 записей в день по счет+аналитика), то выигрышь, скорее всего, станет еще более призрачным.

[mazzy]

Цитата:

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

Это ты про алгоритм версий 2.1-2.5 рассказываешь. Там действительно обороты в разрезе периодов в таблицах балансов хранились. А с версии 3.0 - в разрезе дней храняться.

опаньки. спасибо.
значит теперь нельзя управлять размером LedgerBalances...

Цитата:

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

Соответственно функция ledgerBalance_sumCurrent() считает просто тупо суммируя ledgerBalancesDimTrans. Никакой схемы Балансы+обороты по ledgerTrans там с 2003 года не используется.

ledgerBalance_sumCurrent() - абстрактный класс.
см. LedgerBalanceSum_CurrentMST.buildQuery()

(но! см. LedgerBalanceCur_Current.buildQuery, который работает по LedgerTrans)

Цитата:

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

А учитывая что размеры ledgerTrans и ledgerBalancesDimTrans сопоставимы обычно (ну то есть - конечно балансы поменьше, но поменьше раза в два, может в три), то выигрыш от использования информации балансов невелик.

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

Да, если из Аксапты делать 1С с ее субконтами, то будут почти такие же тормоза, как и у субконто.

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

Цитата:

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

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

Я согласен с тем, что чем дальше, тем меньше остается от первоначальных замыслов. Все как-то размывается... Вводятся фичи, которые драматически ухудшают производительность. Например, Как глобально отключить автоопределение ширины столбца = autoSizeColumns(false) ?

[fed]

Цитата:

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

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

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

[glibs]

Цитата:

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

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

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

[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, где специально объяснялось что это такое

[mazzy]

Цитата:

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

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

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

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

[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 прав. Авторы предполагали что балансы периодически пересчитываются и упаковываются. Вот это надо будет написать отдельной записью в блоге...

[Bober]

Цитата:

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

Когда авторы догадались о том что с блокировками все нехорошо

Это п. Столько лет уже Аксапте. А всё одни и те же грабли. Когда в разрабокту Микрософт перестанут брать дураков ?

[fed]

Цитата:

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

Это п. Столько лет уже Аксапте. А всё одни и те же грабли. Когда в разрабокту Микрософт перестанут брать дураков ?

Справедливости сказать - схема-то еще в Дамгаарде была разработана...
Равно как и способ преодоления последствий с помощью вариантов...

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

[mazzy]

Цитата:

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

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

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

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

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

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