WE41 — Outbound Process Code Maintenance for IDoc Dispatch
WE41 maintains the customizing table of outbound process codes used in ALE and EDI configuration. Each process code is a reusable label pointing to a processing type, typically the standard ALE layer or a specific function module, that governs how an outbound IDoc is technically handed off for dispatch. It is customizing, not a monitoring or execution transaction.
This page covers WE41, the transaction for defining outbound process codes referenced in partner profiles and message control. It focuses on the recurring confusion between process code and message type, and on the diagnostic steps for tracing a dispatch failure back to a missing or misconfigured process code entry.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,120 words
Purpose
WE41 maintains the table of outbound process codes, the generic dispatch labels that partner profile outbound parameters and message control point to when an application generates an outbound IDoc. A process code is not tied to a single message type; the same code, most commonly the standard ALE processing code, is reused across dozens of message types. The one structural fact that explains most confusion: WE41 does not decide which message type triggers which IDoc, and it does not decide the receiving partner or port. It only decides what happens technically once the IDoc reaches the outbound dispatch step, either standard ALE distribution or, for a handful of special cases, a specific function module doing custom preprocessing before the IDoc control record is finalized.
When it is used
This is a one-time or rarely-revisited configuration step, done during initial ALE or EDI setup, or when a custom outbound scenario needs processing logic beyond standard ALE distribution, such as a function-module-based process code that transforms or validates data before the IDoc is released. A consultant opens WE41 when a partner profile outbound parameter references a process code that does not exist, or when a custom development requires registering a new function-module-based process code. It is not used to monitor or reprocess failed IDocs, and it is not where message type to IDoc type assignment happens; those live in WE20 and the message control or change pointer configuration respectively.
How to use it in practice
- Open WE41 and review the existing list of process codes, noting the processing type column for each: standard ALE layer processing versus function-module-based processing.
- To create a new outbound process code, choose New Entries, assign a code, a short description, select the processing type, and if function-module-based, specify the exact function module that will run.
- Save and transport the entry; process codes are client-independent-adjacent customizing and typically move through the transport layer alongside other IDoc customizing.
- Go to WE20 and update or verify the relevant partner profile outbound parameter to reference the new process code for the intended message type.
- Test with WE19 by simulating outbound generation for the message type and confirming the process code fires the expected function module or ALE handoff.
Key data objects
- Outbound process code customizing table - stores the process code key, its description, the processing category (ALE layer versus function module), and the function module name when applicable.
- Partner profile outbound parameters table - stores the process code assigned to each partner, message type, and IDoc type combination, the field that actually links a business scenario to a WE41 entry.
- Function module repository - the ABAP object referenced by a function-module-based process code, executed at dispatch time rather than stored as data.
How to prove it in the data
To confirm which process code a partner profile is actually using, check the outbound parameters table behind WE20 (commonly EDP13) filtered on partner number, message type, and IDoc type, and read off the process code field. Cross-check that value against the list visible in WE41 to confirm the code still exists and its processing type. If the process code is function-module-based, verify the named function module exists and is active in SE37; a process code pointing to a deleted or deactivated function module fails silently at dispatch and shows up only as a stalled or errored IDoc in WE05.
ECC vs S/4HANA
WE41 and the underlying outbound process code concept are unchanged on S/4HANA; this remains classic IDoc and ALE infrastructure carried forward without a Fiori replacement. Consultants working integration scenarios that increasingly favor SAP Cloud Integration or event-based interfaces will still encounter WE41 wherever IDoc-based ALE distribution persists, particularly for master data replication and legacy EDI flows that were not migrated to newer integration patterns.
Common pitfalls and how to diagnose them
- Missing process code entry: a partner profile outbound parameter references a process code that was never created or was deleted, usually after a transport gap between environments. The outbound IDoc generation call fails immediately with a dispatch error rather than producing an IDoc at all; check WE41 first for the referenced code before touching partner profiles.
- Function module mismatch: the process code is correctly defined as function-module-based, but the named function module was renamed, deleted, or never transported. The IDoc gets created but stalls before status 03, often showing an ABAP dump or a status referencing a call error; verify the function module in SE37 and its transport history.
- Confusing process code with message type: consultants new to IDoc configuration assume WE41 controls which message type generates an IDoc. It does not. If IDocs are not being generated at all, the problem is upstream in message control, change pointers, or the application's own trigger logic, not in WE41.
- Wrong processing type selected: a process code created as standard ALE processing when the scenario actually needed a function module (or the reverse) produces IDocs that either skip required custom logic silently or fail because the ALE layer receives unexpected data. Compare the intended design document against the actual WE41 entry rather than assuming the configuration matches intent.
- Transport inconsistency across systems: a process code exists and works in development but is missing in quality or production because customizing transports were cherry-picked. Always confirm the WE41 entry exists in the target system before blaming the interface or the partner profile.
Whose problem this is
This is functional or integration configuration, generally owned by whoever manages ALE and EDI customizing, sometimes basis-adjacent if bundled with the technical IDoc landscape. A clean handover includes the affected partner number, message type, IDoc type, the process code involved, and whether the issue is a missing WE41 entry, a broken function module, or a transport gap between systems.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/we41ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.