Lesson 3 of 6
Mapping and master data
10 min
Listen to this lesson
Every source document arrives with source keys: company code, G/L account, customer, supplier, cost center, profit center, document type, payment terms. The central system posts with central keys. Mapping translates one into the other, and it is where most Central Finance effort, and most defects, live.
Key mapping and value mapping
Central Finance uses the mapping framework of SAP Master Data Governance (MDG). Key mapping handles long-lived master data, such as customers, suppliers, G/L accounts and cost centers: "customer 30155 in source A is 17100001 in the central system". Value mapping handles configuration values, such as company codes, document types, payment terms and payment methods: "payment term CR30 in the legacy ERP is 0004 centrally". Value mappings are usually built in development and transported; key mappings are created as master data is created, often by MDG or by replication.
| Source (what-if) | Object | Source value | Central value | Mapping type |
|---|---|---|---|---|
| Alternadores legacy ERP | Customer | Flotillas Monterrey, legacy ID | Business partner in the central system | Key |
| Alternadores legacy ERP | Payment term | CR30 | 0004 | Value |
| Alternadores legacy ERP | Company code | Legacy entity code | 1910 | Value |
| EP1 | Customer | 17100001 | 17100001 (same key) | Key, identity |
| EP1 | G/L account | ECC operational account | Harmonized central account | Key |
Mapping examples in the evaluated design. Values are illustrative course data.
Mapping actions
For each mapping entity and source, configuration defines what the central system does with incoming values. The common actions are: keep data (post the source value unchanged, sensible when keys are already harmonized), mapping obligatory (a mapping must exist or the document fails), mapping if possible (map where a mapping exists, otherwise keep the value) and clear data (drop the value). Check the exact names and options in your release. The choice is a control decision: mapping if possible lets documents through when a mapping is missing, which keeps the error queue short but may post wrong central values silently.
Master data governance
Mappings need owners. In the what-if design, Contoso planned MDG on the central system as the hub for business partners, G/L accounts and cost centers: new master data would be created centrally, distributed to the sources, and the key mapping recorded at the same time. Governing key mappings themselves through an MDG change request process is not standard out of the box and typically needs extension, so plan the effort. For the Alternadores legacy ERP, which could not receive distributed master data, mappings would be maintained manually and reviewed monthly.
Cost objects need special care. Production orders and internal orders created in the source are replicated or mapped to central cost objects through the cost object mapping framework, so that costs and settlements land on the right central object. A production order such as 1001200 in EP1 would exist in the central system as a corresponding cost object, with the mapping recorded.
What would you do?
In the first integration test, 3% of documents from the Alternadores legacy ERP post centrally with legacy payment terms that do not exist in the central system's configuration. No errors appear in AIF. What explains it?
What goes wrong in testing
| Symptom | Cause | Test |
|---|---|---|
| Unknown values in central documents | Mapping if possible on a field that must be mapped | Query central documents for values outside central configuration |
| Mapping works in QAS, fails in production | Key mappings created in QAS were not recreated in production | Rebuild key mappings in a production-like dry run |
| Two sources collide | Same source ID used in both sources, mapped as one | Test mappings per source system, never globally |
| Settlement lands on wrong object | Cost object mapping incomplete | Follow one production order from source to central settlement |
Mapping defects to look for.
A worked example: one supplier invoice
Follow one EP1 supplier invoice for company code 1710 through the mappings: Lakeside Components invoices 500 rotors CMC-RTR-200 at USD 42.00 against purchase order 4500002246, a total of USD 21,000.00. The table shows what a tester checks in the central document. Where source and central keys are already the same, the mapping action is keep data; where Contoso's what-if design harmonized values, a mapping applies.
| Field | Source (EP1) | Central document | Mapping |
|---|---|---|---|
| Company code | 1710 | 1710 | Keep data |
| Supplier | 17300001 Lakeside Components | 17300001 | Key mapping, identity |
| Reconciliation account | ECC payables account | Harmonized central payables account | Key mapping |
| GR/IR clearing account | ECC GR/IR account | Harmonized central GR/IR account | Key mapping |
| Document type | RE | RE | Value mapping, identity |
| Payment terms | Source term | Central term | Value mapping |
| Amount | USD 21,000.00 | USD 21,000.00 | Never mapped; must be equal |
Field-by-field expectations for one replicated supplier invoice (illustrative).
A good mapping test has one line per field and an expected central value written before the run. The amount row is the control: amounts are never mapped, so any difference there is a defect, not a design choice.
- Key mapping translates master data IDs; value mapping translates configuration values.
- Mappings belong to a source system.
- Mapping actions trade error volume against the risk of silent wrong values.
- MDG can create master data centrally and record key mappings; governing mappings in MDG needs extension.
Check your understanding · not graded
Lesson check
1. Which mapping type translates payment terms such as CR30 to 0004?
2. Which mapping action lets unmapped values pass through unchanged?
3. Why must mappings be defined per source system?
4. What does the cost object mapping framework ensure?