До появления подсистемы TAXDT функция RUSI0 у больничных в CNTR2 прописывал порядковый номер записи. TAXDT задействовал CNTR2 для своих целей, поэтому в коде RUSI0 появился приведенный код - если подсистема TAXDT активна, то CNTR2 не заполняем (оставляем на нужны TAXDT), в противном случае работаем как прежде. Не вижу в этом коде ничего предосудительного.
Далее упоминается CL_HRPAYRU_ADJUST_RUDAT, но не говорится в каком контексте он работает. Раз речь идет о обратном расчете, то вероятно речь идет о RURTR. Функция должна согласовать изменения дохода и определить новые даты для дельт. Где-то здесь нарушение логики работы, раз происходит обработка старого заполнения CNTR2 как ссылки на RUDAT. Там нужно смотреть.
Кроме того, в RURTR есть особая обработка больничных.
И еще один момент. Раз это больничные, то сюда может оказывать влияние подсистема ППФФС. Эта подсистема сама ведет вычисление дельт, и RURTR это учитывает. Вот пример из ее кода
Code:
* CNTR2 Set to in-period to calculate delta
IF ltr_cntr2_sick IS NOT INITIAL AND <ls_it>-cntr2 IN ltr_cntr2_sick.
"for SICK delta already calculated and CNTR2 split already adjusted
READ TABLE rudat INTO ls_rudat WITH KEY cntr2 = <ls_it>-cntr2.
ELSE.
"CNTR2 Set to in-period to calculate delta
PERFORM oprudat_core_i USING <ls_it> abap_false abap_true wpbp[] ab[] CHANGING ls_rudat.
ENDIF.
Короче, вариантов, где что-то может пойти не так, масса. Разбираться нужно в конкретной системе.