SAP Finance conversion objects, all about them

This post is the continuation of my previous post "What is the Data Migration process about ? (Data Migration 101)? where I was explaining the process of Data Migration.

In this post, I will talk about the SAP Finance Migration objects which is my key area of expertise. I will describe the specifics of each objects, its strategy, dependencies and how they fit together in this whole big puzzle.

I will describe them in order, sequence how they need to be created. Some could be created in parallel and some need to be created after others have been created.

The first pre-requiste to start doing Data Migration is that your whole configuration has been transported into Production or your Target environment that you are migrating too.

Extracted Data from the Legacy system should be done all at the last day of the closing period prior to the go-live date. If the go-live is March 1st, then data should be extracted as of the books being closed on February 28th (or 29th for a leap year).

The ideal time of the year for a go-live from a Finance perspective is the 1st day of the new Fiscal year as it simplifies several of these conversion objects, specially GL Balances and Fixed Assets with its values.

Bank Master (Bank Keys)

This is the whole list of Bank numbers, with its names and in some cases their addresses too. This is needed in SAP to be able to perform electronic payments (or Direct Debits too) and register Vendors / Customer Bank account details. SAP normalizes all these data in order to avoid issues while generating payments that could result in payments being rejected by Financial Institutions. If you have a small volume, this information could easily be validated online in many web pages and also in each Bank list of branches. If you have a large volume or anticipate it, there are companies that provide this Bank Directory for specific countries or worldwide ($$$). Ex. Accuity or SWIFT. Bank Keys is a pre-requisite to load Business Partner Vendor / Customer.

Bank Keys Master Data can be migrated using a standard SAP delivered object in the new S/4 HANA Data Migration Cockpit in case you did not purchase the services to obtain Bank Directory Data.

My personal preference: SWIFT Service

Chart of Accounts

This is the heart of the Finance Module in SAP. Without it almost nothing can happen. This contains every single General Ledger account. It can be loaded with the old LSMW, it can be Transported (see this post post that I did in the past) or it can be replicated from your Golden environment into other environments through ALE (this other post too). The chart of accounts is a MUST for all Finance transactional data that will come after, like Fixed Assets values, AR/AP Open Items, GL Balances, Standard Cost calculation and Inventory load.

For S/4 HANA 1909 version, SAP has finally delivered a Migration object for GL Account within the Data Migration cockpit. This is something much awaited since the 1st S/4 HANA version.

My personal preference: create everything in the Golden configuration environment with LSMW or Cockpit and then ALE to other environments.

Profit Center

Another Finance object that is key for SAP Finance. Depending the size of the company and operations they have, this could be a small number of Profit Centers Centers or a large number of records. Based on that if we are talking about a handful of records they can easily be created manually; but it is almost never the case. For a large volume of data, we could always use LSMW or the new S/4 HANA Data Migration Cockpit which it comes out of the box with a Migration Object ready to use. Also another alternative to keep all your environments in synch., you could use ALE to Distribute the Profit Center Master Data (see this post that I did in the past). Profit Centers are a pre-requisite for Cost Centers as Cost Centers need to be assigned to a Profit Center.

My personal preference: create everything in the Golden configuration environment with the Cockpit and the ALE.

Cost Center 

Another Finance object that is key for SAP Finance. Depending on the size of the company and operations they have, this could be a small number of Cost Centers or a large number of records. Based on that if we are talking about a handful of records they can easily be created manually; but it is almost never the case. For a large volume of data, we could always use LSMW or the new S/4 HANA Data Migration Cockpit which it comes out of the box with a Migration Object ready to use. Also another alternative to keep all your environments in synch, you could use ALE to Distribute the Cost Centers Master Data (see this post that I did in the past).

My personal preference: create everything in the Golden with the Cockpit and then ALE

Fixed Assets (Master Data & Values)

This will contain all your Fixed Asset Master records for the entire company with its acquisition values, accumulated depreciation, useful life and depreciation method (Key) among some other data too. There will be many companies that will have assets that are fully depreciated (Acquisition value = Accumulated Depreciation) and that they are still migrating. This is totally normal as they are needed for tracking purposes.

Now a days in S/4 HANA, the Migration of Fixed Assets has been simplified (see this post that I did in the past to learn about the different migration methods) .

When loading the Fixed Assets values, the system will do the following Journal Entries:

Debit  Fixed Asset Balance Sheet account for Asset Class

Credit Accumulated Depreciation Balance Sheet account for Asset Class

Credit  Fixed Asset conversion account *

* This account is a Balance Sheet Account (Ex. 399998) that after loading your GL Balances, its balance will be zero.

Pre-requisite for Fixed Assets Master data are the Cost Centers and the Chart of Accounts.

My personal preference: LSMW with BAPI as described in my previous post

Projects & WBS

This will create all your Projects and their WBSs underneath them so later on you can load the project accumulated values for the ongoing projects. As a pre-requisite you will need Profit Centers and Cost Centers.

Make sure your projects are in status release otherwise you will not be able to post values to them later on when you load your balances. You should not migrate projects and its values if they are already closed or completed.

