If you’re an SAP Retail functional person, it helps to be familiar with relevant IDocs. And if you’re a Master Data Aficionado, it’s kind of expected. This article explains the most common mistake made when attempting to create Generic/Variant Articles in data migration. It’s all about understanding the functional use of ARTMAS IDoc segments.
Data Migration doesn’t fit well into project tracking schemes. Unsurprisingly, the frustration of stakeholders eventually becomes palpable on every project.
The universal question I hear is: “When will the data migration deliverables be “done?”
If you ask me — the functional master data guy — when data migration will be “done” then the honest answer is clear: “The day before go-live.” When will the data migration functional specification be done? Same answer. Go ahead and ask the technical team when the data load program will be finished. “That depends on the functional specification. Oh, and you’re not going to change anything over time, are you?” For some reason, replies like these reliably produce eye rolls.
Converting a standard Plant into an SAP Retail Site Master is a niche topic. But it’s also a window through which to view the differences between these two business objects.
What’s more, SAP S/4HANA’s Industry to Core and the trend of Manufacturers with Retail operations combine to make the topic of Plants versus Retail Sites increasingly relevant.
What was true about Generic Article and Variants in SAP ECC 6.0 has changed from top-to-bottom.
With SAP S/4HANA, in keeping with SAP’s movement of Industry to Core, the implementation of the SAP Retail concept of Generic Article and Variants dramatically changed to align with concepts found in standard Variant Configuration (LO-VC). The result is significant technical change, but also significant business process change, as one would reasonably expect when master data concepts are rearranged.
I am not “all-in” on SAP S/4HANA Migration Cockpit.
Analysts warn that 83% of all data migration projects either fail or significantly exceed budgets. Like a poker table full of serious faces in a swanky casino, the stakes in data migration are sky high. Before going all-in on a single bet of such consequence, you’d better consider the big picture.
Yes, I understand that it’s the recommended tool for loading data into SAP S/4HANA, and has been for 5 years. And — for as many years — it’s been touted as the successor to Legacy System Migration Workbench (LSMW), which is no longer considered strategic. It’s not that SAP S/4HANA Migration Cockpit isn’t usable. After five years of steady revision, it’s achieved that mark, albeit with constraints. And it introduces important innovation, such as Direct Transfer, to transfer data directly from an SAP system. That’s all super-good news, but it’s insufficient information.
Data and business process owners: What numbers should we use for Products, Locations, Suppliers, Customers … and so on? A seemingly simple question, but the consequences of your answer are many and without end. Tread carefully!
Implementing SAP S/4HANA illustrates the universal subject, but with nuances that require your attention to stay clear of trouble.
As usual, observing a few experience-based principles can promote good outcomes for Master Data and business processes, now and in future.
You can load inventory quantity and value for materials in S/4HANA 2020 using IDoc Type MBGMCR04.
Yes, SAP S/4HANA Migration Cockpit is the “recommended by SAP” tool for loading data in S/4HANA. But there are exceptions to its efficacy. For example, IDoc type MBGMCR is exactly how it’s done in SAP Rapid Data Migration with SAP Data Services (On Premise), Migration Inventory Balances (W38).
If you’re not using SAP Data Services then Legacy System Migration Workbench (LSMW) is also relevant, using exactly the same IDoc approach that SAP delivers with Rapid Data Migration. What’s more, LSMW (more precisely, IDocs) remains essential for data migration in SAP Retail. For confirmation of necessity, see SAP Note 2538170 – Migration of Retail Objects to SAP S/4HANA on-premise.
MDA Workbench is a free and simple tool for creating such LSMW projects, and for creating a comprehensive kit of deliverables for data migration.
Excluding production, I’m regularly astonished by lax Security and Controls in SAP Landscapes. With S/4HANA, astonishment becomes concern.
I’m not talking about the blatantly obvious; no, we don’t regularly see SAP_ALL granted in Development systems as in days of yore. It’s more subtle than that, but perhaps not by much.
Is this Product authorized for business processes at this Location on this date?
In SAP Retail, Listing Conditions answer this simple question, but the complexity of producing the answer is massively underappreciated.
There are three main parts to the story: Data Management (business process), Execution (system process), and Listing Conditions (the result). And then there are common exception scenarios to be handled.
We use the words Reference Sites imprecisely. It’s a problem because there are many kinds of Reference Sites. Two, in particular, are often conflated and thus misunderstood.