SAP 1 ERP Central Finance

SAP 1 ERP Central Finance

Harminder Singh, Suresh Perumalla, Brian Vanderwiel

Verizon wireless

Abstract:- Central Finance (CFIN) is an SAP provided solution to plan and implement a roadmap for migrating legacy ERP systems into S/4HANA with minimal disruption to the legacy financial systems. Documents posted in source systems are replicated into S/4HANA and posted to the S/4HANA ledger after transforming the source system data to a common data format. By standardizing data into a common format CFIN enables cross system functions like allocations, segmentation, and consolidations in S/4HANA and paves the way for migrating month-end and year-end book close from source systems to S/4HANA. This whitepaper covers the technical and functional aspects of the CFIN implementation. In this document we will cover details of the integration between non-SAP, legacy SAP (ECC), SAP Landscape Transformation (SLT), Master Data Governance (MDG) and SAP S/4HANA systems.

1. INTRODUCTION

Like large enterprises has complex financial systems, multiple SAP, and non-SAP for different business functions. To reduce redundant processes and to simplify our period end closing process, we emerged with our own strategy which is elucidated in the journal and implemented the central finance solution of 1ERP by referencing the mentioned references. We embarked on a multi-year journey to consolidate all legacy ERPs into S/4HANA. As a first step of our ERP consolidation journey, we implemented CFIN to replicate posted financial documents from non-SAP and SAP ECC systems to S/4HANA using the SAP Landscape Transformation (SLT) replication server. CFIN standard functionality is utilized to transform replicated documents to a common format using key mapping (account, profit center, cost center, etc.) and value mapping (company code, document type, posting key, etc.). CFIN performs all applicable FI substitutions and validations, and posts error free documents to the S/4HANA ledger. Any issues encountered during mappings or validations are flagged as an error and managed by SAPs Application Interface Framework (AIF) where mapping/validation issues can be corrected, and the data can be reprocessed.

SAP Central Finance Architecture

Figure 1 illustrates the architecture of the CFIN implementation. We have 2 SAP ECC systems as source systems shown in architecture diagram, and PeopleSoft 9.1, PeopleSoft 9.0, Oracle and Cost point are non-SAP source systems. The SLT replication server and MDG systems are standalone. The MDG system (also an S/4HANA system) is used for master data and key mappings.

The legacy SAP ECC applications are connected directly to S/4HANA via the SLT. Since SAP does not support or

provide any tools to connect non-SAP systems directly or via the SLT, we developed a custom solution, which is outlined in section 2.

Figure 1: Architecture of Central finance.

2 INTEGRATIONS OF SAP AND NON-SAP SYSTEMS

In this section we will walk through the integration of SAP and non-SAP systems with S/4HANA. Note that extensive knowledge of the source system data and how it is structured is required to build a plan for extracting and transforming the data, and to achieve a successful integration.

SAP Systems

SAP landscape transformation (SLT) is an existing tool used extensively for replicating data from SAP/Oracle applications to SAP HANA at the database level. In this section we will cover how we can utilize SLT to replicate posted financial documents [1]. To enable financial document replication, it is very important to enable the content in SAP SLT with which S/4HANA and SAP ECC application can communicate and that is possible only if you have the understanding of SAP note 2154420. Apply the latest content of note 2154420 according to your release of the system and always have the latest copy of this note.

Figure 2: Connectivity from SAP ECC to S/4HANA

We have created separate MTIDs for SAP ECC application to replicate documents to S4. Also, once you upload the latest SAP content that content needs to be generated in master workbench transaction. Please refer

the below screenshot for SAP ECC to S4 MTID configuration. Similar way we completed the setup of other ECC system.

Figure 3: MTID setup from SAP ECC to S4.

So once the MWB objects are generated, structural relationship will be defined, and mapping will be done.

Figure 4: Structural Relations SAP application

After enabling replication on the SAP source systems, header details of the posted/changed documents are captured on the delivered CFIN replication trigger table CFIN_ACCHD. As soon as a document header is posted to the trigger table, SLT extracts the details of the document and pushes them to S/4HANA. The required configuration and MDG connectivity for CFIN is maintained on the target system (S/4HANA) using transaction code CFINIMG. CFIN utilizes FINS_CFIN_AC_INTERFACE BADI to process incoming documents from the source SAP systems. There are 4 major steps in the BADI –

1. PREPARE_INPUT_DATA Prepares incoming data before applying transformations. This method customized to include custom fields.

2. MAP_VALUES Both Key and Value mappings executed in this step. MDG utilized for key mapping and value mapping are based on VMIMG. Customized to include custom fields.

3. ADJUST_POSTING_DATA Executes final adjustments to the data before calling post step. Customized to apply specific default logic(s) and to handle rounding issues between source and target currency code definitions.

4. CALL_AC_INTERFACE Calls delivered accounting document creation interface to post transformed data from step# 1 through 3.