For ongoing Capital projects, you will post their values when you will be loading GL Balances. Instead of loading Balances to your Balance Sheet Fixed Asset AuC account, you will post all the details to each WBS into a P&L account (or many). After loading the GL Balances and having posted to WBS, you will run period settlement for those projects.

Posting through GL Balances upload

Debit P&L Expense account with Cost Object WBSs

Credit/Credit All the rest of your Trial Balance

On Project Settlement

Credit  Project Settlement Account or Original Account (depending on config) with Cost Object WBS

Debit  Balance Sheet Fixed AuC account *

* The total of all your loaded project values should be equal to your Balance Sheet AuC, if not you have an issue that need to investigate and reconcile.

For Expense Type projects, you should only load the Master Data and not the GL values as your project values settle to Cost Centers and your P&L will already contain those Settled Values. Unless you can easily strip those values from the Cost Center expenses, you should not post values to it. In case you do, you will repeat the same process as with the Project Settlement for Capital projects but for Expense projects.

Project / WBS Master Data can be migrated using a standard SAP delivered objects in the new S/4 HANA Data Migration Cockpit.

My personal preference: Migration Cockpit, as it could get complicated with an LSMW.

Internal Orders

Here you will create this Master Data that will have as a pre-requisite Cost Centers and Profit Centers too. The rest of the process is exactly the same as with Projects & WBSs for its values.

Internal Orders Master Data can be migrated using a standard SAP delivered object in the new S/4 HANA Data Migration Cockpit.

My personal preference: Migration Cockpit but it depends on the Order Type as the Cockpit did not cover certain types. Not sure if they have improved that now in newer versions, I hope so.

Business Partner - Vendor and Customer

This will create the Master Data of your Business Partners with all the different BP roles required for them to fully operate (Sales, Purchasing, FSCM, etc.). There are several standard SAP delivered objects for both of them within the Data Migration Cockpit that cover the different situations, including Credit. Before 1909, Credit was not covered and you had to develop your own custom object to be able to load Credit limits.

Once you have your BPs loaded, with their corresponding roles and extended to the different Company Codes, you will be able to load your AR / AP Open Items.

My personal preference: Migration Cockpit, no other way. Worst case an API could be used if your System of record for BPs is other than SAP.

AP / AR Open Items

This will contain the detail of every single unpaid Vendor and Customer invoice with its corresponding invoice number, document date (the invoice original date), payment term, original value in original currency and original currency. Posting date for this MUST be the last day of the month prior to go-live. Value in Company Code currency should be already re-valuated at month end rate in case it is a foreign currency document.

When loading the AP / AR Open Items, the system will do the following Journal Entries:

Debit AR Subledger / AR individual Customer Account

Credit AR Conversion Account (Ex GL BS 399997)

Debit AP Conversion Account (Ex GL BS 399996)

Credit AP Subledger / AP individual Vendor Account

* One entry per Document / Invoice loaded.

The total of your AP Subledger in your Legacy System should be equal to the Sum of all migrated invoices. I know it sounds obvious, but not all legacy systems are good in terms of reconciliation, data consistency and accuracy. I have seen this several times in the past. In this case, as part of your data cleansing exercise, you should eliminate and adjust these inconsistencies. The same applies for AR.

AP / AR Open items can be migrated using a standard SAP delivered objects in the new S/4 HANA Data Migration Cockpit.

My personal preference: LSMW with an IDOC for FI Document. I have developed a really good one over the years and still works like a charm.

Inventory related Objects

In case you are using Product Costing and doing Manufacturing execution in SAP, you will need these series of objects that are related to Inventory values.

Activity Types

Activity Types are created prior to the creation of Production Work Centers and created in conjunction by your Production Team / Consultant. They can easily be created using the standard delivered S/4 Migration object for Activity Types or manually if they are just a few.

Activity Types rates

After having created the Activity Types, Finance has the responsibility of assigning rates to it. This is done through Tcode KP26. This could be done manually or within the config of KP26 you could create an Excel loading template so you could have a large number of records to load. After this, Production will be able to create their Costing Tab of their Work Centers, otherwise if there is no rate, they will get an error.

Material Prices (moving average)

During the load of your Material Master records and the creation of the Accounting Views of them, you need to assign a Material Price to those materials that have Price Control indicator V - Moving average. If you do not do that, when you load inventory quantity or try to calculate Standard Cost, you will get errors or Inventory with no value on it.

This should be done by and in conjunction to your Material Master Team and within their Data Migration object (Ex. it could be an LSMW, or a new Data Migration Cockpit object, or another method that they could have decided like a BAPI or API).

Reconcile this with your Legacy system values and be ready to explain if there are any differences.

Material Prices (standard)

As part of the creation of the Material Master Accounting views, for Material that will have Price Control Indicator S - Standard; you need to at least put a value during the Material record creation. This value will be overwritten by the standard cost calculation process later on. In this case I always suggest putting a penny (0.01), just to get by and be able to save the record.

Standard Cost Calculation

