Maintaining value mappings

Source data speaks the old system's language: the legacy ERP's payment terms codes, old plant and warehouse codes, old units, old tax codes, old supplier account groups. The target speaks SAP S/4HANA's. Value mapping translates one into the other during the load, so that the files and staging tables can carry the original source values and the translation is documented, reviewed and repeatable.

Mapping tasks

When the cockpit prepares an object, it creates mapping tasks for the fields that need a target value. Each task lists the source values it found in the staging data and proposes a target value where the values are identical. A task stays open until someone confirms it, and an object cannot be simulated or migrated while it has open mapping tasks for values in the data. Typical mapping tasks for Contoso:

Fixed values and defaults

Besides translating values, some tasks set fixed values: a target field that is the same for every record, such as a default reconciliation account for suppliers in company code 1910 or a fixed purchasing group for migrated info records. Fixed values are powerful and dangerous at the same time: one wrong fixed value is applied to every record. Every fixed value needs the same owner approval as a mapping.

Maintaining mappings at scale

Entering a handful of values in the app is fine. Hundreds of payment terms or tax codes are not. Most releases let you download a mapping task's values as a file, fill the target values, and upload them again; check the options in your release. Contoso keeps the mapping specification approved by the data owners as the master, generates the upload file from it, and never edits mappings in the app without updating the specification.

Mappings and change control

Mappings live in the project, so a new project for the next mock starts without them unless you carry them across. Decide how mappings move from mock to mock (file upload, copy or transport, depending on the release and your setup) and check them every time. A mapping that was right in Mock 2 and lost in Mock 3 is one of the most common reasons why a later mock suddenly performs worse than an earlier one.

Keys and numbers

Mapping also touches record keys. If Contoso keeps the legacy supplier and product numbers, the target number ranges must allow external numbers in those intervals, and the migration templates carry the old numbers as the new ones. If new numbers are assigned, every later object that refers to a supplier (info records, open POs, open items) needs the translation from old key to new key; check in the object documentation how your release records and applies it. Watch for overlaps too: some Alternadores suppliers may already exist as business partners in Contoso's system, and they should be extended with company code 1910 data rather than created twice. Decide all this per object early and write it in the specification, because it changes how every dependent object is mapped and how testers find records afterwards.