поле calyy имеет десятичные. Значит можно на уровне процесса расчета стажа сделать пересчет 6 мес в 0,5 года и тогда вроде как должно заработать

Остается тока в процессе расчета стажа воткнуть функцию которая бы переводила месяцы в неполные года. Но такой нет в поставке
все одно абап

За одно получили ответ - Северные САП не считает... А должен? Это вроде законодательный момент.

Ех, как там в ABAPе чего пишется

Я не смог с помощью стандарта - "ниасилил". В 4.6С вообще нет нужных таблиц для шкалы. Тем более, что % надбавки берется из соотв. поля шкалы (в 4.7), а не рассчитывается на основании данных о стажах. Пришлось вообще отказаться от моделей
Вариант с ИТ0015 не подходит - местные бухи просто не будут каждому считать руками и вводить %. Плюс пересчет достаточно сложный, напр., при переходе РКС-МКС-РКС предыдущий процент в РКС запоминается и суммируется с %, заработанным в МКС. Но это уже упоминали.
Ф-цию сделал на основе анализа ИТ0552/ИТ0041/ИТ0001, причем, для последнего настроил признак, МКС это или РКС, чтобы знать, как считать %. Ф-ция рекурсивная, считает %, начиная от пред.стажа и %.

Если, как говорится, "это кому-нибудь нужно", то могу поделиться опытом.

Система ECC 5.0
Для расчета северной надбавки используется модуль косвенной оценки 33BON вариант S.
В таблице T7RU51R для одного процесса настроены 2 шкалы для определения размера надбавки в зависимости от стажа (одна применяется если работнику 30 или менее лет (молодой специалист), вторая - если работнику более 30 лет).
Работник имеет стаж работы на севере 2 года. По шкале молодого специалиста работник достиг максимальной для своего региона 30% надбавки. Но тут ему исполняется 30 лет, и модуль косвенной надбавки начинает считать ему надбавку по шкале "немолодого" специалиста. В соответствии с этой шкалой размер надбавки опускается до 10%, а это естественно неправильно.
Подскажите пожалуйста, можно как-то заставить стандартный модуль косвенной оценки 33BON работать правильно? Или лучше свой модуль разрабатывать? Выше писали, что можно как-то подруливать минимальное начальное значение процента надбавки через ИТ 15. Но я не понял как это может помочь в случае с 33BON.

См. мой пост выше, а также дискуссию с начала топика - с помощью модуля косвенной оценки это сделать невозможно в принципе, поскольку надбавка считается по фиксированной шкале без учета многих условий. Т.е., посчитала система стаж сотрудника 3 года - берет соотв. строку из таблицы T7RU51R. При этом не учитываются перерасчеты в случае перехода из одной зоны "северности" в другую (РКС-МКС-РКС, перерывы в стаже и т.д.).
Кроме того, есть такая особенность: если сотруднику менее 30 лет, но "север" - это не первое место работы, то к нему применяется стандартная шкала, как "для тех, кому за...". Этого стандарт тоже не учитывает в принципе.
Мне пришлось на базе таблицы T7RU51R писать полностью свой ФМ, который уже эксплуатируется более двух лет - претензий пока не было (у нас, т.е., "у них" - у заказчика, считаются проценты надбавок за стаж в зонах МКС-РКС, а также в МОУ-1 и МОУ-2 - в местностях с особыми условиями). Правда, я его писал не в формате модуля косвенной оценки... Т.е., была дополнительно разработана операция расчета з/п, которая и использовала этот ФМ.

Господа, удалось ли кому-то в рамках стандарта ERP 6.0 настроить северную надбавку через варианты M или N модуля 33BON?
Не очень понимаю, как для одной шкалы бонусной модели иметь две шкалы роста надбавки (обычную и ускоренную для молодежи).

И прошу помочь разобраться с параметрами шкалы.


1 поле -- ФМ для определения начального значения.
2 -- вид оплаты, если начальное значение через ИТ15.
3 -- как из таблицы T7RU5 считывать шкалу СН
4 -- ФМ, который запускает процесс расчета, указанный в поле 5. Результат ФМ используется для чтения значения надбавки из T7RU5.
6 -- ??
7 -- ??

