DAX 4: Сальдо по периодам и реверсированные проводки

[Qaz Qwerty]

Здравствуйте все,
Вот такая странная проблема: Сальдо по периодам (кнопка на Плане Счетов) соответствует отчету "Выписка по счету" с опцией "Включить сторнированные".
Но ведь по логике, что сторнировано - то сторнировано и по умолчанию в стандартные отчеты для пользователя входить не должно. А сейчас пользователь смотрит на "Сальдо по периодам", которое почему то включает в себя сторнированные проводки и пытается сообразить, какие данные верны... Пересчет сальдо по периодам почему то эту проблему не решил.

Подскажите как с этим бороться, пожалуйста.
Спасибо!

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

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

Это почему же?
Давайте разбираться с терминологией

Пусть у нас есть новый счет, на котором нет никаких операций.
Создадим по этому счету какие-нибудь движения (корр.счет нас не волнует, корр.счет может быть любым)
1. 01.01.09, Счет, Дт 100, Руб
2. 05.01.09, Счет, Дт 50, Руб
3. 10.01.09, Счет, Дт -50, Руб, Сторно

Сальдо по этому счету на конец 10.01.09 будет 100 рублей (с учетом сторно).
С какой это стати в стандартные отчеты входить не должно?

[Qaz Qwerty]

Mazzy,
Я имею ввиду проводки реверсированные с помощью кнопки "Сторнировать операцию" на форме операций, вызываемой из плана счетов. Сторно-проводка будет тем же числом, с тем же курсом, с теми же аналитиками, что и оригинальная проводка. По умолчанию проводка, которая была сторнирована таким способом, в отчетах выводится не будет.
Так вот у меея сейчас такая ситуация:
+ 100 руб.
- 50 руб, создана и сторнирована вышеописанным способом.

Остаток по отчету: 100 руб без чекбокса "Включить сторнированные" и 50 руб с чекбоксом "Включить сторнированные".
Остаток по запросу "Сальдо по периодам" - 50 руб.
Какой то хлам? Или великий замысел?

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

...реверсированные ...Сторно....

Не, не, не... Вы здорово путаете два термина - реверс и сторно.
Аксапта поддерживает оба. Причем еще нелокализованная.
Аксапта может и реверсировать, и сторнировать (красное сторно).

Реверс - это обратный оборот: был дебет, стал кредит.
Сторно - это минус тот же оборот: был дебет, стал минус дебет.

Обратите внимание на мою запись Дт -50!!!!

Разница хорошо видна, если вы введете в журнал минус дебет и кредит. И разнесете этот журнал. Показываю скриншот с международной Аксапты 2009 (впрочем функционал сторнирования работал и раньше)

В нижней части - исходный журнал, введенный пользователем.
В верхней части - проводки ГК, созданные на основании журнала.



1. Сторно проводка. Обратите внимание, что "минус дебет" преобразуется в проводки главной книги с признаком Коррекция. Этот признак и определяет, что это не кредит, а "минус дебет".

Обратите также внимание на глюк, который идет во всех версиях на моей памяти... Я помню его еще в 2.1

2. Реверс проводка. Дебет с кредитом поменялись местами (или счет с корр.счетом, если думать в терминах русской бухгалтерии)

3. Новый для аксапты функционал, который появился в ax2009. Я создал обычную кредитовую проводку и указал галку, что ее надо реверсировать в указанную дату (обратите внимание на неправильный английский термин - название колонки должно быть Реверс, а не Сторно)

А. Во время разноски Аксапта (А)втоматически создала строку в журнале и разнесла ее как реверс.

=================
Теперь посмотрим в стандартный функционал, который получает Сальдо.
Аксапта может получить:
= сводное сальдо (дебет минус кредит)
= сводный оборот (дебет минус кредит)
= отдельно дебетовый оборот (дебет минус сторно дебета)
= отдельно кредитовый оборот (кредит минус сторно кредита)

Вот например, как настраивается обычная Оборотно сальдовая ведомость (как в 1С) в стандартных финансовых отчетах



