Коллеги помогите решить проблему. Есть некая Z-разработка под названием сводный отчет. Для этого отчета выборка формируется с помощью стандартного экрана в котором выбираются как обычно ТН, ЕР, группы, категории, юрлица и так далее. Конкретно проблема при переходе сотрудника в расчетном периоде из одной категории в другую. То есть если брать сводный отчет по ЕР и сумму сводных отчетов по категориям то цифры не бьются при условии перехода человека из одной категории в другую. Человек попадает и в ту категорию из которой вышел и в ту в которую попал, тем самым задваивая суммы. В событиях программы это выглядит так
INITIALIZATION.
*^^^^^^^^^^^^^^^^^^
MOVE icon_expand TO bt_set.
PERFORM fill_init_vals.


AT SELECTION-SCREEN OUTPUT.
*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
LOOP AT SCREEN.
CASE screen-group1.
WHEN 'SET'.
IF bt_set EQ icon_expand.
screen-active = 0.
ELSE.
screen-active = 1.
ENDIF.
ENDCASE.
MODIFY SCREEN.
ENDLOOP.


AT SELECTION-SCREEN.
*^^^^^^^^^^^^^^^^^^^
CASE sy-ucomm.
WHEN 'SET'.
PERFORM sets_display.
ENDCASE.


START-OF-SELECTION.
*^^^^^^^^^^^^^^^^^^
gv_perio = pn-begda(6).


GET peras.

После обработки строки gv_perio = pn-begda(6). полю pegas-PERNR присваивается табельный номер, если он соответсвует условию выборки. Но каким образом происходит это присвоение мне не ясно. Там запускаются какие-то стандартные методы и badi , но под дебагером выяснить не удается.

Требуется каким-то образом изменить обработку ТН так чтобы его принадлежность к выборке считалась не по всему периоду, а по последней дате периода. То есть например принадлежность к категории считалась по тому к какой категории сострудник принадлежал на конец периода.

Посоветуйте где копать как настраивать принадлежность сотрудникоов

Скорее всего, вы формируете внутр.таблицу (между событиями START-OF-SELECTION и END-OF-SELECTION), которая по сути и является вашим отчетом. Удалите из этой таблицы лишние строки, где-нибудь после события END-OF-SELECTION, и тогда у вас должно все показывать ок.

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

После gv_perio = pn-begda(6). если pegas-PERNR присвоен табельный номер - выполняется переход на GET peras. и идет формирование таблицы из кластера, а если ТН соответсвующий всем условиям не найден то идет переход на END-OF-SELECTION. Так как это своб по начислениям-удержаниям - там сплитования нет. Конечно можно вставить проверку перед GET peras, но это явно не красиво. Хотелось бы понять где обрабатываются данные внесенные на экран.

Наверное мне бы очень помогла информация каким образом осуществляется прямой переход на события, например GET peras

Попробую объяснить еще раз - раздели чтение персональных данных и чтение данных из кластера. Т.е., между GET PERAS и END-OF-SELECTION сформируй таблицу, которая будет содержать например только ТабНомера (ну и еще какие нить нужные при последующей обработке поля). А сразу же после END-OF-SELECTION запускай цикл по этой таблице, и для каждого последнего нового ТабНомера (например, через AT END OF PERNR) читай кластер. Т.е. выборку из кластера делай уже после того как отработает ЛБД и ты сможешь выделить последнюю запись по каждому отдельному таб.номеру.

См., например RPCDEPBSVANO_MASS_PRINT

Да, спасибо, я вашу мысль понял и так и почти таким путем и пошел. Плохо то что не удалось вклиниться в стандарную обработку, чтобы исключить лишние ТН еще до GET PERAS в момент их присвоения в peras.