Feb 28, 2019

ALE Distribution of Master Data

A couple of months (posts) ago I wrote about propagating Chart of Accounts and GLs through ALE to other environments. But GLs accounts are not the only objects that can be transferred through ALE. In fact there are tons of Master Data objects that can be transferred using ALE in SAP. 

I put together a small list of some relevant Master Data objects that could be relevant for Finance (from my perspective).

As I mentioned before in my other post (ALE Chart of Accounts to other environments) , you need to Create / Update your Distribution Model before you can start defining new objects that you want to transfer through ALE.

This is a Table that gives you a list of the TOP objects that I transfer normally through ALE, with their corresponding Message Types, Tcodes to trigger them and setup for the Partner profiles.



These are the Outbound Partner Profiles



These are the Inbound Partner Profiles


Remember, as I mentioned in my other post; once you trigger your IDOCs. You should be able to monitor them in the sending system with WE02 and then in the receiving system with WE02 too. If you have errors, those are most likely from you Partner profiles setups, check them and re-process or re-trigger the IDOCs.


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Feb 4, 2019

SAP Product Costing, Cost Estimates Tables


These are some important Tables within the SAP Product Costing module. This tables store all the data related to Cost Estimates (aka Standard Cost Calculation executions).

Each time you run a Cost Estimate (Tcode CK11N individual / CK40N mass), internally a Cost Estimate number / Cost Estimate number is created to store your Material execution.

Table: KEKO - Product Costing - Header Data
This table contains a header record for each Material, Costing Date, Plant. It also contains all the Dates, Lot size, unit of measure, user that has executed it, costing variant used and date that the Cost Estimate was marked and released among many other data.



Then you have other tables that give you the details of the data contained in this Header / Cost Estimate execution.

Table: KEPH - Product Costing: Cost Components for Cost of Goods Mfd
This table contains the total calculated amounts for each of the Cost Components according to your Cost Component config.
Your link between this one and KEKO is the Product Costing Number / Cost Estimate number. There is one line per Header record in KEKO. 
You have Cost Field KST001 all the way until KST040 for a Total of 40 different Cost Components.


Finally you have Table CKIS

Table: CKIS - Items Unit Costing/Itemization Product Costing
This table contains every single line item for your Cost Estimates as per your BOM (Bill of Materials) and Routing. One record per Material contained in a BOM and/or activity in a Routing, with the Cost Element derived from it Plant, Material, determined price, quantity, unit of measure and Total Valuation among many other information.
The link with KEKO is the Cost Estimate number.



With all this info, you could easily reconstruct your Cost Estimate results.


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.

Jan 30, 2019

Fixed Asset Migration in times of S/4 HANA

Fixed Assets Migration in times of S/4 HANA is way more easy and straight forward than what it used to be back with ECC 6.0 (or prior). This is all thanks to the re-structuring and simplification that SAP has done in Finance since the introduction of Simple Finance and subsequently S/4 HANA. Now the Fixed Asset module is completely integrated with the Universal Journal, same as AP and AR. 
Because of that we now have fewer steps, tweaks and reconciliations to do during the migration.

Transfer Date specifications

We will start by setting our conversion date to that last date of our last Fiscal Year in our Legacy System (this taking into consideration that my go-live date is the same as my new Fiscal year start, so no mid-year migration). 

In S/4 HANA 1610 version you still need to set the Transfer Date through the IMG and with a Transport that you will have to promote all the way up to Production as we used to do in ECC6.0.


Here you will specify the last date of your prior Fiscal Year. Ex Go-Live 2019-01-01, the you will enter 2018-12-31.


In S/4 HANA 1709 version, this IMG entry has been removed and replaced by Tcode FAA_CMP_LDT and has simplified it. Now this Tcode can be accessible and edited in any client / environment and you do not need a transport anymore to specify a date. 

Here you get to Specify the Transfer Date, the Transfer Status of your Company Code and also the FI Document Type that you will use when posting the Asset Values to the GL. There is also an interesting point where you can specify that the system will calculate the planned depreciation figures for each Asset already at the time of Migration. If not, you will have to subsequently run AFAR - Depreciation Calculation for that. In times of S/4 HANA and great performances, I do not see why we would not calculate it at creation. 

So once we specified the dates in our config, we are ready for our next step.

Fiscal Year change

If our go-live date is 2019-01-01, then I need to do the Fiscal Year balance carry forward so then the FY2018 will be considered closed in the system. This is a requisite to be able to load my Asset Values as of 2018-12-31. Without this step, I will get an error.

Execute FAGLGVTR to carry forward your balances. Even if you have no postings in FY2018, you still need to execute this step, as it is the one who will mark FY2018 as close in the system. (You can verify this once executed in Tcode OAAQ for your Company Code).

If you have more than one Ledger, you need to execute both Ledgers in FAGLGVTR.

