IDOC_OUTPUT_ORDERS — Outbound IDoc Generation for Purchase Order EDI Output
IDOC_OUTPUT_ORDERS is the standard function module SAP assigns as the processing routine for purchase order output types sent via EDI or ALE. It reads the NAST output record, pulls the purchasing document, builds an outbound IDoc of message type ORDERS, and hands it to the IDoc/EDI subsystem. It is released for use inside standard output determination, not as a general-purpose API.
This page covers IDOC_OUTPUT_ORDERS, the function module that converts a purchase order into an outbound ORDERS IDoc during message control processing. It focuses on the single exception the interface exposes, why output requests silently stay unprocessed when that exception is swallowed, and the master data checks that actually resolve stuck output.
Published 16 Sept 2026· 1,191 words
What it does
IDOC_OUTPUT_ORDERS is the standard processing routine SAP delivers for purchase order output types configured with a transmission medium of ALE/EDI (message type ORDERS in procurement). It is invoked by message control when an output request in NAST is processed, either immediately at document save or later through a batch output run. The module reads the linked purchasing document, maps header and item data into the segments of the ORDERS basic type, opens an IDoc control record, fills the data segments, and passes the finished IDoc into the ALE/EDI layer for routing to the vendor's port. It is released for use as a message control processing routine, configured against an output type in the standard IMG for purchasing output determination. It is not intended to be called directly from custom code as a synchronous conversion API.
Parameters
The interface follows the pattern common to NAST-driven output function modules: it receives the output request as its main import parameter and returns the generated IDoc through table parameters.
- OBJECT (import, structure NAST): the output request being processed, carrying the output type, application, transmission medium, partner data, and the key of the purchasing document (EKKO/EKPO) that triggered the output.
- IDoc control table (table parameter): filled with the control record of the outbound IDoc once generation succeeds, including sender, receiver, message type, and basic type.
- IDoc data table (table parameter): filled with the generated data segments built from the purchase order header and line items.
- Return/status information: the module sets status information back into the NAST return structure so message control can mark the output request as processed or in error; it does not return this through a documented RETURN structure of its own.
Exceptions
The interface exposes essentially one meaningful exception, raised when the module cannot complete IDoc generation for the given output request.
- ERROR_MESSAGE_RECEIVED: raised when the underlying processing hits an application error while building or handing off the IDoc, most commonly a missing partner profile for the vendor and message type ORDERS, a missing or inconsistent port/partner agreement, or a mapping failure against the purchase order data. When this is raised, NAST is meant to be updated with an error status so the output request shows as not processed and is picked up again on the next output run.
- Swallowed exception, no logging: if the caller catches ERROR_MESSAGE_RECEIVED without writing to the application log or checking NAST status afterward, the purchase order looks like output was attempted but nothing reaches the vendor. Buyers see the output as 'sent' in the purchase order output screen while no IDoc, or an IDoc stuck at an early control status, actually exists.
- Repeated silent failure: because the same output type re-triggers on every scheduled output run without a fix to the underlying partner profile or condition data, the same error recurs run after run, generating noise in job logs without ever alerting anyone unless the NAST error status is actively monitored.
How to call it safely
This module is not meant to be called directly from custom ABAP. It is registered against a purchasing output type in the IMG for output determination and invoked by the standard message control processing (immediate processing at save, or a scheduled output program that reads open NAST records). After a processing run, the check is never 'did the function module return' but whether NAST-VSTAT for the output record shows processed successfully, and whether a corresponding IDoc was created and reached at least the status confirming handoff to the port. Confirm this in the IDoc monitor by document number and message type, not by trusting the green status shown in the purchase order's output screen alone, since that reflects message control's own bookkeeping and can lag or misreport if the exception path was mishandled by a custom wrapper.
ECC vs S/4HANA
IDOC_OUTPUT_ORDERS remains the mechanism for classic NAST-based purchase order EDI output on S/4HANA; there is no announced replacement function module for this specific outbound flow. SAP's newer output management approach for purchasing documents is oriented around form-based output (print, PDF) rather than EDI/IDoc, so IDoc-based vendor communication for purchase orders continues to run through the classic message control path. From a clean-core standpoint, the module should be treated as classic architecture: extend behaviour through condition routines, BAdIs in the output determination framework, or IDoc segment enhancements rather than modifying or copying the function module itself.
Common pitfalls
- Missing or incomplete partner profile for the vendor and message type ORDERS causes the module to raise its exception on every run; the purchase order shows an output record but no IDoc is ever generated, and the fix is in partner profile maintenance, not in re-running the output.
- Basic type or segment version mismatch between what this module generates and what the receiving system or middleman expects (older ORDERS0x version on one side, newer on the other) produces an IDoc that leaves the system successfully but fails downstream in translation, which looks unrelated to this function module at first glance.
- Custom requirement routines or condition records that suppress the output type for certain purchase order categories mean this module is never called at all for those documents, and the absence looks like a technical failure when it is a configuration decision.
- Blind reprocessing of stuck NAST error records without first checking the IDoc monitor wastes time; the underlying cause (bad partner profile, missing condition record, vendor master not extended for EDI) has to be fixed before reprocessing produces a different result.
- A locally copied version of this module that has not been kept in sync with SAP's segment mapping after an upgrade silently drops new fields added to a later basic type version, producing IDocs that pass generation but are incomplete on the receiving side.
Whose problem this is
Functional ownership sits with procurement/MM configuration, who maintain the output type, condition records, and the assignment of this module as the processing routine. EDI/ALE basis or integration teams own partner profiles, ports, and IDoc monitoring. Interface or ABAP development owns any custom wrapper or Z variant and is responsible when exceptions are being caught without proper status handling.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/idoc-output-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.