S4F03 Col11 Conversion of Accounting to SAP S/4HANA

S4F03
Conversion of Accounting to SAP
S/4HANA
.
.
PARTICIPANT HANDBOOK
INSTRUCTOR-LED TRAINING
.
Course Version: 11
Course Duration: 2 Day(s)
e-book Duration: 4 Hours 15 Minutes
Material Number: 50148284

SAP Copyrights and Trademarks
© 2018 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. Please see http:/
/global12.sap.com/corporate-en/legal/copyright/index.epx for additional
trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software
components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only,
without representation or warranty of any kind, and SAP SE or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate
company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business
outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’
strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any
reason without notice. The information in this document is not a commitment, promise, or legal
obligation to deliver any material, code, or functionality. All forward-looking statements are subject to
various risks and uncertainties that could cause actual results to differ materially from expectations.
Readers are cautioned not to place undue reliance on these forward-looking statements, which speak
only as of their dates, and they should not be relied upon in making purchasing decisions.
© Copyright. All rights reserved. iii

Typographic Conventions
American English is the standard used in this handbook.
The following typographic conventions are also used.
This information is displayed in the instructor’s presentation
Demonstration
Procedure
Warning or Caution
Hint
Related or Additional Information
Facilitated Discussion
User interface control Example text
Window title Example text
© Copyright. All rights reserved. iv

Contents
vi Course Overview
1 Unit 1: Journey to SAP S/4HANA with the Activate Methodology
2 Lesson: Introducing SAP S/4HANA
8 Lesson: Outlining the Conversion Journey
15 Unit 2: Preparation for a Conversion to SAP S/4HANA
16 Lesson: Explaining the Conversion Process
24 Lesson: Analyzing the Conversion Process per System Starting
Point
36 Lesson: Preparing for Conversion to SAP S/4HANA
45 Lesson: Preparing for Business Partner Adoption (Customer Vendor
Integration)
57 Lesson: Describing the SAP S/4HANA Installation Phase
63 Unit 3: Customizing Financials in SAP S/4HANA
64 Lesson: Conﬁguring General Ledger Accounting
80 Lesson: Conﬁguring new Asset Accounting
89 Lesson: Migrating to new Asset Accounting
95 Lesson: Customizing Controlling for Account Based CO-PA
98 Lesson: Preparing for Migration Material Ledger
101 Lesson: Preparing for Migration of House Bank Accounts
103 Lesson: Preparing for Migration of Credit Management/Trade
Finance
111 Unit 4: Conversion to SAP S/4HANA
112 Lesson: Migrating to the Universal Journal
129 Lesson: Finalizing Migration and Post Processing Business Partner
133 Lesson: Performing Post Migration Activities
142 Unit 5: Additional Topics for Migration
143 Lesson: Explaining Business Downtime Reduction with Near Zero
Downtime (NZDT)
148 Lesson: Explaining Conversion Results
153 Lesson: Using new Asset Accounting
© Copyright. All rights reserved. v

Course Overview
TARGET AUDIENCE
This course is intended for the following audiences:
● Project Manager
● Application Consultant
● Support Consultant
© Copyright. All rights reserved. vi

UNIT 1 Journey to SAP S/
4HANA with the
Activate Methodology
Lesson 1
Introducing SAP S/4HANA 2
Lesson 2
Outlining the Conversion Journey 8
UNIT OBJECTIVES
● Introduce SAP S/4HANA
● Get an Overview of the Conversion to SAP S/4HANA
© Copyright. All rights reserved. 1

Unit 1
Lesson 1
Introducing SAP S/4HANA
LESSON OBJECTIVES
After completing this lesson, you will be able to:
SAP HANA and SAP S/4HANA
Your business processes a large volume of data. You want to extract information from this
data to create meaningful reports. You want to understand how SAP HANA can help you with
your data storage and analysis needs, and future proof your organization in preparation for
the expansion of the Internet of Things.
You also want to update your current system landscape to a next generation solution, and you
are interested in what the new SAP S/4HANA suite can oﬀer and the deployment options that
are available.
Figure 1: Trends of a Digital World
By the end of 2009, 5% of the world's population owned smartphones. Four years later that
ﬁgure jumped to 22%. Currently, 1.7 billion people are on social networks. Over the next three
years that audience will surpass 2.55 billion. By 2020, 5 billion people will be online, while 50
billion devices will be connected to the Internet of Things, creating a digital network of virtually
everything. And cloud computing - a $41 billion business in 2011 - will grow to a $241 billion
business in that same time frame. The exponential growth of mobile devices, social media,
cloud technologies, and the amazing amounts of data that they generate have transformed

the way we live and work. In fact, 61% of companies report that most of their people use
smart devices for everything from e-mail to project management to content creation.
While all of these advancements have improved our lives and have provided us with greater
opportunities for innovation than ever before, they have also presented a new challenge:
unprecedented and crippling complexity in the data created from online activities. Data from
online purchases, online banking, and online applications might be of interest to the
organizations that own it, but they can only integrate it with their core business processes if
they run SAP S/4HANA.
Figure 2: Trade-Off Broad and Deep Analysis or Speedy and Simple Reporting
With existing technologies, optimizing across the five dimensions shown in the figure, Trade-
Off Broad and Deep or Speedy and Simple Reporting, is not possible. You have to decide
between a broad and deep analysis of your business warehouse systems or to create high
speed but simple reports from your data.
In both scenarios, real time updates are difficult, almost impossible to design. In a data
warehouse environment, updates occur overnight in batches.
Advances in Technology
In the last few years, significant advances in technology mean that application developers can
build smarter and more powerful applications, for example:
● Multi-core processors enable parallelism of tasks meaning more throughput of data and
faster processing. This enables real-time responses.
● Larger memory can hold an entire organization's database. This means that we can
eliminate the mechanical spinning disk and the latency it brings.
● Advances in the design of on-board cache mean that data can pass between memory and
CPU cores rapidly and without bottlenecks.
● We can now easily slot more servers into our landscape to add more processing power or
memory in order to scale to any size.
Lesson: Introducing SAP S/4HANA

● Cloud computing is now a compelling deployment option for our customers who do not
want to take on the complexity and cost of installing and maintaining IT landscapes.
Virtualizing machines lowers the costs of running enterprise-wide applications. Public
cloud services based on subscription models provide convenient access to the latest
solutions at a reduced cost.
SAP developers have worked closely with leading hardware partners who shared with them
the product blueprints of their new CPU architectures. This meant that the SAP developers
could re-write their business application software to fully harness these advances.
Figure 3: The Vision of SAP HANA
For more than 20 years, organizations have been using specialist software, usually with
additional hardware, to extract, transform, and load (ETL) data from transactional systems to
dedicated reporting systems. Based on the technology available at the time, this was the
optimal way to provide an overall view of business data with good response times (especially
when you add accelerator software/hardware).
Online transactional processing (OLTP) was separated from online analytic processing
(OLAP). The reason for this lies in the database design of OLTP and OLAP. Quite simply, a
database model was either built for OLTP optimization or OLAP optimization, but not both.
This brought with it complexity, redundancy, and latency. Business ﬁgures today usually only
become available the next day for analysis once the data has been extracted and loaded to a
reporting system.
Databases that support SAP S/4HANA can handle both OLTP and OLAP processing from a
single data model and therefore, we do not need to move transactional data to a separate
system. This means transactional and analytical applications run oﬀ the same tables, and
data is available in real-time at every level of detail.
Unit 1: Journey to SAP S/4HANA with the Activate Methodology

Figure 4: Remove Complexity with SAP S/4HANA
Traditional applications were built on a hierarchical data model. Detailed data was
summarized into higher level layers of aggregates to help system performance. On top of
aggregates, we built more aggregates and special versions of the database tables to support
special applications. So as well as storing the extra copies of data, we also had to build
application code to maintain extra tables and keep them up to date. Database indexes
improve access speed because they are based on common access paths to data. But they
must be constantly dropped and rebuilt each time the tables are updated. More code is
required to manage this process.
The traditional data model is complex, and a complex data model causes the application code
to be complex. It has been found that up to 70% of application code is built specifically for the
performance of an application, and adds no value to the core business function. With a
complex data model and complex code, integration with other applications and
enhancements are difficult.
Using the raw power of SAP HANA, we can aggregate in sub seconds from any line item table.
We do not need pre-built aggregates. SAP HANA can generate any view of the data at run-
time, all from the same source tables. SAP HANA organizes data using column stores, which
means indexes are usually not needed (they can still be created but usually offer only minor
improvement). So in addition to losing the aggregates and indexes from the database, we can
remove huge amounts of application code that deal with aggregates and indexes. We are left
with a simplified core data model and simplified application code. Now it is much easier to
enhance the applications and integrate additional functions.

Figure 5: SAP S/4HANA Core and Lines of Business Solutions
SAP S/4HANA is not a single product but covers many applications. Customers can start with
the basic components and add to them later. S/4HANA Enterprise Management is a great
place to start. This is known as the simpliﬁed core and can be considered as the replacement
for SAP ERP. Here, we ﬁnd support for all core business processes, such as quotation to cash,
procure to pay, and so on. For many customers, this is where their S/4HANA adoption begins.
S/4HANA Enterprise Management can be easily integrated with SAP S/4HANA Lines of
Business (LoB) solutions. These options can be added at any time and provide best-in-class
lines of business solutions and connections to SAP Business Networks. Customers can
choose the LoB solutions that suit their businesses.
In the past, we had multiple add-on applications surrounding the core with overlapping
models and much redundancy (for example, SAP CRM and SAP SRM surrounded the core
ECC). Overlaps and redundancy have been completely removed with SAP S/4HANA.
SAP S/4HANA is built natively and optimally to run only on the SAP HANA platform.

SAP S/4HANA Delivers Functional Completeness
Figure 6: Functional Completeness of the Solution
SAP provides a fully integrated platform, based on the latest technology trends, to allow
finance to lead the transformation to digital business. The figure, Functional Completeness of
the Solution, shows the functional completeness the SAP S/4HANA offers. All aspects of
financial requirements across all roles are supported in granular solution areas.
Related SAP Links
The following table shows examples of relevant SAP links.
Table 1: Related SAP Links
Where What Link
sap.com SAP HANA http:/
/hana.sap.com/
SAP Service Marketplace Hybrid Scenarios http:/
/service.sap.com/
public/hybrid
sap.com SAP S/4HANA Help Portal https:/
/help.sap.com/
s4hana
sap.com SAP S/4HANA LoB Finance http:/
/go.sap.com/
solution/lob/finance/
s4hana-finance-erp.html
LESSON SUMMARY
You should now be able to:

Unit 1
Lesson 2
Outlining the Conversion Journey
LESSON OBJECTIVES
Conversion of an ERP System to S/4HANA On-Premise Edition
The Conversion Scenario
A large holding company, JOLLY-G, has a number of its businesses running on different
versions of SAP products. They have learned of the benefits of SAP S/4HANA and SAP
Activate was successful. They want one of the businesses, MERRY-C, that is currently running
on SAP ERP, to convert to the On-Premise SAP S/4HANA system.
The scenario in this unit explains the conversion from SAP ERP to SAP S/4HANA.
Figure 7: Your Way to SAP S/4HANA System Conversion
The figure, 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 to 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 for 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.
Figure 8: SAP S/4HANA On-Premise System Conversion: Work Streams
The figure, SAP S/4HANA On-Premise System Conversion: Work Streams, provides an
overall view of the deliverables that are included in a system conversion to SAP S/4HANA.
Note:
The relative positions of the deliverables within a phase/work stream in the figure,
SAP S/4HANA On-Premise System Conversion: Work Streams, does not imply
dependencies.
In the system conversion/transition, we are looking at adopting some of the capabilities of
SAP S/4HANA, not necessarily transitioning the current system functionality.
Table and configuration adjustments are needed. The second big area to address is custom
code. This is assessed, cleaned up, and adjusted.
Other important aspects are data volume strategy definition, data clean up, data archiving
and data aging configuration within the system. SAP HANA is an in-memory database, so it
Lesson: Outlining the Conversion Journey

requires a lot of memory. Therefore, a good strategy is required for managing the data
volumes and moving data between in-memory and storage. Input to the strategy includes the
use of the data (analysis or use in the application), the volume and the state of the existing
transactional and master data.
It is necessary to ensure the right skillset of the people involved in the workstreams for an
SAP S/4HANA conversion project:
● - a project manager
● - a technical basis team
● - application experts for finance, controlling and asset accounting. In certain projects
credit management is also a required skill.
● - logistics application experts with expertise in Customer-Vendor Integration and Business
Partner.
● - developers.
● - a UX lead for SAP Fiori.
● - an analytics lead.
Figure 9: Key Deliverables per Phase
The figure, Key Deliverables per Phase, shows the key deliverables per phase.
Answering Questions about a Conversion
As a result of following the SAP Activate methodology for conversion projects, the following
questions need to be addressed for the specific circumstances:
● How do I get an ideal SAP S/4HANA strategy that benefits my company? What is the ideal
roadmap towards implementing SAP S/4HANA?
● What are application quick wins I can implement quickly as part of the conversion process?

● How do I identify custom code that needs to be adjusted to SAP S/4HANA?
● Will the SAP database seamlessly ﬁt into the existing infrastructure?
● What does it mean for the operations team?
● What is the overall project duration and what are the related eﬀorts?
● What are the potential risks and how can they be managed?
Scenario
Merry-C has completed the Advice and Plan workshops with SAP. As a result, it has
formulated a high-level plan and has agreed a business case for the conversion of its SAP ERP
to an on-premise SAP S/4HANA system. Merry-C is now ready to prepare its conversion
project.
The pre-project Advice and Plan workshops with SAP show how valuable a system conversion
is, and how you can implement new functionality as part of this conversion.
LESSON SUMMARY
Lesson: Outlining the Conversion Journey

Unit 1
Learning Assessment
1. SAP HANA utilizes which new technology?
Choose the correct answer.
X A Wireless networking
X B Solid State drives
X C Multi-core CPUs
X D Large Read Only Memory
2. SAP HANA takes advantage of optimized aggregate tables to oﬀer OLAP and OLTP from a
common platform.
Determine whether this statement is true or false.
X True
X False
3. Which products are Line of Business solutions that can easily be integrated with the SAP
S/4HANA digital core?
Choose the correct answers.
X A SAP Success Factors
X B SAP Cash Management
X C SAP Accounting & Financial Close
X D SAP Ariba
4. During a system conversion project, you should only convert the existing system as is and
not concentrate on redesigning processes and removing redundant custom code.
X True
X False

Unit 1
Learning Assessment - Answers
1. SAP HANA utilizes which new technology?
X A Wireless networking
X B Solid State drives
X C Multi-core CPUs
X D Large Read Only Memory
Correct! Of the options provided, multi-core CPUs enable the SAP HANA technology to
function and utilize in-memory data.
2. SAP HANA takes advantage of optimized aggregate tables to oﬀer OLAP and OLTP from a
common platform.
X True
X False
Correct! The SAP HANA technology allows the use of line-item tables directly avoiding
inﬂexible aggregate tables.
3. Which products are Line of Business solutions that can easily be integrated with the SAP
S/4HANA digital core?
X A SAP Success Factors
X B SAP Cash Management
X C SAP Accounting & Financial Close
X D SAP Ariba
Correct! SAP Cash Management and SAP Accounting & Financial Close are both part of
the SAP S/4HANA core and not separate solutions that require integration.

4. During a system conversion project, you should only convert the existing system as is and
not concentrate on redesigning processes and removing redundant custom code.
X True
X False
Correct! Though the conversion should “work” on a technical level, adoption of SAP S/
4HANA is an opportunity to both clean-up your system and redesign processes.
Unit 1: Learning Assessment - Answers

UNIT 2 Preparation for a
Conversion to SAP S/
4HANA
Lesson 1
Explaining the Conversion Process 16
Lesson 2
Analyzing the Conversion Process per System Starting Point 24
Lesson 3
Preparing for Conversion to SAP S/4HANA 36
Lesson 4
Preparing for Business Partner Adoption (Customer Vendor Integration) 45
Lesson 5
Describing the SAP S/4HANA Installation Phase 57
UNIT OBJECTIVES
● Describe the migration steps to SAP S/4HANA on a high level
● Understand the possible starting points for migration
● Explain the scope of changes in the General Ledger
● Understand the preparation steps for a conversion project
● Prepare Customer-Vendor Integration
● Describe the SAP S/4HANA installation phase

Unit 2
Lesson 1
Explaining the Conversion Process
LESSON OBJECTIVES
The Conversion Process
Carry out the Following Steps:
1. Plan and prepare for the conversion to SAP S/4HANA.
2. 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.
Figure 10: Suﬃx “New” Removed for FI, G/L and AA in SAP S/4HANA 1709

