Financial Management Blogs by SAP
Get financial management insights from blog posts by SAP experts. Find and share tips on how to increase efficiency, reduce risk, and optimize working capital.
cancel
Showing results for 
Search instead for 
Did you mean: 
Cirlei_Guedes
Product and Topic Expert
Product and Topic Expert

This Blog is an overview of the conversion process with which you can move from your existing SAP Business Suite to the next-generation business suite: SAP S/4HANA

Cirlei_Guedes_0-1710522414179.png

You need to gain an idea of the project steps and necessary preparations, use the following tools to do your project planning:

ASU Toolbox Application Conversion Assistant (ATACA)

ASU Toolbox Application Conversion Assistant (ATACA) contains all the information that is not already available in existing SAP S/4 HANA conversion tools, such as guidelines, check tools, migration tools, and SAP Notes to help you convert your system from SAP ERP to SAP S/4HANA in the most efficient way. 

When should ATACA be started before the Conversion?

ATACA is a tool that provides information and actions related to the source and target system. Therefore you should start ATACA as soon as you have your first Sandbox-System available where you are doing the conversion project.

You should have finalized your planning phase, the target release specification and the system analysis before starting ATACA. With this, you are guaranteed to look at only relevant steps for your conversion project.

All actions in the tool are documented to enable you to use ATACA from the beginning till the end of your conversion project.
It is recommended to view the content at an early stage where probably no actions are needed yet but to get an overview.

As soon as actions apply, you can start ATACA, do the actions and see what you have done already. The content will guide you until you reach the technical downtime of Software Upgrade Manager (SUM).
It is also recommended to view the post-conversion activities already in the source system to be prepared for actions that are coming up once the converted system has been released.
You can start ATACA by starting transaction /ASU/AMT.

When should ATACA be started after the Conversion?

You can start ATACA immediately once the Software Update Manager has released the system for post-processing activities, also before or in parallel to the FIN-Migration.
First of all, it is recommended to view the content of the after-conversion tasks already before the conversion! This ensures that you are prepared for the actions and decisions you need to make.
Once you are in the target system and start ATACA it will filter out the steps that are not relevant anymore due to your target release and will display only the relevant ones.

In case ATACA is recommending notes relevant to the FIN-Migration, make sure these are implemented before the FIN-Migration is started. Key users working with ATACA after the conversion need to be aware if the FIN-Migration is running in parallel or not. They should not execute any actions that might harm the Migration. But they can do actions in other modules in parallel. They can also check the consulting notes or tips and optimize the system.
It is recommended to view (and act to) the content of ATACA before the system is used productively by all end users again.

You can start ATACA by starting transaction /ASU/AMT.

More information SAP Note 3008338 

Simplification Item Catalog

Focuses on what needs to be considered in an implementation/migration project from SAP ERP 6.X to SAP S/4HANA. This tool enhances and replaces the Simplification List for SAP S/4HANA (PDF). The PDF is still available, but we recommend using the catalog.

Cirlei_Guedes_0-1710441271585.png

The simplification item catalog provides customers with a description of all relevant changes that might have an impact when converting from SAP ERP to SAP S/4HANA or SAP BW to SAP BW/4HANA. Within each topic, which is referred to as a "simplification item", corresponding SAP Notes and mitigation possibilities are documented.

Cirlei_Guedes_1-1710441631755.png

SAP Readiness Check

Cirlei_Guedes_4-1710509307836.png

SAP Readiness Check analyzes your existing system using built-in API's, which may need to be updated to ensure the most up-to-date analysis tools are implemented. In the Supported Scenarios section above, you will find links to SAP Notes, which guide you through the preparation steps required for the specific scenario.

The preparation steps should be initially completed in the development system and then transported through to the production system. We highly recommend running SAP Readiness Check tools in the production system to get an accurate picture of actual system usage.

Although not mandatory, this tool is highly recommended.

To access SAP Readiness Check on SAP for Me, visit https://me.sap.com/readinesscheck.

To access SAP Readiness Check on SAP Cloud ALM, select the SAP Readiness Check app in the SAP Cloud ALM for Implementation section of the SAP Cloud ALM home page. For information on setting up your SAP Cloud ALM tenant, including user role assignment, visit https://help.sap.com/docs/cloud-alm/setup-administration/required-setup.

