Уважаемый ZGilgelad, большое спасибо за проявленный интерес.

Да, Вы правильно поняли проблему.
Дело с том, что ELIMI RY сбрасывает сплиты по группировке сотрудников (T503-ABART) и по отсутствию (AB-ABZNR), но не по рабочему месту (WPBP-APZNR).
Если изменить ELIMI RY на ELIMI RYA, то во внецикле все посчитается правильно, а в регулярном - нет, поскольку в регулярном расчете сплиты по рабочему месту ставятся корректно.
Во внецикле WPBP имеет одну запись с APZNR = 01, а в регулярном расчете - 3 записи APZNR = 01, 02, 03.

Да? Жаль. Хорошая была версия)

Посмотрите еще формы:
ruave_intermediate_calc - генерация промежуточных ВО
write_adjust_wtype_to_ruave - применение правил обработки (вызывается в форме country_specific_cumulation)
Есть еще один ФМ связанный с t7ru51av_b, но он о другом и не должен повлиять
/AV* появляются в ФМ HR_RU_AV_REFINE_RESULTS

в каких-то правилах расчета используемых для RUAVE видел проверку на категорию внецикла. Если внецикл, то устанавливается сплит SETIN A=01

Спасибо.

Как крайний вариант, думаю устанавливать/сбрасывать сплит по WPBP для внецикла.

ISergiv
Сталкивался с такой проблемой. Если Вы используете станартное правило RUWA - лучше всего написать сообщение в SAP, ибо явный косяк.
В моем случае из-за специфики клиента правило было уже не стандартным, поэтому просто добавил веточку после ELIMI RY в которой для VAKEYPAYTY A,B и прочих сбрасывал еще и ELIMI A.

Спасибо, уважаемый msv за то что откликнулись.

Кажется после трехдневной трассировки потянул ниточку...
Признак APZNR для промежуточных видов оплат берется из соответствующего признака вида оплаты для отпускных (в моем случае это кастомный вид оплаты 3000).
Осталось понять где его правильно установить, и почему функция PAB делает его равным 00 для внецикла...

Из T554C она берет APZNR , там галочка напротив вида оплаты, типа разделять по WPBP . Сравните настройку по своему 3000 ВО в регуляре и в межрасчете .

Уважаемый Dimon, благодарю Вас, за то, что подключились к решению проблемы.

Вероятно Вы абсолютно правы на счет T554C, но, к сожалению, в настройках для внецикла (O) нет опции сплитования (SPL01).

Какое решение в такой ситуации будет наиболее правильным?

Вероятно, просто нужно в своем правиле ZUWA сбрасывать сплит по APZNR для внецикла?

Залезть через SE16 и поставить галку . Это такой хитрый косяк у SAP . Или стереть запись для внецикла и скопировать запись из регуляра , поставив отметку , что это внецикл .

Dimon
Спасибо за наводку, ловко SAP однако!
ISergiv
Наиболее правильное решение - стандартное. Поэтому если есть возможность выставить сообщение в SAP - сделайте это, тем самым облегчите жизнь всем консультантам которые будут спотыкаться об эту "фичу" в будущем.

Спасибо всем.

Дамы и господа,
история с кварталкой имеет продолжение...
Согласно законодательству (его комментариям), при включении в расчет среднего квартальной премии должно соблюдаться несколько требований. Часть из них была озвучена выше, но для полноты перечислю снова:
1) релевантный период (период расчета) = 12 месяцев до месяца начала отпуска;
2) если премия за один и тот же ПОКАЗАТЕЛЬ и один и тот же ОТЧЕТНЫЙ ПЕРИОД выплачивалась частями, то в расчет должен идти одна из частей, которая является максимальной;
3) для расчета должны быть выбраны 4 квартальные премии!!! Если в релевантный период попадает 5 премий, то из них нужно выбрать 4 максимальные!!!
4) квартальные премии сокращаются, если: а) они выплачены не за фактически отработанное время, б) отчетный период, за который они выплачены неполностью попадает в релевантный период.

Рассмотрим конкретную ситуацию.
Сотрудник идет в отпуск в феврале 2016 года, релевантный период с 01.02.2015 по 31.01.2016.
Сотрудник отработал 2015 не полностью.
Сотрудник получал квартальные премии:
за 4 квартал 2014 года: 1 часть 31.01.2015 = 10000 руб, 2 часть 30.03.2015 = 5000 руб;
за 1 квартал 2015 года: 31.05.2015 = 7000 руб;
за 2 квартал 2015 года: 1 часть 31.07.2015 = 3000 руб, 2 часть 30.09.2015 = 4000 руб;
за 3 квартал 2015 года: 31.10.2016 = 1000 руб;
за 4 квартал 2015 года: 31.01.2016 = 5000 руб.