Figure 11: SAP S/4HANA and SAP S/4HANA Finance
The decision to go for SAP S/4HANA Finance and S/4HANA in a second step should be based
on the business benefits, but it is not a mandatory prerequisite for any system conversion. A
reason may be that the customer specific prerequisites in logistics are not fulfilled yet.
For the general introduction of all S/4HANA solutions on premise or cloud (upgrade guide,
conversion guide, simplification list, and so on), see http:/
/help.sap.com/s4hana
Figure 12: SAP Help Portal SAP S/4HANA Overview
Lesson: Explaining the Conversion Process

Figure 13: Procedure Conversion to SAP S/4HANA
The procedure to convert to the SAP S/4HANA, from the perspective of accounting, has the
following five basic stages:
1. Preparation phase:
● It is necessary to check all of the requirements before starting a conversion to S/
4HANA. It is recommended to use the Simplification List as of SAP S/4HANA 1709 via
the SAP Readiness Check for SAP S/4HANA (note 2290622). However, the
Simplification List as a PDF can be used directly as well, which shows all possibilities
and not only the relevant ones.
A second tool supporting the conversion process is the Simplification Item-Check (SI
Check). You can check the SAP note 2245333 for details. The Roadmap Viewer can be
used for the planning. In addition, system requirements must be checked. The custom
code conversion tool (not mandatory but highly recommended) checks your custom
code against a list of simplifications developed for SAP S/4HANA. Besides this the use
of the Maintenance Planner must be prepared (mandatory).
2. Installation phase:
● The system administration installs SAP S/4HANA using the Software Update Manager
(SUM).
● The system backups are taken for the totals and index tables, and the new SAP HANA
view tables are created.
3. Customizing phase:
● Customize general ledger accounting, asset accounting, management accounting
(profitability analysis and the material ledger), customize house bank accounts, and
depending on the initial situation trade finance respectively credit management.
4. Data conversion phase:
Unit 2: Preparation for a Conversion to SAP S/4HANA

● The actual conversion of the financial data occurs. Update the universal journal for
G/L, AP/AR, CO, FI-AA, material ledger, and credit management/trade finance.
● Migrate house bank accounts.
● Perform reconciliation and all required checks for the data before and after the
conversion.
5. Post-processing phase:
● Update the due dates and the offsetting account in documents.
● Transfer the backup tables to the historical section of the database. Conversion means
upgrading an ERP system to S/4HANA or S/4HANA Finance.
For starting with a new installation with S/4HANA, see note 2185245 New SAP S/4HANA
installations: Conversion of customizing settings in financials required?
Caution:
Always follow the correct sequence for conversion activities.
Figure 14: Productive Conversion Experience from an SAP S/4HANA Project
The figure, Productive Conversion Experience from an SAP S/4HANA Project, shows the
sequence of steps and timing of a conversion project from the financial consultant
perspective.

Figure 15: Overview: Implementation Guide (SPRO)
The authorization object FINS_MIG is required to execute SAP S/4HANA conversion
activities.
High Level System View of Conversion Sequence
Figure 16: Typical Conversion Cycles in a Project
1. Start a conversion including customizing without transports in a separate copy of the
productive environment. This provides an overview of problems and duration.
2. Start the conversion of the development environment. This is the system mostly without
transaction data.
3. Copy the productive environment to the test environment and import customizing
settings from the development environment.
4. Migrate the test environment and correct errors directly in the productive environment.
5. Repeat steps 3 and 4 and test new functionality after a second conversion.
6. Migrate the productive environment after 2 3 successful test conversions.

The tests in the sandbox don't affect the other servers or clients.
The final test conversion cycle is known as the dress rehearsal. This typically takes about 5
conversion cycles (sometimes one less and sometimes more).
Starting with the conversion from the development system, customizing is only transported
and imported including activation of the new asset accounting.
For emergency transports, another transport track is sometimes created.
Figure 17: Project Considerations for an SAP S/4HANA Conversion
Note:
SAP S/4HANA installation level is the system, not the client. To remove client 001
and 066, see note 1749142.
The schedule for the very first conversion is usually too short (first test cycle)
especially after implementing software using Software Update Manager and
before the functional conversion (S4F03). A specific period should be scheduled
to allow for responses to technical problems (recommendation is 2-3 weeks). The
same applies to the time after functional conversion to a first testing by business
department (recommendation is also 2-3 weeks).

Figure 18: Sequence in Test and Productive Environment
What does "Company Code Speciﬁc Conversion to S/4HANA " mean?
● It is a separate service and not part of this course. This course shows a standard
conversion from ERP to S/4HANA.
● Main objective of this scenario is to support conversion of data from an ECC system to an
already productive S/4HANA system.
● Conversion to S/4HANA will only happen for participating company codes whereas
existing data in an SAP S/4HANA system will remain untouched.
● It can only be used with the SAP LT OBT(Object Based Transformation) tool, which is
shipped with SAP Landscape Transformation software.
● Execution of scenario without using SAP LT OBT will cause inconsistencies in the system.
● For more information, see note 2522155.

Key Takeaway Points
Figure 19: Common Conversion Complication Factors
● Conversion can be started at any point after all prerequisites have been met.
● Customer vendor integration is necessary for SAP Business Partner.
● SAP S/4HANA is installed at the system level.
● The schedule for the very first conversion is usually too short (first test cycle). Especially
after implementing software by Software Update Manager and before the functional
conversion (documented here in the course), a specific period should be scheduled to be
able to respond to technical problems (recommendation is 2-3 weeks). The same applies
to the time after functional conversion to a first testing by business department
(recommendation is 2-3 weeks as well).If you use the classic ledger, you can migrate
directly to S/4HANA without first migrating to the new GL in a separate project.
● A system conversion (Brownfield approach) can be 1-step approach (database conversion
to HANA and conversion in the same project) or a 2-step approach (database conversion
to HANA and conversion in a second project) Simplification (simplification list) is not only
simplification but change.
LESSON SUMMARY

Unit 2
Lesson 2
Analyzing the Conversion Process per System
Starting Point
LESSON OBJECTIVES
Conversion Starting Points
You currently run a system on classic G/L, new G/L, or SAP S/4HANA Finance and want to
upgrade to use the functionality of the latest version of SAP S/4HANA. You want to know if
your current system configuration meets the prerequisites and what kind of changes you will
need to prepare for.
Figure 20: Migrating to SAP S/4HANA
Greenfield Implementation: New SAP customers starting with SAP S/4HANA take over their
legacy data using other tools (such as the SAP Conversion Cockpit). SAP S/4HANA
conversion tools only work for existing customers and systems. Depending on the active
applications in the source system, different preparation steps are relevant. The Greenfield
approach (new implementation) is always an option and should be considered.
Brownfield Implementation: If the system is in relatively good condition (for example, highly
integrated, using a unified chart of accounts, and so on.), the trend is more likely to convert

the system (Brownfield approach). If the existing structures are to be rebuilt, the Greenfield
approach could be a better solution. For heterogeneous large system landscapes, SAP
Central Finance is third option (course S4F04 SAP Central Finance). With the Greenfield
approach, there is a risk that the old structures will be rebuilt almost exactly as they were. The
Greenfield approach takes longer. Often, the cost and effort of Greenfield is twice or three
times as high as Brownfield. On the other hand, it is possible to completely rebuild your
system according to new current requirements.
Figure 21: Conversion from Classic G/L and from New G/L
You can convert either directly from classic G/L to SAP S/4HANA or first migrate from
classic G/L to new G/L and from there to SAP S/4HANA. Keep in mind this is a complete
system conversion and not only an upgrade.
Lesson: Analyzing the Conversion Process per System Starting Point

Note:
As of January 2019, there is no SAP service for a subsequent switch from
accounts approach to ledger approach. However, it is planned. Currently, the only
way to convert from the accounts approach in the classic GL to the ledger
approach in S/4HANA is to migrate to the new general ledger as a separate
project before converting to S/4HANA (course AC212 Conversion to New General
Ledger Accounting). In all other cases, a system can be converted directly from
the classic GL to S/4HANA and optimized later. The following list outlines the
different transition scenarios if a customer wants to go from an SAP ECC System
to SAP S/4HANA:
● System conversion: Customers who want to change their current SAP system
to SAP S/4 HANA.
● New implementation: New implementation of SAP S/4HANA - for example,
customer migrating from a legacy system.
● Landscape transformation: This is for Customers who want to consolidate their
landscape or carve out selected entities (like a company code) or processes
into an SAP S/4HANA system.
● Central Finance: Scenario for heterogeneous large system landscapes. A S/
4HANA system acts as central finance system.
High Level System Prerequisites for Conversion
It is required for the system you are converting to:
● Use a unicode system (Perform a combined upgrade and Unicode conversion first if the
system is still non-Unicode before converting to S/4HANA).
● Use an ABAP-only system
● Use SAP NetWeaver 7.52
● Use SAP ERP with Enhancement Package 0 or higher or SAP Business Suite powered by
SAP HANA or a SAP S/4HANA Finance solution (see note 2526924)
● SAP Business Suite on HANA systems that are on SAP HANA 1 needs to upgrade first to
SAP HANA 2
The transition to SAP S/4HANA does not require the source system to be already on SAP
HANA DB.
If an ERP 6.0 system is on a lower EhP level than 8 it is not necessary to go to EhP 8 in a
separate project before. A one-step conversion is also possible (new EhP level and conversion
at the same time).

Figure 22: Subsequent Implementation of Accounting Principle
Note:
If a system that uses the accounts solution is migrated, it is currently not
possible to subsequently introduce other ledgers.
Figure 23: Subsequent Implementation of Document Splitting

Figure 24: Customizing and Data Transfer
Figure 25: Overview of Steps for Data Transfer

Figure 26: Subsequent Optimization for a SAP S/4HANA System
Figure 27: Concept of Subsequent Implementation of Document Splitting

Figure 28: Activation of Document Splitting and Additional Ledger
Figure 29: An Important SAP Note: 2304418
Only one ﬁscal year can be open in asset accounting during conversion and the last year
cannot be reopened after conversion.

Figure 30: Different Scenarios
Scope of Changes in General Ledger Accounting
Migration to SAP S/4HANA
● Migration can be executed at the end of any period when all necessary prerequisites are
fulfilled.
● It is more a technical migration. Most errors cannot be adjusted by business departments.
● Functional migration of accounting is supported by a migration guide and monitor.
● Changes to coding blocks, external interfaces, security, and so on, are optional.
● Consider whether data archiving makes sense.
Migration from a General Ledger Perspective
● SAP S/4HANA is based on the new G/L ERP.
● It provides the same capabilities as new G/L (a central database expanded to more
modules, ledgers, document splitting) and leverages existing capabilities.
● It is further optimized for SAP HANA, for example, universal journal, no totals tables,
convergence with CO, and better reporting.
Additional Notes for Customers with Classic G/L
● As part of the migration, classic G/L data is automatically transferred to the new data
structures.
● Existing EC-PCA (profit center), EC-CS (consolidation), and SL (special ledger) functions
and features remain.
● Subsequent optimization (such as adoption of parallel ledger or document split) is always
an option and is not possible during migration.

● Customers already running a migration project to new G/L in SAP ERP should continue
this project. The same goes for customers urgently requiring document splitting.
Classic General Ledger Migration Constraints
Migration to accounting on SAP HANA from a classic G/L setup does not support the
following scenarios:
● Implementation of document splitting
● Balance sheets at the profit center level
● Migration from special purpose ledger to new general ledger accounting
● New implementation of parallel accounting
● New implementation of segment reporting
● Implementation of the ledger approach for parallel accounting
● Change in chart of accounts and conversion of chart of accounts
● Inclusion of customer fields
● Transfer of quantities to new general ledger accounting
Note:
Only existing dates are migrated. All topics listed here must be handled with
separate projects before or after migration (if technically possible).
Functions Affected by the Migration to SAP S/4HANA
● Foreign currency valuation
In SAP S/4HANA (as was the case previously with new G/L), you need to define valuation
areas to conduct foreign currency valuation. The valuation postings are made to the ledger
group defined per valuation area.
● Reconciliation between controlling and financial accounting
The universal journal is updated directly, so no reconciliation ledger or real-time
integration in the sense of the new GL is needed.
Functions that Can Be Adopted After the Migration
● Cost of Sales (COS) accounting (Ledger 0F)
You no longer need a separate COS ledger. You store the data directly in ledgers.
● Preparations for consolidation (Ledger 9)
You no longer need the consolidation staging ledger. You can store the data directly in all
ledgers, but it is still possible to use for preparation of consolidation.
Change Management Preparations
As there are differences between classic and new G/L, and between new G/L and SAP S/
4HANA, it is necessary to do the following:

● Have a good understanding of the full scope, not just a technical description of the
required customizing and migration.
● Train end users on the delta.
● Have a time schedule that allows several test migrations.
● Check authorizations during acceptance tests.
● Involve auditors or compliance experts where required.
Factors that Can Affect the Length of a Migration Project
● Support from customers (how many people, how quickly you can set up a test system, and
so on)
● Experiences of project members and consultants
● The quality of data, size of the system, and so on (migration of a system with goLive 2013
might be easier than a system with goLive 1996)
● There is a Near Zero Downtime (NZDT) scenario to minimize downtime
Note:
The first test (usually in the sandbox) gives a good first impression of what the
duration will be and the potential setbacks for the migration project (to get first
experience of a conversion , to test functional changes with regard to SAP S/
4HANA, to check data quality issues etc.).
Figure 31: New Programs and Transactions in S/4HANA

Figure 32: SAP Value Assurance Services for SAP S/4HANA
There are a number of services that support a conversion to S/4HANA at various phases,
such as:
● Migration Planning Workshop
● Transition Planning for New Implementation
● Custom Code Management Architecture and more.
Our Course System Landscape for a Sample Migration in 2016
● System: T68 and Client: 400
● Company code: 1000
● Classic GL and classic asset accounting
● Accounts approach to parallel accounting
● Enterprise extension EA-FIN ﬁnancial extension is active
● New depreciation engine is active
● Migration can be performed at any period end
● Special ledgers: Cost of sales accounting / preparation of consolidation
● Proﬁt Center Accounting (EC-PCA)
● Test data: Approximately 500.000 G/L accounting documents and a few special entries
for asset accounting (posted starting January 2015 and up to September 2016)

Note:
SAP S/4HANA is already installed for the course, so it is not possible to use the
old balance carry forward program and other programs.
LESSON SUMMARY

Unit 2
Lesson 3
Preparing for Conversion to SAP S/4HANA
LESSON OBJECTIVES
Migration Preparation
You want to make sure you have fully prepared your system for a conversion to SAP S/
4HANA. You want to understand what kind of flexibility you have for making subsequent
corrections after the installation of SAP S/4HANA. Finally, you want to understand the impact
that installing SAP S/4HANA has on your system before starting the migration.
Figure 33: Analysis and Preparation of Migration - Details
Analysis and preparation is the first of the five migration stages.

Preparation of Migration
Figure 34: SAP Readiness Check for S/4HANA
The Readiness Check for SAP S/4HANA gives a ﬁrst high-level impression of the conversion
impact. It is necessary to use SAP Solution Manager 7.1 or 7.2 connected to the old SAP
Business Suite System (SAP Note 2290622)
As a further option, if the SAP Solution Manager does not meet the requirements or if there is
no connection to the SAP Support Portal for security reasons, note 2310438 (SAP Readiness
Check for SAP S/4HANA - Managed System) can be used.
In both cases the check is free of charge.
Maintenance planner must be used. It checks if add-ons, business functions, and industry
solutions are supported for the conversion.
Figure 35: Aspects of SAP Readiness Check for S/4HANA
Readiness check as of S/4HANA 1709 checks the following aspects:
Lesson: Preparing for Conversion to SAP S/4HANA

● Impact regarding add-ons, Business Functions and deployed Industry Solution
● Sizing estimation
● Deprecated transactions the customer frequently uses in the SAP Business Suite
● Recommended SAP Fiori transactions based on current transaction usage
● Details about Simplification Items relevant for the customer and required functional
changes
● Impact on existing custom code extensions
SAP Readiness Check,executed in the SAP ERP PRD system, analysis results are compressed
to the Readiness Check Cloud Dashboard.
Additional Information:
● Notes for add-ons: 2214409 and 2011192
● Notes for industry solutions: 2659710 for S/4HANA 1809 and 2491467 for S/4HANA 1709
● Notes for sizing: 1872170 and 1793345 for a more detailed overview compared to the
Readiness Check
● Note for Always-Off Business Functions: 2240359
● Notes for Customer specific code: 2241080 and as for 1809 Custom Code Migration Guide
for SAP S/4HANA 1809 (http:/
/help.sap.com/s4hana)
Preparing for Migrating
● Creating business partner by customer vendor integration
● Archive if necessary
● Corrections and reporting
Preparation Phase Asset Accounting
● Close all fiscal years except the current fiscal year.
● From SAP S/4HANA 1809 onward, the checks from RASFIN_MIGR_PRECHECK (notes
1939592 and 2333236) are included in the Simplification Item Check framework.
Important note for all solutions: 2618023 - Migration Preparatory Checks for FI-AA: Error
Messages and Possible Solutions
● Check if new asset depreciation is active (SAP Note 965032). If not, enterprise extension
EA-FIN must be activated.
● Perform period-end closing activities in asset accounting:
- Periodic asset postings RAPERB2000
- Depreciation run RAPOST2000
● Lock asset accounting via posting periods to avoid further asset transactions as
RAPERB2000 asset accounting can no longer be used.

