Добрый день.

С 01.01.2007 изменился порядок оплаты б/л по уходу за детьми и взрослыми членами семьи ФЗ255. Теперь в году оплачивается только определенное количество дней. SAP в ноте 1017960 в качестве решения предлагает использовать механизм Time Quotas.
Как его использовать, как настроить отсутствие, чтобы после использования определенного количества дней в году это отсутствие не оплачивалось?

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

Хотелось бы получить оценку данных вариантов, и почитать Ваши предложения по данному вопросу.

Уже есть тема
http://sapboard.ru/forum/viewtopic.php?t=21740

Тема есть, но там другие моменты рассматриваются

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

Вот тока как разрулить за каким ребенком уход и какой лимит списывать - тока ABAPом ...

а мы пока склоняемся к использованию "Family Member/Dependents" - 0021 ИТ, расширение 2001 ИТ на 2 поля из 0021, V0 - присвоения...
понятно, что тут тоже абап, но нам показалось, что так логичнее.
особенно в случае, когда несколько детей

При реализации варианта с двумя лимитами столкнулся со следующей проблемой:
В системе уже используется лимит для основного ежегодного отпуска, с группой правил выбора типа лимита 33, которой использует период действия «дата начало основного отпуска» = дате приема на работу,
Т.к. новые лимиты должны выдаваться на календарный год и соответственно период действия равен календарному году, я создал еще одну группу правил выбора типа лимита с кодом отличным от 33. Но возникает проблема QUOMO можно присвоить только одно возвращаемое значение.
Как решить данное противоречие?

Я так понимаю - проблема с "интервалом действия/использования" по умолчанию?
Тогда так как новые лимиты создаются на календарный год, то никакое динамическое определение даты не нужно и достаточно просто задавать период при 01.01 - 31.12 при запуске отчета генерации лимитов. В этом случае даты по умолчанию подставляться не будут.

После проведения тестовых настроек для вариантов описаны в первом сообщений делаю вывод в о том что оба варианта имеют значительные недостатки.
Первый вариант предполагает много ручной работы по отслеживанию лимитов.
Второй вариант при реализации в полном объеме предполагает большое количество отсутствий и лимитов. Кол. отсутствий и лимитов рассчитывал по следующему алгоритму. (количество дней в календарном году делим на количество полагающихся лимитов на год по каждому случаю, получаемый результат равен максимальному количеству возможных случаев.)

Также т.к. при реализации обоих вариантов предполагается использовать лимиты, возникает следующая проблема
Сейчас все отсутствия по временной не трудоспособности использую экран 2008 (V_554S_O), при настройки отсутствий с использованием лимитов в систем доступен только экран 2001, следовательно, становятся не доступны определенные поля имеющееся в экране 2008 и предназначенные для ввода в систему критично важных данных (номер б/л, серия б/л и т.д.), также теряется логика «период продолжения выплаты заболевания».

Поэтому хотелось почитать более подробное описания решения предлагаемое Абу.

А может не заморачиваться с лимитами и сделать проще - порядковый номер ребенка, как уже написали, тянуть из расширения ИТ 2001, остальные данные хранить в каком-нить техническом виде оплаты и тянуть через RT из периода в период - анализ LRT + накопление (если бы можно было строго привязать к 01.01.XXXX-31.12.XXXX, подошла бы и CRT):

со структурой:

RTE = номер ребенка
NUM = число оплаченных дней больничного
AMT = число месяцев, отработанных в календарном году данным сотрудником - после 12 обнулять, и NUM тоже. Я так понимаю, календарный год - что-то типа отпускного года.

Начальных значений ВО столько же, сколько детей в ИТ 0021. Вид оплаты с больничным, соответственно, в схеме корректировать на предмет разницы технического ВО с 45 дн., сплитуя перед расчетом на оплачиваемую и неоплачиваемую части. Возможно, в связи с этим понадобятся еще изменения в расширении ф-ции YSI00(RUSI0), не знаю, пока не настраивала (но скорее всего не понадобятся), просто появилась такая идея.

