Signing off a new partner setup

A new EDI partner is not "configured" when the consultant says so. It is configured when someone independent has compared the setup with the signed specification, seen real IDocs pass in the right statuses, and confirmed that production matches what was tested. At Contoso, Priya runs this as a formal configuration review for every EDI partner, and Great Lakes Fleet Services was the first.

The configuration review

1. Identity: SCC4 shows the client's logical system (CMPCLNT100 in CMP); BD54 has no stray production names in test systems.
2. Connection: SM59 connection test for the destination to PO succeeds; the destination targets XP1 in CMP and XQ1 in CMQ.
3. Port: WE21 port uses that destination and record type version SAP Release 4.x.
4. General profile: partner 17100001, type KU, status A, permitted agent is the O2C EDI desk position.
5. Outbound rows: ORDRSP, DESADV and INVOIC with the partner functions, port, output mode, basic types and message control lines from the spec.
6. Inbound rows: ORDERS with process code ORDE, syntax check set, trigger immediately.
7. Supporting data: output condition records for BA00 and LAVA exist for the customer, the billing output rules return the EDI channel for its bill-to, and inbound conversion data (covered in sap-edi-203) is in place.

Proving it with messages

Configuration screenshots prove intent; IDocs prove behavior. For each message type the reviewer keeps one IDoc as evidence, displayed in WE02: the control record (partner, port, basic type), the data records that matter and the status history. Inbound, the target is status 53 with the created sales order. Outbound, the target is status 03 at minimum, plus the partner's confirmation from the middleware side (a 997 and, where the partner offers it, a look at the data received). WE19 helps where a real partner file is not yet available: it copies an existing IDoc, lets you edit it and starts inbound processing through the normal function module, so you can prove the profile and process code before Great Lakes sends its first test file.

Negative checks

A review that only sends good messages proves half the setup. Priya adds three negative checks for each new partner in CMQ. First, an IDoc from an unknown sender (an edited copy in WE19 with a different partner number) must stop in status 56 and create a work item for the IDoc administrator, proving exception handling works. Second, an order with an unknown customer part number must stop in status 51 and reach the O2C EDI desk position, proving the permitted agent is right. Third, with the partner profile set to inactive, an outbound output must fail visibly instead of silently, proving that switching a partner off really stops traffic. Each check takes minutes and catches the configuration gaps that otherwise surface during hypercare.

Comparing quality and production

The last step before go-live is a field-by-field comparison of the partner profile in CMQ and CMP. Every difference must be either deliberate (the port, and nothing else, in Contoso's design) or a defect. The comparison is easy to do with an export of the four partner profile tables from each system or with WE20's display side by side; what matters is that it is done and filed, not that it is elegant. The same review covers the condition records for EDI output, because a missing BA00 record in CMP produces no 855 and no error message at all.