==================
Теперь о Сальдо по периодам.
Опять же "дебильный" английский термин "Period balances". Дело в том, что это "сводный оборот за период".
Просто термин "balance" означает у этих англосаксов много чего... А словосочетания "Period balances" надо трактовать как идиому, означающую "оборот"
(Мы так и не смогли доказать переводчикам, плюнули, оставили так )

Так вот, "сальдо по периодам" означает сводный оборот (все дебеты минус все кредиты).

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

Поэтому для проклято-буржуинского учета особой смысловой разницы между сторно и реверсом нет. Это просто различные способы (достаточно извращенные) записи одного и того же.

Так вот. Чтобы распознать разницу между сторно и реверсом:
1. обращайте внимание на галочку "Коррекция"
2. создайте нормальную (для российского бухгалтера) оборотно сальдовую ведомость в нормальных международных финансовых отчетах (задача на 2 минуты) и юзайте эту форму (не используйте извращенный российский генератор финансовых отчетов - это задача на полчаса-час)

=========
После этого переформулируйте ваш вопрос, полностью осознавая разницу между сторно и реверсом. Если честно, то из-за путаницы терминов, я не очень понимаю какой результаты вы ожидаете.

Черт, получилось сумбурно.
По-моему, я уже объяснял на форуме подобное уже пару раз. Поищите.
Надо статью написать.

Добавил: если вы укажете версию, то я приведу скриншоты для указанной вами версии. Сейчас скриншоты из международной ax2009

[mazzy]

Цитата:

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

Добавил: если вы укажете версию, то я приведу скриншоты для указанной вами версии. Сейчас скриншоты из международной ax2009

Черт, я тормоз. Версия указана в названии темы. Извините.
Ок. Скриншоты:

(О-о-о! Как же медленно работает 4ка по сравнению с ax2009... пипец)

ручной ввод в нижней части скриншотв, созданные проводки ГК на основании в верхней части скриншота.
функционал для реверсирования accruals, который появился в ax2009, отсутствует

те же самые проводки ГК, но приближенные к международной версии


настройка ОСВ

[Qaz Qwerty]

Mazzy, Во-первых конечно спасибо огромное за объяснения.

Я с русской версией не дружу, по принципу "Не знал и забыл" Чтобы написать на русском языке, я переключаюсь в русский интерфейс аксапты, обнаруживаю всякие слова типа "реверсировать" и "сторнировать", ну и употребляю их, так сказать, по месту обнаружения. "Поэтому для проклято-буржуинского учета особой смысловой разницы между сторно и реверсом нет. Это просто различные способы (достаточно извращенные) записи одного и того же." Это чистая правда. В нашей буржуазии этой проблемы нет, реверсируй-сторнируй как хочешь, хочешь минусом (чтобы видно было, что это коррекция, по "необычной транзакции" на счете), хочешь переворачиванием. Ну да ладно.

Теперь пытаюсь переформулировать.

Баланс на счете на конец июня 2009: -373422,46 . Это правильный баланс. Он совпадает с тем, что в буржуйской аксапте называется Period Balances.

Запускаем отчет Account Statement без чекбокса Include Reversed. Получаем неправильный результат: 133867,88 С чекбоксом получаем правильный результат: -373422,46

Так что же происходит?
А произошло то, что пользователи реверсировали проводки на другую дату (в данном случае на дату после отчета).
Видим реверсированные транзакции, например:
Date Year closed Period code Currency Amount currency Amount Amount secondary currency Reversed
2/28/2009 No Normal USD 70500 70500 0 TRUE
5/31/2009 No Normal USD 97534.56 97534.56 0 TRUE
9/15/2009 No Normal USD -70500 -70500 0 TRUE
9/30/2009 No Normal USD -97534.56 -97534.6 0 TRUE

Видно чудестничество – транзации запощены в феврале, например, а реверсированы в сентябре, и так далее. Видимо пользователь 15 сентрября решил пересмотреть транзакции и реверсировал их пачками, используя кнопку «Reverse» на форме транзакций. Благо период открыт.

