Skip to end of metadata
Go to start of metadata


This WIKI provides an overview of the most common inconsistencies and display issues that may occur on transaction MD04.


MD04 is a key transaction for production planning and control, which displays the up-to date stock and requirements situation. Every time transaction MD04 is accessed, planning elements and documents from different areas are read from database, compiled and displayed to the user.

In some cases, these elements may be incorrectly displayed on MD04, and this is generally caused by database inconsistencies. Since planning elements are read directly from database and they may belong to different areas, there are several possible causes and corrections for such inconsistencies. The most common problems are listed on this WIKI.

Table of Contents

Deleted or already completed sales order/delivery

Firstly, take a look on note 1992885, which describes the most common issues related to sales orders on MD04.

If a deleted, already completed or simply inconsistent sales order, delivery, quotation or SD schedule agreement can be found on transaction MD04.

This is an inconsistency that can be corrected by the report SDRQCR21, which should be already available on your system. For more details about the report execution and the parameters, please refer to SAP Note 25444

In some cases, on a make-to-order scenario, the sales order is already completed, but the sales order stock is still displayed on MD04 because there is still a quantity linked to the sales order special stock. SAP Note 1723507 provides instructions to remove the stock and the sales order will not be displayed on MD04 anymore.

If you need further assistance to find the root cause of this issue, you may refer to question 1 of the SAP FAQ Note 547277 .

Note 1909466 corrects a program error that may lead to this inconsistency,

The issue may also be caused by user-exits as explained on the section INCONSISTENCIES of KBA 2041268. In order to confirm if this is the cause of the issue, user-exits on includes MV45AFZZ, MV45AFZB and MV50AFZ1 should be deactivated.

Sales order/delivery number is not displayed

A sales order, delivery, quotation or SD schedule agreement is displayed on transaction MD04 without any reference to the document number. Error message “61111 - Selected function cannot be used for the element” is displayed when you try to open the element.

This is not an inconsistency. It happens when “daily requirement” or “weekly requirement” is selected for the availability check in the material master. More information about this system is provided on SAP Notes 70408 and 1649669.

Inconsistent subcontracting dependent requirement

A subcontracting dependent requirement (planning element SubReq) for a purchase order or schedule agreement which was already processed or deleted is still displayed on transaction MD04.

This is an inconsistency that can be corrected by the report RM06C020, which should be already available on your system. You can find more details about this report and the source code (in case it is missing on your system) on SAP Note 115899 . In some cases, the inconsistency is only found if you run the report using the reservation number, which you can get on field provision on MD04.

A known program error that can cause this inconsistency is corrected by SAP Note 1578969.

1578969 Active subcontracting requirement of deleted PReq

Inconsistent “Nproc” dependent requirement

“Nproc” dependent requirements are reprocessing records for goods movements that failed during a REM backflush. These records should be processed using transaction COGI or MF47, however, in some cases, they are inconsistent and they can’t be processed. 

The error message "RM887 - Changed REM profile regarding generation of post processing records" may also be displayed on transaction MFBF on MF47.

If the record can be found on MF47 or COGI, but they can’t be processed, it is an inconsistency that can be corrected by the report ZINCON_REPROC. This report is attached to SAP Note 383141 , which brings more information. If the error RM887 is observed on MFBF, the report should be executed for the components, not for the parent material.

Otherwise, if this record can’t be found on COGI or MF47, it is a 'lost' reprocessing record, for which the planned order does not exist anymore. You should implement and run the report ZRMBF06, which is attached to SAP note 95307 or following the procedure from SAP note 901146 .

Dependent requirement without parent planned order

A dependent requirement is displayed on transaction MD04 for which the planned order has already been deleted. The planned order number is displayed in the MRP element data of the dependent requirement, however, this planned order can’t be accessed on transaction MD12 and it does not exist on table PLAF. When you try to access the planned order the error message “61 003 - Planned order XXX does not exist”.

Report ZCHECKRESB1 from note  2047547 can be used to clear this inconsistency. 

The root cause of this inconsistency is generally a custom program that deletes planned orders directly from table PLAF.

You can run transaction code_scanner, selecting pakacge Z* and search string "PLAF" to find if there is any program deleting data directly from table PLAF.

The standard BAPI BAPI_PLANNEDORDER_DELETE should be used to delete a planned order, instead of directly database update.

