Introduction
I have been part of multiple accrual engine implementation, from S4HANA 1809 new accrual engine functionality is available. Customers who have implemented or used accrual engine functionality before S4HANA 1809 needs to carry out the migration.
For the customers who have implemented the old accrual engine, migration is a mandatory activity that needs to be carried out once their ERP environment is upgraded to S4HANA 1809.
In this blog post, I will try to cover the list of migration activities that need to be carried out. This migration activity guideline is for finance consultants who are tasked to migrate old accrual engine to the new accrual engine.
Following is an example of the configuration of the cockpit and the execution of the cockpit as well.
1. Migration Cockpit Configuration
1.1. Migration Precheck Customising
Use
Using this Customizing activity, you can precheck to migrate configuration items from the old accrual engine to the new accrual engine.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACE_MIG_CUST_CHK |
IMG menu path | Accrual Engine Data Migration> Migration of customization for Accrual Engine > Migration Pre-check for customizing |
- Maintain the following values in the views described below:
You should not get any error in this precheck, if any precheck error is received, you may have resolved the error before proceeding ahead with migration.
1.2 Migration of Customising
Use
Using this Customizing activity, you can migrate configuration items from the old accrual engine to the new accrual engine.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACE_MIGRATE_CUST |
IMG menu path | Accrual Engine Data Migration> Migration of customization for Accrual Engine > Migrate Customising for accrual engine |
- Maintain the following values in the views described below:
You should not get any error in this step, if any error is noted in a test run, you may have resolved the error before proceeding ahead with migration.
You may note there is the option to reset the migrated customization, this would delete the migrated customization from new tables.
1.3 Manual Migration steps for accrual engine
Use
Using this Customizing activity, manual steps of migrating configuration items needs to be performed. This line item specifically refers to account determination. There are two steps in doing this activity, one is to check what was old configuration and the second being retrofit the old account determination logic into a new configuration table.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEADETCUST |
IMG menu path | Accrual Engine Data Migration> Manual Migration steps for account determination > Account Determination for manual accruals |
- Maintain the following values in the views described below:
The idea is to note how to account determination logic has been written in this step. If there is extended account determination logic that has been written, the same can be displayed as well.
Maintain new account determination
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEADETCUST |
IMG menu path | Accrual Engine Data Migrationà Manual Migration steps for account determination à Account Determination for manual accruals à Create Post Migration Content à Create and Edit basic account determination |
- Maintain the following values in the views described below:
The biggest difference between the old framework and the new framework is how offsetting accounts and P & L accounts were treated. In Old accrual engine Offsetting account and P & L account were column whereas in the new accrual engine these are represented by row with identifier PER_ACCR_ACCNT and PER_OFFSTNG_ACCNT.
If you are going to determine the offsetting account or accrual account via user input at the time of accrual object creation, these line items need to be kept empty. You may enter the data directly in the customizing table TACAC_ACCDETS4 and then capture the table entries in the transport request if the data volume of the account determination is large.
1.4 Migrate BAdi from old accrual engine to new accrual engine
BAdi implemented in the old accrual engine won’t work in the new accrual engine. Below BAdi is obsolete.
- ACEPS_BAPIPREDOC_MOD “Change Document Before Summarization” and
- ACEPS_BAPIDOC_MODIFY “Change Document After Summarization”
New BAdi BADI_ACE_DOCUMENT_SCHEMA_CUST is introduced.
Please make sure the old logics implemented is retrofitted in the new BAdi.
BAdi for the migration steps: Implement the BAdI ES_ACE_MIG (Migration for custom includes in old tables: method IF_BADI_ACE_MIG->ACESOBJ_ASSGMT_MAP)
If any of the custom fields have been included in old tables such as ACEDSASSGMT, the standard migration program will not migrate values in those fields. We have enhanced the standard migration program using BAdi mention above.
1.5 Preparation for Migration of transaction data – GL account used for Migration
Use
In this activity, for each application using the Accrual Engine, you specify for each company code the G/L account to which the system is to post the migrated Accrual Engine postings.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEMIGIMG |
IMG menu path | Accrual Engine Data Migration> Preparation of migration of transaction data > specify GL account used for migration |
2. Maintain the following values in the views described below:
During the migration of transaction data, the system is going to create an entry in the ACDOCA table using this GL account for each of the accrual objects.
1.6 Preparation for Migration of transaction data – Create Mass Data Project for Migration of Accrual Engine Transactional Data
Use
The transactional data of the Accrual Engine consist of accrual objects and accrual postings. You migrate both these objects using a mass data project.
In this activity, you create the required mass data project. After you have completed one or several test iterations, you migrate your mass data project into your production system. For this reason, this mass data project is a Customizing object.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEMIGIMG |
IMG menu path | Accrual Engine Data Migration > Preparation of migration of transaction data à Create Mass Data Project for Migration of Accrual Engine Transactional Data |
- Maintain the following values in the views described below:
1.7 Preparation for Migration of transaction data – Assign Migration Project to Company Codes
Use
In this activity, you assign a mass data project id to company codes.
The program that migrates the transactional data of the (old) Accrual Engine to the (new) S/4HANA Accrual Engine will migrate the data of those company codes.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEMIGIMG |
IMG menu path | Accrual Engine Data Migration> Preparation of migration of transaction data > Assign Migration Project to Company Codes |
- Maintain the following values in the views described below:
2. Migration of Transactional data of Accrual Engine– Run Project for Migrating Transactional Data of Accrual Engine
Use
You migrate your transactional Accrual Engine data.
Before you migrate, make sure the following configuration is there in your environment
Config node: IMG>Financial Accounting >General Ledger Accounting à Business Transactions > Accruals Management > Basic Settings àAccrual Item Types > Define Accrual Item Types
Ledger Group 0L drives the migration for item type mapping internally. If your accrual engine setting needs posting to be made to open item managed GL account, you may remove 0L after the migration is carried out.
Steps to carried out in production
- Migrate Old accrual objects with the configuration of ledger group 0L
- Once the accrual object migration is complete transport changes to remove 0L from configuration, will enable accrual posting to open item managed GL accounts.
Procedure
- Access the transaction by choosing one of the following navigation options:
Transaction code | ACEMIGIMG |
IMG menu path | Accrual Engine Data Migrationà Migration of Transactional data of Accrual Engine > Run Project for Migrating Transactional Data of Accrual Engine |
- Maintain the following values in the views described below:
Select the Project you have created to run the migration
The migration process is a step by step process. Follow the sequence mentioned in the cockpit.
Before Upgrade of the production system start, it is important to clear any postings in the t code ACACTRANSFER, any accrual document in the old accrual engine not posted to finance will come as the following type of error
The FI journal entry for ACAC/3010/2019/RVNUEP/SFRS/941882796A9D1ED899B6461B6CFB70EF/00001 hasn’t been posted.
Step 1: ACE: Reconcile accrual objects before migration
Select the activity and Press on
Pop up will come as follows
In this step, all rechecks are done from a data consistency perspective.
Once the packages are run in the background cockpit will show follows
Click on Errors from the toolbar to list out records with error
Double click on Error
Check the accrual object and carry out the required action, you have to update the old table and correct the data.
Step 2 ACE: Reconcile accrual postings before migration
In this step any postings which have not been posted to finance will come as an error. In a test environment, you can ignore but it’s important that in the production environment all such unposted documents are either deleted or posted to finance.
Select the activity and Press on execute
Pop up will come as follows
The following output will be displayed on the cockpit
Click on Error to filter out records with error
Step 3: ACE: Migrate accrual objects
In this step, all the master data will be migrated from old tables to new tables. It is important to have a quick table count check for old vs new table.
You may do a quick comparison of old table data vs new table, key tables are as follows
Old Table | New Table |
ACEOBJ | ACESOBJ |
ACEDASSGMT | ACESOBJ_ASSGMT |
ACEDSOP | ACESOBJ_PARAM |
From the Cockpit screen Select the activity and Press execute
Following output screen will appear once processing is complete
Do check the table count for table ACESOBJ, ACESOBJ_ASSGMT and ACESOBJ_PARAM. There are other tables as well but this three table contains accrual object master, account assignment and parameter level information
You can see old accrual objects are migrated. You can go to t code ACACTREE02 and verify any of the old accrual objects.
Step 4 : ACE: Check accrual objects after migration
In this step system validates migrated master data to find any prospective error.
Select the activity and Press Execute
Pop up will come as follows
Following output screen will appear once all processing is completed
Step 5 ACE: Migrate accrual postings
This step will migrate all the transaction postings from the old accrual engine and will create an entry in the ACDOCA table with account configuration mentioned in “Accrual Engine Data Migration> Preparation of migration of transaction data > specify gl account used for migration”
Select the activity and Press on execute
Pop up will come as follows
Once processing complete following screen will appear
We may check quick data entry in the ACACTREE02
Document number starting from CB* indicates migrated items
Step 6: ACE: Check accrual postings after migration
In this step, all the entries which have been created in the ACDOCA table will be verified by the system.
Select the activity and Press on execute
Pop up will come as follows
Once processing is complete following status will be shown
Once you complete the above steps, the migration process is complete.
Conclusion
S4HANA Accrual Migration cockpit tool is a very useful tool to migration old accrual objects and historical accrual posting to the new S4HANA environment.
Following are key lesson learned during the migration process
- In terms of the time of execution, the tool handles huge data very efficiently, so overall execution time in the production server remains in 1-4 hours. This would include all validation activities.
- Before the start of the Migration activity, it’s important to make sure all the relevant OSS notes are applied.
- If old accrual engine tables were enhanced, it is important to implement BAdi so that the standard migration process can migrate the data from the old table to the new tables.
I trust the above information would help the finance consultant to execute the migration activities. If any questions on this topic feel free to reach out to me by responding to this blog post.
Okumaya devam et...