Если кому интересно, в итоге использовал
BADI CHANGE_MRP_DATA
Метод CHANGE_MDPSX_MDBS.

Все оказалось проще пареной репы, я поступил так:
Проверяю есть ли Входящая поставка для позиции, если есть убираю позицию заказа для MRP.
Работает как MD01 так и MD03, MD04, MD05.
Дальше правда не копал, передам стажерам тестить.
Всем удачи !!

Постановка задачи:

Товарищи не спешно ищется решение для следующей ситуации:
1. Размещаем PO у поставщика на M1 100 шт.
2. Поставщик подтверждает M1 50 шт, данный факт отражем созданием входящей поставки и регистрируем разницы между заказаным и подтвержденным количеством в ППП (POD).
3. В итоге в MDO4 имеем картину
- PO 50 шт
- INBDEL 50 шт

Есть желание видить только открытое количество по входящей поставке.
Метка конечной поставки сносит и заказ и поставку из ожидаемого к ПМ количества.

Могу делать так:Воркфловом делю позицию заказа на подтвержденное и нет и на не подтвержденное ставлю метку конечной поставки.

Может кто подскажет более красивое решение?
Но не самого процесса а технической реализации.
Заранее спасибо.

Не знаю, то ли предложение я тебе предложу, однако я так понимаю, что тебе нужна инфа по входящим поставкам.

Так сделай query по таблицам VBUK, LIKP, LIPS там пересечение по полю VBELN (поставка).
Выбирай поставки по полям «Вид поставки» (LIKP–LFART) и «Общий статус движения материала» (VBUK–WBSTK).
По полю VBUK–WBSTK, если оно не будет равно "С" ты сразу поймешь, что к поставке не было движения материала.

А вот ломать MD04 это не тот путь, да и выводит тама все правильно.

Ну ты ведь и сам понимаешь, что это не то ...

Приложу еще и сценарий:
Дело в том, что Поставщик после подтверждения, более не рассматривает заявку и при следующем ППМ я должен сгенерить новую заявку на неподтвержденное количество, а закупщик отработать соотвествующим образом.
В преведенном мною случае в верхнем топике открытое количество заказа напрямую влияет на результаты ППМ.
Ломать ни кто не собирается, ибо давно бы уже сломал

Если так
>1. Размещаем PO у поставщика на M1 100 шт.
Здесь размещаем не РО, а список заявок.

>2. Поставщик подтверждает M1 50 шт, данный факт отражем >созданием входящей поставки и регистрируем разницы между >заказаным и подтвержденным количеством в ППП (POD).
Здесь по подтвержденым позициям заявок создаем РО.

Тогда остаются открытые заявки и закупщики думают дальше что с ними делать.

Сергей, тут же заставят писать агрегацию заявок.



Это надо делать после создания PO, смысл входящей поставки теряется.



Равно то же самое, что и заказы, можна так же заставлять их править заказы.

2SE 4.7
Ага,только это уже совсем другая история
Я например не вижу стандартных способов решить данную проблему.

Попробую сделать здезь:
Importing MRP data - BAdI MD_CHANGE_MRP_DATA
User-defined MRP elements in MRP/LTP - BAdI MD_ADD_ELEMENTS

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

Ну это все-таки изменения стандарта Кинь документацию, я не использовал их.Спасибо.

Using the Business Add-In (BAdI) MD_ADD_ELEMENTS, you can change the MRP data that was imported during the following processes:

Planning run of material requirements planning, master production scheduling, and long-term planning
Construction of the stock/requirements list
Planning table of repetitive manufacturing

Once the requirements and receipts have been completely imported in the standard system, you can completely revise the data. You can also add user-defined requirements and receipts to the table of MRP elements.

Note the far-reaching effects, which may result, for example in the subsequent net requirements calculation in planning and during the interpretation of the planning result. There is no consistency check after the method has run. SAP does not accept responsibility for any data inconsistency, which may occur, nor for errors in subsequent processes.

Due to the complexity of this BAdI and the high risk, which can arise as a result of changes, this BAdI is only designed for SAP internal Industry Business Solutions. Customers or partners should only use this BAdI in exceptional cases and in consultation with the development department

А правка формул и переноса данных в VOFM - изменение стандарта

You can use the Business Add-In (BAdI) MD_CHANGE_MRP_DATA to change the MRP data that is read during the following processes.

Planning run of material requirements planning, master production scheduling, and long-term planning
Creation of the stock / requirements list
Planning table of repetitive manufacturing
Using the available BAdI methods, you can implement a user-defined logic when importing the MRP element from the database.

In the processes mentioned above, the internal table MDPSX is built up from the MRP elements read from the database. In the standard logic for MRP, it is defined whether an MRP element is taken into account in the MRP and in which form (for example quantity, date).

You can use this Business Add-In to

Take into account MRP elements in certain cases, although they are never taken in to account according to the standard logic.
Not take into account MRP elements, which are considered according to the standard logic.
Change characteristics such as MRP relevance, dates, quantities and so on, of imported MRP elements
You can define in your implementation whether you want to take action in the display only or also in planning.

You should however note the far-reaching consequences that, for example, subsequent net requirements calculation can have in planning and interpretation of the planning results. There is no consistency check after running the methods. SAP takes no responsibility for any data inconsistencies which result or for errors in subsequent processes.

Как по описанию,так то что доктор прописал.Я сейчас в системе 4.6 и там этих бади еще нет.VOFM - безобидная вещь А с этими 2мя бади я бы прислушался к параноидальным советам сап
Хотя, насколько я знаю, Вы товарищ опытный.Отпишите,как все получится.

SAP takes no responsibility for any data inconsistencies which result or for errors in subsequent processes.

Вы про это?
Ну волков бояться в лес не ходить!

А не безопаснее ли и проще написать абап,который будет "приводить в порядок PO",да повесить его на batch job?Ну как альтернативу точно стоит рассмотреть,хотя и не стандарт,но все-таки