Sapforum.Biz
Логистика => Управление материальными потоками (MM) => Тема начата: DEAD_MOROZ от Май 25, 2009, 03:47:40 pm
-
Добрый день.
Настроен автоматический выбор партий в исходящей поставке на основания признака(Дата последнего ПМ), т.е. по правилу сортировки первыми выбираются самые старые партии...
Столкнулся со следующей проблемой.
Если в позиции заказа на поставку указать номер партии и затем попытаться создать исходящую поставку(тр. VL10b), то получаем сообщение VL 206 'Партия 0903000243 определена инициирующей операцией и не может быть изменена'.
Данное сообщение возникает, если номер партии, указанный в позиции заказа, отличается от номера партии, которая определилась с помощью стратегии выбора.
Но иногда возникают ситуации, когда партия должна присутсвовать уже в заказе на перемещение, и не обязательно она должнва быть самой сторой. Может быть кто-то сталкивался с похожей проблемой и можно ли её побороть?
Ранее у меня было убеждение, что стратегия выбора не отрабатывает если в инициирующем документе указана партия. Как оказалось я ошибался... ???
-
А отключить данное сообщение, чтобы оно не пугало пользователя... кстати версия системы какая? В SAP-е оно от версии к версии часто логика меняется.
-
Версия 6.0.
Отключить не получится, потому как тип сообщения прошит в коде:
Программа FV50PF0L.
................................................. ............
IF NOT XEKET-CHARG IS INITIAL AND
XEKET-CHARG <> LIPS-CHARG.
MESSAGE E206 WITH XEKET-CHARG.
ENDIF.
-
Версия 6.0.
Отключить не получится, потому как тип сообщения прошит в коде:
Программа FV50PF0L.
................................................. ............
IF NOT XEKET-CHARG IS INITIAL AND
XEKET-CHARG <> LIPS-CHARG.
MESSAGE E206 WITH XEKET-CHARG.
ENDIF.
Мда, это они жестоко однако... ::) и нот похоже никаких на эту тему нет... ну можно в гнездо писать, чтобы сделали это сообщение отключаемым.
-
Обнаружилась интересная нотка 1268978. ;D
Пробуем...
-
Обнаружилась интересная нотка 1268978. ;D
Пробуем...
Да я ее видел, но там другой модуль править предлагают LV50LF17, а ты написал что по отладчику код в другом месте работает, хотя может и поможет. О результатах проверки отпишись.
-
нота, как и ожидалось не помогла ;D
Но, в процессе установления причин проблемы было замечено, что:
1) Если после добавления позиции, выполнить проверку доступности, то поставка успешно создается!!! ???
2) Если в порядке заполения полей позиции номер партии указывать раньше отпускающего склада, то поставка успешно создается!!!! ???
Далее выяснилось, что видимо основная проблема в уже известной кривости проверки доступности в заказе на перемещение:
Т.е. при заполении позиции поставки таким образом, что номер партии указываем после отпускающего склада, создаются 2 партии поставки, при этом вторая партии поставки на содержит номера партии ???
Если же при создании заказа руководствоваться способами предложенными выше, то обе партии поставки содержат номер партии и VL10b отрабатывает без ошибок.
-
Если же при создании заказа руководствоваться способами предложенными выше, то обе партии поставки содержат номер партии и VL10b отрабатывает без ошибок.
Ну тут два варианта остается, точнее один но с разными продолжениями. В общем можно написать с этим примером в SAP и они сделают ноту (если ее уже нет, просто мы не нашли) или найти где идет заполнение этого поля, подготовить модификацию и уже ее отправить в SAP с вопросом не так ли будет правильно?! Как показывает практика, второй вариант быстрее дорастает до ноты.
-
Можно попробовать в 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) выскакивает, при указании/изменении принимающего завода ;D. Поковыряюсь мот получицца побороть. ;)