upd: Когда у работника происходит накопление определенного стажа работы на Севере и переход на новый процент СН, находит ли это отражение в 8 ИТ? Как, грубо говоря, кадровик может узнать текущий процент СН, или как вывести этот процент в отчет?

Сразу отвечу на вопрос о 8-м ИТ: на то она и косвенная оценка, что рассчитывает процент на контрольную дату. Это справедливо и для 8-го ИТ, и для расчёта з/п. Текущий процент можно посмотреть в 8-м ИТ, вывести в отчёт - выполнить косв. оценку на отчётную дату (ФМ - RP_EVALUATE_INDIRECTLY)

Теперь о полях в настройке. Процесс расчёта, указанный в поле (5), вызывается и в (4), и в (6). В (4) он вызывается для расчёта переменного ключа таблицы T7RUB5 (т.е., собственно расчёта стажа), а после определения значения по шкале - в (6) для расчёта "конечной даты". Т.е., берётся найденный переменный ключ из шкалы, из него вычитается текущее значение (стаж). Разница в (ГГ,ММ,ДД) прибавляется к расчётной дате. Зачем - пока ещё не понимаю. Проблема же состоит в том, что шкала в T7RUB5 работает только в целых годах, при этом кол-во месяцев или дней задать нельзя. Точнее, как заметил AlY 04.07.2007 в 12:55, можно настроить процесс расчёта стажа, чтобы он возвращал стаж в годах с дробной частью, но такого ФМ-а нет, а значит, в стандарте стаж для северных считается только в целых годах.

Поле (7) отвечает за расчёт суммы: если это поле пустое, то для вычисленного % запускается модуль косв. оценки PRZNT; если же установлено в Х, то считается, что шкала вернула СУММУ, и именно эта сумма будет отображаться в 8-м ИТ.

По поводу двух шкал (ускоренной и обычной): насколько я понимаю, в рамках стандарта их настроить невозможно, т.к. в таблице T7RUB5 нет поля "Возраст", а через признак 33BPM выбрать персональный модификатор для указания шкалы невозможно, т.к. в принзнаке неизвестно, на какую дату проводится анализ.

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


Вопрос был в том, как это выглядит на экране 8 ИТ. Мне до этого не встречались в 8 ИТ ВО, оцениваемые косвенно, с возможностью изменения во времени без создания новых записей инфо-типа. Не представлял, как это будет отражено в интерфейсе. Теперь разобрался: на экране внизу есть специальные стрелочки, с помощью которых можно смотреть периоды постоянства процента СН.


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


А это уже плохие новости. Тоже пока не вижу способа настроить отдельную шкалу для молодежи.

Настраивали ли СН для вахтовиков?

V_T7RUB2_ext и тот залоченый код, который сап приготовил для ЕХП5

