The objective of this blog is to help you to enhance an existing migration object, specifically the Fixed Asset, but might be helpful to clear some doubts for other objects as well.
The blog has no introductory aspects, it is recommended that you are familiar with the Migration Cockpit and the Migration Object Modeler, otherwise it will appear incomplete.
No ABAP skills required, but helpful if you have.
It is common among fixed asset management processes to have complex assets, which consist of one or more sub-assets that are associated with a main asset. The sub-assets are associated with the same number of the main asset but separately identified by the sub-number.
SAP delivers within the S/4HANA Migration Cockpit an object for the migration of fixed assets, but this object contains some restrictions, one of these is the creation of sub-assets.
In this blog I will show how to enhance the object delivered for fixed asset migration to migrate a fixed asset as a sub-asset.
For additional information about the object restrictions, I suggest reading the documentation for the object available in the migration cockpit and the SAP Notes indicated in the documentation.
Understanding the API capability
There are different ways to understand how an API works, I suggest always start with the documentation, but there isn’t a rule for that.
Whatever way you choose to understand the API behavior, the first step is to identify the API used by the migration object.
For that go to transaction LTMOM, open you object and double click on the “Target Structures” menu, in the shown screen you’ll see the field “Function Module”.
Copy the function module name and go to transaction SE37 to display its attributes.
Once you are displaying the attributes of the function, look for the “Function Module Documentation“.
Documentation analysis should be done based on your business requirement.
It means, look for a parameter that is related to what you are looking for and read the information provided to understand how the parameter works.
Based on the documentation above, we understand that the API requires in the field CREATESUBNUMBER the value “X” to create a sub-asset instead a main asset, with that information we now know what is required to adapt in the field mapping of the migration object to achieve our goal.
Now let’s start to change a migration object, for that, go back to transaction LTMOM and make a copy of the Fixed Asset migration object (Z_FIXED_ASSET_XXX) of your project.
Identify technical requirements
We already know that the migration object delivered by SAP was designed to migrate the main asset only, so it is expected that the structures of the object need to be adapted for the creation of the sub-asset.
If your requirement is not the same as the proposed for this blog, will be necessary to perform two steps before you change the migration object:
- First, understand the field mapping.
- Second, test and simulate the new mapping to conver your requirement.
For the second step, use the transation SE37 to test and simulate your own mapping and check if the results will cover your requirement as expected.
For the business scenario that I proposed for this blog, I did these steps and will present here the conclusion.
There are three fields that need to be changed, which are:
- Main asset number – this field should receive the asset number created in the system.
- Asset Subnumber – this field should receive the subnumber of the main asset.
- Checkbox-create – as shown in the documentation this field should receive the value ‘X’.
In order to do that will be necessary to change the Source Structure, below is one of the standard source structures of the fixed asset migration object.
The different structures that contain in the migration object are related with each other by the key fields BUKRS + ANLN1 + ANLN2.
In our business scenario, we should be able to repeat this key several times in order to create several sub-assets for one single main asset, which won’t work in the curret state.
Thus, we need to add a new parameter in this key that allow us to repeat the Asset number and Asset subnumber, otherwise, the system will abort the process due to key duplication.
Look at the screenshots below to understand the scenario AS-IS/TO-BE.
Let’s adapt the migration object, please follow the steps below:
1. Include one field as key in all the structures of the migraiton object,
Remember, this new field will be used to sorting the sequence of the sub-asset creation, define a type that you can apply this kind of logic.
2. Adjust all the foreign key relationship between the structures.
3. Map the fields as shown in the screenshot below.
Note: Assign the conversion rules CVT_ANLN1 and CVT_ANLN2 respectively.
4. Assign a rule to move the fixed value (‘X’) to the checkbox field
5. Finally, generate the migration object again.
If you follow these steps, now you should be able to create the sub-assets with the Migration Cockpit.
Note that the field we add in the structure will not actually interact with the API structure, this is just to allow us to repeat the main asset number many times. In other words, even the field being a numeric type, its value will not be the actual subnumber, that column only is to sort the sequence that the sub-asset will be created.
I hope this document helps you with your requirement.