Добрый день!

Подскажите в каких случаях при расчете среднего учитывается коэффициент адаптации?

У меня в RUAD он получился равный 101,21 и ,как мне кажется, из-за этого зашкалили отпускные.

Заранее спасибо.

если на виде оплаты стоит галка адаптировать

А RUAD это что?
Вы уверены что у вас не RUAJ.
Это 2 разных правила формирующие повышающие коэффициенты. Но 1-е из старой схемы RU00 а второе из RUS0
причем во втором коэффициент умножен на 100

Галочки используются если расчет через AVERA(RUAVE) - это в RUS0
А в старой схеме через операцию RUADP.

Вообще если у вас RUAD то явно что-то с расчетом коэффициента не так. Врядли человеку з/п в 100 раз повысили. А не плохо бы

У меня так было:).
В процессе эксплуатации RUAD выяснилось:
Адаптационные коэффициенты в каждом месяце перемножаются и сохраняются в моем случае в в/о /02I в поле RTE.
Функция RUAVE (в зависимости от правила кумуляции) использует адаптационный коэффициент следующим образом:
При запросе в 5 месяце базы за 2 месяц база умножается на отношение произведений адаптационных коэффициентов (5/2).
Из-за того, что при сохранении в поле RTE произведение коэффициентов округляется до двух знаков появилась приличная погрешность в расчете отпускных.
Я подправил правило RUAD (умножил на 1000) получил похожий результат как у Jesus. Лечилось обратным перерасчетом.
Jesus возможно вы закрывали предыдущие месяца с разными правилами подсчета адаптац. коэф.

Интересно всех устроило стандартное правило адаптации для подсчета отпускных. У нас расчетчики говорят, что нужно адаптационный коэффициент применять только в случае изменения оплаты по всему предприятию (один коэф. на всех), а при одиночных изменениях (штатные перемещения) не учитывать.

Так и есть
потому в правиле RUAD есть операция RUPPR 8?10
и коэффициент изменяется только при выполнении условия. В противном случае он неизменен и следовательно отношение коэф. текущего месяца и предыдущего = 1. Т.е. нет пересчета

AlY операция RUPPR 8?10 проверяет причину изменения (сужу по отладчику).
В случае если в один день две причины (изменение оклада по всему предприятию и частное изменение оклада) можно выкрутиться, не изменяя схему расчета?

Это получается что общее повышение по предприятию 15% а у этого чела 25. Но в расчете должно быть 15%?
Понятно что в 8 его реальная з.п. - т.е. 25 % прирост и определить 15 никак. Тут хоть любую причину ставь.
В таких случаях обычно процент вводят готовый прямо в 8-й ИТ.

Тругого не знаю Вариантов конечно много, но все уже это докручивание на месте и схемы и правил.

А что проверяет операция "RUPPR8?10"?
Если человеку почасовую оплату меняют на оклад, коэффициент адаптации получается большим. Как можно отследить этот случай, чтобы он(коэффициент) не менялся?

В ВО /02I эти проверки сделаны
через NUM- статус сотрудника на момент формирования (RT-ABART)
и AMT - оклад (или ставка)

А далее в правиле формирования /02i проверяется менялся ли статус (ABART) относительно предыдущего. Смотрите правило RUAJ

У нас /02I рассчитывается правилом RUAD. Схема RU00. RUAJ в схеме не используется. Попробовала его поставить вместо- и вместе с RUAD, ничего не меняется.
А RUAD при смене ставки на оклад /02I сильно повышает.
Какая операция отслеживает изменение?
И что проверяет RUPPR8?10 ?

операция проверяет причину изменения 8-го ИТ

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

У нас средние считаются через MEANV и применяем правило адаптации. При этом возникает погрешность, связанная с округлением коэффициентов адаптации. Для /02I я уже увеличила точность на 1000. Но при работе MEANV отношение коэффициентов все равно округляется до двух знаков и возникает погрешность. Можно ли здесь что-нибудь еще сделать?

Перешли на новые средние - проблема округления разрешилась.
Но есть еще одна. При повышении оклада с первого числа все работает, но если оклад меняется в середине месяца то получается неправильно. Для отпуска в том же месяце, когда было повышение, адаптации не присходит вообще. А для отпуска в следующем месяце, предыдущий месяц (где было повышние оклада с середины месяца) адптирутся полностью, хотя надо чтобы повышение касалось только кусочка со старым окладом. Что здесь можно сделать?

Для функции RUAVE нужно чтобы кусочки провильно на вход попали т.е. /02I и в/о где кумулируется база для отпуска (функция анализирует полупериоды):
повышение 10.09.2006 следовательно при расчете за сентябрь в кластере должно быть два разных /02I и в/о где кумулируется база для отпуска.
Все ИМХО, возможно заблуждаюсь. У нас такой ситуации еще не было.
julyb посмотрите как у вас сгенерированы выше указанные в/о.