Добрый день.
Стоит задача: включить ежегодный бонус в расчет базы для отпуска пропорционально отработанному времени в прошлом году.
Подскажите как это осуществить?

P.S. Сразу оговорюсь, что опыт настройки Wage typов небольшой.

Добрый день!
Мы настроили отдельный технический вид оплаты для доли премии и его расчет (Т554С, таблицы V_T51AV* (правила кумуляции, расчета среднего...)).
Сначала считается коэффициент, на который нужно сокращать премию, потом доля премии.
После отработки в схеме функции RUAVE включили свое правило расчета, которым добавляем долю премии к среднедневной ставке для отпуска.

посмотрите также ноту 1095015, будет полезно.

Добрый день!



Мне кажется более правильно создать еще один WT, который рассчитывался бы вместе с бонусом в том же периоде и содержал бы сумму бонуса уже скорректированную на коэффициент отработанного времени в прошлом году:
WT = WT_Bonus * 2200(ActWSTimeHrsY) / 2010 (WrkTimeNormHrsY)
Потом включить WT в базу для расчета отпуска.

Но у меня никак не получается настроить расчет нового WT. Я так понимаю надо настроить V_T51AV_A, V_T51AV_B, V_T51AV_P
Если про V_T51AV_P все понятно - надо указать для нового WT созданный Av.rule. Av.rule настраиваем в V_T51AV_A:
- rel. rul - затрудняюсь выбрать нужное значение в табл. V_T51AV_R
- Cum rule - настраиваем в V_T51AV_B что суммировать и как. в данном случае добавляем сюда WT_Bonus (c галочкой Amont), возможно еще что-то
- Fin.proc. - тоже затрудняюсь выбрать из вариантов V_T51AV_E.

У нас премия за год вводится и выплачивается с учетом отработанного времени. Т.е. если в приказе сказано, что выплатить премию в размере оклада с учетом отработанного времени, то сотрудник, у которого оклад 50000 руб. и время отработки 80%, получит 40000 руб.
Пример (как это считается у нас): в апреле 2011 Иванов И.И. получил премию по итогам 2010 года 40000 руб., а в мае 2011 идет в отпуск и, допустим, он уже отгулял отпуск в феврале 2011 года, который мы должны тоже пересчитать с учетом премии. Для майского отпуска релевантный период - это с мая 2010 по апрель 2011, для февральского отпуска релевантный период - с февраля 2010 по январь 2011.
У нас есть тех. вид оплаты "ПремИтогГода", который я ввожу массово сотрудникам в 12.2010 года (чтобы данная премия действовала только на 2011 год), который включаю в кумуляцию для правила расчета доли премии.
Правило релевантности использую стандартное RU09.
В правиле расчета доли премии "База по премиям" (у нас на предприятии она еще сокращается на Коэффициент = Количество отработанных календарных дней в релевантном году/Количество всего календарных дней в релевантном году) делится на количество дней для отпуска за релевантный период.
Если я Вас, Orida, окончательно не запутала...

Все понятно . Почти то, что надо. Вот только какие конкретно настройки надо сделать, чтоб задать этот коэффициент и скорректировать сумму на него?
Как реализовать:
Коэффициент = Количество отработанных календарных дней в релевантном году/Количество всего календарных дней в релевантном году
Скорректированный Бонус = "База по премиям" * Коэффициент ?

P.S. Номера WT "Количество отработанных календарных дней в релевантном году", "Количество всего календарных дней в релевантном году" и "База по премиям" я знаю.

Вам нужно собирать 3 отдельных параметра: 1) сумма премии 2) плановые дни 3) фактические дни. Настраиваете для них 3 правила расчета средних. Правило для суммы настроивате на вид оплат премии, правило для дней - на виды оплат соотвествующих дней. Правилом релевантности обеспечиваете сбор данных за прошлый год.

В итоге получаете 3 числа - сумма и дни. Остается только выполнить корректировку. Причем ее можно сделать в прямо в правиле конечной обработки для суммы. Для этого дни должны быть обработаны в первую очередь (обеспечивается кодировкой правил расчета средних). В правиле конечной обработке дней полученные дни записать в переменные (таблица VAR), а при обработке сумм - считать эти переменные и выполнить вычисление.

PS.
Таким образом нельзя получить величину "Количество всего календарных дней в релевантном году", если сотрудник принят в середине года. Вы уверены, что формула должна быть именно такая? Обычно еще учитывают отработанные месяца, то есть 1/12 от премии за каждый отработаный месяц.

PSS.
Для каких целей Вы считаете средний? Смущает фраза "Количество отработанных календарных дней". Календарные дни используются(использовались) в расчете больничных, но там премия должна браться в полном объеме без пересчета.
Для остальных видов средних для пересчетов используются рабочии дни.

Получилось допытать отдел персонала и выбить уточнения к тому, что они хотят. Получается им нужна модель как у вас Tantsa. Не могли бы вы поподробней написать как настроить расчет корректирующего коэффициента и как изменить правило расчета?

