Вопрос по отпуску. Ранее при переходе в РФ нас не пускали (то переход, то национализация ). Теперь становится актуально.
Что есть:
13-е апреля в Крыму праздник, - в календаре 1 PRAZ^1.
у человека отпуск с 01.04.2015 по 21.04.2015.
WPBP
01 01.04.2015 21.04.2015
02 22.04.2015 30.04.2015
В расчете два технических
* /876 ФактКаленда01 19,53
* /876 ФактКаленда02 8,79
Общая сумма /876 = 28,32 (не 29,3)
и
* /877 НедействКал01 1,00
Вопрос:
1. Появление /877 - это "ошибка/недонастройка" в системе?

2. Я правильно понимаю, что в RT должен накопиться только один /876 за период НЕ отпуска - 8,79?
Сейчас после RUF4 накапливаются оба вида и не совсем понимаю как занулить /876 приходящийся на период отпуска.

3. Можно у Вас подсмотреть настройку T554C. Вот что у меня:
13 Праздничные дни во время отпуск 100,00 04 Всегда кроме праздничных дней
01 Отпуск 100,00 03 В праздники
и
4. Актуальное правило RUF4.

Спасибо.

1. У нас ВО /877 НедействКалДниДляОтпуска содержит дни отсутствия. В вашем случае д.б.= 21

2. Правильно, но с 2014 года формируется ВО /882 Факт. КД для отпуска 29,3.
Нота 2021655 - Federal law 55-FZ from 02.04.2014. New coefficient for calculation of the average wages – 29,3.
У вас ошибка возможно из-за неправильного /877.

3. У нас нет такого правила оценки отсутсвий.

4. В ноте 2021655 создано новое правило RUF8, которое вызывает RUF4.

Спасибо.

С 02.2015 по 06.2015 была накоплена "база" для расчета отпускных (технические виды).
С 01.07.2015 будет массовое повышение окладов.
"Бухгалтерия" просит для всех, кто пойдет в отпуск начиная с 07 2015 проиндексировать "базу" на определенный к-т (рассчитывается как новый оклад / старый и т.д. ... согласно зак-ва РФ).

Заложен ли этот механизм в стандартные настройки системы у Вас (подскажите где, - таблицы или правила...)?
Сейчас это у меня реализовано путем добавления в схему расчета своих процедур/функций.

Добрый день!
Механизм в стандарте есть.
Реализовано с помощью правил адаптации для основ расчета средних значений (ВО /02I и /010).
Настройка правил адаптации V_T51AV_C. Присвоение правил адаптации V_T51AV_B.
Обработку производит функция RUAVE. В процессе работы последней, суммы до глобального повышения адаптируются (увеличиваются) в соответствии с коэффициентом который хранится в ВО /02I.
Для вычисления коэффициента нужно создать свое мероприятие и причину для ИТ0008 (поле PREAS - Причина изменения основных данных). При проведении мероприятия это поле должно обязательно заполняться (если это глобальное повышение), тем самым в схеме (правило RUAJ, подсхема RUT1) будет формироваться ВО /02I с коэффициентом индексации.
Так же обратите внимание на операцию RUADP которая обрабатывает специфические ситуации, когда глобальное повышение производится когда сотрудник уже в отпуске. В этом случае нужно часть отпуска после повышения индексировать (адаптировать), а до - нет. Например, сотрудник в отпуск с 25.06.2015 по 15.07.2015, глобальное повышение 01.07.2015. Тогда среднее для отпуска до повышения (25.06.2015 - 30.06.2015) не индексируется, а после (01.07.2015 - 15.07.2015) индексируется. Если я ничего не напутал
Операция RUADP вызывается в правилах RUK1 и RUK3 (нота 1723584).

P.S. дополнительно рекомендую Вам почитать курс HR433 (желательно самый последний) или посетить его . В нем подробно изложен процесс индексации и все ключевые настройки + ссылки на законодательство и картинки с примерами.
P.P.S. на форуме было много тем по поводу индексации. Посмотрите еще их. Например:
viewtopic.php?f=11&t=85879&hilit=RUADP;
viewtopic.php?f=11&t=84354&hilit=RUADP
Удачи!

