[DEAD_MOROZ]

Добрый день.
Настроен автоматический  выбор партий в исходящей поставке на основания признака(Дата последнего ПМ), т.е.  по правилу сортировки первыми выбираются самые старые партии...
Столкнулся со следующей проблемой.
Если в позиции заказа на поставку указать номер партии  и затем попытаться создать исходящую поставку(тр. VL10b), то получаем сообщение VL 206  'Партия 0903000243 определена инициирующей операцией и не может быть изменена'.
Данное сообщение возникает, если номер партии, указанный в позиции заказа, отличается от номера партии, которая определилась с помощью стратегии выбора.
Но иногда возникают ситуации, когда партия должна присутсвовать уже в заказе на перемещение, и не обязательно она должнва быть самой сторой. Может быть кто-то сталкивался с похожей проблемой и можно ли её побороть?
Ранее у меня было убеждение, что стратегия выбора не отрабатывает если в инициирующем документе указана партия. Как оказалось я ошибался...

[Uukrul]

А отключить данное сообщение, чтобы оно не пугало пользователя... кстати версия системы какая? В SAP-е оно от версии к версии часто логика меняется.

[DEAD_MOROZ]

Версия 6.0.
Отключить не получится, потому как тип сообщения прошит в коде:

Программа FV50PF0L.
................................................. ............

 IF NOT XEKET-CHARG IS INITIAL AND   
    XEKET-CHARG <> LIPS-CHARG.       
   MESSAGE E206 WITH XEKET-CHARG.   
 ENDIF.                             

[Uukrul]

Версия 6.0.
Отключить не получится, потому как тип сообщения прошит в коде:

Программа FV50PF0L.
................................................. ............

 IF NOT XEKET-CHARG IS INITIAL AND   
    XEKET-CHARG <> LIPS-CHARG.       
   MESSAGE E206 WITH XEKET-CHARG.   
 ENDIF.                             

Мда, это они жестоко однако...  и нот похоже никаких на эту тему нет... ну можно в гнездо писать, чтобы сделали это сообщение отключаемым.

[DEAD_MOROZ]

Обнаружилась интересная нотка 1268978. 
Пробуем...

[Uukrul]

Обнаружилась интересная нотка 1268978. 
Пробуем...

Да я ее видел, но там другой модуль править предлагают LV50LF17, а ты написал что по отладчику код в другом месте работает, хотя может и поможет. О результатах проверки отпишись.

[DEAD_MOROZ]

нота, как и ожидалось не помогла 
Но, в процессе установления причин проблемы было замечено, что:
1) Если после добавления позиции, выполнить проверку доступности, то поставка успешно создается!!! 
2) Если в порядке заполения полей позиции номер партии указывать раньше отпускающего склада, то поставка успешно создается!!!! 
Далее выяснилось, что видимо основная проблема в уже известной кривости проверки доступности в заказе на перемещение:
Т.е. при заполении позиции поставки таким образом, что номер партии указываем после отпускающего склада, создаются 2 партии поставки, при этом вторая партии поставки на содержит номера партии 
Если же при создании заказа руководствоваться способами предложенными выше, то обе партии поставки содержат номер партии и VL10b отрабатывает без ошибок.

[Uukrul]

Если же при создании заказа руководствоваться способами предложенными выше, то обе партии поставки содержат номер партии и VL10b отрабатывает без ошибок.

Ну тут два варианта остается, точнее один но с разными продолжениями. В общем можно написать с этим примером в SAP и они сделают ноту (если ее уже нет, просто мы не нашли) или найти где идет заполнение этого поля, подготовить модификацию и уже ее отправить в SAP с вопросом не так ли будет правильно?! Как показывает практика, второй вариант быстрее дорастает до ноты.

[DEAD_MOROZ]

Можно попробовать в badi ME_PROCESS_PO_CUST~PROCESS_ITEM принудительно дергать ФМ:
CALL FUNCTION 'MEPO_DOC_ITEM_ATP_EXP'
EXPORTING
  im_item       = lw_mepoitem
  im_ac_mode    = 'P'
EXCEPTIONS
  error_message = 1
  OTHERS        = 2.
именно он вызывается при нажатии на кнопку проверки доступности в заказе.
Для позиций с заполненой партией.
Вроде работает, только промежуточный экранчик(CO09) выскакивает, при указании/изменении принимающего завода  . Поковыряюсь мот получицца побороть.