Дальше пытаемся разобраться, где же беда в отчете, как получилось 133867,88 вместо 373422,46.

Date Amount Reversed
12/31/2006 -6465.45 FALSE
1/31/2007 -17156.1 FALSE
1/31/2009 122698.4 FALSE
Удаленные строки...
1/31/2009 15437.68 FALSE
2/28/2009 70500 TRUE
2/28/2009 174163.6 FALSE
2/28/2009 30158.79 FALSE
3/31/2009 -474117 TRUE
4/30/2009 -425124 TRUE
5/31/2009 97534.56 TRUE
5/31/2009 7428.47 TRUE
6/30/2009 216259.6 TRUE
6/30/2009 227.77 TRUE
Total -373422
Reversed -507290
Total - Reversed 133867.9

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

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

Я с русской версией не дружу

Завидую.
Извините за употребление слова "проклято-буржуинский"

Цитата:

Сообщение от Qaz Qwerty

Запускаем отчет Account Statement без чекбокса Include Reversed.

Запускаете кнопочкой из плана счетов?
Этот?


Щас глянем.

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

Так что же происходит?

"Тут все элементарно", начал было я свой текст... И углубился на час исследований.

Прежде всего:
В ax4.0 ввели новый функционал - реверсирование.
В ax3.0 этого функционала не было. Вот как выглядела форма этого отчета в ax3.0


Что делает галка Include Reversed:
1. показывает колонку Trace Number
2. Изменяет запрос "хитрым образом", чтобы "спрятать" отреверсированные проводки из отчета (см. ниже)


Как изменяется запрос:
Если вы делаете как обычно, то у вас отчет делается со Specification = Posting, а Posting Layer = Current.
В этом случае за изменение запроса отвечает метод LedgerBalanceSheetDimCol_Cur.q_addNoReversed()

public void q_addNoReversed(QueryBuildDataSource _qbds)
{
    QueryBuildDataSource qbds;
    ;

    qbds = _qbds.addDataSource(tablenum(TransactionReversalTrans));
    qbds.joinMode(JoinMode::NoExistsJoin);
    qbds.addLink(fieldnum(LedgerTrans,TableId), fieldnum(TransactionReversalTrans,RefTableId));
    qbds.addLink(fieldnum(LedgerTrans,RecId), fieldnum(TransactionReversalTrans,RefRecId));
    qbds.addRange(fieldnum(TransactionReversalTrans,Reversed)).value(enum2str(NoYes::Yes));
}

Обратите внимание, что этот метод вызывается только в том случае, если галка СНЯТА. Если галка установлена, то метод НЕ вызывается, и запрос НЕ меняется.

Вот пример тестового отчета без галки (отреверсированные проводки НЕ показывать, спрятать):

И пример тестового отчета с галкой (отреверсированные проводки показывать):


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

