Добрый день, дорогие абаперы!
Может кто сталкивался с подобной проблемой.
В своей разработке для RE-FX (ОСы привязаны к объектам имущества) происходит массовая обработка списка ОС посредством вызова ФМ BAPI_FIXEDASSET_CHANGE для каждого ОСа ( меняются только временно-зависимые данные!).
Обнаружилась очень неприятная вещь - при отработке ФМ для первого ОС видимо где-то сохраняется инфа по драгметаллам (запись из таблицы GLOFAAASSETDATA).
И для всех последующих ОС перетираются данные по драг металлам!!
В параметрах ФМ нет упоминаний об этих данных.
В отладчике сидела, уже глаза на лоб вылезли, не нахожу, где вообще эта таблица затрагивается
Может посоветуете чего умного?
Заранее спасибо..

Для начала установить все самые последние ноты, если не поможет то узнать через se30 в каком месте происходит обращение к данной таблице и смотреть почему. Так же все таки проверить параметры передаваемые в ФМ, может какая-то настройка комплексных ОС мешает

Чёрный Freelancer, спасибо за se30!! И чего я раньше туда не смотрела?
Нашла - табличка там не очищается и при след. вызове ФМ она содержит данные предыдущего ОС - они и переписываются.
Ассигню (SAPLGLO_FIAA_SCREENS)it_precious_materials[] и очищаю

Проблема связана, с тем, что все вызовы БАПИ выполняются в одной и той же roll area.
Соответственно, решить проблему можно, вызывая БАПИ с использованием DESTINATION 'NONE'.
Тогда при каждом вызове для этого ФМ будет выделяться своя roll area.

Этот способ является абсолютно "легальным", в отличии от ASSIGN (PROG)DOBJ, который, как известно, является FOR INTERNAL USE ONLY

Если все же делать через ASSIGN (PROG)DOBJ, то необходимо почистить еще и переменную PRM_ALL_DELETED в той же программе,
иначе в некоторых случаях глюк остается.