Introduction
When I hear and read about the "new" migration tool in S/4, it always look like it is a disruptive change, that most of the consultants fear and refrain from using.
Let me share my point of view, as an old consultant with a lot of LSMW experience. I will demonstrate how much it is actually close to LSMW, but stricter and a bit less flexible (especially for those like me who used to do LSMW for all kind of purposes).
To make it more realistic, I will follow the steps to enhance AR Open Items migration so that we can "split" lines per profit centers. This is not a big deal, and let's assume you have set up correctly document splitting with profit centers as one of the characteristics, and that your chosen AR document type is made relevant for splitting.
You may have guessed it, we will let the standard split the items: there will be multiple G/L lines with different profit centers, and one single AR line: this will enable to have AR clean (you do not want your AR to be polluted with profit center splitting) and have the actual split happen in ACDOCA.
Overall Structure
There is no surprise here if you are used to LSMW, an object is globally split in 3 main components:
In LSWM, these are the steps where it happens
[LSMW] Define Source Structures / Define Source Fields: you define your source structures in 2 steps, first the "wrapper" structures, and then their inner fields
[LSMW] Define Object Attributes: target structures are implicitly defined with your loading method, that is if you select an IDoc, your target structure is the IDoc structure, if you pick BAPI, your target structure is the BAPI parameters. If you like BDC (this is bad, and you know it), your target is the implicit input fields of your recording.
[LSMW] Define Structure Relations / Define Field Mapping and Conversion Rules: your mapping is defined in 2 steps, first the structure mappings, then field mappings
I assume you are familiar with these explanations, let's see what it looks like in LTMC.
Source structures
One single screen allows you to define your source structures. But you still do it in 2 steps, first the wrapper structures (left pane), then fields within (right pane):
There is one more option hidden here. Right click on one of the structure and jump to "Display view".
This enables you to hide fields or make them mandatory or optional. This can ease and speed up migration custom object creation in the following use cases:
- you have validated that you can use the SAP delivered templates to load your materials, but you find the huge numbers of fields cumbersome. You don't need them all actually. Copy into a custom migration object, and in the structure view, make them invisible (as long as they are not mandatory)
- you can use the template as is, but would like some more business mandatory fields. It is just a matter of clicks
Now back to our use case (enhancement of AR), we do not want to duplicate AR lines, that is, one line in the upload file must tally to one accounting document. To do so, we will need to fill all possible profit centers on the same line.
Save and generate. This will make this new template available. Let's check it.
Launch Migration Cockpit UI (LTMC), navigate to your new migration object and download the template. This is magically simple, the template is updated with your new fields.
Target structures
As in LSMW, target structures are implicitly linked to the loading method you select. Except here, you don't have a choice on the "method", this is going to be a function module.
Forget IDocs, forget BDC (good news, it is evil). Here instead, all you can do is to select your function module. Any one. And especially BAPI.
In our example, it is bound to DMC_MIG_ACC_DOCUMENT_POST. But hold on, don't you fill it really looks like BAPI_ACC_DOCUMENT_POST's parameters? Well, this is only because of the test flag, as BAPI_ACC_DOCUMENT_POST does not have such input and a wrapper function is still needed:
If you have some technical knowledge and you are familiar with BAPIs, you must fill at home. To create data is nothing more than just calling correctly a BAPI. Just like old LSMW with BAPI (don't argue you are still a fan of LSMW with BDC, today ... ).
Mapping from source to target
This part is a bit more difficult to catch, but still its concepts are very similar to LSMW ones. You start with structure to structure mapping.
Structure mapping
As in SAP delivered template for AR, source structure S_BSID is mapped 1:1 to ACCOUNTGL. That is, one BSID line will generate 1 GL account line. Our requirement is to generate as many GL lines as profit centers, with total offsetting exactly one AR line.
Then, as per SAP splitting magic, AR lines will be split in ACDOCA.
If you remember from earlier enhanced source structure, we can have up to 5 profit centers for one AR line. In terms of mapping, we will "repeat" BSID segment 5 times (mapping type split = repeat, target 5 = repeat 5 times):
Field mapping: AccountGL lines
So one GL line per profit center, and up to 5 lines ... but how are field values repeated? By default, when mapping type is "Split", all values are repeated: you will have exactly 5 times the same line.
You need at least to have an incremental item number, and each line its profit center. Here we go.
Right click on ITEMNO_ACC and "Delete rule". Then again right click and mark field for split:
You then have to map each split value:
We will assign item numbers ranging from 2 to 6, as number 1 will be reserved for AR line.
And of course we do the same for profit center:
Fine, but what if we do not fill exactly with 5 profit centers in the input file? You are right, we should skip lines where its value is empty.
If you are LSMW black belt, you would remember that such a conditional record skip is possible, and this must occur in END_OF_RECORD event. There is the exact equivalent in LTMOM, except we cannot directly write inline ABAP code, but wrap it in a named "rule" instead.
We will call it IF_PRCTR_NOT_NULL, which is self-explanatory:
If you are old enough, that would remind you SAPscript or smartforms. Profit center is set as a parameter so we can reuse this rule. Look at the instruction keyword "skip_record" (this is actually a macro): this is exactly the same as in LSMW (this sounds familiar if you are black belt -remember skip_record, skip_transaction, etc.?).
And we will use it directly as a rule in End Of Record ( R_ACCOUNTGL 😞
Now the tricky part: if you use the search help, only source fields are proposed. We may use S_BSID-PRCTR/2/3/4/5, but we want the rule application to be more flexible. We will set parameter value to R_ACCOUNTGL-PROFIT_CTR, which means we check in the current target record instead of the source record. This is something you must be familiar with in LSMW too!
Field mapping: AR lines
In SAP template, AR profit center is mapped. We will remove that mapping because as stated, we will let standard splitting do its job for profit center.
Field mapping: Currency lines
Here comes the annoying part. Each GL line and AR line must have a corresponding currency line. But that's not all, they must be repeated for each currency type (document currency and local company currency -and only one-).
This can lead to a complex mapping, and it is avoided in SAP template by using ABAP code to append all records:
As I hate coding, I will go for a mapping instead. I need 2 currencies per GL/AR line, which total to up to 5 GL lines + 1 AR line = 6 x 2 = 12 currency lines.
A lot ... but still manageable:
As for currency field, this would be an alternate between document and local currency:
Create a custom rule to sum all split amounts (set minus for offsetting amount)
And assign it to AMT_DOCCUR:
Now, what if my profit center is empty? We will conditionally skip currency lines with custom event rule:
And assign it to end of record event:
You are done! Your new migration object is ready to use.
If you have followed my explanations and want to do the same, remember my own assumptions though:
- document splitting is activated and effective for your document type
- you deal with only 2 currency types: document currency and one single local currency (you can have more, but it means more currency lines)
- you do not deal with tax items BSET (I did not bother with it, but if required you would apply similar mappings as other structures)
- you do not deal with one-time customer lines BSEC (but you could, just apply similar mappings)
- you do not deal with with-holding tax items
Conclusion
Fear not, LTMOM/LTMC is not that different from LSMW:
- stricter: only function modules can be used. To me, this ensures you actually segragate responsibilities, data transformation is done in migration cockpit but data creation is happening in an independant function
- less flexible: you can do a lot with LTMC, almost as much as you did in LSMW but without inline code. If you used to master LSMW and interact in events with instructions like skip_record, skip_transaction, you will not be lost. But for sure this new tool is clearly more "ABAP oriented" than LSMW
I would recommend to use Migration Cockpit as much as possible and forget LSMW (and especially LSMW with BDC -transaction based recording are highly unstable), but bear in mind these huge inconveniences:
- all-OK-or-nothing input check is desperately ANNOYING. You cannot partially process files if there is a single error in a single field (!)
- processing logs are from another century ... it is like LTMC is not meant to display, navigate, analyze logs ...
- SAP Managed Tags:
2 Comments
