Lesson 1 of 6
Outbound order acknowledgments (855 / ORDRSP)
11 min
Listen to this lesson
Customers do not chargeback for orders. They chargeback for what the supplier tells them afterwards: an acknowledgment that promised a date nobody could meet, or a ship notice that did not match the truck. This course covers those two outbound messages, the X12 855 purchase order acknowledgment and the 856 ship notice (EDIFACT ORDRSP and DESADV), as Contoso Motor Co. sends them to Great Lakes Fleet Services from SAP S/4HANA CMP through SAP Process Orchestration 7.5 on XP1.
Course sap-edi-203 ended with sales order 1000457 created from Great Lakes' 850 for purchase order GLF-PO-55120: 50 alternators CMC-ALT-100, requested for October 21, 2026, to the Grand Rapids depot GR04 (ship-to 17100006). Course sap-edi-202 explained why the confirmation is determined by message control (NAST) at Contoso: sales documents stay on NAST, and SAP's documentation for sales documents says you choose one output framework for all sales apps; you cannot combine the two. This lesson follows the confirmation from the saved order to the 855 that Great Lakes' buyer reads.
The SAP side: BA00, SD10 and ORDERS05
The chain has four links, and each one has a name you will see in tickets. Output type BA00 (order confirmation, application V1) is determined by a condition record for sales organization 1710 and customer 17100001 with partner function SP, medium 6 (EDI) and dispatch time 4. The outbound row in WE20 for message type ORDRSP has the message control line V1 / BA00 / SD10. Process code SD10 calls function module IDOC_OUTPUT_ORDRSP, which you can confirm in WE41. And the IDoc uses basic type ORDERS05: SAP's list of outbound SD messages shows the sales order confirmation on the ORDERS basic types, because one structure serves orders, changes and responses.
| ORDERS05 segment | What the ORDRSP carries | Feeds in the 855 |
|---|---|---|
E1EDK01 header | Currency, Contoso's order number (BELNR), header action field | BAK08 seller's order number 1000457 |
E1EDK02 qualifier 001 | Customer purchase order number | BAK03 GLF-PO-55120 |
E1EDK03 dates | Document and purchase order dates by qualifier | BAK04 purchase order date |
E1EDKA1 partners | Sold-to, ship-to and Contoso as supplier (LF) | N1 loops, if the guide asks for them |
E1EDP01 item | Item number, quantity, unit, price; reason for rejection (ABGRU, ABGRT) | PO1 line; ACK01 IR when rejected |
E1EDP19 qualifier 001 / 002 | Customer material GLF-ALT-100 and Contoso material CMC-ALT-100 | PO1 BP and VP product IDs |
E1EDP20 schedule lines | Quantity and date per schedule line | ACK02 quantity and ACK05 date |
The ORDRSP segments the 855 map reads. Display a real IDoc in WE02 and the segment documentation in WE60 before you design the map.
The 855: what Great Lakes expects
The 855 has a header segment BAK and a PO1 loop per item with an ACK segment that states what happens to the line. BAK01 is the purpose (00 original), BAK02 the acknowledgment type, BAK03 and BAK04 the buyer's PO number and date, BAK08 the seller's order number and BAK09 the acknowledgment date. In the ACK, ACK01 is the line item status, ACK02 and ACK03 the quantity and unit, and ACK04 and ACK05 a date qualifier and date. Great Lakes' implementation guide uses qualifier 067 (current schedule delivery), so the 855 promises a delivery date, not a ship date.
ST*855*0001~BAK*00*AD*GLF-PO-55120*20261014****1000457*20261014~PO1*1*50*EA*240.00**BP*GLF-ALT-100*VP*CMC-ALT-100~ACK*IA*50*EA*067*20261021~CTT*1*50~SE*6*0001~
Read it as Great Lakes' buyer does: original acknowledgment, with detail and no change, for PO GLF-PO-55120 dated October 14; Contoso's order 1000457; line 1 accepted, 50 each, delivery on October 21. CTT counts one PO1 line with a quantity hash of 50, and SE01 counts six segments from ST to SE.
| Code | Meaning (X12 004010) | When Contoso's map sends it |
|---|---|---|
BAK02 AD | Acknowledge, with detail, no change | Every line confirmed in full on the requested date |
BAK02 AC | Acknowledge, with detail and change | At least one line changed in quantity or date |
BAK02 RD | Reject with detail | Every line rejected, each with its reason |
ACK01 IA | Item accepted | Confirmed quantity and date equal the request |
ACK01 IQ / IB | Accepted, quantity changed / item backordered | Partial confirmation now, remainder later |
ACK01 DR | Accepted, date rescheduled | Full quantity, later date |
ACK01 IR | Item rejected | Item has a reason for rejection in the order |
Acknowledgment codes in Great Lakes' guide. Each partner picks its own subset; the guide is the contract.
- Does every item have a reason for rejection?Yes → BAK02 RD, ACK01 IR per line · No → next question
- Is every item confirmed in full on the requested delivery date?Yes → BAK02 AD, ACK01 IA per line · No → next question
- Is the full quantity confirmed, only later?Yes → ACK01 DR with the new date; BAK02 AC · No → next question
- Is part confirmed now and the rest later or not at all?Yes → one ACK per schedule line: IQ for the confirmed part, IB for the backorder; BAK02 AC · No → escalate the mapping gap to Theo
Where do those decisions come from? SAP does not send "IA" or "DR". It sends the order as it stands: items, quantities, schedule lines with dates, and any reason for rejection. The map in Process Orchestration compares ordered and scheduled values and chooses the codes. The ORDERS05 item segment does have an action field (E1EDP01-ACTION, with domain values such as 001 item added, 002 changed, 003 cancelled and 004 not changed), but check in WE02 whether your release and output actually fill it before you build logic on it. Theo's team proved the map in CMQ with three orders: one fully confirmed, one partly confirmed (30 now, 20 a week later) and one with a rejected line.
The EDIFACT twin: ORDRSP
An EDIFACT partner gets the same content in an ORDRSP message. BGM uses document name code 231 (purchase order response) and a message function: 29 accepted without amendment, 4 change, 27 not accepted. Each line sits in a LIN group whose action code says 5 accepted without amendment, 3 changed or 7 not accepted, with QTY and DTM for the confirmed quantity and date. The IDoc does not change: ORDRSP / ORDERS05 feeds both, and the middleware owns the standard.
When the 855 should not go out
Contoso's BA00 procedure keeps the standard requirement that holds the confirmation while the order is incomplete or blocked. From sap-edi-203 you know two cases: a price mismatch between Great Lakes' expected price (EDI1) and SAP's net price, and a credit block. In both, sending an 855 would promise something Contoso has not agreed to. The confirmation waits until Maria's team resolves the order, and then BA00 goes out once.
What would you do?
Great Lakes orders 50 CMC-ALT-100 for October 21. Availability confirms 30 for October 21 and 20 for October 28. The 855 in CMQ arrives at Great Lakes' test system as BAK02 AD with one ACK*IA*50. What should Theo's team fix?
- BA00 (V1) with medium 6 → WE20 ORDRSP row, message control V1 / BA00 / SD10 → IDOC_OUTPUT_ORDRSP → ORDRSP with basic type ORDERS05.
- The 855 header BAK carries purpose, acknowledgment type, PO number and date, and Contoso's order number; each PO1 line has ACK segments.
- SAP sends order facts (schedule lines, rejection reasons); the map derives BAK02 and ACK01 codes from them.
- EDIFACT ORDRSP uses BGM 231 with function 29, 4 or 27 and LIN action codes 5, 3 or 7.
- The BA00 requirement holds the 855 for incomplete or blocked orders, so the customer never gets a promise Contoso has not made.
Check your understanding · not graded
Lesson check
1. Which process code builds the ORDRSP IDoc from Contoso's BA00 output?
2. An item is confirmed in full but a week later than requested. Which ACK01 code fits Great Lakes' guide?
3. Which basic type does the outbound ORDRSP message use?
4. In an EDIFACT ORDRSP, which BGM message function says the order was accepted without amendment?