We advise you to use SAP Readiness Check on SAP for Me if you intend on collaborating closely with SAP or a systems integrator. Otherwise, you will need to share an offline version of the results or create a user in your SAP Cloud ALM tenant for each individual you wish to grant access to the dashboard results.

For more information SAP Readiness Check  and  Feature Scope Description 

3344480 - SAP Readiness Check Deployment Options 

2913617 - SAP Readiness Check for SAP S/4HANA 

Simplification Item Check

To learn more about how to perform simplification item checks and their relation to SAP Readiness Check, you can explore the following links:

https://blogs.sap.com/2018/03/26/sap-s4hana-simplification-item-check-how-to-do-it-right./

https://blogs.sap.com/2020/01/02/simplification-item-catalog-simplification-item-check-and-sap-readi...

2399707 - Simplification Item Check 

Roadmap Viewer

 
The purpose of Roadmap Viewer is to provide access to SAP Activate methodology implementation roadmaps. Implementation roadmaps offer a comprehensive view of your project teams' associated activities, deliverables, and tasks with accompanying accelerator assets in document and hyperlink format.
SAP Activate roadmaps are organized by logical categories or by solution and help you keep track of all your improvement and innovation deliverables during all your SAP projects.
Access all your enterprise project management resources and project phases for many SAP solutions in this easy-to-consume format.
In addition, upload a specific roadmap into SAP Solution Manager for project management. This presents a customized project plan in the form of a work breakdown structure, which you can use as a starting point for project delivery.
 
Use the Roadmap Viewer to familiarize yourself with the project steps required for the transition to SAP S/4HANA.

Cirlei_Guedes_1-1710505377271.png

For more information SAP Activate Roadmap Viewer 

SAP Signavio Process Insights, discovery edition

Cirlei_Guedes_5-1710510433509.png

The SAP Signavio Process Insights, discovery edition will provide tailor-made recommendations based on data extracted from your SAP ERP system. It will help business decision-makers in your company understand the value of moving the current SAP ERP to SAP S/4HANA and transform your processes.

Cirlei_Guedes_6-1710510766296.png

For more information SAP Signavio Process Insights, discovery edition 

 

Now let's talk about Finance, Conversion of Accounting

Considerations for the Project Set-Up Complete the analysis and effort estimation before converting your system. The conversion to SAP S/4HANA requires application consultants with in-depth FI, CO, and Asset Accounting knowledge to be involved in the preparation of the data migration before the installation.

While tasks, such as sizing and installation, can be planned and carried out by the project lead and administrator, also make sure you have application consultants available for the following tasks that have to be performed throughout the conversion: • Check of custom code and modifications • Implementation of SAP Notes Effects of Data Model Changes

To use Finance in SAP S/4HANA you have to migrate the existing user data from the General Ledger, Asset Accounting, Controlling and Material Ledger. The data migration is necessary because Finance in SAP S/ 4HANA rests on a uniform data model for all accounting areas. The comprehensive ACDOCA data table contains all line item documents. After the migration, all postings of the named applications are written into the ACDOCA table.

The following tables are replaced by views using the same technical names:

• The line item, totals tables and application index tables of the General Ledger (GLT0, BSIS, BSAS and FAGLFLEXA, FAGLFLEXT, FAGLBSIS, FAGLBSAS)

• The totals tables and application index tables of Accounts Receivable and Accounts Payable (KNC1, KNC3, LFC1, LFC3, BSID, BSIK, BSAD, BSAK)

• The line item and totals tables of Controlling (COEP for certain value types, COSP and COSS)

• The material ledger tables for parallel valuations (MLIT, MLPP, MLPPF, MLCR, MLCD, CKMI1, BSIM)

• The Asset Accounting tables (ANEK, ANEP, ANEA, ANLP, ANLC)

Replacing these tables with views using the same names ensures that all read accesses to the tables mentioned are retained.

Supported Conversion Paths and Procedures

If you are using one of the following products, you can convert your system to SAP S/4HANA:

• SAP ERP 6.0 or higher

• SAP S/4HANA Finance 1605

• SAP Simple Finance, on-premise edition 1503

• SAP Simple Finance add-on 1.0

The following options are supported:

Cirlei_Guedes_0-1710521420624.png

