DAX 4: Поле Correct или Два минуса не равны плюсу

[Qaz Qwerty]

1. Открываем SQL и видим:
AmountCUR = -150, AmountMST = -150;
2. Открывает table browser и видим:
AmountCur = -150 , AmountMST = --150
Correct (Correcting) = Yes.
3. Формируем отчет и видим, что циферки в отчете прошли как положительные, а должны пройти как отрицательные.


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

[Qaz Qwerty]

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

[mazzy]

Цитата:

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

AmountMST = --150, Correct (Correcting) = Yes.

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

Цитата:

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

Кажется, если в дебете указать циферку с минусом, то система разносит это как сторно и помечает как correction...

да, красное сторно.

+Сумма, correct = No - это дебет
-Сумма, correct = No - это кредит
+Сумма, correct = Yes - это сторно кредита
-Сумма, correct = Yes - это сторно дебета

Цитата:

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

вот если бы можно было очистить поле программно и пересчитать остатки...

зачем очищать то?

а пересчитать в финансовых периодах. Кнопка "Пересчитать периоды"

[CDR]

Цитата:

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

Кажется, если в дебете указать циферку с минусом, то система разносит это как сторно и помечает как correction...

Для строк журнала ГК именно так система и работает: если в дебете или кредите указать сумму с минусом, то система разносит это как сторно и помечает как correction. В дебетовой проводке по строке журнала останется минус, а в кредитовой получится минус минуса.

Цитата:

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

+Сумма, correct = No - это дебет
-Сумма, correct = No - это кредит
+Сумма, correct = Yes - это сторно кредита
-Сумма, correct = Yes - это сторно дебета

Это справедливо уже непосредственно для самих проводок ГК, однако проще и надежнее все-таки смотреть поле Crediting.

[Qaz Qwerty]

Mazzy,
Проблема в том, что считается неправильно. Если распечатать отчет с транзакциями, то выводится остаток, из которого видно, что числа посчитаны как положительные, то есть как просто дебет числа. А они отрицательные. По моей логике, отрицательное число в дебете счета = кредит счета = уменьшение остатка, а у меня остаток растет.
Скажите проверить еще раз?
Попытка удалить признак "correct" и пересчитать остатки ни к чему не привела, остаток не изменился. По ходу перегружаю все журналы, чтобы теперь правильно расставить дебеты и кредиты, а это миллион операций

[Qaz Qwerty]

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

[Maxim Gorbunov]

Цитата:

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

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

Хм. Оборот по кредиту/дебиту счета никто в "упрощенном буржуинском" не отменял. Посмотрите в Period balances стандартного международного приложения

[Qaz Qwerty]

Да, все должно быть правильно. Отображается как два минуса, считается как отрицательное число.
Не знаю, почему остаток не совпадает с екселем, может и не по этой причине. Я еще поразбираюсь... Прошу прощения за путаницу.

[CDR]

Такое очучение, что вы запутались в трех соснах.

1. Журнал ГК.
Проверяем в журнале поля: счет, корр.счет, дебет, кредит.

Если сумма в дебете положительная, то а)сумма в проводке по счету должна быть больше нуля, "остаток" по счету тоже должен увеличиться; б) сумма в проводке по корсчету должна быть отрицательной, "остаток" по корсчету должен уменьшиться. Это "обычная дебетовая операция".

Если сумма в дебете отрицательная, то а) сумма в проводке по счету должна быть меньше нуля, "остаток" по счету должен уменьшиться; б) сумма в проводке по корсчету должна быть положительной (минус минуса), "остаток" по корсчету должен увеличиться. Это "сторно обычной дебетовой операции".

Если сумма в кредите положительная, то а)сумма в проводке по счету должна быть меньше нуля, "остаток" по счету должен уменьшиться; б) сумма в проводке по корсчету должна быть положительной, "остаток" по корсчету должен увеличиться. Это "обычная кредитовая операция".

Если сумма в кредите отрицательная, то а) сумма в проводке по счету должна быть положительной (минус минуса), "остаток" по счету должен увеличиться; б) сумма в проводке по корсчету должна быть отрицательной, "остаток" по корсчету должен уменьшиться. Это "сторно обычной кредитовой операции".

2. План счетов и проводки.
Идем в план счетов и проверяем проводки и сальдо. Все должно быть так, как описано высше.

3. Смотрим свой отчет, если в отчете не так, как описано высше - отчет выкидываем нафиг.

[Maxim Gorbunov]

Цитата:

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

Да, все должно быть правильно. Отображается как два минуса, считается как отрицательное число.
Не знаю, почему остаток не совпадает с екселем, может и не по этой причине. Я еще поразбираюсь... Прошу прощения за путаницу.

С Экселем проблема как раз старая. Корректирующие проводки в экселе выгружаются неправильно. Фильтруйте по значению поля Коррекция, например.

[Logger]

Цитата:

Сообщение от Maxim Gorbunov

