Whilst customers have been successfully converting their ECC systems to S/4HANA for many years, there are still a significant proportion who have yet to make the move and these are often older implementations who remain on Classic GL.

These customers and their partners may be unsure whether a migration to NewGL in ECC prior to their S/4HANA conversion project is mandatory or recommended.

A NewGL migration project in ECC is a significant project, creating delays and cost which impact both the business case and the broader time to value for S/4HANA. However where this is not considered, customers may find the outcome of the move to S/4HANA does not meet their expectations.

Without a NewGL migration the transition from Classic Profit Center Accounting (“EC-PCA”) to running Profit Centers in the Universal Journal can have unforeseen challenges which are not recognized until late in the project.

This article is intended to provide guidance on the options and the outcomes for various scenarios.

Note that this article is only relevant for a conversion scenario and not for greenfield implementations of S/4HANA. Also I should mention that officially SAP retired the term NewGL but I’ll continue to use it for this discussion of legacy concepts.

 

What is NewGL?

There is a mass of information available on this topic but for the purposes of this discussion it can be understood as having two key elements:

• New data structures provided by Ledger tables FAGLFLEXT (totals) and FAGLFLEXA (line items) or equivalent alternatives for Public Sector and Joint Venture Accounting (“JVA”) solutions
• New functions including Document Splitting and Zero Balancing, parallel accounting (as separate Ledgers in the Ledger tables), the Segment field, flexible additional fields and the direct update from CO to enable real time FI-CO reconciliation.

These are complemented by migration tools for Classic GL customers which populate the FAGLFLEX* tables and activate new functions such as splitting. Predefined migration scenarios determine the data sources (Classic GL, EC-PCA, Special Ledgers) and whether Splitting is activated.

NewGL removed the requirement to run classic Profit Center Accounting (“EC-PCA”) which had its own update rules and timing differences. It also reduced or removed the requirement to run Special Ledgers through the use of Parallel Ledgers and custom fields.

 

But don’t you get NewGL in S/4HANA anyway?

Partially – when performing a standard Brownfield conversion from ECC running Classic GL, the system automatically moves data to the new Universal Journal structure, but new functions are not activated. In addition, the Finance data conversion has a few nuances to be aware of.

S/4HANA uses the Universal Journal table ACDOCA which holds financial data previously stored across Classic GL, Controlling and EC-PCA tables. So effectively ACDOCA provides the NewGL structures and considerably more across Controlling and sub-ledger accounting.

A conversion does not introduce new functions or change data beyond a defined standard scope. For example you cannot activate Document Splitting as part of the conversion. So whilst the NewGL functions of splitting and parallel ledgers are technically available in S/4HANA, activation requires a separate follow on project.

 

What does the standard ECC to S/4HANA conversion do?

There is considerable information already available on this process so I’ll keep it brief and focus on customers running Classic GL and EC-PCA. In very simplistic terms it is a 2 step process:

1. Software Update Manager (“SUM”) process which technically converts the system to S/4HANA. This includes updating code and creating the new tables, including ACDOCA
2. Finance post-processing which loads the data from the ECC tables into ACDOCA. The primary data sources are:

• General Ledger
  • GLT0 (GL totals in Classic GL)
  • BSEG (GL entry view)
• Controlling
  • COEP (CO line items)
• AR, AP, AA & ML item level details

What is excluded from the conversion:

• Data not in the source tables above and only in EC-PCA or other Special Ledgers
• Creation of additional ledgers
• Change from Account to Ledger approach for parallel valuations
• Activation of Document Splitting
• Population of Segment values or other custom fields

The conversion process itself is defined by SAP and there are limited opportunities to influence the standard behaviour.

 

The EC-PCA challenge

EC-PCA is often the source for management reporting as well as legal consolidation and group external reporting. This means historical data converted into S/4HANA must match these previously reported values.

The problem is that EC-PCA is not a source for the load of data into ACDOCA and vital postings are excluded, for example:

• Direct PCA postings
• PCA allocations
• End of month “splitting” of AR/AP through F.5D (Calculate Balance Sheet Adjustment) and 1KEK (Transfer Payables and Receivables to Profit Center Accounting) transactions
• Profit Center detail for Material and Asset documents
• PCA Balance carried forward