Preparation Phase Asset Accounting: Check Report
● Important hint: For deactivate company codes, see note 2406313.
● The following checks are performed (this is just a selection):
- New General Ledger (new GL) is active (only a warning as it is not a requirement)
- Classic Real Estate (RE classic) is not active
- No requests (with reference to assets) are used in Public Sector Management Fund
Management (PSM-FM possible only for acquisition as for 1809)
- All periodic postings are posted successfully (no update terminations)
- All relevant depreciation areas for parallel currencies exist
Figure 36: Check for New Asset Accounting
In transaction SA38, you can execute program RASFIN_MIGR_PRECHECK to perform the
pre-check (since S/4HANA 1809 integrated into SI-Check).
Since 2017, a point that affects many customers has become particularly important. Inactive
company codes are technically active company codes when there is evidence in any year.
Even status "Company code deactivated - later reporting allowed" does not work here. This
status means normally that all fixed assets are deactivated, a year-end closing has been
performed for all fiscal years of the company code and the company code is deactivated. This
is often not the case. Note 2406313 shows two alternatives - either archiving or catching up
the missing steps. These are the only two ways to make these company codes available again
for postings. Increasing the values for the last completed fiscal year in tables is not supported.
In short, all company codes with a depreciation plan need the last year as a closed fiscal year.
Preparation Phase Asset Accounting: Additional Currency
● For every additional currency type defined on the company code, a corresponding
depreciation area needs to be set up. Your current system configuration might not match
this new requirement (number of parallel currencies in FI-AA < number of parallel
currencies in G/L).

Important for account approach is note 2180591 Currencies in FI-GL and FI-AA are
inconsistent. Accounts approach: The parallel currencies in the general ledger and the
relevant depreciation areas in Asset Accounting must be defined congruently for the
leading valuation. For the multiple valuations, they do not necessarily have to be defined
congruently.
Caution:
You first need to set up a parallel area for each additional currency used in the
corresponding ledger of G/L. It is not possible to open a new depreciation
area (with program RAFABNEW) after installation of SAP S/4HANA and
before migration. New asset accounting cannot be activated, and migration
displays errors.
● Calculate the plan values for depreciation (transaction AFAR).
● When using the ledger approach with non-calendar fiscal year variant for parallel valuation,
see SAP Note 2220152.
Preparation Phase Asset Accounting: EA-FIN Financials Extension
● Enterprise extension EA-FIN is required for FI-AA (new) and SAP S/4HANA.
● The business function should be activated and tested in a small separate project before
the migration, if not already active.
● The following main enhancements are provided with extension EA-FIN in ECC:
- Accrual engine
- Intercompany reconciliation (cross-system)
- Depreciation engine in asset accounting (since ECC 6.0)
- Check SAP Note 1121965 for the complete list of functionalities and information
Hint:
Focus on scheduled depreciation values while testing (see SAP Note 965032 -
Differences between old and new depreciation calculation).
Insurance Values in Asset Accounting in S/4HANA
Defining insurance values in the asset master record is not possible anymore. Insurance
values must be maintained in S/4HANA in a separate depreciation area. If no such area
exists, it must be built before the conversion (note 2270388).

Preparation Phase FI, SL, CO, and Sub-ledger
Figure 37: Comparison: SAP Readiness Check and Simplification Item Check
● There are two tools are used to support the conversion process for 1809: SAP Readiness
Check in note 2290622) and Simplification Item-Check (SI-Check) in notes 2399707 and
2502552. For data consistency checks in Finance area note 2245333 - Pre-transition
checks for FIN: Error messages and possible solutions to find solutions for
recommendations before the upgrade can be used.
Figure 38: S4F03_SI_Check.pptx
It is strongly recommended to run the Simplification Item Check and fixing the issues
found by the checks as early as possible.
For S/4HANA Finance 1605 use note 2176077 - Program FINS_PRE_CHECK_SFIN_1605

● Ensure all balances are carried forward for the current fiscal year (accounts: FAGLGVTR or
F.16, Receivables/Payables F.07, Assets: AJRW).
● For account-based CO-PA, execute delta upload with delta load.
Caution:
When using classic GL, initialize valuation differences from currency
valuation. Field BSEG_BDIFF for open items must be empty for all years. If
not, create a new valuation method in the customizing path of the classic GL
and reset the valuation before the SAP S/4HANA is installed. The new foreign
currency valuation run after migration has to be in the same reporting period.
● For S/4HANA use SAP note 2129306. Check customizing settings prior to upgrade to S/
4HANA Finance or S/4HANA to check if settings in GL, CO, and the currency set allow
migration.
● Program FINS_MIG_PRECHECK (step in customizing) is part of SAP S/4HANA, and
cannot be used before installing SAP S/4HANA software.
● Check for canceled update requests (transaction code SM13).
●
Figure 39: Initialize field BSEG-BDIFF in Open Items when Migrating from Classic G/L
Initialize field BSEG-BDIFF for all open items (customers, vendors, accounts). The reset must
be done in the same reporting period as the next run for foreign currency evaluation after
conversion. This is only relevant if a classic G/L system will be converted to S/4HANA
Finance or S/4HANA.

Preparation Phase Reconciliation
●
Note:
Only use RFINDEX_NACC - FI Consistency Check with the option, Indexes vs.
Documents. All other checks of this program are not relevant for a migration.
The report is unfortunately not very clear. In many migrations, this topic will
be tackled in a second conversion based on the problems determined during
the first migration in the sandbox. The new reconciliation report is much
faster. The problem with open-item management should also be cleared for
G / L accounts, as many Fiori apps based on the open-item management.
Correction reports for open item management do not work anymore under S/
4HANA. Do not use program ZFINDEX_MIG from note 1592904 here.
● Reconcile asset accounting with GL (transactions ABST and ABST2)
● Reconcile AP/AR sub ledger with GL (report SAPF190 or TFC_COMPARE_VZ)
● Reconcile materials management with GL (reports RM07MBST and RM07MMFI)
● Reconcile ledgers (transaction GCAC)
● Check FI documents with FI balances for all fiscal years without archived data
(transactions F.03 or FAGLF03)
Before migration, all sub ledgers must be fully reconciled. Not all detected errors during
conversion need to be cleaned up. It needs to be clarified if these errors are relevant or not.
Certain kinds of errors can be accepted in the migration monitor, but remain visible. An error
in the migration to the universal journal must be fixed, whereas an error in CO line items from
the last century certainly does not have to be corrected.
Preparation Phase Audit
● The migration is supported from a technical point of view by many technical checks and
programs.
● This is certainly not sufficient from a business perspective. Special stakeholders, such as
internal or financial auditors, must be involved in the project to outline and verify the
following reconciliations for comparisons:
- Financial statement, account balances, and so on.
- Asset history sheet, and so on.
● There should be no postings after extracting data for any planned comparisons.
Otherwise, all reporting snapshots have to be repeated. Closing posting periods in FI, CO,
special ledger, and so on, might be helpful.
● Remember to cancel any periodic and planned jobs.
Recommended Reports for the Before-After Comparison
● Ledger comparison (transaction GCAC)
● Financial statements (program RFBILA00)

● Asset history sheet (program RAGITT_ALV01)
● Depreciation run for the planned depreciations (program RAHAFA_ALV01)
● Totals report for cost centers (transaction S_ALR_87013611)
● Sales order selection (program RKKBSELL)
● G/L account balance list (program RFSSLD00)
● General ledger line items list (program RFSOPO00)
● Compact document journal (program RFBELJ00)
● Vendor sales (program RFKUML00)
● Vendor open item list (program RFKEPL00)
● Customer sales (program RFKUML00)
● Customer open item list (program RFDEPL00)
● Customer recurring entry original documents (program RFDAUB00)
● Cost centers: actual/plan/variance (transaction GR55 with report group 1SIP)
You do not need to run all items mentioned. You should make a proposal that is equally
acceptable to all parties. The business department has to conﬁrm the migration.
Figure 40: Why is the Preparation Phase so Important?
Postings are not permitted in the system after installing SAP S/4HANA until the end of
migration.
LESSON SUMMARY

Unit 2
Lesson 4
Preparing for Business Partner Adoption
(Customer Vendor Integration)
LESSON OBJECTIVES
Customer Vendor Integration
You know that using business partners (BPs) in an SAP S/4HANA system is required. You
want to understand the steps required to prepare for the Customer Vendor Integration (CVI)
before SAP S/4HANA is installed.
Business Partner Approach - Motivation
● A business partner, such as the SAP Strategic Object Model, is a single point of entry for
master data for business partners, customers, and vendors.
● Business partners are used in applications such as the following:
- SAP Collections Management (FSCM-COL)
- SAP Credit Management (FSCM-CR)
- SAP Treasury and Risk Management (TRM)
- Loans Management (FS-CML)
- Customer Relation Management (CRM)
- Supply Chain Management (SCM)
- Supplier Relationship Management (SRM)
- Global Trade Services (GLS)
- Diﬀerent industry solutions
● The CVI component ensures synchronization between the business partner object and the
customer/vendor objects.
● Customer and vendor master data tables are still used and will be updated by CVI.

Figure 41: CVI
Figure 42: Integrated Object Model: CVI
CVI
● This is one of the most complex and elaborate subprojects of migration. Transformation
time depends on the complexity of number ranges, consistency of, for example, ﬁeld
attributes, partner data consistency, customer/vendor enhancements (extensions), and
data volume.
● It can be done (customizing, synchronization, and so on) as a separate subproject before
migration or as part of the migration project. However, it must be done before the
conversion process starts.
Business partners are be used in Finance, Sales, HR and Procurement. The
recommendation here is to start as early as possible.

● As a prerequisite of the SAP S/4HANA conversion project, all customers, vendors, and
their contacts must be converted to business partners. Only SAP Business Suite
customers with CVI in place can move to SAP S/4HANA.
● CVI ensures that customer and vendor master data tables are updated automatically after
a BP is created or changed.
Figure 43: How to Convert a Customer and a Vendor
The challenge you face with adoption of the business partner as the single customer or
vendor entity is consolidating an often very diverse set of account groups, number ranges,
and ﬁeld assignments.
Figure 44: CVI Conversion Steps Only Valid for SAP S/4HANA
Lesson: Preparing for Business Partner Adoption (Customer Vendor Integration)

The tools provided for conversion during an SAP S/4HANA migration concern the
preparation and the post processing phases.
Figure 45: Step 1 - Archive Data with Deletion Flag
Step 2 - Download SAP Reports and Check/Integrate Enhancements
● Download the following check reports:
- 974504: Inconsistencies in link tables of master data sync check report
- 1623677: CVI Customizing Check Report CVI_FS_CHECK_CUSTOMIZING
- 2216176: Pre- and post-conversion check report PRECHECK_UPGRADATION_REPORT
● Check and integrate customer/vendor enhancement (for example, customer-specific
fields in table KNB1). See SAP Notes 2309153 and 1623809. The notes explain how to
make customer enhancements to the CVI (integrating additional customer/vendor fields
in the business partner, and using CVI synchronization to update them in the customer/
vendor).
Figure 46: Step 3 - Business Function Activation

Use the switch business partner framework browser for activating: CA_BP_SOA,
VENDOR_SFWS_SC1 and VENDOR_SFWS_SC2 have to be active for the vendor contact
person data to be synchronized with BP contact person data (SAP Note 1454441
Development of contact person for vendors).
Figure 47: Step 4 - Customizing Activations
There are various flags that need to be activated in this step.
Figure 48: CVI Conversion - Preparation: Number Ranges
There are a number of recommendations:
● Variant A: As a mirror image of the customer/vendor number range the business partner
number range should be defined.
● Variant B: Maintain the business partner number range in such a way that the most
numbers from customer/vendor can be reused. In this case, not all customers or vendors
will get the same business partner number.
● Variant C: It is also possible to see the business partner number completely independent
of the customer or vendor number.
However, accounts receivable and accounts payable still use the customer and vendor
number and not the business partner number. For an additional opportunity since 1709
see note 2368760 CVI Enable flexible Accounting & Numbering.

Figure 49: Step 4 - Customizing Number Ranges
For each number range used for customer and vendor account groups, a number range for
business partners also has to be created as long as you want to continue using these
intervals.
Hint:
All customers and vendors must be migrated.
Figure 50: Step 4 - Further Number Range Customizing
To allow the customer/vendor numeric numbers to be taken over to the business partner, the
numeric intervals of the business partner number ranges must be set to external, if equal
numbers are desired. Switch back business partner intervals after the successful data
synchronization. Most of business partner intervals are used internally, unless the number
comes from another source system (for example, CRM or MDG).
Figure 51: Step 4 - Business Add Inns (BAdIs)
The following BAdIs are provided for CVI data mapping:

● Data Assignment BP - Customer/Vendor/Contact Person
● Data Assignment of Bank Details BP - Customer/Vendor
● Data Assignment of Payment Cards BP - Customer
● Data Assignment of Form of Address from Customer/Vendor to BP
● Defaults for Creating Data from BP to Customer/Vendor
Figure 52: CVI Conversion - Additional Information
Figure 53: CVI Conversion Field Grouping (Hide, Required, Optional)
Another task after the test migration is to adopt the ﬁeld grouping for the business partners.
There are a lot of new ﬁelds for the user to select.

It doesn’t make sense to create multiple BP roles (third parties, affiliated companies, and so
on.) just because of different field controls in different account groups in FI,MM and SD.
Mandatory fields for all master records of a business partner role can be defined at role level
(for example, reconciliation account, language, and so on.) For specific additional mandatory
fields, field control can be maintained at business partner type level (business partner type
should then be a general required field).
Figure 54: Step 5 - Mapping Tasks - Connecting BP Groups to Account Groups
The figure, Step 5 - Mapping Tasks - Connecting BP Groups to Account Groups, shows the
following details:
● Vendors: BP Roles FLVN00 (company data) FLVN01 (purchasing data)
● Customers: BP Roles FLCU00 (company data) and FLCU01 (sales data)
Figure 55: Step 5 - Mapping Tasks - Connecting Customers and Vendors to Business Partner
For every customer/vendor account group, a BP grouping must be available. You can only
use the same business partner grouping if the customer number is equal to the vendor
number in SAP ERP.

Figure 56: Step 5 - Mapping Tasks - Mapping Attributes
You need to map the different customer specific values for attributes such as marital status,
legal form, legal status, payment cards, industries, number, departments, authority, and so
on, of contact persons.
Figure 57: Step 6 - Check Customizing
Run the customizing check report, which will report any problems in your configuration.

Figure 58: Step 6 - Industry Attribute Check Report (Optional)
Check the FSBP_IND_SECTOR_MAPPING_CHECK report and set up industry mapping
industry entries for assignment in the context of CVI. Also evaluate existing or missing
assignment entries.
If the number of diﬀerent industry values are low, this report is not required.
Figure 59: Step 6 - Check Mappings
Run check report mapping (SAP Note 2216176) to ensure all the necessary CVI mappings are
done.
The following mappings are checked:
● BP roles are assigned to account groups
● Every account group BP grouping must be available
● Customer value mapping
● Vendor value mapping
● Customer and vendor value mapping (BP →
customer/vendor)

● CVI mapping (check CVI_CUST_LINK/CVI_VEND_LINK vs. KNA1/LFA1) - post-conversion
check
● Contact person mapping - post-conversion check
Figure 60: CVI Conversion - Synchronization - Data Load
To run the MDS_LOAD_COCKPIT report and create a corresponding SAP business partner for
the customer, vendor, and contact data for general data, addresses, role data, and bank
details, do the following:
1. Double-click the desired synchronization process:
● Customer →
Business Partner
● Vendor →
Business Partner
2. Filter the customer/vendor by account group or customer/vendor numbers to run the
synchronization in smaller batches if desired.
3. Run the report (F8).