You can go from any enhancement package of SAP ERP directly to SAP S/4HANA. To reduce business downtime, you can choose to do a downtime-optimized conversion (see SAP Note 2293733 ) or you can apply the Near Zero Downtime method (see SAP Note 693168 ).

Minimized Downtime Service Portfolio

To achieve the minimal suitable technical downtime of a SAP S/4HANA conversion, different approaches need to be considered to identify the solution that best suits the customer-specific requirements. The Minimized Downtime Service usually is delivered by one of the following engineered consulting services.

  •  Exclusive Consulting Services (only delivered by SAP consulting)

Some advanced methodologies, best practices, direct development support and standard technologies are combined within the following exclusive project-based SAP consulting services.

  • Near-Zero Downtime Technology for SAP S/4HANA Conversion with Repeatable Delta Conversion

This is the flagship methodology of the whole MDS family. It contains the broadest set of possibilities to reach the ultimate goal of a SAP S/4HANA system with very limited downtime.

  • Near-Zero Downtime Technology for SAP S/4HANA Conversion

This methodology offers the possibility to perform an SAP S/4HANA conversion with limited downtime.

Advanced Consulting Services

Another offering to reduce technical downtime is to leverage expert consulting services based on standard technologies with downtime reduction capabilities and best practices for SAP S/4HANA conversions. With these specialized methodologies, it is possible to reduce the downtime to the minimal suitable level.

  • Downtime-Optimized Conversion for SAP S/4HANA

This methodology is highly specialized to perform SAP S/4HANA conversions which include a system upgrade or enhancement package update, database migration and SAP S/4HANA conversion with reduced downtime.

The figure below, Your Way to SAP S/4HANA System Conversion, shows some of the differences (in blue) between SAP ERP and SAP S/4HANA. It also shows how you can perform a system conversion to an SAP HANA database, SAP S/ 4HANA application, and SAP Fiori.

Cirlei_Guedes_0-1710525129497.png

Customers who want to change their current system into an SAP S/4HANA system (Database, NetWeaver, and Application transition) in one step can benefit from the following:

● Migration without re-implementation

● No disruption to existing business processes

● Re-evaluation of customization and existing process flows

There are tools available to help complete these activities.

Software Update Manager (SUM) and Database Migration Option (DMO) are used for rapid database migration.

The below figure, Key Deliverables per Phase, shows the key deliverables per phase.

Cirlei_Guedes_1-1710533865519.png

Please, get an outline of the project steps involved, and get an understanding of the high-level mandatory customizing changes that the conversion will bring to the system.

For the general introduction of all SAP S/4HANA solutions on-premise or cloud (upgrade guide, conversion guide, simplification list, and so on), see http://help.sap.com/s4hana.

741967 - How to plan and execute the financial data migration during conversion of SAP ERP solution ... 

Before you start to convert to SAP S/4HANA (on-premise) make sure that you only execute the steps that are necessary for the conversion.

In particular, you must not migrate or convert data twice while you execute the application-specific follow-on activities for Finance listed in SAP Note 2332030

Please follow the rules that are listed in the SAP Note  2450377 - Conversion of SAP S/4HANA Finance to SAP S/4HANA – Migration Steps for Finance

 

Technical Changes in Controlling

In SAP S/4 HANA the totals records for primary and secondary costs have been removed and the universal journal includes all actual cost postings, both primary and secondary.

  • This ensures for primary postings that there is a single source of truth, such that all general ledger items with an assignment to cost centers, orders, WBS elements, business processes, or CO-PA characteristics are treated as one data record which is enriched with the relevant profit center, functional area, segment, and so on. Since Financial Accounting and Controlling will always be in synch, the company code is checked during all postings to an account assignment in Controlling and it is no longer possible to remove the flag "CoCd Validation" in the controlling area.
  • For secondary postings, this ensures that all sender-receiver relationships that are triggered by allocations, settlement, and so on are captured in the universal journal along with the partner profit centers, functional areas, and so on that are affected by the allocation.

The former tables COEP, COSP, and COSS are replaced by views of the same name, so-called compatibility views, that aggregate the data in the universal journal on the fly following the old table structures.
CO standard transactions are adapted in a stepwise manner to access the new universal journal table (ACDOCA) directly instead of using compatibility views. The conversion process is ongoing.
From a business point of view, all classic transactions are still running - based on compatibility views or using direct access to ACDOCA.
The goal of the compatibility views is to provide a bridge to the new data model. Using these views may have a performance impact on existing reports and you are recommended to investigate whether the new Fiori reports meet your business needs.  
Customer coding still runs based on the compatibility view

Read more about it in the SAP Note 2270404 - S4TWL - Technical Changes in Controlling 

Reports for Before-After Comparison

To verify your posting data after the migration, document your posting data. You may use the following standard reports:
– Financial statements (program RFBILA00)
– Totals report for cost centers (transaction S_ALR_87013611)
– Order: Actual/Plan/Variance (transaction S_ALR_87012993)
– G/L account balance list (program RFSSLD00)
– General ledger line items list (program RFSOPO00)
– Compact document journal (program RFBELJ00)
– Asset history sheet (program RAGITT_ALV01)
– Depreciation run for planned depreciation (RAHAFA_ALV01)
– Vendor sales (program RFKUML00)
– Vendor open item list (program RFKEPL00)
– The customer sales (program RFDUML00)
– Customer open item list (program RFDEPL00)
– Customer recurring entry original documents (program RFDAUB00)
– Ledger comparison (transaction GCAC)
– Sales order selection (program RKKBSELL)

 

Conversion from CO-PA Cost-Based to Margin Analysis

 

The SAP S/4HANA on-premise edition allows for two different profitability analysis solutions:

  • Margin Analysis
    Profitability Analysis within the Universal Journal addressing the needs of internal and external accounting, supporting real-time derivation of reporting dimensions and embedded analytics. Designed for use in combination with event-based revenue recognition.
  • Costing-based CO-PA
    Groups revenues and costs according to value fields and applies costing-based valuation approaches. Data is recorded in a dedicated persistency apart from external accounting. Designed for use in combination with results analysis.

SAP recommends using Margin Analysis in SAP S/4HANA. Margin Analysis has been extended broadly over the past releases and we continue to conduct new developments in this area only. It is perfectly integrated into the overall concept of the Universal Journal and is therefore fully in line with our Financial Accounting development strategy. Margin Analysis is active if there is an activation flag for 'margin analysis' in the IMG procedure mentioned above.

In addition to Margin Analysis, SAP also offers Costing-based CO-PA. Before the conversion to SAP S/4HANA on-premise, SAP recommends that you verify whether Margin Analysis can already cover all requirements and costing-based CO-PA can remain de-activated.

If you currently work with costing-based CO-PA, you can continue to run both approaches in parallel, by making the appropriate settings per controlling area. The essential difference is that costing-based CO-PA is a key figure-based model, rather than an account-based model.

Business Value

The universal journal (ACDOCA) is the heart of Accounting and includes all Margin Analysis characteristics to allow multi-dimensional reporting by market segment. The universal journal includes columns for the standard characteristics and all additional characteristics included in an organization’s operating concern (up to sixty characteristics, including the fixed characteristics). If you have already configured an operating concern for Margin Analysis, columns will be created for each of the characteristics during migration.

The benefit of this approach is that all revenue and cost of goods sold postings are automatically assigned to the relevant characteristics at the time of posting and that allocations and settlements are made to the characteristics at period close. It is also possible to configure some expense postings such that the characteristics are derived automatically so that material expenses assigned to a WBS element (account assignment) are automatically assigned to the characteristics entered as settlement receivers for the WBS element. This automatic derivation of the characteristics can reduce the number of settlements and allocations to be performed at period close and provide real-time visibility into spending during the period. If you use event-based revenue recognition, the journal entries for the recognized revenue and/or recognized COGS will also be assigned to the characteristics so that you can report on the revenue adjustments without the need to settle. You will still need to settle if you work with results analysis for long-running projects and orders to move the calculated values to Margin Analysis at period close.

There are also no reconciliation issues between the general ledger and Margin Analysis. Be aware, however, that revenue is recognized at the time of invoicing and the cost of goods sold when the delivery is made. If there is a time gap between delivery and invoicíng, costs may be visible in Margin Analysis for which no revenue has yet been posted (matching principle). From SAP S/4HANA 2021, you can use event-based revenue recognition to recognize revenue with the outbound delivery or to delay the COGS posting until the contract is completed.

 

There is no direct migration from costing-based CO-PA to Margin Analysis.

