Коллеги, приветствую.

Исходные данные 1:
-в инфо-группе прописан ИТ0008
-в динамике, на processing type 06, для ИТ0008 была повешена подпрограмма, которая, в зависимости от определенных условий задавала или нет RP50D-FLAG1
-в динамике, если задан флаг, была прописана строчка: INSS,0014,,,(PSPAR-BEGDA),(PSPAR-ENDDA) - то есть, чтобы с теми же периодами, что и ИТ0008, создавалась запись в ИТ0014.
Итог:
-флаг заполняется, а ИТ0014 - не создаётся.

Решил пойти иным путём.

Исходные данные 2:
-в инфо-группе прописан ИТ0008
-в динамике, на processing type 06, для ИТ0008 была повешена подпрограмма, в которой, в зависимости от определенных условий, с помощью HR_INFOTYPE_OPERATION создавался ИТ0014

запуск ФМ выглядит так:



Итог:
-Инфо-группа отрабатывает. Но, при попытке выйти из ИТ0000 - PA30 падает в DUMP. Тип ошибки - COMMIT_IN_PERFORM_ON_COMMIT.

Уточнение:
- На ИТ0014 навешена Badi, в BEFORE_OUTPUT которой, в зависимости от условий, подтягивается заданный ВО
- Пляски с бубном делал следующие:
a) снимал/ставил параметр nocommit;
b) кодил/закрывал COMMIT после вызова ФМ-ника.

Что я делаю не так? Как мне всё закодить так, чтобы ни DUMP-ов не было и ИТ0014 создавался?

а можете полностью динамику выложить?

0008 06 90 P T001P-MOLGA='33'
0008 06 91 P PSPAR-MASSN='01'/X
0008 06 92 P PSPAR-MASSN='03'/X
0008 06 93 P PSPAR-MASSN='04'/X
0008 06 94 P PSPAR-MASSN='02'/X
0008 06 95 P PSPAR-MASSN='05'/X
0008 06 100 F CHECK_1222(ZDIN)
0008 06 105 P RP50D-FLAG1='X'
0008 06 110 I INSS,0014,,,(PSPAR-BEGDA),(PSPAR-ENDDA)

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

Почему то мне кажется, что так нельзя пользоваться этим ФМом. Если не путаю, то перед вызовом ФМа, нужно заблокировать табельник, а он у Вас и так заблокирован, и Вы пытаетесь сделать commit на середине мероприятия.

попробуйте убрать INSS и поставить INS, и указать подтип

По поводу использования ФМ HR_INFOTYPE_OPERATION в динамике: там есть не совсем корректный выход, по этому необходимо запускать его через submit. В таком случае выход будет именно из вызванной Z-программы, а не из MP*, и тогда все работает.

Указать подтип не могу. Я же сказал, что на этом ИТ у меня висит Badi, в которой и заполняется ВО (он же подтип).
Так же, просто INS не катит, так как он может работать и как MODIFY. А INSS - работает как безусловное добавление. Только такое и требуется. Чтобы не изменялись записи, которые уже есть на данном табельнике

Ок. Завтра, непременно, попробую вашу рекомендацию.
Вот, почему везде в САПе такие грабли? Недавно, делал рассылку уведомлений, при создании записей по определенному ИТ. Делал это через Badi. Класс рассылочный, из Badi не работал. Пришлось делать отдельную прогу и запускать её из реализующего класса SUBMIT-ом.

Коллега. Я писал, что экспериментировал разными методами. Делал чистый вызов ФМ-ника на добавление, без последующих коммитов и с заданным параметром nocommit. Все-равно был дамп.
Согласен, что выполнение COMMIT'а в данном месте, фактически, ломает LUW-процесс.

Неа, коллеги все не так. Внутри PA30 нельзя вызывать этом ФМ потому что он сам же PA30 и вызывает посредством CALL DIALOG. Это даже не LUW это просто особенности работы. Если хочется динамики используйте чистую динамику-через-абап.

То что привели выше в настройках данамики тоже не сработает. после F операции ничего больше выполняться не будет тем более операция проверки P. А должна быть последней, так как это реально выполняемый ABAP код в котором можно наворотить все что угодно (хоть туже рекурсивную динамику)

Я бы в подпрограмме которая выполняется в динамике после 0008 инфотипа заполнил бы переменную DYANMEAS (это полный аналог T588Z) и вот в этом случае выполнится абсолюьно все что Вам надо. Делали не раз и не два, и тут никакие бади не помешают. Типичный пример после создания записи 22 показываем диалог-вопрос и если подтверждаем ввод, то опять показываем 22 инфоти для ввода и так до бесконечности пока пользователь сам не прервет рекурсию, причем это работает и в процессе мероприятий - как только пользователь откажется от создание очередной записи 22 инфотипа выполнение основного мероприятия продолжиться.

Отлично. Через DYNMEAS сработало. Хвала и почёт великому гуро )))