Financial people don’t like migrations. Yet you cannot escape it. The impact on the general ledger is significant as the load of your GL accounts may share a common structure across your different entities but may present slight variations such as the link to alternative accounts. With the Migration Cockpit, SAP makes your life a lot easier. In this blog, I will explain/demonstrate how to maximize the use of the Migration object modeler to ease your migration process.
Migration Cockpit
In the SAP S/4HANA environment, one of the most common solutions for master data migration and load – both for new implementations and conversions – is the SAP HANA Migration Cockpit, also called Landscape Transformation Migration Cockpit or LTMC.
LTMC facilitates the migration of data import through predefined templates in a file-based approach. The cockpit is based on a systematic data control approach that ensures data quality through system-based data duplicates and preexistence checking.
Are you operating in an international environment? Then the migration process will probably be split into different waves, with phased deployments per country. Let’s assume that all the different entities across your international environment share a common Chart of Account and different country/local charts of accounts.
Data-update-driven object
The automatic duplicate/preexistence check performed by the migration cockpit can prevent the load of your master data GL account at company code level if the set of GL accounts is identified as already existing.
To bypass this, the Migration Object Modeler Tool (LTMOM) provided by SAP can be used to transform standard migration objects into a data-update driven objects. The tool offers you a wide range of possibilities. For this blog we’ll keep our focus on two main elements:
- copying an existing migration object.
- field mapping – action for data record transition from ‘import’ to ‘update’ type.
Before you start
Prerequisites for this approach are:
- the migration project is already created;
- standard migration objects are already defined within this project.
Here is how the process goes
- Create a copy of an existing object
The first step is to perform a copy of an existent migration object. The copied version must remain an object specifically dedicated to a file-/table-based migration. The newly created object is not subject to a specific naming convention and is, in most case scenarios, following the migration project logic. You can even create the newly created object into another migration project.
- Field Mapping – Change the object set up from “Import” to “update” parameter on the following fields
Once you have created the extended version of the standard object, you can access the field mapping of the newly created version and start applying new mapping rules and action records.
In this scenario, we’ll transform our GL_Account (extended) object so that it no longer fulfils a sole importing purpose but also an updating one. As such, we’ll swap the parameter value of the action data record of the 4 following elements from I-type (import) to U-type (update):
- Chart of Accounts << General Data
- Descriptions << Account Names
- Key Word << Account keywords
- Controlling Area << General data
- Save and generate the new/extended object
Result
The result: a new object will be created, oriented on the update of system values, not on the import. This new object will allow you to proceed with your file-based import without further duplicate checks.
Attention points on data over-write priority
Also, with this way of working, the risk remains that master data, such as GL account master data at company level for other company codes, will still be overwritten. This is because the migration template no longer performs a preexistence check. It may force the new values for all entities at the general data level, such as GL account group. Please be aware of this.
Recommendations
Migration is an important phase of any implementation or conversion project, which often involves specific planning. Will identical objects need to be loaded at different times for different entities? Then consider standard migration objects and systematic checking for duplicates and preexistence. This way, you avoid problems with future loads.
Therefore, a good understanding of the LTMOM tool and the possibilities of object extension for update purposes is beneficial. The use of LTMOM is not restricted to the change of action for data record. It also covers various other needs, such as the definition of specific mapping for standard and custom objects.
Also, remember that working with data-update-driven objects may affect the data already stored in the system. Are you planning to use that method to load additional accounts to other foreign entities? Then be aware that part of the GL account data set may be modified if your load file is not perfectly aligned with your target system.
Learn more?
I hope you found this blog helpful, and that the tips will give you some extra time in your migration process. For more information, please contact SAP S/4HANA Migration Cockpit SAP S/4HANA 2020 FPS02 or SAP S/4Hana Migration Object Modeler – Files/staging Tables.
Or ask your question via SAP Q&A.
Thank you for your time. I look forward to hearing your response!