Many people consider this as a conversion object, I don't. From my point of view, this is more a process than a conversion object, as you do not develop any program or conversion object for it. You just need to run the Standard Cost Calculation process (Tcode CK11N individual or CK40 mass). Once you obtained a suitable Standard Cost, you will release it and your Material Master records will have a Cost for those with Price Control Indicator S - Standard. If you do not do that, when loading inventory quantities you will get Inventory with no value on it or a penny as described before, which is almost the same as no value.

Reconcile this with your Legacy system values and be ready to explain if there are any differences which there are high chances there will be. In many Companies some sort of dollar threshold is established prior to this exercise to accept differences. In some other cases, there are Management calls right after to discuss these differences and sign-off on them.

Inventory Qty load

This is where it all ends for Inventory. Your MM or WM Team will load their Inventory Quantities and based on the Material Master Cost assigned in prior steps for the different materials (S or V), the system will do Qty * Cost and post a Journal Entry for that Inventory Initial load process.

Initial Inventory load Movement Type 561 will trigger FI-MM Account Determination GBB-BSA.

When loading Inventory, the system will do the following Journal Entries:

Debit Inventory Balance Sheet Account (as per Valuation Class of the Material record) (BSX)
Credit Inventory Balance Sheet Initial load / Conversion Account (Ex 399999) GBB-BSA

The total of your Inventory load resulting from the Quantity load should be equal to the Sum of all Inventory Balance Sheet accounts that you will load in your GL Balances. If not you have an issue and should reconcile it.

As a suggestion, I strongly recommend this approach before loading inventory quantities... Once you have Moving AVGs and Standards in your system, you should extract them and put them in Excel. Then before loading the Inventory Quantities, ask for that file and dump it in Excel. Do a quick Vlookup to populate all Materials with prices. Then do Qty * Cost and do the full sum. If it Balances to your GL, you should go buy yourself a lottery ticket. If it does not balance, which is most likely the situation, start a reconciliation process Material by Material. As said before, in many Companies some sort of dollar threshold is established prior to this exercise to accept differences. In some other cases, there are Management calls right after to discuss these differences and sign-off on them.

GL Balances

Now we reached the last of the SAP Finance Conversion objects, the most important one and the one that closes the whole loop and series of conversion accounts. After posting the GL Balances, all your 39999x Conversion accounts will go down to zero. If not, you have an issue derived from any of the previous conversion objects that you need to analyze and reconcile.

As previously described in each individual object, you cannot map your GL Balances for the different subledgers and/or modules (AR, AP, Inventory, Assets, Projects and Internal Orders) directly to the subledger accounts, instead you need to map those GLs to the 39999x Conversion accounts. Each subledger loaded have posted the offset to the conversion account. Then the GL Balance upload will come to offset those GL Conversion Accounts (39999x).

Remember, GL Balances needs to be done with a posting date as of Dec-31st (in case your go-live is Jan 1st). 

Note: always pay attention to your Parallel Currencies amounts, not just your Local / Company Code currency amounts. This is normally a challenge because not many Legacy systems have Parallel Currencies capabilities like SAP.

My personal preference: Migration Cockpit object delivered by SAP.

Timings 

Inventory load will happen right during the go-live weekend as Inventory quantities are crucial to be able to start Producing and Shipping in the new system after go-live.

Fixed Assets load will most likely happen during the 1st days after the go-live as the company still needs to close their Fixed Assets in their Legacy System, then Extract, Transform and get ready to load into SAP. So expect to receive that info a couple of days after. And this is totally normal.

AR/AP Open Items load, will most likely happen during the go-live weekend. These Open items are needed right after you start operating in the new system so you can pay your Vendors and apply cash received from Customers. There could be a minor delay of 1 or 2 days max, but more than that will have an impact on the business.

Project and Internal Order values will happen with the load of the GL Balances.

The load of your GL Balances (or the whole Trial Balance), cannot happen during the go-live weekend. No Accounting / Finance department closes their books in a weekend or during the go-live. So, information to load the balances will come no sooner than mid-month after the go-live date. Only once the books have been closed, all JEs posted, everything reconciled; then Finance will be able to produce a file ready to upload the whole Trial Balance. This needs to happen before you start your 1st Month End exercise in SAP, otherwise you will not be able to produce proper Financial Statements.

Note on LSMW 

Before people start jumping at me ... I want to clarify something on this.

SAP has released notes that LSMW is not the preferred Migration tool for S/4 HANA, that they will not support it anymore, it is at your own risk and you should use instead the new S/4 Migration Cockpit. All good with that. But .... Where I see an issue is in trying to use LSMW in Objects like BP where you cannot use recordings in those screens and some other screens (like ABLDT for Fixed Assets values) where you have tables and you cannot manage that properly with recordings.

But LSMW is not only about recordings. You can use BAPIs and IDOCs with it and still be 100% S/4 HANA compliant, as those BAPIs and IDOCs have (most likely) been updated to be used in S/4 HANA. So using them will not break anything and data will still be properly created. LSMW with BAPIs and IDOCs is still way more performant than the Migration Cockpit, way faster. I have lived that 1st hand. The only thing that you need is people like us (old SAP Consultants) that know how to use it for each an every single object.

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.

www.dnabusinessconsulting.com

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.

www.dnabusinessconsulting.com