Figure 61: CVI Conversion - Synchronization Report
CVI mapping checks if all the customers/vendors are converted to BP, that is, the number of
entries in table CVI_CUST_LINK/CVI_VEND_LINK equals KNA1/LFA1.
Contact person mapping checks if all contact persons have been converted to BP, that is,
CVI_CUST_CT_LINK and CVI_VEND_CT_LINK must contain the same number of entries as
contact table KNVK with the condition KNVK with where condition KUNNR <> SPACE and
KNVK with where condition LIFNR <> SPACE.
If there are inconsistencies in link tables, check SAP Note 974504 Inconsistencies in link
tables of master data sync.
Resolve the errors and run report MDS_LOAD_COCKPIT until all customers/vendors/contact
person are converted to BP.
Key Takeaway Points
● Archive unnecessary data. It is also important to check the non-active company codes in
FI-AA.
● A certified financial statement for the previous fiscal year is a prerequisite for the
conversion.
● The preparation phase is very important because there are a few possibilities for making
corrections after the installation of SAP S/4HANA.
● Involve stakeholders to evaluate relevant data for acceptance of migration.
● Certain aspects can be taken care of in preliminary projects, such as activation of EA-FIN.
● CVI can be launched in a separate project before migration.
● All years in the system will be converted. A restriction is not possible.
LESSON SUMMARY

Unit 2
Lesson 5
Describing the SAP S/4HANA Installation
Phase
LESSON OBJECTIVES
Installation of SAP S/4HANA
The installation phase is the second of ﬁve phases.
SAP S/4HANA Installation Phase
● Installation is performed by a system administrator, there is a separate installation guide
for this process.
● The following steps are executed automatically by the system:
- Create backup tables for the totals tables and index tables in the data dictionary that
are deleted (*_BCK in FI and *_BAK in CO).
- Save the totals tables and index tables in backup tables.
- Delete the original totals tables and index tables.

- Create SAP HANA views (with the same names) for the totals tables and index tables
and the new table ACDOCA Universal Journal.
- It usually takes approximately 12 to 18 hours to load the software by the SUM. But that
this just the technical migration. The functional migration will follow in the next
chapters.
Caution:
After installation of SAP S/4HANA, postings are not possible until the end of
migration. The system (all clients) is not usable.
Only one Asset Solution for SAP S/4HANA
● After the technical installation of SAP S/4HANA is complete, remember the following
points:
- It is not possible to post in asset accounting, either by using the old logic or the new
logic.
- Migration and activation of new asset accounting has to be completed.
- It is no longer possible to return to classic asset accounting. Classic asset accounting
does not exist in the SAP Accounting powered by HANA solution.
- Balance sheets and account balances cannot be generated anymore (tables are
empty).
LESSON SUMMARY

Unit 2
Learning Assessment
1. Which of the following are NOT required to be adopted in a conversion to SAP S/4HANA
Finance 1605, but ARE required in a conversion to SAP S/4HANA 1809?
X A Customer Vendor Integration
X B Universal Journal
X C Material Ledger
X D New Asset Accounting
X E Logistics Simpliﬁcations
2. On which level is SAP S/4HANA installed?
X A Company Code
X B Client
X C System
X D Database
3. Only one ﬁscal year can be open in asset accounting during migration, the previous year
can be reopened after migration is completed.
X True
X False
4. You can implement additional standard ledgers in a system during a migration project.
X True
X False

5. Which factors can greatly aﬀect the required length of a migration project?
X A The size of the system
X B The system starting point new or classic GL
X C The data quality in the system
X D The use of the near zero downtime scenario (NZDT)
6. When starting from a system without CVI, to create the new Business Partners and take
over the existing customer/vendor numeric account numbers, the business partner
number ranges must be set to external.
X True
X False
Unit 2: Learning Assessment

Unit 2
1. Which of the following are NOT required to be adopted in a conversion to SAP S/4HANA
Finance 1605, but ARE required in a conversion to SAP S/4HANA 1809?
X A Customer Vendor Integration
X B Universal Journal
X C Material Ledger
X D New Asset Accounting
X E Logistics Simplifications
Correct! With the finance only add-on, you do not require to adopt the materials ledger
and business partners.
2. On which level is SAP S/4HANA installed?
X A Company Code
X B Client
X C System
X D Database
Correct! SAP S/4HANA requires a system level conversion, affecting all clients in use.
3. Only one fiscal year can be open in asset accounting during migration, the previous year
can be reopened after migration is completed.
X True
X False
Correct! You can’t reopen previous fiscal years for asset accounting after migration.

4. You can implement additional standard ledgers in a system during a migration project.
X True
X False
Correct! Introduction of an additional standard ledger requires a separate project after
migration (or a new G/L migration project before).
5. Which factors can greatly affect the required length of a migration project?
X A The size of the system
X B The system starting point new or classic GL
X C The data quality in the system
X D The use of the near zero downtime scenario (NZDT)
Correct! The project length is not affected by the prior use of classic or new GL (though
this might be an indication of the age of the system, which can affect the length). Using the
NZDT scenario has an affect on the length of a downtime, however this is only a small part
of the total migration project.
6. When starting from a system without CVI, to create the new Business Partners and take
over the existing customer/vendor numeric account numbers, the business partner
number ranges must be set to external.
X True
X False
Correct! If you require the same numbers, you have to set the number range to external.

UNIT 3 Customizing Financials
in SAP S/4HANA
Lesson 1
Configuring General Ledger Accounting 64
Lesson 2
Configuring new Asset Accounting 80
Lesson 3
Migrating to new Asset Accounting 89
Lesson 4
Customizing Controlling for Account Based CO-PA 95
Lesson 5
Preparing for Migration Material Ledger 98
Lesson 6
Preparing for Migration of House Bank Accounts 101
Lesson 7
Preparing for Migration of Credit Management/Trade Finance 103
UNIT OBJECTIVES
● Configure General Ledger Accounting for Migration
● Configure Asset Accounting for Migration
● Migrate to new Asset Accounting
● Configure Profitability Analysis for Migration
● Configure the Material Ledger for Migration
● Configure House Bank Accounts for Migration
● Configure Credit Management for Migration

Unit 3
Lesson 1
Configuring General Ledger Accounting
LESSON OBJECTIVES
General Ledger Configuration
You need to configure the system to be able to migrate to SAP S/4HANA. General ledger
customizing must be adapted in accordance with the new transactions and programs. You
need to be able to understand and execute the customizing steps in new asset accounting.
Customizing is the third out of five phases of SAP S/4HANA migration.

Figure 64: Software Update Manager
Software Update Manager (SUM) is the technical tool for system conversion to SAP S/
4HANA. Migration starts after the SUM ABAP process and the follow-up activities.
Figure 65: S/4HANA Always On Functions
Lesson: Conﬁguring General Ledger Accounting

Figure 66: IMG Activity: Check Customizing Settings Prior to Migration
Execute the pre-check again to identify and fix any additional problems.
Figure 67: Set Number of Jobs for Activities in Mass Data Framework
By default, after the installation of SAP S/4HANA and before finalizing the migration, an error
occurs in the case of an attempted posting: FINS_FI_MIG 150 Data migration is not yet
finished: Posting of documents is not possible. The message can be switched from error to
warning/information in the test environment but should never be changed in a productive
system as this will lead to data inconsistencies. Start with 10 jobs to define the optimal
number of jobs. Increase or decrease this number and check the effect on the system
performance in the data migration monitor in the later steps.
Unit 3: Customizing Financials in SAP S/4HANA

Figure 68: IMG Activity: Check and Adopt Fiscal Year Variants
The fiscal year variants of productive controlling areas and all their assigned company codes
must be the same.
Figure 69: Currency Settings for Migration
All entries in the universal journal need all required currency types and amounts according to
the customizing. This includes the currency types that were only used in controlling.
Define exchange rate types:
This is relevant for statistical CO objects with object currency not equal to company currency.
The corresponding line item with the real account assignment is already archived and no
company currency is available.
Amounts in local currency need to be calculated by using this currency type (M or EURX) and
a posting date.
Currency type of the controlling area = global currency (KSL)
SAP Help: Each journal entry contains the currency type of the controlling area, regardless of
whether this currency type is defined as second or third local currency in FI. Each journal
entry always contains the postings from CO. If the currency type of the controlling area is
defined as second or third local currency in FI, this currency type is filled not only in the

general ledger view of the FI postings (table ACDOCA, field KSL) but also in the entry view
(table BSEG, fields DMBE2 etc.). The controlling area currency is thus integrated with FI...
Having the currency type of the controlling area as second or third local currency in FI is the
recommended setting for a greenfield-approach. Currency settings cannot be changed in the
brownfield approach. To check or change your setting, use transaction
FINSC_LEDGER(section Company Code Settings for the Ledger for the leading ledger) or
transaction OB22.
Calculate amounts for previous CO specific currencies:
Amounts for currency types that were formerly used only in CO are calculated and form
existing FI amounts based by FI customizing or by using the CO approach (note 678180).
Use value "2 - According to CO Approach" for migration to enable compatibility with classic
SAP ERP releases. It is also possible to use value "1 - According to FI Currency Customizing"
as well. But in this second case it is necessary to calculate currency type 30 from currency
type 10 instead of currency type 00. Currency types 30 and 10 would be identical.
Calculate amounts for previous CO specific transaction currencies (this is only needed in case
of using transfer prices):
In short, for a migration from ERP, use value 2 Calculate Transaction Currency for each
Parallel Valuation (1 Take Document Currency for all Valuation is used for a new S/4HANA
installation).
Figure 70: Migrate General Ledger Customizing
The new G/L is an active flag set automatically in the background after this step if it was not
already active.
The technical migration involves the following settings for the journal entry ledger:
● Company code assignments
● Currency settings
● Fiscal year variant
● Open period variant
● Settings from real-time integration of CO-FI
This activity should not be repeated if it has run error-free, since it overwrites the values.

Figure 71: IMG Activity: Define Settings for Ledgers and Currency Types
All relevant information is automatically adopted to the new transaction define settings for
ledgers and currency types.
Customers with a classic C/L automatically receive customizing for a leading ledger and the
data migration to this ledger.
Figure 72: Up to 10 Parallel Currencies per Ledger
It is possible to define eight additional currency types besides the local currency (HSL, the
currency type 10) and the global currency type (KSL, the currency type of the controlling
area). There is no more dependency on the currency types of the leading ledger. Table
FINSC_VERSN_LD defines the mapping controlling area and version to ledger.
The new currencies have the following characteristics:
● Real-time currency conversion for all currency types is possible
● Balance zero per document is guaranteed for each currency
● Controlling area currency (KSL) is now calculated for all accounts, even for non cost
elements
● This requires that the amounts are selected from historical data. This is not yet supported
for all processes. Therefore, amounts are converted with the current exchange rate
(program FINS_ACDOC_UTIL_SET_KSL from note 2357161).

The new clearing logic is available for open items on general ledger accounts, customers,
vendors, CO allocations and GL allocations, but not for material ledger process, CO
settlements and fixed asset processes like depreciation.
Hint:
It is not possible to introduce, or to delete, another currency during migration.
Transfer Prices
Figure 73: Transfer Prices Example One Ledger
Transfer prices are supported since SAP S/4HANA Finance 1605 and SAP S/4HANA 1610.
ERP customers using transfer prices can migrate. The transfer price solution had been built to
provide different perspectives on the value chain within the group. It supports up to three
parallel valuation methods for legal, group, and profit center valuation. The CO compatibility
views transform the transactional data in the universal journal back into the old CO data
model.
● The legal perspective looks at the business transactions from a company’s point of view.
Pricing is driven by legal requirements and tax optimization strategies.
● Profit center valuation looks at profit centers as independent entities within the group.
● The group view considers the group as a whole. The processes are valued by eliminating
inter company/inter-profit center profits.
● Using transfer prices is normally a topic in Controlling.
Table FINSC_VERSN_LD: Read-access to CO actual data (=postings) will read the data from
this ledger in table ACDOCA. In this example, from ledger 0L for all three CO versions.
Table FINSC_LD_CMP: One record in the ACDOCA table stores the data for all three COEP
records (CO line items). An additional ledger also exists. They are not evaluated by read-
access by CO. So they do not need to be certain of all the currency types the CO would
require.
Overview currency types:
● 11 Company Code Currency, Group Valuation

● 12 Company Code Currency, Profit Center Valuation
● 31 Group Currency, Group Valuation
● 32 Group Currency, Profit Center Valuation
Figure 74: Transfer Prices Example Two Ledgers
Table FINSC_VERSN_LD: In this example, read-access to CO data will read the data from
ledger 0L for version 000 (legal valuation) and version 0GR (group valuation). The data for
version 0PC (profit center valuation) will be read from ledger L2.
Parallel Valuation of Cost of Goods Manufactured (COGM)
The functionality of multiple valuation of cost of goods manufactured (COGM) provides
parallel valuations according to multiple accounting principles (business function:
FIN_CO_COGM). Multinational organizations often report according to multiple accounting
principles, such as IFRS as the global accounting standard and a second GAAP for a local
accounting standard. For those countries that do not report solely according to IFRS, it is
possible to set up additional ledgers for the local GAAPs and to calculate activity prices and
material prices that are based on the different inputs, such as the different approaches to
depreciation, pensions, and so on. The major change in customizing is that postings in CO
must be always integrated with FI. COGM using parallel accounts is not supported. COGM
using parallel ledgers is available for a conversion with SAP S/4HANA 1610 FPS02 (notes
2270414 and 1852519). Only if this business function FIN_CO_COGM is activated, the
corresponding features become visible, for example in the IMG (Customizing Implementation
Guide, transaction SPRO) and can be used.
Customizing Accounting Principles and Valuation Areas
● Accounting principles and valuation areas might already be used (new GL) to post
differences in valuation either to different accounts (account approach) or to different
ledgers (ledger approach in new G/L). For example, the accrual engine uses accounting
principles and foreign currency valuation uses valuation areas.
● If these objects are not yet in the client you need to create these now.
● All objects have to be assigned in customizing for all approaches (account approach and
ledger approach).

Figure 75: Ledger Approach: Valuation Area- Accounting Principle - Ledger Group Since New G/L
Valuation areas are required for foreign currency valuation. Valuation areas are assigned
directly to the accounting principle and, thus, indirectly to ledger groups.
Figure 76: Account Approach: Deﬁne Settings for Ledgers and Currency Types
You conﬁgure the settings for the Account Approach as for Ledger Approach but of course all
accounting principles refer to the leading ledger. There is a new indicator Parallel GL Accounts
in the company code settings for the ledger. This is to increase transparency when assigning
more than one accounting principle to a ledger for the company code. It might be easier to
use customizing step "Review the Assignment of Ledger and Company Code to Acc.-
Principles" for adding accountings principles to company codes.

Figure 77: IMG Activity: Define Ledger for CO Version
The leading ledger (usually 0L), maintained in Define Settings for Journal Entry Ledger, must
be always assigned to CO version 0. The leading ledger is representative for controlling. This
is currently a restriction.
Use IMG activity, Review the Assignment of Ledger and Company Code to Acc.-Principles, to
get an overview about the assignment of ledgers, company codes, and accounting principles.
Figure 78: IMG Activity: Define Document Types for Postings in Controlling
This activity is taken from financial accounting to create document types. Controlling also
uses document types when posting to FI. It is recommended to have a separate document
type for controlling postings with the indicator G/L account set.
In SAP S/4HANA, all controlling business transactions also use document types (for example,
manual re-posting of primary costs). Document type for controlling (for example, CO) must
allow the new account type for secondary costs as well.

Figure 79: IMG Activity: Define Document Type Mapping Variants for CO Business Transactions
The document types can be specified on the following levels:
● Company code via different document type mapping variants.
● Controlling business transactions (for example KAZI - Actual cost center accrual) which
can have a separate document type.
● Normal postings and cross-company postings that can have separate types per business
transaction as well.
Figure 80: Document type and Ledger Groups in Controlling
The figure, Document type and Ledger Groups in Controlling, illustrates how you now enter
both the document type and the ledger group in manual CO transactions to differentiate
transactions by document type or to enter a posting for a specific accounting principle (such
as international or local GAAP).
Figure 81: IMG Activity: Check and Define Default Values for Postings in Controlling
● Default settings are necessary for postings where there is no possibility to manually define
the document type and ledger group in the Controlling business transaction.
● The major question here is which ledger(s) should Controlling update?