Хочу уточнить.
1. То есть система не индексирует каждый пред период. Индексируется уже рассчитанная RUAVE средняя на /20I ?
2. К-т индексации получается индивидуальным (поскольку завязан на ИТ0008)?

1. Нет. Индексируется собранная кумуляция (каждый ВО подлежащий включению в расчет среднего) за период а не само среднее. Я поэтому вам и указал, что само правило адаптации прописывается в ракурсе V_T51AV_C, а присваивается непосредственно правилу кумуляции в V_T51AV_B (каждому ВО для правила кумуляции). В логе RUAVE видно, в таблице кумуляций, что суммы увеличены, а не те что лежат в кластере, если конечно /02I не равен 1 (т.е. нет глобального повышения зп);
2. Да именно так. Индексация вообще процесс не тривиальный. Даже специальная программа есть для создания мероприятия и расщепления ИТ0008. Называется RPITRF00.

Если «на пальца» объяснять, то получается так. В процессе работы системы каждый месяц в расчете вычисляется коэф-т индексации (ВО /02I или /010), который показывает степень изменения заработной платы относительно прошлого периода. Имейте в виду, что этот коэф-т именно относительный – на первом этапе он равен 100%, затем, например, 110%, каким и будет оставаться следующие периоды. При следующей индексации он вычисляется уже относительно 110%, то есть 121% при 10% индексации, и т.д.
Когда приходит время расчета среднего, блок расчета среднего просматривает этот коэф-т, вычисляет и составляет таблицу индексации (за 12 месяцев повышений может быть несколько, месяц может индексироваться частично). В этой таблице индексаций будет не исходный коэф-т из кластера (ВО /02I или /010), а вычисленная относительная индексация (например, между 110% и 121% разница 10%). Затем производится индексацию найденных ВО, входящих в базу среднего, в соответствии с построенной таблицей.
Функциональность достаточно сложная с точки зрения технической реализации. До сих пор идут ноты по исправлению найденных ошибок в этом блоке.

еще про признак 33BPC надо не забыть и ракурс V_T7RU51AV_C.

При наших настройках перед RUAVE получил правильный /20I (RUAJ) (признак учел, необычно что "UK" ).
Вижу, что RUAVE на выходе получает среднюю без учета индексации (далее в схеме идет RUA3). Ситуация вроде соответствует моей версии курса HR433: "Правило RUA3 осуществляет окончательную обработку средних значений, в том числе адаптацию среднего значения в случае глобального повышения, произошедшего в текущем расчётном периоде. Среднее значение, рассчитанное функцией RUAVE, умножается на отношение /02I для частичного периода после глобального повышения, к /02I, рассчитанному для частичного периода до глобального повышения".

Согласен. Уже подзабыл
В случае если событие наступает в месяце глобального повышения, как раз работает RUA3, так как нет записи в кластере для текущего периода с ВО /02I.
Но это для старого расчета средних с пред и пост обработкой RUAVE. В новых же средних (бизнес-функция HCM_LOC_CL_19), все делает RUAVE не зависимо от того когда наступил случай расчета среднего (поправьте, если ошибаюсь).

По курсу не совсем понятно что настроить для отработки RUA3. Сейчас правило в холостую отработало...

Есть такое.
Системы под рукой к сожалению нет, подсказать не могу
Посмотрите в журнале RUA3. На сколько помню из VAR'а достается переменная с значением /02I.
Хотя могу ошибаться.

Смотру, что фигурирует 65 класс обработки. У меня на отпуске в 512w стоит "Средние за 12 мес без учета повышения з/п".

А почему вы используете /02I? Это старое решение, лучше использовать /010. В нем хранится оклад за каждый месяц. RUAVE сравнивает /010 в месяце повышения или события (зависит от настрйки в t7ru51av_c) и сравнивает со /010 в каждом из месяцев расчётного периода до глобального повышения, полученный коэф-т умножается на сумму индексируемого ВО. Исключение составляют только отсутствия, которые начались до повышения, а закончились после. Эти случаи обрабатывает RUADP.

UPD
Более того, использовать /02I даже неправильно, т.к. выплаты могут быть индексируемые и неиндексируемые, причем в привязке к дате, а /02I, на сколько я помню, просто повышает ставку среднего в правиле RUA3.