RoustR, а какое Вы расширение делали 33 OKT?
Мы попытались настроить свой признак, который работает с 0006 инфотипом "Адреса" (новый подтип адреса для платежей НДФЛ вести в каждом сотруднике, потому что у нас несколько налоговых, да, еще и изменение в середине года). Но резюме программиста по этой идее отрицательное. HRULNDFL не сможет работать ни с чем другим кроме структуры 0001.

Через assign до внутренних переменных отчета добирались? помоему признак вызывается в нескольких местах с разным переменным окружением, разве нет?

Нет, просто модификаций. Мне было проще, у нас в этом месте уже была вставка, поэтому мне даже придумывать ничего не надо было.
Через assign даже не думал. Это все-таки происходит не в самом HRULNDFL, а в классе CL_HRPAYRU_PLTAXRUN, общение с которым происходит через интерфейс. К внутренней "кухни" получится так добраться?

2tantsa
Там даже не сам ИТ0001 используется, а таблица WPBP из расчета. И действительно "пихать" туда, скажем, ИТ0006 не стоит.

Вообще, в чем основная проблема? В том, что САП предусмотрел слишком мало информации, которая доступна для признака 33OKT. Подход был бы намного гибче, если бы признаку было передано: ТН; в-период, для которого происходит определение; дата периода WPBP-BEGDA (это как расширенный вариант для-период, признак вызывается для записи WPBP).

Перед вызовом признака делаю вставку, в которой сохраняю необходимую мне информацию - ТН, INPER, WPBP-BEGDA. Расширять структуру PRUMY, которую использует признак 33OKT, я не стал, поэтому сохраняю эту информацию просто в памяти.

Далее все укладывается в стандарт. В признаке 33ОКТ в дерево принятия решения вставляется вызов подпрограммы. Пишется эта программа, которая получает структуру PRUMY, и в которой можно восстановить значение дополнительных параметров, которые мы сохранили ранее.
Все, теперь можно реализовывать свою логику. Хотите «прицепить» ИТ0006? Пожалуйста, ТН и дата есть, нужно лишь считать ИТ0006.
Если есть желание сохранить возможность настраивать признак на основе дерева принятия решения с расширенной информаций (то есть делать потом настройки без участия ABAP-ра), то создается свой Z-признак, который можно вызвать из этой подпрограммы. Так можно реализовать проверку: до реорганизации было одно значение ОКАТО, после – другое без ABAPа.

Еще вариант – написать в САП с просьбой расширить структуру для признака PE03 . Только писать нужно сразу описывая решение. Может быть, в таком случае согласятся сделать.

ясно, думал что есть возможность без модификации отчета подломить логику.
На мой взгляд, в общем случае, нужно дробить расчет зп (например мероприятием), в случае разделения НДФЛ в середине месяца, поэтому достаточно признаку в структуру передавать дату сплитования расчета. Не понятно почему сапу трудно добавить такую мелочь в стандартный отчет.

RoustR, Macros, большое спасибо за поддержку!
Мы пошли немного другим путем: сделали копию программы, открыв на селекционном экране даты
BEGDA, ENNDA. И еще донастроили возможность выбора с селекционного экрана Юр.лица из T7RU9A напрямую. Признак 33OKT сейчас не используем.
Сформировали справки с 01.01.2012 по 30.06.2012 и с 01.07.2012 по 31.12.2012 в разные налоговые и на разные юр.лица.
У нас с счастью не было сотрудников, которых надо разбивать внутри месяца.
Конечно, это решение не идеальное, потому что в будущем надо помнить, что сотруднику делали 2 справки в разные налоговые, т.к. эта информация нигде не хранится сейчас.