добрый день!
на внутренних совместителях вылезла проблема, может кто сталкивался и подскажет.

на проекте реализован расчет вн.совместителей с помощью программы HUACALCM (с некоторой модификацией для расчета оффсайкла).
в кластере для обоих табельных сидят следующие записи с периодами расчета.
P 17.07.2009 - выплата аванса
A 17.07.2009 - выплата аванса (пересчет в регулярном расчете)
A 07.2009 - регулярный расчет.

теперь, при расчете 08.2009 для внутренних совместителей пересчитывается оффсайкл 17.07.2009. и при этом совсем не пересчитывается регулярный расчет 07.2009. в кластере получается каша.

насколько успела разобраться, в HUACALC0 (который вызывается из HUACALCM) в инклуде RPCHRT09_INSERT_BONUS_RUNS_INT в табличку APER, которая содержит только период 08.2009 втупую добавляется запись с 17.07.2009.
и такая проблема с оффсайклом только для внутренних совместителей. с обычными людьми проблем нет.
может кто-нибудь что-нибудь быстро подсказать?
спасибо.

отвечу сама себе, вдруг кому пригодится.
проблема заключалась в табличке mjrrdt, где заполняется дата, с которой запускать расчет ЗП для табельного номера. и HUACALC0 в инклуде RPCHRT09_MAIN, где определялась переменная ruecktab (судя по всему, дата обратного расчета).
если для сотрудника в ИТ 0003 нет даты обратного расчета, и на экране драйвера вн.совместителей ничего не введено, то в табличке mjrrdt поле rrdat должно быть просто пустым.

Внутренние совместители на мультерасчете + offcycle - это смелый ход:-) Респект!
Есть информация(могу ошибаться), что мультирасчет(HRUCALCM) не будет поддерживаться САП-ом после выхода EHP/5 где будет локализация Сoncurrent Employment без использования мультирасчета. И поэтому если сейчас у клиента HRUCALCM, то при использовании нового решения EHP/5 внутренних совместителей придется пересматривать. Сейчас конечно ничего не поделаешь, если клиента не удается уговорить обойтись без этого.

дык, а куда же деваться, если клиенту надо и вот надо именно так.

Нередко удается договориться с клиентом, что совместители реализуются на ОДНОМ табельном. Например вся ситуация может выродиться в то что по основной работе у сотрудника берется график из ИТ0007, а график по совместительству вводится присутствиями (так однажды сделали на проекте). При этом в альтернативную оплату вводили штатную должность по совместительству.
Таким образом получалось два табеля(две формы Т-13) по одному сотруднику, но в зарплате это был один табельный(как перст). И не было проблем с расчетом налогов, перетаскиванием баз и прочих неприятностей мультирасчета.
Ну понятно оценка времени понадобилась конечно. Карточка Т-2 была тоже одна.

как вариант. а откуда брать оклад по совместительской штатной должности? из 1005 ИТ?

Оклад по совместительству вводите в ИТ0008 - надбавкой к основному. Получается есть оклад(основная работа) и надбавка(за совместительство)

ну, уже двух клиентов не удалось уговорить на такое решение. настояли на мультирасчете.
при этом у них есть внутренние совместители (которых считаем мультирасчетом), а есть простые люди, которым платится доплата за совмещение - если сотрудник часть рабочего времени своего ещё работает за того парня (т.е. перерабатывает).

Вопрос к <Екатерина Мячина>. Вы off-cycle для Украины внедреяте? В рамках HR-CEE?

Какая у клиента мотивация была, что им так понадобился мультрасчет?

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

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

да. в рамках украинского Add-On'a есть реализация off-cycle, вполне жизнеспособная.

А трудовоых договоров сколько у сотрудника которого вы мультирасчетом считаете?


?! А не подскажете с каким сервис-паком украинский появляется off-cycle ?

два. больше не пробовали, да и не было необходимости.



честно говоря, Вы меня озадачили.
поискала. первый раз слово "offcycle" фигурирует в 18м патче 19.10.2007 (HR-CEE 110_600 Service Pack 18 (SAPK-11018INHRCEE)).
в доке по украинскому Add-On'у (которая была выпущена 18.06.2007) есть какие-то крохи по настройке выплаты аванса внециклически. и о том, как себя ведут налоги при offcycle.

может мы говорим о разных вещах?

Насчет кол-ва договоров понятно. Имейте в виду что САП не будет развивать решение на HRUCALCM0 (а почему собсвенно RU? Может HUACALCM0 ?)
По поводу offcycle. У нас есть один продуктивный клиент на Украине который активно использует offcycle. Но перед началом проекта я справлялся в САП и выяснил что для Украины нет полноценного решения для offcycle. Но есть для России - в рамках EHP3/4. Клиент у нас имел офисы и в России и на Украине. И мы приняли решение реализовать offcycle для Украины так же как и для России. Для этого были сделаны модификации в украинских модулях (клиент должен отслеживать модификации по отдельному реестру) и в результате offcycle одинаково реализован для России и Украины. Другими словами EHP3/4 в части offcycle работает для Украины. Может это актуально только для случаев когда у организации есть филиалы в этих странах.