Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
Shakeel_Ahmed
Product and Topic Expert
Product and Topic Expert




 

Business Scenario


In my experience, during sales and pre-sales discussions for various SAP deals, a common question often arises when engaging with executives, whether it's the CFO, CIO, or other C-level discussions. That question revolves around the fate of their old data and whether they can continue reporting on it within the SAP system. In response, we typically propose workarounds.

With SAP S/4HANA Cloud, public edition (similar feature you have in S/4HANA Private Cloud.OP) you have the capability to import historical data and generate reports at the G/L level, offering insights from both Profit and Loss and Balance Sheet perspectives. You can seamlessly upload balance data for the past 33 years.

Learn more about its coverage: Historical Balances

 

Introduction


You can migrate historical financial transactions into your SAP S/4HANA Cloud using the SAP S/4HANA Migration Cockpit.

This process loads the historical balances for general ledger accounts into the universal journal without intricate validation checks, resulting in zero net effects. Consequently, these balances will automatically be reversed on the specified migration key date, ensuring a zero balance. The migrated historical balances are primarily intended for reporting purposes, and it's not feasible to access the migrated documents themselves."

Historical financial balances are needed only for audit and internal reporting purposes. Individual accounting document cannot be seen.

Note: Utilize the migration object 'FI - Historical Balance' to import historical balances for existing general ledger accounts.

 

For each period, include only one line per document in the migration file. A 'Document Posting' (Migration item) should be created based on a combination of the company code, G/L account, ledger (0L, 2L, etc.), period, and fiscal year.

 

Key Features Supported



  • Migrating historical G/L account balances.

  • Migrating closed posting periods prior to the migration key date.

  • Posting to G/L accounts with open item management.

  • Posting to G/L accounts (with cost element category 1) without the necessary CO object assignment.

  • It is feasible to make postings with a cost center even when the cost center's validity is not applicable on the posting date or period of historical data.

  • Direct posting to reconciliation accounts (Customer, Vendor, Asset).

  • Handling data up to 33 fiscal years in the past.

  • Managing multiple account assignments for the same historical balance posting with identical key field combinations and different run IDs.


 

Prerequisites



  • Migration Key Date with Ongoing Data transfer status in Define Settings for Legacy Data Transfer

  • Cost Center (if required for historical data migration postings)

  • Profit Center (if required for historical data migration postings)

  • Master Data for Joint Venture Accounting (JVA) (if working for Oil and Gas industry)


 

Supported Currencies


Historical balance migration object facilitates the data migration of the following currency-related fields:

  • Document/Transactional Balance Currency

  • Company Code Currency

  • Group Currency

  • Freely defined currency/3rd currency


Currency-specific guidelines

  • All currency amount fields (transaction, group, etc.) are required and must be completed. Failure to do so will result in an error message during both the simulation and migration processes.

  • The transaction/document currency field is mandatory and must be filled. Other currency fields (USD, INR etc.) are optional.


 

Data Migration Approach for Historical Balance


Select one of the two available migration scenarios within the SAP S/4HANA Migration Cockpit by configuring/confirming the 'Control Parameter'.

Approach 1: In this approach, 'Next Period Movement/00001' is used for Profit and Loss (P&L) G/L account balances, and 'Period Balance/00002' is employed for Balance Sheet G/L account balances.



  • Migration Date for Cut-over




Method: Next Period Movement:


Initially post the balance in the first period and then post the subsequent period's movements (primarily intended for profit and loss accounts). We will use this method to upload historical profit and loss account balances.

Control Parameter selection in against your migration project 00001




  • Below is the file that we have prepared an upload template for P&L balances for period 1/2015.


 




  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 01/2015



 

  • Below is the file that we have prepared an upload template for P&L balances for period 2/2015.





  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 02/2015





  • Below, it is illustrated when and how the reversal entries occur for Profit and Loss (P&L) balances. The reversal takes place in the month of the Go-Live date, which is defined in the 'Migration Key Date with Ongoing Data Transfer status' within the 'Define Settings for Legacy Data Transfer' app. The cutover date is set as 31.03.2022.


Reversal of P&L Entries:


Here “Next Period Movement” is how it works: Example.

Method: Period Balance


It records each uploaded balance at the beginning of the posting period and the system automatically reverses it in the following period. We will employ this method for managing Balance Sheet G/L account balances.


Control Parameter selection in against your migration project 00002




  • Below is the file that we have prepared an upload template for Balance sheet G/L balances for period 1/2015.





  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 01/2015


 




  • Below is the file that we have prepared an upload template for Balance sheet G/L balances for period 2/2015.


 




  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 02/2015



Here is how “Period Balance” works: Example.



Reporting on Historical Balances



  • Reporting of Balance Sheet and Income Statement using Historical Migrated Data for the period of 01/2015.





  • Reporting of Balance Sheet and Income Statement using Historical Migrated Data for the period of 02/2015.





  • Reporting of Balance Sheet and Income Statement has zero balance for the period of 03/2022 which is data migration date/period also. Report is being seen before any go-live cutover transaction.



It is automatically zero in the cutover period i.e., 03/2022. Cutover has no impact or change due to historical balances upload.

