Lesson 5 of 6
Inbound order errors and fixes
9 min
Listen to this lesson
When IDOC_INPUT_ORDERS cannot create the order, the IDoc gets status 51 (application document not posted) with the error message from the order logic, and a work item goes to the permitted agent: at Contoso, the O2C EDI desk position in Maria's team. Status 51 is not an IDoc problem. It is an order problem that happens to be reported on an IDoc, and the fix is almost always in master data or configuration, followed by reprocessing.
The usual suspects
| Symptom in the status 51 message | Root cause | Fix | Owner |
|---|---|---|---|
| Sold-to or ship-to cannot be determined | Unknown external partner number (no EDPAR entry) or ship-to not a partner of the sold-to | Add EDPAR entry or partner assignment | Master data team with Maria |
| Sales organization, channel or division missing | No E1EDK14 data and no EDSDC entry for customer and supplier number | Add EDSDC entry, or fix the map to send E1EDK14 | Integration team |
| Material cannot be determined | No customer-material info record, or customer number sent with qualifier 002 | Create KNMT record (VD51) or fix the qualifier in the map | Maria's team or integration team |
| Material not maintained for the sales area or plant | Material lacks sales views for 1710 / 10 or plant data | Extend the material | Master data team |
| Unit of measure unknown or not allowed | ISO unit not mapped, or unit not defined for the material | Fix the map or add an alternative unit | Integration team, master data team |
| Customer blocked for sales | Order or sales block on the customer | Business decision; release the block or reject the order | Credit or sales management |
| Requested date in the past or invalid | Wrong date or format in the 850, or wrong qualifier in the map | Ask the partner, or fix the map | Partner, integration team |
Common causes of status 51 for inbound orders, and who fixes them.
Sibling course sap-edi-208 covers IDoc errors in general; this table is the order-specific part. One example from Contoso's hypercare is worth remembering: a Great Lakes ORDERS IDoc failed with 51 because the customer had a sales block set during a credit review. The right response was not to remove the block to let the IDoc post, but to let credit management decide and then reprocess.
Reprocessing
- Read the messageWE02 or BD87: open the status 51 record and its long text; note the IDoc number, e.g. 0000000004711
- Find the root causeCompare the IDoc data with the raw 850 in PO: is the data wrong at the source, in the map, or missing in SAP?
- Fix it where it belongsMaster data or Customizing in SAP; a map change through the integration team; a resend request to the partner if the source is wrong
- ReprocessBD87: select the IDoc and process it; the status moves to 53 with the new order number
- Close the loopConfirm the 855 went out; record the cause so repeat errors become a data or process fix
BD87 (status monitor for ALE messages) lists IDocs by status and message type and reprocesses the selected ones with the original data. WE02 and WE05 display IDocs, and WE09 searches by content, which helps when Great Lakes asks about "our PO GLF-PO-55120" and you need the IDoc number. SAP also offers an IDoc Monitor for Inbound Orders report (Logistics > Logistics Execution > Information System > Monitors), which shows inbound order IDocs in a business view and lets you branch to the order.
Editing IDocs: almost never
WE02 lets an authorized user edit a data record. When you save, the IDoc gets status 69 (IDoc edited) and SAP keeps a copy of the original with status 70. Editing is tempting and almost always wrong for orders. Change a quantity, price or part number and the order no longer matches what the partner sent, the 855 confirms something the partner never ordered, and the audit trail shows a manual change to a customer's purchase order. Contoso's rule: edit only to correct a mapping defect that is already fixed in the map, with the integration lead's approval and a ticket; otherwise fix master data and reprocess, or ask the partner to resend.
Every status 51 is also a lesson for the next Monday. Contoso's O2C EDI desk records the root cause of each one in a simple log: missing KNMT record, unknown ship-to, blocked customer, map defect. After the first month of hypercare the log showed that two thirds of the errors were missing customer-material info records for new Great Lakes parts, which led to a standing agreement: Great Lakes sends new part numbers a week before ordering them, and Maria's team creates the records in advance.
When should an IDoc be closed without an order? When the partner confirms it was sent by mistake or replaced by another order. Then the IDoc is set to status 68 (error, no further processing) through the deletion flag in BD87 or WE02, with the reason recorded, so it stops appearing in the error list without disappearing from the audit trail.
What would you do?
An ORDERS IDoc from Great Lakes is in status 51: "Material GLF-ALT-100 not found". The KNMT record exists for sales organization 1710 and channel 10. The IDoc shows E1EDP19 with qualifier 002 and value GLF-ALT-100. What is the root cause and fix?
- Status 51 is an order problem reported on the IDoc; fix the root cause in master data, configuration or the map.
- Reprocess the original IDoc in BD87 so the order stays linked to the partner's message.
- Editing in WE02 creates status 69 and keeps the original as 70; for orders, edit only with approval for a known map defect.
- Close mistaken IDocs with status 68 and a recorded reason instead of leaving them in the error list.
Check your understanding · not graded
Lesson check
1. What does status 51 on an inbound ORDERS IDoc mean?
2. Which transaction reprocesses a status 51 IDoc after the root cause is fixed?
3. What status does SAP give the original copy of an IDoc that was edited in WE02?
4. A Great Lakes order fails with 51 because the customer has a sales block from a credit review. What is the right action?