Кстати, да - вопрос очень актуальный (: Поскольку стаж учитывается только фактический, то мы пока думаем делать через 552-й ИТ + присутствия. Т.е., в 552-й ИТ будем записывать "длинные" стажи с переопределением срока (напр., запись с 01.01.2008 по 31.12.2010, но стаж - 1 год 2 мес. 23 дня), а актуальный считать, отталкиваясь от присутствий. Но при таком подходе получается, что вахтовик как бы заново принимается на работу датой продуктивного старта системы. Как сделать по-другому, пока ещё не придумал.


Да, это имеет смысл. А где можно посмотреть "залоченный" код?

Ещё вопрос. Стандартная косв. оценка, работающая через вид косв.оценки M (для надбавки за сев.стаж именно её нужно использовать), в то же время может использовать ИТ 1222 (общие атрибуты ОМ). Возникает конфликт моделей оценки для вредников, работающих в условиях севера. Т.е., в атрибутах шт.должности (ИТ 1222) мы указываем модель оценки для определения % за вредные условия труда, но это значит, что мы теряем модель оценки для расчёта % СН. Как такое можно победить? Пока только "форкнули" стандартную оценку и сделали обработку своего вида косв.оценки "Y". Может, есть способы поэлегантней?

У вас на каждую вахту будет создаваться запись ИТ 2002? В принципе, наверное, вариант.
Мы хотим по данным кластера временных данных смены считать. Пока в процессе. А начальные данные (на дату старта) можно закинуть в тот же 552 ИТ и настроить два правила выбора (присутствия + начальные данные).


Возрастные примочки можно увидеть в методе GET_PMCODE класса CL_IM_HR_IV_33BON плюс ракурс, на который указал Macros.
Примочки, касающиеся шкалы СН в дробных годах, находятся в ФМ HR_RU_BMSCALE_NORT*.
Легко распознаются по коду
Хотим использовать этот код пока без установки EhP5. Есть способ накатить это небольшим пакетом? Пока найти этот пакет не получилось.
Скопировали класс CL_IM_HR_IV_33BON в Z, боремся с функциями HR_RU_BMSCALE_NORT*, у которых в интерфейсе жестко прописан класс CL_IM_HR_IV_33BON. Пытаемся переучить на Z.


Вредников не настраивал. Неужели там действительно возникает конфликт? Ведь одновременно могут быть несколько сценариев атрибутов по несколько атрибутов в каждом. На крайний случай для северки можно использовать вариант N.

Т.е., АВАР? А если по присутствиям создать процес расчёта ЗПЗ? Мы так хотим выкрутиться, поскольку в случае перехода в другую БЕ на новый таб. можно будет кинуть ещё одну запись в ИТ 552 с общим стажем на вахте, зато текущий стаж не надо рассчитывать самому.

Я это обошёл наследованием от CL_IM_HR_IV_33BON - всё замечательно работает (:

Именно так - могут быть. Но используется конкретно в косв.оценке только ОДИН сценарий, к сожалению. Это делается в ветке для вида косв. оц. М: считывается ИТ1222 у орг.присвоения сотрудника (в порядке O-S-C), где находится именно тот атрибут, который прописан в параметре RUBONMODEL таблицы T7RURPTCST00 для программы IND_VAL. А сценарий, какой вид атрибута брать в качестве модели косв.оценки, прописывается в параметре RUBON. Получается, если мы задаём сценарий/атрибут, то теряем северные, если не задаём - вредность ):

По ветке N в качестве модели возвращается код объекта, который прописан в параметрах OTYPE, RELAT, RSIGN той же таблицы. Т.е., последовательно для O-S-C ищется соединение RELAT-RSIGN с объектом типа OTYPE, и если находится, то код этого объекта возвращается в кач-ве модели.

Т.е., в любом случае, не получается скрестить "ужа с ежом". BAdI для выбора модели тоже не нашёл. Обошли своим модулем с доп.видом Y, как я и писал выше.

Хороший вариант. Но ф-ции HR_RU_BMSCALE_NORT* все-равно переделывать.

А вредники у вас тоже по 33BON (m,n)? Тогда сложность осознал. Но ваше решение не до конца. =)

Нашел очередную проблему с молодежной шкалой, и пока не знаю, как ее решить. Скопировал EhP5 код по работе с таблицей T7RUB4_ext. Для работника в возрасте до 30 лет все работает норм., для работника старше 30 -- тоже. Но вот момент перехода с молодежной шкалы на льготную при достижении 30 лет совсем кривой: происходит понижение процента СН. Берется северный стаж на момент тридцатилетия и по общей шкале определяется процент СН. В случае, если северный стаж меньше пяти лет и больше 6 месяцев (для РКС), это всегда приводит к уменьшению процента СН, что неправильно.

Есть идеи как можно разрулить эту ситуацию?

А их в любом случае переделывать (:

Моё решение основано на наследовании. Если вид косв. оценки <> Y, вызываем метод родителя, если Y - то свой, в который и внесены правки для 30 лет и пр.

Точно T7RUB4_ext, а не T7RUB2_ext?

Да, это неправильно (: Как разрулить, зависит от решения заказчика, т.к. в законе прямо не сказано. Вариантов 2, но все они отталкиваются от %, а не от стажа:

• при переходе через 30 лет поступаем, как с вновь принятым, т.е., вычисляем "кусочный" % (напр., 42%), а затем уже во "взрослой" шкале доопределяем разницу;
• при переходе через 30 лет запоминаем последний % по шкале (напр., 40%) и во "взрослой" шкале ищем следующее повышение.

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

Вторая, конечно.

Вопрос скорее по системе, а не по нормативке. Нет уверенности, что переработки функций HR_RU_BMSCALE_NORT* будет достаточно для исправления ошибки.