Missing Partner Profile Entry for Outbound Message Type

The business report usually comes in as 'the order confirmation never reached the vendor portal' or 'the material master change didn't show up on the other side' after a new document type, plant, or interface was rolled out. Nobody in the business team says 'partner profile'. They say the document 'disappeared', or that the interface 'stopped working the moment we started sending returns' or 'as soon as we onboarded the new supplier'. Often the complaint is scoped narrowly: one specific transaction type or one specific business partner is affected while everything else on the same interface keeps working, which is the first clue that this is a configuration gap for one combination rather than a broken connection.

In almost every case the cause is a gap in the WE20 outbound parameters for the partner, not a technical connectivity fault. The usual causes, roughly in order of frequency:

Start in WE20 and look up the partner type and partner number the failing document is addressed to, then check whether the outbound parameters tab lists the message type at all. If it is missing, this is confirmed. If it is present, check the receiver port assigned against WE21 to confirm the port still exists and points to the correct RFC destination or file location. Cross-check BD64 to see whether the distribution model expects this message type for this receiver, since a model entry with no matching WE20 line is a common mismatch. Pull the actual failed documents in WE02 or WE05 filtered by message type and status to confirm every failure carries the same early status and the same error text pointing at the partner agreement rather than a network or authorization issue. If the interface runs through cloud integration, confirm on the BTP side that the expected sender party or component matches what the outbound parameter and port were built to send, since a mismatch there produces the identical symptom from the other direction.

Pull WE02 filtered by message type and date range covering the go-live or change window, sorted by status; every failing record for that message type and partner will sit at the same early outbound status with an identical error text referencing the partner agreement, while other message types for the same partner or the same message type for other partners process normally. Comparing that against the WE20 outbound parameter list for the partner confirms the missing line.

If the outbound parameter line for the message type is simply missing under an existing, otherwise correct partner profile, add it directly in WE20 with the right basic type, receiver port, and output mode; this is a client-specific configuration change, not a data fix, and does not require a transport in most landscapes because partner profiles are commonly maintained per system rather than moved through transport. If the partner profile itself does not exist, it has to be created from scratch with the correct partner type, then populated with the outbound parameters, which is the same category of change. If the port is wrong, correct it in WE21 first, since editing the outbound parameter to point at a broken port fixes nothing. If the gap traces back to BD64 having an entry with no WE20 backing, decide whether the distribution model line should be removed or the partner profile should be built out to match the intended design, since leaving both inconsistent will resurface the same failure for the next message type added later. None of these fixes touch the already-failed IDocs automatically; those still need to be reprocessed once the profile exists.

The reflex is to reprocess the stuck IDoc repeatedly through the outbound processing report or to restart the tRFC queue, on the assumption that it is a timing or connectivity hiccup. It fails every time because the message never reaches a point where connectivity matters; the ALE layer rejects it before dispatch is even attempted. A second common wrong move is escalating to the BTP or middleware team on the theory that the receiving side is rejecting the message, when the message never left the source system at all.

Ownership sits with whoever maintains ALE distribution configuration for the sending system, usually the functional team responsible for the source module together with basis or the integration team if the receiver is a BTP tenant. The handover note should state the exact partner number and type, the message type affected, and whether the fix is a one-off addition or needs to be repeated across a landscape of multiple systems.