● This is the same critical setting as in new G/L where the ledger group assigned in the real-
time integration variant determined the ledger posted to in Financial Accounting. When no
ledger group is entered in controlling transactions, all ledgers are updated in table
ACDOCA (exactly as for FI transactions). The majority of customers update all ledgers.
● The decision is simple here when using the accounts approach.
Options for Defining Offsetting Account Determination Types
● 0
No display of offsetting account
● 1
Display offsetting account if clearly specified
● 2
Always display offsetting account with the highest amount
● 3
Two including automatically generated line items
Option 3: Always display offsetting account with the highest amount including automatically
generated line items is generally the optimal solution from a business point of view, as it is
never possible to show all offsetting accounts.
IMG Activity: Define Source Ledger for Migration of Balances
● Define source ledger, company code (star * = all), year (1900 = all years), and target
ledger for migration of the balances.
● The year should always be the earliest year with postings and for which no future year has
archived documents.
● The source ledger can be any ledger (0 Classic GL, 9 Preparation of Consolidation, 8A
Profit Center Accounting, and so on).
Note:
Remember to check tables FAGLFLEXT_BCK and GLT0_BCK and not
FAGLFLEXT and GLT0 to see the entries.
● Example for new GL starting in 2010 and ledger 0L, Z1 and Z2
Source ledgers = Target ledgers, Year 2010
● Example for classic GL in 2010 and migration to new G/L in 2012, account approach
Entry 1 Source Ledger 0 and year 2010, target ledger 0L
Entry 2 Source Ledger 0L and year 2012, target ledger 0L

Hint:
For starting a migration with classic G/L and the following IMG activity, Check
and Define Settings for Substitution for Cost-of-Sales Accounting: Only in the
case of a derivation of functional areas using a substitution with call-up point
0005. In SAP S/4HANA the substitution must be created new and assigned for
call-up point 0006.
Use the following IMG activity, Check and Define Settings of Controlling Area, to check the
settings for all controlling areas.
Figure 82: Execute Consistency Check of General Ledger Settings
All the configured settings of the general ledger are checked again for readiness for migration.
Figure 83: IMG Activity: Activate Business Functions only Relevant for S/4HANA Finance
The business functions include (amongst others) the following helpful functions:
● Posting and Clearing for Specific Ledger Groups
● Drilldown Reports for Profit Centers and Segments
● Switch to Open Item Management for G/L Accounts
● Check Posting Period for Non-Representative Ledgers

The business functions will be activated with the transport requests in follow on systems
(very important: activation of all activated business functions should be transported, a quick
manual check in the target system is necessary).
Accrual Management
Figure 84: Accrual Management
The S/4HANA Accrual Management is optimized for S/4HANA and replaces Acrual Engine
with S/4HANA 1809. Accruals Management comes with the first scenario of Purchase order
accruals.
It is fully integrated into the General Ledger:
● All currencies of General Ledger are supported.
● The Accrual Engine postings are stored only as line items of the universal journal entry
(table ACDOCA).
● The fiscal year variant of the G/L ledgers are supported
There is no redundant storage of the postings as original document. Periodic postings to
general ledger is obsolete. So, there is no reconciliation effort necessary with G/L. The
separate carry forward program is obsolete as well. Now Accruals Management enables
complex postings with more than two lines by using customer-defined posting schemas.

Figure 85: Migration of Accrual Engine to Accrual Management
The data model of customizing and transactional data of the (new) S/4HANA Accrual Engine
have changed compared to the old Accrual Engine. Several of the old tables have been
replaced by new tables. As a consequence, customizing and transactional data need to be
migrated after the customer has upgraded/converted to SAP S/4HANA 1809 or higher. The
transactional data of the Accrual Engine consist of Accrual Objects and Accrual Postings.
Hint:
Only the application Manual Accruals was switched to the (new) S/4HANA
Accrual Engine. Other applications stay on the old Accrual Engine in release
1809. No migration is required for other applications like Real Estate
Management (RE). If manual accruals has been using before the upgrade
migration of customizing and transactional data is a mandatory activity.
Figure 86: Accrual Engine Migration: Activities in Customizing and Productive System
The customizing has to be transported and imported before a migration of the transactional
data can be executed. Technically, the migration of Accrual Engine transactional data is based
on a separate tool compared to the migration of other postings: It uses the mass data

processing cockpit which is an SAP standard tool for mass data processing. The migration of
the transactional data (accrual objects and accrual postings) of the Accrual Engine is
performed by creating and executing a mass data project (project type = 70).
The mass data project is created in the Customizing system. The project is to be transported
to the productive system. After importing the mass data project in the productive system, this
project can be executed there. Once the execution of the mass data project has been
completed, the migration was done and the Accrual Engine can be used again for creation of
new accrual objects and to perform accrual postings.
Key Takeaway Points
● Customizing steps are required before migration can start.
● Settings should be managed and transported via change requests.
● Unlike a migration to new G/L, all years with postings have to be migrated to SAP S/
4HANA. Only in case of using Accrual Engine for manual accruals a migration is necessary
for it.
LESSON SUMMARY

Unit 3
Lesson 2
Configuring new Asset Accounting
LESSON OBJECTIVES
Asset Accounting Configuration
You need to configure the system to be able to migrate to SAP S/4HANA. New asset
accounting must be configured as part of the SAP S/4HANA prerequisites. You need to be
able to understand and execute the customizing steps in new asset accounting.
Overview of Customizing and Migration
● To activate new asset accounting, complete the following steps:
- Prepare and precheck before installing SAP S/4HANA
- Set up new customizing needs
- Migrate charts to depreciation
- Activate new posting logic
● Even if you migrate to SAP Accounting powered by SAP HANA from a system (for
example, EHP8) and have FI-AA already active, you must still migrate every active chart of
depreciation.
● Migration to the new asset accounting is a migration of customizing settings. At this time,
values in tables (ANLC, ANEP, and so on) are not changed.
Figure 87: Preparation of New Asset Accounting = Customizing

The asset accounting customizing documentation displays the sequence of steps required to
migrate. In the course, you will go through the process for manual chart of depreciation
migration.
Customizing Steps and Checks for New Asset Accounting
● Check and create accounting principles and ledger groups.
● Assign accounting principles to ledger groups for both approaches:
- Ledger approach
- Account approach
● Account approach: Define asset balance sheet accounts of parallel valuation as
reconciliation accounts.
● Define a new technical clearing account for integrated asset acquisition.
● Quantity update: Define depreciation area.
● Integrated transactions: Specify alternative document type.
● Define revenue distribution for retirement by APC or net book value.
● Post net book value instead of gain/loss.
● There are no restrictions of transaction types to depreciation areas.
Figure 88: New Asset Accounting in Preparation
The status for new asset accounting must be in preparation.
Lesson: Configuring new Asset Accounting

Figure 89: Automatically Generated Ledger Groups for the Account Approach
All depreciation areas representing the same accounting principle are assigned to the same
accounting principle (and ledger group).
Parallel Valuation Approaches
● Companies often report to the following accounting regulations:
- International Generally Accepted Accounting Principles (GAAP)
- Local GAAP
- Tax GAAP
● There are different objects to indicate these requirements. Valuation areas (FI) are used
for closing activities like foreign currency valuation, sorting/reclassification or further
valuations.
● Accounting principles are used for the following:
- New asset accounting to combine different depreciation areas to an accounting
principle
- Accrual engine
● Ledger groups are used for the following:
- Manual postings in FI (for example, in FB50L, enter G/L Account Document for Ledger
Group)
- Manual postings in CO (for example, KB11N, manual reposting of costs)

Figure 90: Explanation per Approach to Parallel Valuation
In the account approach to parallel valuation, the additional valuation areas and accounting
principles are assigned to ledger groups in customizing, just as in the ledger approach. The
difference is that in the account approach, the same underlying ledger is assigned, the leading
ledger. With the ledger approach, a new ledger is automatically assigned to a ledger group
with only that ledger included.
The combination of more than one ledger in a single ledger group is possible with the ledger
approach, for example with the naming in the figure, to post 0L and Z1 together, without
updating Z2.
Automatically Generated Ledger Groups for the Account Approach
● The ledger groups can be created automatically as follows:
1. Execute migration report FAA_CHECK_MIG2SFIN for your depreciation plan.
2. Maintain the description of your automatically created ledger group in IMG: Financial
Accounting → Financial Accounting Global Settings → Ledgers→ Ledger→ Define
Ledger Group.
● The system performs the following settings:
- Creates a ledger group for each leading depreciation area of a non-leading accounting
principle. This ledger group is always assigned to the leading ledger 0L.
- The name given to the automatically created ledger group is: &+number of depreciation
area+&.
- The depreciation plan is not migrated during this first execution, due to missing ledger
groups. The depreciation plan must be migrated twice.
● It is recommended to create entries manually.

Figure 91: Manually Assigned Settings
When conﬁguring the depreciation areas manually, select for areas that post to the G/L:
● In the account approach: Area posts APC immediately, depreciation periodically
● In the ledger approach: Area posts in realtime
Figure 92: Adapt Value Takeover and Parameter Takeover
Value takeover can only be done within a set of depreciation areas, which are assigned to the
same accounting principle. Leading areas need to be set to 00 (you need to delete the entry,
not type 00).

Figure 93: Reconciliation Accounts (only for Account Approach)
There is a program to automatically switch all accounts of parallel valuations to reconciliation
accounts. This is only required for the account approach.
New Account Technical Clearing Account for Integrated Asset Acquisition
● Balance behavior:
- Ledger approach: Always balances to zero per ledger group and account assignment.
- Account approach: Always balances to zero together with the Contra account:
Acquisition value posting in your financial statement.
● Is defined as a reconciliation account, but not managed on line items
● Different technical clearing accounts for asset acquisition for specific account
determinations are possible, for example, to set different field status for the text field.
Figure 94: Quantity Update
Define the depreciation area for quantity update, as follows:
● In the asset master data, the quantity is only updated if a posting is performed to the
depreciation area.
● If this IMG activity is not manually maintained, the system by default updates the quantity
when a posting is made to depreciation area "01".

Figure 95: Document Types for Integrated Transactions
It is possible to indicate a different document type to be used by the system for the
automatically generated accounting principle specific documents in asset accounting on the
client or company code level. Use of document splitting can be a reason for this or requiring
external number ranges for FI-documents posted through logistics invoice verification.
Figure 96: Revenue Distribution for Retirement by APC or Net Book Value for Mass Retirement
In this step, specify at company code level how the system is to distribute revenues arising
from asset retirements, either based on the net book value or on APC. In the standard system,
the distribution is based on the net book value.
Check the distribution of revenue for your company codes and adjust the distribution to meet
your requirements.

Figure 97: Post Net Book Value Instead of Gain/Loss
In this step, specify that you want the system to post the net book value of an asset being
retired to the account Clearing of revenue from sale of assets and Clearing of revenue from
internal sale. No proﬁt/loss (from sale) or loss from asset retirement (after scrapping) is then
posted. Post net book value is a legal requirement in France for French retirement.
The restriction of the posting logic to certain depreciation areas is done in classic asset
accounting using area types.
Check Transaction Types
● In new asset accounting, it is not possible and not necessary to restrict transaction types
to depreciation areas. Restrict posting to a depreciation area or accounting principle
directly in the posting transaction.
● If you were using transaction types that were restricted to certain depreciation areas, you
can no longer use these transaction types. Check whether your existing transaction types
that are not restricted to depreciation areas are suﬃcient. Investment support and
revaluation and new valuation are an exception.
● Exceptions are as follows:
- The transaction types for investment support and revaluation are automatically
generated by the system when you create a corresponding measure, and therefore, are
restricted to the depreciation area to be posted to.
- The transaction types for revaluation and new valuation that relate to transaction type
group 81/82/89 can continue to be restricted to depreciation areas.

Figure 98: Marking Transaction Types as Obsolete
Set all transaction types (restricted to depreciation areas) to obsolete. A ﬂagged transaction
type can no longer be used and is no longer proposed in the input help of the transaction
types. For reporting and audit reasons do not delete the obsolete transaction types.
Figure 99: Summary Additional Manual Activities
LESSON SUMMARY

Unit 3
Lesson 3
Migrating to new Asset Accounting
LESSON OBJECTIVES
Asset Accounting Migration
You have conﬁgured new asset accounting and now want to complete migration and start
using it. You need to be familiar with the migration steps to start using new asset accounting
in your system.
Settings that Need to be Applied
● An accounting principle is assigned to each depreciation area. The ledger group is derived
from the accounting principle.
● The posting indicator of a depreciation area is conﬁgured so that the following occur:
- Delta areas (not relevant any more) do not post. Deleting delta areas is recommended.
- The leading depreciation area of each accounting principle posts in real-time for both
approaches (ledger and account approach).
● The indicators for inheritance of depreciation terms and APC values is adapted so that the
following occur:
- The leading depreciation area of each accounting principle is set to initial (00).
- Each depreciation area can only inherit terms/values of depreciation areas belonging to
the same accounting principle.
● An active chart of depreciation, that is assigned to a company code, is needed. A sample
chart of depreciation cannot (and does not have to) be migrated.
● Each chart of depreciation is categorized as one of the following:
- Ledger approach
- Account approach compatible

Figure 100: Preliminary Requirement: Customizing is Complete
This step should only be started after asset accounting has been completely conﬁgured.
Figure 101: Migration of Chart of Depreciation via Migration Report
The ﬁrst chart to migrate to new asset accounting is the chart of depreciation.

Figure 102: Procedure: Migration of the Depreciation Plan
The ﬁgure, Procedure: Migration of the Depreciation Plan, shows the process for automatic
migration of the chart of depreciation.
If a chart of depreciation cannot be migrated automatically by the migration report, you can
customize manually by doing the following:
1. Check which depreciation plans are active or need to be migrated.
2. Check if accounting principles are set up.
3. Check if ledgers and ledger groups are set up.
4. Check the assignment of accounting principles to ledger groups.
5. Set up of depreciation areas by checking the following:
● The accounting principles (and ledger group) are assigned to each depreciation area.
● The posting indicator for each depreciation area is correct.
● The posting indicator for adoption of APC values is correct.
● The posting indicator for adoption of depreciation terms is correct.
● The currency type of a depreciation area for parallel currency is correct.
Lesson: Migrating to new Asset Accounting

Figure 103: Log of Report Migration of Chart of Depreciation
The Report Migration of Chart of Depreciation log shows that the depreciation plan has been
migrated when all steps are completed manually beforehand.
Figure 104: Check Prerequisites for Activating New Asset Accounting and Activation
The final two steps include a final technical check of the prerequisites and setting the
activation flag to active.

Figure 105: Adjustments if New Asset Accounting is Already in Use
Not all steps are needed if asset accounting (new) is already active before migration either via
business function FI-AA, Parallel Valuation FIN_AA_PARALLEL_VAL) in Enhancement
Package 8 for SAP ERP 6.0 or in SAP S/4HANA Finance.
Figure 106: Overview of the Sequence of Migration
Ensure that you use a system copy to test from the production system to the test system
(quality assurance system).
Check the conﬁguration in all systems before migration. See SAP Note 1939592 Prerequisites
for migration (since S/4HANA 1809 integrated into SI-Check).
Sequence of the Migration for the Development System
1. Create prerequisites for the use of new asset.
2. Install SAP S/4HANA.
3. Set up customizing for new asset accounting (request).
4. Migrate the charts of depreciation (request).
5. Perform any additional customization if step 3 is not performed (request).
6. Check prerequisites for activating new asset accounting.
7. Activate the customizing switch so that asset accounting (new) is active (request).
8. Migrate data to SAP S/4HANA.
Lesson: Migrating to new Asset Accounting

Sequence of the Migration for Test and Productive Systems
1. Create prerequisites for the use of the new asset.
2. Close asset accounting via posting periods.
3. Install SAP S/4HANA.
4. Import customizing FI, CO, ML, and so on (request).
5. Create missing master data, for example, technical clearing account.
6. Import settings for asset accounting (new) including activation by transport (request) so
that asset accounting (new) is active, but values have not been migrated yet.
7. Open posting periods after ﬁnishing migration to table ACDOCA.
Key Takeaway Points
● Pre-checking requirements for asset accounting (new) is very important before starting
the installation of SAP S/4HANA (now integrated in SI-check).
● You must have completed periodic postings in the system before installing SAP S/4HANA
(RAPERB2000 ― periodic APC postings is deleted in SAP S/4HANA). If the conversion
does not start immediately after the month closes, the periodic APC postings must be
repeated.
● Postings are not possible (including in FI-AA) after installation of SAP S/4HANA until
migration has been ﬁnished.
● Only one migration per depreciation plan is allowed in the development system. In other
system, (QA, PROD), migrations for asset accounting (new) are realized by importing the
relevant requests.
● Settings in FI-AA must be correct before migration starts.
● The actual tests are the deciding factors for the GoLive, not just the pre-check programs.
● Finance migration has to be executed for each client (SUM is for the whole system).
LESSON SUMMARY

