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

[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 с сервис паком у нас все в порядке, второй. Хот фиксов на эту тему не было вроде бы, по крайней мере среди финансовых серий. И с целостностью проводок все тоже в порядке.

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

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