S/4HANA output control for EDI

Billing documents at Contoso run on SAP S/4HANA output control, so Great Lakes' invoices, both the PDF copy emailed to its accounts payable mailbox and the 810, come out of rules instead of condition records. This lesson builds those rules and shows where EDI differs from print and email.

Configuration objects

• Output types per application object type, under Cross-Application Components > Output Control > Define Output Types, for example output type BILLING_DOCUMENT for application object type BILLING_DOCUMENT.
• Channels assigned to the output type: PRINT, EMAIL, EDI (and IDOC or XML where the application supports them).
• Business rules in the Output Parameter Determination app (transaction OPD in SAP GUI), one set of decision tables per business application and determination step.
• Form templates for print and email; EDI-type channels send data, not a layout, so no form is involved.

The determination steps

SAP's documentation for the app explains the mechanics that matter for EDI. Each step is a decision table with condition columns you can adjust and result columns SAP defines. Entries are processed from top to bottom, so specific rows go first. A step can return multiple matches: the output type, receiver, channel and email recipient steps may yield several results, which is how one invoice can go out by email and by EDI. The exclusive indicator on a receiver or channel row stops the evaluation at that row. And the output relevance step does not determine a parameter; it decides whether the output may be transmitted, and if it says no, the item stays "in preparation".

Read the table the way the system does. For Great Lakes' bill-to, the first row returns EDI; the second returns EMAIL and is exclusive, so evaluation stops and the print row is never reached. For any other customer, only the last, general row matches. Had the EMAIL row not been exclusive, Great Lakes would also have received a printed invoice, the classic "why did the customer get three invoices" ticket.

From EDI channel to IDoc

SAP's documentation says that when an application triggers output through the EDI channel, output control determines the receiver and channel and hands over to the communication infrastructure; the business application assembles and sends the technical message, and the message format (IDoc or SOA) is defined by that application. For Contoso's billing, Theo's team proved in CMQ that the EDI channel for Great Lakes produces an INVOIC IDoc with basic type INVOIC02 through the partner profile's INVOIC row (port XQ1_PO, collected and sent every 30 minutes). The point for any project is the method, not the assumption: check the owning application's documentation for your release, then prove the format with a real document before you design the partner map around it.

Receivers are expressed as partner roles, using the partner function codes the document carries. SAP's own example tables for billing use role RE (bill-to) and RG (payer). If Great Lakes' bill-to on an invoice were a different business partner from the sold-to, the receiver step would follow the bill-to, and that partner would need its own EDI arrangements. That is one more reason the partner functions in the order, the output rules and the WE20 rows must be designed together and checked with real documents.

Monitoring output items

Each determined output is an output item on the document with its type, receiver, channel and status. In SAP Fiori, apps such as Manage Billing Documents show the output section with the items, their status, a preview for print and email, and actions to send again or change the recipient. For EDI items, the status tells you whether the item was handed over; the IDoc in WE02 tells you the rest. OPD keeps change logs of the rules, which SAP documents as viewable in transaction OPD, so a rule change before an incident can be traced.