Creating master data (and customizing, without customizing requests!) is a serious matter. Your data migration process better be executed properly and accurately. For one thing, it’s a tedious mess to clean up (archive) if things goes awry. Of course, as a Master Data Aficionado reading this article, you now have a plan for success.
Let's begin by recognizing that your Site Master business process design dictates where and when you'll be executing Site Master data migration.
Site Master Distribution is Best Practice in S/4HANA. If you've adopted that architecture then plan to execute Site Master data migration only in your Development Customizing Golden client. Then use Site Master Distribution to distribute those Site Masters to downstream systems-clients that require Site Masters.
What is being created?
Site Master is one business object comprised of many technical components.
Site Master data migration creates all of the above. Configuration is copied from a Reference Site to the new Site.
When should Site Masters be created?
I tend to wait as long as possible before creating all Sites! Why?
Here’s some key context:
- There are no automated tools to create configuration, including Site Master configuration.
- There is no standard mass update program for Site Master.
- While standard mass update functionality exists for Business Partner, there are limitations (e.g. it’s possible to update existing data, but not possible to create new data).
What’s more, what we understand to be “Site Master configuration” usually includes significant cross-functional configuration from Requirements Planning, Purchasing, Inventory Management, Sales, Manufacturing, and other business processes.
Given this, functional configurators should not make any customizing that includes entry of a Site number without first consulting Site Master experts for possible (likely) inclusion in a Reference Site. This is critical for for establishing a reliable and error-free New Site Creation process, as well as accurate data migration. Failure to do so is a common source of defects in most implementation projects.
It then follows that Site Master configuration can only considered "stable" after thorough cross-functional testing of the related configuration, followed by thorough testing of Reference Sites. That necessarily includes:
- Creating a new Site Master based on a Reference Site (for each flavor of Reference Site).
- Distributing the Site Master from the Customizing Golden client to a test system-client.
- Confirming that the new Site Master and its underlying configuration supports business process execution.
Given the above, and that corrections for defect resolution are potentially manual and time consuming, master data practitioners are understandably reluctant to create hundreds or thousands of Site Masters – especially in the Customizing Golden client! – until after the Site Master creation process has been thoroughly tested.
It’s a struggle during every implementation project to decide exactly when is the right time to create all Site Masters in the Customizing Golden client. There isn’t an easily prescribed time.
The master data team member responsible for Site Master would obviously prefer to wait until Integration Test Cycle 3, when the design is stable, and corrections are least likely. But that’s not practical. Most other teams will prefer immediate creation of all Site Masters, even before Integration Test Cycle 1. Your data migration team will want all Site Masters as soon as possible, to enable unit test and performance test of extension of Article Masters to all Sites. Unfortunately, all parties are correct in their respective judgments.
I would argue that it’s usually possible and preferred to hold off on creating all Site Masters until the beginning of Integration Test Cycle 1, when the first mock load of Article master will occur. Before then, create and test, create and test, and then create and test some more, and as often as practical. After that, you’ll likely have to create all Site Masters and accept the misery and cost of correcting defects or supporting changes.
Defects will follow in two flavors: Customizing and Master Data. To be prepared for this eventuality, it's an advantage if your Site Master data migration objects are capable not only of creating Sites and Site Business Partners, but are also capable of changing Sites and Site Business Partners.
Data Migration Program Options
SAP S/4HANA Migration Cockpit is the generally recommended tool for data migration in S/4HANA. But there is no standard content for Retail Site Master.
Also consider SAP Note 2586412, which documents function module DISTRIBUTE_SITE_DATA. The note explains that this function module is used to create and update site master data in SAP S4/HANA. Given this, you might be inclined to pair this function module with SAP S/4HANA Migration Cockpit and call it a day.
Besides the fact that function module DISTRIBUTE_SITE_DATA is not released for use by SAP customers (i.e. not supported, per SAP Note 109533), it suffers the same deficiency as its ECC 6.0 predecessor, described in SAP Note 1865903. When creating a Site Master, neither of these function modules consider Reference Sites or Site Profile Copy Rules, which are fundamental concepts in SAP Retail and critical to any process for Site Master creation (data migration is not an exception).
Using DISTRIBUTE_SITE_DATA for data migration of Site Master is not a solution, but only a first step in undertaking extremely-high-complexity development in the hope of successfully creating a customer-specific solution. This seems unusually bad advice, especially when a standard alternative exists.
Follow Standard Behavior
To understand the data migration approach, observe the standard system behavior when creating a Site Master.
As a first step, you create a Site Business Partner (BP) using standard T-Code BP. As a second step, you use standard T-Code WB01 to create the Site Master.
Because you've smartly observed the Best Practice for Site Numbers, that Site # and Site BP # are the same number, T-Code WB01 recognizes that the Site BP for the Site already exists, and it adopts the BP as the Site BP.
Based on this observation, the data migration approach is to likewise create Site Masters in a two-step process.
Step # 1: Create Site Business Partner
As a first step, create the Site BP. SAP S/4HANA Migration Cockpit is the recommended data migration tool for this step, but it comes with some constraints. The most notable is that it’s mainly for the initial creation of data and doesn’t easily support updates.
A flexible alternative, for both data migration of and integration with BP, is to create your own program based on a standard class that SAP provides for this purpose. For details, refer to SAP Note 2417298 - Creation of Business Partner with Customer and Supplier Roles, which advises that "to create Business Partner with Customer and/or Supplier roles in S/4HANA, we recommend to use standard API: CL_MD_BP_MAINTAIN."
This isn’t a small amount of work. But you should weigh the effort against risks and inflexibility associated with any other alternative. Moreover, this same conversion object is also required for other Business Partners (Suppliers and Customers), so you’re crafting a data migration object with relevance beyond Site Master.
Step # 2: Create Retail Site
As a second step, SAP recommends only the use of Extended Computer Aided Test Tool (eCATT) to create Site Masters via SAP GUI screen recording (see SAP Note 1274501 – Batch input, and e/CATT in the Site Master).
Note that SAP specifically recommends against using batch input or Legacy System Migration Workbench (LSMW) in the SAP Retail Site Master environment. eCATT is the standard and recommended tool because standard T-Code WB01 for Create Site is not batch enabled. Basically, this means that LSMW will fail when attempting to access subscreens via screen recording in T-Code WB01.
The aforementioned simplicity of executing T-Code WB01 means that the eCATT object will likewise be simple. That’s a very good thing.
Yes, it’s quite possible to use LSMW for minor updates of Site Master, as this video of LSMW Screen Recording demonstrates. But LSMW isn’t an option if you need to access a subscreen, so you shouldn’t use LSMW to create a data migration process for Site Master.
Instead, watch this real-world example eCATT for Site Master Data Migration being created in just 12 minutes: Simple eCATT Data Migration Example.
Summary
In summary, the process for data migration of Site Master include's the following steps:
- Create Site Business Partner
- Retail Site via SAP GUI screen recording (eCATT)
- SAP Managed Tags:
3 Comments
