From implementation guide to mapping spec

A partner's implementation guide (IG) describes how that partner uses a standard: which segments it sends, which are mandatory for it, which qualifiers and codes it uses, and what each field means in its business. It is the source of truth for the partner's side. A mapping specification is your document: it states, rule by rule, how each element of the partner's message becomes a field in your system, or the other way around. Testers test against the spec, so a vague spec produces vague tests.

Reading an implementation guide

Read the IG with three questions in mind. Usage: is each segment and element mandatory (M), optional (O) or conditional for this partner, which can differ from the standard. Qualifiers and codes: which values the partner sends, for example N1 with qualifier ST for ship-to, DTM with qualifier 002 for the requested delivery date, or PO1 with qualifier BP for the buyer's part number. Meaning: what the partner intends, such as whether the price in PO1 is a unit price the supplier must honor or only for information.

If you use Integration Advisor, the IG becomes a message implementation guideline (MIG): the partner's profile of the standard, with its qualifiers and code values, and the mapping becomes a mapping guideline (MAG). Even then, keep a human-readable spec that business users can sign and testers can test against; export or cross-reference it with the MAG so the two never drift.

Collect the partner's code lists early, because they become value mappings. Northern Plains sends units of measure as EA and CA, depot codes such as D07, and its own part numbers; each needs a known SAP counterpart (PC, a case quantity, a ship-to party, a material). Put every list in the spec as a table owned by a named person, and agree what happens when the partner adds a value: in practice, a new depot or part number is the most common change request after go-live.

The columns of a testable spec

The example column is the one teams skip and testers need most. A rule without an example invites two people to read it two ways; with an example, the expected result of the test case is already written.

Contoso's 850 to ORDERS05 spec for Northern Plains

Outbound documents need specs too

Teams write careful specs for the inbound 850 and then wing the outbound documents, which are the ones the partner validates. Write a spec for each: the 855 from the ORDRSP IDoc, the 856 from the delivery's DESADV IDoc (DELVRY07), and the 810 from the INVOIC IDoc (INVOIC02). The 856 deserves the most care because of its hierarchical levels (HL segments for shipment, order, pack and item, as the partner's guide requires) and because the partner matches it to its PO and its receiving dock. The 810 needs rules for totals: in X12 the TDS01 total invoice amount carries an implied two decimals, so 12,000.00 is sent as 1200000. Each of these rules gets an example, and each example becomes a test.

Gaps: what the EDI doesn't carry

Every spec finds data SAP needs that the partner doesn't send, and data the partner sends that SAP doesn't store. For inbound orders in SAP S/4HANA, the sales area usually isn't in the 850, so it is assigned to the customer for EDI in Customizing (transaction VOE2, table EDSDC); external partner numbers such as depot codes are converted to SAP partner numbers with transaction VOE4 (table EDPAR); and buyer part numbers are resolved through customer-material information records. Write each gap into the spec with its owner, and treat the conversion tables as test data that must be right before testing starts.