Unit 3
Lesson 4
Customizing Controlling for Account Based
CO-PA
LESSON OBJECTIVES
Profitability Analysis Configuration
You need to configure the system to be able to migrate to SAP S/4HANA. Management
accounting must be customized according to new transactions and programs.
Figure 107: Customizing Controlling for Account Based CO-PA
The settings within the migration menu path for controlling are only relevant for configuring
account-based CO-PA.
Figure 108: IMG Activity: Only if Using Business Intelligence Based on Account-Based CO-PA
Execute the final BW delta extraction run before migration starts.
Figure 109: IMG Activity: Delete Settings for the Change of Profitability Segment Characteristics

Summarization with SAP S/4HANA is no longer available. All totals are aggregated by reading
line items in real-time. This step deletes the relevant settings for summarization.
Figure 110: Activate Account-Based Profitability Analysis in Customizing
Definition and activation of account-based CO-PA is recommended. Revenue postings and
cost of goods sold postings are updated under the relevant account. They are assigned to the
correct market segment characteristics.
It is necessary to check all functionality during testing and decide if costing-based CO-PA
should be replaced by account-based CO-PA. The question of whether to replace it or not is
one of the most important decisions in a migration project. Costing-based CO-PA can be used
as before but is much faster. Characteristics are automatically included in the universal
journal during activation operating.
Hint:
Historical data is never migrated when activating account-based CO-PA during
migration.
Key Takeaway Points
● It is recommended to activate all account-based profitability analysis during migration so
that all new profitability reporting is available.
● Costing-based profitability analysis is still available (and is enhanced compared to any
database system). Both types of profitability analysis can be used in parallel.
● Account-based profitability analysis is the default solution in SAP Accounting powered by
HANA. You need to perform a test to check if all the functionalities can be used as before in
costing-based CO-PA.
● Fields of account-based CO-PA are not derived subsequently during migration. It can be
used for the next fiscal year in this scenario.

LESSON SUMMARY
Lesson: Customizing Controlling for Account Based CO-PA

Unit 3
Lesson 5
Preparing for Migration Material Ledger
LESSON OBJECTIVES
Material Ledger Configuration
You need to configure the system to migrate to SAP S/4HANA. The material ledger must be
customized.
Material Ledger
● The material ledger is an inventory sub ledger, which is mandatory for SAP S/4HANA
(Simplified Logistics) and must be activated.
● The material ledger uses the currencies defined for the leading ledger in financials.
Separate currency customizing is obsolete.
● Materials not relevant for actual costing (xBEW-MLAST = ‘2’) are no longer valuated in the
ML document tables MLHD, MLIT, MLPP, MLCR and MLCD. Instead, document data is
reconstructed by read access compatibility views based on ACDOCA. All attributes of the
ML data model, relevant for pure inventory sub-ledger functionality, are part of the
ACDOCA table.
Hint:
Actual costing is still an optional business feature and all data handling for
actual costing relevant materials are unchanged in material ledger document
tables (xBEW-MLAST = ‘2’).
● Migration of material ledger is necessary even if SAP S/4HANA Finance is already used in
the legacy system.

Figure 111: Material Ledger Update Document
Actual tables are replaced by compatibility views if price determination 2 - transaction-based
costing is used.
Unlike Greenﬁeld approach (activating Material Ledger transaction codes OMX1 with price
determination 2, OMX2 Deﬁne Material Ledger type, OMX3 Assign Material Ledger type to
valuation area and activate Material Ledger by program CKMLSTART) the Material Ledger will
be activated automatically during migration with this step (if not already active). See note
2332591 - S4TWL - Technical Changes in Material Ledger.
Figure 112: IMG Activity: Migrate Material Ledger Customizing
All customizing settings for the material ledger will be taken over automatically.
Since S/4HANA 1709, there is a new IMG activity "Check Assignment of Material Ledger
Types to Valuation Areas" in order, as the name implies, to check and, if necessary, adjust the
assignments of material ledger types to valuation areas.
Lesson: Preparing for Migration Material Ledger

Key Takeaway Points
● The material ledger tables are not completely obsolete.
● Adopting (migrating) the settings of material ledger customizing is always required in SAP
S/4HANA.
● The Universal Journal in S/4HANA is the material ledger in terms of different valuations
(transfer prices) or different currencies.
● Actual Costing (including Actual Cost Component Split) is still optional and has a simplified
table structure. By activating the material ledger for the controlling area currency
(currency type 20), posting logic in this currency has changed. If a further valuation is
important in addition to a legal valuation, the values after test migration must be checked
exactly.
LESSON SUMMARY

Unit 3
Lesson 6
Preparing for Migration of House Bank
Accounts
LESSON OBJECTIVES
House Bank Configuration
You need to configure the system to migrate to SAP S/4HANA. House bank account must be
used via the SAP NetWeaver business client or the SAP Fiori app. Several settings are
significant for migration.
Figure 113: IMG Activity: Define Number Ranges for Bank Account Technical IDs
Create number range intervals for bank account technical IDs (interval 01 for all company
codes).
Figure 114: IMG Activity: Define Number Ranges for Change Requests
Create number range intervals for change requests used in bank account management
(interval 01 for all company codes).

Figure 115: IMG Activities: Assign Number Ranges and Deﬁne Settings for Bank Account Master Data
A proposal for the classiﬁcation from a project could be: Assign the number ranges from the
previous steps and create at least one account type. You can specify additional account types
depending on the analysis required in reporting for bank master data.
LESSON SUMMARY

Unit 3
Lesson 7
Preparing for Migration of Credit
Management/Trade Finance
LESSON OBJECTIVES
Credit Management Conﬁguration
Trade Finance
Figure 116: Is Trade Finance Relevant to your Conversion?
For more information, see note 2267310 S4TWL - Foreign Trade. Set status Not needed for
migration of ﬁnancial documents to Trade Finance if it is not relevant.
It is also important to check whether third-party foreign trade systems are in use for foreign
trade processes.
Software component SD-FT: Pre-Transition Checks messages:
1. The functionality Legal Control service is active/used. This functionality is not
available in SAP S/4HANA. See Note 2213485.
2. The functionality Letter of Credit is active/used. This functionality is not available in
SAP S/4HANA. See Note 2213485.

3. The functionality Preference Management is active/used. This functionality is not
available in SAP S/4HANA. See Note 2213485.
Credit Management Configuration
You need to configure the system to migrate to SAP S/4HANA. Certain settings are needed
for migrating Credit Management. The need to migrate credit management settings will also
be checked.
Figure 117: Benefits of SAP Credit Management (FIN-FSCM-CR)
The benefits of SAP Credit Management (FIN-FSCM-CR) are as follows:
● Upgrading from basic credit management functionality to advanced automated credit
management processes is easier.
● It has SAP HANA-based reporting and analytics.
● SAP Fiori apps for credit management are a planned future enhancement.
Figure 118: SAP Credit Management

Is Migration of Credit Management Needed?
● Migration is not needed if FI-AR-CR credit management is not use (to check, tables KNKK
and KNKA are empty and transaction code FD32 is not used).
● Migration (conﬁguration data, master data, credit exposure data, and credit decision data)
is needed when using FI-AR-CR credit management. It is an option to activate to FIN-
FSCM-CR SAP credit management in your existing ERP 6.0 landscape before your SAP S/
4HANA migration project, but there are no tools to migrate as they are used with SAP S/
4HANA migration (note 2270544 - S4TWL - Credit Management).
● Migration is not needed if you are already using FIN-FSCM-CR SAP Credit Management.
Figure 119: IMG Activity: Migrate Credit Management Customizing
It is recommended that you migrate Credit Management customizing whether using credit
management or not. Several customizing settings such as create credit segments out of
credit control areas and risk classes out of risk categories are adopted automatically.
Figure 120: Preparation for Credit Management
Preparation steps include the following:
● Deﬁne how credit representative groups (FI-AR-CR) are mapped to credit analyst groups
(FIN-FSCM-CR).
● Map the customer credit group to the customer group.
Lesson: Preparing for Migration of Credit Management/Trade Finance

● Set the default settings for the business partner.
Figure 121: IMG Activity: Check Customizing Settings
There is an automated check application that ensures all relevant settings are checked.
Was ERP SD Revenue Recognition used? The newly available SAP Revenue Accounting and
Reporting functionality should be used instead. There is a migration before conversion
necessary (note 2267342 - S4TWL - ERP SD Revenue Recognition).
LESSON SUMMARY

Unit 3
Learning Assessment
1. The fiscal year variants of productive controlling areas and all their assigned company
codes must be identical.
X True
X False
2. You can introduce a new currency type during conversion.
X True
X False
3. On which levels can the default CO document types be specified?
X A Regular and cross-company posting
X B Currency Type
X C Company Code
X D Controlling business transactions
X E Accounting Principle
4. Which asset accounting configuration step is required?
X A Specify alternative document number ranges for integrated posting.
X B Define a technical clearing account for integrated asset acquisition.
X C Assign accounting principles to all depreciation areas
X D Create transaction types for posting to specific depreciation areas.

5. When activating account-based CO-PA during a migration, the historical data of the
current ﬁscal year are update for CO-PA values.
X True
X False
Unit 3: Learning Assessment

Unit 3
1. The fiscal year variants of productive controlling areas and all their assigned company
codes must be identical.
X True
X False
Correct! The variant code has to be the exact same.
2. You can introduce a new currency type during conversion.
X True
X False
Correct! Introducing new currency types for existing company codes is not currently
possible during a conversion.
3. On which levels can the default CO document types be specified?
X A Regular and cross-company posting
X B Currency Type
X C Company Code
X D Controlling business transactions
X E Accounting Principle
Correct! You can specify different types per company code, business transaction, and on
if it is a inter or intra company code transactions.

4. Which asset accounting configuration step is required?
X A Specify alternative document number ranges for integrated posting.
X B Define a technical clearing account for integrated asset acquisition.
X C Assign accounting principles to all depreciation areas
X D Create transaction types for posting to specific depreciation areas.
Correct! You must assign an accounting principle to each depreciation area through the
ledger group assignment.
5. When activating account-based CO-PA during a migration, the historical data of the
current fiscal year are update for CO-PA values.
X True
X False
Correct! Historic profitability data generation data is not in scope during a conversion.

UNIT 4 Conversion to SAP S/
4HANA
Lesson 1
Migrating to the Universal Journal 112
Lesson 2
Finalizing Migration and Post Processing Business Partner 129
Lesson 3
Performing Post Migration Activities 133
UNIT OBJECTIVES
● Migrate to the Universal Journal
● Finalize the Migration
● Perform Post Migration Activities

Unit 4
Lesson 1
Migrating to the Universal Journal
LESSON OBJECTIVES
Universal Journal Migration
You have conﬁgured the system to meet your requirements and the requirements of SAP S/
4HANA. You now want to understand how the data migration works and be able to perform
the required steps in your system.
Migration
The migration to SAP S/4HANA is SQL-based and cannot be compared to a migration from
classic G/L to new G/L.
Migration Steps
1. Execute migration activity.
2. Display status of activity.
3. Find a solution if there is an error from a note or program, or create a new ticket.
Figure 122: Principle Procedure of any Migration to SAP S/4HANA
The migration customizing menu path as of S/4HANA 1610 or S/4 HANA Finance 1605 now
looks a little diﬀerent compared to the former releases S/4HANA 1511 or S/4 HANA Finance
1503. The basic migration procedure is the same for all migrations to SAP S/4HANA
products.

Figure 123: Migration Monitor
The real migration is now performed by a central monitor transaction. Migration monitor
provides automatic execution of data migration, and ensures the right sequence of migration
activities.
The monitor performs the following:
● Lists all migration runs in the client.
● Covers all information about a data migration within a client.
● Shows logs of manual migration activities (who, what, when).
It is now possible to reset migration at an earlier step, and to re-execute activities.
IMG Activity: Partitioning Universal Journal Entry Line Items Table
The diﬀerence between new G/L and SAP HANA through this activity is as follows:
● New G/L Note 820495:
If the estimation for the largest company code exceeds the above-speciﬁed value of about
500,000 totals records, and/or if you expect more than 10 million total records for the
leading ledger, you should consult SAP Services or get external advice to evaluate
potential performance risks.
● SAP S/4HANA for table ACDOCA determined by a test migration:
Partition ACDOCA only if you expect more than 500 million records. You must partition the
table if you expect to reach 2 billion records. SAP recommends 300 million to 500 million
records as an optimum partition size.
Lesson: Migrating to the Universal Journal

Figure 124: IMG Activity: Regenerate CDS Views and Field Mapping
The transaction regenerates the views for all related applications of table ACDOCA to do the
following:
● Regenerate customer-specific fields in the CDS views.
● Regenerate the mapping of customer-specific fields in the data migration.
● Redirect SELECT-statements from the concerned database tables to the corresponding
compatibility views.
Figure 125: Redirect Select-Statements - Safeguarding Customer Investments
From the perspective of an ABAP program that requires read access, nothing has changed as
SAP provides compatibility views. These compatibility views redirect the select statement to
the new persistency in SAP HANA.
Unit 4: Conversion to SAP S/4HANA

In the example in the ﬁgure, Redirect Select-Statements - Safeguarding Customer
Investments, access to table FAGLFLEXA is redirected through the FGLV_FAGLFLEXA view to
the universal journal table. As a result, custom ABAP programs that read directly from
FAGLFLEXA via select statements continue to run as before and no change is required in the
customer code.
Figure 126: IMG Activity-Analyze Transactional Data
The transaction checks if all documents are complete and correct. If there are errors,
inconsistencies should be cleaned in the productive environment, at least before starting
migration. It is necessary to clarify whether the error is critical or not. For example, a reported
error in Controlling for posted values in the last millennium that are no longer relevant, can be
ignored.
The following are several additional checks for S/4HANA:
● Check open item management between entry view and master data.
● Check amounts between GLT3 and currency customizing (Special Ledger: Preparation for
consolidation).
● Check amounts between FAGLFLEXT and currency customizing (new general ledger totals
table).
● Check amounts between FAGLFLEXA and currency customizing (new general ledger
general ledger view/line items).
● Check amounts between GLT0_BCK and currency customizing (classic general ledger
saved totals table).

Figure 127: Documentation of the 7 Single Steps in the Migration Monitor
Migration Step 1 in the Monitor: Migration Cost Elements
Figure 128: Migration Step Cost Elements in Chart of Accounts
In the new data model, only a single master record, the G/L account, is needed.
You diﬀerentiate between the following G/L account types (GLACCOUNT_TYPE): non-
operating expense or income, primary costs or revenue, secondary costs, and balance sheet
account.
The master data tables SKA1, SKB1, and SKAT are always ﬁlled. With the G/L types, primary
costs or revenue, and secondary costs, the CSK* tables are updated.
Figure 129: Consistency Check of G/L Accounts and Cost Elements During Migration
A typical error message is: Primary cost element XYZ (type 1) not found in chart of accts XYZ.
Example: There is an entry in the CSKA controlling table but no entry in the SKA1 Financial

Accounting table. The CSKA table will no longer be used and serves as the basis for this
migration step. Every inconsistency should be corrected, otherwise there will be a wrong
account type after migration. Cost elements that are not in FI are migrated as secondary cost
G/L accounts.
Migrate secondary cost elements to chart of accounts (GL account tables: SKA1, SKB1 and
SKAT) for all company codes assigned to the controlling area as a complete run or delta run.
There is no need to migrate primary cost elements. All account maintenance in SAP S/
4HANA takes place via GL account transaction (FS00).
Figure 130: Migrate Default Account Assignments
Default assignments are no longer possible on cost center or internal orders. Any legacy
default assignments are migrated automatically by the system to maintain the status quo.
Migrated values are transferred to transaction OKB9 (table TKA3A).
Summarizing the following activities will be performed by migration of all cost elements,
including the following:
1. GCC (Check Consistency of G/L Accounts and Cost Elements)
2. GCM (G/L Account and Cost Element Merge)
3. DAA (Default Assignment for Cost Elements)

Figure 131: Authorizations Migration
Merging cost elements and G/L accounts requires adjustments to authorizations. These are
not migrated automatically.
Current roles with activities such as maintain G/L accounts (transaction code FS00) or
maintain cost elements (transaction codes KA01-KA06) must be checked and changed via
role maintenance (transaction code PFCG).
The necessary authorizations must be validated by the following tests after migration. This is
similar to new G/L migration projects (for example, missing authorizations for ledger and
segments when migrating from classic G/L).
Migration Step 2 in the Monitor: Technical Check of Transactional Data
The system analyzes if all transactional data is complete and correct (migration activities RC1
and RC21). There are several additional checks compared step "Analyze Transactional Data"
before like reconciliation of asset management and material ledger management.
In the reconcile transactional data activity, the system performs the following checks:
● Zero balance compliance and that all line items have corresponding document headers in
FI/CO.
● Is clearing information missing?
● Does currency information of the documents match the currency customizing?
● Missing or duplicated entries in backup-index tables.
● Open item ﬂag of master data to transactional data.
In real projects with mass data from large time periods, there are many errors that need to be
classiﬁed and corrected.
These all are technical checks in addition to the reports mentioned in the preparation phase.

