Бухгалтерская отчетность а AX 4.0 и выше

[Alexx7]

Цитата:

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

Давно не смотрел этот код, но, на мой взгляд, если речь только об остатках типа "Счёт-аналитика" - кодирования немного. А вот для сальдо типа "Дебет счёта - Кредит счёта - Аналитики", который очень нравится нашим бухгалтерам (не потому что без него нельзя, а потому что с ним привычнее) объём кодирования будет сравним с переписыванием всего функционала разноски

А какая разница? Пишем в таблицу прмежуточных итогов полюбому при разноске. При разноске же и имеем все данные о счетах дебета кредита и аналитике. Я переживаю только за объем базы и за возможные торможения при разноске.

[mazzy]

Цитата:

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

А какая разница? Пишем в таблицу прмежуточных итогов полюбому при разноске. При разноске же и имеем все данные о счетах дебета кредита и аналитике.

Это уже делается.
См. таблицы: LedgerBalancesDimTrans, LedgerBalancesTrans

Цитата:

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

Я переживаю только за объем базы и за возможные торможения при разноске.

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

НО:
1. в этих таблицах промежуточных итогов нет корреспонденции (ну, не локализовали, блин)
2. стандартные классы, которые занимаются оптимальной выборкой сальдо/оборотов не знают о корреспонденции (опять же, не локализовали)
3. ГФО ничего не знают о стандартных оптимальных классах, а тупо делают запросы к базе данных по LedgerTrans от начала времен.

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

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

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

Цитата:

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

3. ГФО ничего не знают о стандартных оптимальных классах, а тупо делают запросы к базе данных по LedgerTrans от начала времен.

Да какие запросы - таблица LedgerTrans, связанная сама с собой Ну, кто-то додумался "сэкономить" и не продублировал хотя бы поле "Кор.счёт" в LedgerTrans. Куча запросов по корреспонденции сразу бы заработали на порядки быстрее. А если добавить "Кор.аналитику" (полей по числу аналитик добавится), все обороты по корреспонденции и остатки считались бы быстрее. Ан нет, авторы "теорию баз данных", видимо, читали, а то, что эта "теория" разрабатывалась для минимизации объёма хранимой информации и отсутствии дублирования, когда единицей хранения одного бита было ферритовое колечко с обмоткой, забывают. А для получения отчётов такая структура, ну, никак не оптимальна. В итоге, имеем на 4 поля меньше таблицу и кучу работы по оптимизации отчётов, работающих по ней.

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

Цитата:

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

А какая разница? Пишем в таблицу прмежуточных итогов полюбому при разноске. При разноске же и имеем все данные о счетах дебета кредита и аналитике. Я переживаю только за объем базы и за возможные торможения при разноске.

Разница, увы, большая (навскидку):
1. Создать таблицу для хранения промежуточных итогов.
2. При КАЖДОЙ разноске эту таблицу обновлять (например, завязав на корреспонденцию).
3. Сделать процедуру пересчёта и сделать по-уму, чтобы не днями считалась, а хотя бы часами.

И, последнее:
4. Добавить использование таблицы в ГФО.

Если задача - просто добавить использование сальдо типа "Счёт-Аналитика", первые 3 пункта вообще не нужны.