This example illustrates the issue for AR items. The Sales Order has two lines for materials each assigned to different Profit Centers. When the Billing Document updates Finance we see the GL BSEG record has Profit Centers on the Sales lines but the AR line is blank.

EC-PCA is initially updated with the Sales lines and at period end the F.5D and 1KEK transactions calculate the pro-rata split of the open invoice and posts the adjustment.

During the conversion, BSEG is the source for FI line item data in ACDOCA. For AR and AP items in particular, BSEG does not carry the Profit Center field for reconciliation account lines, meaning the Profit Center split previously held in EC-PCA is not reproduced in ACDOCA.

The extent of the issue can be evaluated in ECC (prior to conversion) at the GL account level with transaction GCAC, comparing GLT0 (GL totals) with Ledger 8A (EC-PCA totals). The same transaction run in S/4HANA (post conversion) can include Profit Center differences by comparing Ledgers 0L and 8A.

The other major issue is that there is no automatic native equivalent of the F.5D / 1KEK functions in S/4HANA without the activation of Document Splitting. The Profit Center for AR / AP items are either left blank in the Universal Journal or can be assigned (e.g. through Substitution) to a single Profit Centrer. However, a functional equivalent can be achieved via a periodic Extension Ledger adjustment as described in Scenario 1 below.

Technically it’s possible to run EC-PCA in S/4HANA but this is not recommended, due to unnecessary data volumes and reconciliation issues with ACDOCA. It is recommended to deactivate the update of EC-PCA following the successful conversion. Further details on the move off EC-PCA are described in note 2425255 – Profit Center Accounting in the universal journal in SAP S/4HANA, on-premise and private cloud and 3628735 – Profit Center Accounting in the Universal Journal after migration to S/4HANA.

So this leaves us with two issues to address:

• How to align the values in ACDOCA with EC-PCA in a conversion
• How to enable AR/AP assignment in S/4HANA post conversion consistent with EC-PCA split logic

A similar situation exists with Special Ledgers with the potential added complexity of custom fields and update logic.

 

Scenarios

Let’s look at a couple of scenarios and the potential options

Scenario 1

Customer executes the standard conversion process and needs a solution to the issues mentioned above.

1 – align the values in ACDOCA with EC-PCA

The suggested approach using standard functionality is to post GL journals for the difference with Company Code, GL Account and Profit Center plus other required attributes such as Functional Area.

This should be performed as part of the conversion downtime before new postings are made in ACDOCA.

• Execute Ledger comparison (0L and 8A) report GCAC to identify differences
• Use a dedicated Extension Ledger which can be locked following completion of adjustments and also ensures these postings are isolated from Ledger 0L. This is important because if EC-PCA is still running under compatibility mode (per Note 2425255), only 0L postings trigger EC-PCA updates; Extension Ledger postings do not.
• Use a defined Document Type for further clarity.
• Post to the specific Ledger using Transaction FB01L
• Posting is subject to usual GL controls so adjustments to MM, AR, AP & AA requires separate adjustment GL Accounts.
• Post manually for relatively low volumes of adjustments, otherwise use BAPI or API to automate.
• Post the adjustment entry against the blank Profit Center for items where PRCTR was not populated on the original BSEG line converted to ACDOCA and offset to the correct Profit Center derived from EC-PCA.
• Consider minimising postings by updating Year to Date differences rather than opening up and posting to prior periods / years. This approach needs to be balanced against the requirement for period-level Profit Center comparatives for historical periods as only year-to-date totals would align.

A project specific development would ensure this can be executed in each test conversion cycle and in Production. The development would include read of EC-PCA and ACDOCA, identification of differences, creation of the posting file and execution steps.

Note that this approach is a summary adjustment and does not update at the individual documents.

2 – enable AR/AP split

The simplest option is to accept the different behaviour in S/4HANA and to set a default value in the AR or AP line. However as this is a single posting line, only a single Profit Center can be set in the original document, even where the offsetting cost or revenue relates to several Profit Centers.

