Добрый день!
Если отсутствия настроены на списание целого лимита, то он всегда будет использоваться целыми.
Если лимита будет не достаточно, то он будет заимствоваться с будущего лимита (главное чтобы дата начала использования позволяла его использовать).
Например:
Ежегодный оплачиваемый отпуск получился 27,61 (сотрудник был в административном отпуске 19 дней).
Запись лимита в ИТ2006 выглядит следующим образом:
01 Ежегодный отпуск 27,61 20 01.02.2014 31.01.2015 01.02.2014 31.12.9999
20 дней сотрудник использовал и собирается в очередной отпуск на 10 дней.
Лимита не хватает. Генерируем или создаем запись ИТ 2006 на 2015-2016 год:
01 Ежегодный отпуск 28 00 01.02.2015 31.01.2016 01.02.2015 31.12.9999.
Меняем дату использования на 01.02.2014 у лимита 2015-2016 года (можно в стандартном инкуде для программы генерации лимитов прописать логику, чтобы дата начала использования всегда устанавливалась равной дате последнего приема).
Все. Можно регистрировать отсутствие на 10 дней.
В итоге после регистрации отсутствия получаем следующую картину по лимитам:
01 Ежегодный отпуск 27,61 27,61 01.02.2014 31.01.2015 01.02.2014 31.12.9999
01 Ежегодный отпуск 28,00 02,39 01.02.2014 31.01.2015 01.02.2014 31.12.9999
При компенсации при увольнении компенсируем столько сколько положено, с нецелой частью . Если в динамике создавать запись ИТ0416 при увольнении, то можно написать свою прогу, которая будет считать и подставлять неиспользованный отпуск в поле компенсации.
У этого решения есть свои недостатки, но зато полностью на стандарте.
Если я правильно понял, то вам требуется чтобы было использовано только целое число, а остаток всегда висел. Т.е. для нашего примера так:
01 Ежегодный отпуск 27,61 27,00 01.02.2014 31.01.2015 01.02.2014 31.12.9999
01 Ежегодный отпуск 28,00 03,00 01.02.2014 31.01.2015 01.02.2014 31.12.9999
То тут кроме как Z другого варианта не вижу. Так как правила использования лимитов линейные по датам и типам лимитов.
Можно сделать обработку в оценки времени по таким лимитам и округлять последние до целого в большую или меньшую сторону, а излишки или недостатки округления скидывать в технический лимит, который будет использоваться только для компенсации. Но при этом нельзя обновлять лимит (кнопка "Значения по умолчанию" в ИТ2006 или отчет HRUTQTA0), так как все вернётся назад согласно настройкам, если опять же не подломаете.
Если обновление лимита имеет место быть, то нужно предусмотреть доп. обработку в оценке времени для таких ситуаций, чтобы случайно ещё раз не создать или дополнить технический лимит. И т.д..
Вариантов много, подводных камней ещё больше.
А вообще по хорошему лучше всегда иметь лимиты в целых частях, т.е. убедить бизнес принять правила округления до целых. Тогда будет меньше всего проблем.
ИМХО: с нецелыми остатками слишком много "веселухи"