Approach 2: In this approach, 'Period Balance/00002' is utilized for P&L and Balance Sheet G/L account balances.



  • Migration Date for Cut-over




Method: Period Balance:


It records each uploaded balance at the beginning of the posting period and the system automatically reverses it in the following period. We will employ this method for managing P&L and Balance Sheet G/L account balances.

Control Parameter selection in against your migration project 00002


 

  • Below is the file that we have prepared an upload template for period 1/2015 and period 2/2015.


 





  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 01/2015





  • This is how a posting will be displayed in the system when viewed in the 'Display Line Items in General Ledger' app (accessed from the 'Display G/L Account Balances' app) for period 02/2015



 

Documents highlighted in yellow represent reversals for period 1 in period 2. We have included the cumulative balance of period 1 and period 2 in the period 2 upload.

 

  • Reporting on Historical Balances

  • Reporting of Balance Sheet and Income Statement using Historical Migrated Data for the period of 01/2015.



 

  • Reporting of Balance Sheet and Income Statement using Historical Migrated Data for the period of 02/2015.



 

  • Balance Sheet and Income Statement for the period of 03/2015



It is zero/no balance as we have not uploaded for period 3/2015. Previous data is already reversed.

 

Migration File and Accounting Document No. Generation


Data Migration and File Preparation



  • Import Method for Historical Balances should be one method within one Data Migration Project.

  • Each project will process only one file. If you attempt to process a second file, you will encounter the following error:





  • Fiscal year and period must precede the migration key date. Postings after this key date are not permitted.

  • You are not required to upload Profit or Loss data for P&L and retained earnings G/L accounts. The system will automatically calculate them based on the transaction data for historical balances.

  • Parallel processing is not an option for this task. This migration object can be used with only one job at a time, as the underlying API does not support concurrent processing.

  • Correcting Historical Migrated Balances: Change source amounts from positive to negative, e.g., 100.00 to -100.00. Then, remigrate the corrected data in a separate project due to key field constraints.

  • For each period, include only one line per document in the migration file. A 'Document Posting' (Migration item) should be created based on a combination of the company code, G/L account, ledger (0L, 2L, etc.), period, and fiscal year.

  • Posting multiple line items per document – Not Available

  • Utilizing external accounting document numbers - Not Available

  • Making postings on blocked or non-existing G/L accounts - Not Available

  • Direct posting to an extension ledger not supported.


 

Accounting Document:



  • The internal document number follows the naming convention, for instance, DHG0000001:


D = Document


H = Historical


G = General Ledger Balance


0000001 = Sequentially generated




  • Similarly, the naming convention for a reversal document number, like DHR0000001, is as follows: Reversal Entries are generated at the same time (with same template) automatically in the very next period.


D = Document


H = Historical


R = Reversal


0000001 = Sequentially generated




  • The template contains the posting period and fiscal year, with document dates not included. The system consistently uses the first day of the month as the posting date, which is also applied to reversal entries.


 




  • Document number for record purpose is generated but can not be seen in Manage Journal Entries App.



 

How to Verify and Report Your Data in the System for Historical Balances



  • Data Migration Status app

  • Display G/L Account Balances (new) app (It will show reversal also, can be filtered out)

  • Display line items in General ledger app (It will show reversal also, can be filtered out)

  • Balance sheet/Income Statement App

  • P&L – Actual

  • Cost Center Report (It will show reversal also, can be filtered out)





  • Profit Center Report (It will show reversal also, can be filtered out)





  • Executing The Trial Balance Report


Ensure that every balance associated with the G/L accounts in the production system is reconciled to zero by the cut-off date. Ideally, the general ledger should have no entries at all.

  • Reviewing Balance Carry forward Accounts.


Ensure that the balances in the balance carry forward accounts, such as Retained Earnings Accounts, are at zero in the production system before migration. If any balance is not zero, you can manually clear it by executing a new carry forward process.

More Information



  • Most Important: Your data migration balance for the go-live date will remain unchanged, regardless of whether you have uploaded historical balances or not. The utilization of historical balances has no effect on your go-live date migration balance. It will be treated as if a zero balance has been uploaded through the historical balance upload. Everything gets revered effectively which are upload as part of Historical Balance.

  • Only the ACDOCA table (Universal Journal) will undergo migration. There will be no entries in BSEG andd FAGLFLEXA, as only balances are migrated, and no documents are generated.

  • No need for Balance Carry Forward execution.

  • Available Migration Objectsin SAP S/4HANA Cloud.

  • Viewing migrated historical documents - Not Available

  • Ensure you have the required Business Catalog for Data Migration project creation: SAP_FIN_BC_GL_JE_PROC_PC


 

 

 




Disclaimer: This article is intended solely for educational purposes. When engaging in customer projects or working with SAP S/4HANA Cloud, Public Edition, it is essential to follow and seek guidance from the official SAP documentation available on https://help.sap.com/docs/ for S/4HANA Cloud, Public Edition.

 




Learn > Share > Grow

Embrace a culture of continuous learning and growth. Stay connected for additional insights and future blog posts to expand your knowledge.
1 Comment
Labels in this area