Здравствуйте!
Orida, отвечаю на Ваш вопрос. Собственно, Roustr основные вещи написал уже.
У нас для расчета премии существует 3 правила в V_T51AV_A, которые выполняются последовательно:
1) 0052 Оно собирает Календарные дни, фактически отработанные в рел. периоде, т.е. без отсутствий и помещает их в тех. вид. оплаты 9001. Например, их 305
2) 0053 Оно собирает Календарные дни всего, отработанные в рел. периоде. В идеале их 365 или меньше, если сотрудник на предприятии работает меньше года.
Пусть в нашем примере это 365.
В правиле конечной обработки для правила 0053 обращаемся к уже посчитанному ВО 9001. Например так: AMT=E 9001, а в NUM у нас 365, далее DIVID ANR и получаем Коэффициент 305/365=0.84. Для коэффициента у нас тоже есть свой тех.вид оплаты 9002
3) 0054 Это правило для Доли премии.
В кумуляции собираем Премию в AMT и Дни для отпуска в NUM.
Например, премия 40000, а дни для отпуска 295,31
В правиле конечной обработки обращаемся к ВО 9002, сокращаем AMT на коэффициент, делим на отработанные дни для отпуска и получаем
40000*0,84/295,31 = 113,78 Доля премии 113,78 помещается в тех.вид оплаты 9003

А далее в своем отдельном правиле можно добавить 9003 к Среднедневному заработку для отпуска.

Большое спасибо за ответ. Стало ясно, что надо делать. Сейчас тестирую. Остался только один вопрос. Технический вид оплаты (из примера) 9002 и 9003 создать лучше копией с какого стандартного вида оплаты? Правильно ли я понимаю, что у них не должны быть установлены никакие Processing Classes, Cumulations и Evaluation Classes?

Сделала как описано, немного изменив. Пункт 1 и 2 объединила в одно правило (ZY05), собрав фактические часы и занеся их в AMT, и собрав плановые часы в NUM. В правиле конечной обработки применила стандартное правило X018. Там, правда, используются формулы AMT=M и NUM=M (описание значения данной операции не нашла, но думаю это то что надо) вместо AMT=E 9001 . Результат собирается в 9011.
В третьем пункте, как и написано, собираю Премию в AMT и в правиле конечной обработки обращаюсь к 9011 (*): RTE=E 9011
Затем получаю премию скорректированную на коэффициент: MULTI NRA.
Результат заношу в 0482. И эту сумму уже включаю в базу для расчета.
Вот только на шаге (*) на мой взгляд 9011 равно 0, так как правило ZY05, по идеи, не запускалось...
Тест подтверждает мои предположения, так как результат не выдается.
Пожалуйста, помогите разобраться.

Вот только на шаге (*) на мой взгляд 9011 равно 0, так как правило ZY05, по идеи, не запускалось...
Запускалось или нет должно быть видно в журнале обработке. Посмотрите в там. Но я думаю дело в не этом.

AMT=M и NUM=M
Буковка M здесь означает таблицу MV. Функция AVERА (RUAVE - это "обертышь" для AVERА) собирает данные в отдельную таблицу CUMULATION. Перед вызовом правил конечной обработки, данные куммулируются в таблице MV, а AMT/NUM/RTE=M дает доступ к накопленным значениям.

правиле конечной обработки обращаюсь к 9011 (*): RTE=E 9011
E - это таблица RT. Вы в RT к этому времени явно что-нибудь положили? AVERA сама ничего в RT не переносит. При работе по такой схеме данные где-то нужно сохранить. Tantsa предлогала RT, у нас использовалась таблица VAR.
Вот это фраза -Результат собирается в 9011 - что значит поточнее?

ЗЫ. Еще. Поосторожнее с отклонением с использованием полей. Вы используете поле AMT, а оно само не переносится. Мало того, после AVERA в записях в IT поле AMT будет вычислено как RTE * NUM.
Поле NUM тоже не всегда переносится (завист от настроек).

Я имела в виду, что в V_T51AV_P для 9011 назначено правило расчета.


Тогда получается, что в правиле конечной обработки надо на конце добавить ADDWTE* (если использовать таблицу RT) :
AMT=M
NUM=M
DIVID ANR
ADDWTE*

Тоже добавила в правило конечной обработки для 0482.
Протестировала, но не получилось....

Ну, с журналом расчет немножко работать нужно. Особенно на первых порах.
Поставьте после DIVID PRINT X, он выведет обработываемую запись в журнал. Потом в журнале найдите это место, посмотрете что в записе находится.

Вот у Вас команда ADDWTE*. * на конце что значит? * значит, что запись в RT сохранится с текущим видом оплат. А какой он текущий? AVERA в поле LGART (вид оплат) кидает имя правила конечной обработки. Оно у Вас совпадает с кодом вида оплат?
Если в журнал поставить PRINT X, то увидете что именно Вы обработываете. Так же посмотрите в конце в RT, там что-нибудь лишнее появилось? Может быть нужно будет явно прописать, типа ADDWTE9001, если правило используется только для этих целей.

Сначало добейтесь, чтобы у Вас сохранялось так, как Вы ожидаете.Затем переходите к считыванию.

Допустим, Вы используюте AMT=E 9001. Поставьте после него PRINT X, посмотрите в журнале правильно ли считалось.

Вообще, поначалу лучше контролировать каждый шаг исполнения правила.

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

Пробовала print в правилах вставлять....
Я явно что-то не так делаю, я не вижу в журнале обработки, что правило ZY05 запускается.
Возможно я не указала верный processing class или не сделала другую настройку, чтобы рассчитался по среднему мой новый созданный вид оплаты.

Как я сделала:
в таблицу V_T51AV_P добавила новый вид оплаты 0482, который в свою очередь рассчитывается на основе тоже нового вида оплаты 9011, который тоже рассчитывается по среднему. Таким образом при расчете отпуска система просматривает таблицы V_T51AV* находит правило для расчета отпускных видит что нужен 0482 начинает считать его, видит, что для его расчета нужен 9011, начинает считать его.
Возможно моя логика неправильная.

Помогите разобраться или подскажите что почитать.
Спасибо.