Добрый день! Это лечится Note 1815690 - Maternity leave if employee didn't have earnings in 1 year .

Да, действительно, должно помочь.

Вот ведь, поддержка САП называется. Я выставил САПу эту ошибку 05.02.2013, 11-го предложили поставить ноту 1819486, которая не имеет отношение к этой проблеме. Сразу же отписался об этой. И на этом все затихло. Сегодня уже 21-е, ответа нет.
И поиск у них на сайте через раз работает в последнее время.

Не могу найти на портале ноту эту 1815960, может быть ее нет в общем доступе еще или поиск не работает опять на портале?
В ней коррекция кода или настройки ручные есть?

Там только Correction Instruction. Номер ноты неверно указан.
Ссылка на ноту:https://websmp230.sap-ag.de/sap(bD1ydSZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1815690

Спасибо,нашел.

Побуду хоть раз ньюсмейкером. Note 1824277 - Maximum daily average rate for maternity since 2013 (276-FZ)

Решил сюда тоже написать.

Нашел следующие ошибки в расчете больничных.

1. Проявится ошибка в следующей последовательности действий. Принят ТН в 2012 году. Сотрудник сразу предоставил справку 4-н о доходе за 2011 и 2012 года у другого работодателя. Бухгалтер ввел эту информацию в ИТ0293 с даты приема.
В феврале 2013 у ТН случается сначала обычный больничный, затем больничный-производственная травма. В этом случае расчет обычного больничного будет произведен без учета дохода другого работодателя. Производственная травма – правильно.
Ошибка происходит в ФМ HR_RU_AV_REL_SICK_2011_YEARS в случае, когда он используется для разных правил расчета среднего. В данном случае это правила ACхх и SIхх. В модуле имеется защелка, которая призвана защитить от повторного переноса данных. Когда модуль сработает для правил ACхх, то для правил SIхх он уже не работает.
Ошибка не связана с изменением законодательства в 2013 году. Просто ситуация, когда она может проявиться, достаточно редкая.
В САП об этом написал.

2. Обнаружил у себя в системе возможность появления в таблице AB кластера расчета перекрывающихся записей больничных. Это приведет к тому, что в случае декрета в такие месяца ВО /890 будет увеличен кратно, что приведет к ошибке в расчете среднего отпуска по берем/родам и отпуска по уходу за ребенком.

Сценарий примерно такой. В январе ТН завели больничный вида отсутствия ХХХХ. Был выполнен регулярный расчет за январь. В феврале выяснилось, что больничный заведен неправильно, следовало использовать вид отсутствия YYYY. Заменили. При перерасчете январе в феврале в таблице AB может быть 2 записи больничного: и ХХХХ и YYYY на один и тот же промежуток времени.
Дублирование связано с обработкой класса 68, правила RUES, операция RUSPL YO. Если какой-нибудь ВО баз налогов /12х собирается с учетом сплита AB, и если для этого ВО установлено значение 68-го класса обработки 1, 5, 7 или 8, то в правиле RUES операция RUSPL YO перенесет запись отсутствия в из старого расчета. Так как виды отсутствия старого и нового расчета не совпадают, то в AB появятся две записи на один и тот же период.
Когда придет время, и этот месяц будет попадать в период расчета среднего по больничного по берем/родам, то ВО /890 будет сгенерирован для каждой записи в AB, а значит дни отсутствия этого больничного будут учтены дважды.

Казалось бы, что описанный сценарий довольно редкий. Однако, если в промежуток 2011-2012 годов выбор способа расчета среднего больничного по берем/родам выполнялся заведением разных видов отсутствия, то такая ситуация будет возникать достаточно часто.

Вышла нота 1825038 по обновленной справке 4н.
https://service.sap.com/sap/support/notes/1825038

При вычислении среднего для отпуска по уходу за ребенком до 1,5 лет в правиле RUVM операция RUABL? выдает ошибку "У вида оплаты нет присвоения отсутствия". Хотя средний для отпуска по беременности и родам рассчитывается без ошибок, правило расчета средних одно и то же. Где и что нужно присвоить?

У ВО отпуска по уходу за ребенком не установлен сплит по AB. Где-то потеряли.

Перед RUAVE этот сплит есть. Где он мог потеряться?

после ноты 1784690 ожидается, что ВО, попадающий в обработку в RUAVE, должен иметь сплит по РМ. Если это какой-то свой внецикл, то, вероятно, надо этот сплит где-то до RUAVE "доподнять". Если религия позволяет, то можно вернуть ПКО в предыдущее состояние (если это не СЕ).

Нам помогла модификация правила RUVM веточки С, перед RUSPL YA стоит RESET A.
Надо поставить RESET YA.

Спасибо! Помогло!!!

Новую форму уже утвердили, я пока только проект закона видел. Может ли бизнес ее уже применять?