BAPI BAPI_SALESORDER_CREATEFROMDAT2 не содержит входящих параметров чтобы сохранять в создаваемом заказе VBKD-TRATY. В иторнетах встречается предложение вместо этого использовать ФМ SD_SALESDOCUMENT_CREATE (который внутри BAPI и вызывается), передавая TRATY в BUSINESS_EX. Это бред, поскольку BUSINESS_EX это исходящий параметр. Еще есть вариант обновлять VBKD-TRATY прямым update после вызова BAPI и сохранения по полученному номеру заказа. Это в принципе вариант, но все можно сделать прямо через BAPI описанным ниже способом.
VBKD может хранить данные как на уровне позиции, так и на уровне заголовка - в последнем случае в VBKD-POSNR будут 0. От того куда нужно записать TRATY зависит, что нужно расширять и что передавать в параметрах. В примерах будет про позиции, но для заголовка тоже указано что и как.
Показаны сообщения с ярлыком BAPI. Показать все сообщения
Показаны сообщения с ярлыком BAPI. Показать все сообщения
пятница, 8 ноября 2019 г.
понедельник, 21 декабря 2015 г.
Пользовательские поля в товаре
Когда вы расширяете какую-то стандартную сущность (заказ там или товар) добавляя свои ZZ-поля в стандартные таблицы с помощью доп.структур, то часто приходится решать задачу передачи значений этих полей извне. То есть фактически надо как-то передавать эти поля в BAPI.
Стандарт для этих целей в "приличных" BAPI предусматривает поля EXTENSIONIN или типа того. Чтобы все работало на автомате, как правило, этими же ZZ-полями нужно еще расширить определенную структуру. Ну, и структуру с X-полями (это которые надо ставить в X там где реально данные)
"Внутре" данные из EXTENSIONIN перекладываюся в эту структуру (либо move-correcponging'ом, либо через assign componet), а потом и в реальную структуру таблицы.
Правда иногда этого бывает мало - надо реализовывать либо user-exit, либо BADI и перекладывать там самим.
А бывает еще веселее. Вот, например, BAPI BAPI_MATERIAL_SAVEDATA. Для создания и изменения товара. Она же используется в IDOC MATMAS (ФМ IDOC_INPUT_MATMAS_BAPI). В наличии параметры EXTENSIONIN и EXTENSIONINX. Дополнительно надо расширять структуры BAPI_TE_* и BAPI_TE_*X. Ну, то есть, если расширяли MARA то расширяем и BAPI_TE_MARA, если MARM - то BAPI_TE_MARM. Ну и так далее.
Но просто так все равно работать не будет. Стандартные поля будут обновляться, а ваши нет. Чтобы побороть это есть транзакция OMSR. В ней надо прописать поля, которые можно редактировать (там и стандартные присутствуют). Тогда они будут "проходить" через BAPI.
Подробностей не подскажу - не абаперское это дело настройки настраивать. Но куда послать консультанта вы теперь знаете =)
Стандарт для этих целей в "приличных" BAPI предусматривает поля EXTENSIONIN или типа того. Чтобы все работало на автомате, как правило, этими же ZZ-полями нужно еще расширить определенную структуру. Ну, и структуру с X-полями (это которые надо ставить в X там где реально данные)
"Внутре" данные из EXTENSIONIN перекладываюся в эту структуру (либо move-correcponging'ом, либо через assign componet), а потом и в реальную структуру таблицы.
Правда иногда этого бывает мало - надо реализовывать либо user-exit, либо BADI и перекладывать там самим.
А бывает еще веселее. Вот, например, BAPI BAPI_MATERIAL_SAVEDATA. Для создания и изменения товара. Она же используется в IDOC MATMAS (ФМ IDOC_INPUT_MATMAS_BAPI). В наличии параметры EXTENSIONIN и EXTENSIONINX. Дополнительно надо расширять структуры BAPI_TE_* и BAPI_TE_*X. Ну, то есть, если расширяли MARA то расширяем и BAPI_TE_MARA, если MARM - то BAPI_TE_MARM. Ну и так далее.
Но просто так все равно работать не будет. Стандартные поля будут обновляться, а ваши нет. Чтобы побороть это есть транзакция OMSR. В ней надо прописать поля, которые можно редактировать (там и стандартные присутствуют). Тогда они будут "проходить" через BAPI.
Подробностей не подскажу - не абаперское это дело настройки настраивать. Но куда послать консультанта вы теперь знаете =)
Подписаться на:
Сообщения (Atom)