IDOC_INPUT_ORDERS — Inbound IDoc Processing for Sales Orders
IDOC_INPUT_ORDERS is the standard SAP function module registered as the inbound process code for message types ORDERS and ORDCHG. It maps incoming IDoc segments into sales order create or change logic, effectively performing what VA01/VA02 does, but driven by EDI/ALE inbound data. It is invoked by the IDoc framework, not typically called directly from custom code, and it reports results through status records rather than raised exceptions.
This page covers IDOC_INPUT_ORDERS, the inbound function module that turns ORDERS and ORDCHG IDocs into sales order creation or change. It focuses on how success and failure are actually communicated through the IDoc status table rather than ABAP exceptions, and on the reprocessing and monitoring mistakes that keep failed EDI orders stuck in the inbox.
Published 16 Sept 2026· 1,125 words
What it does
IDOC_INPUT_ORDERS is the standard inbound function module that SAP registers as the process code handler for message types ORDERS and ORDCHG. When an EDI subsystem or an ALE distribution sends a sales order IDoc into the system, the partner profile routes it to this function module, which parses the header and item segments (E1EDK01, E1EDKA1, E1EDP01 and related) and drives the same creation or change logic that VA01 or VA02 would perform interactively. It is a released, standard SAP object intended to be called by the IDoc inbound dispatch mechanism, background reprocessing transactions, or workflow, rather than as a general-purpose API for custom Z-programs. It is RFC-enabled and can technically be invoked directly, but doing so bypasses the surrounding commit and status handling that the framework normally provides.
Parameters
- INPUT_METHOD - importing parameter that signals the call context (for example whether the call originates from mass processing or a single online post); influences internal commit behavior
- MASS_PROCESSING - importing flag indicating the call is part of a batch of idocs being processed together, which affects how commit and error handling are staged
- IDOC_CONTRL - tables parameter holding the IDoc control record (structure EDIDC), one row per idoc submitted
- IDOC_DATA - tables parameter holding the IDoc data segments (structure EDIDD), including the order header, partner, and item segments
- IDOC_STATUS - tables parameter returned by the function module with one status record per idoc (structure BDIDOCSTAT); this is the primary channel for success or failure information
- RETURN_VARIABLES - tables parameter returning workflow-relevant output values, such as the sales order number created
- SERIALIZATION_INFO - tables parameter used when order idocs for the same object must be processed in a guaranteed sequence
Exceptions
- Genuine ABAP exceptions on this function module are minimal and almost entirely technical; they do not reflect whether the order was actually created correctly, so absence of an exception is not proof of success
- Technical exceptions surface when the control record's message type does not match what the module expects, typically because a partner profile or a reprocessing program pointed the wrong process code at this function module
- The real result channel is the IDOC_STATUS table: a failed order creation caused by a missing sold-to partner, a blocked material, a credit check failure, or a pricing error comes back as an error status record with message text in the status segment, not as a raised exception
- A caller that only checks sy-subrc after the call and ignores IDOC_STATUS will believe every idoc succeeded when in fact all of them are sitting with an error status visible in idoc monitoring
- Under MASS_PROCESSING, one failing idoc in a batch does not stop the rest; each idoc gets its own status row, so partial success across a batch is expected and has to be evaluated idoc by idoc rather than assumed all-or-nothing
How to call it safely
This function module should not be treated like a BAPI called directly from custom code expecting a single clean return value. The intended path is the standard ALE/EDI inbound dispatch: the idoc arrives, the partner profile routes it to the ORDERS or ORDCHG process code, and the framework invokes this function module with the correct commit and workflow context already set up. Where a custom reprocessing report must invoke it directly, populate IDOC_CONTRL and IDOC_DATA fully and correctly, let the framework issue its own commit rather than wrapping an external COMMIT WORK around the call, and always inspect IDOC_STATUS for every idoc afterward rather than trusting a clean function call return.
ECC vs S/4HANA
On S/4HANA this function module continues to exist as the standard inbound handler for classic EDI and ALE order intake and has not been formally deprecated. It is not positioned as a clean-core extension point; new custom logic belongs in the associated enhancement or BAdI framework for inbound order processing rather than in modifications to the function module itself. For new integration builds, SAP's general direction favors API-based order creation and Integration Suite-mediated mappings over direct IDoc segment handling, but existing EDI landscapes built on this function module remain supported and are commonly left in place rather than migrated purely for architectural reasons.
Common pitfalls
- Testing with a manually copied idoc and forgetting to correct the partner data in the control record, producing what looks like a business error but is actually a routing or authorization mismatch
- Treating a green status in idoc monitoring as proof the sales order matches the source data exactly; the framework can mark the idoc technically successful while individual line items were rejected or defaulted
- Mass-reprocessing a batch of failed order idocs without diagnosing the underlying cause first, so the same missing sales area extension or blocked customer produces the same error status on every retry
- Extending or modifying the associated inbound user exits or enhancement points without accounting for multiple item segments per idoc, breaking on multi-line orders after being tested only with single-line test data
- Building custom downstream logic on the assumption that a sales order number is always returned immediately, without checking RETURN_VARIABLES, and then propagating a blank order number into a dependent process
Whose problem this is
This sits at the boundary between the interfaces/EDI team and the SD order-to-cash function. The interface or middleware team owns partner profile setup, IDoc routing, and monitoring of stuck or error idocs. The SD functional consultant owns the business logic behind why an order failed once the idoc status text points at pricing, credit, material determination, or partner data. Basis involvement is usually limited to the RFC or queue layer feeding idocs into the system, not to the content of the failures.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/idoc-input-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.