никого не призывают так делать, но если вы уверены в том, что 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 выставили в частности и по нашему инциденту.
На текущий момент все проблемы, с которыми мы столкнулись, с неконсистентностью сплитов, решили в стандарте.