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

[Alexx7]

Добрый день.

Существует ли в аксапте бухгалтерская отчетность (регламентированная)? Я имею ввиду бух. баланс, прибыли и убытки форма 2 и т.д. Искал не нашел. Может быть есть отдельное решение для формирования этой отчетности?

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

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

[snv]

Как правильно сказал Михаил, нужно копать в сторону РФО.
Только там куча ограничений, например отсутствие запроса на разные таблицы, актуально для баланса; трудно построить за период; сальдо по клиентам поставщикам с привязкой к профилю. И выводится сразу в ексель - что лишает возможности дрилл-дауна (орфография моя).
Если есть деньги, я бы вам посоветовал сразу посмотреть на продукты которые позволяют выгружать данные во внешнее приложение и там строить как нужно. Продукты называть не буду, сочнут за рекламу еще. Просто посмотрите в том же гугле про OLAP.

[Alexx7]

Спрошу ещё немного не по теме.
По совету товарищей, решил поработать с ГФО. Вопрос:
Мне нужно получить остаток на конец периода по по счету 50 с корр. счетом 70 (например). Создаю строку в настройках с типом строки "Операция" и выбираю тип операции "Сальдо кредит". Указываю диапазон счетов 50 и там же диапазон корр. счетов 70. При проверке дает сальдо по 50 счету вне зависимости от выбранной корреспонденции. Вычитал, что фильтрация по корр счету включается только при выборе типа операции "оборот в корреспонденции", а мне надо сальдо.
Можно как то обойти этот нюанс без кровопролития?

Спасибо.

[TasmanianDevil]

Цитата:

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

Можно как то обойти этот нюанс без кровопролития?

Какой логический смысл в таком делении сальдо ?
По аналитике - оно понятно, но по корр.счету

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

Цитата:

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

Мне нужно получить остаток на конец периода по по счету 50 с корр. счетом 70 (например). Создаю строку в настройках с типом строки "Операция" и выбираю тип операции "Сальдо кредит". Указываю диапазон счетов 50 и там же диапазон корр. счетов 70. При проверке дает сальдо по 50 счету вне зависимости от выбранной корреспонденции. Вычитал, что фильтрация по корр счету включается только при выборе типа операции "оборот в корреспонденции", а мне надо сальдо.

Нужно перестраивать план счетов и разноску, прорабатывать аналитики, чтобы решить задачу другими средствами, например, финотчётами международными. Иначе скорость отчётов будет ниже плинтуса, примерно как у ОСВ.

[mazzy]

Цитата:

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

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

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

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


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

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

Цитата:

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

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

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

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

[mazzy]

нет. и не планируют. и даже не понимают сути проблемы.

===========
А собственно, что это я? Я же добрый фей.

[Alexx7]

Цитата:

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

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

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

[snv]

Цитата:

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

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

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

[snv]

Цитата:

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

Какой логический смысл в таком делении сальдо ?
По аналитике - оно понятно, но по корр.счету

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

[BOAL]

Баланс по пустой комапнии токо за счет запросов в ГФО может строится 20мин - будни юзания.
То есть, оно все работает и для раз в мес отчетности можно и ночами строить, адля быстро посмотреть ГФО не годится.

Есть вариант, поняв, че вы хотите и настроив это в ГФО, повторить эту настройку в ОЛАП кубике и иметь быстрый срез на вчера. Кубик можно и в самой АХ смотреть.

Ну или свои писать отчеты (тут уже от фантазии все зависит).
Т.к. второе ограничение ГФО - это статика его настроек.
Добавишь что в аналитики и план счетов - и перенастраивай, но это как раз нормально, т.к. ГФО по устоявшимся п-с и аналитикам должен работать.

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

[Alexx7]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

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

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

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

[TasmanianDevil]

Цитата:

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

Оборот в корреспонденции и не поверите Оборот в корреспонденции дебет\кредит.

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

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

Цитата:

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

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

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