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

[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 и прочие плохо тестируемые ситуации. Например, есть прецендент, когда перезагрузка системы в процессе проведения большого журнала, и повторное перепроведение привели к удвоению части постингов за этот месяц. Часть ваучеров были продублированы, как это случилось - не известно, так как транзакция не была закончена. Мне ни разу не доводилось сталкиваться с такой ситуацией раньше. Это не единственный странный случай, который случился в процессе обработки большого массива данных, поэтому для меня было проще убрать все сомнительные моменты и все переделать.
Иногда просто невозможно все сделать замечательно и в пределах временного бюджета. Особенно если действует принцип "нецелесообразно - значит вредно". Надеюсь, это имеет смысл.