S/4HANA Central Finance Implementation - Dummy Initial Load
SAP Central Finance (CFIN), every large organization is thinking/talking about it is one or another way! It quickly gives the S/4HANA value benefits without necessarily disrupting existing processes. In such CFIN projects, there is a mandatory step for the initial load, even if you do not want to migrate the historical data from the legacy system to the SAP Central Finance system.
This blog covers the scenario where you do not require historical data to load in central finance, which happens if:
A. It is an overall greenfield project, i.e., the source system (ECC, S/4HANA) and target central finance system is new, and business started the transaction processing in the new system only.
In this case, SAP provides a "blank" initial load option and then activate the "Online Replication." However, SAP recommends this only for Proof of Concept and not for the actual production usage.
OR
B. The legacy transfers to a new source system (ECC, S/4HANA), which is getting connected to a central finance system.
In this case, SAP provides an approach to perform the “Full” initial load for migrated data and then activate the "Online Replication."
We have seen below challenges with the above approaches:
With "blank" initial load, sometimes the necessary function modules or technical programs do not get generated in the source system, which may cause an issue in subsequent online replication.
“blank” initial load does not verify whether the end to end replication cycle is working before start using that for online replication mode.
If the "full" initial load is selected, it blocks extra time in the blackout window for CFIN go-live. You would need to wait for "full" initial load to be over, checking on errors, rectify and reconcile before the system is released to users for usage.
A new approach is designed to make it more risk-free for initial load, termed as "Dummy” initial load which works as below:
(i) Before go-live blackout (can be one/ two weeks before also based on master data and technical readiness in source system), make some dummy postings into the source system with penny amounts. Such postings should capture at least the additional custom fields in the coding block to check the working of such fields in replication, as standard fields are mainly assumed to be working.
You may make such posting with positive/ negative lines so that the net impact is zero.
You can make posting per affiliate in the go-live scope.
Before such "dummy" postings, all necessary master data, etc. should be in place in the source system and target CFIN system. It does not require that all cost objects (like internal order, WBS, etc.) need to load in the source system. Even posting may be made to some migration specific G/L account, which does not require a cost object assignment.
(ii) Perform the initial load process in the source system, SLT system, and CFIN system, which will replicate such dummy postings from source to CFIN system.
Refer link "Sequence of the Initial Load" for standard SAP sequence of activities for the initial load.
Verify the postings replicated, including the custom dimensions.
This initial load will be very fast as there are only a few "dummy” entries in the source system. It may even be complete in just 1 – 2 hours window and packages will be very few, only based on the various company codes in the source system:
(iii) After this, online replication will get activated. Now, whatever posts in the source system in the go-live blackout period will go to target the central finance system on a real-time basis.
This “Dummy” initial load approach brings below benefits:
1. Results in the end to end smoke test for SLT replication to central finance, including mapping determination checking on a sample basis.
2. Reduced pressure on blackout during go-live as:
The initial load can happen much in advance of the blackout window.
Even during data migration, first, some small chunk of data can be loaded for each data migration object type, and replication can be checked before performing full data migration for that object. It reduces the risk of any bigger mess-up.
3. Proactive monitoring of replicated data during the blackout:
The migrated data in the source system can be checked for replication to central finance in Realtime. For any issue, corrective actions can be taken proactively in parallel to source system data migration.
It will result in the SLT replication to complete almost the same time as data migration completes in the source system.
4. Risk-free error handling:
If there is some issue in this mandatory Initial Load step, then the reset procedure of the initial load might need to be initiated. This procedure is documented in the below link "Reset the Initial Load and Clean-Up System Data."
· However, with this initial dummy load, this reset procedure is also rapid, and impact is limited to such dummy postings not having any financial impact. You can run the initial load as often until the SLT integration setup is entirely correct.