Closed PM order reservation displayed on MD04.

 This is generally a database inconsistency, where the field RESD-XLOEK was not set for the reservation. The correction report from note 600151 should fix the inconsistency.

Reservation of a deleted component from a production or process order still appears on MD04

A component is deleted from a production or process order and it receives the status DLT (I0013), however, the deletion indicator is not set (RESB-XLOEK) and the reservation still appears on transaction MD04. This is an inconsistency that should be solved by note 2304812.

Inconsistent purchase order, inbound delivery or shipping notification.

For an MM document, such as a purchase order, inbound delivery or shipping notification you observe one of the following symptoms:

  • More then one line appears for a purchasing document in MD04
  • Confirmation's MRP relevant quantity was not reduced, hence MRP still calculates with it
  • MRP element ’POitem’ still visible in MD04 after posting Inbound Delivery
  • MRP element ’ShpgNt’ still visible in MD04 after posting GR
  • Negative quantity in MD04 even after goods receipt is posted
  • The receipt quantity in MD04 is inconsistant from PO History

This is generally an inconsistency on the MM tables EKET, EKES or EKBE, where the quantity reduced for MRP (field DABMG) was not correctly updated. The following SAP note list the correction reports to clear this kind of inconsistency and the notes with code corrections to avoid this kind of issue:

  2044484 - Troubleshoot to EKET, EKES, EKBE table inconsistencies

A purchase requisition was already converted to purchase order is still displayed on MD04

This is generally caused by an inconsistency on table EBAN, which is not updated during the conversion. Report RM06HL04 is available on the standard system on the latest releases and it can be used to fix inconsistent orders. Note 171331 provides more information about this report.

Field Available Quantity is blank

The field "available quantity" from transaction MD04 is empty for an specific planning element. There are several possible causes and you can find an overview on knowledge base article 1825187.

Inconsistencies on IS-AFS systems

If you are using the industry solution SAP Apparel and Footwear (IS-AFS), different tables are used, therefore, there are also different reports to fix inconsistencies.

Report J_3AMBAC : Inconsistencies on purchase requisitions

Report J_3AMPOC: Inconsistencies on purchase orders

Report /AFS/RMD_CHECK : Inconsistencies on dependent requirements

Report /AFS/SDRQ: Inconsistencies on sales orders

Related Content

Related Documents

Frequent issues on MD04

MRP: Frequently Asked Questions

MD04: Problems with sales orders

Related Notes

SAP Note 25444 : SDRQCR21: Recovery of sales and delivery

SAP Note 70408 : No display of sales order number in MD04

SAP Note 95307 : Deletion report for 'lost' reprocessing records

SAP Note 115899 : Correction report for subcontractor requirements

SAP Note 171331 : Correction report for quantity ordered in PReq

SAP Note 383141 : RM887, RM757: Collect. note inconsistent postprocessing recs

SAP Note 547277 : FAQ: Requirements in SD and in the delivery

SAP Note 901146 : NPROC dependent requirements can not be processed

SAP Note 1578969 : Active subcontracting requirement of deleted PReq

SAP Note 1649669 : Sales order number or delivery number is not displayed in transaction MD04.

SAP Note 1723507 : Completed sales order displayed on MD04

SAP Note 1825187 : Available quantity incorrect on MD04/MD05

SAP Note 1888035 ; Trouble shooting for incorrect entries in transaction code MD04

SAP Note 1909466 ; No stock found when using manual batch/batch split in delivery

SAP Note 1992885 : MD04: Problems with sales orders and deliveries

SAP Note 2044484 : Troubleshoot to EKET, EKES, EKBE table inconsistencies

SAP Note 2304812 : Order reservations in deleted or [technically] completed orders are still active




  1. Former Member

    It is definitely Superhit at box office,it is Key transaction for the Production Plannining, DEVENDRA  

  2. Former Member

    It is very useful information & I solved my problem by using that information. I am very thankful to Caetano Almeida for this page. I want to know about SAP Note 1909466 in detail. Anyone can help me in this regards?

    1. Hello Iqbal


      Note 1909466 contains a code correction for a program error that could lead to inconsistencies on MD04.

      If this note is missing on your system you should ask your basis to implement it.



  3. Former Member

    Dear Caetano Almeida,

    Again bundle of thanks for your cooperation.


  4. Former Member

    Very nice wiki doc.

    Thanks Caetano Almeida  !



  5. Thanks a lot! Very helpful