С Экселем проблема как раз старая. Корректирующие проводки в экселе выгружаются неправильно. Фильтруйте по значению поля Коррекция, например.

Именно так !
При выгрузке через буфер обмена, в Excel попадают числа вида -- или -+ и Excel может у них знак неверно определять. А выглядит для нас как будто ошибка. Мы для обхода этого глюка отдельно свою выгрузку в Excel проводок написали.

[Logger]

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

Туда не ходи - сюда ходи, снег башка попадет - баланс хрен соберешь...

[Qaz Qwerty]

ээээ... так много всего.
1. Дебет - кредит - сторно. Я не знаю как правильно. Наш CPA утверждает, что для BS важен остаток, а для PL важен net transactions. Я предполагаю, что для тех, кто занимается выверкой, например выверкой банка или поставщиков, действительно может быть важно разделять коррекции и нестандартные обороты типа возврат денег поставщику, но на практике она разбираются с оборотами в основном на основании информации о типе и номере документа, а не как записана транзакция. На вопрос, надо ли повторить все отрицательные дебеты и отрицательные кредиты, которые импортируются из базы восточной Европы как сторно-операции, CPA сказал что его не волнует и это чисто IT вопрос и regional aspect, не имеющий отношения к подготовке к аудиту и налогам. CPA бывают разной квалификации, но я слышу это второй раз. Для статистической выборки не достаточно, но говорят что по двум точкам можно провести прямую . Попытки найти в интернете сочетание слов GAAP и storno привели только к ссылкам на вопросы по аксапте, а положение о порядке внесения коррекций утверждает "считайте хоть вверх ногами, но нас волнует cumulative effect и не вздумайте менять прошлые записи чтобы уменьшить налоги", очень практично. Так что если кто нибудь мне может быть ссылку на рекомендации GAAP по записи коррекций через сторно - было бы замечательно. Может удалось бы утереть нос CPA, но очень сомневаюсь

Сравнение с экселем. Я собственно сравниваю аксаптовский отчет с оригинальным источником данных в Екселе. Я понимаю насчет глюка вытягивания через буфер обмена, проблема не в этом была. По поводу роста-убывания сальдо, я в общем то понимаю все, но все равно, спасибо за подробное объяснение! Кому нибудь наверняка будет полезно!

[CDR]

Осталось привести пример строки из загружаемого файла и соответствующую ей созданную строку журнала ГК, и все станет на свои места.

[Qaz Qwerty]

К сожалению нет времени на эксперименты. Скажу только, что так как CPA don't care насчет сторнирования, мне помогло следующее:
- Удалить транзакции.
- Сделать журналы не проведенными.
- Записать отрицательные дебеты в кредиты (и отрицательные кредиты в дебеты).
- Провести все заново и закрыть года.
- Запустить TB.
Сейчас "остатки" выглядят хорошо.
Нельзя назвать интеллигентным решением, но проще чем периодически натыкаться на эту проблему.

[Raven Melancholic]

Цитата:

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

- Удалить транзакции.
- Сделать журналы не проведенными.

Ага, млин, соответствуем концепции путь Аксапты Что-то я не особенно понял проблему. Что сторно, что реверс, в отчетах (включая финотчетность буржуйскую и российскую все работает нормально). Единственная известная мне проблема - копирование выделенных операций ГК в Excel. Из-за этой операции выполнять кучу нерегламентированных операций??? Конечно здорово, но может быть стоит познакомиться с финансовой отчетностью и генератором финансовой отчетности (то что mazzy его не любит не значит что им не нужно пользоваться).

[Maxim Gorbunov]

Qaz Qwerty,

Послушайте, то, что Вашему CPA все равно, как Вы проведете коррекции, еще не значит, что они не нужны. Из Ваших объяснений я понял, что Вы пытаетесь консолидировать данные. В таком случае, то, что Вам хотел сказать CPA, скорее всего означает, что ему неинтересны данные с точностью до проводки. Разумным подходом, в данном случае, было бы консолидировать ежедневные балансы. Тогда и проблем с коррекциями бы не было, и соответствие между исходной и консолидированной базой было бы логически сохранено.

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

[Qaz Qwerty]

Maxim,
Странные вещи Вы говорите однако, с учетом Вашего опыта Eжедневные балансы консолидировать нельзя в случае работы со многими странами трудно, надо консолидировать на уровне проводок потому что:
1. Надо сохранять номер ваучера для того, чтобы отслеживать постинги задним числом, которые есть. Никто не идеален.
2. Потому что мапинг может меняться во времени, и коррекции будут зависеть от корренспондирующих проводок. Например, недавно пришлось выделить реализованный FX с unbilled revenue.

3. Потому что в системе выполняется FX переоценка, которая базируется на историческом рейте для некоторых счетов, то есть на рейте транзакции, который отличается от общего списка рейтов в системе, например для англии это королевский курс, а для России - курс ЦБ на дату проведения платежа, а для Китая...