(Опять хочется пнуть локализацию: вместо #$%^& доделок лучше бы исправили этот функционал, чтобы делалось сторно, а не реверс и исправили бы метку. Ладно.)

Это пока было все просто... минут на 5-10 разбора с Аксаптой.
Теперь начались сложности. Я попытался промоделировать ситуацию, чтобы воспроизвести поведение в вашей базе. И не получилось.

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

Остается две возможности:
1. у вас не последний сервис-пак. У меня установлен AX4.0 SP2
2. у вас нарушена целостность данных в таблицах LedgerTrans и TransactionReversalTrans (какой-то программист своими шаловливыми ручками удалял или правил проводки в LedgerTrans, например, а про TransactionReversalTrans - забыл)



Что посоветую:
1. Поднимите на последний сервис пак хотя бы семейство классов LedgerBalanceSheetDim. По крайней мере класс LedgerBalanceSheetDimCol_Cur
Если не поможет, то
2. Попробуйте создать копию базы/компании. В копии создайте пару НОВЫХ счетов и промоделируйте ситуацию с "реверсированием" на не ту дату. Скорее всего на новых тестовых проводках все будет правильно (будет соответствовать ожиданиям)
Если на тестовых данных будут ошибки, то возвращайтесь к пункту 1 и ищите изменения в семестве классов.
Если все будет правильно на тестовых проводках, то
3. Нужно будет разбираться с целостностью данных. Тут тема большая. Не видя данных приходит слишком много вариантов что может быть неправильно. Скорее всего, часть проводок в LedgerTrans таки была у вас удалена программистами (или хитрыми доработками ваших программистов).

[Qaz Qwerty]

Mazzy,
Версия ядра 2.0.2501.116. Согласно вот этой ссылке: http://www.axaptapedia.com/Build_numbers с сервис паком у нас все в порядке, второй. Хот фиксов на эту тему не было вроде бы, по крайней мере среди финансовых серий. И с целостностью проводок все тоже в порядке.

И моделируется ситуация довольно просто.
Сделайте оригинальные постинги в начале года, а реверсируйте на конец года (тем самым хитрым реверсированием). Сформируйте отчет (Вы правильно поняли про какой отчет идет речь) на середину года с галкой и без галки. Почувствуйте разницу. Получилось?

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

[Qaz Qwerty]

Вот примерчик:
1 янв 2009 +100 (реверсированная)
2 янв 2009 +50
1 окт 2009 -100 (реверсирующая)
=========================
Баланс на 1 июн 2009 согласно "Period balances" - +150; согласно здравому смыслу так как реверсирование прошло позднее +150; согласно отчету без галочки +100, отчету с галочкой +150.

[mazzy]

Теперь наконец-то понял чего вы хотите.

Ха! Точно. Бага - отчет за прошедший период изменяется.
Огромное спасибо.

В ax2009 такое же поведение.

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

[Qaz Qwerty]

На самом деле сальдо по периодам врет. Потому что то, что реверсировано (даже позднее текущей даты), это реверсировано, в отчеты для пользователя входить не должно. И конечно они должны быть связаны, реверсированная и реверсирующая проводка. А сейчас мне приходится рекомендовать бухгалтерам пользоваться неправильными данными сальдо по периодам и формировать отчет с галочкой. Если они раскусят этот фокус, то опять обвинят что "я не бухгалтер" и заставят переписывать запросы, а не хочется.

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

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

Это с какой это стати?

Будем использовать ваш же пример:
Вот примерчик:
1 янв 2009 +100 (реверсированная)
2 янв 2009 +50
31 янв: печатаем отчет за январь. Получаем сальдо 150.
После отчета, где-то осенью, создаем реверсирующую проводку
1 окт 2009 -100 (реверсирующая)
31 окт: печатаем отчет за январь. Получаем сальдо 100.

Вопрос: с какой стати изменилось сальдо в старом периоде? Мы же не вносили туда никаких новых данных. Мы изменили данные в октябре.

Поэтому сальдо по периодам как раз показывает правильно: что бы мы ни делали после января, в самом январе было, есть и будет 150.

[Qaz Qwerty]

Mazzy, у меня есть объяснение, но это в общем-то на любителя. Я считаю, что раз это не журнальное исправление и по умолчанию не печатается в отчетах, то обе проводки должны испарится и выводится только для информационных целей, не влияя на баланс.

[Qaz Qwerty]

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

[mazzy]

Цитата:

Сообщение от Qaz Qwerty

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

В ax2009 появилось и журнальное исправление.
Просто недоработали. Бывает.

Нужно было прятать только реверс/реверсированное в том же дне. Это оправдано. Но прятать в разных днях нельзя - отчеты "едут". По-моему.

Цитата:

Сообщение от Qaz Qwerty

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

Может быть.

Цитата:

Сообщение от Qaz Qwerty

Баланс прыгать не должен все равно.

Согласен. Но для того, чтобы это обеспечить - нельзя скрывать ревер/реверсированное на разные даты. Можно скрывать только те, что сделаны в одну дату.