Доброго дня.
Подскажите пожалуйста какую нибуть конструкцию assign для операции замещения номера ОС в mseg для 241 ВД.
Стоит следующая задача.
В эксите MBCF0002 динамически с помощью бапи по условиям и предварительным проверкам создаются новые карточки ОС, на последнем вызове эксита бапиха успешно комитится. Необходимо организовать замещение номера ОС в mseg.
Подскажите рабочую конструкцию assign для замещений в записи mseg.
ASSIGN ('(SAPMM07M)mseg') TO <ms>. - не всегда замещает как мне показалось, к сожалению не уверен в корректности работы такого замещения. Может быть есть у кого рабочая надежная конструкция? наверняка уже стояли подобные задачи.

Что значит не всегда замещает? Через какую транзакцию тестируете? как объявили <ms>? Как передаете в нее значение?

1. Структура замещения такова
FIELD-SYMBOLS <ms> type mseg.
ASSIGN ('(SAPMM07M)mseg') TO <ms>.
IF <ms> IS ASSIGNED.
<ms>-ANLN1 = Новое ОС
...........
2. Тестируем через миго
3. Есть подозрение что не правильно срабатывает замещение, так как в продуктиве попадаются ДМ которые не замещены, хотя входные условия срабатывания логики корректны, потому и интересуюсь может кто нибуть подскажет надежную контрукцию замещения в данном эксите.

Надежная конструкция ASSIGN ('(SAPMM07M)MSEG-ANLN1') TO <ms>. Но я думаю что дело не в этом, потому что по Вашему коду все должно замещаться.

У Вас же уже получалось все в MIGO:
viewtopic.php?f=13&t=49700
?
См. там же есть пример ASSIGN для BADI.

Да вот вроде на этапах тестирования работало, но в продуктиве отлавливаются касяки (их немного), ветки логики срабатывания замещений вроде впорядке, грешу на само замещение, так как не замещается вцелом документ.

в методе POST бадихи замещать уже поздно так как замещение проходит, но вот проводки ложаться на замещаемые ОС, потому замещться надо до него.

>> В эксите MBCF0002 динамически с помощью бапи по условиям и предварительным проверкам создаются новые карточки ОС, на последнем вызове эксита бапиха успешно комитится.

Может коммит не успевает пройти, раз в разработке ок а в проде бывает косяк?
COMMIT WORK AND WAIT.

комитится все через
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT = 'X'
IMPORTING
RETURN = ls_return.,
на последней позиции ДМ.
не думаю что в этом проблема может быть.
Хотя согластно концепции замещаться контировка может на не на создаваемые ОС а на найденые в системе.

aivengo у Вас коммит бапихи происходит при общем коммите или как, то есть у Вас бапиха завернута в модуль обновления?

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT = 'X'
IMPORTING
RETURN = ls_return.

срабатывает на проводке последней позиции в ZXMBCU02
В модуль обновления она не завернута так как в дальнейшем после эксита происходят проверки наличия существующих ОС в системе. Потому комитится надо обязательно в нем.

Добрый день.
Если проблема в том, что данные по ОС не успевают "лечь" в БД, то мне кажется перед вызовом BAPI для создания ОС необходимо дернуть SET UPDATE TASK LOCAL ну и COMMIT WORK c WAIT'ом ессно.

И зачем же всё так сразу? Или SET UPDATE TASK LOCAL и COMMIT WORK без WAIT'а, или COMMIT WORK c WAIT'ом.

Совершенно верно! Что-то я поторопился