В релевантный период попадают следующие премии:
за 4 квартал 2014 года: 2 часть 30.03.2015 = 5000 руб;
за 1 квартал 2015 года: 31.05.2015 = 7000 руб;
за 2 квартал 2015 года: 1 часть 31.07.2015 = 3000 руб, 2 часть 30.09.2015 = 4000 руб;
за 3 квартал 2015 года: 31.10.2016 = 1000 руб;
за 4 квартал 2015 года: 31.01.2016 = 5000 руб.

Согласно второму правилу необходимо выбрать максимумы (ФМ HR_RU_AV_REFINE_RESULTS):
НО!!! за 4 квартал 2014 года НЕ нужно выбирать максимум, поскольку в релевантный период попала только 1 часть!!!
Итак, после определения максимумов должно получиться следующее:
за 4 квартал 2014 года: 2 часть 30.03.2015 = 5000 руб;
за 1 квартал 2015 года: 31.05.2015 = 7000 руб;
за 2 квартал 2015 года: 2 часть 30.09.2015 = 4000 руб;
за 3 квартал 2015 года: 31.10.2016 = 1000 руб;
за 4 квартал 2015 года: 31.01.2016 = 5000 руб.

Теперь нужно выполнить правило три - выбрать максимумы:
за 4 квартал 2014 года: 2 часть 30.03.2015 = 5000 руб;
за 1 квартал 2015 года: 31.05.2015 = 7000 руб;
за 2 квартал 2015 года: 2 часть 30.09.2015 = 4000 руб;
за 4 квартал 2015 года: 31.01.2016 = 5000 руб.

Теперь нужно выполнить четвертое правило, поскольку сотрудник отработал год не полностью (или премии выплачены не за фактически отработанное время):
за 4 квартал 2014 года: 2 часть 30.03.2015 = 4500 руб; СОКРАЩЕНА!!!
за 1 квартал 2015 года: 31.05.2015 = 6000 руб; СОКРАЩЕНА!!!
за 2 квартал 2015 года: 2 часть 30.09.2015 = 4000 руб;
за 4 квартал 2015 года: 31.01.2016 = 5000 руб.

Как это реализовать в SAP?

ФМ HR_RU_AV_REFINE_RESULTS просто выбирает максимумы для всех расчетов по человеку, а нам, в некоторых случаях не нужно этого делать, например для кварталки за 4 кв. 2014 года. Для этого внутри ФМ мы должны иметь уже определенный релевантный период.
Как его получить?

4 максимальные премии нужно выбрать уже после получения всем максимумов в разрезе периодов, опять таки имея уже определенный релевантный период. Где выполнить такую обработку?

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

Добавил пока в энхансмент ФМ ...REFINE_RESULTS такую строку:

* отбрасываем все расчеты, не входящие в релевантный период
CHECK ( ( AV_PERIOD_BEGDA(4) * 12 + AV_PERIOD_BEGDA+4(2) ) - ( <zlt_result>-evp-fpbeg(4) * 12 + <zlt_result>-evp-fpbeg+4(2) ) ) LE 12.

Плюс логику для выбора максималок:

* Удаляем минимальные суммы в случае, если в расчет попадают более 4 кварталок
DESCRIBE TABLE tmax LINES n.
IF n GT 4.
n = n - 4. "количество удаляемых премий
DO n TIMES.
CLEAR: smax.
smax-rt-betrg = 9999999999999.
LOOP AT tmax WHERE indlg = 'AQ'.
IF tmax-rt-betrg LT smax-rt-betrg.
smax = tmax.
ENDIF.
ENDLOOP.
DELETE tmax WHERE seqnr EQ smax-seqnr.
ENDDO.
ENDIF.

Всем счастья и удачи.

Дамы и господа, все равно нужна ваша помощь!
Затычка прекрасно работала, до сегодняшнего дня...
Сегодня производится расчет отпускных в феврале за март месяц (начало отпуска 03.03.2016).
Сижу и туплю. При расчете AVERA_NO_DOUBLE_DO вызывается дважды. Первый раз затычка срабатывает корректно, поскольку внутрь передается AV_PERIOD_BEGDA = '20160301'.
При втором вызове AV_PERIOD_BEGDA = '20160201' и все слетает к чертовой матери...
Не могу понять, на кой ... вызов производится дважды, и почему отличаются периоды?
Буду благодарен за любую помощь.

Ядро обработки средних может запускать несколько раз. Первый раз - общий прогон, соответствует работе стандартной функции AVERA. Второй - отдельный прогон по сплитам для текущего периода (индикатор этого прогона - флаг avest-curr = 'X').
Третий - как раз ваш случай, отпуска будущих периодов (индикатор прогона - флаг avest-sppe2 = 'X'). Выполняется процедурой ruave_sppe2_calculation. Он фактически делает моделирование расчета текущего месяца, затем получает результаты расчета из него, и запускает цикл средного еще раз (там будет опять и общий прогон и прогон текущего месяца avest-curr = 'X').

Проверить на каком этапе вы сейчас находитесь можно по атрибутам avest-curr и avest-sppe2. Так как все это обычно происходить в ФМ релевантности, то добираться до этих флагов приходиться примерно так