Lesson 1 of 5
Translating codes
8 min
Listen to this lesson
Most interface failures are loud: a connection is refused, a mapping throws an exception, an IDoc lands in status 51. Code translation failures are quiet. A unit code that isn't translated passes through unchanged, the partner's system reads it as something else, and 500 pieces become 500 cases. Nobody gets an error message; somebody gets the wrong delivery. That is why this course treats translation tables as master data that must be designed, owned and tested.
Contoso's move from SAP Process Orchestration on XP1 to SAP Integration Suite brings this into focus. Theo's team has 64 integrated configurations to sort through, and many of them use PI value mapping groups maintained in the Integration Directory, plus FixValues tables inside ESR mappings. Every one of those tables has to land somewhere in Cloud Integration, with the same content and a named owner.
Theo's first step was an inventory. For every PI value mapping group in the Integration Directory and every FixValues table in the ESR mappings, the team recorded which interfaces use it, who changes it and how often, and whether S/4HANA already holds the same information. That list drove every decision in this course: some tables moved as they were, some merged, and a few disappeared because the data already existed in SAP master data.
What gets translated
| Code | SAP side (Contoso) | Partner side | What goes wrong if it's missed |
|---|---|---|---|
| Unit of measure | ISO unit in the IDoc, e.g. PCE for pieces | X12 unit code, e.g. EA (each) | Quantities are read in the wrong unit |
| Plant / ship-from | Plants 1710 Detroit and 1720 Chicago | Great Lakes' location codes, e.g. DET and CHI | Orders are scheduled from the wrong plant |
| Partner identifier | Customer or supplier number in S/4HANA | DUNS, GLN or the partner's own ID | Messages are rejected or posted to the wrong account |
| Payment terms, tax and qualifier codes | SAP keys such as 0004 | Partner or standard code lists | Invoices are held or short-paid |
Typical translations in Contoso's EDI interfaces. Partner codes here are illustrative; always take them from the partner's specification.
Where a translation can live
Cloud Integration gives you several places to put a translation, and the choice decides who can change it and how fast. Hard-coded conditions (an if-chain in a mapping or a script) are fast to write and the worst to maintain: every change is a development change. FixValues is a standard function whose table is saved inside the message mapping; changing it means editing and redeploying the mapping. A Value Mapping artifact lives in the integration package, is deployed on its own and can be read in both directions. The Partner Directory holds partner-specific parameters. And a lookup, a call to S/4HANA during the flow, reads the translation from master data that already exists there.
| Option | Who changes it | Change needs | Best for |
|---|---|---|---|
| Hard-coded condition | Developer | Code change, test, deploy | Nothing that the business might change |
| FixValues | Developer | Mapping change, deploy | Small, stable lists owned by the interface, such as fixed qualifiers |
| Value Mapping artifact | Integration team on request of the business owner | Edit or configure and deploy the artifact only | Code lists shared by flows or changed a few times a year |
| Partner Directory | Integration team | Update the partner's parameters | Settings that differ by partner (sap-pim-205) |
| Lookup in S/4HANA | Business, in master data | Nothing in Cloud Integration | Translations already maintained in SAP, e.g. customer material numbers |
- Is the translation already maintained in S/4HANA master data?Yes → look it up or let S/4HANA send the partner's code · No → next question
- Does it differ by partner rather than by code?Yes → Partner Directory parameter · No → next question
- Will the business change it, or is it shared by several flows?Yes → Value Mapping artifact · No → next question
- Is it a handful of fixed values owned by one mapping?Yes → FixValues · No → revisit the design before hard-coding anything
FixValues in practice
FixValues is the right tool more often than its reputation suggests. You fill a small key and value table in the function's parameters, and it travels with the mapping, versioned and transported with it. Contoso's ORDERS05-to-850 mapping uses it for the X12 purpose and type codes in the BEG segment: the SAP purchase order type NB becomes the order type code SA (stand-alone order). That list belongs to the interface, not to the business, and changing it is a deliberate interface change. Set the function's handling of keys that aren't in the table on purpose; don't leave it to whatever the default happens to be, and test it like a value mapping.
Don't translate what SAP already knows
Before creating a table, check whether S/4HANA can produce the partner's code itself. Customer material numbers are a good example. If Great Lakes Fleet Services orders with its own part numbers, the customer-material information records in sales can translate them during order creation, and the inbound IDoc can carry the customer's number in E1EDP19 with qualifier 001. A second copy of that list in Cloud Integration would only drift. The same goes for ISO unit codes, which S/4HANA maintains with its units of measure.
- Translation failures are silent, so they need design, owners and tests.
- FixValues lives inside one mapping; a Value Mapping artifact is deployed on its own and works in both directions.
- Partner-specific settings belong in the Partner Directory; master data translations stay in S/4HANA.
- Never hard-code a list the business may change.
Check your understanding · not graded
Lesson check
1. Where is a FixValues table stored?
2. Great Lakes orders with its own part numbers. What is Contoso's preferred translation?
3. Why does the course call code translation failures quiet?
4. A setting differs by trading partner, such as the X12 version each one uses. Where does it belong?