Central Finance - Lessons Learned Initial Load & R...

former_member263859 · ‎10-01-2021

Introduction

Having been involved in various SAP project implementations we all know how critical the learnings from a project are and how they can help us if we face the similar situation again.

We are a group of consultants at SAP dedicated to gather valuable lessons learned during Central Finance projects and share within the external community. Our main objective is to elaborate on lessons learned in regards to Classic Initial Load and Realtime Replication of transactions from source system to Central Finance system.

Overview

Initial Load is used to transfer postings from a particular period, e.g. current fiscal year, from source system to Central Finance. Classic Initial Load of FICO posting is carried out via customizing in Central Finance.

Initial load of CO Posting, posting to secondary cost elements, is carried out via SLT.

The below architecture diagram represent which different interface are available for replication from Source system to Central Finance.

Before executing initial load to transfer posting, All relevant master data should be created in Central Finance -

initial load of cost objects should be executed to replicate cost objects that exists in source system.

Projects and WBS should also be replicated from source system.

It is recommended that Initial Load be executed in following sequence

Master Data Load (GL, Customer/Vendors..)

AUFK Initial Load (cost Objects)

WBS Replication

FI/CO Postings

CO secondary Posting Documents.

for the initial Load, view VFCIN_SOURCE_SET needs to be configured in source system which controls balances from which month/year are transferred and what documents are transferred to Central Finance.

Once Initial load is completed Real Time Replication can be activated. Real time replication for FI/CO posting in performed via SLT.

The 2 main difference between Classic FI/CO Initial Load and Real time Replication are:

Granularity of data
- For Classic Initial Load - Data is read from accounting tables (BKPF/BSEG/BSID/BSIK..), where data is summarized based on the summarization setting maintained in source system
- For Realtime Replication - Data is captured in Central Finance Staging table in source system, at the time for posting, before summarization takes places. so the transactions replicated has more granular information.

Error handling
- for Classic Initial Load - any errors resulting from reposting of transactions in Central Finance can be viewed via Application Log via CFINIMG.
- For Real time replication, as replication happens via SLT, error handling is done using AIF Monitor.

This blog will mainly focus on lessons learned from FI/CO classic initial load and real time replication.

FICO Initial Load - Considerations and Challenges

Upgrade the SAP source systems to current. Fixes for issues will be in place. Otherwise, notes must be individually installed, which can be time consuming and increases risk of notes being missed out.

Data volume should be considered when deciding on timeframe for transferring documents . Business should be involved in discussion to determine how much of history should be really transferred to Central Finance.

Reposting every FI document is very performance-intensive and requires master data from the entire timeframe for which each document is transferred, therefore it is recommend to transfer balances for previous years as per business requirements.

Insufficient time and resources allocated to test cycles. Many errors related to master data, mapping and FI base configuration are seen in initial testing cycles so appropriate functional and technical resources should be allocated for test cycles. More time should be allocated to initial testing cycles where majority of errors can be hashed out.

Allocation of business resources for test cycles to carry out reconciliation activities at end of test cycles.

Not considering full volume of data during initial test cycles can lead to incorrect estimate of time required to actual cutover and go live.

Challenges loading old open items where GL Master attributes might be changed over time and is not same as the time of open item. e.g OIM flag.

FICO Initial Load - Lessons

Plan ahead, solid foundation for further phases

Pro-actively resolve errors with Standard consistency checks and simulation. This can help eliminate many errors related to GL account setup and FI/CO configuration.

Include reconciliation activity after initial load during test cycles. This will help validate the quality of data being loaded and bring out any issues/risk during early testing.

Enable Customer Teams on Error resolution process as early as possible

Scope for the testing should be defined clearly along with the entry and exit criteria for each test cycle.

Functional and technical resources should be planned to support testing cycles to fix the mapping and master data errors.

Execute the simulation of mapping and posting, even though they are optional. Although it may seem that skipping the simulations saves time, in the long run correcting problems before actual posting takes less time overall. Using the simulations may even prevent the necessity to delete and redo an initial load.

Data cleansing in source systems for Open Items reduces the amount of data to be loaded during initial load.

Fully understand and follow the prescribed procedure to drop and reload an initial load. This is essential to ensure all relevant FI/CO tables and staging tables are cleared and are empty in Central Finance, in case a situation of re-extract and reload is required after posting is executed in Central Finance.

GL Reconciliations flag should only be checked in the Initial load customizing when CO secondary postings are not planned to be replicated for the company code. If CO posting are also planned to be replicated that checking this flag in FI initial load customizing can duplicate the CO entries in CFIN.

Changing mappings after the initial load is complete and ongoing replication is started may lead to serious inconsistencies in follow-on processes. For example, if the mapping of a business partner is changed and invoices for the business partner have already been transferred to Central Finance, follow-on documents, such as clearing documents, will be posted to a different business partner.

Standard DFV reports are good starting point as reconciliation report but based on business requirement additional check might be required.

Copy of production should be used for initial load testing cycles as that will closest to production data.

Governance of customizing should be planned from the beginning so source and CFIN configuration is kept in sync.

FICO Realtime Replication - Considerations and Challenges

Some of common challenges observed for real time replication are –

Understanding differences between Initial load and Replication

Test scripts / Strategy / Production (like) data
- Mostly in initial load test cycles, snapshot of production data is taken. So it might not cover all Business process scenarios and actual volume. This then pose a challenge when testing real time replication. So testing strategy and scripts is very critical..
- Simulating real time posting like in production system can be challenging.

Learning curve on ongoing maintenance pose a challenge as users are not familiar about AIF error processing.

Capacity not planned
- SLT server resources (please refer to the SLT sizing guide) and network bandwidth to handle the volume of real time replication.
- Resources required for daily monitoring and resolving AIF errors resulted from real time replication of documents

Real-time replication testing doesn’t depend on Initial load testing. This testing can be performed after or in parallel with real-time replication. But it is recommended to complete Initial load completely before switching real time replication as you can have failure on clearing or reversal if original documents are still not posted.

FICO Realtime Replication - Lessons

Tests should include changes to master data as well which should incorporate any master data governance tool used by the customer (e.g. Standalone MDG )

Avoid master data mapping changes once replication is active.
- e.g if GL mapping is required to be change, it needs to be ensured the GL account mapped earlier does not have any open items and is balanced to zero. Otherwise there can have issues with processes like clearing, reconciliation.

Include operational Teams for knowledge transfer of known errors

Main scenarios to be included for ongoing replication: Document splitting, Intercompany postings, clearing transactions, finance documents originated from logistics modules (Open item Management)

Root cause analysis for all error categories should be documented.

AIF monitoring and error resolution process with clearly defined responsibilities should be defined.

Early Involvement of Infrastructure team for proper sizing of the Central Finance system, SLT Server and the Network. It’s important specially for the customers having high volume of transactional flow

We hope that above considerations, challenges and lessons learned which we gathered from various projects and teams in our organization will help you to plan for the Initial Load and Realtime Replication better in your projects.

You can also find more lessons on other topics by utilizing assets from CFIN Activate Roadmap. To learn more on CFIN Activate Road map, please refer to blog - Release of SAP Activate Roadmap for SAP S/4HANA for Central Finance.

We invite you to post any feedback, ideas, or tell us how this content was helpful for your project.