4. Потому что нужно сохранять текст проводки, для того, чтобы показывать в отчете, так как локальный учет отличается от GAAP. Например, есть FA которые tax-deductible, и не вычитаются, а в восточно-европейском учете все валится в кучу, и тогда корпоративный контролер разгребает эту кучу по каждой проводке.

5. Потому что надо очищать локальный FX со счетов обязательств и денежных счетов, но оставлять FX возникающий в процессе покупки - продажи валют, что не всегда выделено на отдельном счете, и тоже является частью платежа.

... и другие причины тоже, много, в предположении что локальный учет не идеальный и не все можно сделать на уровне плана счетов.

это было раз.
во-вторых, по поводу CPA, которому все равно. Им не все равно. Потому что они вытягивают данные из системы удобными им способами, и к двум минусам относятся плохо, а еще хуже относятся к исчезновению знака вообще, как в случае с HTML. Удобными им способами является сохранение отчета в HTML с форматированием и копирование проводок через буфер обмена. CPA может спросить N раз почему это возникло и кому это нужно (мне?!?), и приговор будет "I am not comfortable with the data/process" Как можно объяснить финансовому контролеру, что данные выведенные в отчете с галочкой "включить реверсированные проводки" отличаются от этого же отчета без этой галочки и оба отчета правильные, потому что пользователь реверсировал на конец года, то есть в другом месяце?

По поводу использования нерегламентированных операций - пришлось перегрузить данные, потому что это было быстрее, чем разобраться почему отчет TB в аксапте показывает данные, отличающиеся от отчета, построенного в системе с оригинальными данными, не смотря на то, что транзакции совпали. С учетом того что это миллион проводок, работа с SQL с разными выравниваниями, загрузка из SQL и прочие плохо тестируемые ситуации. Например, есть прецендент, когда перезагрузка системы в процессе проведения большого журнала, и повторное перепроведение привели к удвоению части постингов за этот месяц. Часть ваучеров были продублированы, как это случилось - не известно, так как транзакция не была закончена. Мне ни разу не доводилось сталкиваться с такой ситуацией раньше. Это не единственный странный случай, который случился в процессе обработки большого массива данных, поэтому для меня было проще убрать все сомнительные моменты и все переделать.
Иногда просто невозможно все сделать замечательно и в пределах временного бюджета. Особенно если действует принцип "нецелесообразно - значит вредно". Надеюсь, это имеет смысл.

[Maxim Gorbunov]

Очевидно, моего опыта недостаточно, чтобы прочитать ваши мысли и узнать постановку задачи до того, как вы о ней расскажете. Тем не менее, заметьте, что дневные балансы можно консолидировать и с разбивкой по валютам и курсам. Хотя, всё равно неясно, почему все те вещи, которые вы перечислили, необходимо делать именно в консолидированной компании, а не в консолидируемых или непосредственно во время консолидации. Впрочем, мне это неинтересно, так что не воспринимайте это как вопрос.

По поводу того, что ваши пользователи не comfortable с системой и процессом, так может им действительно стоит пользоваться чем-то другим в таком случае. В конце концов, клиент DAX не единственный способ достать данные из системы. Есть SSRS отчеты, которые можно легко экспортировать в Excel. Можно настроить View, к которому пользователи будут подключаться из Excel. В конце концов, можно сделать свою процедуры выгрузки в Excel, как предложил Logger. Ну и совсем уж, наконец: вам несколько раз сказали, что этот эффект есть не более, чем ошибка отображения. Вместо того, чтобы с ней разобраться, вы решили изменить данные, хотя проблему эту можно легко решить исправлением всего лишь одного свойства одного поля в форме, которая отображает бухгалтерские проводки.

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

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

На этом, пожалуй, распрощаюсь. Удачи вам в ваших начинаниях.

[Qaz Qwerty]

Ок, отлично.
Вы предлагаете:
1. Разобраться с ошибкой отображения, то есть лезть в код.
2. Отказаться от деталей и погрузится в вычисление группировок по дням, валютам, счетам, аналитикам, и курсам, а так же отдельным корреспондирующим проводкам, потеряв возможность анализировать постинги задним числом и деталей транзакций.
3. Использовать вместо Аксапты другой инструмент для консолидации, в том числе построить view к которому пользователи будут подключатся из ексель, на объеме больше чем 5млн транзакций и порядка 400тыс строк балансов по аналитикам - валютам - периодам.
4. Объяснить, что нельзя пользоваться буфером обмена и сохранением в HTML. Разработать специальную выгрузку отчетов.
И сделать все это, для того, чтобы сохранить особенность проводок, которая не важна в международном учете. Великолепно! Конечно, целесообразность такая штука которую всегда можно оспорить в России, где она выражается в эмоциях, но не в буржуазии, где она выражается в валюте.
Если Вы даете такие рекомендации, то удачи Вам в Ваших начинаниях, и спасибо за советы, которые технически абсолютно корректны.