ORDRSP message type — ORDRSP IDoc Order Response Message Type

ORDRSP moves an order confirmation, not a new order. On the sales side it is generated outbound from a sales order, usually through output determination, to tell a customer what was actually confirmed: dates, quantities, prices, sometimes item rejections. On the purchasing side it arrives inbound from a vendor confirming a purchase order already sent as ORDERS, and it updates confirmed quantities and dates on the PO schedule line so MRP and delivery planning reflect what the vendor actually committed to rather than what was requested. The same basic IDoc structure used for orders is reused here, with the segments repurposed to carry confirmed values instead of requested ones. Direction and business meaning depend entirely on which side of the interface is generating the IDoc, which is easy to lose track of when reading a status list months later.

The structure mirrors the order IDoc it responds to, with the same header and item segments carrying confirmed rather than requested values.

Both directions need a partner profile entry for the trading partner with ORDRSP maintained under outbound or inbound parameters as applicable. Outbound requires an output type on the sales order tied to a partner function, with the output determined at save or through a manual output run, feeding NAST and triggering IDoc generation with the correct port and RFC or file destination. Inbound requires the process code linked to the function module that reads the IDoc and posts the confirmation against the purchase order; this only works if the purchase order item carries a confirmation control key that expects an order acknowledgement or ASN-style confirmation category matching what the inbound IDoc declares. Without that control key set on the PO item, the IDoc can post cleanly and still leave the purchase order schedule line untouched, because the system has nowhere defined to store the confirmation. Segment filtering and partner-specific conversion rules, if used, sit on top of this and can silently drop fields the business side assumes are arriving.

Work from IDoc status backward to the business document rather than starting in the sales order or purchase order.

Functional MM owns the confirmation control key setup and the interpretation of confirmation categories on the purchase order; functional SD owns output determination and confirmation content on the sales order side. Basis or the integration team owns partner profiles, ports, and connectivity. Escalate to ABAP only when the posting function module itself needs a fix or a partner-specific enhancement for non-standard confirmation logic.

ORDRSP is deceptively easy to mark as successfully processed while the business content is wrong or incomplete.

The reflex is to reprocess the failed IDoc in BD87 and move on once it goes green. If the underlying cause is a missing confirmation control key or a qualifier mismatch, reprocessing either fails again identically or, worse, posts against the wrong line or creates a duplicate confirmation entry that MRP then treats as an additional commitment. The status turns green, the ticket closes, and the purchase order or sales order still does not reflect what the partner actually confirmed, which surfaces later as a delivery date mismatch nobody can explain.