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

Вот ответ SAPHotline от 17.05:
"...учитывая отсутствие четких законодательных указаний по данному порядку
выбора необходимых годов из числа предыдущих (т.е. не всех случаях, а
лишь по заявлению сотрудника, и при этом выбор года должен быть
осуществлен таким образом, чтобы не возникло уменьшения суммы пособия),
автоматизация этого аспекта в предлагаемом в настоящее время в рамках
стандартной системы решении не осуществлялась.
При возникновении подобных ситуаций можем предложить Вам осуществлять
ручной расчет ставки, по которой будет необходимо оценивать больничный.
Возможность указания определенной из необходимых исходных данных ставки
предусмотрена в предлагаемом решении и может быть выполнена вводом ВО
SIRT в 15 ИТ (см. описание ноты 1548253).

С уважением,
Иван Андреев
Служба поддержки SAP"

Да ручной ввод ставки сразу сделали. Отчет то как выводить потом?

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

Решение САП не удачно в том, что выбор года расчета среднего жестко зашит в настройке правила расчета среднего. Да и не красиво это – на каждый год требуется свое правило расчета среднего.
Если же выбор релевантного года перенести в правило релевантности, то все становится намного гибче. Правило расчета среднего при таком подходе не зависит от года, их всего два: для прошлого и для позапрошлого годов (условно). Проверка релевантности периода происходит в правиле релевантности, то есть динамично. Это позволяет реализовать подмену года. ФМ для проверки релевантности при этом получается не намного сложнее ФМ для годовой премии.
Именно из-за самого подхода САП не реализует замену года. Все так и останется, если только какой-то крупный клиент не продавит.

Для самостоятельно решения задчаи подмены можно предложить такие варианты.

Вариант 1. Я его описал – перенос проверки периода в правило релевантности. Настройка становится проще – один раз настроил и забыл. Минус – решение становится не похожим на стандартное.

Вариант 2. Полу-хакерский. В ФМ релевантности передается структура RESULTS, в которую загружены рассматриваемые периоды. При первом вызове ФМ можно выполнить подмену года, то есть удалить из RESULTS результаты расчетов, которые загрузила система, и загрузить свои.

Вариант 3. Ну и вариант в духе решения САП. Создать правила расчета среднего на прошлые года и активировать их использование в случае необходимости подмены года

1. Первый вариант на первый взгляд красив. А если бухгалтера будут вводить в ИТ293 суммы за другие года, то как должно отработать правило релевантности?
САП я так понимаю исходил из отсутствия времени на нормальную разработку, поэтому решение полуколхозное.

Это не релевантность. Доход другого работодателя просто добавляется в правиле конечной обработке правила расчета среднего.

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

К слову сказать, у нас расчет среднего срабатывает на каждый случай больничного, заморозка не используется. Это сделано из-за z-отчета, которые формирует расшифровку расчета среднего. Если использовать заморозку, то отчет бы не работал (нет расчета среднего). Отчет нужен. Проще запускать расчет среднего на каждое событие, чем переделовать отчет или объяснять пользователям -смотри первый больничный в этом году .


Я бы не сказал, что оно полуколхозное. Просто не все тонкости учли. Не обязательно же сразу все сделать. Доделали бы через месяц. Но саму возможность нужно было сразу закладывать. И это требование бы диктовало бы способ реализации.

А сейчас там нужно либо все переделывать, либо извернуться как-то. Что-нибудь и сей час можно придумать, но это будет именно "изворот".

Например, можно сделать так. Вот правило расчета среднего IL10. Для 2011 года в нем указано число рассматриваемых периодов 24. Увеличим это число, скажем до 72 (5 лет + 1, это максимальное расстояние сдвига).
В ФМ релевантности делаем изменения. Если пользователь ввел замену года, скажем с 2010 на 2008, то просто в ФМ отмечаем периоды 2008 года, вместо 2010 года. Все, это будет работать, для IL10 вместо 2010 года соберется 2008. Да, еще нужно разобраться с данными ИТ0293.
Только смысл существования кучи видов оплат и правил на каждый год теряется.

RoustR, а как определять на какой год заменяем данные?
Например, данные должны браться из 2007, 2008 года вместо 2009, 2010.
У вас есть какое-то решение?
Вводить вспомогательные ВО?

Вы должны заложить возможность выбора обоих периодов, т.к. сотрудник может попросить посчитать исходя из 2005 и 2009. Нигде не написано, что в заявлении должны быть подряд 2 года.

Я делал так. Завел 2 вида оплат "замена прошлого года" и "замена позапрошлого" года. Эти виды оплат вводятся в ИТ0015/0014. В поле "Кол-во" вводится год, на который происходит замена. ФМ релевантности реагируют на этих видыоплат, делая замену года, если они есть. На подмену реагирует и выбор года дохода из ИТ0293.

Логика работы видов оплат относительная, замена года выполняется в зависимости от года, в котором введен вид оплат. Это позволяет не заводить новые виды для каждого года. Сейчас 2011 год, прошлый год - это 2010. Если нужно заменить 2010 год на 2008, вводим вид "замена прошлого года" и ставим в нем "2008".

Выбор ИТ 0015/0014 зависит от организационный моментов. По логике, сотрудник должен подавать заявление о замене года на каждое событие (типа, на отпуск по беремености отдельно, на отпуск по уходу за ребенком - отдельно). Если реализуем такую логику, то делаем ввод в ИТ0015 в месяце начала события. Если хотим облегчить труд бухгалтеру и немного отойти от правил, то можно реализовать ввод в ИТ0014. Тогда замену можно выполнять на большой период, например на весь год.

Замена года выполняется независимо. Можно заменить один год, можно заменить два года. Выбранные года могут не идти друг за другом. Только добавил проверку, чтобы не выбрали один год дважды.

Друзья, кто нашёл ветку поиском, - кастомные решения уже неактуальны.
см Note 1617139 - HR-RU: New Algorithm of SI Compensation Payments Since 2011

У нас не работает эта функция.
Все необходимые настройки выполнены; инфо-тип 3273 заполнен. В отладчике операции RUABL таблица p3273 пустая, не прочитано ни одной записи. Подскажите, пожалуйста, где и каким образом производится чтение ИТ3273 в вашей системе?

Там нет явного считывания.
Есть объявление INFOTYPES: 3273 occurs 2.. Оно означает что будет создана таблица p3273, куда логическая база данных сама положит записи ИТ с учетом временной выборки и настроек прав доступа. Когда происходит событие GET PERNR, эта структура уже будет заполнена.

Странно однако не заполняется. В своем отчете попробовала объявить, в GET PERNR таблица заполнилась. А в расчете почему не заполняется?

Ну, проверьте на GET PERNR в расчете. Если p3273 пустая, то вероятно есть какие-то проблемы с полномочиями.
Если - нет, то очищается где-то уже в расчете. Причем это уже скорее всего что-то самодельное, z-кое. Просто искать нужно.