Just over a decade ago, the appearance of the New Ledger represented a major breakthrough in the Sap financial data model

  • Simplification of the architecture of financial modules (including merger of the profit centers accounting the general ledger)
  • Introduction of true multi accounting principles (IFRS, Local GAAP …) through the use of ledgers within the FI-GL module
  • Acceleration of closing processes (FI-CO reconciliation & document spliting in real time, native segment reporting …)
  • Multi-axis reporting in General ledger (including through the appearance of the FAGLFLEXT table, much richer and more flexible than its ancestor GLT0)

 

Although already exceptional, this progress seems today all relative to the look of the giant leap accomplished by Sap with S4HANA

 

Firstly, the power of Sap HANA databases has enabled a drastic overhaul of the financial modules ‘ data model.

Without going into the technical details (storage model “In-memory”, based on columns, massively parallel processing), the power of this database makes it possible to get rid of the tables of totals and other secondary indexes (e.g BSIK, BSAS,…) and at the same time the “heaviness” of the associated code

Do not underestimate this progress; this constitutes a turning point unprecedented in the history of the information systems:

Finally rid of these secondary aggregates and indexes inherited from an era where the servers could manage enough RAM and processors to calculate the totals on the fly and force us to many fireworks!

 

It’s never easy to provide precise figures in terms of performance gain as the parameters are numerous but in practice, the responsiveness of the system is impressive.

What a pleasure everyday to no longer have this small amount of waiting time during each transaction call! Not to mention program execution time

This exceptional performance gain is naturally linked to the adoption of the HANA database, the current data of which is stored in RAM (no comparison at this stage with the response time of the traditional hard disks) but also the model of S4HANA hyper-purified data that is able (thanks Hana) to exonerate from the processes particularly consuming in resources and in time of updating total tables.

 

Secondly, Sap multiplied the potential of the New Ledger through the introduction of the “Universal Journal”, in other words, a table (“ACDOCA” for real data) combining the main FI-CO characteristics, allowing a simplification of reporting (“one single source of truth”) but also to relegate to the past the problems of reconciliation FI-CO and FI-AA

The ACDOCA table includes nearly 370 fields in the latest Sap S4HANA versions (variable according to the number of fields added to the Coding Block and Account based CO-PA ) but does not substitute for BSEG (FI document table which now borders the 390 fields)

In fact, it place itself at the level of the FAGLFLEXA tables – as long as the records are managed by Ledger – while condensing the real data from CO-OM, CO-PA Accountant, Material Ledger and asset accounting

 

However, ACDOCA is not a simple extension of the FAGLFLEXA table; Sap has been much more judicious in creating a universal journal without “polluting” the accounting framework (BSEG in a way) with purely analytical flows:

Thus, when a purely analytical transaction is posted, an FI document is now recorded with a header record (BKPF), records in the universal journal (ACDOCA) but absolutely nothing in BSEG and it is well there lays the whole quintessence of the Universal Journal

 

This type of flow is easily identifiable when consulting an FI part:

  • Type of part in principle dedicated (“CO” most often)
  • Part Status “U” (“Standardized Part”)
  • No input view (only view of general ledger)

 

This new “kind” of FI part (records in BKPF and ACDOCA without registration in BSEG) is also used by other mechanisms such as revaluation in foreign currencies or GL distribution cycles.

Note in passing that there are also cases of records only in ACDOCA during the carry-forward, this seems logical when there is no longer a true table of totals (replaced by views for reasons of compatibility)

 

bout This new architecture comes with many improvements / simplifications («Simplification List”)

It is not possible here to be exhaustive, as an example, for financial modules:

  • Introduction of a new type of Ledger in FI (Extended Ledger) allowing to manage (via manual journal entry only) some adjustments for various purposes (IFRS or local GAAP adjustment, preparation for consolidation, fiscal reporting, internal reporting) without replicating data from the reference Ledger
  • Merging of the general accounts with cost elements (FS00)
  • Customers and suppliers are now business partners (BP), except versions S4HANA Finance
  • Bank accounts are now master data in order to benefit from new functionalities under S4 (Account opening workflow for example) and must be managed via Fiori or NWBC
  • The new asset accounting (already available from ECC6 EhP7) now makes sense with S/4HANA and is no longer optional if you want to use this module
  • Account based Co-PA is partly related to analytical CO-PA – In terms of functionality – and is integrated into the universal Journal, making it more interesting than ever before
  • Material Ledger also becomes a mandatory step (except for S4HANA Finance versions) in order to benefit from multi-currency reporting in stock management
  • Customer credit management is now necessarily carried out in SAP Credit management (FIN-FSCM-CR) in order to benefit from more advanced functionalities (credit agency data integration, scoring and credit ceiling calculation, dependency management in credit-related events…)

 

Finally, it would be unthinkable to mention Sap’s many efforts to make the interface more user-friendly, especially with Sap Fiori, which could be described as “Web based”, “Cross platforms / devices” , “Cross applications”, “Role based”, “Transactional / Analytical / Factsheet”.

 

Marc Samama

Sap S/4Hana Consultant