Migration Step 3 in the Monitor: Material Ledger Migration
The migration of the Material Ledger is needed to use SAP S/4HANA Materials Management -
Inventory Management (Simplified Logistics).
The following steps are performed during migration:
● M10 (Migrate material ledger master data)
● M11 (Migrate material ledger order history)
● M20 (Check material ledger master data)
● M21 (Check material ledger production order and purchase order history.
Actual costing is still optional in S/4HANA and will not be activated automatically during
migration. However, if actual costing is already used in the source system, material ledger
data will be transferred to the new data structure to enable a much faster cost calculation.
Migration Step 4 in the Monitor: Enrichment of Data
The following are examples of data enrichment (ENR Enrich transactional data) fills:
● BSEG-fields from BKPF (table BSEG for line items contains typical header fields now as
well)
● COEP from COBK and OBJNR (table COEP for line items contains typical header fields now
too)
● Profit center fields into CO line items
● Company code data into old CO line items
● BSEG_ADD from FAGLBSIS/AS
● Valuation differences for different other currencies.
The check of migration (R22 Check Enrichment of transactional data) documents if all
documents are correctly enriched.
Both steps should be complete, even for clients that do not have transaction data.
Migration Step 5 in the Monitor: Migration of Line Items (Filling the Universal Journal)
The universal journal (table ACDOCA) is filled in this activity.
The document is called Universal journal entry (UJE) and combines the transactional data of
the applications FI, FI-GL, CO, ML and FI-AA. If active, it is enhanced by characteristics of
It is important to understand how different documents from different applications are
migrated to a single document in table ACDOCA (Table BSEG does not change).
In IMG activity, Check Migration of Accounting Documents to Universal Journal Entry, the
system checks if all accounting documents have been migrated correctly. For example,
results from CDS-views of asset accounting are compared to the original values of obsolete
asset accounting tables ANL*.

Figure 132: Document Migration Starting Point
Where the universal journal gets its data to be updated might differ. You can have the
following options:
● G/L lines without sub-ledger details
● Sub ledger lines in CO and asset accounting
● G/L lines that relate to sub ledger lines. The relationship is one of the following:
- 1:1 - one to one relationship
- 1:n - one to many relationship due to aggregation in the general ledger
- Many to many relationship from different aggregation levels from the different
components
Figure 133: Migration of Line Items in a 1:1 Relationship - Example
The figure, Migration of Line Items in a 1:1 Relationship - Example, shows how the yellow bars
show the information written in BSEG from the FI document and the green bars show the

information that is taken from the CO document. In the end, the universal document has three
line items, the same as the Prima Nota and original FI document and compared to the two line
items of the CO document. The three line items include the information gathered from the FI
and the CO line items.
Figure 134: Migration of Line Items in a 1:n Relationship - Example
In a one to many n relation, as the ﬁgure, Migration of Line Items in a 1:n Relationship -
Example, shows, for example a legacy accounting document with fewer lines than the prima
nota, the universal journal updates separate lines from the CO application directly. Therefore,
in this case, we have two line items in FI and three line items in CO. The corresponding uniﬁed
document has four line items: the three line items from CO and the closing credit line item
from FI.

Figure 135: Migration of Line Items in an m:n Relationship - Example
It is complicated when you have a many to many relationship.
As you can see in the figure, Migration of Line Items in an m:n Relationship - Example, in the
example of the Prima Nota, a purchase order, has different cost center and order values for
each line item.
This has translated in the legacy system to a document in FI where the PO number and PO
position was updated and three line items are posted (the credit of 270 is missing) and a CO
document with the cost center and order information in two additional line items.
In the universal journal, an entry is created with five line items to maintain all the information.
The two line items are directly from the FI, the other two line items are directly from CO, and
the closing item closes both the FI and CO document part separately. As a whole, the
document seems to have a debit balance. This is only the case in the table and all reports
display correctly.
Migration to the Universal Journal includes the following steps:
● MUJ (Data Migration into Universal Journal: Line Items)
● R23 (Check Migration of Journal Entry)
Migration Step 6 in the Monitor: Migration of Balances
The balance totals are the basis for audited statements and not the line items. Totals are
calculated by aggregating line items in SAP S/4HANA. There can be differences between the
sums of migrated line items and the original totals (historic line items may be archived or as a
result of a conversion).
The migrate balances activity (DLT Data migration to the universal journal entry: Deltas for
Totals) posts a delta on the level of G/L totals as a difference between the sum of line items to
balances carried forward. It is the same for Controlling and Material Ledger (if these are not
active, the totals of material inventory contain local currency only). In the end, migrated line
items plus balance adjustments from migration equal the original totals.

Figure 136: Overview Migration Balances
You migrate balances based on the delta values from the ledger totals and the line items of
BSEG and FAGLFLEXA. For CO, it is again the delta of the CO totals to the line items plus the
aggregate values of the line items. For material inventory totals, only the balances are
migrated.
Other reasons for differences can be archived documents, sub-ledger postings such as CO-
internal clearing without real-time integration FI or changed transaction data by customer-
specific programs.
Beside the special status of these corrections (ACDOCA-BSTAT = C) it is possible to see the
component from which the difference arose (ACDOCA-MIG_SOURCE is A from FI-AA, C from
CO and F or G from new Gl or classic GL).
Balance Carry Forward Entries in SAP S/4HANA
● Old balance carry forward entries (FAGLFLEXT or GLT0):
- Are stored in table FAGLFLEXT_BCK or GLT0_BCK.
- Sample for delta general ledger totals: table ACDOCA is filled with all delta data, for
example, from archived documents. The entries are made with a special document
number (starting with a letter) and do not show up in line item reports.
● New balance carry forward entries are updated and stored in table ACDOCA as line items
ACDOCA-BSTAT=C Balance Carryforward and Balance Adjustments from Migration
(transaction code FAGLGVTR).
● New balance carry forward entries for customer and vendors are calculated on-the-fly
(transaction code F.07).
The activity Check Migration of Balances (R24) checks if all balances have been migrated
correctly using compatibility views, regardless of whether there are some fields with the same
entries and the same values. If there are inconsistencies between aggregates from different
applications, the system ensures total equality for FI-GL.

The system takes the cost center from Controlling and does not reconcile this field with FI.
Controlling takes the lead here. The system also takes amounts from the ML and does not
reconcile this field with FI.
No differences are shown if values are archived in one application but not in another.
Migration Step 7 in the Monitor: Calculation of Depreciation and Total Values
Planned depreciation is determined with each master record change and with each posting on
the asset and is updated in database accordingly.
The depreciation run adopts planned asset values and posts them. The posting document is
updated at asset level.
The calculation of the planned depreciation remains as before, but values are stored in
another table. This is the new standard program (FAA_DEPRECIATION_CALCULATE) to
recalculate values.
This is the initial calculation of depreciation values and total values (AFA Initial Depreciation
Calculation and R25 Check Initial Depreciation Calculation).
The program can be executed according to time and resource restraints later, but it is
important that it runs before the first depreciation run.
Figure 137: After all these Explanations the Migration Starts
The migration monitor is helpful because of the following:
● Enable a One Click Migration
● Provides an overview of the status of the migration
● Ensures the execution of the migration steps in the correct order
● Supports error analysis

Figure 138: Migration Monitor Shows Errors
It is possible to reset, repeat and reschedule activities.
Data migration will stop in case of errors. It is necessary to correct or accept errors. This is
the diﬀerence, as opposed to, a new G/L migration, where all errors must be corrected. Use
set halt to stop migration at a certain step. Use next activity and start to repeat the same
activity. The reset and repetition of migration steps in the monitor will be done automatically
while using this button. There is no need to start separate programs to reset line item
migration, or to reset aggregate deltas and to set status of packages. All runs are stored
together with the logs in diﬀerent run Id's behind every step.
In the meantime, it is possible to terminate a job at runtime by setting the number of "Target
Number of Jobs" to 0. This option is not visible on the slide because the two buttons for
increasing or decreasing the number of jobs are only shown at runtime.
Figure 139: Accepting Uncritical Errors

Hint:
Due to the already implemented S/4HANA software, this error in the preparation
of the training system can not be easily corrected. Normally, all previous years
must be completed in Asset Accounting. This error will be used to show how to
accept errors.
Figure 140: Classify Errors
It is important to determine the message number of an error FINS_RECONXXX.
Figure 141: IMG Activity: Migrate General Ledger Allocations
Allocations for proﬁt centers, segments, and so on, in new G/L are based on the totals tables
FAGLFLEXT. There are no allocations for classic G/L. Existing allocations must be migrated to
the CDS View ACDOCT Deprecated - Totals Compatibility View on ACDOCA.

Figure 142: IMG Activity: Migrate House Banks Accounts
House banks are no longer customizing objects. Migration is necessary to migrate these to
separate bank account master data (from table T012K to FCLM_BAM_ACLINK2). House
banks can be used in Bank Account Management Lite if not using new Cash Management or
in Bank Account Management if using new Cash Management (SAP Note 2243324).
House banks are maintained in the new transaction code FI12_HBANK. Bank accounts
(known as Account IDs) must be maintained through a web-dynpro via SAP NetWeaver
Business Client (roles SAP_FI_BL_BANK_MASTER_DATA or SAP_BR_AP_ACCOUNTANT) or
via the SAP Fiori app.
Check transaction code SLG1 when there are errors with the house bank migration. There
might be errors even status is green.
Figure 143: Overview of Bank Structure and Bank Accounts
In SAP S/4HANA, use the Bank Structure and Bank Accounts overview report.

Figure 144: Bank Account Management via SAP Fiori App or SAP NetWeaver Business Client
Bank Account Management is possible with the SAP Business Client or by using the relevant
SAP Fiori apps.
Figure 145: Credit Management Migration
If Credit Management is to be used, you must start and check all steps sequentially. It is not
possible to change these steps.
LESSON SUMMARY

Unit 4
Lesson 2
Finalizing Migration and Post Processing
Business Partner
LESSON OBJECTIVES
Migration Finalization
You have completed the migration to the universal journal and now want to ﬁnalize the
migration to SAP S/4HANA.
Figure 146: Migration Runs
You can use the migration monitor: transaction code FINS_MIG_STATUS.
This is the time at which the business department must again create all the lists in the same
way as before migration.
After comparing the values, the business department normally releases the system at the end
of the migration.

Figure 147: Display Logs - Information
Before posting can be created, migration must be set as completed. Completed migration
implies the following:
● Customizing is consistent (program FINS_CUST_CONSISTENCY_CHECK).
● All views are generated successfully and all redirects are set.
● The migration took place and the amount of data in the universal journal is reasonable.
● All packages have been processed and no error occurred. All messages have been
accepted.
● The migration ﬁnished switch will be logged.
Figure 148: Important Note and Program for all Conversion Projects
Migration Finalization Continued
Comparisons and reconciliations should be performed in the same way as before.
Business departments must be involved before setting migration to complete, to compare
and to conﬁrm that the migration has been performed successfully and correctly.

After setting the migration to completed, postings are possible again.
Figure 149: Check Number Ranges for Customer / Vendor Account Groups (FI and Logistics)
The customer/vendor numeric number ranges must be set to external to allow identical
numbers for customer/vendor and business partner.
Another option is to further assign the customer and vendor number independently of the
business partner number internally.
Figure 150: Check Number Ranges for Customer / Vendor BP-Roles
After a successful data synchronization, the numeric intervals of the business partner can be
changed to internal. Set the last numbers from tables KNA1 (Customer) and LFA1 (Vendors).
Lesson: Finalizing Migration and Post Processing Business Partner

Figure 151: Business Partner Mapping Tasks: Business Partner to Connecting Customers and Vendors (if Not
Already Done in the Preparation)
This is the opposite direction to that used during the migration.
Figure 152: Creating Business Partner (Transaction Code BP)
Use the transaction BP to create, maintain, and display customers and vendors.
The Importance of a Good Test Environment
● There should be at least one correct and complete migrated system for testing purposes
after migration. This is particularly important for new topics such as the following:
- New asset accounting
- Customer vendor integration
LESSON SUMMARY

Unit 4
Lesson 3
Performing Post Migration Activities
LESSON OBJECTIVES
Post Migration Activities
You want to understand and be able to perform activities that can be done after migration is
set to complete.
Activities after Migration
● The post-migration activities can only start after the migration is set to complete.
● We recommend that they are executed during system downtime but you can also execute
them at a later stage.
● The activities include the following:
- Transfer of application indexes to cold storage (data aging)
- Fill due dates in FI documents
- Fill the oﬀsetting account in FI documents
Figure 153: IMG Activity: Transfer Application Indexes (Data Aging)
● Application indexes that correspond to already archived documents are stored in tables
BSIS_BCK, BSAS_BCK, BSID_BCK, BSAD_BCK, BSIK_BCK, BSAK_BCK, FAGLBSIS_BCK,
and FAGLBSAS_BCK.
● This program transfers these table entries into the historic area of the database.
● Data aging is used to move closed objects from a hot partition to cold partition(s).

Figure 154: Database Footprint Reduction in SAP S/4HANA (Theoretical Model)
An SAP S/4 HANA system requires a lot less data volume than a traditional system. This is
achieved through aggressive data compression, system architecture simpliﬁcation, and
historic data aging.
Figure 155: Partitioning by Application-Deﬁned Temperature

Figure 156: Data Aging for SAP Business Suite on HANA and SAP S/4HANA
Data aging is a business data management concept for reducing the SAP HANA memory
footprint. Only operational (current) data is loaded into SAP HANA main memory. Non-
operations (historical) data remains primarily stored on disk, it does not aﬀect current data
performance, and it remains accessible via SQL on request.
Figure 157: Data Management Strategy: Data Archiving and Data Aging
Lesson: Performing Post Migration Activities

Figure 158: Fill Due Dates in FI Documents
The system calculates the net due date and the discount due dates and stores them in the
document tables BSEG (document line items), BSEG_ADD (New G/L), VBSEGD, VBSEGK,
and VBSEGS (parked documents) to ensure high-performance reporting on open items. The
fields maintained are: Due date for discount 1 and 2, and Additional Net due Date.
Figure 159: Update Offsetting Account
This report fills the following fields in tables BSEG and BSEG_ADD accordingly to the
customizing setting:
● Offsetting Account Number (Field GKONT)
● Offsetting Account Type (Field GKART)
● G/L Account of Offsetting Acct in General Ledger Accounting (Field GHKON)
Number of Test Migrations
The number can be larger than expected. The first indicator here is rather the migration
in the sandbox system than the size of the system.
Complexity Of The Settings
Complexity depends on topics like using transfer prices, the quality of data, the number
of used charts of depreciation, and so on. Even a small system can be more complex than
expected.
Industry Solutions and Add-ons

Ensure HANA compatibility with all external applications and add-ons.
Figure 160: Additional Activities
Credit Management and migration of financial documents to Trade Finance have to be set to
completed in additional steps. If you use the Accrual Engine before the ERP system, then this
data must also be migrated afterward.
Figure 161: Enrichment of Balance Carryforward
Migrating to SAP S/4HANA transfers the transferred balances from the totals tables of the
previous system (for example, ECC 6.0). The carried forward balances thus have the same
granularity as before. If the granularity of the balance carried forward is correct, then these
enrichment steps need not be performed. If the balance carried forward for items with open
items should be more detailed. For example, for additional fields or account assignments in
table ACDOCA, it is possible to recalculate the balance carry forward based on the open items
on the last day of the previous fiscal year.
Lesson: Performing Post Migration Activities

Key Takeaway Points
● Migration programs are SQL-based and are much faster to run compared to, for example,
the programs used for migration from classic to new G/L.
● Expectation is that 10 million line items in ACDOCA takes 10 minutes (experience from a
project: step MUJ 540 millions line items ACDOCA in 10 hours)
● The migration programs do not always stop during runtime due to errors. Errors are
collected and shown in logs. In contrast to a migration to new general ledger via service,
certain errors can be accepted during migration.
● The migration transfers data is exactly as it is. The main challenge is data cleansing pre-
migration.
● All solutions (S/4 HANA or S/4 HANA Finance) use the same logic.
LESSON SUMMARY

Unit 4
Learning Assessment
1. It is possible to reset and to re-execute migration activities in the migration cockpit.
X True
X False
2. What does setting the migration to complete mean?
X A All migration packages have been processed and no error occurred.
X B Test posting have already been performed in the production environment.
X C Data aging has been processed for all backup tables.
X D All views are generated successfully and all redirects are set.
3. The system calculates the net due date and the discount due dates for open items and
stores them in the Universal Journal table ACDOCA.
X True
X False
4. After customer vendor integration synchronization, the number intervals of the business
partner should normally be changed from external to internal.
X True
X False

Unit 4
1. It is possible to reset and to re-execute migration activities in the migration cockpit.
X True
X False
Correct! If there are errors in a process step, you can restart it after correcting the
problem.
2. What does setting the migration to complete mean?
X A All migration packages have been processed and no error occurred.
X B Test posting have already been performed in the production environment.
X C Data aging has been processed for all backup tables.
X D All views are generated successfully and all redirects are set.
Correct! Data aging is optional and test postings are never performed in production.
3. The system calculates the net due date and the discount due dates for open items and
stores them in the Universal Journal table ACDOCA.
X True
X False
Correct! The system calculates the net due date and the discount due dates and stores
them in the document tables BSEG (document line items), BSEG_ADD (New G/L),
VBSEGD, VBSEGK, and VBSEGS (parked documents).

4. After customer vendor integration synchronization, the number intervals of the business
partner should normally be changed from external to internal.
X True
X False
Correct! You generally should have internal number range assignment for new business
partners as the business partner is now the leading master data for customers and
suppliers.

UNIT 5 Additional Topics for
Migration
Lesson 1
Explaining Business Downtime Reduction with Near Zero Downtime (NZDT) 143
Lesson 2
Explaining Conversion Results 148
Lesson 3
Using new Asset Accounting 153
UNIT OBJECTIVES
● Explain business downtime reduction with Near Zero Downtime (NZDT)
● Explain the migration results
● Use new Asset Accounting

Unit 5
Lesson 1
Explaining Business Downtime Reduction with
Near Zero Downtime (NZDT)
LESSON OBJECTIVES
Near Zero Downtime
You want to understand the concept of Near Zero Downtime (NZDT) for the productive
migration system.
Figure 162: Near Zero Downtime (NZDT)
The Near Zero Downtime (NZDT) approach allows users to minimize downtime for a S/4
conversion (SAP software upgrade and data migration) for systems with a very high data
volume. It is a project based solution using DMIS add-on from SAP. It requires some
consulting support.
The following steps allow you to minimize the downtime for migration:
1. Create a clone of the productive system.
2. Perform migration on the clone system.
3. Re-sync migrated the clone with the productive system.

The clone system becomes the new productive system.
Figure 163: Migration to SAP S/4HANA with Business Downtime Reduction by Near Zero Downtime (NZDT)
The sequence of steps for migration to SAP S/4HANA include the following:
1. Recording over DB-Triggers.
2. System Cloning and Isolation.
3. Upgrade and Installation of SAP S/4HANA.
4. Initial SAP S/4HANA Migration and Validation.
5. Online delta replay (across releases).
6. Downtime.
a. Oﬄine Delta Replay
b. SAP S/4HANA Migration of Delta
c. Last Transports
d. Infrastructure Change / System Switch
e. Final Validation
Before beginning the cloning process, the following activities must be completed:
Unit 5: Additional Topics for Migration

Figure 164: Activities Before Taking the Clone
Business Restrictions
Business Restrictions During Recording Phase (General)
● No archiving
● No customizing changes
● No changes in repository
● No postings in closed periods
● No profit center changes
Business Restrictions During Recording Phase (Asset Account Specific)
● No legacy data transfer for asset data (for example, transaction AS91)
● No asset depreciation postings with old depreciation report RABUCH
● No year-end closing activities FI-AA (transactions AJRW, and AJAB)
● No data corrections in asset accounting using any of the reports starting with RACORR*
● Closed fiscal years are not allowed to be re-opened
See SAP Note 2309893 Near Zero Downtime method for migration to S/4HANA and S/
4HANA Finance. For general information, see note 693168 - Minimized Downtime Service
(MDS).
Lesson: Explaining Business Downtime Reduction with Near Zero Downtime (NZDT)

Figure 165: Steps in More Detail
Figure 166: Downtime Activities in more Detail (step 6)

Figure 167: SAP S/4HANA Delta Migration (step 6)
Key Takeaway Points
The following are key takeaway points:
● The downtime for software upgrade to SAP S/4HANA and migration can be minimized by
the Near Zero Downtime approach.
● Time expenditure for the data comparison is higher.
● It can continue to post in the productive system while an upgrade and the initial data
migration is running on a clone. Once the initial data migration has been completed and
checked, a short downtime is necessary in the productive system in order to migrate the
rest of the data and complete the upgrade.
● The NZDT service enables S/4HANA conversions for customers with exceptionally
complex and critical conversion requirements.
LESSON SUMMARY
Lesson: Explaining Business Downtime Reduction with Near Zero Downtime (NZDT)

Unit 5
Lesson 2
Explaining Conversion Results
LESSON OBJECTIVES
Migration Results
After migration, you would like to check the changed transactions and processes in the
system.
Figure 168: Multi-Dimensional Reporting in the Balance Sheet
Optimized Transactions
The following are Optimized Transactions:
● Vendor line items: FBL1H (FBL1N can still be used)
● Customer line items: FBL5H (FBL5N can still be used)
● Line item display G/L: FBL3H, FAGLL03H
● Settlement (Plant Selection) CO88H
● Settlement (Make-to-Order Sales Orders) VA88H
● Settlement (Internal Orders) KO8GH
● Settlement (Projects) CJ8GH
● Results Analysis KKAKH (POC method or revenue-based)
● WIP Calculation at Actual Costs KKAOH

● Variance Calculation w/ Full Settlement KKS1H
● Variance Calculation for Cost Centers KSS1H
Figure 169: New User Interface: SAP Fiori Apps
The following are the features of the new user interface of the SAP Fiori apps:
● Easy to-use screens
● Most common ﬁnance transactions and reports can be executed via SAP Fiori Apps.
Examples for G/L Accountant include the following:
- Post G/L Document (FB50)
- FinDoc Display, Change, Reverse (FB03, FB02, FB08)
● The following are examples for A/P Accountant:
- Post Invoice without PO (FB60)
- Create Single Payment (F-53)
- Create and Revise Payment Proposal (F110, FBZ0)
● Examples for A/R Accountant include the following:
- Manual Clearing (FB05)
Lesson: Explaining Conversion Results

Figure 170: Sample for Process Improvement: Intercompany Reconciliation on-the-Fly
The reduced time to close books is the result of the following:
● Accelerated automated matching
● No more batch jobs, real time analysis supports continuous intra-period process execution
● Improved user experience and enhanced data drill down
● Better process oversight through new management dashboard
Figure 171: Process Improvements New Cost of Goods Sold (COGS) and WIP Analysis

Figure 172: SAP Fiori KPI Apps and Dashboards
The ﬁgure, SAP Fiori KPI Apps and Dashboards, shows objects that require the new data
model to work.
Figure 173: Simulations, Performance and Radical Redesign of Processes
Innovations and beneﬁts of the Universal Journal in SAP S/4HANA
● Harmonization of internal and external accounting (FI, Asset Accounting, Controlling,
Material Ledger and account based CO-PA).
Lesson: Explaining Conversion Results

● All reporting runs from a single set of data on the line item level providing a single point of
truth for Financials. SAP Hana Views on-the-Fly. No more materialized aggregates and
indices.
● Reporting across diﬀerent applications is now possible.
● Allows new reporting options connecting legal aspects, responsibilities, and market view.
● The new concept reduces reconciliation eﬀort and helps to achieve the full capabilities of
LESSON SUMMARY

Unit 5
Lesson 3
Using new Asset Accounting
LESSON OBJECTIVES
Understand the Architecture of Asset Accounting in SAP S/4HANA
Scenario
You want to understand and use the posting logic in asset accounting. You also want to know
the beneﬁts that implementing asset accounting brings to your end-users.
Figure 174: Technical Changes to Tables
New Asset Accounting is the only asset accounting solution in SAP Accounting on SAP HANA.
Classic Asset Accounting is no longer available. Conﬁguration and activation is on the client
level. Both multiple valuation approaches are possible: Ledger Approach and Account
Approach. Usage of the new Depreciation Calculation Engine is mandatory (based of
extension EA-FIN Note:1498047).
Actual items include the following:
● Actual data of ANEP, ANEA, ANLP, ANLC is now stored in table ACDOCA. ANEK data is
stored in BKPF.
● Compatibility views FAAV_<TABLENAME> (that is, FAAV_ANEK) are provided to enable
non-disruptive reporting on old tables.
After migration, access to the content of old tables is still possible via views
FAAV_<tablename>_ORI.
Non-actual items include the following:

● Statistical Line Items in Asset Accounting (for example, calculation for tax purposes) are
now stored in table FAAT_DOC_IT.
● Planned Depreciations and Revaluations (previously ANLP and ANLC) are now stored in
FAAT_PLAN_VALUES.
● Year-dependent attributes for depreciation are now stored in FAAT_YDDA.
● Benefits from the Universal Journal integration.
The Universal Journal integration provides the following benefits:
● No redundancy in data storage.
● Reconciliation between G/L and AA is ensured by design.
● No reconciliation step in financial close required.
● All non-statistical items are updated as Universal Journal entries.
● Reporting for previous fiscal years is possible due to compatibility views even after
migration.
● Transparent assignment of depreciation area to accounting principle.
● Depreciation posted with all details: accumulated depreciation and depreciation cost by
asset.
Figure 175: Benefits from Posting Logic Simplification
The simplification of posting logic provides the following benefits:
● Auditability and simplicity
Independent and complete depreciation areas of equal power.
● Simplified Chart of Depreciation

Only one depreciation area per valuation necessary. No further depreciation areas (delta
areas) are necessary to portray a parallel valuation.
● New document display
Detailed impact of any transaction to the books.
● New transactions for ledger group (depreciation area) specific documents.
● Flexible account determination.
● Simple close, fast close, soft close.
● Transparency throughout the period.
● Asset balances in real time - APC posting run no longer required.
● Plan values in real-time - updated with every master data change and every asset
transaction.
● Elimination of reconciliation steps.
● Fast depreciation posting run due to simple processing logic, new data structures and
parallel processing.
● Navigation and drilldown per accounting principle.
● Posting to different periods possible.
Restriction: The beginning and end of the fiscal years must equal.
Explain the Posting Logic in Asset Accounting
Figure 176: Example: Integrated Acquisition with Different Amounts per Accounting Principle
For an integrated asset acquisition posting, the system divides the business transaction into
an operational part and a valuating part. For the operational part (vendor invoice), the system
makes a posting to all ledger groups against the technical clearing account for integrated
asset acquisitions. For the valuating part (asset posting with asset capitalization), the system
generates ledger-group-specific documents that it also posts against the technical clearing
account for integrated asset acquisitions.
For each ledger group that is assigned in your chart of depreciation, the system creates a
corresponding ledger-group-specific document. In this way, the system ensures that the
Lesson: Using new Asset Accounting

technical clearing account for integrated asset acquisitions has a balance of zero (for each
ledger and account assignment object) for every ledger group assigned in the chart of
depreciation. So the system can ensure the zero balance, manual postings cannot be made to
the account. The account does not appear in the balance sheet, but in the notes to the
financial statement (since it has a zero balance).
Automatic postings are made to the technical clearing account for integrated asset
acquisitions for the following transactions: asset acquisition and investment support
measures.
Figure 177: Sample Posting - Ledger Approach Transaction Vendor Invoice
The ledger approach results in three documents:
● Technical Clearing Account Acquisition (TCA) to Vendor (The Ledger Grp and Account.
Principle fields are blank)
● Asset to TCA (Ledger Grp: 0L and Account. Principle: IFRS)
● Asset to TCA (Ledger Grp: N1 and Account. Principle: LOCA)
Figure 178: Sample Posting - Ledger Approach Transaction Correction Advertising and Sales Costs
To post transactions such as corrections, you no longer need a transaction type limited to
specific depreciation areas.
You can choose the accounting principle or depreciation area (transaction AB01L) directly in
the transaction view.

Figure 179: Sample Posting - Account Approach
For all other depreciation areas that are posted to FI in the accounts approach, the account is
posted to Contra Account: Acquisition Value Posting, which is assigned in the account
determination, instead of the Technical Clearing Account. This approach results in the
following three documents:
● Technical Clearing Account Acquisition (TCA) to Vendor (The Ledger Grp and Account.
Principle fields are blank)
● Asset to TCA (Ledger Grp: 0L and Account. Principle: INT)
● Asset to TCA (Ledger Grp: LO and Account. Principle: LOC)
With an account approach there is only one ledger 0L. The ledger group 0L and LO book in the
leading ledger 0L.
Figure 180: Assets Activated for Specific Accounting Principles
Only relevant accounting principles are represented on the asset (or on the asset class) by
their corresponding depreciation areas.
All postings issued within FIAA affect those accounting principles that are relevant for the
involved assets only.
P&L postings for all other accounting principles can be handled manually by the end user.

If a certain accounting principle is not represented on the asset by an area, which posts APC
online to general ledger, the posting is re-directed to Account for Non-Operating Expense
(field T095-KTNAIB).
If no accounting principle is represented on the asset by an area, which posts APC online to
G/L, the system issues an error. This error notification can be changed into a warning, in
which case the statistical areas in FI-AA are updated.
Figure 181: New Settlement for Assets Under Construction
It is possible to assign the settlement rule for each line per depreciation area posting to the
general ledger (transaction AIAB).
Accounting principle specific postings are also generated from Controlling.
New and Obsolete Programs for FI-AA (New)
● Periodic APC postings: RAPERB200 obsolete and deleted
● Reconciliation postings: RAABST02 obsolete and deleted
● Fiscal Year Chance: RAJAWE00 obsolete and deleted
● Post depreciation RAPOST2000 is replaced by program FAA_DEPRECIATION_POST
For year-end closing, there is no separate balance carry forward needed in asset accounting,
the general balance carry forward transaction of FI transfers asset accounting balances by
default.
The most current planned depreciation values are calculated automatically for the new year
after performing the balance carry forward.
See SAP Note 220832: FAQ for legacy data transfer in SAP_FIN 720 and subsequent
releases.
In the new solution, the master data continues to be created in transaction AS91 and changed
in transaction AS92. However, the takeover values are posted separately in the new posting
transaction ABLDT. When you do this, a posting is made to the transfer clearing account
immediately. In other words, the manual step for the summary write-off is no longer required.
BAPI_FIXEDASSET_OVRTAKE_CREATE and transaction AS100 (which calls the BAPI
internally) have been fully adjusted to the new logic.
Transaction ABLDT uses an input-enabled ALV grid control. Therefore, according to SAP Note
311440, it does not support batch input.

As an alternative, you can use BAPI_FIXEDASSET_OVRTAKE_CREATE. (See SAP Note
2252940.)
In the case of assets under construction (AuCs), you cannot transfer cumulative APC or
accumulated depreciations.
In the manual case, with transaction AB01 (not transaction ABLDT) or, as of SAP Note
2294012, via the new transaction ABLDT_OI.
In the case of a transfer using BAPI_FIXEDASSET_OVRTAKE_CREATE, do not enter the
values into the CUMULATEDVALUES table; enter them into the TRANSACTIONS table
instead.
Figure 182: New Depreciation Run
The determination of the depreciation values of an asset and the posting of depreciation
expense takes place in the system asynchronously as follows:
1. Calculate depreciation
The planned depreciation is determined with each master record change and with each
posting on the asset and updated in the database directly.
2. Post depreciation
The depreciation run adopts the planned asset values and posts them in Financial
Accounting.
Planned depreciation is determined and updated with each asset master record change and
each posting to the asset. The depreciation run posts the precalculated planned values.
The journal entry is updated in ﬁnancials on the asset level.
Period end closing can be performed even if there are errors on individual assets.
A test run can be performed but still with the restriction for 1000 assets.
The Selection view is simpliﬁed as the Reasons for posting run (planned depreciation run,
repeat, restart, unplanned posting run) are no longer relevant.

LESSON SUMMARY

Unit 5
Learning Assessment
1. Using Near-Zero Down Time helps make the conversion to SAP S/4HANA simpler.
X True
X False
2. After conversion, users can continue to use all the previous transactions they are familiar
with.
X True
X False

Unit 5
1. Using Near-Zero Down Time helps make the conversion to SAP S/4HANA simpler.
X True
X False
Correct! Though it might be required for larger customers, it is a more complicated option
for conversions that don’t require it.
2. After conversion, users can continue to use all the previous transactions they are familiar
with.
X True
X False
Correct! Though the conversion is mostly indeed non-disruptive for users, there are some
changes they will need to get familiar with, depending on their legacy system starting
point.

S4F03 Col11 Conversion of Accounting to SAP S/4HANA

More Related Content

Similar to S4F03 Col11 Conversion of Accounting to SAP S/4HANA (20)

More from Libreria ERP (20)

Recently uploaded (20)

S4F03 Col11 Conversion of Accounting to SAP S/4HANA