Подскажите, пжл, может кто сталкивался... Записал пакетник. Он в цикле запускается n раз ч-з CALL TRANSACTION... .
Отрабатывает в режиме "А" без вопросов, а вот в режиме "N" всегда начиная со второй итерации ругается, что поле X на экране Y не найдено. Естеств. записано все правильно.
Разные комбинации с l_opt из OPTIONS FROM l_opt ни к чему не приводят.
Как такое может быть, руками в режиме A всегда отрабатывает, что за бред... И еще более не понятно, что при первой итерации в режиме N отлично отрабатывает... В цикле ничего не меняется/не переписывается, только подсовываются новые данные и опять запускается пакетник...

может bdc data[] забываете очищать

К сожалению нет. Проблема остается, решения найти пока не могу

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

а номер экрана в ошибке Y правильный, какой и ожидали?
в редакторе экранов правда нет такого поля?

Если в цикле начать сразу со второй итерации, пропустив первую, отработает?
Напишите дословно, какое сообщение выскакивает.

Ладно повторюсь, хотя все вроде написал в своем посте. Я же написал насчет режима пакетника, что "игрался" с параметром nobinpt.
И еще просто из любопытства - Нельзя ли подробнее про ситуации Чем же ситуация в режиме "А" МОЖЕТ отличаться от ситуации в режиме без экранов с ТЕМИ ЖЕ данными? И как можно записать пакетник, не зная логики транзакции, которую вы предлагаете поссмотреть???

Кто-нибудь может по существу подсказать что-нибудь, неужели никто не сталкивался? Транзакция из аддона IS-U... Единственное, что приходит на ум, что не успевает что-то обновиться... Тогда это непобедимо... Похоже, что надо "заворачивать" - не могу найти решения, а бапишек для того же никаких нету

Даже и не знаю, что ответить... Да, правильный. Да, такой и ожидал. Неправда, в редакторе экранов есть такое поле.



Еще тяжелее ответить. Насчет второй итерации не понял. А какая разница, если поменять данные местами? Цикл же работает в завимости от выборки, а ее результаты динамические, в отличие от результата пакетника в режиме N...
Насчет сообщения - я привел его в своем посте. Не думаю, что значения X и Y играют какую-нибудь роль.

И еще один просто попутный вопрос - может кто знает, обьясните, пожалуйста, чем режимы отличаюся А и N с технич. точки зрения, кроме времени выполнения.

Заниматься удаленной отладкой значительно труднее, чем вам, имеющим доступ к данным.
Поэтому, я впоминаю ситуации, которые возникали у меня и пытаюсь их исключить для вашего варианта.
А в ответ получаю только вопросы. Да все что спросил, может играть роль.

А она точно во второй итерации отрабатывает правильно и до конца?
Насколько я понял - транзакция стандартная - тогда может стоит рассекретить X и Y? Заодно стоит посмотреть где вызывается этот самый Y и при каких условиях.

Фу, проблема решена. Решение оказалось очень простое, а вот причина непонятна. Транзакция FP05 -> постобработка пакета платежей. В режиме N со 2 запуска пакетника (и до конца цикла) транз-ция уходила с закладки "Выяснение" (отловить это оказалось проще, чем предполагалось, спасибо товарищам) на другую. На каком этапе не знаю, да уже и все равно. Почему - не знаю. Решение - просто возвращаюсь на закладку. В режиме А такого перехода нет, что смутило сразу и смущает до сих пор. Как же такое может быть?. Всем спасибо за участие.

P.S. не думаю, что этот аддон распространен. Насчет поля:

add_bdc:
'X' 'SAPLFKZ0' '0500',
'' 'RFKZ0-KLBTW' l_betrh_txt.

Еще раз всем спасибо.

set-get параметрыОчень просто - в коде тр.FP05 понатыкано проверок на SY-BATCH eq 'X', а режим запуска 'N' - это фоновое выполнение, без отображения экранов. Вот и получается что поведение транзакции в зависимости от режима выполнения пакетника различно.Тем неменее встречается.