This blog is intended for project members responsible for Doc Conversion functionality in S4 Hana Finance. It explains the Standard options for Doc Conversion functionality and Data migration. Consultants who have Standard conversion Experience can understand the functionality very easily. This blog is based on the real time Project experience which gone live recently.

What Is DOC:

The approach is based on the idea to move downtime activities (like data conversion from old to new data model) and database migration (in case of source system on non-HANA database) to uptime processing of SUM. For a standard conversion, the FIN data conversion has to be executed after the SUM has finished, by respective IMG activities (e.g. FIN customizing, FIN data migration). The downtime-optimized approach will even move the FIN data migration (partly) into the SUM uptime processing.

Data conversion is moved to uptime processing. If the source system is not yet on SAP HANA database, the database migration of the affected tables is then done in uptime as well, prior to this data conversion.

Overview:

1. The approach can be used for a system conversion from SAP ERP 6.0 to SAP S/4HANA.
2. It reduces the technical downtime by executing data conversion and migration (if required) in uptime.
3. Approach is possible for source systems on SAP HANA or on non – SAP HANA database.
4. Approach will require additional effort for project planning, impact analysis, and additional test runs.

Planning for Downtime Optimized Conversion 

During DOC conversion we must follow below restrictions or Freeze

1. Stack Freeze: No changes to Stack on source ECC​, means we are not going to upgrade /Update any stack in source system .
2. FI Customizing Freeze: Customizing Freeze initiates a phase during which Customizing changes as well as many Finance and Controlling activities are no longer possible. The Customizing Freeze starts once the production system is copied to the sandbox to prepare the final Finance Customizing transport.

No (customizing) changes allowed; For details check downtime optimized Conversion Guide attached to Note 2443938. A “standard” SAP S/4HANA conversion is a prerequisite, this freeze is between standard and Doc to keep consistency​.

Please Find the below link where you can find the customization restriction for finance.

https://help.sap.com/docs/SLTOOLSET/a882504353b1407da13a271cf9dfcaf5/1f04d85a0fb7420c954d2365634ec88…

3. Hard Freeze : Reoccurs during every downtime-optimized Conversion iteration.

Following are list of transactions that are locked by SUM during the short FI-AA freeze:​

• KA12 – Archive cost centers (plan)​
• KA16 – Archive cost centers (line items)​
• AS91 – Legacy data transfer​
• AJRW – FI-AA Balance Carryforward​
• AJAB – FI-AA Year End Close
• SARA – Data Archiving Administration​
  •  

Duration ​

Starts with phase “lock workbench” in SUM preprocessing and ends after the completion of the creation of the clone for downtime simulation (valid for Load Verification and Dress Rehearsal) or the completion of the Productive Cutover (valid for Go Live)

4.Recording Freeze: 

• Avoid Full Retirements or Full Retiring Transfers (transactions which deactivate assets w depreciation). Do not post full retirements or full retiring transfers starting the first day of the open period when triggers are activated.
• Changes in Material Ledger are not allowed​. Activation or deactivation of Material Ledger Actual Costing for one or more plants​. Use of transaction CKMSTART (Production Startup of Material Ledger). ​Initialization of periods for material master records (MMPI)​​

 Active Material Ledger Actual Costing before SAP S/4HANA conversion​. The following must be completed in the source system before executing the final delta migration run ​

• Complete all Material Ledger costing runs for actual costing (transaction CKMLCP) ​
• Complete all alternative valuation runs (transaction CKMLCPAVR)​
• After the system conversion, no changes to costing runs and alternative valuation runs created before the system conversion are possible​.

The following changes in Inventory Management are not allowed​

• Archiving for materials (archiving object MM_MATBEL)​
• Archiving for material documents (archiving object MM_MATBEL)​
• Execute MM-IM inconsistency check reports (note 1227770) to correct MM-IM data
• ​Corrections are recorded in table MMINKON_UP

5.FI-AA Closing Freeze: Before the beginning of the creation of the triggers and ends after the successful activation of the trigger recording

