tantsa, большущее спасибо! Посмотрела внимательнее на правило RUA3. Всего-то надо для ВО отпуск класс обработки поставить "9" (а нас было "5", в 000 манданте стоит "А"), и ЧУДО!!! Отпускные в месяце повышения ЗП проиндексировались!!!

tomacik, с такими ситуациями не сталкиваемся, поэтому не подскажу.

В правиле адаптации можно настроить, учитывать ли изменение оклада в обе стороны или только при повышении (ракурс V_T51AV_C, тип адаптации B или P). У вас, видимо, учитывается только повышение оклада, поэтому при уменьшении оклада - коэффициент 1.
Я смоделировала пример с уменьшением оклада, адаптация работает и в сторону уменьшения (например, может быть коэффмциент 0,9)

Добрый день! У сотрудника могли быть локальные повышения и уменьшения. Допустим январь 1900руб оклад, февраль 1900руб, март 19500, апрель 17000, в мае глобальное повышение стал 17340. Коэффициент = 1,02. У Вас к январю будет применен 1,02 или 1? В случае правильного применения какое у Вас правило адаптации? На сколько я тестировала RU00 применяет 1,02 ко всем периодам. А у Вас как?

tomacik, смоделировала ваш пример.
Ввела ваши оклады сотруднику и отпуск в мае 2015, правило адаптации RU02
В функции RUAVE скумулировалось так:
январь 17000
февраль 17000
март 17000
апрель 17000,
т.е. все адаптировалось к апрельскому окладу
А на шаге RUA3 ставка умножилась на 1,02, т.е адаптировалась к майскому окладу

Спасибо, Tansta!
Она сначала применила понижающий коэффициент к доходу месяца где оклад был больше и потом опять применила в RU03 повышающий и в итоге образовалась 1?
Я правильно поняла? У нас сильно подломано правило RUA3, в нем Операции RUADP нет вообще, а есть какие-то телодвижения с в0 /02I.

Добрый день!
Локальное или глобальное повышение видно в 8 ИТ (причина изменения). У нас если локальное- причина 00, если глобальное- 01. В правиле RUAJ обрабатывается эта причина (признак 33BPC). В вашем примере это будет январь-1, февраль-1, март-1, апрель-1,2. Но лучше использовать сотки (январь-март 100, апрель 120). Это если у вас правило адаптации с коэффициентом /02I.

Сказали бизнесу, что перевод с оклада на тариф и обратно делать в любой день, только не в день глобального повышения ЗП.и проводить причиной 00 в 8ИТ.

tomacik, хочу уточнить, в моем тестовом примере все локальные повышения обрабатывались как глобальные. это связано с нашей настройкой для конкретного заказчика, у нас все повышения окладов - глобальные.

Всем здравствуйте!
Да, отпускные проиндексировались (в правиле RUAM), и все оплаты по-среднему, которые привязаны к отсутствию. А как быть со средними, которые привязаны к присутствиям? как я поняла RUADP обрабатывает только отсутствия. У нас коммандировка настроена как присутствие, и она в правиле RUAM не индексируется.

Коллеги, добрый день!
Подскажите, пожалуйста еще один вопрос. У вас продление отпусков индексируется правильно? Продление настроено расчет по среднему также как и отпуска, по одному и тому же правилу? Проблема когда отпуск начинается и заканчивается до глобального повышения, оплачивается внециклом. Затем прерывается больничным, и продляется уже в месяце после даты глобального повышения. У нас идет индексация, хотя не должна, т.к. продление отпуска до повышения. Поля SPPE1 (и SPPE2 тоже пробовали) ссылаются на дату отпуска до глобального повышения.

Коллеги, поделитесь, какие настройки для правил адаптации установлены в Ваших системах?

Ситуация: не верно работает адаптация отпусков для периода сразу после официального старта. Отпуск сотрудника берется в месяц Ч, а весь предшествующий год находится в историческом прошлом. Исходное повышение оклада тоже было в прошлом, за пол-года до старта. Для отпуска используется правило модификации RU02.

Настройки для RU00 и RU02:
оцениваться по типу 4 исходя из ВО /02I, глубина 24 календарных месяца.

Настораживает, вроде же ВО /02I считается устаревшей технологией - почему он присутствует здесь? Может нужно по /010 сравнивать?

да, нужно использовать RU01 или RU02.
Проверьте, что /010 в принципе существует в прошлых периодах. Бывают, что его немножко забывают включить в миграцию.
Еще нужно проверить сплиты WPBP и группировку правил для расчета ЗП (ABART и APZNR)
Алгоритм со /02I - устаревший, но тоже требует, чтобы ВО был в месяце перед глобальным повышением.

Коллеги, добрый день,
Обнаружилась некорректная работа операции RUADP.
У сотрудника произошло глобальное повышение заработной платы 01.01.2018 (индексация). В месяце индексации имеются отсутствия оплачиваемые по среднему заработку. Виды оплат из которых оцениваются эти отсутствия, рассчитываются по одному правилу расчета средних значений. Самое простое, что эти отсутствия просто одинаковые. При этом первое отсутствие начинается и заканчивается в январе (11.01.2018-12.01.2018), а второе - переходящее на следующий месяц (13.01.2018 – 04.02.2018). Оба отсутствия имеют «Оценка в текущем периоде расчета», то есть февральская часть второго отсутствия оплатится в феврале.
При расчете января на выходе RUAVE ставка оплаты отсутствий рассчитана без учета индексации, и также записана в таблицу AVERAGE. ВАЖНО, что порядок следования записей в AVERAGE соответствует кодам видам оплаты, а не датам отсутствий. В результате конечной обработки в правиле RUA3 операция RUADP рассчитывает коэффициент индексации LV_PREV_FACTOR применяет его к ставкам оплаты отсутствий OT-BETPE и переписывает соответствующее значение в AVERAGE. В соответствии с примечанием к условию перезаписи AVERAGE «"In case of global salary increase we only adjust once in the calculation period to avoid the multiple adjustment sv_onetimeadjust = 'X'.» индексированная ставка вписывается только в одно правило (первое плавило), и если это правило и ставка относится к первому отсутствию (по датам), то второе правило и ставка (к переходящему отсутствию) остаются неизменными.
В дальнейшем, при расчете февраля используется для второго (01.02.2018 – 04.02.2018) отсутствия неиндексированная ставка из AVERAGE, что не корректно.
Кто-то сталкивался с подобным?