Key mapping values are maintained in MDG and value mappings are maintained in the target system using transaction code VMIMG by each logical system (source system).

AIF is a framework to implement and monitor application interfaces. As part of CFIN implementation SAP delivers standard AIF interfaces for managing CFIN replication [2]-[3]. We utilized SAP delivered interface ids AC_DOC & AC_DOC_CHG for SAP source systems and AC_DOC_EX for non-SAP source systems. Errors from CFIN replication can be monitored and reprocessed by using /AIF/IFMON or /AIF/ERR codes.

Non-SAP Systems

The most interesting topic we found in central finance is the integration of the NON-SAP application with S4HANA, it is quite challenging to configure the NON- SAP application with S4HANA, as it involves lot of customizing. We are replicating documents from NON- SAP applications like PeopleSoft (9.1 & 9.0), oracle and cost point. We created custom programs, tables and used advance replication options to replicate posted documents from all NON-SAP applications. After replicating posted documents to custom SLT tables, we used custom modules and standard SAP functionality to replicate documents to S4. For more details please refer sap note 2481900, this SAP note keeps on changing, so we recommend to use the latest copy of this note. Figure 5 illustrate the data flow from NON-SAP application to S4 (eg.Peoplesoft 9.1).

Figure 5: Connectivity from non-SAP to SAP S/4

Below diagram illustrate the MTID configuration of Non-SAP application (eg. PeopleSoft 9.1)

Figure 6: MTID setup from NON-SAP to S4.

To replicate the data from NON-SAP application to SLT, advance replication feature plays the most important part. So we created custom functions to map and filter data from source system tables to customs tables on SLT.

Figure 7: Mapping of the NON-SAP table with custom programs.

A custom rogram scheduled to run every few minutes to process data on Z tables and performs following four major functions:

1. Splits PeopleSoft 9.1 documents into multiple SAP documents based on the multiple PeopleSoft fields used for S/4HANA company code derivation.

2. Split each document from step #1 into multiple documents if the total number of lines in the document is more than 900 lines.

3. Generate a unique object key for each replicated S/4HANA document to enable duplicate identification in AIF.

4. Map PeopleSoft field values to SAP fields and post the processed data to the CFIN SAP SLT tables (/1LT/CF_E_HEADER, /1LT/CF_E_ACCT and

/1LT/CF_E_EXT_IT).

The delivered /1LT/CF_E_HEADER table acts as a trigger for the non-SAP systems replication. As soon as a header record is posted to the table SLT pushes document details to S/4HANA. Like SAP replication, external system documents received from SLT go through key and value mapping and standard FI substitutions and validations before posting to S/4HANA. Any documents with mapping or validation issues/errors are managed in AIF.

To manage our Z tables volumes, enable manual intervention for production issues, and facilitate testing, several utility programs were created allowing the team to upload data, archive data to backup tables, and delete data from the Z tables.

Figure 8: File based replication from NON-SAP to S/4

PeopleSoft 9.1 replication was a big challenge for our team as we had to deal with large volumes of data (80M+ line items per month). By design PeopleSoft stores more details online item tables (PS_JRNL_HEADER and PS_JRNL_LN) compared to the ledger table (PS_LEDGR) and to replicate necessary line-item details

we choose to tap into the PS_JRNL_HEADER and PS_JRNL_LN tables as our source for replication. But PeopleSoft uses the same line-item tables for storing all journals (documents) including journals in progress, awaiting for approval, awaiting for posting, posted, etc. This resulted in an additional challenge to filter data at the source system to pass only posted documents to SLT, especially the PS_JRNL_LN table as it does not have a field to identify posted journals. Our source system database administrators built a custom process to filter and pass only posted journals to SLT.

One more challenge we faced with PeopleSoft 9.1 is the performance impact on the source system, especially during month-end processing. We leveraged Oracle Golden Gate technology to address performance issues on the source system. Instead of tapping PeopleSoft 9.1 tables directly we replicated data from PeopleSoft 9.1 to Golden Gate and utilized Golden Gate tables as input to SLT replication. Another one of our non-SAP systems, Cost point, uses replication like PeopleSoft 9.1. Both are real-time replications.

Replication of data from two other non-SAP source systems (Oracle and PeopleSoft 9.0) is similar to PeopleSoft 9.1, but instead of using real time replication we utilize file-based interfaces. As soon as an interface file arrives on the SLT file system from a source system, a custom process kicks off in SLT to read and process the file. Basic functionality is similar to the PeopleSoft 9.1 custom process, documents from the source system will be split into multiple SAP documents by number of lines, map PeopleSoft 9.0/Oracle fields to SAP fields, generate unique object keys for identifying duplicates for each document and post data to the /1LT tables. Data flow after posting data to the /1LT tables is exactly the same as PeopleSoft 9.1 replication. Figure 4 illustrates the non-SAP replication including the file transfer and the mapping of FI documents on the S/4HANA side.