P.S. Кстати, для принятых на работу до 01.01.2007 откуда этот календарный год отсчитывается - с даты начала действия закона, т.е. с 1 января, получается?

Небольшое уточнение: разбивать на оплачиваемую и неоплачиваемую части, естессно, после кумуляции и расчета средних, перед окончательным расчетом в YSI00/RUSI0. В неоплачиваемой в AMT забивать 0.

Спасибо за ответы и развитие темы!

Насколько я понял из предлагаемого решения, если учитывать все возможные случаи:
в случае ухода за больным ребенком в возрасте до 7 лет,
в случае ухода за больным ребенком в возрасте до 7 лет в особых случаях,
в случае ухода за больным ребенком в возрасте от 7 до 15 лет,
в случае ухода за больным ребенком в возрасте от 7 до 15 лет,
в случае уход за ребенком-инвалидом до 15лет, особые заболевания,
в остальных случаях ухода за больным членом семьи

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

В случае ухода за больным ребенком в возрасте до 7 лет /Лимит по закону 60/ Максимально возможное количество отсутствий 6
В случае ухода за больным ребенком в возрасте до 7 лет по списку/Лимит по закону 90/ Максимально возможное количество отсутствий 4
В случае ухода за больным ребенком в возрасте от 7 до 15 лет/Лимит по закону45/ Максимально возможное количество отсутствий 8
В случае уход за ребенком-инвалидом до 15лет, особые заболевание /Лимит по закону120/ Максимально возможное количество отсутствий 3
В остальных случаях ухода за больным членом семьи /Лимит по закону30/ Максимально возможное количество отсутствий 12

Итого: 33


ВО для отсутствий будет 33, плюс 33 кумулятивных ВО, всего 66?

Не слишком много?

BVM177
Зачем 66, для каждого вида больничного свой вид оплаты и соответствующий лимиту кумулятивный ВО - этого достаточно.

А вообще мне уже дурно от этих нововведений ФСС. Мало того, что им приспичило что-то принципиально менять ровно под новый год, когда с этими праздниками и так мало времени остается. Так еще и было бы из-за чего все это затевать - можно подумать, бешеные бабки платят по б/листам. Это ограничение 16125 р. вообще маразм, как будто больному человеку деньги нужны меньше, чем здоровому. Особенно если серьезно чем-то болен и нужно покупать дорогущие лекарства

да чего в нем непонятного-то?
создал новый экран (2001 ИТ не расширяется), таблицу, в которой храню поля из 0021 ИТ - подтип и порядковый номер + еще два поля (чек-боксы) для особого списка отсутствий и "амбулаторное лечение".
все.

такое решение нравится тем, что я всегда могу отследить по уходу за кем конкретно был больничный. + напишу логику для схем/правил расчета з/п. + хочу сделать свои строки в V0 для отчетности.
а лимиты однозначно не нравятся - в законе же прямо написано: "при уходе за этим", а как "этого" отследить-то в лимитах я не знаю.

по ВО пока не все понятно - какие и сколько. ясно, что их будет не 1-2 - это же оплата самого отсутствия и годовые кумуляции дней.

Кстати, знакомые кадровики говорят, что все-таки календарным годом в данном случае считается с 1 января по 31 декабря для всех сотрудников (см.выше), но что делать с принятыми в середине года и исчерпавшими этот лимит на предыдущем месте работы, никому не известно... в законе фигурирует только слово "календарный" с уточнением "столько-то календарных дней по трудовому договору" лишь в отдельных случаях. Кто-нибудь знает наверняка?

Добрый день.

Согласно NOTE 1017960, был выполнены следующий пунк.

Function RUSI0 (YSI00) is corrected for supporting calendar day calculation process. Another change is related to seniority calculation. Old version used date type '26' for social insurance group detect. Now this date type can be redefined by parameter RUSI0-DATE_TYPE for report HRUCALC0 (for 4.6C RPCALCY0) in table T7RURPTCST00.

но оценка процента оплаты в зависимости от стажа все равно происходит на основе '26' даты. В чем дело?