никого не призывают так делать, но если вы уверены в том, что RUDAT у вас не переполнится, то вместо перелопачивания правил, можно сделать функцию, которую добавить перед RUCDT и EXPRT и которая пробежится по таблицам, сгенерировав отсутствующие сплиты в RUCNX.
За основу можно взять класс cl*ru*flex*split*refine*, метод get_by_result
Вроде именно он используется в отчетности для заполнения RUCNX в расчетах, в которых нет этой таблицы.

По поводу SETIN. Его скорее всего не адаптируют, т.к. SETIN просто устанавливает сплит. А предполагается, что сплит - это не самостоятельная вещь, а ссылка на какую-то таблицу расчета. Соответственно, логично управлять не только сплитом, но и записями связанной таблицы.
В целом идея здравая, но специфику клиентов не сказать, что учитывает.

Но на самом деле со всеми этими ID...8, которых может быть под миллион (гипотетически), есть один нюанс. Стандартные проводки выдерживают 99 999 записей в RT.

Проблема в том, что если пропуски в RUCNX возникли, то нельзя быть уверенным в том, что расчет был выполнен без ошибок. Пропуск в RUCNX это не просто косметический дефект. Он означает, что где-то работа со сплитами могла быть выполнена с ошибкой, и обработка могла быть выполнена не так, как должна была быть.

Аналогичная проблема, пока сделали расширение в RUOC1.

Добрый день!
В суть проблемы не вникал (поэтому не уверен что поможет), просто фиксирую, что исправления в ноте 3163724 - PIT: inconsistent content in RUCNX and payroll results table предназначены для озвученных вами объектов.

Коллеги, приветствую.
Ноту 3163724 выставили в частности и по нашему инциденту.
На текущий момент все проблемы, с которыми мы столкнулись, с неконсистентностью сплитов, решили в стандарте.

RoustR, приветствую!
Было ли предоставлено решение озвученной проблемы? Столкнулись с такой ситуацией, которая усугубляется еще и тем, что в результате такого поведения у /322 не проставился сплит CNTR1 на TAX. И, как следствие, не сгенерировался /32E в RUTXD MDDE.

Приветствую! А вызов RUSPRO* не помогает?

rass, а как обозначенная Вами операция могла помочь (действий над сплитами не производилось, поэтому - нет, такой вариант не рассматривался)? Проблема наблюдается в момент работы функции RURTR, как и описывает RoustR. Изначально у сотрудника сплитованный на периоды кластер, вторая часть которого не содержит налогооблагаемых выплат (RUDAT, TAX и RUCNX практически пустые). Данный период пересчитывается без сплитования (это стандартное поведение, по сути), последствия и поведение в момент обработки RURTR в соответствии с описанием RoustR.

Ясно, я неправильно поняла суть бага.
Мы пока с таким не столкнулись.
Спасибо за раъяснения.

Обнаружил еще одну ошибку в введении механизма RUCNX. Нас от поддержки SAP отключили, поэтому не знаю исправлена ли она на данный момент, но на всякий случай напишу сюда. Вдруг кому-то полезно будет.

В работе функции RURTR с параметром OC есть шаг переноса сумм удержанного НДФЛ из межрасчета в рег.расчет по схеме /322 -> /P22. За это отвечает процедура process_values_74_123. Так вот, эта процедура не адаптирована под RUCNX - записи из ORT, которые упакованы относительно ORUCNX, переносятся в IT/RT без перепаковки относительно RUCNX. Значит для перенесенных записей в RUCNX может не оказаться необходимого ключа.

Это не вызывает проблем пока RUDAT не переполнен - сплиты в ORT на TAX / RUDAT в такой момент адаптированы под таблицы текущего расчета. Может лишь появиться сообщение, что нет подходящего ключа в RUCNX, но при этом ключ будет самостоятельно правильно восстановлен. Но если RUDAT был переполнен, то это приведет к уже ошибки.

Проблема должна появляться в случае выполнения межрасчета 0105 с глубоким перерасчетом, когда RUDAT переполнен.

Исправление очень простое - при переносе записи из ORT нужно ее распаковать относительно ORUCNX и упаковать относительно RUCNX.