If more granularity is required to match the EC-PCA approach, the recommendation is still to default a single PC for the original posting (and any subsequent clearing) and then create a period end adjustment.

• Create a report to analyse offsetting accounts in AR and AP documents open at period end
• Define an Extension Ledger to ringfence the adjustments
• Use a defined Document Type for further clarity
• Post to the specific Ledger using Transaction FB01L
• Posting is subject to usual GL controls so adjustments to AR & AP requires separate adjustment GL Accounts
• Post manually for relatively low volumes of adjustments, otherwise use BAPI or API to automate.
• Offsetting entry to default PC from original AR & AP document
• Adjustment is Reversed in following period

A project specific development would automate the process and can be provided with default PC rules where the offsetting entries in the open AR and AP documents cannot be interpreted.

Scenario 2

In this scenario the customer is running Classic GL and EC-PCA in their ECC system and wants to introduce Document Splitting in S/4HANA, align to previously reported values and deactivate update to EC-PCA.

There are 3 potential pathways to achieve the outcome, each with its own challenges, risks and benefits.

Option A

This is the “traditional” 2 step approach, first executing the NewGL migration in ECC followed by the standard conversion to S/4HANA.

The NewGL migration covers the merge of EC-PCA and GL data as well as the introduction of Document Splitting. The S/4HANA standard conversion will move data from NewGL tables in ECC to ACDOCA table in S/4HANA.

Option B

This also entails a 2 step approach:

• First execute as for Scenario 1, with the standard S/4HANA conversion and subsequent adjustments.
• Then execute Subsequent Implementation of Document Splitting (SIS) in SAP S/4HANA which allows customers who migrated without document splitting to activate it post-migration, enabling balance sheet reporting at sub-company-code levels such as Profit Centre, Business Area, and Segment. It is included in the standard offering at no additional licence cost and follows a defined 3 Phase process (Preparatory, Execution and Post Processing). Refer SAP Help for further details.

This solution approach avoids the initial delay of a NewGL migration project in ECC and enables the business to convert to S/4HANA and start realizing value across Finance and other modules. However, it will entail delays to the achievement of the target end state until well after the S/4HANA conversion. It is recommended to execute the subsequent implementation with migration date at the start of the Financial Year.

Option C

This option is mentioned for completeness as it is not a standard approach but has been delivered as a project solution by SAP Consulting for global customers with specific requirements. It enables the realization of the target state in a single step using the SAP Selective Data Tansition (“SDT”) approach to enrich data in the source tables prior to the load to ACDOCA and has been unofficially titled “NewGL On the Fly”. It has also supported the adoption of JVA as part of Universal Journal using the GL splitting function as part of the single conversion step. It is not a standard, generally available SAP product and cannot be self-implemented. It requires engagement of SAP Consulting and is subject to eligibility assessment. 

Option comparison

 

So is a NewGL migration required?

Coming back to the original question, the short answer is “no”: the standard S/4HANA conversion will execute without NewGL live in the source system and will follow the defined process to populate ACDOCA. The slightly longer answer is “it depends” (as always).

To provide a complete answer we need to consider 3 aspects:

• Current Finance scope in ECC alongside Classic GL, e.g. EC-PCA, Special Ledgers, JVA
• Target Finance scope in S/4HANA, e.g. ACDOCA matches EC-PCA, Doc splitting active, parallel ledgers
• Timeline for achieving the target scope in S/4HANA

An understanding of these topics will enable an informed discussion of the options and outcomes.

Customers have remained on Classic GL because they have not identified a compelling business case for a migration to NewGL. It is not recommended to delay the S/4HANA conversion in order to deliver functions that have not previously been prioritised in ECC.

In conclusion

There is no single correct approach for navigating this topic but proper understanding and planning can avoid delays, rework and misaligned expectations during the move to S/4HANA.

For customers who are well progressed with their planning or even where they have started the conversion project, the approach outlined in scenario 1 is probably the preferred approach as it does not change overall timelines and the additional EC-PCA activities can be confined.

Where the conversion is some time off any of the outlined approaches are possible and the choice will depend on required business outcomes in terms of scope and timing.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Source link