Lesson 3 of 6
Partner profiles: outbound parameters
11 min
Listen to this lesson
The partner profile in WE20 is the heart of IDoc configuration. It has a general part per partner and a list of rows per message: outbound parameters for what you send and inbound parameters for what you receive. This lesson builds Great Lakes Fleet Services' outbound side in CMP client 100.
The general profile
In WE20, partners are grouped by partner type in a tree. You position the cursor on Partner Type KU and create partner 17100001. The system checks that the customer exists, because partner type and number must match master data. On the general part you set the partner status to A (active); I (inactive) stops communication and T (template) makes the profile a sample for the partner profile API. On the post-processing tab you name the permitted agent: the user, position or organizational unit that receives a work item when an IDoc for this partner fails. Contoso uses a position for the O2C EDI desk in Maria's team, so errors reach a role, not an individual on vacation.
The outbound row
Each outbound row is keyed by partner, partner function, message type, optional message code and message function, and the test indicator. For Great Lakes' order acknowledgment, the row looks like this:
| Field | Value for Great Lakes ORDRSP | Why it matters |
|---|---|---|
| Partner function | SP (sold-to party) | Must match the partner function of the output record in message control; otherwise no IDoc is created |
| Message type | ORDRSP | The logical message; the key for the row |
| Receiver port | XP1_PO | The tRFC port to Process Orchestration in production |
| Output mode | Transfer IDoc immediately | Each IDoc goes to the port as soon as it is created; the alternative is Collect IDocs |
| Basic type and extension | ORDERS05, no extension | The structure; when a message carries custom segments, such as Contoso's extension for Great Lakes' fleet unit numbers (course sap-edi-209), the extension is entered next to the basic type |
| Cancel processing after syntax error | Set | An outbound IDoc with a syntax error stops (status 26) instead of being sent |
| Message control: application / output type / process code | V1 / BA00 / SD10 | Links the sales output record to the program that builds the ORDRSP IDoc |
Great Lakes Fleet Services' outbound partner profile row for ORDRSP in CMP.
The message control tab is what connects an output type in the application to the IDoc interface. SAP's documentation for outbound processing under message control states the rule: you must assign the application and the output type uniquely to an IDoc type in the partner profile. For each output type you send to this partner by EDI you add a line: application, output type and the outbound process code that fills the IDoc. If the line is missing, the output record finds no process code and fails with the error SAP routes to process code EDIN ("No process code in the additional partner profile MC parameters").
| Output | Application | Output type | Message type | Partner function | Process code | Basic type |
|---|---|---|---|---|---|---|
| Order acknowledgment (855) | V1 sales | BA00 | ORDRSP | SP | SD10 | ORDERS05 |
| Ship notice (856) | V2 shipping | LAVA | DESADV | SP | DELV | DELVRY07 |
| Invoice (810) | Billing on output control | No NAST line (was V3 / RD00 in ECC) | INVOIC | BP | No message control line (was SD09) | INVOIC02 |
| Purchase order to Lakeside (850) | EF purchasing | NEU | ORDERS | VN | ME10 | ORDERS05 |
Contoso's outbound EDI rows: the first three on customer 17100001 (KU), the last on Lakeside Components (LI).
The invoice row is the exception. In ECC, Contoso's invoices used NAST output type RD00 in application V3 with process code SD09. After the conversion, Contoso runs billing documents on SAP S/4HANA output control (the SD stream's decision, covered in sap-sd-207), while sales documents, deliveries and purchase orders stay on NAST. The INVOIC row on partner 17100001 therefore keeps its port, basic type INVOIC02 and output mode, but the trigger comes from the billing output rules instead of a message control line. Course sap-edi-202 explains both frameworks.
Output mode, packet size and subsystems
Transfer IDoc immediately sends each IDoc to the port as it is created: SAP still records status 30 (ready for dispatch), then moves on to 03 at once. Collect IDocs leaves them in status 30 until report RSEOUT00 sends them, usually as a scheduled job, in packets whose size you set in the row. Collecting suits high-volume, low-urgency messages such as nightly invoice runs. A second choice, start or do not start the subsystem, only matters for file ports with a trigger. Contoso sends ORDRSP and DESADV immediately, because Great Lakes measures 855 and 856 timeliness, and collects INVOIC: an RSEOUT00 job sends Great Lakes' invoices every 30 minutes, so an invoice IDoc can sit in status 30 for up to half an hour by design.
Two smaller fields cause confusion. Segment release on the outbound options can pin the segment definitions to an older release; SAP recommends leaving it blank so the latest segment version is used, unless a partner's translator truly cannot handle newer fields. The EDI Standard tab lets you propose a standard (X for X12, E for EDIFACT), a version and an EDI message type such as 855 to the subsystem. PO 7.5 at Contoso determines these from its own partner agreement, so the tab is filled only for documentation.
LI and LS outbound rows
A supplier profile (partner type LI) works the same way with purchasing values: Lakeside Components gets an ORDERS row with partner function VN, port XP1_PO, basic type ORDERS05 and message control EF / NEU / ME10. A logical system profile (partner type LS) is used for ALE: its outbound rows usually have no message control tab entries, because ALE outbound is triggered by the distribution model and change pointers rather than by output records.
What would you do?
In CMQ, outbound deliveries for Great Lakes get a LAVA output record with status "processed with errors", and no DESADV IDoc exists. The processing log says no process code was found in the partner profile message control. What is the fix?
- The general profile holds partner type, number, status (A, I, T) and the permitted agent for errors.
- Each outbound row sets partner function, message type, port, output mode and basic type (plus any extension).
- Message control maps application + output type to a process code: V1/BA00/SD10, V2/LAVA/DELV, EF/NEU/ME10 (V3/RD00/SD09 where billing still runs on NAST).
- Collect IDocs leaves IDocs in status 30 until RSEOUT00 runs; transfer immediately passes 30 and reaches 03 at once.
Check your understanding · not graded
Lesson check
1. Which output mode leaves outbound IDocs in status 30 until a job sends them?
2. In Contoso's setup, which process code builds the ORDRSP IDoc from output type BA00?
3. What must the partner function on an outbound row match?
4. What does partner status T (template) mean in WE20?