Если расчетный период по табельному бьется в середине на два, например 16 марта. Т. е. в кластере в одном в-периоде есть два одинаковых "в" и "для" периодов.
И в первой части расчета у сотрудника возникает задолженность на конец периода (1.03-15.03). Которая переходит в задолженность на начало периода второй части (16.03-31.03). И если она целиком не гасится, то остатки задолженности переходят на конец периода.
Если при таком случае собрать свод начислений удержаний по такому табельному, то он, можно сказать, не контачит.
Получается следующее в отчете:
1. Задолженность на начало;
2. Задолженность на конец равная (задолженность на начало + остатки).;
Это не верно.
А правильно:
1. Задолженности на начало не должно быть вообще (т.к она возникает в середине расчетного периода 16.03-31.03).
2. Задолженность на конец - должны быть только остатки задолженности.
Свод собираю стандартной прогой: RPCLGA00

Внимание вопросs!
Получается разбивать расчетный период, например, на два нельзя?
Т. е. в одном в-периоде, всегда один в-период. Извините за тавтологию
При таком варианте любой свод нач. и удержаний хоть стандартный, хоть самописный не будет отлавливать этот момент?

Я так понимаю, вы мероприятиями бьете wpbp. А зачем задолженность у вас считается на полупериод? У нас используется подобное разделение и все ОК.

Из названия таблицы видно, что разделяем не только WPBP, а весь расчет целиком: "Индикатор мероприятия "Разделение расчета"".
Т.е. если смотреть кластер то там в колонке в-период будет в таком расчетном периоде два одинаковых значения.
А разбиваем, так как до 16 марта он был ГПХ, а после штатник!
Т. к. в стандарте есть запрос на группировку сотрудников 4. И она определяется по орг. присвоению на конец даты расчетного периода.
Правило RUPG:
D OUTWPABART
* SCOND=T IF
4 SCOND=F IF
IF RUPG Проверка ГрКс расчета <> 4?
Так вот если сотрудник был вначале в ГПХ, а затем в штате в одном периоде вот она возвращает значение - штатник. А если наоборот, то он ГПХ.
А если ГПХ, то проскакивается часть схемы (что неверно, т. к. сотрудник за пол месяца заработал оклад и т. д.)! Посмотрите в схеме RUS0.
Вот поэтому и хотим бить расчет по мероприятию! Вот тут та и возникает описанная выше проблема.

Скажите, а переход из ГПХ в штат у вас через увольнение и прием осуществляется?
Быть может не стоит заморачиваться с разбиением кластера (это потом еще не в одном месте аукнится), а просто создать новый табельный, ведь ни какие исторические данных от ГПХ не интересны штатному сотруднику.

А если уволить, а потом принять на новый табельный как ЕСН собирать? так же как и у внутренних совместителей, дравером hrucalcm?

Да, через увольнение прием, но только вот на новый табельный это конечно хорошее решение, но не подходит бизнесу. Поэтому принято решение принимать на один табельный. И уже так и принимаем, но только с 1 числа. А вот с середины нельзя было. Из-за описанной выше проблемы. Вот сейчас этим и занимаюсь, чтобы принимать с середины месяца.
Используя стандартную схему это победимо, только если вот разбивать периоды по мероприятию. Тогда возникает, по крайней мере, проблема с переходящими долгами. Может, конечно, еще что вылезет, но я пока нашел это!
Если не разбивать, то нужно переписывать стандартную схему. Т. е. нужно убирать проверку на группу сотрудников 4.
У кого была такая же проблема? Кто как выходил из нее? Убирал проверку или бил периоды. А если бил, то что тогда делать с проблемой - неверным отражением в своде переходящих долгов?

Да, через увольнение прием, но только вот на новый табельный это конечно хорошее решение, но не подходит бизнесу. Поэтому принято решение принимать на один табельный. И уже так и принимаем, но только с 1 числа. А вот с середины нельзя было. Из-за описанной выше проблемы. Вот сейчас этим и занимаюсь, чтобы принимать с середины месяца.
Используя стандартную схему это победимо, только если вот разбивать периоды по мероприятию. Тогда возникает, по крайней мере, проблема с переходящими долгами. Может, конечно, еще что вылезет, но я пока нашел это!
Если не разбивать, то нужно переписывать стандартную схему. Т. е. нужно убирать проверку на группу сотрудников 4.
У кого была такая же проблема? Кто как выходил из нее? Убирал проверку или бил периоды. А если бил, то что тогда делать с проблемой - неверным отражением в своде переходящих долгов?

Да, про регресс согласен. Думаю, Hrucalcm можно попробовать.

Вот такая ситуация:
Сотрудник был в штате, потом уволился и принялся на ГПХ, затем опять перешел в штат, а под конец года на ГПХ. Так вот налоги вы должны собрать по ЕСН по последнему его табельному ГПХ (если hrucalcm) . И вся база за год должна быть по такому сотруднику в CRT у последнего - ГПХ.
Я конечно понимаю, что это абсурд, но всякое может быть, так вот с этим HRucalcm и корректным ведением 121 ИТ и т. д. точно бухгалтера там или кадры что-нибудь напутают. И пойдет весь этот расчет в вкривь и в вкось. Так что потом сами рады не будете что связались с hrucalcm. По опыту знаю, они та простых внутренних совместителей и то умудрялись так данные завести, а потом через так месяца 3 спохватиться, что они считались не верно. А если в одном месяце база разъехалась, и спустя даже месяц это было обнаружено, то получить верный расчет из-за этого крайне сложновато будет. Нужно будет назад откатываться. Короче - это не панацея, а скорее всего ...
Но мой предыдущий вопрос никто не отменял! Буду признателен, если кто-нибудь поделится информацией.

Можно посмотреть в правилах по налоговым льготам, там как раз обрабатывается такая ситуация, чтобы льгота 2 раза не давалась . Соответственно можно сделать какую-то аналогичную проверку - и долг вычислять 1 раз , например RU-1 и RU-2 правила, там вызов RUSPL P?A как раз для этого

Dimon, но с точки зрения расчета все верно!
Если есть долг на конец, то он должен передаться дальше в следущий расчет до тех пор пока не погасится. Я же не могу посчитать его в первом расчете и не передать (для гашения) дальше, даже если этот второй расчет тот же расчетный период. А если не передавать, то он там и повиснит в первом расчете. Что неверно. Вот это и есть отличие от льготы. Как это не плачевно звучит, долги - дело переходящее! И их течение нельзя прерывать.
Проблема в отчетности. Что она не отрабатывает что расчет бьется на два и в нем есть задолженность.

Коллеги, неужели никто не сталкивался с задачей разделения расчетов и с возникающими в этом случае проблемами с долгами?!

Ключево ошибкой в данном случае есть:

Вы по определению никогда не соберете универсальной утилитой что-то связанное с законными требованиями. Для данной задачи скорее что-то свое нужно делать. А долги нормально обрабатываются в 2-NDFL

p.s. А кроме того прога RPCLGA00 считается устаревшей и не поддерживается. SAP рекомендует использовать H99CWTR0