Which ECC configuration will S/4HANA reject? Check it before the load: every value your vendors use, how many depend on it, and whether the new system has it. Step 3 of 6: map. SAP's Migration Cockpit will tell you a purchasing organization is not valid in S/4HANA. It tells you after the data is in the staging tables, one value at a time as someone confirms it, and it does not say how many vendors depend on that value. Step 1 profiled the system. Step 2 decided which vendors were worth keeping and corrected them at source. This step keeps the same running example, the vendor master, and checks the configuration each vendor carries, purchasing organization, payment method, reconciliation account and account group, against the new system, well before the load, so the gaps are decided rather than discovered. This post covers the three questions the mapping flow answers, why the vendor counts matter, and how the replace-with column carries the decisions into the load. Step 3 of 6: the configuration your vendors use, what S/4HANA accepts, and where the two do not line up, in one flow. Also available on YouTube. Why map before the loadThe running example is the vendor master from step 2: the vendors kept after cleansing, and the configuration each one carries. In this example the target is a greenfield S/4HANA system. Its configuration is built fresh, so every value a vendor carries has to exist there before that vendor can load: the purchasing organization, the payment method, the reconciliation account, the account group. The cleansing flows from step 2 corrected most of the data errors at source, but some were deliberately left unresolved to show what happens here. The Migration Cockpit's Fiori app checks each target value when you confirm it. That is useful, but it only sees configuration values once the data is in the staging tables, it works one value at a time, and it does not tell you how many vendors depend on each value. Well before the load, the questions are different: what is actually in use, what will the new system accept, and where do the two not line up? With those answered, the program can decide what to configure in S/4HANA and what to map to a different value. One flow, one lane per section of the vendor dataThe DVW Flow Tool flow is laid out in lanes, one for each section of the vendor data, which makes it easy to follow, document, and work through with stakeholders. Each lane reads both systems, ECC and S/4HANA, for the latest snapshot, so the comparison is always between what is there now on both sides. 1. What is actually in useNot what is configured in ECC, only what is used by the vendors you decided to keep and migrate. Each value comes out with the number of vendors behind it. The counts are the point. A value used by hundreds of vendors has to exist in the new system, no discussion. A value used once might be an old mistake that should be mapped away rather than configured. Without the count, every gap looks the same size. 2. What S/4HANA acceptsThe same flow reads the new system's own configuration, so the check is against what is really in S/4HANA right now, not a spreadsheet from last month. On a greenfield project the configuration moves weekly, and a mapping built against a stale extract fails for reasons that were fixed days ago. 3. Where the two do not matchJoin the two and the interesting part is where there is no match. Every vendor on one of those values would be rejected during a load to S/4HANA. A few of the checks need more than a straight code lookup:
The list the S/4HANA team works fromWhat comes out is one list: each value, how many vendors use it, and whether the new system has it. For every gap there are two choices. Configure the value in S/4HANA, or type what to use instead in the replace-with column. The column is only filled where there is a gap, and the answers are kept every time the flow reruns, so the decisions accumulate rather than being redone. At load time the next flow picks up those replacements automatically. If the program would rather hold the mappings in SAP, the same targets can be set in the Migration Cockpit's own mapping screen. Both work, so use whichever you prefer. That is mappingFind out what is in use, check it against the new system, and get the gaps decided before they become failed loads. Next in the series is the mock load, where the Flow Tool fills SAP's own migration templates straight from ECC data. For the wider picture see the SAP data migration solution page. In this series
Find your own mapping gaps before the loadRead and write SAP data from any analytics or data platform. Free 30-day trial, full functionality, no commitment. Trusted by 500+ enterprises. Comments are closed.
|