The Required and Recommended Action(s) are: Analyze existing reporting requirements to understand how market segment reporting is handled today. Also includes the transfer of profitability information to other systems, including data warehouses and consolidation. During conversion, the system will create columns in the universal journal for all characteristics in the operating concern.
If costing-based CO-PA is currently used, analyze what workarounds are being used to reconcile the profit and loss statement with costing-based CO-PA to determine whether these will be required in the future. Check whether the functions available with Margin Analysis can already satisfy your reporting requirements or whether you will continue to need costing-based CO-PA for an interim period. If combined Profitability Analysis is currently used, check whether the functions available with Margin Analysis can already satisfy your requirements.
Existing reporting transactions, such as KE30 and KE24, will continue to work, but also investigate possible usage of the Fiori apps to display information by market segment, including additional currencies and data from the extension ledgers.


Creation of Profitability Segments and Account Determination for COGS

If you only used costing-based CO-PA but no Margin Analysis before the conversion you need to understand when a profitability segment is created in the sales process and how COGS are posted during the delivery. In Margin Analysis the billing and the delivery are recorded as separate documents and both journal entries are assigned to a profitability segment. This means a change to include the assignment to a profitability segment in the COGS posting and the need to change the account determination to select an account/cost element.

The profitability segment is always derived for the sales order item and referenced during the delivery. Since the delivery document is now assigned to a profitability segment, you will need to ensure that you are updating an account of type P (primary costs and revenues) rather than an account of type N (non-operating expenses). Check the account determination for transaction GBB (Offsetting Entry for Inventory Posting) and account modification constants VAX and VAY. COGS posted before the conversion are posted without a cost element (type N), but after the conversion with a cost element (type P). To avoid issues, assign an account of type N to account modification VAX and an account of type P to account modification VAY (Margin Analysis works with VAY as a default).
• If you only worked with costing-based CO-PA and did not use incoming sales orders (record type A) prior to the migration, you will have open sales order items and delivery documents with no assignment to a profitability segment, even though this is required once Margin Analysis is active and the system will issue a message that the assignment to a profitability segment is missing if you reschedule the sales order item or post a goods issue after the migration. You can use transaction KE4F to derive the missing profitability segments for a small number of sales order items. For larger volumes of data, run the transaction in parallel over multiple packets of different sales orders (see SAP Note 2225831).
• Where sales orders are partially delivered at the time of conversion, it is recommended to cancel the deliveries and create new ones as this will result in the profitability segment being selected with reference to the sales order during delivery. However, this solution is not practical where goods movements have already been posted with reference to the delivery. The COGS for these goods movements will not be visible in Margin Analysis.
• If you choose to use the same G/L account for account modification constants VAX and VAY, you should also cancel all deliveries posted before the conversion and create new ones to ensure that the assignment to the profitability segment is correct.

 

Margin Analysis

The term "margin analysis" replaced the term "account-based profitability analysis", which you may still find on some user interfaces or in some documentation.

With the margin analysis functions, cost and revenue information is always current and 100% reconciled with the income statement.

This ensures greater transparency and makes the information easy to use.

Transparency is achieved by means of journal entries, which represent the single source of truth for financial data. Profitability reporting is based on income statement items, allowing drill-downs on any characteristic, for example, the product group.

Be aware of the difference between income statement items with true account assignment to a profitability segment and items referred to as "attributed items":

  • Income statement items with true account assignment to a profitability segment are part of processes such as settlement, allocation, and top-down distribution.

  • Attributed items appear in reports only.

An income statement item has a true account assignment to a profitability segment in cases such as the following:

  • The item is already determined in a logistical document such as a sales order or billing document.

  • A manual account assignment is performed via the CO-PA account assignment screen, for example for manual FI postings.

  • For the G/L account referenced in the income statement item, automatic account assignment to a profitability segment has been defined in Customizing.

For income statement items without a true account assignment to a profitability segment (for example, items assigned to orders, WBS elements, or sales order items), an attributed profitability segment can be determined when the journal entry is created. This function can be activated in Customizing. Further information can be found in Profitability Characteristics in Journal Entries.

In both cases, the available data is enriched, for example by accessing CO-PA derivation, and the result is written to the income statement item based on certain restrictions. Details can be found in Profitability Characteristics in Journal Entries.

 

How to deactivate CO-PA - SAP ECC 

