WE20 — WE20 Partner Profile Maintenance
WE20 maintains the ALE/IDoc partner profile: the record that tells the system, for a given partner and message type, which port to use outbound and which process code or function module to call inbound. A missing or wrong entry here is the single most common reason an IDoc fails to generate or fails to post on receipt.
WE20 is the classic transaction for creating and maintaining partner profiles used by the IDoc/ALE interface layer. This page covers the outbound versus inbound split, the tables the save writes to, and the diagnostic order for the recurring failure patterns: missing profile, wrong direction, bad process code, and port misconfiguration.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,176 words
Purpose
WE20 maintains partner profiles, the control record that governs how the IDoc interface handles messages for a specific partner. A profile is keyed by partner type (customer, vendor, logical system, bank) and partner number, and it is split into two independent sub-areas: outbound parameters, which define per message type which port to send through and whether IDocs go immediately or get collected; and inbound parameters, which define per message type which process code (and behind it, which function module) receives and posts the IDoc. The structural fact behind most confusion: a profile entry is partner plus message type plus direction specific. A partner having outbound entries for one message type implies nothing about another message type, and outbound entries say nothing about inbound capability for the same partner. Each combination has to be added on its own screen.
When it is used
WE20 is used during initial setup of an EDI, ALE, or B2B/B2G interface partner, when a new message type is added to an existing partner (for example extending a customer that already receives order confirmations to also receive invoices), and during incident triage when an IDoc has not been generated outbound or has stalled inbound. It sits downstream of the distribution model (BD64) and the port definition (WE21), and upstream of process code assignment (WE41/WE42). A consultant reaches for WE20 rather than WE19 when the goal is permanent configuration rather than a one-off test send; WE19 replays or resends an existing IDoc against the profile that WE20 defines, it does not create the profile itself.
How to use it in practice
- Open WE20, select the partner type (KU customer, LI vendor, LS logical system, B bank) and enter the partner number.
- If the partner has no profile yet, create the header: partner type, language, and any classification fields required by the interface.
- For outbound traffic, go to the outbound parameters section, add the message type, set the basic IDoc type, choose the receiver port, and set output mode to transfer immediately or collect.
- Optionally assign an outbound process code if a custom conversion is needed before send.
- For inbound traffic, go to the inbound parameters section, add the message type, and assign the process code that links to the posting function module.
- Save. Confirm the message type is not duplicated under the wrong direction and that the partner number matches exactly what the sending or receiving system uses.
Key data objects
- EDPP1 - partner profile header: partner number, partner type, language, and general classification data for the profile.
- EDP12 - outbound parameters per message type: receiver port, basic IDoc type, output mode (immediate or collect), optional outbound process code.
- EDP13 - additional outbound detail used for message variant or segment-level filtering on more granular outbound setups.
- EDP21 - inbound parameters per message type: process code, processing mode, and the link to the inbound posting function module.
How to prove it in the data
Run SE16 on EDP12 for outbound or EDP21 for inbound, filtering on the exact partner number and partner type in question, and check whether the message type at issue has a row. Compare the values against the IDoc control segment EDIDC for the failing IDoc: SNDPRN/SNDPRT and MESTYP for inbound, RCVPRN/RCVPRT and MESTYP for outbound. A mismatch on partner number, partner type, or message type between EDIDC and the profile table is the confirmation that the profile is missing or wrong, not a downstream mapping issue.
ECC vs S/4HANA
WE20 is unchanged on S/4HANA; it is still the transaction used to maintain partner profiles and there is no dedicated Fiori app replacing it. The underlying IDoc interface and its tables remain the same. Anyone approaching this from a Fiori-first mindset should expect to work in the classic GUI transaction for this specific configuration step, even on an otherwise Fiori-only S/4 landscape.
Common pitfalls and how to diagnose them
- Missing partner profile entry: IDoc status shows a partner profile not available error on send or receipt. Check that partner type and partner number match the sender or receiver exactly as they appear in EDIDC, including case and leading characters; a logical system name typed with a different case than the one in the distribution model will not match.
- Wrong direction: the message type exists in the profile but under outbound when the scenario needs inbound, or vice versa. This happens when someone copies an existing partner profile as a template and only updates the message type, not the direction section.
- Wrong or missing process code inbound: IDoc reaches the system and sits at an error status because the process code points to a function module that does not exist, is inactive, or does not match the basic type. Verify the process code assignment in the process code configuration before assuming the posting logic itself is broken.
- Port misconfiguration outbound: the IDoc generates and shows a status suggesting it was passed to the port, but nothing arrives on the other side. The profile is correct but the port it references points to a stale RFC destination or wrong file path; verify the port definition separately rather than re-saving the profile, which changes nothing.
- Collect mode left unnoticed: IDocs generate correctly but never leave the system because output mode is set to collect and the periodic job that flushes the collected queue is not scheduled or has stopped running. Re-saving the profile again does not push the queue; the collection job has to run.
- Partner number mismatch with distribution model: the profile is set up for a partner number that differs from the logical system name defined in BD64, so ALE distribution silently skips the partner. Reconcile the two before touching the profile again.
Whose problem this is
Functional or integration consultant owns the partner profile content itself: message type, direction, port assignment, process code choice. Basis owns the technical definition of the port and the RFC destination or file path behind it. ABAP owns the process code's function module when it is custom. A good handover includes partner number and type, message type, direction, the port name, the process code, and the IDoc number and status for reproduction.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/we20ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.