Можно подправить и его, но либо придется его хорошенько переделать, либо теги <ОПСстраховаяЧасть> и <ОПСнакопительнаяЧасть> исчезнут совсем, в том числе и для строк в которых они должны фигурировать. Так что оптимальный вариант все-таки подождать исправление САП

ага, как минимум в 3-х местах + в каждой строчке 110-114 поменять параметр

Здравствуйте. Скажите пожалуйста, а что нибудь слышно по форме СПВ-2?

Проект так и не утвердили в ПФР, но судя по тематическим форумам, некоторые отделения ПФР прекратили прием СПВ-1, требуют СПВ-2. Бардак.

Macros спасибо

[quote="kotejka"]Добрый день.
После установки SAPKE60471 возникла следующая ошибка:
Программа HRULNDFL, при выгрузке в файл XML формируестя 2-ая строка "ымл-#######", которой раньше не было. Файл не проходит проверку в программе CheckXML.

Решение:
Для корректного формирования xml файла по форме 2НДФЛ необходимо выполнить следующие действия:
1. Выгрузить и разархивировать из ноты 1965224 вложение E_T5_33E.zip.
2. Сделать копию каждого из 3-х разархивированных файлов
3. Переименовать копии из E_T5_33E.TXF в E_T5_33R.TXF, из E_T5_33E.TXH в E_T5_33R.TXH, из E_T5_33E.TXT в E_T5_33R.TXT
4. В транзакции se38 запустить отчет HRUUTED0, ввести язык RU, имя формы E_T5, нажать F8, выбрать строку с формой E_T5, затем выбрать меню "Обработать->Загрузка", загрузить файлы E_T5_33R.TXF, E_T5_33R.TXH, E_T5_33R.TXT и сохранить форму.

Возможно эта нота поможет, без ручного тюнинга 2008995 - HRULNDFL: Xml is not downloaded in Russian language

Эта нота не сработала...
Ошибка ушла только после ручного "тюнинга")

В ноте 2008995 - HRULNDFL: Xml is not downloaded in Russian language добавили 3 шаг в разделе Solution:
After implementing of correction instructions check that note 1965224 is implemented. In transaction se38 run report HRUUTED0, enter language RU, form name E_T5, press F8 and if line with form E_T5 exists then select this line, select menu "Form->Delete", delete form and save form.

После выполнения данного шага "ымл-#######" в xml-файле не появляется.

Добрый день, SAP HR профессионалы.

Поделитесь опытом как решили вопрос с обновлением коэф. 29,3 для расчета отпуска?
Для учета нового коэф. 29,3 вместо 29,4 необходимо при отработанных полностью месяцах умножать средний на коэф. 29,4/29,3 с апреля 2014?
Что делать если месяца отработаны не полностью за последние 12 месяцев? Создавать еще один вид оплаты для расчета кал. дней исходя из 29,3 в каждом месяце и делать перерасчет всех сотрудников за предыдущие 12 месяцев, чтобы с апреля 2014 учитывались калю дни по новому ВО?

Заранее благодарен

Подождите пару недель, САП что-нибудь сделает. Недолго осталось.


В общем случае, 12 месяцев недостаточно. Еще может быть сдвиг периода расчета среднего на более ранний период из-за декрета, например. Если этого не сделать, средний может быть значительно искажен в большую стороны. У нас например, есть люди, которые фактически не работают с 2006 года - из одного декрета в другой.

Кроме этого, изменение действует со 02-го числа. Попробуйте настроить правило расчета среднего не с первого числа, увидите, что такая настройка работает не правильно.

Тоже столкнулись с этой проблемой. А все из-за кода а-ля "Сделано в Индии" в инклуде H99CAVERA. Суть вот в чем: если у вас средняя настроена 3 разными способами за период, и на каждый полупериод есть отсутствие, то средние для каждого полупериода посчитаются корректно, а вот присвояться криво, всем ВО в каждом полупериоде в итоге присвоится последняя посчитанная средняя.
Даже интересно как наш САП это разрулит.
Пока решили сделать настройки с 1-ого числа - потери копеечные.

Да, процедура ENDPROCESSING, вот здесь
Проверка периода по какой-то причине производится только по одной дате, что является ошибкой. Причем, правильное условие там есть, но только оно закомментарено.

Кроме этого есть и другие проблемы.
1. Иногда требуется производить расчет среднего на дату, отличную от даты начала записи ИТ2001. Для этого там предусмотрено поле "ДатаОц/РасчСр" (SPPE2). Так вот, если там указана дата, когда действует другое правило расчета среднего, например, отсутствие апреля, а средний нужно посчитать на дату марта, то будет ошибка. В реализации RUAVE при обработке SPPE2 правило расчета среднего считываются не по дате SPPE2, а по датам из WPBP.

2.Изменение правила расчета среднего плохо работает в случае использования механизма "заморозки" среднего. Если связанное продолжение отсутствия, для которого используется заморозка, приходится на период с другим правилом расчета среднего, то возникнет ошибка, типа, "продолжение должно оцениваться по тому же правилу среднего что и начало".

Для этого есть ракурс V_T7RU51AV_PT "Определить соединения правил расчета средних значений для отсутствий", в котором можно указать преемственность правил расчета средних. После настройки замороженные средние будут переходить корректно.

Попробовал. Да, работает. Только есть одно замечание. В схеме функция RUOAV, которая производит перенос замороженных значений, работает заметно раньше блока расчета среднего. Между тем, расчет среднего может быть связан с расчетом вспомогательных ВО, например, когда требуется пересчет премий. Эти ВО генерируются непосредственно перед RUAVE (старый алгоритм расчета среднего, правило RU17).
Так как вспомогательных ВО на момент работы RUOAV еще нет, для них преемственность правил расчета средних не работает.

Перенес RUOAV после работы правила RU17 (у нас старый алгоритм расчета среднего). После этого заработало как надо.