MASTER_IDOC_DISTRIBUTE — Generic ALE outbound IDoc distribution function module
MASTER_IDOC_DISTRIBUTE is the generic ALE function module that takes an already-built master IDoc (control record plus data segments) and, using the distribution model and partner profiles, splits it into one communication IDoc per receiving partner for RFC or file dispatch. It is released for customer use and is called internally by most standard outbound message wrappers such as ORDERS and INVOIC generation programs.
Covers what MASTER_IDOC_DISTRIBUTE actually does inside the ALE outbound chain, its parameters and exceptions, and the specific way it fails silently when the distribution model returns no receivers. Focused on the diagnostic reflexes needed when a caller believes distribution succeeded but no communication IDoc was ever created.
Published 16 Sept 2026· 1,004 words
What it does
MASTER_IDOC_DISTRIBUTE sits between application logic that has already assembled a master IDoc and the ALE communication layer. It does not build the master IDoc itself; it takes a finished control record and data table, resolves which partners should receive the message using the distribution model (maintained via BD64) and partner profiles (WE20), and generates one communication IDoc per resolved receiver, each of which is then handed to the port definition for RFC, file, or other outbound processing. It is a released, customer-usable function module, and in practice most application-specific outbound generation programs, including standard ORDERS and INVOIC message creation, call it internally rather than duplicating its distribution logic.
Parameters
- master_idoc_control - importing/changing control record (EDIDC-style structure) carrying message type, IDoc type and basic type, direction, and other header fields; sender and receiver partner fields are normally left blank because they are resolved from the distribution model rather than supplied by the caller.
- master_idoc_data - tables parameter (EDIDD-style structure) holding every data segment of the master IDoc in the order required by the segment hierarchy for the given IDoc type.
- communication_idoc_control - tables parameter, exporting, returned with one row per communication IDoc actually created, including the document number assigned to each; an empty table after the call is the single most important thing to check.
- sy-subrc / standard exceptions - the module raises named exceptions on structural problems rather than relying purely on sy-subrc, and callers should check both.
Exceptions
- error_in_idoc_control - the control record is incomplete or inconsistent: missing message type, an IDoc type that does not match the segment definition, or a direction value the ALE layer cannot process. If this is swallowed, no communication IDoc is created but the caller may proceed as if the outbound message was sent.
- error_in_idoc_data - the data table does not match the expected segment structure: wrong segment name, segments out of hierarchical sequence, or a field value exceeding its defined length. Swallowing this can leave a partially written or corrupted master IDoc that fails much later during processing rather than at the point of the call.
- error_writing_idoc_status - the status record could not be written to the database, usually a lock conflict, tablespace issue, or authorization problem on the status tables. If swallowed, an IDoc may exist with an incomplete or missing status history, which shows up later as confusing gaps in the IDoc monitor rather than as an obvious failure at creation time.
How to call it safely
Build the master idoc control record with message type and basic/extension type populated, leave receiver partner fields blank so the distribution model resolves them, and populate the data table with all segments in the correct hierarchical order for that IDoc type. Call the function module and check both sy-subrc and the three named exceptions. Critically, also inspect the returned communication_idoc_control table: if it is empty, the call can still return without any exception, which means the distribution model produced zero matching receivers. Only after confirming at least one row in that table should the caller commit work; committing before this check is a common source of ghost outbound runs that look successful in application logs but leave nothing in WE02.
ECC vs S/4HANA
MASTER_IDOC_DISTRIBUTE remains available and functionally unchanged on S/4HANA; classic ALE and IDoc processing is one of the accepted exceptions to strict clean-core guidance because so much existing outbound integration depends on it. There is no formal successor function module. New interface development is generally steered toward API-based or event-based integration patterns, but existing IDoc-based outbound flows built on this function module continue to run without a mandated migration path.
Common pitfalls
- Treating the absence of a raised exception as proof of success. The module can return cleanly with zero rows in communication_idoc_control when the distribution model has no matching receiver for the message type and partner combination.
- Forgetting the explicit commit after the call. IDocs created by this function module do not become visible or dispatchable until the caller commits, and batch jobs that abort before the commit leave orphaned, uncommitted data.
- Building the data table with segments in the wrong hierarchy order. The function module performs only basic structural checks at call time; segment sequence problems frequently surface only when a receiving system or downstream processing program tries to parse the IDoc, far from the original call.
- Reusing the same control record structure across a loop of calls without resetting docnum and status-related fields, which can cause stale values to leak into a subsequent distribution.
- Assuming a maintained partner profile is enough. Distribution also depends on the distribution model filter settings in BD64; a partner profile with no corresponding model entry results in silent zero-receiver distribution.
Whose problem this is
This is integration/ALE developer territory. The technical call and its exception handling belong to whoever built or maintains the outbound interface program; the distribution model and partner profile configuration that determines whether any receiver is resolved belongs to the functional or basis team responsible for ALE/EDI setup. Failures traced to zero receivers are a configuration issue, not a code defect in the function module itself.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-function-modules/master-idoc-distributeERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.