ERPClimb logoERPClimb
IDoc message typeObjectORDERSModuleBTP_INTEGRATION

ORDERS message type — ORDERS IDoc Message Type for Purchase Orders

ORDERS is the IDoc message type that carries a purchase order between two SAP systems or between SAP and a vendor/customer EDI subsystem. Outbound, it transmits a PO created in MM to a vendor. Inbound, it receives a customer's PO and triggers automatic creation of a sales order via a configured process code.

This page covers the ORDERS IDoc message type used to move purchase order data in and out of SAP, both as an outbound PO to a vendor and as an inbound trigger for sales order creation. It focuses on the segments carrying the order data, the partner profile and process code setup required for the flow to work, and the ordered checklist for diagnosing a stuck or rejected ORDERS IDoc.

Published 16 Sept 2026· 1,063 words

What it carries

ORDERS moves the purchase order document across systems, and it runs in two directions with different meanings. Outbound, it represents a PO created in the buying company's MM module, sent via ALE or EDI to a vendor's system or EDI subsystem, usually triggered by output determination on the purchase order itself. Inbound, it represents a PO received from a customer, and the receiving system uses it to automatically create a sales order in SD, standing in for a manually keyed VA01 entry. The same message type name is reused for both legs because the underlying document structure (header, partner data, items, schedule lines) is symmetric even though one company is the buyer and the other the seller. Order changes typically travel as a separate message type built on similar segments, and order confirmations come back as ORDRSP, not as ORDERS.

Segments

  • E1EDK01: document header, carries order type, currency, document date and the overall header control data
  • E1EDKA1: partner segments, repeated per partner function (sold-to, ship-to, vendor, bill-to), each occurrence tagged with a partner function qualifier
  • E1EDK02: reference document data, holds qualifiers for the customer PO number, vendor order number and related document references
  • E1EDK03: date segment, header-level dates such as document date and requested delivery date, distinguished by date qualifier
  • E1EDP01: item segment, one occurrence per line item, holds quantity, unit of measure and item category
  • E1EDP19: object identification, carries material number in various forms (own material number, customer material number, EAN), qualifier-driven
  • E1EDP20: schedule line data, item-level delivery dates and quantities where the order specifies delivery schedules

Configuration

For outbound ORDERS, the purchase order needs an output type driven by condition records (message determination in MM), a partner profile maintained for the vendor as partner type LI with ORDERS in the outbound parameters, a process code pointing to the outbound function module that builds the IDoc, and a port (usually RFC or file) that the IDoc is routed through. For inbound ORDERS, the partner profile is maintained for the customer as partner type KU with ORDERS in the inbound parameters, referencing a process code that maps to the function module responsible for creating the sales order, and the customer must be extended to the sales area used in that mapping. In both directions the partner number in the IDoc control record must match a maintained partner profile exactly, and the port must resolve to a live RFC destination or file location. Missing sales order type mapping in the inbound customizing for EDI order types is a frequent gap even when the partner profile itself looks correct.

What to inspect when it fails

  • Check IDoc status first, WE02 or WE05: status 51 (application error) versus status 56 (not yet processed, in queue) point to different root causes
  • Read the actual error text attached to the status record, not just the status number, since 51 covers everything from missing material mapping to a locked document
  • Verify the partner profile in WE20 for the exact partner number and partner type used in the IDoc, and confirm ORDERS is listed with the expected process code
  • Verify the port in WE21 and, for RFC ports, test the underlying RFC destination in SM59
  • For inbound failures, check whether the customer is extended to the sales area implied by the order type mapping, since a missing sales area extension produces a document-not-created error that looks unrelated to the IDoc
  • For outbound failures, check the output type condition record on the purchase order (message determination) to confirm the output was actually generated before assuming an ALE problem
  • Use WE19 to replay the same data as a test IDoc, changing one field at a time, to isolate whether the failure is data-driven or configuration-driven
  • Reprocess only after the underlying cause is fixed, via BD87, and reprocess in small batches to avoid masking a second unrelated failure

Whose problem this is

Functional (MM for outbound, SD for inbound) owns the partner profile business logic, the process code choice, order type mapping and output determination. Basis or the integration team owns the port definition, RFC destination health and the ALE/EDI subsystem connectivity. Escalate to ABAP only when the process code points to a custom function module or user exit and the failure trace points inside that custom code rather than at missing master data or configuration.

Common pitfalls

The common reflex is to select the failed IDoc in BD87 and hit reprocess, sometimes several times, hoping the error clears itself. It rarely does, because status 51 errors are almost always caused by a data or configuration mismatch, such as a customer not extended to the sales area, a material not mapped, or a missing partner function, none of which change between reprocessing attempts. Repeated reprocessing without reading the application log wastes time and, if the underlying issue is a duplicate document check, can also create partial or duplicate sales orders once the fix is finally applied and the queue is replayed in bulk.

  • The same message type name covers two structurally different business flows, outbound PO and inbound sales order creation, which confuses anyone searching logs by message type alone without checking direction
  • A status 53 (successfully posted) does not guarantee the resulting sales order or PO is free of warnings; check the application document itself, not just the IDoc status
  • Partner function mismatches fail silently in some configurations, producing a sales order with the wrong ship-to rather than an outright error
  • Customer material number versus internal material number confusion in E1EDP19 causes item-level rejection that looks like a missing master data record when the material actually exists
  • Order change traffic uses very similar segment structures to the original order, and mixing up the two during manual analysis leads to chasing the wrong document

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-idoc/ordersERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.