Purpose

To explain how to:

  1. Deactivate COPA
  2. Deactivate one of the forms of CO-PA, if both Account-based and costing-based CO-PA are active.

Overview

If you would like to deactivate CO-PA module completely or if you have Account-based and Costing-based CO-PA active and you would like to deactivate one of them due to the increasing size of the related tables.

How to deactivate CO-PA 

Step 1.

Execute transaction KEKE   

    -> Change activation status from 2, 3 or 4 (Component active for both types of Profitability Analysis) to 0 (Component not active) for the required controlling/operating concern.

Cirlei_Guedes_8-1712585507558.png

Note: It is recommended to only do this step initially, as you may experience problems/errors if you need to modify a document that has a PA segment assigned or which has a COPA document. If you need to switch COPA back on via KEKE, it would be simple to do so for the time period required to modify or reverse any document posted earlier to CO-PA.

Step 2.

In the customizing of CO area (transaction OKKP) under the "Activate components/control indicators" section, change Profit Analysis to 'component not active'.

Cirlei_Guedes_9-1712585849730.png

Step 3.

After 6-12 months, you can then decide whether you need the historical data in COPA for reporting or not. Based on that you can decide to archive the data or delete the operating concern. Please note that deleting the operating concern would completely delete the data for good.

 

How to deactivate one of the forms of CO-PA, if both Account-based and costing-based CO-PA are active

Step 1.

Execute transaction KEKE   

    -> Change activation status from 4 (Component active for both types of Profitability Analysis) to 2 (Component active for costing-based Profitability analysis) or 3(Component active for account-based Profitability analysis).

Cirlei_Guedes_11-1712586084267.png
     -> Save.

Note: It is recommended to only do this step initially, as you may experience problems/errors if you need to modify a document that has a PA segment assigned or which has a COPA document. If you need to switch COPA back on via KEKE, it would be simple to do so for the time period required to modify or reverse any document posted earlier to CO-PA.

Step 2.

Execute transaction KEA0

    -> Enter your operating concern

    -> edit data structure

      Cirlei_Guedes_12-1712586851414.png

    -> Uncheck the Account-based or costing-based as required

Cirlei_Guedes_13-1712586943716.png

    -> Save.

Step 3.

On transaction KEA0 (Environment tab), Regenerate/activate the operating concern.   

The status is green.

Cirlei_Guedes_14-1712587574464.png

Step 4.

Execute transaction OKKP

     -> In the view activate components/control indicators).   

     -> change to "Component active for costing-based profitability analysis" or "Component Active for Account-based Profitability analysis".    

Cirlei_Guedes_15-1712587625831.png

Note: Reposting existing documents (like invoices) could be a problem since at the time of posting there was an account-based CO-PA document. So at the time of reversal system will expect the same else will throw error KI144. This error message can be changed into an information or a warning message (see note 98262). This problem could also come for documents 'in process' i.e. if sales order and GI have been done with account-based CO-PA and at the time of billing it is inactive. The cost accounting document created with account-based CO-PA active is a different one than that with account-based turned off. If account-based isn't active the posting leaving CO-OM is put to a reconciliation object. If account-based is active the same posting will go to a profitability segment for account-based CO-PA. This 'trick' made the introduction of account-based CO-PA possible without creating extra tables. The reconciliation object is naturally on a higher aggregation level so that the number sum records in CO is smaller than with account-based CO-PA active.

If you get the error message KI235 after deactivating CO-PA then please refer to SAP note 2217322 - KI235 - Account requires an assignment to a CO object Logic

If you choose to deactivate the costing-based COPA in KEA0 and KEKE and regenerate the operating concern, the data posted in relevant COPA tables will not be deleted. However, note that if you do this you will lose all reporting capabilities of costing-based COPA. In other words, the data will be available in the database tables, however, you will not be able to access this in any CO-PA report/transaction. The costing-based data also will not be migrated to account-based. Also, some other problems may occur.
Transitioning to different types of CO-PA is not quite an easy task and should be carried out with great caution and tested thoroughly. Activation of certain CO-PA types is meant to be for a longer period of time, not switching on and off at times of "need".
If you want to retain the old Costing-based data for reporting purposes, although, you do not wish to continue using costing-based CO-PA assessment then please implement note 3007194

 

Frequently asked questions in COPA