Depending on the replication volume, architecture of the source system and network landscape we utilized different integration methods for different external systems. PeopleSoft 9.1 and Cost Point are real time integration using SLT, whereas Oracle and PeopleSoft

1. are file-based interfaces. To ensure data integrity we added additional controls in the custom modules to identify duplicate journals/documents for real time integration and to identify duplicate files for file-based integration. By doing so we were able to catch and eliminate duplicate errors before AIF and also added additional file-based interface controls to identify missing files.

   Performance Optimization

   Another challenge which we faced was to optimize the performance of the replication, our business team has certain SLAs for the replication of documents. The number of documents replication from SAP Application and NON SAP legacy systems are huge, so to meet those SLAs we turned on the parallelism in advance replication feature,

   with which can replicate the documents with in the defined SLAs. There is no simple formula which can fine tune the overall replications, its an effort of days with which we can reach to that point where we can meet the overall SLAs. Balanced access plans with parallelism on the table under replication for NONSAP system. One more area we concentrated on for performance tuning was custom processes on SLT to map legacy values to standard SLT replication tables. We designed all custom processes by unique key utilized in the source system, for example custom process for PeopleSoft 9.1 is designed to process journals by PeopleSoft Business Unit and Journal Date. By doing so we were able to schedule parallel jobs to run concurrently and process data for multiple business unit simultaneously without looking any time during close window.

   Figure 9: Replication of documents within SLA

   Figure 10: Parallelism on the Access plan and table replication

   Upgrade Strategy

   We started 1ERP project on 1709 S4 release on HEC and SLT with DMIS on 2013 on Sybase database. Then we migrated our production landscape from HEC to on premise and database migrated from Sybase to HANA 2.0 and this was a big change in our landscape. Using standard SAP provided R3Load tool, we migrated production data of SLT to HANA 2.0. As mentioned above in SAP system and NON SAP system, we upgraded the latest content to 1909. Key challenges which we faced after the upgrade and migration was the data type for logging table got changed and we had to regenerate the runtime object and workbench objects. Also, with that we have to upgrade the upgrade the DMIS add-ons in the source SAP systems.

   3 RECONCILIATION

   Apart from the complicated PeopleSoft 9.1 integration, the biggest challenge we faced was data reconciliation. Our main objectives for this CFIN integration were to meet SLAs for replication timings, and data integrity. Data posted in the source system should tie with data posted in S/4HANA with minimum or no manual intervention. We utilized a different reconciliation approach for SAP and non-SAP source systems.

   Reconciling data for SAP source systems is simple and straightforward. Out of the box, SAP provides two reports to compare data between source and target systems and report any missing data.

   FINS_CFIN_DFV_FI_NUM: Reconciles data at documents level and provides details of documents in source, documents in AIF with error, documents in AIF without error and documents not in CFIN (missing).

   FINS_CFIN_DFV_FI_BAL: Provides details of G/L balances between source systems, AIF and S/4HANA ledger.

   Reconciling data for non-SAP systems is more challenging. Out of the box SAP does not provide any utility/tool to reconcile data for non-SAP source systems. We leveraged BODS to build custom reports to reconcile data between SLT and Source system tables and report any discrepancies. By using BODS we were able to directly connect and query source system and SLT tables, which is must efficient than building a custom SAP reports on SLT to directly query source system tables. BODS reports are just one piece of the puzzle, they ensure that all the data posted in the source system replicates successfully to SLT standard tables. The second piece of the puzzle i data reconciliation between SLT standard tables and S/4HANA. We built a second custom process to do this validation. A simple program to compare data between the /1LT /CF_E_HEADER table and the S/4HANA AIF tables to make sure that all documents replicated to S/4HANA and to verify that there are no duplicates in S/4HANA by Object Key. This ensures that none of the source documents are missed in replication or posted twice in the target system.

   The reconciliation process for both SAP and non-SAP systems is automated and scheduled to run multiple times a day to report any discrepancies as soon as possible.

   CONCLUSION

   In order to enable large enterprises with multiple legacy financial systems to accelerate their migration to S/4HANA with minimal disruption to the existing systems, they must choose the best integration option to ensure success of the CFIN project. Some of the key aspects the team should consider before deciding on the type of integration includes:

   • How much data is being replicated?

   • How soon do you need data in target systems?

   • Can legacy systems support the type of integration?

   • Does it cause any performance issues on the source system?

Answers to these questions will help users to decide which type of integration best suited for implementation.

REFERENCES

BLOG:

1. Ahmed, S. (2017). SAP S/4 HANA Central Finance: A Complete understanding about Central Finance. https://blogs.sap.com/2017/12/28/sap-s4-hana-central-finance-a- complete-understanding-about-central-finance/

2. Rainer, C. (2020). Different views on what is Central Finance. https://blogs.sap.com/2020/02/14/different-views-on-what-is- central-finance/

3. 3.https://www2.deloitte.com/us/en/pages/finance- transformation/articles/cfo-guide-sap-s4hana-central- finance.html