SAP Retail Site Master Distribution prompts questions from many teams: Basis, Security, Network / Infrastructure, and Controls / Compliance. Oh, and the Master Data team is very interested too.
The context is that SAP Retail Site Masters are created in the Development Customizing Golden system-client and then distributed to all downstream systems-clients that require Site Masters. This is the production process.
The key design decision to adopt Site Master Distribution establishes one version of the truth for Site Master as a business object, including customizing and master data. Data Replication Framework (DRF) is the standard functionality that enables the distribution process.
SAP customers typically place Site Master creation and maintenance either within their Finance organization (because they are usually the first to know about a new location) or within a centralized master data team. In any case, only two – or a few – individuals in an organization are typically granted authorization to maintain and distribute Site Master data. This is true even in organizations with thousands of Site Masters.
Site Master maintenance and distribution is rooted in standard functionality, well documented, and tightly controlled.
The individual who executes Site Master maintenance and distribution only executes steps according to a Business Process Procedure (BPP), which is click-by-click documentation for a standard procedure. This is a very narrow scope of authorization and process execution, and never (or almost never) includes authorization to perform configuration.
Any requirement or process step that falls outside of the BPP is, by definition, not part of the Production process and requires exception handling by a Production support team or becomes a small IT project. In such cases, a Production support team or a Project team, with configuration authorization, would lead configuration and maintenance activities.
Any change to the Production process would prompt updates to Site Master Business Process Procedure documents.
Site Master Distribution is typically executed by the same individual who performed Site Master creation and maintenance. That individual has the most intimate understanding of which target systems-clients should receive Site Masters and when.
Yes, it does.
That prompts a requirement for a specific Security role in the Customizing Golden client, and perhaps for downstream Quality and Performance systems-client as well.
Development and Quality systems in an SAP landscape are always considered part of the production support landscape; any unavailability or downtime constrains your ability to implement and test fixes for production support issues.
The fact that Production master data is maintained in a Development system-client does heighten system-availability sensitivity, but this is mitigated by straightforward procedures. Your plan for Development system unavailability should include permitting a user with a Firefighter ID to create and maintain Site Masters directly in Production, followed by steps to backfill the Customizing Golden client (when available), followed by controlled distribution and testing for all downstream systems-clients that require Site Masters.
It’s a potential scenario – like many others – deserving of recognition and attention, but it doesn’t likely add to formal Development system availability requirements.
Maintaining one version of the truth in your Customizing Golden client can potentially pose a challenge when you have a business requirement for “multiple versions of the truth” across the landscape.
Recognizing the scenario is the first step, and some combination of activity coordination and planned system adjustment over time then follows. Options exist to influence both when Site Masters are distributed, and exactly what data will be distributed. Given how few individuals participate in the process, coordination usually requires little effort.
A classic example is the creation of a Distribution Center, which usually includes customizing that falls outside of the production Site Master creation process, which is focused mainly on the cookie-cutter nature of Stores. Such a Site Master may require a coordinated process that considers the timing and sequence of Site Master Distribution and possibly-related customizing request(s).
Another common example involves introduction of a new business process that includes customizing for Site Masters, especially for Sites that already exist in Production. In this scenario, you want to introduce or change Site-specific customizing or master data in Development, and then Quality systems, must avoid transferring specific customizing or master data to Production until a future release date. That’s a very generic scenario description. Realize that your specific scenario will require an equally situation-specific response, with consideration of your situation-specific table- and field-level details.
For example, it’s possible via configuration to control the specific list of tables that will be transferred during Site Master Distribution.
For finer grained control, consider SAP Note 2661831 – Site distribution via DRF: BAdI method for influencing Site Master data. You want to distribute a Site Master between two SAP S/4HANA systems using DRF, but before transferring the Site Master data, you want to do some checks to remove or enhance the data to be distributed. You can use this note to activate the BAdI BADI_SITE_DISTR to carry out your own checks, and to adopt the data to be distributed.
You have complete control of the “when and where” when configuring and executing Site Master Distribution. While automatic distribution is possible, it’s typical that distribution of Site Master(s) is a deliberate step, executed by a responsible individual, with Site Masters distributed to specific systems-clients.
You have complete control of the specific list of Site Master and Customizing tables to be transferred during Site Master Distribution. It’s configuration.
Here’s the relevant customizing path:
SPRO > Logistics – General > Plant Master > Settings for Plant Replication > Maintain Tables for Plant Transport
Also see the contents of table SITE_DISTR_TABS, which holds this customizing.
In this Customizing activity, you determine which tables are to be transferred with a Site via DRF. You can also add Customizing tables that you maintain for Site Masters, in addition to the standard tables. SAP Note 2659797 explains that adding additional tables includes a small development activity: you need to add to the structure SITE_DISTR_SITE_STY for each additional table.
Additionally, SAP Note 2659797 states: “Add a component with the name of the table to the include. The component type must be a standard table and the name of the row type of the table must be the same as the name of the transparent table.”
In practice, we find that it’s possible to add a custom table (a Z Table) to structure SITE_DISTR_SITE_STY and to the list of tables in Maintain Tables for Plant Transport. With this, it’s possible to add your own customizing or master data tables to the Site Master Distribution process. You can combine this functionality with the addition of Z-Tables to your Site Profile Copy Rule to maximize the possibility that your Site Master maintenance process does not require follow on configuration steps.
Here’s some key context:
What’s more, what we understand to be “Site Master configuration” potentially includes significant configuration that’s relevant for Requirements Planning, Purchasing, Inventory Management, Sales, Manufacturing, and more functions.
Site Master configuration is only considered stable after thorough testing that necessarily includes:
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 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 judgements.
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 that you know will follow.
Defects will arrive in two flavors: Customizing and Master Data. To be prepared for this eventuality, make certain that 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.
Site Master usually includes lower-level master data assignments, with the most obvious example being Merchandise Categories assigned to a Site.
If you wanted to assign Merchandise Categories to Sites in the Customizing Golden client, then you’d first have to create the Merchandise Categories in the Customizing Golden client, and then expect to maintain them there as an ongoing master data process. But you don’t want any more master data – or any more master data maintenance – in the Customizing Golden client than necessary.
Let’s talk about so-called Split Maintenance, whereby some Site master data is maintained in the Customizing Golden client, but other Site master data (e.g. assignment of Merchandise Categories to Site) is maintained directly in downstream systems-clients (including Production) after the Site Master is distributed.
Your design and configuration must consider and enable this possibility on a table-by-table basis.
For example, if you don’t maintain the assignment of Merchandise Categories to Sites in the Customizing Golden client, and you distribute a Site Master from your Customizing Golden client to Production, where the assignments have separately been maintained, then the assignments in Production will be deleted. That makes perfect sense, as the Site Master was faithfully replicated. But it’s not the desired outcome.
The solution, for any table that you want to maintain in downstream systems-clients (including Production), is to remove the table from the list of tables considered in Site Master distribution.
Following our example, table WRF6 holds the list of Merchandise Categories assigned to a Site Master. If you remove table WRF6 from the list of tables to be distributed, then existing Merchandise Categories assignments in recipient systems-clients are not disturbed by Site Master distribution.
[[ Read this for a detailed explanation: Site Master Data Migration: What, When, and How To ]]
Plan to execute data migration for Site Master in your Customizing Golden client, and then distribute those Site Masters to all downstream systems-clients that require Site Masters. The data migration scenario is the same as the production scenario; Site Master are only created in your Customizing Golden client. But how to automate this?
SAP S/4HANA Migration Cockpit is the recommended tool for data migration in S/4HANA. But there is no standard content for 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 109553), 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.
To understand the data migration approach, observe the standard system behavior when creating a Site Master by using T-Code BP followed by T-Code WB01.
As a first step, create a Site Business Partner (BP) using T-Code BP. Then use WB01 to create the Site Master. Because you have observed the Best Practice that Site # and Site BP # are the same number, WB01 recognizes that the Site BP for the Site exists and adopts the BP that was created independently in the first step.
Based on this observation, the data migration approach is likewise to create Site Masters in a two-step process.
As a first step, create the Site BP? While use of SAP S/4HANA Migration Cockpit is the recommended approach, 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.
The flexible alternative for BP, both for data migration and integration, is to create your own load program based on a standard class provided for this purpose. 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 work effort against risks and inflexibilities 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 scope and relevance far beyond Site Master.
As a second step, SAP recommends the use of Extended Computer Aided Test Tool (eCATT) to create Site Masters via screen recording (see SAP Note 1274501 – Batch input, and e/CATT in the Site Master). Note that SAP does not recommend using batch input or Legacy System Migration Workbench (LSMW) in the SAP Retail Site Master environment. It’s recommended that you use the eCATT function instead of batch input.
Site Master data migration via screen recording ensures that considerable (and standard) master data and configuration copy functionality for Site Master is considered in the data migration process. Before executing Site Master data migration, it’s critical that Site Profiles and Reference Sites, which are specified in Site profiles, are thoroughly tested.
In summary, the process for data migration of Site Master will include the following steps:
For all practical purposes, No.
There is no standard program or content to support this requirement. Consider the complexity described in answer to What’s the Data Migration scenario for Site Master?
The configuration versus master data dichotomy for Site Master rages on even as you consider ordinary Basis tasks such as a Client copy.
Site Master tables are technically defined as Customizing. For this reason, they are included in a Client Copy that excludes master data. But we understand that Site Master tables need to be considered as master data in some scenarios.
On this point, consider SAP Note 2665614 – List of site tables to be excluded in client copy.
SAP Note 2665614 warns that if you carry out a Client Copy operation then Site maintenance, Site distribution and other Site related processes do not work correctly in the copied client. Whoops.
Be aware that SAP Note 2665614 only provides an initial list of tables to be excluded during a Client Copy, based on defaults and SAP delivered content.
The list is only a starting point from which a Site Master functional analyst must publish an actual list of tables to be excluded, according to your specific implementation. The prerequisite steps in your Client Copy protocol will include checking both your implementation-specific table-exclusion list and also the latest version of SAP Note 2665614 (for possible additions).
Business Partner Key Mapping presents another consideration after performing a Client Copy. Just as the system uses a GUID to internally identify a Business Partner, it also uses a GUID in Business Partner Key Mapping to identify the sending and recipient system-clients. After a system copy or a client copy, the link between the system-client number and the GUID may no longer be correct, which will cause Site Master Distribution to fail.
Standard T-Code MDG_ADJUST_IDM (Adjust Key Mapping after Client Copy) is provided to correct the error condition. The transaction runs in just a few seconds because it doesn’t create new BP Key Mapping entries, it simply changes one entry in table UKMDB_AGCBNSS0.
The context is that SAP Retail Site Masters are created in the Development Customizing Golden system-client and then distributed to all downstream systems-clients that require Site Masters. This is the production process.
The key design decision to adopt Site Master Distribution establishes one version of the truth for Site Master as a business object, including customizing and master data. Data Replication Framework (DRF) is the standard functionality that enables the distribution process.
01 – Who maintains Site Masters?
SAP customers typically place Site Master creation and maintenance either within their Finance organization (because they are usually the first to know about a new location) or within a centralized master data team. In any case, only two – or a few – individuals in an organization are typically granted authorization to maintain and distribute Site Master data. This is true even in organizations with thousands of Site Masters.
02 – What governance typically exists in the Production process?
Site Master maintenance and distribution is rooted in standard functionality, well documented, and tightly controlled.
The individual who executes Site Master maintenance and distribution only executes steps according to a Business Process Procedure (BPP), which is click-by-click documentation for a standard procedure. This is a very narrow scope of authorization and process execution, and never (or almost never) includes authorization to perform configuration.
03 – Are there exceptions to who maintains Site Masters?
Any requirement or process step that falls outside of the BPP is, by definition, not part of the Production process and requires exception handling by a Production support team or becomes a small IT project. In such cases, a Production support team or a Project team, with configuration authorization, would lead configuration and maintenance activities.
Any change to the Production process would prompt updates to Site Master Business Process Procedure documents.
04 – Who Executes Site Master Distribution?
Site Master Distribution is typically executed by the same individual who performed Site Master creation and maintenance. That individual has the most intimate understanding of which target systems-clients should receive Site Masters and when.
05 – My Development system includes Production data?
Yes, it does.
That prompts a requirement for a specific Security role in the Customizing Golden client, and perhaps for downstream Quality and Performance systems-client as well.
06 – Does my Development system have new availability requirements?
Development and Quality systems in an SAP landscape are always considered part of the production support landscape; any unavailability or downtime constrains your ability to implement and test fixes for production support issues.
The fact that Production master data is maintained in a Development system-client does heighten system-availability sensitivity, but this is mitigated by straightforward procedures. Your plan for Development system unavailability should include permitting a user with a Firefighter ID to create and maintain Site Masters directly in Production, followed by steps to backfill the Customizing Golden client (when available), followed by controlled distribution and testing for all downstream systems-clients that require Site Masters.
It’s a potential scenario – like many others – deserving of recognition and attention, but it doesn’t likely add to formal Development system availability requirements.
07 – Are there downsides to maintaining Site Masters in the Customizing Golden client?
Maintaining one version of the truth in your Customizing Golden client can potentially pose a challenge when you have a business requirement for “multiple versions of the truth” across the landscape.
Recognizing the scenario is the first step, and some combination of activity coordination and planned system adjustment over time then follows. Options exist to influence both when Site Masters are distributed, and exactly what data will be distributed. Given how few individuals participate in the process, coordination usually requires little effort.
A classic example is the creation of a Distribution Center, which usually includes customizing that falls outside of the production Site Master creation process, which is focused mainly on the cookie-cutter nature of Stores. Such a Site Master may require a coordinated process that considers the timing and sequence of Site Master Distribution and possibly-related customizing request(s).
Another common example involves introduction of a new business process that includes customizing for Site Masters, especially for Sites that already exist in Production. In this scenario, you want to introduce or change Site-specific customizing or master data in Development, and then Quality systems, must avoid transferring specific customizing or master data to Production until a future release date. That’s a very generic scenario description. Realize that your specific scenario will require an equally situation-specific response, with consideration of your situation-specific table- and field-level details.
For example, it’s possible via configuration to control the specific list of tables that will be transferred during Site Master Distribution.
For finer grained control, consider SAP Note 2661831 – Site distribution via DRF: BAdI method for influencing Site Master data. You want to distribute a Site Master between two SAP S/4HANA systems using DRF, but before transferring the Site Master data, you want to do some checks to remove or enhance the data to be distributed. You can use this note to activate the BAdI BADI_SITE_DISTR to carry out your own checks, and to adopt the data to be distributed.
08 – Are Sites distributed everywhere, all at once?
You have complete control of the “when and where” when configuring and executing Site Master Distribution. While automatic distribution is possible, it’s typical that distribution of Site Master(s) is a deliberate step, executed by a responsible individual, with Site Masters distributed to specific systems-clients.
09 – How do I know which tables are being distributed?
You have complete control of the specific list of Site Master and Customizing tables to be transferred during Site Master Distribution. It’s configuration.
Here’s the relevant customizing path:
SPRO > Logistics – General > Plant Master > Settings for Plant Replication > Maintain Tables for Plant Transport
Also see the contents of table SITE_DISTR_TABS, which holds this customizing.
In this Customizing activity, you determine which tables are to be transferred with a Site via DRF. You can also add Customizing tables that you maintain for Site Masters, in addition to the standard tables. SAP Note 2659797 explains that adding additional tables includes a small development activity: you need to add to the structure SITE_DISTR_SITE_STY for each additional table.
Additionally, SAP Note 2659797 states: “Add a component with the name of the table to the include. The component type must be a standard table and the name of the row type of the table must be the same as the name of the transparent table.”
In practice, we find that it’s possible to add a custom table (a Z Table) to structure SITE_DISTR_SITE_STY and to the list of tables in Maintain Tables for Plant Transport. With this, it’s possible to add your own customizing or master data tables to the Site Master Distribution process. You can combine this functionality with the addition of Z-Tables to your Site Profile Copy Rule to maximize the possibility that your Site Master maintenance process does not require follow on configuration steps.
10 – During an implementation project, is the timing of Site Master creation important?
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” potentially includes significant configuration that’s relevant for Requirements Planning, Purchasing, Inventory Management, Sales, Manufacturing, and more functions.
Site Master configuration is only considered stable after thorough testing 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 Site Master and 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 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 judgements.
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 that you know will follow.
Defects will arrive in two flavors: Customizing and Master Data. To be prepared for this eventuality, make certain that 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.
11 – What other master data is required in the Customizing Golden client to support Site Masters?
Site Master usually includes lower-level master data assignments, with the most obvious example being Merchandise Categories assigned to a Site.
If you wanted to assign Merchandise Categories to Sites in the Customizing Golden client, then you’d first have to create the Merchandise Categories in the Customizing Golden client, and then expect to maintain them there as an ongoing master data process. But you don’t want any more master data – or any more master data maintenance – in the Customizing Golden client than necessary.
Let’s talk about so-called Split Maintenance, whereby some Site master data is maintained in the Customizing Golden client, but other Site master data (e.g. assignment of Merchandise Categories to Site) is maintained directly in downstream systems-clients (including Production) after the Site Master is distributed.
Your design and configuration must consider and enable this possibility on a table-by-table basis.
For example, if you don’t maintain the assignment of Merchandise Categories to Sites in the Customizing Golden client, and you distribute a Site Master from your Customizing Golden client to Production, where the assignments have separately been maintained, then the assignments in Production will be deleted. That makes perfect sense, as the Site Master was faithfully replicated. But it’s not the desired outcome.
The solution, for any table that you want to maintain in downstream systems-clients (including Production), is to remove the table from the list of tables considered in Site Master distribution.
Following our example, table WRF6 holds the list of Merchandise Categories assigned to a Site Master. If you remove table WRF6 from the list of tables to be distributed, then existing Merchandise Categories assignments in recipient systems-clients are not disturbed by Site Master distribution.
12 – What’s the Data Migration scenario for Site Master?
[[ Read this for a detailed explanation: Site Master Data Migration: What, When, and How To ]]
Plan to execute data migration for Site Master in your Customizing Golden client, and then distribute those Site Masters to all downstream systems-clients that require Site Masters. The data migration scenario is the same as the production scenario; Site Master are only created in your Customizing Golden client. But how to automate this?
SAP S/4HANA Migration Cockpit is the recommended tool for data migration in S/4HANA. But there is no standard content for 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 109553), 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.
To understand the data migration approach, observe the standard system behavior when creating a Site Master by using T-Code BP followed by T-Code WB01.
As a first step, create a Site Business Partner (BP) using T-Code BP. Then use WB01 to create the Site Master. Because you have observed the Best Practice that Site # and Site BP # are the same number, WB01 recognizes that the Site BP for the Site exists and adopts the BP that was created independently in the first step.
Based on this observation, the data migration approach is likewise to create Site Masters in a two-step process.
As a first step, create the Site BP? While use of SAP S/4HANA Migration Cockpit is the recommended approach, 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.
The flexible alternative for BP, both for data migration and integration, is to create your own load program based on a standard class provided for this purpose. 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 work effort against risks and inflexibilities 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 scope and relevance far beyond Site Master.
As a second step, SAP recommends the use of Extended Computer Aided Test Tool (eCATT) to create Site Masters via screen recording (see SAP Note 1274501 – Batch input, and e/CATT in the Site Master). Note that SAP does not recommend using batch input or Legacy System Migration Workbench (LSMW) in the SAP Retail Site Master environment. It’s recommended that you use the eCATT function instead of batch input.
Site Master data migration via screen recording ensures that considerable (and standard) master data and configuration copy functionality for Site Master is considered in the data migration process. Before executing Site Master data migration, it’s critical that Site Profiles and Reference Sites, which are specified in Site profiles, are thoroughly tested.
In summary, the process for data migration of Site Master will include the following steps:
- Step 1: Site Business Partner via ABAP program, based on standard API: CL_MD_BP_MAINTAIN.
- Step 2: Retail Site via screen recording (eCATT)
13 – Can Site Masters be created programmatically as a Production process?
For all practical purposes, No.
There is no standard program or content to support this requirement. Consider the complexity described in answer to What’s the Data Migration scenario for Site Master?
14 – What platform issues should Basis and Functional resources both be aware of?
The configuration versus master data dichotomy for Site Master rages on even as you consider ordinary Basis tasks such as a Client copy.
Site Master tables are technically defined as Customizing. For this reason, they are included in a Client Copy that excludes master data. But we understand that Site Master tables need to be considered as master data in some scenarios.
On this point, consider SAP Note 2665614 – List of site tables to be excluded in client copy.
SAP Note 2665614 warns that if you carry out a Client Copy operation then Site maintenance, Site distribution and other Site related processes do not work correctly in the copied client. Whoops.
Be aware that SAP Note 2665614 only provides an initial list of tables to be excluded during a Client Copy, based on defaults and SAP delivered content.
The list is only a starting point from which a Site Master functional analyst must publish an actual list of tables to be excluded, according to your specific implementation. The prerequisite steps in your Client Copy protocol will include checking both your implementation-specific table-exclusion list and also the latest version of SAP Note 2665614 (for possible additions).
Business Partner Key Mapping presents another consideration after performing a Client Copy. Just as the system uses a GUID to internally identify a Business Partner, it also uses a GUID in Business Partner Key Mapping to identify the sending and recipient system-clients. After a system copy or a client copy, the link between the system-client number and the GUID may no longer be correct, which will cause Site Master Distribution to fail.
Standard T-Code MDG_ADJUST_IDM (Adjust Key Mapping after Client Copy) is provided to correct the error condition. The transaction runs in just a few seconds because it doesn’t create new BP Key Mapping entries, it simply changes one entry in table UKMDB_AGCBNSS0.
CLIENT COPY WITHOUT MASTER DATA
- Before performing a Client Copy operation, check SAP Note 2665614 – List of site tables to be excluded in client copy.
- SAP Note 2665614 lists at least 54 tables to be excluded. Please expect that SAP Note 2665614 could be enriched at any time to include additional tables. Checking this SAP Note for the possible addition of new tables to exclude should be a prerequisite step in your Client Copy protocol.
- Please expect that the Site Master functional owner may also publish a list of tables to be excluded. Checking this list for the possible addition of new tables to exclude should also be a prerequisite step in your Client Copy protocol.
- If the target client is a Site Master Distribution recipient and Key Mapping is only relevant for distribution of Site and BP from Customizing Gold client (in other words, key mapping is not relevant for some other business process) then exclude Business Partner Key Mapping Tables:
- UKMDB_KEYBNSS0
- UKMDB_AGCBNSS0
- UKMDB_SCHBNSS0
- UKMDB_MGPBNSS0
- UKMDB_V78BNSS0
- If Business Partner Key Mapping Tables are not excluded then execute T-Code MDG_ADJUST_IDM (Adjust Key Mapping after Client Copy) in the copied client immediately after the client copy and before attempting execution of Site Master Distribution.
CLIENT COPY WITH MASTER DATA
- Ignore SAP Note 2665614 – List of site tables to be excluded in client copy.
- If the target client is a Site Master Distribution recipient and Key Mapping is only relevant for distribution of Site and BP from Customizing Gold client (in other words, key mapping is not relevant for some other business process) then exclude Business Partner Key Mapping Tables:
- UKMDB_KEYBNSS0
- UKMDB_AGCBNSS0
- UKMDB_SCHBNSS0
- UKMDB_MGPBNSS0
- UKMDB_V78BNSS0
- If Business Partner Key Mapping Tables are not excluded then execute T-Code MDG_ADJUST_IDM (Adjust Key Mapping after Client Copy) in the copied client immediately after the client copy and before attempting execution of Site Master Distribution.
Related Content
- Site Master Distribution: Functional Review
This 15-minute video illustrates the functional details. - Site Master Data Migration: What, When, and How To
- Blog category: Site Master Distribution
- SAP Managed Tags:
4 Comments