If your FY did not change when you check it with OAAQ, then you might have to execute Tcode AJAB to close the FY and then re-execute FAGLGVTR.

Migration Options

The recommended approach by SAP for S/4 HANA is to use the new Migration Cockpit (Tcode LTMC) (as per OSS Note 2287723). For that SAP has delivered a standard migration object that can be used to Migrate your Fixed Assets Master data as well as the Fixed Assets Balances (Acquisition costs and Accumulated Depreciation). Behind the scenes, this standard migration object uses BAPI FIXEDASSET_CREATEINCLVALUES that takes cares of creating the Asset Master Data as well as the values.
This BAPI creates the IDOCs, but it is exactly the same as BAPI_FIXEDASSET_OVRTAKE_CREATE Business Object Method BUS1022 in LSMW. 



Before S/4 HANA and Simple Finance, in ECC we used to create the Asset Master Data with Tcode AS91/2 and from there we also had the option to enter the "Take over values". Now this last option for the values has been replaced by Tcode ABLDT that at the same time it posts the values to the Sub-ledger it also posts to the GL as well with an FI Document. In fact due to the whole set of changes that SAP has performed since Simple Finance, there is no more Sub-ledger and everything posts to the GL.
Because of this, there is no more need to tweak the setup of the Asset reconciliation accounts ON/OFF to Post a separate entry with the total value of the Migrated Assets. ABLDT does the posting directly to the GL. So, no more reconciliation between GL and sub-ledger too as we used to do in ECC.

The 2nd option that we have to migrate, is to continue using our old and beloved LSMW. There are several OSS Notes related to the subject where SAP does not recommend the use of LSMW anymore in S/4; but in some cases SAP has still not delivered a Migration Object either for certain pieces of Master or Transactional Data. In the case of Fixed Assets, we do have a Migration Object; but still has certain limitations that I will comment later on in this blog post.

Because of some of this limitations, I still continue to use LSMW for Fixed Assets Master Data and Values.
So my LSMW that I built over the years (even back in ECC6.0) still works as a charm and it is fully compatible with S/4 HANA and has zero side effects. Why ? Because I built an LSMW that uses BAPI FIXEDASSET_CREATEINCLVALUES that ends up triggering IDOCs. So this BAPI does still the same that the standard Migration Object that SAP built does. At the end, it is exactly the same. The only trick is that you really need to know how to and where to provide the right values in the right segments or structures, which could be challenge initially.

Once executed (any of the 2, Migration or LSMW), you will have all the Master Data and Values created and posted to the GL; so then you are left with just running an standard Fixed Asset report to verify the total amount of your Migrated Assets and reconciled them.

Limitations of the Migration Cockpit - Fixed Assets object

As per real life experience, I can say that I found certain limitations in the Fixed Asset Migration Cockpit object delivered by SAP. Then I ended up finding a couple of OSS Notes that talk about it (can't find them now).

#1 - For large volume of Assets, it is not recommended to use the Migration Cockpit as the performance is really inferior compared to the BAPI running in LSMW.

As an example, one of my latest clients had 21,000 Fixed Assets to Migrate. With the Migration Cockpit, the calculation was giving me something like 10 or more hours of execution for that amount of records.
With the LSMW using the same BAPI with IDOCs, it went down to 3 hours. This after the application off OSS 2616079 that also improves the performance. But still the LSMW option is still recommended.
There is also another OSS Note where SAP does not recommend the use of the Migration Cockpit for large volume of Assets and recommend instead LSMW, so it is contradicting the other Note.
If your client is an Asset intensive company (Ex. Mining, Oil & Gas or has large manufacturing Plants), chances are that you will easily have more than 10k Assets easily. 
I remember an old Mining company were I had 45k Assets.

#2 - The New Migration Cockpit in S/4 is not able to open XML files bigger than 100 MB. This is an standard limitation (also in another OSS Note). This could sound as a lot if you compared it with ASCII / TXT files, but not for XML based one.

The Migration Cockpit templates are based on XML files that you handle, manipulate and populate normally using Excel. XML files tend to have large file sizes. Normally several MBs. That is due to the large amount of characters that you will find inside them and the tons of tags that an XML file standard has. This ends up creating big file sizes. 

As an example for this client that had 21k Assets to be migrated, an XML file with all the 21k was around 450 MB. So a file containing around 5k records, was reaching and in some cases going over the 100 MB. So I would have needed to create 4 or 5 files of less than 100 MB each. Plus the significant loading loading time of Migration Cockpit vs. LSMW.
In this case, I guess that SAP still needs to improve the performance and handling of large data volumes in the Migration Cockpit.


Additional information
2537549 - Collective SAP Note and FAQ for SAP S/4HANA Migration cockpit (on premise)


If your Company and/or Project needs to implement this, or any of the functionalities described in my Blog, or advise about them, do not hesitate to reach out to me and I will be happy to provide you my services.