•  Avoid FI-AA <-> FI-GL mismatches during the FI-AA data conversion​
• Execute consistent FI-AA closing activities (RAPOST2000, RAPERB2000, AFAR, …)​
• Avoid any intermediate FI-AA postings to ensure consistent data for initial FI data conversion​.

Transports to be considered: Any functional transports created in ECC as part of Pre-conversion before SUM tool (By default SUM will consider these transports as part of CTI) and Post Conversion Transports before the Data Migration will be part of DOC cycle.

Below Configuration nodes for which TR created for Standard conversion are part of CTI Buffer for Doc conversion.

• Check Customizing Settings Prior to Migration
• Set Number of Jobs for Activities in Mass Data Framework
• Preparations and Migration of Customizing for General Ledger
• Preparations and Migration of Customizing for Accrual Engine
• Preparations and Migration of Customizing for Asset Accounting
• Preparations and Migration of Customizing for Controlling
• Preparations and Migration of Customizing for Material Ledger
• Preparations for Migration of House Bank Accounts
• Preparations for Migration of Financial Documents to Trade Finance
• Preparatory Activities and Migration of Customizing for Credit Management
• Transport Accepted Error Messages

Note :

1. Transport created for the node Activities after Migration is not part of CTI Buffer.
2. Number of jobs mentioned in the node Set Number of Jobs for Activities in Mass Data Framework will be the same jobs in Doc conversion. You can’t change the no of Jobs in Doc Cycle. please make sure you maintained the correct number of jobs and capture in the transport.
3. Make sure you capture the activation of new asset accounting mentioned in the node Activate Asset Accounting (New)
4. Make sure you capture the accepted errors during Data migration into a transport mentioned in node Transport Accepted Error Messages
5. During Doc Conversion if you created any new plant for which we have not captured the TR for ML activation, please use transaction code UPG_SFIN_CUST before start of data migration.

Data Migration:

• Data migration divided into two parts. Historical Data which is part of Standard cycle and Delta Data after the trigger. During Doc Cycle Historical data will automatically Update during Up-time and Delta data will update during Down-time.
• The Errors which were accepted during data migration in Standard cycle which is captured in the transport will automatically accept in Doc Conversion cycle.
• If any new errors come up during Doc Conversion cycle must accepted manually with the help of Doc Basis consultant.
• Functional consultant will take help from the Basis team to accept the error message because we need to login DDIC users in the shadow system. generally, we get one DDIC user id for the conversion.

Credit Management Migration:

• We must perform Credit Management Migration similar as standard conversion in the Doc Cycle.

Complete Migration:

• We must Set Migration to Completed similar as standard conversion in the Doc Cycle after the credit management migration.

Activities after Migration:

• We must perform all activities mentioned in the node Activities after Migration similar as standard conversion.

Remove Freeze Period:

• Once all activities completed and after getting confirmation from the Basis team, Business can create transports and send to other systems and also business can change the master data .

Relevant Notes:

• Guide for downtime-optimized Conversion with SUM 2.0 SP 17
• SAP Note 3301507 on downtime-optimized Conversion with SUM 2.0 SP 17
• SAP Note 2879083 Downtime-optimized Procedures using downtime-optimized Conversion: additional information on data replication
• SAP Note 2402270 Export of Table Statistics for SUM Impact Analysis
• SAP Note 2481983 SUM Impact Analysis for downtime-optimized DMO / downtime-optimized Conversion

Note :

• For standard Conversion, we crate transport requests for Post conversion activity in the Dev system and these TRs are moved to Production but for Doc conversion we have to create TRs for Every cycle ie Development, quality and pre-Production.
• Transport Requests created in standard Conversion cycle will be the part of CTI buffer for Doc Conversion
• For every Doc Conversion cycle, standard Conversion is mandatory.
• If we missed any Freeze mentioned above, we have to start from the scratch for every cycle.
• Doc Conversion is best for the customer which have more transaction data and they need less down time.
• Load Verification Cycle is required for Real production load and recorded data changes just before Production cycle.
• Make sure month end, quarter end and Year end activities are completed before starting Doc Cycles

Conclusion:

This blog is very useful for all the customers and Consultants who are planning to implement Doc in the S4 system .it Covers the Consideration of Understand the supported various business scenarios.