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

[mazzy]

Цитата:

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

Формы с 1 по 4 можно настроить в Генераторе финансовых отчётов.

Да. Но только нужно предупреждать и оговаривать следующее:

Помните, что ГФО для получения сальдо суммирует все записи LedgerTrans от начала времен. Что может привести к катаcтрофическим последствиям через полгода-год-два. Буржуйская функциональность работает от промежуточных итогов.


=============
- Но только помни, что в 12 часов твоя карета превратиться в тыкву, твой кучер в крысу, а бальное платье в лохмотья...
- А собственно что это я? Я же добрый фей!

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

Цитата:

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

Да. Но только нужно предупреждать и оговаривать следующее:

Помните, что ГФО для получения сальдо суммирует все записи LedgerTrans от начала времен. Что может привести к катаcтрофическим последствиям через полгода-год-два. Буржуйская функциональность работает от промежуточных итогов.

Неужели это ещё не починили... Давно не смотрел. Да и суммируют как. Какой там sum(), офигенный while select с проверкой условий внутри цикла Хорошо, хоть обороты в корреспонденции починили, а то мой первый вариант Формы "Движение денежных средств" на демобазе почти час считался.

[Alexx7]

Цитата:

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

...
Буржуйская функциональность работает от промежуточных итогов.
...

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

[snv]

Цитата:

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

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

а зачем вам от промежуточных итогов?
понятно когда нужны статистические данные - можно использовать.
а когда нужен отчет с пылу с жару - вам прийдется пересчитывать данные (у меня в трешке с базой 15 гиг это занимает часа три, и вешает аксапту намертво).
если хорошо пройти напильником по РФО, то получается хороший отчет, и считает все данные с начала времен достаточно шустро.

[mazzy]

Цитата:

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

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

Нет, конечно.
ВСЕ данные (как это делаетс сейчас ГФО пересчитывать не нужно).
Нужно будет пересчитать данные от промежуточных итогов до даты "с пыла с жара".
А это гораздо меньше, чем 15 гиг.

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

Цитата:

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

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

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

[Alexx7]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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