После применения ноты 1951419,
Wage type /120
1.1. Delimit wage type /120 on 01.01.20141 and set value 8 to processing class 68.
1.2. Save your entries.
- If you want to process the payroll accounting for year 2013 during the year 2014, you have to perform the corresponding adjustment of the start date of the new customizing (for /120 and other wage types).

Ошибка заключается в том, что если у ВО /120 68 =0, то значения /120 не восстанавливаться, а берутся из IT, в результате с новыми настройками в IT после RURB /120 оказывается не правильная сумма - больше на /128 из ORT.
Привожу пример, максимально упрощённый, с обратным расчетом без доначислений. Т.е. на экране запуска драйвера ставим дату обратного расчета месяца в котором были ВО, которые имеют кумуляцию 28 (/128).

Оригинальный расчет 04/2013 в 04/2013 - ошибок нет .
У сотрудника в 04/2013 был начислен оклад 1000 руб., который имеет кумуляцию 20 и был начислен б/л 300 руб., который имеет кумуляцию 28.
На вх. RUTAX /120(1300 руб) = /120 (1000 руб) +/128 (300 руб) – это правильно.
В кластер в RT также пишется/120= 1300 руб.

Обратный расчет 04/2013 в 01/2014, в котором возникает ошибка.
Никаких изменений за апрель не делается!
Т.к. для /120 изменен класс обработки 68 с «пусто» на 8, изменилось и формирование /120 при обратном расчете, а именно, происходит восстановление в соответствии с логикой значение 8 класса обработки 68.

Почему ошибка!

Т.к. сейчас у ВО /120 класс обработке 68 = 8
1. Из ORT /120 (1300)-> AIT – в правиле RUES
2. Из AIT /120(1300) ->IT – функцией PITAB A AIT
3. Сама ошибка возникает в RU76, а именно, не обоснованное увеличение зн. /120 (1300 руб) в IT на значение /128 (300 руб), после чего /120 в IT равен 1600 рублей.
Эта же сумма передается на вход RUTAX /120(1600 руб)
Ошибки:
1. В итоге в кластер для результата расчета FOR 04/2013 IN 01/2014, технические ВО /120, /405, /320 и т.д. сохраняются некорректными
2. Если у сотрудника была льгота, которая предоставлялась с ограничение, т.к. изменяется база, льгота не применяется.

Как было до применения ноты, почему не было ошибки.
1. Из ORT /120 не передавался.
2. В IT ВО /120 до правила RU76 приходил сформированный на основе кумуляции в него только оклада 1000.
3. В RU76 ошибка не возникала, т.к. выполнялись п. 1 и п.2. т.е. RU76 возвращал /120(1300) = /120 (1000) + /128 (300)

Коллеги, ваше мнение, я прав - нота 1951419 портит данные при обратных расчетах?
Кто уже столкнулся, писали в САП, как комментируют. У меня к сожалению сейчас нет возможности выставить сообщение в САП.

Коллеги, есть на форуме люди, которые применили ноту или установили релевантный SP? Даже если сделать настройки с 01.01.2014 будут проблемы, они просто проявиться позже.

68 кл обработки, всегда возвращаем свои значение после пакетов.
На мой взгляд, если у /120 68 = 8, тогда /128 теряет смысл. Вам должен помочь следующий твик: перенос кумуляции 28 на 20 у входящих в/о в 28, с даты смены 68 кл у /120.
Проверьте.

Macros, предлагаемое Вами решение не поможет, а вернее поможет, если в совокупности применить с настройками ноты с датой начала - равной актуальному месяцу расчета.

В данном случае речь идет о том, что настройки ноты применены с 01.01.2013 (что разрешается самой нотой).
Почему ваши рекомендации не помогут - т.к. /128 тоже имеет 68 = 8, то при ретро расчетах он востанавливается из ORT, значение из ORT передается в IT, и в RU76 кумулируется в /120, при этом в IT уже лежит /120 (в который входят все начисления), который также берется из ORT т.к. по ноте у него теперь 68=8.

Вы используете /128?

Нет на текущем проекте не используем.

Проверить в системе не могу, да всю цепочку в уме не вижу.

