Здравствуйте!
Имеется следующая проблема: необходимо значительно модифицировать транзакцию CO11N, однако скопировать ее и "довести" до кондиции не получается, так как она привязана к программе, являющейся пулом функций. А скопировать все представляется реальным, но не совсем верным. Может подскажете выход из ситуации?
Как альтернатива - наведите на мысль, в какой последовательности и какие функц. модули надо пускать для подтверждения операций производственного заказа или их сторнирования. Видел множество ФМ-лей среди которых и заплутал.

Про BADI слыхал?

Если кратко:

1)
CALL FUNCTION 'BAPI_PRODORDCONF_GET_TT_PROP'
* EXPORTING
PROPOSE = s_prop <- см. описание структуры
IMPORTING
RETURN =
TABLES
timetickets = - заполняется: заказ операция кол-во
GOODSMOVEMENTS = - получаем список движений
LINK_CONF_GOODSMOV =
DETAIL_RETURN =
.
2)Получаем в таблицах: timetickets GOODSMOVEMENTS
данные предлагаемые CO11N по умолчанию
Меняем их на то что нужно

3)Создаем подтверждение
CALL FUNCTION 'BAPI_PRODORDCONF_CREATE_TT'

4) Если материалы ведутся партиями и нумеруются не автоматически-
создать + классифицировать (примеры есть в форуме).

примерно так.

удаление подтверждения:
BAPI_PRODORDCONF_CANCEL

Не совсем понял, что надо вводить в GOODSMOVEMENTS в первом ФМ. Для timetickets достаточно впринципе номера заказа и операции. А вот для GOODSMOVEMENTS - не подскажете? Пробовал материал + завод + заказ.
Выставление "Х" в структуру PROPOSE в соответствующее поле эффекта тоже не даёт.

Интересно, а чем вызвана необходимость модификации?

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

а вот PROPOSE = 'X' - надо

А если он ничего не возвращает? Смотрю через SE37. Ввожу только заказ и операцию в timetickets.

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

Может было бы проще просто добавить контрольную операцию, которую и подтверждал бы следующий цех? Ну или операции с контрольными признаками? Не рассматривали такие варианты?

Было бы, но так заказчик не хочет. Хочет через "одно место". (

1. "X" нужно проставлять в последнем байте PROPOSE
2. TIMETICKETS надо заполнять максимально полно: с количествами, с датами, прочими признаками

Забыл отписаться. Все получилось. Спасибо.
Сейчас пытаюсь побороть такой неприятный момент, как блокировка. При выполнении транзакции появляется надпись, что заказ уже обрабатывается мною. СOMMITы вроде расставил, где надо. Блокировка выплывает не в BAPI, а в другой функции.

Перед вызовом проверяй заказ на блокировку
примерно так:

SET UPDATE TASK LOCAL - F1

Проблема не вполне тривиальна.
Дело в том, что лок происходит в функции CO_RU_GET_ORDER_DATA и успешно снимается функцией CO_RU_ORDER_DEQUEUE. Однако в этом случае возникает событие "ORDER_WITHOUT_OPERATION".
SET UPDATE TASK LOCAL не проходит - функции бапишные для подтверждения операций заказов не могут использоваться с добавочным "IN UPDATE TASK".
Вообщем вот такой вот ступор... Хотя лок происходит именно после ввода подтверждения...
Вот такие вот пироги.