In this blog series, we are looking at some of the challenges and risks that most commonly affect SAP S/4HANA conversion projects and how to mitigate them with the right selection of tools and approaches.
In the previous blogs, we
- outlined areas where customers usually face challenges during conversions Conversion to SAP S/4HANA On-Premise – what are the key problem areas?
- went through consistency checks in the source SAP ERP during the Preparation phase Conversion to SAP S/4HANA- Consistency checks in Finance: Part 1
- looked into finance data migration (Conversion of Accounting) in more detail Conversion to SAP S/4HANA- Insights into Finance Data Migration
In this blog, we will discuss how to handle errors during the finance data migration phase of S/4HANA Conversion.
Start with data cleansing in the source ERP system as early as possible
Analyzing the quality of your data and performing a data cleansing can last weeks or even months. Therefore, it is very important to identify any configuration/data quality issues well in advance before your SAP S/4HANA conversion project starts. In the SAP ERP system, we have various programs available in the system for checking financial data. For checking the consistency of configuration and mandatory pre-requisites, it is the Simplification Item Check you should run in your SAP ERP system. For checking the consistency of transactional data, it is the new Reconciliation prior to S/4HANA Conversion program where we ported migration relevant G/L checks from S/4HANA to SAP ERP. Besides, we have a number of older consistency check programs such as programs for GL – Sub ledger reconciliation, comparative analysis program and technical check of documents tables program. You may refer to blog SAP S/4HANA- Consistency checks in Finance: Part 1 for detailed information.
Perform several test conversions
One of the common problems with Conversion of Accounting was that pre-check tools available in the SAP ERP were not able to detect all migration relevant data inconsistencies. The checks accessible after the technical installation of S/4HANA and executed as a part of the data migration process are more advanced than old check programs in ERP. The only way to detect all inconsistencies was to run S/4HANA test conversion on a copy of productive data. The situation has improved considerably with the release of SAP Note 2755360 which ships the new Reconciliation prior to S/4HANA Conversion program (transaction FIN_CORR_RECONCILE). The new tool contains the subset of checks which are normally executed during the finance data migration. Currently, only General Ledger checks are covered as a part of the new tool. For other finance application areas such as asset accounting, still, the best way to make sure that migration relevant data inconsistencies are discovered is to carry out one or several iterations of S/4HANA conversion tests. Experience has shown that for larger system one test isn’t sufficient. Having at least two S/4HANA Conversion tests in an SAP system, which is the recent copy of the productive system will have a positive impact on your data quality. The data quality results of these conversion tests are important for further data cleansing activities.
Error handling
The errors can be detected during different stages of a conversion project. Ideally, you discover and correct all data inconsistencies in the source SAP ERP system before starting conversion. The data inconsistencies can be detected with Analyze Transactional Data program after technical conversion or during data migration with programs which are executed after each migration activity automatically. Regardless of the stage at which the error is detected, as a general rule, you need to analyze each error, find its root cause and correct it if possible.
1. Analyze the error
Even though there are many hundreds of possible error messages types (almost 1000 error message numbers in the respective migration message classes FINS_RECON, FINS_FI_MIG, FINS_ML_MIG…), in the majority of conversions you will have to face only several error types. Besides, the error types are very often interdependent, it means that multiple error messages can have a single cause.
Sometimes, already the long text of an error message provides sufficient information to resolve the issue.
If not, a good starting point is SAP KBA Note 2714344 Financial data migration to SAP S/4HANA: Most frequent Error Messages – Information and Recommendations where you can find the list of most frequently occurring error messages together with details about possible root causes, impact, and course of actions. Here you can also identify errors that can be safely accepted.
You can search the SAP Support Portal for coding corrections of migration programs using the reported error number as a search term and component FIN-MIG.
2. Identify the root cause
There are multiple reasons for error messages to occur: you may have inconsistent data in the source system, you may have wrong or missing configuration or there may be a coding error in the migration programs. Sometimes, if affected data is old, it might not be worth it or possible to determine the root cause.
3. Correct the error
As a general rule, all errors should be corrected. If the error is due to configuration for migration you might be able to fix the configuration in technically already converted S/4HANA system. There are cases when the relevant configuration error can be resolved only in the source SAP ERP which means rolling back the whole technical conversion phase and starting again. However, If you ran the simplification item check, these kinds of configuration problems could not have escaped your attention.
If the error is because of a bug in the standard migration programs, implement the correction Note, reset and repeat the stopped migration activity.
If the error is due to transactional data inconsistency, you need to correct it in the source production system. The data cleansing in the source system must be completed before the next test S/4HANA conversion cycle to assure that the results are taken into consideration. During test conversion, it is OK to accept such an error for the sake of completing the actual test cycle.
Another way how to deal with old inconsistent data is to archive them.
4. Report an incident
In case you fail to identify the root cause, impact, or correction shall be done by SAP, you can report an incident. You always have to analyze the error beforehand and thorough documentation of your analysis for validation. When SAP accepts to support the issue, the corrections if any will be done only in the production system. (GT It means that if you want to be sure to solve the error in the next conversion run you need to execute a new copy of the production environment on your system to be converted) No corrections will be done in the migration system. Please see the SAP Note 2643232 – SAP S/4HANA migration: Accepting FINS_RECON ** errors
What is handled as a part of SAP support
The issue may be the result of custom code error, modifications or by incorrect handling of the software. For example, you changed the line item or open item management of GL account master data without following the proper procedure. Or your custom program inconsistently updated the tables. In that case, you will be offered a Spot consulting from SAP which is a chargeable service. You can refer to SAP Note 2414374 – Process followed during handling of Spot consulting incidents in Financial Inconsistencies for more details.
Errors during productive conversion
Even though you ran several test conversions, there is a small chance that an unknown, previously undetected error pops up during productive conversion run. There are several possible reasons, for example, the error could be introduced into the system in the time window between the last test run and productive run. During productive conversion, the most important thing is to minimize idle time. Therefore, it is very important to make sure that you can make fast and effective decisions about errors. Before starting the conversion, you should agree with all stakeholders on the error handling process.
When an error can be accepted
There are several scenarios when it makes sense to accept the error without correcting it.
Examples:
- Data inconsistencies in tables which are outdated in S/4HANA. A good example is an inconsistency between application indexes and document line items tables BSEG – Error message numbers FINS_RECON 220 – FINS_RECON227 Fields in XXX do not match. These are the cases when values of some fields differ between index and document tables in the source SAP EPR. If you verify it is data in BSEG which is correct, you do not have to rectify data in application indexes. These tables are not used in S/4HANA and their content is moved to backup tables.
- Rounding differences
- The result of past local currency changeover project (euro conversion, the introduction of new currency…). These rounding differences are considered as normal. Please refer to the SAP Note 2781513 – High number of immaterial differences identified during conversion to SAP S/4HANA
- Planned ordinary depreciation rounding in totals table ANLC. Please refer to SAP Note 2328351 – FINS_RECON 761 for small NAFAP differences.
- Line items Inconsistencies in the closed years – they have minimal impact on reporting if totals are correct
- Error FINS_FI_MIG 123 ”CO document XXX: more than 3 COEP items assigned to ACDOCA item”. If the affected CO documents are from old fiscal years, you can accept the errors in the migration cockpit. As a result, these items will not be migrated to ACDOCA. The CO totals will be corrected by the migration of balances (step DLT), so there should not be an impact on reporting and operations by the missing items.
- FINS_RECON 766 ”MISMATCHED BALANCE FOR ANLP”. If the error is raised for closed fiscal years, check if the aggregated totals per fiscal year between original ANLP and ACDOCA view are the same. In this case, there would only be a difference in the posting periods. In this case, the error message could be accepted. Alternatively, you can archive the ANLP table.
- “False positives“
- Group assets – Errors FINS_RECON772 No entry in original table item for entry in compatibility view ANEK, FINS_RECON744 Mismatched amount ANEP, FINS_RECON781 Mismatched balance for ANEA. These errors can be accepted since they are related to the deviation from the sequential number (LNRAN) of the existing group asset. You find more details in the SAP Note 2508546 -Error messages in the context of migration of group assets
- Non-productive company codes without data – Error FINS_FI_MIG 002 NO FI-GL aggregates for ledger &1, company code &2 exist. In case the company code is not productive, the error message can be ignored. Please refer to SAP Note 2424125 – Migration to S/4 HANA: No GL Balances.
Conclusion
To successfully migrate the existing transactional data, they must be clean and consistent. It is likely that you are going to have at least some errors in it. Therefore, rapid and efficient error handling is important part of any S/4HANA conversion project. Please let us your experience know in the comments below!
Brought to you by the SAP S/4HANA RIG
No comments:
Post a Comment