У нас схема настроена не так, как у вас, но я решил воспроизвести ситуацию по вашему описанию. Мой вывод такой - проблема в использовании кумуляции /128. Настройте новые изменения с 01.01.2014 и одновременно избавьтесь от кумуляции /128 с этой же даты (а то там получается «масло масленное».

Да, и ошибки в стандарте там нет. В вашем примере, вы смотрите только на апрель 2013. Посмотрите, что еще в декабре 2013 происходит. У вас суммы налога должны просто перераспределиться – в апреле увеличатся, в декабре уменьшатся. Если бы вы изменения сделали в декабре 2013, то такого перераспределения бы не было. P68=8 следит по изменениям по годам, был бы перерасчет в одном календарном году, такого эффекта бы не было.

Я так понял, что Вы хотите изменить настройки с 01.01.2013? Можете сказать какого эффекта от этого вы хотите добиться?

Это если стандартных вычетов нет, иначе может НДФЛ за год измениться.

Ну, да. С вычетами все становиться эффектнее

Но даже в этом случае это будет ошибкой настройки, а не ошибкой работы логики классов обработки. Если бы в этом примере не была задействована 28-кумуляция, и мы бы задним числом у /120 изменили 68-й класс, то какие-то изменения с НФДЛ все равно бы происходили.
Делать такие изменения задним числом всегда чревато.

Что бы база перерасчета 2013 учитывалась в 2014.


Так работать будет, но при этом еще надо ВО из /128 перекинуть в /120. И то не во всех случаях!

Ошибка в стандарте есть, если Вы смоделировали мой пример, то можете легко в этом убедится - посмотрите значение /120 в RT в "P" расчете, и "A" расчете 04/2013 (после применения ноты) суммы разные, а при отсутствии доначислений должны быть одинаковые. Причем база /120 будет расти с каждым расчетом, в который будет попадать 04/2013 при обратных расчетах.

Если применить ноту как есть, даже с 01.01.2014, то ошибка в стандарте начнет воспроизводится с 02/2014.

1. Проблема что 28- кумуляция задействована, более того в стандарте в не включено более 100 ВО.
2. В ноте есть ссылка, что если вы хотите использовать настройки раньше 2014 то можете это делать.

Тогда еще одна идея: Все ставим по ноте, потом корсхемой за 2013 обнуляем /128, кумуляцию 28 переносим на 20 с даты смены 68 кл у /120.

Я расматривал это вариант, основная проблема, что в кластер легли испорченые данные при расчете января. Как это теперь вылечить.

Вообще, проблема в чем? В том, что механизм 68-го класса обработки работает не в тот момент времени, когда нужно. Этот механизм должен работать, когда работа с базой уже полностью завершена. Но при использовании 28-й кумуляции база /120 окончательно формируется позже. В результате, при обратном расчете мы сравниваем /120 текущего расчета, который еще до конца не сформирован, с /120 базой прошлого расчета, который был сформирован полностью. При таком подходе при наличии ВО /128 всегда будет выявляться разница, которая затем будет куда-нибудь переносится в соответствии с логикой 68-го класса.

То есть, /120 должен адаптироваться раньше, чем работает 68-класс. Вот только 28 кумуляция сама использует механизм 68-го класса, поэтому мы не можем просто перенести процедуру адаптации /120 на сумму /128 (правило RU76) выше.

BVM177, вот что можно сделать в вашем случае для 2013 года. Нужно выполнить обработку 68-го класса дважды: сначала в только в отношении ВО /128, затем для всех остальных. Цепочка действий в случае обратного расчета должна быть примерно такой:
- правила 68-го класса (RUES, RUE5, RUE6) для /128
- затем RU76 P76 NOAB
- затем (RUES, RUE5, RUE6) для всех остальных.
(далее там еще раз будет выполнен RU76 P76 NOAB, но это не помешает, так как /128 уйдет из IT на первом вызове)

Как это можно сделать. Для 68-го класса добавляете новое значение (для определенности пусть будет $), это значение присваиваете ВО /128 с 01.01.2013. Делаете копию правил (RUES, RUE5, RUE6), в которых удаляете все ветки, кроме 8, которую в свою очередь переименовываете в $. Вставляете обработку этих правил перед стандартными, затем вызов RU76, затем стандартные (RUES, RUE5, RUE6).

Первый прогон 68-го класса восстановит /128, затем произойдет адаптаций /120, а затем уже полностью собранный /120 будет сравниваться со старым расчетом. Таком образом, изменения /120 произойдет только, когда действительно какие-то новые суммы пройдут.

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

Не думаю, что можно будет "продавить" такое сообщение об ошибке. Имеет места два разных подхода к сбору данных для налогообложения. Оба подхода сами по себе рабочие. Проблема возникает, если их смешать. Только смысла их смешивать нет.
И потом, ошибка не в решении новый ноты 1951419, а в той, которая вводила кумуляцию /128. Думаете, САП переделает устаревшее решение, когда есть новый подход от ФНС?