WE42 — Inbound IDoc process code assignment

WE42 is the customizing transaction for inbound process codes. A process code is a short identifier that sits between the partner profile (WE20) and the actual processing logic: the partner profile's inbound parameter for a given partner and message type names a process code, and WE42 is where that process code is bound to a function module or a workflow task. The structural fact that causes most confusion is that the process code is not the function module and not the message type — it is a separate customizing key, usually client-independent and transportable, that can exist in one system and be missing in another after a transport. When an inbound IDoc fails to post, the root cause is frequently not the interface data at all but a process code entry that was never created, was deleted, or points at a function module that no longer exists in the target system.

WE42 is used during initial setup of any classic IDoc-based inbound interface, whenever a new message type or a custom Z function module is introduced, and during troubleshooting when inbound IDocs are stuck with a processing error that is not explained by the application data itself. It sits upstream of WE20 in the configuration chain: WE20 tells the system which process code to use for a partner and message type, WE42 tells the system what that process code actually does. A consultant reaches for WE42 rather than a Fiori app or a modern interface tool specifically because this is classic ALE/IDoc plumbing; on S/4HANA it still governs the same inbound path even where newer integration technology (CPI, APIs) handles the outer transport layer, because the IDoc still has to be dispatched to a function module once it lands.

Start from the failed IDoc number in the control record table, note the partner, message type, and direction. Look up the inbound partner profile entry for that partner and message type to read off the process code it is configured to use. Then check the WE42 customizing table for that exact process code value: if there is no row, the assignment was never created or was lost in a transport; if there is a row, confirm the function module name it contains still exists and has not been renamed or deleted. Finally read the IDoc's status records to see whether the error text matches 'function module not found' or a similar determination failure rather than an application posting error.

WE42 and the inbound process code concept are unchanged on S/4HANA; this remains classic ALE/IDoc customizing and there is no Fiori app that replaces it. What changes in practice is the surrounding landscape: IDocs on S/4HANA are frequently paired with cloud integration middleware for the outer transport, but once the IDoc is dispatched into the ABAP stack, the same process code determination logic in WE42 governs which function module or workflow handles it.

Functional consultants own the process code assignment and its mapping to the correct message type and partner. ABAP development owns the function module implementation and must be told immediately if its interface signature changes. Basis or the integration team owns the port and connection layer feeding the IDoc in. A good handover includes the process code value, the function module name, the message type, a sample failing IDoc number, and the exact status error text.

WE41 is the outbound counterpart and is worth reading alongside WE42 to understand the full process code model on both directions. WE20 is the partner profile transaction that actually references the process code and is the first place to check when an inbound IDoc fails. WE30 and WE31 cover IDoc type and segment definition, useful when the failure turns out to be structural rather than a process code problem. WE19 is the test tool for manually triggering an inbound IDoc through a given process code to isolate whether the assignment itself works. WE05 gives the IDoc list to find failing instances and their status history.