IDoc Purchase Order in SAP: ORDERS and ORDERS05

An IDoc (intermediate document) is SAP's standard container for moving business data in and out of an SAP system. Each IDoc has a control record that names the sender, receiver, and message type, one or more data records holding the segments, and status records that track what happened to it. For a purchase order, the message type is ORDERS and the basic type is normally ORDERS05.

That single sentence answers most of the search traffic on this topic, but it hides the part that actually costs projects time: partner profiles, process codes, status 51 errors, and the orders that never arrive as structured data at all. Here is the working detail, verified against SAP documentation and practitioner sources.

What is an IDoc in SAP?

An IDoc is a structured data container SAP uses to exchange documents with other systems, whether by EDI, ALE, or a middleware platform. Every IDoc has three parts: a control record (table EDIDC) with sender, receiver, direction, and message type; data records (EDID4) holding the segments; and status records (EDIDS) recording each processing step.

What is the IDoc type for a purchase order?

The IDoc basic type for a purchase order is ORDERS05, described in SAP as the purchasing and sales document interface. ORDERS05 is the current version of the ORDERS01 through ORDERS05 family. It is used in both directions, so the same basic type carries a purchase order out of a buyer's system and a sales order into a supplier's system.

What is the message type for a purchase order IDoc?

The message type is ORDERS. Message type describes the business meaning of the data, while the basic type describes its structure, and the pairing ORDERS with ORDERS05 is the standard purchase order combination. The same ORDERS05 basic type also serves other message types, including ORDRSP for an order response and ORDCHG for an order change.

Purchase order message types and their basic types

These are the message types that show up around a purchase order lifecycle, with the X12 transaction each usually maps to in a US trading relationship.

If you are mapping between these and the X12 side, our breakdowns of the EDI 850 purchase order and the EDI 856 advance ship notice cover the segment logic on the other side of the translator.

What is the difference between ORDERS and ORDRSP?

ORDERS is the order. ORDRSP is the answer to it. The buyer sends ORDERS to the supplier with what it wants; the supplier returns ORDRSP confirming acceptance, rejection, or amended quantities and delivery dates. Both use basic type ORDERS05, so the structure looks familiar, but the direction and business meaning are opposite.

Key segments in an ORDERS05 IDoc

ORDERS05 is deep, with well over a hundred segments once you count sub segments. In practice a purchase order interface touches a small subset. These are the ones you will spend your mapping time on.

Segment definitions can be read in the system with WE31 (segment editor), the full hierarchy with WE30 (IDoc type development), and printable documentation with WE60.

How do you create a purchase order using an IDoc?

Inbound purchase order creation uses message type PORDCR1 with basic type PORDCR102, processed by function module IDOC_INPUT_PORDCR1, which calls a purchase order BAPI internally. Inbound ORDERS is different: at a supplier it normally creates a sales order, not a purchase order. Choose based on which document you actually need created.

The setup, in order

1. WE21: define the port (file, tRFC, XML, or ABAP-PI) the IDoc will travel through.
2. WE20: create the partner profile for the vendor or logical system, with an inbound or outbound parameter for the message type, the basic type, and the process code.
3. Output determination: for outbound POs, an output type on the purchase order in ME21N or ME22N triggers the IDoc through the message control setup.
4. WE19: use the test tool to build a sample IDoc, or copy an existing one, and push it through inbound processing in debug so you can see exactly where a mapping breaks.

How do you check the status of a purchase order IDoc?

Use WE02 or WE05, the IDoc list transactions. Filter by date, message type, partner, or direction and read the status column. Outbound status 03 means the data was passed to the port successfully. Inbound status 53 means the application document posted. Status 51 means the IDoc reached the application but the posting failed.

Troubleshooting IDocs that fail

Almost every purchase order IDoc failure falls into a short list of causes.

• No partner profile. If WE20 has no entry for that partner and message type combination, the IDoc has nowhere to go and errors before any business logic runs. Check the partner number, partner type, and the exact message type spelling.
• Unknown vendor or customer. The partner number in E1EDKA1 has to resolve to a master record. A vendor that exists in one company code but not another fails the same way as one that does not exist.
• Unknown material. The value in E1EDP19 must match a material master or a customer material info record. Vendor part numbers that were never maintained are a classic status 51 cause.
• Unit of measure and price mismatches. A partner sending EA when the material is maintained in CS will post the wrong quantity or fail outright.
• Reprocessing. Once the underlying master data or configuration is fixed, use BD87 to reprocess the IDoc. It does not need to be re-sent by the partner, because the data records are already stored in the system.

The habit worth building: read the status record text in WE02 before touching anything. It names the application message, and that message usually names the missing object.

What is the difference between IDoc and EDI?

EDI is the external standard for exchanging business documents between companies, such as X12 in North America or EDIFACT internationally. An IDoc is SAP's internal format. A translator or middleware layer converts the X12 850 into an ORDERS05 IDoc and back. ALE, by contrast, uses IDocs between SAP systems with no EDI standard involved.

The gap IDocs cannot close

An IDoc interface only works when the trading partner is already sending structured data. That assumption holds for large retailers and tier one manufacturers. It fails constantly everywhere else. A large share of US supplier and customer orders still arrive as an emailed PDF, a scan, or a photo of a printed order, and no partner profile, port, or process code can consume any of them. We wrote about that split in EDI versus PDF purchase orders.

The missing step is turning that PDF into structured fields. Once header data and line items exist as clean records, your mapping tool or load program can build an ORDERS05 IDoc, call a purchase order BAPI, or hit an API. Teams without a full middleware stack often wire the systems together with a lightweight integration layer rather than adding another translator subscription, and either route works as long as something upstream produced structured data in the first place.

To be direct about the boundary: PurchaseOrders.io is a data capture layer. It reads a purchase order PDF, scan, or photo and returns the header fields and line items as Excel, CSV, JSON, or through a purchase order API. It does not create purchase orders, post to SAP, generate IDocs, transmit IDocs, or translate EDI. It produces the structured output that your IDoc, BAPI, or EDI process consumes. If you want that output shaped for an SAP load, see purchase order to SAP, or purchase order to XML if your mapping tool expects XML. For the PDF to structured data step ahead of a translator, see converting PDF purchase orders for EDI, and for the general loading pattern, how to import purchase orders to an ERP.

Where to start

If you are building a purchase order interface, confirm three things before writing a line of mapping: the message type and basic type pairing your partner expects, whether the flow is inbound or outbound from your side, and which master data the IDoc will have to resolve. Get those right and most status 51 errors never happen. Then decide what you will do about the partners who will never send an IDoc, because on most SAP landscapes they are the larger share of the order volume.