Подскажите кто как поступает в следующей специфической ситуации при увольнении.
Имеется право на ежегодный отпуск состоящее из нескольких видов лимита:
- основной
- дополнительный
...

При сокращении лимитов система последовательно их сокращает в порядке приоритета заданного настройкой. Однако при увольнение система сокращает каждый лимит пропорционально фактически отработанному времени. Иногда встречается ситуация, что когда человек взял отпуск наперёд, а затем увольняется, то система показывает, что он перегулял отпуск. Причём он перегулял какой-то конкретный лимит, хотя и уложился суммарно в заработанное им право на отпуск.
Например.
человеку положено 24 осн. + 7 доп. дней отпуска = 31 в сумме
Он взял отпуск в 26 дней наперёд. Система спишет это как 24 осн. + 2 доп. При увольнении когда будет происходить ограничение неиспользованных отпусков система сообщит что, человек заработал 20 основного, а использовал 24 нужно поправить..., а дополнительного отпуска использовал 2, а заработал 6. Т.е. суммарно перерасхода нет. Но и остатка не должно оставаться, а он остаётся.

После сокращения квот нужно пересохранить отпуск и произойдет перераспределение дней по квотам

Такой вариант не сработает.

Т.к. лимит с перерасходом мы вынуждены будем сбросить для того чтобы закончить операцию ограничения т.е. мы откатим значение в состояние перерасхода. И при попытке пересохранить отпуск получим туже ситуация что и в начале.

To qwety:
Добрый день!
Подскажите удалось ли победить данную проблему. Если удалось, то не поделитесь опытом?
Спасибо!

Не дождавшись ответа придума свой вариант, может кому поможет:
Для такой ситации сделал следующее:
1. Разрешил отрицательное использование нужных мне типов лимитов (при этом не включал в положение о подсчёте правило использования сверх полагающегося количества дней, чтобы избежать отрицательного использования отпуска). При такой настройке если ограничиваешь лимиты, при увольнении, и получается отричательное использование, то система не ругается и даёт сохранить запись ИТ2006. При попытке создать ИТ0416 и компенсировать дней больше чем положено система ругается и не даёт компенсировать больше положенного. Как раз то что нужно;
2. Далее написал динамику после сохранения 0298 инфо-типа (ну и соответственно после ограничения ИТ2006) в которой анализируются все записи ИТ2006 до контрольной даты, высчитывается разница по всем типам лимитов положенных к компенсации, а так же дата ИТ0416 сдвигается на 1 ден назад (всё это делается с помощью абапа в самописных ФМ для динамики), так как по базовой настроке дата мероприятия увольнения всегда сдвигается на день вперёд, что нам не подходит так как не верно будет считаться средние в расчёте зп. Если разница положительная, то создаю запись ИТ0416 и в поле ANZHL вставляю число подлежащих компенсации дней, если отрицательная, то опять же через динамику создаётся запись в ИТ0015 с нужным ВО и количеством дней подлежащих удержанию. В итоге мы получеам в расчёте зп 2 вида оплаты если по разным типам лимитов у нас получилось и компенсаци я и удержание;
3. Написал маленькое правило Z416 и поставил его в начале подсхемы RUA1, соответственно модифицированную в YUA1:
PIT Z416 NOAB
Z416 Обнуление ВО в зависимости от подсчёта по полю NUM
*
4416 КомпенсОтпускаУволенен
NUM+ 4424
NUM?0
*
>
NUM=*
ADDWT *
4424 Возврат отпуска при увол
NUM+ 4416
NUM?0
<
ADDWT *
=
>
NUM=*
ZERO= AR
ADDWT 4416
В итоге полуем всегда на выходе или удержание или начисление или ничего.
Надеюсь кому поможет.

P.S. Проблема тут только в одном: по закону удержание нужно считать по ставке среднего последнего отпуска в период которого лимит был использован и может получиться так, что по компенсации это одно среднее, а по удержанию другое. Если сумма по удержанию и компенсации 0, то по хорошему деньги то разные и их по разному нужно считать, а мы тут схитрили и обнулили. С другой стороны с точки зрения кадров лимиты учитываются суммарно, а не по отдельности и если 0, то 0. Так что тут решение принимать Вам. Лучше в ПР сразу прописатьчто вот так и никак по другому

На всякий случай - посмотрите отчет RPTBPC10, мы его вызывали в динамическом мероприятии при увольнении , как раз для такого-же случая. Он должен перераспределить отрицательный перерасход и вызвать обратный расчет. А для удержания делается лимит , типа 90 , по которому генерируется неоплачиваемый вид оплаты . Тогда у вас получится, что весь перерасход придется на этот 90-й лимит, обратный расчет вызовет "снятие" части отпуска и получится , что он снимется как раз с тем средним, который был в момент отпуска .

В стандарте это появилось в Ehp5 , но никто не мешает попробовать реализовать самим если Ehp по каким-то причинам не стоит

http://help.sap.com/erp2005_ehp_05/help ... ontent.htm

А Т-61 при таком подходе не "поплывёт" ли...
... И Т-60 за прошлый отпуск, который пересчитался?

Не могу понять, подскажите, пожалуйста
Можно ли настройками заставить T61 считать RUAVE для полей раздела AVER не из в-периода, а из для-периода, отличного от в-периода?
Например, сотрудник увольняется в апреле. В марте у него отпуск был, а в результате ограничения лимитов при увольнении образовался перерасход.
Перераспределяем использование отпуска, в итоге пересчитывается в апреле мартовский отпуск и "снимается" кусок оплаты.
Но Т-61 анализирует только апрель, не видит изменений в марте и RUAVE, ничего не выводит в форму.
ФМ HR_RU_DAQ_AVERA вызывается с im_daq-begda и endda апрельскими, и затем проверяет считанные для-периоды результатов расчёта на равенство апрелю в моём примере.