Вышла нота 1814007 - https://service.sap.com/sap/support/notes/1814007.
Здесь вроде не замечена.

спасибо, добавил в шапку

Коллеги, добрый день.

Подниму вопрос по поводу заполнения ВО /890. У нас система в 2012 году жила только с кадровым и табельным учетом. Отсутствия велись корректно в ИТ2001, там все есть. В 2013 стартует зарплата. За 2012 историческая ЗП загружалась, соответственно в кластере таблица AB за 2012 пуста. Правильно ли Я понимаю что система не будет анализировать напрямую ИТ2001 и выход для ввода ВО /890 за 2012 год это заполнение ИТ0293?

Правильно.


Один из. Другой вариант, раз вы данные за 2012 год загружаете в кластер, туда же можно загрузить и /890.

Так же можете сделать расширение, и в ФМ HR_RU_AV_REL_SICK_2011_YEARS для 2012 года считывать и анализировать данные ИТ2001, вместо AB. Это самый быстрый варинат для реализации в ваших условиях.

SAP Выпустил ноту Note 1819486 - Wage type /890 is incorrect for more ab record in 1 period
по поводу учета нескольких отсутствий в одном периоде.

Обнаружилась ошибка - если в ИТ0293 в ВО SI** завести только дни, то эти дни рубятся в правиле RU25. Там идет проверка на AMT?0, если равно то идет кривая обработка и ВО SI** на выходе нет. Соответственно в расчете БиР они не учитываются. Решил пока проблему отправляя ВО SI** в таблицу RT до обработки в правиле RU25.

Добрый день!

Обнаружили следующую проблему: если работник с января 2013 года берет отпуск по беременности и родам
сразу же после окончания отпуска по уходу за ребенком до 1.5 лет, то:
- формируется база за 2011 и 2012 год;
- количество отработанных дней равно нулю (то есть количество дней в виде оплаты /890 равно -730).

Выводится сообщение об ошибке:
Прерывание в операц. ERROR
20130101
RUVM****** = XMES RU011 ERROR.

Может, кто-то сталкивался с подобной ситуацией?

Да, натыкался. Ошибка в логике. Писал в САП, ответили так

RoustR, спасибо!

В шапку добавлен п.6 Новые формы персучата СЗВ-6-4, АДВ-6-5
Создана отдельная тема для обсуждения этого вопроса.
viewtopic.php?f=11&t=81196

В текущем решении сапа имеется ошибка в расчете при замене расчетных годов, максимум для дневной ставки исчисляется не в соответствии с последними изменениями закона, в ноте Note 1821752 - 276-FZ. Letter N 15-03-18/12-169 from 11.01.13 обещают исправить эту ошибку к 28.02.2013.
Пример ошибки:
2009 415000 за 300 дней
2012 512000 за 300 дней

По закону расчет должен из среднего (415000+512000)/(300+300) = 1545 далее ограничиваем максимумом (463000+512000)/730 = 1335,62.
Система сейчас ограничивает максимумом (415000+512000)/730 = 1269,86.

p.s.
Надеюсь, что обещают именно это исправление...

Добрый день.
Столкнулись с точно такой же ситуацией. ВО не доходит до средней, если не введенная сумма. Решили проблему путем изменения значения какого-то класса обработки. Вообще странное поведение ВО, почему-то в САП решили что без суммы данные ВО вводится не может.

Коллеги еще один вопрос назрел, с расчетом доп. взносов в ПФ по списку 1 и 2. У ТН, у которых есть вредность по списку 1 или 2 и которые находились в отпуске или на больничном в текущем месяце, доп. взносы не считаются. Вопрос: это корректное поведение? Если да, то не могли бы вы привести ссылку на закон где это прописано? Сам искал в консультанте, но нигде нет упоминание такой ситуации.

В этом месте есть еще и другая ошибка. Если один из годов был полностью нерабочим (в декрете), то сумма максимума налогообложения берется только за один год.
Пример
2011 0 р за 0 дней (365 дней исключены)
2012 400000 за 200 дней

Средний получается 400000/200 = 2000, который должен быть ограничен величиной (463000+512000)/730 = 1335,62.
Фактически ограничивается (0+512000)/730 = 701,37

Можно кого-нибудь попросить посмотреть, как у вас в системе отрабатывается такая ситуация. Самый простой случай, без замены годов, без ИТ0293.
Пусть есть ТН, который в 2013 уходит на больничный по берем/родам (скажем 15.01.2013). Расчет среднего выполняется за 2011 и 2012 год. Пусть в 2012 году у Тн были больничные (20 дней), эти дни должны быть исключены из расчета среднего. То есть, за 2012 год должны быть учтены 366-20 = 346 дня.

За сбор кол-ва дней отвечает правило расчета среднего SNxx, за 2012 год это будет SN12. Можете посмотреть, какое значение примет поле NUM у ВО SN12 в таблице IT на выходе из функции RUAVE?
У меня сейчас получается в таблице IT в SN12 сидит 366, то есть без исключения дней. При этом, в таблице AVERAGE значение SN12 правильное – 346. Сам расчет среднего тоже выполняется правильно, с учетом дней исключения.

Я проанализировал, почему так получается. На данный момент, мне кажется что, это следует из логики настройки среднего. RUAVE выполняет работу в два этапа:
- сначала правила расчета среднего работают для всех ВО за все периоды,
- затем для каждой записи, вызвавшей расчет среднего, отдельно только по текущему периоду.
На первом этапе SN12 работает как задумано – собирает /890 из 2011 и 2012 годов, затем в правиле конечно обработке из кол-во дней в году (366) отнимается собранная сумма (20), и SN12 становится равным 346.
На втором этапе сначала срабатывает правило расчета среднего для больничный по берем/родам (просто в порядке сортировки этот ВО идет раньше). Это правило получает собранные значения, в том числе SN12 равное 346, и на основе это вычисляет верное значение среднего.
Затем правило опять работает правило SN12, напомню, только для текущего месяца. В текущем периоде уже нет релеватных ВО /890, поэтому вычисляется значение 366 – 0, и в итоге SN12 становился равным 366.

С одной стороны значение неправильное, с другой стороны, неправильное значение не используется. Но не используется оно просто только из-за порядка сортировки. Если будет какой-то ВО, например на Z, настроенный на правило PREG, то он будет обрабатываться после правила SNхх, а значит получит уже неверное значение.

Меня только смущает одно. Когда я в январе настраивал схему, мне кажется тогда все правильно заполнялось. У нас ВО SNxx участвует в отчете по расчету среднего, поэтому я этот момент проверял. Поэтому хотел удостоверится, что это проблема не только в нашей системе.

Как у вас заполнены SNхх на выходе из RUAVE?

у нас так же