
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
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) 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.
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.
SAP Readiness Check
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./
2399707 - Simplification Item Check
Roadmap Viewer
For more information SAP Activate Roadmap Viewer
SAP Signavio Process Insights, discovery edition
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.
For more information SAP Signavio Process Insights, discovery edition
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:
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.
Some advanced methodologies, best practices, direct development support and standard technologies are combined within the following exclusive project-based SAP consulting services.
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.
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.
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.
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.
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.
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
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.
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
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)
The SAP S/4HANA on-premise edition allows for two different profitability analysis solutions:
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.
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.
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.
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.
To explain how to:
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.
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.
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'.
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.
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).
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
-> Uncheck the Account-based or costing-based as required
-> Save.
Step 3.
On transaction KEA0 (Environment tab), Regenerate/activate the operating concern.
The status is green.
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".
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
This blog is based on SAP Help Portal and SAP ONE Support Portal
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
4 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |