Очень давно хотел написать статью о переоценке валютных позиций в SAP. В системе S/4 и в ERP это нормально не работало и, на мой взгляд, работать нормально никогда не будет.
Стали появляться статьи о том, что все отлично, есть решение, нужно только настроить. Как показывает мой опыт, авторы статей “есть решение!” просто не понимают того, как это должно работать.
Рассмотрим, какие есть варианты настройки, что из них можно использовать, какие у вас проблемы будут при использоваии всех этих вариантов.
В SAP допустима оценка для 3 типов счетов:
Для понимания ситуации процесс оценки лучше рассматривать на примерах. Счет 60 в вашей системе скорее всего будет контрольным (за исключением технических счетов поправки, если мы говорим про обычную проводку), который обычно ведется в индексе открытых позиций.
| Дебет | 20.01 [В SAP будет 30,31 - 35] | 100 000 ₽ |
| Кредит | 60.01 [Кто нам должен] | 100 000 ₽ |
Начнем с обычной переоценки, потом перейдем к логике дельты и, может быть, к трансляции (толку от которой не будет, как ни настраивай). Обычная переоценка в SAP, во-первых, не поддерживает реклассификацию, во-вторых, реализованная разница проводится свернуто, и развернуть ее не получится.
В SAP обычно говорят о двух видах разниц:
Пример оценочной разницы
| Дебет | 91.02 [расходы от курсовых разниц] | 0 USD | 100 000 ₽ |
| Кредит | 52.99 [валютный счет в банке] | 0 USD | 100 000 ₽ |
Пример реализованной разницы, возникает от выравнивания (или при проводке платежа с выравниванием)
| Дебет | 91.02 [расходы от курсовых разниц] | 0 USD | 800 ₽ |
| Дебет | 60.01 [счет расчетов, курс 71, 72] | 200 USD | 14 200 ₽ |
| Кредит | 52.01 [валютный счет, курс 75] | 200 USD | 15 000 ₽ |
Откуда такой рублевый эквивалент, спросите вы? В примере пост. оплата по курсу 75 руб двух начислений на 100 USD по курсу 72 руб и 100 USD по курсу 70 руб, разница будет свернута при отражении в главной книге.
А теперь следующий вопрос, если мне нужен отчет, который бы показывал реализованные курсовые разницы в разрезе начислений. К примеру, чтобы на контрагента выставить. Правильно, пишите такой отчет сами, как хотите, SAP о вас заботится. Сумму разницы придется делить по таблице bse_clr, при этом разбирая частичные выравнивания, если был аванс.
Дальше будут примеры с расчетом для разных вариантов настройки переоценки.
Обычная оценка без активации логики дельты сторнируется первым числом следующего месяца. В том числе, это верно и для переоценки в конце года. При этом нужно понимать, что сторно выполняется по тем же счетам учета, по которым возникла разница.
Рассмотрим пример. У нас на 01.04.2020 была задолженность (100 USD покурсу 70). Задолженность не платилась 30.04.2020 и 31.05.2020. На 30.04.2020 у нас был курс 68 рублей за доллар, 31.05.2020 у нас был курс 75 рублей за доллар.
Какую переоценку мы привыкли видеть? На 30.04.2020 будет
| Дебет | 60.01 [счет расчетов курс 68] | 0 USD | 200 ₽ |
| Кредит | 91.01 [Курсовые разницы, оценка] | 0 USD | 200 ₽ |
На 31.05.2020 мы хотели бы видеть
| Дебет | 91.02 [Курсовые разницы, оценка] | 0 USD | 700 ₽ |
| Кредит | 60.01 [счет расчетов курс 75] | 0 USD | 700 ₽ |
Вроде логично с учетом пункта 12 и пункта 13 ПБУ 3. Разница отражена в периоде возникновения в составе прочих доходов/расходов. Как и ожидалось, предлагаемое решение по ПБУ 3) понимает логику переоценки как им удобно. Ведь если сторнировать начисление разницы это тоже будут прочие доходы/расходы? Соответственно без активации логики дельты в стандартной программе переоценки увидим следующее
На 30.04.2020 будет
| Дебет | 60.01 [счет расчетов курс 68] | 0 USD | 200 ₽ |
| Кредит | 91.01 [Курсовые разницы, оценка] | 0 USD | 200 ₽ |
На 01.05.2020 будет сторно
| -Дебет (минус) | 60.01 [счет расчетов курс 68] | 0 USD | 200 ₽ |
| -Кредит (минус) | 91.01 [Курсовые разницы, оценка] | 0 USD | 200 ₽ |
На 31.05.2020 сумма оценки рассчитается не от предыдущей оценки а от рублевого эквивалента на момент возникновения задолженности
| -Дебет (минус) | 91.02 [счет расчетов курс 68] | 0 USD | 500 ₽ |
| -Кредит (минус) | 60.01 [Курсовые разницы, оценка] | 0 USD | 500 ₽ |
Итого за 05.2020 у нас, по мнению P, будет правильный фин результат (700). Ну а что такого, что -Кт на 91.01 на самом деле Дт91.02.
Для классической переоценки без логики дельты я не буду приводить пример с частичной оплатой, пример будет для логики дельты. Тем более, что логика остается та же самая, при возникновении реализованной разницы сап ее показывает не от предыдущей оценки а от даты возникновения разницы.
Как понять что у вас активирована дельта-логика? В настройке курсовых разниц в транзакции OBA1 для плана счетов и области (это важно чтобы указывали область, где активирована дельта-логика) по операции KDF у вас появится дополнительная настройка.
Подзаголовок у экрана в моей локализации называется “Только оценка иностр. валюты с пом. дельта-логики”. Поля ракурса V_T030HB-LSREA и V_T030HB-LHREA. В этих полях должны быть указаны счета прочих доходов/расходов для реализованной курсвовй разницы. Это должны быть те же счета, что вы указали для выравниваемого счета в транзакции OB09 “Выбор счета для проводки курсовых разниц”.
Блок с трансляцией можно пока не заполнять.
При запуске логики дельты есть 2 опции которые переведены криво. Обязательно нужно выбрать одну из них “Оценка при закрытии года” или “Оценка за период меньше года”. Не очень знаю сценарии при которых бы использовался индикатор “Оценка за период меньше года”, обычно используется “Оценка при закрытии года”. Описание SAP зачем эти индикаторы доступно в ошибке FR654. “Оценка за период меньше года” посчитает вам дельту, но при этом будет пытаться ее сторнировать первым числом следующего месяца.
Соответственно если используют дельту то обычно с включенной “Оценка при закрытии года”, запускается каждый месяц, правильно чтобы никто не догадался. При этом в логике дельты у вас повятся новые колонки “Старая разница”, “Новая разница”. Как раз они и показывают сумму предыдущей оценки по документу.
Итак, если у нас активирована логика дельты и не было оплат у течении 04 и 05 периода из предыдущего периода.
На 30.04.2020 будет без изменений, так как предыдущая оценка будет 0.
| Дебет | 60.01 [счет поправки курс 68] | 0 USD | 200 ₽ |
| Кредит | 91.01 [Курсовые разницы, оценка] | 0 USD | 200 ₽ |
На 31.05.2020 при курсе 75 рублей за доллар будем видеть проводку дельты. Предыдущая оценка у нас отразила положительную разницу на 200. На момент возникновения курс был 70, при предыдущей оценки курс был 68. Итого (75-68) * 100 получаем 700 одной проводкой.
| Дебет | 91.02 [Курсовые разницы, оценка] | 0 USD | 700 ₽ |
| Кредит | 60.01 [счет поправки курс 75] | 0 USD | 700 ₽ |
И тут мы думаем, что все получилось. Нет, не получилось. Давайте посмотрим как будет работать с 50% оплатой в течении 05 месяца. К примеру 05.05 была пост оплата на 50% по курсу 77 рублей за доллар.
При проводке платежа мы получем реализованную разницу что логично, так как у нас пост оплата 50 * (70-77) = 350. Это как раз и будет реализованная разница. Но посчитает сап ее не от предыдущей оценки, которая была по курсу 68, а от курса на дату возникновения задолженности 70, что не логично.
| Дебет | 60.01 [счет расчетов, курс 70] | 50 USD | 3500 ₽ |
| Дебет | 91.02 [реализованные разицы] | 0 USD | 350 ₽ |
| Кредит | 52.01 [валютный счет, курс 77] | 50 USD | 3850 ₽ |
То есть, у нас после оценки на 30.04 100 долларов стоили 6800 рублей (курс возникновения 70, курс оценки 68).
Если смотреть по проводкам, мы хотим видеть следующее, на дату пост оплаты 05.05 (курс 77)
| Дебет | 60.01 [валютный счет, курс 68] | 50 USD | 3400 ₽ |
| Дебет | 91.02 [реализованные разицы] | 0 USD | 450 ₽ |
| Кредит | 52.01 [валютный счет, курс 77] | 50 USD | 3850 ₽ |
На дату оценки 31.05 курс (75). У нас осталось 50 долларов по 3400, после оценки должно стать 50*75 = 3750. Итого нужен Кт на 350.
| Дебет | 91.02 [реализованные разицы] | 0 USD | 350 ₽ |
| Кредит | 60.01 [валютный счет, курс 75] | 0 USD | 350 ₽ |
Итого хотим видеть разницу на 800 отрицательную, красивую, двумя проводками.
Сап сделает следующее. При оценки он корректирует неправильную реализованную разницу, которую начислил от начальной оценки. Эта разница проводится по документу платежа или выравнивания. По счету реализованных разниц в корреспонденции со счетом поправки проведет. Это как раз те 100 рублей которых нам не хватало при проводке реализованной разницы, так как ее считали от курса возникновения а не от курса последней оценци задолженности.
| Дебет | 91.02 [валютный счет, курс 75] | 0 USD | 100 ₽ |
| Кредит | 60.01 [счет поправки] | 0 USD | 100 ₽ |
После корректировки реализованной разницы, сап приступает к расчету корректной разницы и покажет 2 умопомрачительные проводки с учетмо частичного выравнивания. Одна делается по открытой позиции начисления, вторая по открытой позиции частичного выравнивания. Заметьте что минус идет на 91.02 в кредит.
| Дебет | 60.01 [реализованные разицы] | 0 USD | 350 ₽ |
| Кредит | 91.02 [валютный счет, курс 77] | 0 USD | 350 ₽ |
| Дебет | 91.02 [валютный счет, курс 75] | 0 USD | 700 ₽ |
| Кредит | 60.01 [счет поправки] | 0 USD | 700 ₽ |
Итого мы все-таки получим нужную разницу, но на двух счетах (реализованных и оценочных разниц), плюс 2 не нужные проводки. Не корректную разицу от выравнивания с частичной пост. оплатой и сторно этой проводки.
Логика дельты активируется в ракурсе V_FAGL_FCV_DELTA для каждой области оценки. Зачем нужно несколько областей? И что это вообще такое. Область оценки – очередной термин придуманный в SAP, нужен он для того чтобы можно было выполнять оценку отдельно для разных видов учета.
Главное свойство области оценки, что в рамках нее выполняется переоценка. То есть если у нас несколько регистров: для управленческого учета, для бухгалтерского учета, для налогового учета. Область оценки с настройками логично создавать под каждый из регистров, чтобы можно было выполнять оценку отдельно в бухгалтерском/управленческом/налоговом учете.
Можно сделать так, чтобы переоценка выполнялась сразу по всем регистрам, тогда будет одна область присвоенная нескольким правилам учета.
Метод оценки определяет как рассчитывается разница, для РФ используют обычно “Оценка как таковая” (V_FAGL_T044A-XAUFW). Так же в настройках метода обязательно нужно указать как проводить переоценку, признак “Провести по каждой отдельной позиции” (V_FAGL_T044A-XPOST) обычно должен быть установлен.
Первое, что нужно знать про эту функцию, работает она только при итоговом выравнивании позиции. При частичном выравнивании ничего не работает. Второе, это активируется она в таблице V_001_F.
Пример корректной настройки счетов трансляции есть в этой статье. То есть не нужно пытаться выдумывать счета поправки, они должны соответствовать 91 счету оценочной разницы.
То есть в настройках OBA1 для операции KDF в блок “Трансляция” вносятся 91 счета оценочных и реализованных разниц, никакиз счетов поправки к 60 счету там быть не должно. В поле “Расход” блока “Трансляция” вносится счет отрицательной оценочной курсовой разницы, в поле “КорректБлнс/расход” вносится счет расходов реализованной курсовой разницы. Если в блок внесете счет поправки кредиторской задолженности расчет по сальдо будет неправильным.
Проводка трансляции выполняется между 91 счетами. Зачем в принципе ее настраивать вопрос открытый. Если проводка поправки реализованной разницы может быть как-то объяснена, то проводка трансляции в принципе не понятна, так как выполняется только при итоговом выравнивании.
Продолжим наш пример, чтобы посмотреть как это работает.
Допустим у нас была полная поплата оставшихся 50 долларов по курсу 80 на 05.06.2020. На момент предыдущей оценки курс был 75. Логично что мы хотим видеть одну простую проводку (80-75)*50 = 250
| Дебет | 91.02 [валютный счет, курс 75] | 0 USD | 250 ₽ |
| Кредит | 60.01 [счет поправки] | 0 USD | 250 ₽ |
Сап нам сделает при выравнивании проводку реализованной разницы от курса возникновения задолженности (70), курс на дату полной оплаты был 05.06 (80)
| Дебет | 91.02 [валютный счет, курс 80] | 0 USD | 500 ₽ |
| Кредит | 60.01 [счет расчетов] | 0 USD | 500 ₽ |
Затем стойко будет проводку корректировать, причем корректирует через тот же счет, через которую разницу отразил, то есть проводка будет в Кт 91.02
| Дебет | 60.01 [счет поправки] | 0 USD | 250 ₽ |
| Кредит | 91.02 [валютный счет, курс 80] | 0 USD | 250 ₽ |
Итого, мы получаем нужную нам разницу, но двумя провоками и в оборот по неправильной стороне 91 счета. Затем сап мужественно пытается реклассифицировать разницу. Но в расчет трансляции он берет только разницу от последнего выравнивания, предыдущий платеж не учитывается. Проводка трансляции будет
| Дебет | 91.02 [оценочная разница] | 0 USD | 150 ₽ |
| Кредит | 91.01 [реализованная разица] | 0 USD | 150 ₽ |
Еще можно было бы понять если бы снималась полностью корректировка в Кт91.02. счета, но когда снимается тоьлко часть такой рекласс будет только путать пользователей.
В целом нужно понимать, что логика запуска переоценки в SAP не лежит на поверхности, полного решения я не нашел ни на sapjam ни на sapboard ни на help.sap.com. Очень много проектов где ни активируют ни логику дельты ни трансляцию и живут с тем что есть. С учетом вот такой логики оценки любая задача связанная с отражением разниц. Будь то акт сверки в условных единицах или перевыставление разниц в SAP начинает играть новыми красами и загонять взявшегося за нее бедолагу глубоко в отладку, хорошо если в отладку.