Всем доброго дня.

Стоит передо мною следующая задача: при сохранении заказа в VA01/VA02 внести кое-какие изменения в конфигурацию позиций (имеющихся и добавляемых). Использовать для этих целей предполагается USEREXIT_SAVE_DOCUMENT_PREPARE в SAPMV45A.

Изначально консультантом было предложено использовать BAPI_SALESORDER_CHANGE, но, судя по всему, этот ФМ сам дергает программу SAPMV45A, что приводит либо к утыканию в блокировки, либо бесконечной рекурсии. Соответственно, сейчас стоит проблема в том, чтобы найти альтернативное решение.

Мне удалось найти пару вроде бы подходящих ФМ: CUCB_GET_CONFIGURATION и CUCB_SET_CONFIGURATION, которые я использую примерно следующим образом:



Для существующих позиций оно вроде работает, а вот для новых нет: никаких ошибок не выдается, но изменений не происходит. Видимо, это из-за того, что позиция еще не сохранена в БД. Пробовал завернуть указанный код в ФМ и вызывать его в UPDATE TASK (и V1, и V2) - не помогло.

Помогите, пожалуйста, довести этот подход до ума или найти более правильное решение. Буду премного благодарен

У меня была другая задача. Необходимо было при создании сбытового заказа (VA01) со ссылкой на другой сбытовой заказ переносить некоторые признаки конфигурации в копируемую позицию. Использовал userexit_cust_material_read в SAPMV45A. Читал из копируемой позиции CUCB_GET_CONFIGURATION, не нужное удалял, в новой позиции cuobj еще не был виден, методом тыка:) вызвал CUCB_CHANGE_CONFIGURATION во входной параметр передал cuobj из копируемой позиции и система сама разобралась и в новую позицию прописала нужную мне конфигурацию

Как-то это странно. CUCB_GET_CONFIGURATION ведь возвращает всего лишь копию значений - как он узнает, что что-то поменялось? Принцип работы CUCB_CHANGE_CONFIGURATION в этой ситуации и вовсе загадочен. Так или иначе, сейчас пытаюсь адаптировать сей подход под свои нужды, спасибо. Уже вижу, что действительно у новой позиции CUOBJ меняется - на момент сохранения он один (не знаю, откуда берется); после сохранения - уже другой.

Ну люди ж делали:) По всей видимости модуль обновления сначала видит конфигурацию(набор признаков) что ему подсунули в память, а уже при апдейте гененерит cuobj со ссылками.

Факир был пьян, факинг не удался.

Мои игрища с конфигурацией завязаны на позицию заказа на поставку, поэтому вместо USEREXIT_CUST_MATERIAL_READ пытаюсь использовать что-нибудь вроде USEREXIT_MOVE_FIELD_TO_VBAP (он вызывается после редактирования данных позиции). Увы, описанный фокус с вызовом CUCB_GET_CONFIGURATION/CUCB_CHANGE_CONFIGURATION никакого эффекта не дает.

Вообще наверное все это не очень хорошо..., ну так влазить в обработку конфигурации. Но если очень нужно, то в твоем случае можно поискать возможность уже после сохранения заказа выполнить следующую цепочку:
CUCB_GET_CONFIGURATION по уже сгенерированным CUOBJ затем в CUCB_CHANGE_CONFIGURATION передать нужную конфигурацию в CHANGING параметр, после вызвать CUCB_CONFIGURATION_HAS_OBJECT , CUCB_CONFIGURATION_TO_DB и C14Z_COMMIT_WORK. У меня так в z-тр-ции изменяется конфигурация при определенных условиях.

Согласен, но бизнес есть бизнес: хотят и все тут.


В этом направлении тоже думаю, но пока не придумал, как привязаться именно к сохранению заказа.

Была мысль дернуть мою ФМ-ку со STARTING NEW TASK 'aaa' и там уже дожидаться, когда будут отпущены все блокировки на заказ. Однако тут две проблемы предвижу:
1. Если у пользователя уже открыто максимальное количество сессий, то этот вызов не отработает - нехорошо;
2. STARTING NEW TASK, как я понимаю, делается через RFC, что подразумевает неявный коммит - совсем нехорошо.

trop, мега-спасибо, оно работает!
Вот оно как бывает: ищешь-ищешь, а решение все это время почти под носом лежало...