IDoc Partner Profiles, Process Codes and Ports

An IDoc interface separates business-message structure from partner-specific runtime configuration. A partner profile is keyed by partner number/type and contains outbound/inbound message parameters. Outbound parameters determine message type, receiver port/output mode and related processing; inbound parameters map message type/process context to a process code. Ports define how IDocs leave or enter the system—commonly tRFC destinations, files, XML and other supported port types. Process codes are application dispatch keys; inbound process codes typically point to the function/module/workflow that understands the IDoc's business message.

Use WE20/WE21/process-code analysis whenever an IDoc reaches the framework but routes incorrectly, uses the wrong function, cannot find partner configuration, or dispatches to the wrong destination. Do not change partner profiles when the real problem is an application-level validation in the correctly selected process code. In landscape migrations, partner numbers/logical systems and ports deserve explicit post-copy/BDLS review.

EDIDC stores partner/message/port identity chosen for each IDoc. BD64/ALE can determine which logical receivers should receive a message; the partner profile then controls actual outbound/inbound parameters. SM59 can sit beneath an RFC port. Process codes are maintained in transactions such as WE41/WE42 depending on direction and are referenced by the profile. EDP* configuration tables exist but should be treated as implementation storage, not edited directly.

An inbound ORDERS IDoc is received but returns 'partner profile not found'. EDIDC shows sender logical system and partner type. WE20 contains an ORDERS profile for a similar partner number but different partner type, so no match exists. After the correct inbound partner parameter is transported/maintained, the process code resolves and application processing begins. If it then fails with a purchasing message, the incident moves from partner configuration to MM.

Partner profiles, ports and process codes remain central for classic IDoc interfaces in S/4HANA. Some modern integrations avoid these objects by using released APIs/events, but retained IDocs still depend on them. Clean-core does not mean removing standard IDoc configuration; it means avoiding unsupported modifications/direct-table manipulation.

Integration/ALE teams own WE20/WE21/process-code configuration. Basis owns RFC destinations/connectivity. Functional teams own application errors after dispatch. ABAP owns custom inbound/outbound processing modules and extensions.

WE20, WE21 and WE42 have dedicated TCode pages; EDIDC proves the resolved partner/message/port on a runtime IDoc. The RFC destinations topic explains SM59 underneath tRFC ports.

Production verification: Capture the IDoc number when one exists, sender and receiver logical systems, message type, basic type or extension, current and prior statuses, partner type, process code or port, and the exact timestamp. Use WE02 or WE05, WE20 or WE21, BD64 and EDIDC or EDID4 or EDIDS as appropriate so the incident can be placed at trigger, routing, transport, or application-posting layer.

Operational readiness: For production readiness of IDoc Partner Profiles, Process Codes and Ports, add an operational runbook that names the source owner, integration or platform owner, and target application owner; defines correlation, retry or replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed or business-invalid payloads, and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue, retention and order behavior and how a corrected message is reprocessed without duplicating a business transaction.