Skip to Content
avatar image
Former Member

How to migrate / distribute Site Master data in Retail S/4 HANA?

What is the prescribed method to migrate / distribute Site Master data from the golden client to other logical systems? This is for an S/4 HANA Retail system. I have scanned knowledge articles and notes as well. Given that the Site Master uses the Business Partner now, we are not clear on the correct methodology to create and distribute site master data and the associated business partner data across systems.

This is a greenfield implementation for Retail S/4 HANA, this is NOT a migration from ECC to S/4 HANA.



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Sep 13, 2017 at 10:10 AM

    Hi Sikandar,

    we are also implementing greenfield S/4 retail and we have successfully set up the site distribution using DRF.

    Having set it up and got it working, my feelings on it are that it is just about ok for initial migration of sites from a golden client, however it is going to be very painful for an ongoing site creation process. It is nowhere near as straightforward as WBTIMEX and there are quite a few pitfalls which can trip you up. It is understandable as the process is very new but hopefully SAP will spend some time streamlining it over the next few releases.

    Here are my experiences with it so far:

    • The MDG (master data governance) setup needs to use SOA services (not IDOCs) for the BP, and RFC connection for the site. There is no clear documentation on how to set this up or which objects to use. There is a SAP guide but it is not specific enough.
    • The process expects that you have a separate SLD system to manage the business systems involved. We don't need to use an SLD for any other purpose in our current implementation so it we didn't want to set it up just for this. We have instead used the BADI to determine the local business system but this was quite difficult to figure out and doesn't seem to work all that well. If you have an SLD in your landscape it may work better.
    • We consider that using direct output would not be appropriate in this case as it means you would get data being updated immediately in the production system prior to doing any tests in QA, so probably pooled output with manual running of the DRFOUT transaction for each site is the right approach here.
    • You need to first send the BP across, then the site. As they use different comms methods (SOA v RFC) there are two different places to check for BP and site messages which adds a layer of complexity.
    • You need to consider key mapping for the BP transmission. For this site distribution process it should be transparent as we would never have a different BP code in the source / target system for the same site BP. The way we have set it up is to have 'no key mapping', which means the system when it is working properly should create an entry in the key mapping for the source and target with the same number.
    • We are constantly having to manually set the key mapping using MDG_KM_MAINTAIN for a few different reasons e.g. if you have manually created the site/BP in the target system previously e.g. if it is a test system and you subsequently want to update the site from golden client (this is understandable and should only happen on initial testing and set up of reference sites etc or if you do things in the wrong order, however we had to find this out the hard way, it is not obvious from the documentation).
    • More worryingly, we often see situations where we get an error on the BP transmit or the site transmit, however the site or BP has been successfully created in the background. In this case no update has been made to the key mapping so we then have to manually update it. Not all errors will stop the update to the site/BP.
    • We have a strange problem where initial send of the BP sometimes fails saying the site doesn't exist in the distribution chains you are creating the BP for, however the site is not yet even created. Hopefully we can get to the bottom of this one with more testing.
    • We often get 'site record is locked' when sending the site across, when there appears to be nothing locking the site record (indeed the site doesn't even exist). Messages appear to say the site will not be created, however it does create the site but doesn't update the key mapping.
    • Sending BP for the first time often results in error 'task insert not supported', and the key mapping is not updated, however the BP is created but only at the general level and you then have to repeat it for distribution chain / company code.

    So you can see that although you can force sites and BPs across, it is certainly not a painless process and often results in error messages, some of which appear irrelevant and some only partially stop creation/update of the object so they then need manual clearing up.

    it would be great to get clearer and specific documentation on this from SAP and recommendations about how the process should be used in the real world.

    I'd welcome any comments or experiences from other consultants on this.

    Best regards

    Jeremy Doyle

    Add comment
    10|10000 characters needed characters exceeded

  • Sep 07, 2017 at 09:10 AM

    Hi Sikandar,

    Site distribution on S/4HANA is possible via Data Replication Framework (DRF).

    Some important remarks regarding the DRF:

    – Same framework used for BP and site (with separate outbound implementations).

    – BP needs to be distributed before site (checks in inbound processing) .

    (WBTIMEX not supported on S/4HANA any longer - but still can be used to push from ERP to S/4 or pull into ERP)

    - No customizing transports are written from site maintenance

    Distribution modes:

    – Automatic (direct or pooled) from site maintenance.

    – With initial transfer option

    – Manual with site selection and/or consideration of filters via

    Further info:

    – Tcode DRFOUT (report RDRF_MESSAGE_OUT)


    – Combination of automatic / manual possible

    I hope the above shared info will help you to perform this.

    The transaction also provides program documentation, if any clarification needed.

    Best regards,
    Andras Strobl

    Add comment
    10|10000 characters needed characters exceeded