Professional Documents
Culture Documents
Migration
BIRMINGHAM - MUMBAI
Mastering SAP S/4HANA 1709 –
Strategies for Implementation and
Migration
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in
any form or by any means, without the prior written permission of the publisher, except in the case of brief
quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information
presented. However, the information contained in this book is sold without warranty, either express or
implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any
damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and
products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot
guarantee the accuracy of this information.
ISBN 978-1-78883-933-4
www.packtpub.com
To my father, for everything I am and will be.....I owe it to you.
To my wife, for her inspiration, and to my kids, Nilay and Nivi, for their love.
mapt.io
Mapt is an online digital library that gives you full access to over 5,000 books
and videos, as well as industry leading tools to help you plan your personal
development and advance your career. For more information, please visit our
website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and
Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
At www.PacktPub.com, you can also read a collection of free technical articles, sign
up for a range of free newsletters, and receive exclusive discounts and offers
on Packt books and eBooks.
Contributors
About the author
Nitin Gupta is an IT professional with expertise in SAP solution architecture,
business process transformation, and project management and over 11 years of
experience in managing and delivering complex SAP and transformation
projects resulting in efficiency and productivity. He has successfully led and
managed full lifecycle SAP implementation projects across the globe. He holds
a master's in business administration and is presently based in Auckland.
About the reviewer
Pallavi Gupta is a finance expert with vast experience in SAP. Her expertise
includes SAP Financials and SAP S/4HANA. She is presently working as an
independent consultant on several projects under her own company. She has
excellent interpersonal skills and is involved in several client-facing roles.
She is presently based in Auckland.
Packt is searching for authors like
you
If you're interested in becoming an author for Packt, please visit authors.packtpub
.com and apply today. We have worked with thousands of developers and tech
professionals, just like you, to help them share their insight with the global tech
community. You can make a general application, apply for a specific hot topic
that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Mastering SAP S/4HANA 1709 – Strategies for Implementation and Mi
gration
Dedication
Packt Upsell
Why subscribe?
PacktPub.com
Contributors
About the author
About the reviewer
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the color images
Conventions used
Get in touch
Reviews
1. An Overview of SAP HANA, S/4HANA, and Migration
Technical requirements
In-memory data – a core to SAP HANA
Optimization of in-memory data
Data storage model
Data compression
Delta storage
Data aging
SAP HANA Live
Introduction to SAP S/4HANA
Understanding SAP S/4HANA
The Universal Journal
Compatibility views for historic data
Merging G/L accounts and cost elements
Logistics changes
Changes to material master data
Sales activity
SD rebate processing
Data model changes
Credit management
Introduction to SAP Fiori
What is SAP Fiori?
Key pillars of the Fiori experience
Type of Fiori apps
SAP Fiori Launchpad
SAP Fiori architecture
SAP Fiori business benefits
S/4HANA migration overview
Introduction to migration
Concept of business partners
Customer vendor integration
What is CVI?
Business impact of CVI
CVI conversion scenarios
Summary
Questions
2. Migration to SAP HANA – Tools and the Project
Technical requirements
System migration
SAP homogeneous system copy
Reasons for a homogeneous system copy
SAP heterogeneous system copy
System copy consequences and decision table
Migration check service
Benefits of migration check service
System copy method
Database-specific copy method for Java
SAP migration tools
ABAP OS/DB migration
DB object size calculation with R3SZCHK
JAVA OS/DB migration
System copies – import and export
Software logistics toolset
Software provisioning manager
Target database size
Migration project overview
A sample schedule
SAP OS/DB migration check analysis
SAP OS/DB check verification
Required source system information
Required source system – technical information
Performing a migration test run
Final migration planning
Installing and upgrading
Software update manager
Summary
Questions
3. SAP S/4HANA – Deployment Options
What is deployment?
SAP S/4HANA deployment options
SAP S/4HANA On Premise
SAP S/4HANA on Cloud
Comparing S/4HANA On Premise and On Cloud
Types of cloud
An overview of implementation scenarios
Hybrid model of deployment
Summary
Questions
4. Impact of S/4HANA on the SAP General Ledger
Technical requirements
The history of the General Ledger
An overview of the Classic General Ledger
An overview of the New General Ledger
Features of the New GL
General Ledger in SAP S/4HANA
Data structure of GL in SAP S/4HANA
Universal Journal
Ledgers and currencies
GL account and cost elements
Changes to transactions and search options
Customizing the SAP General Ledger
Activating SAP Reference IMG
Checking and adopting Fiscal year variants
Migrating General Ledger customizations
Defining settings for the Journal Entry Ledger
Defining ledger groups
Assigning the accounting principle to the ledger group
Defining a ledger for Controlling
Defining document types for posting to Controlling
Defining the document type mapping variant
Defining default values for posting in Controlling
Defining the offsetting account determination type
Defining the source ledger for migration of balances
Executing the consistency check for the General Ledger
Activating business functions
Summary
Questions
5. Impact of S/4HANA on SAP Controlling and Profitability Analysis
Technical requirements
An introduction to SAP Profitability Analysis (CO-PA)
Usage of COPA
Methods of profitability management
Methods of Profitability Analysis in SAP
Aspects in SAP profitability management and organization units involved
Comparative analysis of various methods
Types of CO-PA
Account-based COPA
Costing-based COPA
Differences between account-based and cost-based COPA
COPA in SAP S/4HANA
Integration of Account-based CO-PA to Universal Journal
Attributed profitability segments
Realignment in CO-PA with SAP S/4HANA
Characteristics that cannot be changed
Characteristics that can be changed freely
Characteristics that can be changed only if the account assignment
is not true
Characteristics that are changeable if the field is initial at the
time for execution of realignment
Reporting options in CO-PA with SAP S/4HANA
The Fiori app
Analysis for Office
HANA Live
COGS split in S/4HANA-based CO-PA
Defining accounts for splitting COGS
Defining additional quantity fields
Defining accounts for Splitting Price Differences
Material Ledger in SAP S/4HANA
Significant changes in Controlling in SAP S/4HANA
Changes in transactions
Changes in tables
Changes in configuration
Configuration of the document type for CO
Maintaining document-type mapping for CO transactions
Checking and defining default values for posting in Controlling
Maintaining version for the ledgers
Summary
Questions
6. Impact of S/4HANA on SAP Asset Accounting
Technical requirements
An overview of SAP Asset Accounting
Features of SAP Asset Accounting
Organizational units in Asset Accounting
Charts of depreciation
Integration components
Integrating with Controlling
Integrating with General Ledger (FI)
Integrating with Material Management (MM)
Asset classes and their components
An introduction to New Asset Accounting
Key changes in New Asset Accounting
Changes to transaction codes
An introduction to the Technical Clearing Account (TCA)
Changes to AuC and Transaction Types
Posting to the Universal Journal
New depreciation-calculation engine
Depreciation areas and ledgers
Data migration in New Asset Accounting
Summary
Questions
7. S/4HANA New Functionalities – Cash Management, BPC, and Fiori UX
Technical requirements
Introduction to Bank Account Management (BAM)
Solution overview
Redesigned approach in SAP S/4HANA
Configuration
Maintaining number ranges for bank account technical IDs
Maintaining bank account types
Configuring enable payment approval process
Configuring payment signatories
Configuring cash pool for cash concentration
Existing options for extensibility
ICF services
BAM and BAM Lite
Introduction to Cash Management
Prerequisite check
Master Data set up
Bank statement processing
Manage cash operations
One Exposure from Operations
Introduction to BPC
What's new in this area?
Before and after S/4HANA comparison
Applications used
Components supported
How data flows
Authorizations
Planning modeler
Introduction to Fiori
Summary
Questions
8. Overview of Implementation Scenarios
Technical requirements
Available implementation scenarios
New implementation
Duration of the new implementation
Approach in new implementation
Data migration
System conversion
How to plan a migration project?
Key performance indicators (KPIs) in migration
Landscape transformation
Benefits of landscape transformation
Characteristics of SAP S/4HANA landscape transformation projects
System landscape transformation (SLT)
Preconfigured solutions
Available consolidation scenarios
Migration of business units
Migration of selected applications (central finance)
Elements of central finance
Central finance replication model
Solution methodology – central finance
Summary
Questions
9. Period End Closing in SAP S/4HANA
Technical requirements
Closing activities
Month-end closing
Year-end closing
Reporting with SAP S/4HANA
Financial statement versions
Reporting options in SAP S/4HANA
Closing Cockpit in SAP S/4HANA
Closing Cockpit usage scenarios
Closing Cockpit configuration
Creating a template
Creating tasks
 Defining the Dependencies and Create Task Lists
Releasing the Task List
Checking dependencies
Executing dependencies
Process control
Summary
Questions
10. Premigration Activities
Technical requirements
Preparation for migration
Prechecks in migration
Preparation and migration of customizing for General Ledger
Activating SAP Reference IMG
Checking and adopting Fiscal year variants
Migrating General Ledger customization
Defining settings for the Journal Entry Ledger
Defining ledger groups
Assigning accounting principles to the ledger group
Defining the ledger for controlling
Defining document types for posting to controlling
Defining document type mapping variant
Defining default values for posting in controlling
Defining the offsetting account-determination type
Defining the source ledger for the migration of balances
Executing consistency checks for General Ledger
Activating the business functions
Preparing and migrating customization of Asset Accounting
Preparing and migrating customization of controlling
Preparing and migrating the Material Ledger customization
Preparing and migrating the House Bank accounts customization
Preparing and migrating the Credit Management customization
Summary
Questions
11. Migration Activities
Technical requirements
Data migration
Partition of Universal JE Line Items
Regenerating CDS views and field mapping
Analyzing transaction data and status display
Starting and monitoring data migration
Overview tab
Migration runs
Status of migration run
Control tab
Tables tab
Migration of cost elements
Technical check of transactional data
Material Ledger migration
Enrichment of data
Migration of line items
Migration of balances
Calculation of depreciation and total values
Migrating General Ledger allocations
How to do it?
Migrating house bank accounts
Migrating Credit Management
Migrating Credit Management Master Data and status display
Migrating Credit Management exposure and status display
Initializing Documented Credit Decisions (DCD) and status display
Reconciling Documented Credit Decisions (DCD)
Completing migration
Reconciling and comparing migrated data
Setting migration to complete
Summary
Questions
12. Post-Migration Activities
Technical requirements
Activities after migration
Running reconciliation reports
Business process validation
Transferring application indexes and displaying the status
Filling due dates in FI documents and the display status
Filling offsetting accounts in FI documents
Enrichment of balance carryforward
Settings for enrichment of balance carryforward
Reconciling the balance with line items and displaying reconciliat
ion status
Specifications for Balance Sheet and P&L accounts
Enriching balance carryforward based on line items
Manual activities for credit management
Completing a credit management migration for unmigrated customers
Deactivating the reconciliation ledger
After migration testing
Testing HANA-optimized reports
Testing reporting
Testing database usage
Testing intercompany reconciliation
Testing Universal Journal and the closing process
Summary
Questions
13. Central Finance – a No-Disruption Approach
Technical requirements
An overview of SAP Central Finance
Understanding Central Finance
Key business benefits and use cases
Central Finance process use cases
Key limitations
Short-life master data
Fixed assets
Inventory
Logistics documents
Costing-based COPA
Document-splitting
Profit-center-only postings
Central Finance architecture
Source system
System Landscape Transformation
SAP Master Data Governance (MDG)
S/4HANA system  
Application Interface Framework (AIF)
Central Finance interfaces
Central Finance mapping 
Initial load and real-time replication
System configuration 
Source system 
System Landscape Transformation (SLT) 
Defining objects
Defining the initial load object
Defining the replication object
Activating the Initial Load and Replication Objects
Control Load/Replication using the SAP LT Replication Server
S/4HANA system
Configuring the SAP Application Interface Framework (AIF)
Clearing Functionality
Central Payments
Business benefits of Central Payment
Configuring Central Payment
Managing cost-based COPA in SAP Central Finance
Summary
Questions
14. Greenfield Implementation
Technical requirements
Greenfield implementation
ASAP methodology
The key benefits of the ASAP methodology
Phases of the ASAP methodology
Agile ASAP 8 methodology
SAP Activate
Pillars of SAP Activate
SAP Best Practices
Guided configuration
Methodology
SAP Activate methodology's features
Activate methodology key characteristics
The Activate methodology structure
Governance, roles, and responsibilities
Activate journey – new implementation (cloud)
Activate journey – new implementation (premise)
Activate journey – system conversion
Differences between SAP Launch, ASAP, and SAP Activate
Summary
Questions
15. The Near Zero Downtime (NZDT) Strategy
Technical requirements
The Near Zero Downtime strategy
Summary
Questions
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
If you look on the internet, you will find that SAP is one of the blooming areas
in technology, and with the introduction of SAP S/4HANA, the processes and
organizations are going through major changes. Millions of jobs are available;
however, the skill set is limited as the product is new and is still evolving. The
content is scattered across areas such as logistics, Central Finance, changes
with S/4HANA, Closing Cockpit, and migration steps. You can find these
areas in several books covered in several ways, so what is it that this book
offers that's different?
This book is the one-stop shop for all these areas. You will find an end-to-end
overview of the processes, changes, simplifications, deployment options, and
configuration of all the relevant areas, including, but not limited to, SLT,
Central Finance, New Asset Accounting, and Fiori tiles.
Who this book is for
This book will work as a guide to those who have SAP project experience and
are looking to learn more about SAP S/4HANA, such as functional consultants,
integration experts, project managers, design leads, and solution architects.
Also, people who are new to SAP S/4HANA can start with this book.
What this book covers
This books is purely focused on SAP S/4HANA innovations, and also gives a
background of how the process was handled before SAP S/4HANA within
SAP itself. It covers the following areas:
Chapter 1, An Overview of SAP HANA, S/4HANA, and Migration, helps you get
into the topic. You will understand the journey and path of innovation, starting
from HANA and then moving to S/4HANA. This will set the stage for the rest
of the chapters.
Chapter 10, Premigration Activities, helps you learn about the preparatory
activities involved in migration.
Chapter 14, Greenfield Implementation, is the best way to learn about SAP
activate in detail. This chapter will guide through the methodology and how it
differs from the previous SAP implementation methodologies.
, The Near Zero Downtime (NZDT) Strategy, is a small chapter that
Chapter 15
guides the readers through the core features of NZDT and explains how it can
be used to reduce the downtime during migration.
To get the most out of this book
In order to use this as the best method for learning, ensure that you understand
the key SAP terms, processes, and organization structure in SAP. Although it is
not expected that you should be aware of all SAP ECC configurations in
advance, if you know them and have previously used them in your projects,
that's excellent.
When you are learning the configuration chapters, have the system ready
(maybe DEMO system) so that you can follow the instructions and get the
correct results.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams
used in this book. You can download it here: https://www.packtpub.com/sites/default
/files/downloads/MasteringSAPS4HANA1709StrategiesforImplementationandMigration_ColorImage
.
s.pdf
Conventions used
There are a number of text conventions used throughout this book.
Bold: Indicates a new term, an important word, or words that you see
onscreen. For example, words in menus or dialog boxes appear in the text like
this. Here is an example: "SPRO | Financial Supply Chain Management | Cash
and Liquidity Management | Bank Account Management | Basic Settings."
Warnings or important notes appear like this.
General feedback: Email feedback@packtpub.com and mention the book title in the
subject of your message. If you have questions about any aspect of this book,
please email us at questions@packtpub.com.
Errata: Although we have taken every care to ensure the accuracy of our
content, mistakes do happen. If you have found a mistake in this book, we
would be grateful if you would report this to us. Please visit www.packtpub.com/sub
mit-errata, selecting your book, clicking on the Errata Submission Form link,
and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the
Internet, we would be grateful if you would provide us with the location
address or website name. Please contact us at copyright@packtpub.com with a link
to the material.
If you are interested in becoming an author: If there is a topic that you have
expertise in and you are interested in either writing or contributing to a book,
please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave
a review on the site that you purchased it from? Potential readers can then see
and use your unbiased opinion to make purchase decisions, we at Packt can
understand what you think about our products, and our authors can see your
feedback on their book. Thank you!
In-memory data
Optimization of in-memory data
Delta storage:
Technical requirements
For this chapter, the following are required:
The hard disks are cheap and affordable and are at the lowest space in the
consequential structure, but the key to this entire process of in-memory data
modeling is performance. In the following figure, if we move from top to
bottom, it shows a higher latency with lower price, and if we move vice versa,
it depicts a higher performance:
All traditional database management systems use the disk as a primary storage
and the main memory is used as just a buffer.
Optimization of in-memory data
SAP HANA stores data in a columnar format, which results in effective
compression and reduction in overall data size. Also, this resolves the
problem of data flow between the main memory and cache.
Data storage model
Normally, the data storage in databases is in a table format. A table is a data
structure in which the information is organized. It can store data in rows and
columns and can be used to display data in a structured format. Databases
normally comprise several tables, and each table has a specific purpose.
The preceding table is a simple example of data. Now, we will check out what
it looks like in a row-based layout:
Both methods of storage have their own pros and cons, and SAP HANA
supports both the models. However, performance is enhanced when the
columnar model is used, as it enables an effective projection by accessing only
relevant columns, which reduces the number of accesses to memory. Also, it
allows for an effective compression, especially when column sorting is done.
Data compression
The technique that is used to reduce the count of bits for data in memory is
known as data compression. In this technique, the overall memory is reduced
and, hence, the cost is reduced, and all of the data reading is done on the
compressed set. Many compression methods, such as run-length encoding,
cannot be applied in the row-based layout. This is a very technical topic, so
we will not go into too much detail here, but, for now, it is important that we
understand the storage scenarios and the meaning of compression.
Delta storage
Normally, data insertion to compressed data is really slow. This problem is
solved with SAP HANA, as it brings the concept of delta storage with it. In
this structure, the storage of a columnar table includes the main storage and
delta storage. Any write operation, such as insert, update, or delete, is done in
delta storage, which is, again, a columnar storage, and any addition is
appended to the end of the structure:
This is what the architecture looks like; it simplifies the database structure and
results in faster processing:
Data aging
In today's world, we are just playing with data. Businesses' data volumes are
immense, and their data is confidential and important in terms of business
continuity as well as growth and compliances. For example, companies have to
detail their financial data for 7 years to 10 years due to IRS audits.
The size of the data is growing day by day, and much effort, as well as money,
is spent on the maintenance of that data.
For sure, we need the actual and latest data to run the business, which is about
10%, and, from time to time, we might need access to 30% of the data.
However, what about the remaining 60% data? Have you accessed the
documents of the projects that you worked on 7 years ago? Do you frequently
see photos of your holidays that you had taken around 8-10 years ago? The
typical answer is no.
The same applies to organizations; they don't really access that 60% of data.
So, what are we doing with that data? What is our strategy? In rare cases, we
will need to access the old data as and when we are showing the order history
to a customer or when we are running comparisons over decades, or during an
audit.
In the new concept of data aging, the data that we access regularly, that is, the
latest actual data, is known as hot and the rest, the 60%, is known as cold. The
temperature of the data decides the strategy to store the data. The goal of aging
is to reduce the main memory footprint and to speed up database queries by
only keeping operationally relevant (hot) data in the main memory. In SAP
HANA, aging is different from archiving in the sense that cold data is still kept
within the SAP HANA database and remains accessible via SQL in the very
same table as the hot data.
Regular daily queries are on hot data, and the cold data is generally
partitioned, as shown in the following figure:
The configuration has to be defined once in the setup phase, and, using this
solution, data can be restructured by a background task and automatically
pushed out of memory if needed.
FAGLFLEXT 1 00000000
SAP S/4HANA is powered by SAP HANA, which combines both OLTP and
OLAP processing. Now, the transactional data does not need to be moved to
another system for analytics, and they run in the same tables, which results in
efficiency and avoids redundancy.
This is what it looks like with and without SAP HANA Live:
The following figure explains that the story line has spanned for more than 10
years:
SAP S/4HANA is designed to run only on the SAP HANA database, and it
already has all the features of this powerful in-memory design from SAP. It can
be deployed on-premise, on the cloud, or on hybrid cloud as needed, and it's
very flexible. The data model in SAP S/4HANA has been simplified. It has
resulted in the removal of several tables. This has reduced the data footprint to
a large extent and also simplifies the system design, usability, and extensibility.
This has resulted in making the financial management simpler and faster. With
the use of Fiori, end users receive personalized information with a detailed
level of data, taking them to the line item details of the transactions. Data
analytics is a method that varies across organizations.
Business intelligence products that cover various ways to represent data are
also available. The products include renewed managerial roles that
specifically target individuals, for example, a financial officer or receivables
manager. In addition, SAP delivers renewed transactional roles for the end
users, such as the general ledger accountant or the fixed assets accountant:
SAP SuccessFactors:
SAP S/4HANA integration and the SAP SuccessFactors Employee
Central Payroll rapid deployment solution (function module web
service that covers finalized, COBL checks and ongoing cost center
replications not yet started)
SAP Ariba:
Ariba Invoice Management (buyer side) and payment advice and
cancel payment advice
Ariba Discount Management (buyer side) and payment proposal and
PayMeNow
Concur:
SAP S/4HANA implementation with Concur and reuse of SAP ERP
add-on (delivery by Concur product)
SAP Fieldglass:
SAP S/4HANA integration planned in a joint project with SAP
Fieldglass, LOB PROC, and SAP Master Data Governance (FIN
contributes cost center and internal order replication)
The Universal Journal
The Universal Journal is all about next-generation accounting, where a single
table is responsible for storing data in place of several tables. This is one of
the major simplifications resulting from the evolution of SAP S/4HANA. It
makes the process transparent, reconciliation free, and allows for seamless
navigation and a deeper insight of an organization's financial data. From a
technical aspect, it's a redundancy-free storage of financial data, consisting
mainly of a general ledger, asset accounting, controlling, and a material ledger.
The General Ledger was redesigned in 2004. It added many advantages, such
as extensibility, parallel views, document splitting, and multiledger
functionality, but its main aim was to replace classic ledgers. However, it
failed to provide flexibility to SAP customers, as they were looking for
improvements such as reconciliation among various subledgers, such as AP,
AR, G/L, AA, and CO. The situation used to look like this:
In the preceding figure, you will notice that there is disharmony between the
financial components, such as the depreciation areas in Asset Accounting, G/L
in the General Ledger, and the cost element in Controlling. All these resulted
in manual work for the customers in reconciling all these items with each other,
wherever necessary. Now, SAP S/4HANA has addressed this issue in the form
of the Universal Journal.
The new architecture combines all the components that we just discussed, and
in place of the reconciliation view (the preceding figure), we now have the
integrated view:
The new journal entry consists of a header (table BKPF) and their
respective items (table ACDOCA)
The new SAP HANA-based reporting of all the components (G/L, AA,
ML, and CO) can access the customer fields
The ACDOCA table contains all the fields needed for G/L, CO, AA, ML, and
PA
The list of tables that were part of this structure and are merged with
the ACDOCA table now includes the following:
Tables removed:
FAGLFLEXA, COEP, ANEP, ANEA, ANLC, ANLP, and MLIT
Material Ledger:
Contents of MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, and BSIM are now
stored in ACDOCA; MLHD data is stored in BKPF
When we talk about the external postings (that is, coming from other systems to
SAP S/4HANA), the view looks like the one shown in the following figure:
Compatibility views for historic data
For the existing SAP customers, all the programs and custom developments
will work successfully on the existing tables. Now, what will happen to those
customizations? Every customer and consulting partner was worried about this.
Customers may not want to spend on the redevelopment of everything, and, of
course, they won't want their business and reporting to be affected due to the
introduction of S/4HANA to their organization. A very simple answer to this
problem is to use compatibility views. Compatibility views are named V_TABLE.
For example, the compatibility view of the COEP table is V_COEP.
The read operations in the ABAP code are redirected toward a view (V_COEP)
via a specific setting in the data dictionary definition of table COEP. This view
then no longer reads the physical the COEP table, but the new Universal Journal;
it now maps the data back to the structure of COEP. From the perspective of the
program code, there has not been any change:
MM01 to create
MM02 to change
MM03 to display
However, the length of the material number has changed along with some field-
level changes. New fields have been added and a few fields have been
removed.
This big change is the length of the Material number field. This was in heavy
demand by customers due to various industry requirements to have a lengthy
material number. It was of 18 characters in SAP ECC, and now it's 40 in
S/4HANA. It was a big change, almost three times the previous length.
Let's look at an example from both systems to see what the Material number
looks like.
However, the default SAP S/4HANA system come with 18 characters only, and
it needs to be extended based on customer requirements.
After this, the field will look like the one shown in the following screenshot:
Another change in the material master is the foreign trade data. This is now a
part of SAP GTS and is not available in S/4HANA.
The new material type SERV is now added. As the name implies, it is intended
to be used for service. The following are the available views for the material
type:
Basic data
Sales view
Purchasing view
Accounting
Sales activity
The Sales Support function (SD-CAS) is no longer supported in S/4 HANA.
SAP suggests SAP CRM or SAP Cloud for customers as the recommended
solution.
SD rebate processing
The SD rebate functionality has been replaced by Settlement Management.
Hence, the transaction VBO1 is no longer available in S/4 HANA.
Data model changes
With the introduction of SAP S/4HANA, several changes have been introduced
in SAP SD:
Pricing: Prices were stored in KONV, but now they will be in PRCD_ELEMENTS
Status tables: VBUK and VBUP have been removed
Index tables removed from the system: VAKPA, VAPMA, VLKPA, VLPMA, and VRKPA
Tables removed: VBOX, S066, and S067
Credit management
Credit management has been discontinued from S/4 HANA, and the
recommended solution is FSCM. Thus, transactions such as F.28, F.31, F.32, and
F.33 are no longer supported. The following are the new transactions in these
areas:
New Old
Purpose
transaction transaction
UKM_MY_DCDS VKM1
Releasing of blocked sales orders due to
credit
Introduction to SAP Fiori
In this section, we will cover the key concepts and aspects of SAP Fiori. We
will also deep dive into some of the important areas. Let's begin with the
question that anyone starting with the technology may ask—what is SAP Fiori?
What is SAP Fiori?
People are drawn to things of beauty. Fiori is an Italian word that means
flower. To view the Fiori logo, visit the official Fiori website (https://sapfioriu
i.com/).
SAP Fiori is the user interface (an actually beautiful user interface) for SAP
applications. SAP aims to have this experience for all its solutions over a
period of time. Fiori can give the best possible experience when interacting
with the SAP Business Suite. When implemented with SAP HANA, the
solution integrates with the existing IT landscape. Additionally, SAP Fiori
results in access to the same data information via various modes and sources:
SAP Fiori is designed with the idea that your work environment needs to be
available to you wherever you are—on your desktop, tablet, or phone.
Key pillars of the Fiori experience
The following diagram represents the key pillars of Fiori:
The SAP Fiori Launchpad offers themes and can be personalized to meet brand
requirements.
Within each application, the user can interact with the SAP Fiori app. This app
covers lots of daily work tasks, along with the enterprise-level tasks.
However, each pattern and control is optimized to address a specific type of
task in a simple, easy-to-use manner. They are flexible enough to be combined
and work synergistically. The consistent use of patterns and controls ensures a
coherent user experience and gives users a sense of familiarity across SAP
Fiori apps.
Adding applications
Removing applications
Modifying applications
In the SAP Fiori theme designer, custom themes can be designed for the
Launchpad. For example, the following tasks can be performed:
New SAP customers can use classic tools to migrate from legacy systems to
SAP S/4HANA. The migration process can be started at any period for the
SAP ECC customer, and the customer can be on the classic or new G/L when
they start to migrate. There are no SAP services that are needed to migrate, as
there was in migration from the classic G/L to new G/L migration.
Until now, in SAP, there were several redundant objects that have now been
replaced by business partners in S/4HANA. This reduces the data volume and
the number of tables. For SAP business partners, this is not new, as it was
already being used in the SAP modules in various ways:
With the emergence of SAP S/4HANA, the major impacted area with reference
to business partners are customers and vendors. Normally, the volume of this
master data is huge in every organization, and most of the time, one party
shares both the relationships. The BP in SAP S/4 HANA is capable of
managing master data centrally for business partners, customers, and vendors.
BP is the only transaction needed to create, edit, and display master data.
1. Set up the general data. Once this is updated, table BUT000 will be updated:
Role FLVN00 enables the posting of a direct vendor invoice and role
FLVN01 enables the creation of purchasing data, which is a must to
create a purchase order:
3. Set up a customer:
Let's talk about Customer Vendor Integration (CVI). For the sake of
simplicity, we will be using the term CVI going forward.
What is CVI?
CVI is a process supported by the standard SAP Master Data Synchronization
Cockpit tool. It is used to synchronize customer and vendor master data
objects with SAP business partner objects within SAP. With CVI in place, all
the customers and vendors are assigned a BP number. The concept is
illustrated in the following figure:
Business impact of CVI
To ensure a successful upgrade, all customers, vendors, and all contacts that
relate to customers or vendors must be converted to a business partner,
including customers, vendors, and assigned contacts with the deletion flag. CVI
requires high-quality master data to be converted. The quality checks cannot be
switched off on the cockpit level. This way, the customer is forced to run a
high-quality master data project for the customer and vendor master. If not
started in advance, this can be a serious roadblock for the conversion. Before
we execute the CVI conversion, SAP recommends to archive the
customers/vendors with the deletion flag. It is recommended (but not
mandatory) that the business partner ID and customer ID/vendor ID are the
same. Note that in case of overlapping number ranges for customers and
vendors in the start system, an additional number range alignment is required.
The user interface for SAP S/4HANA to create and maintain customer and
vendor master data is the transaction BP. The specific transaction code to
maintain customers/vendors (as in the SAP Business Suite) is not available
within SAP S/4HANA. The BP transaction is the single point of entry to create,
edit, and display master data for business partners, customers, and vendors.
CVI ensures that customer and vendor master data tables are updated
automatically after a BP is created/changed. All KNxx and LFxx
customer/vendor master data tables are still populated as previously in the
SAP Business Suite.
The two types of system copies that can be performed are as follows:
SAP system copy without changing the operating system or the database
SAP system copy while changing the operating system or the database
The following are the proposed solutions for these two system copies:
Backup/restore
Third-party tools for data unload/load
SAP system copy tools
SAP homogeneous system copy
SAP homogeneous system copy is a way to move or copy an SAP system to a
new environment. In a homogeneous system copy, the source and target system
use the same operating system (OS) and database (DB) system. The
hardware architecture remains the same, or is a certified successor, where
SAP supports homogeneous copies as well.
The operating and database systems for a homogeneous system copy are
combinations of OS and DB versions released by SAP. In some cases, an OS
or a DB upgrade may be necessary on the source system before a system copy
can be performed. A homogeneous system copy can be executed by a customer.
There is no need for a specific certification. For the target system, the same OS
can mean an SAP-certified successor, such as Windows 2008 or Windows
2012. Depending on the method used for executing the homogeneous system
copy, it may be necessary to upgrade the DB or the OS of the source system
first. On older SAP system releases, an upgrade may be necessary. This can be
the case if the target platform requires a DB or OS version that is not
compatible with the SAP system version that is to be copied. New hardware
on the target system may be supported by the latest OS and DB versions only.
Reasons for a homogeneous system
copy
The following are some of the reasons for performing a homogeneous system
copy:
Depending on the method used for executing the heterogeneous system copy, it
may be necessary to upgrade the DB or the OS of the source system first. Older
SAP system releases may require an update. You may want to perform a
heterogeneous system copy when a DB or OS changes for one or more of the
following reasons:
Hardware enhancements
Performance improvements
Availability of new technologies
Administrative efficiency
Cost reduction
Guarantee against hardware or software becoming obsolete
Standardization through a group-wide platform strategy
System copy consequences and
decision table
The following are some of the negative consequences of a system copy:
The type of system copy can be decided based on the following table:
Migration check service
The SAP OS/DB migration check has two service sessions:
R3SZCHK generates the target database size file, DBSIZE.XML, for SAPinst. The
extent sizes written into *.EXT files will never exceed 1,700 MB
(1,782,579,200 bytes). Nevertheless, the DBSIZE.XML file is calculated from the
original table and index sizes. The size computations are based on assumptions
and are limited in their accuracy. The DDLOADD table is used to store the
calculated extent sizes before writing them into *.EXT files.
The following are the characteristics for ABAP exports and imports:
The SMIGR_CREATE_DDL report is executed shortly before the system is stopped for
the export. SAPinst is called to perform all required export steps. Depending
on the database and the database type, updated statistics might be required to
support the R3SZCHK size calculation. SAPinst can skip the updating statistics
in most versions:
table splitting is used. The DDL<DBS>.TPL files are stored in the .../DB folder, and
all *.EXT files and the DBSIZE.XML file are stored in the corresponding .../DB/<DBS>
database subdirectory.
The SQLFiles.LST and <TABART>.SQL files exist only if they are created by the
SMIGR_CREATE_DDL report. SAPinst copies them into the .../DB and the respective
.../DB/<DBS> subdirectory. The SQLFiles.LST file is empty (except for a timestamp)
if no <TABART>.SQL files were created.
JAVA OS/DB migration
The following are the characteristics of JLOAD Data:
The following are the characteristics of a JLOAD job file creation using JPKGCTL:
Creates the target database DBSIZE.XML based on the DB size of the source
DB system
Requires no special DB statistics
Has a short execution time
JSIZECHECK is normally called upon to get the DBSIZE.XML file created for
all the required target databases.
JPKGCTL helps in distributing the relevant Java tables to package files
and can also optionally split tables.
JMIGMON calls JLOAD to export the Java metadata and table data. For
applications that store their persistent data in the filesystem, SAPinst
collects the files into SAPCAR archives. The SDM is called to put its
filesystem components, including SDM repository, into the SDMKIT.JAR file.
System copies – import and export
In this section, we will learn how to describe the software logistics toolset and
control the export and import processes of system copies.
Software logistics toolset
The software logistics toolset provides a product-independent delivery
channel for software logistics tools and includes the following channels:
System maintenance
System provisioning
Frontend installation
Change control
LM automation
Software provisioning manager
It provides the latest SAPinst version with software-provisioning services for
several products and releases for all platforms and includes the following
topics:
System installation
System copy and migration
System uninstallation
Dual stack split
System renaming
Target database size
The filename for the target database size is DBSIZE.XML. It is created by:
ABAP: R3SZCHK
Java: JSIZECHECK
Test and final migrations are mandatory only for productive SAP systems. Most
other SAP systems, such as development, test, or quality assurance systems,
are less downtime critical. If the first test run for those systems shows positive
results, an additional migration run (final migration) is not necessary:
Migrate each productive system twice—once for test migration and once for
the final migration. Development, test, and quality assurance systems are less
critical and can often be migrated in a single step. In many cases, the migration
of a quality assurance system is not necessary because it can be copied from
the migration production system:
SAP OS/DB migration check
analysis
Perform an SAP OS/DB Migration Check analysis as soon as possible after a
Migration Check has been ordered and the migration project has been
approved by SAP:
Ensure that you fully understand the current system landscape. There may be
OS/DB-related dependencies between certain systems, which must be
analyzed first. Determine the systems that require migration, the correct
migration sequence, and the time schedule of the customer. In the case of a
hosting environment, determine whether the consultant has access to the source
system.
Required source system – technical
information
The following is a list of technical checks/information we need for our source
system:
Customers already using SAP HANA should update their SAP HANA database
to SAP ERP 6.0 EHP 7 or higher versions, and SAP HANA SPS 7 (or higher
versions), to allow for migration to SAP S/4HANA Finance. If the required
minimum SAP HANA update is planned, check whether it's reflected in the
project execution plan. Similarly, verify whether the implementation team has
sufficient experience or equivalent support to install, configure, and run an
SAP ERP EHP upgrade and installation. The installation of SAP S/4HANA
Finance requires SAP ERP 6.0 systems to be updated to EHP 7 or higher
versions. The stack calculation (using the maintenance optimizer) for the
installation of SAP S/4HANA Finance automatically takes this into
consideration.
Software update manager
The software update manager (SUM) helps you perform release upgrades,
install enhancement packages, apply service packages, and update single
components on SAP NetWeaver. The SUM checks the current version of the
system, analyzes the required components, imports the necessary programs and
add-ons, and finally installs all the components that are divided into a number
of roadmap steps, which, in turn, are further subdivided into a sequence of
phases for monitoring purposes. The SUM is the main tool used to convert your
system to SAP S/4HANA Finance. If your source system isn't yet running on an
SAP HANA database, use the database migration option (DMO) of the SUM
to migrate your database to SAP HANA during the conversion.
With SUM and DMO, you can run the upgrade to SAP ERP 6.0 EHP 7 or a
higher version, the database migration to SAP HANA, and the installation of
SAP S/4HANA Finance in a single step. If SAP S/4HANA Finance is installed
using the SUM with DMO, and the source database isn't SAP HANA, a
specific uncritical error message will occur in the
MAIN_SHDRUN/ACT_UPG phase.
Summary
So, now that we have completed this chapter, we have a fair understanding of
migration processes, tools, services, and types, and we can relax. It is
imperative that you recap all of these; however, you don't need to remember
them by heart. Try the following questions and move on to the next chapter, as
now we are gaining a detailed understanding of SAP S/4HANA topics.
Questions
1. What is a homogeneous system copy?
2. What is a heterogeneous system copy?
3. What is a Migration Check service?
4. What can be the consequences of a system copy?
5. What are the key SAP migration tools?
6. What do we mean by the export and import of system copies?
SAP S/4HANA – Deployment
Options
Now that we have gained an understanding of SAP HANA, migration to
HANA, and S/4HANA, we will get into the details of the deployment options.
This chapter will focus on the available deployment options and discuss about
each of the options available in detail.
Cloud deployment
On Premise deployment
Hybrid deployment
What is deployment?
With the emerging trend of increased data volume and with more ease of end
customers, companies have to deploy various systems in their landscapes, not
just one enterprise resource planning (ERP) tool. An ERP is the central
location and hosts more of the data, however, for managing customers
companies use several CRM systems, for managing employees companies use
HR systems; for expenses management and, similarly, for purchases and alot of
other business areas, like planning, incident management, vendor management,
and more, various systems related to those areas are used. All these systems
generally talk to each other from a technical standpoint in order to manage
businesses and have continuous dataflows.
All these systems are hosted somewhere. This is known as deployment, that
is, where the data space is allocated to you. Up until now, most systems have
been hosted in the client's own space and clients have been responsible for
managing and maintaining those systems.
With the changing trend, the data storage area has gained new flavors. Let's
discuss personal data storage. Initially, we used to store data on floppy disks,
then came CDs, and then hard disks were used. Nowadays, people take
subscriptions to internet-based drives, which can host as much data as you
want; however, they need to pay based on the size of their data, for services
such as Google Drive, Dropbox, and SkyDrive. They give some space for free,
but you need to pay to get more space based on your needs.
Now, the question arises as to what benefit you get or how it is more beneficial
than storing data on CDs or disks? The following are the answers to that
question:
On Premise
On Cloud
Hybrid
Now, we will take a look at what each model looks like and how it works.
If a company has heavily invested in its data centers and it does not want to
discontinue using them so quickly and it's organizational processes are heavily
customized along with modifications, then On Premise is the right fit for SAP
S/4HANA deployment. It is completely supported by SAP; however, a
company has to take the end-to-end responsibility for an On Premise system,
especially, in regard to system governance and operations or the
implementation of maintenance measures:
Using existing data centers and managing a system on one's own is the classic
way to manage IT systems, and to date, it is one of the most used, most
preferred, and most successful methods of deployment. If you look at the
deployment model of any organization in the past, almost all will have had this
model. On Premise can be used by two types of SAP customers:
New installations
Landscape migration for existing customers
A new installation means setting up the SAP system starting from zero, where
the customer is not using SAP presently and wants to start with SAP as their
ERP system. It's like a Greenfield project.
Those customers who are already using SAP can migrate to SAP S/4HANA.
We will discuss both these approaches in detail in subsequent chapters.
Area of
S/4HANA On Premise S/4HANA On Cloud
comparison
Licensing
Traditional Subscription
model
Public cloud
Private cloud
A public cloud usually hosts data for various companies on the same server.
Programmers from various companies can build and execute code without
affecting each other's work. SAP offers public cloud services, which are
governed by SAP architecture. Customers simply pay for what they use.
The following are the three different implementation scenarios regarding how
a customer can move to SAP S/4HANA:
With a hybrid approach, customers can leave their existing systems undisturbed
in an On Premise environment; it consists of SAP ERP instances of various
levels or legacy systems. Adding an SAP S/4HANA instance managed in the
SAP HANA Enterprise Cloud enables a customer to adopt finance innovations
at their own pace.
Summary
In this chapter, we discussed all the deployment options—On Premise, cloud,
and hybrid models. Customers can choose the model based on their needs
however, all of them have some pros and cons. So, now, you are ready to help
customers in choosing the right deployment option.
Let's move on to the next part of this book, where we will learn about the key
changes in each of the functional areas.
Questions
1. What is the meaning of deployment?
2. What are the possible options available to customers for deployment?
3. Explain the features of hybrid model.
4. What is the innovation cycle plan for On Premise, and how is it different
from hybrid?
Impact of S/4HANA on the SAP
General Ledger
In the preceding chapters, we discussed what S/4HANA is all about. Now, we
will get into the details. Be prepared to dive deep into the SAP S/4HANA
journey, as we are starting with the functional changes and the configuration of
the SAP S/4HANA General Ledger (GL). Before we move on to the
configuration, it is important to understand the Universal Journal, the Appendix
Ledger, and other such topics. For those who are starting afresh, you also need
to focus on the sections related to the Classic GL and New GL, so that you get
to know the start and background of this entire story.
Technical requirements
For this chapter, the following is required:
In this section, we will start with the Classic GL and then deal with the New
GL. Further, we will drill down the features of the General Ledger in SAP
S/4HANA.
An overview of the Classic General
Ledger
The General Ledger contains all the financial transactions of a business. Along
with using the Classic General Ledger, businesses also use the Special Ledger
and several other components, such as Profit Center Accounting (PCA), in
order to meet their legal and business reporting and transactional and auditing
requirements. SAP Profit Center Accounting and the Special Ledger are
separate applications. So, these modules were never automatically reconciled
in the Classic General Ledger. This was one of the major drawbacks of using
the Classic GL. However, customers probably did not have any options at that
time. This resulted in more activities at the time of month end closing so that
the reconciliation with the Classic GL could be performed. This was
accomplished by the New GL. Let's discuss the New General Ledger.
An overview of the New General
Ledger
The New GL is the improvised version of the Classic GL. It comes with
several advantages, including the following:
Parallel accounting
Segment reporting
Cost of sales accounting
Document splitting
New tables
Integrated FI and CO reporting
When a customer wanted to migrate from the Classic GL to the New GL,
certain scenarios were available. Since the Classic GL and New GL are now
replaced by SAP S/4HANA, these scenarios may not be realistic for most
customers.
The SAP General Ledger migration for migration from the Classic GL to New
GL has eight scenarios:
HANA has the capability to calculate on the fly, which means it removes
several tables and indices that were creating redundancy in the process:
The tables that are meant for line items and the index of GL are GLT0, BSIS,
BSAS, FAGLFLEXA, FAGLFLEXT, FAGLBSIS, and FAGLBSAS
The total tables and application index tables of accounts receivable and
accounts payable (KNC1, KNC3, LFC1, LFC3, BSID, BSIK, BSAD, and BSAK)
The line item and total tables of controlling (COEP for certain value types
and COSP and COSS)
The material ledger tables for parallel valuations (MLIT, MLPP, MLPPF, MLCR,
MLCD, CKMI1, and BSIM)
The Asset Accounting tables (ANEK, ANEP, ANEA, ANLP, and ANLC)
All these tables are merged to the ACDOCA table with the header table, BKPF.
FAGLFLEXA and some other New GL tables are now obsolete, and there are new
customizing tables. ACDOCA is the new table introduced by SAP in the finance
area, which is the master table containing all line items from most of the
modules, such as the assets and material ledger:
However, the existing programs and custom developments will successfully
work on new tables. SAP now uses compatibility views. Compatibility views
are prefixed with V; for example, V_TABLE and V_COEP for COEP.
The read operations in the ABAP code are redirected toward a view (V_COEP)
via a specific setting in the data dictionary definition of the COEP table. This
view then no longer reads the physical table, COEP, but the new Universal
Journal; it now maps the data back to the structure of COEP. From the perspective
of the program code, there has not been any change:
Universal Journal
In SAP S/4HANA Finance, the Universal Journal captures all the accounting-
relevant transactions in Financial Accounting (FI) and Controlling (CO) as
journal entries. It thus represents the single source of truth for both financial
accounting and management accounting. The result is a fully integrated
accounting system in which all line items from business transactions,
regardless of where they occur, are located in one place. The Universal
Journal contains all the fields (columns) required by the business processes
and individual components. The first release of the Universal Journal was SAP
Simple Finance 2.0, which has since been renamed SAP S/4HANA Finance.
To have only one field available in the Universal Journal for both the GL
account and cost element numbers, the cost elements are contained inside the
GL account master records. To make this happen, there are now four types of
GL account (there were two in ECC: Balance Sheet and Profit and Loss). They
are as follows:
Now, the drop-down menu in the GL master data screen (transaction FS00)
looks as follows:
Cost Element used to have default account assignments in the master data
screen itself, but now, only transaction OKB9 will be available:
If Primary Costs or Secondary Costs are selected as the GL account type, then,
on the Control Data tab, Controlling area settings will be visible as the cost
element category. The drop-down options are based on selecting Primary
Costs as the GL account type. Categories relating to secondary costs are
available if the Secondary Costs GL account type is selected; however, the
Cost element groups will be still available:
Changes to transactions and search
options
On the colored icon at the right of the top menu bar in the S/4HANA GUI,
select the Options button and then go to Interaction Design | Visualization 2,
where an enhanced search can be activated or deactivated. It can also be done
via a keyboard shortcut (Ctrl + Shift + Q):
This enhanced search functionality can be used as needed at several places
while doing day-to day-activities in SAP. For example, in the vendor line item
report, you can find the vendors as follows:
The old reports, such as FBL1N, FBL5N, and FAGLL03, still exist, and,
additionally, new transactions with H as their suffix are introduced, which are
powered by HANA. These include FBL1H, FBL5H, and FAGLL03H, and they
have slightly different screens. The selection screen is almost the same, but the
new button is added halfway down the selection screen instead of at the top
and is labeled Restrictions. Once a report is executed, it looks a little different,
and the line items are summarized by period:
Customizing the SAP General
Ledger
Now we have learned about the changes in GL in S/4HANA along with the
background of the Classic GL and New GL, it will be a good idea to start on
with the configuration of the new items added by SAP.
The configuration is done in the SAP IMG under the following menu path (for
clarity, the screenshots of the path are also provided):
Transaction: SPRO
1. Go to transaction SA38:
By completing this activity, the New IMG will be activated, which will have
all the configuration nodes for S/4HANA.
Checking and adopting Fiscal year
variants
When the GL is migrating from SAP ECC to SAP S/4HANA, it is important to
note that it verifies that the Fiscal year variant in FI and CO are the same.
In this step, SAP checks the Fiscal year variants of the Controlling area and of
all the company code assigned to that Controlling area. Technically, the Fiscal
year variant of the Controlling area and all its company code should be same.
Any inconsistency can be handled separately.
The following configuration settings are migrated with the preceding step:
Any failure or warning needs to be handled before moving to the next step.
Defining settings for the Journal
Entry Ledger
Before executing this IMG activity, the following prerequisites need to be met:
Once these prerequisites are met, the IMG node can be executed, and this
activity results in the ledger definition. One ledger can be the leading ledger
0L, and other ledgers can be configured based on business requirements:
All company code needs to be assigned to the leading ledger 0L, and company
code assignments to other ledgers along with currency settings, Fiscal year
variants, and open period variants for non-leading ledgers must be completed
here.
If the decision is to use parallel accounting using GL accounts, then the Parallel
GL Account checkbox must be checked:
Also, the accounting principle assignment must be done to the ledger based on
business requirements, such as IFRS and USGAAP. With this assignment, the
documents posted in one accounting principle are also posted to all the
assigned ledgers, and if the ledger is not specified, the document gets posted to
all the ledgers:
To learn more about the different Fiscal year variants, refer to SAP Note # 1951609
(S-User ID required): https://support.sap.com/en/index.html.
Defining ledger groups
Before we start the configuration, let's understand what a ledger group is.
When we create a ledger in SAP, the system generates the ledger group with
the same name, and data to any ledger can be posted and reported using the
ledger group. A ledger group has the following main features:
For example, a separate document type can be created that can be used for the
reposting or allocation of primary costs. For document types used in CO, you
must select the G/L account indicator under the Account types allowed section.
The transaction code remains the same as for FI document types, OBA7.
In case the default ledger group is not mentioned, all CO transactions will get
posted to all the ledgers:
Defining the offsetting account
determination type
Before we start configuring for this determination type, let's understand what
an offsetting account is. An offsetting account is the second leg of the
accounting entry. For example, we have the following accounting entry:
DEBIT 600100 Sundry Expense
So, if we run the GL report for GL , then the offsetting account will be
600100
122100.
Now, what will happen if the accounting entry has multiple lines, as in the
following code:
DEBIT 600100 Sundry Expense
Now, the credit side has two lines, so which one is the offsetting account?
Here, offsetting is needed for reporting purposes, and each business can have
their own way of reporting. In the configuration activity, this is taken care of.
In this activity, you will define the offsetting account determination for all
applications. This activity needs to be executed before the migration to SAP
S/4HANA Finance. In this case, the option selected must be As case 2, but
including line items generated automatically because the offsetting account
with the highest amount along with the line items that are generated is
displayed automatically using this option:
Defining the source ledger for
migration of balances
When the migration is done, we will need to tell SAP what is the ledger to be
migrated, based on which it will read the tables.
In this configuration activity, the source ledger is selected; also, the source
database table for the balances of the SAP General Ledger, from which the
transfer of opening balances is needed. The following are used:
Target ledger
Company code (mention * if it needs to be executed for all company code)
Start with the fiscal year (by specifying the 0001 year, you apply the
settings for all fiscal years)
Executing the consistency check for
the General Ledger
This is the final check for customizing settings.
Transaction: FINS_CUST_CONS_CHK
This needs to be executed before the migration of transaction data, and there
should be no error messages appearing. The Check passed message should be
visible, and in case of any error, the necessary action needs to be taken:
Activating business functions
In this activating business functions activity, the business functions are
activated that are necessary for migrating to SAP S/4HANA Finance. The
following given business functions have to be activated by transaction code
SFW5:
Now, we will move on to the Controlling and COPA section and will talk in
detail about the changes done in those areas using the innovation.
Questions
Now, let's see if you can answer the following questions based on the reading
of this chapter:
COPA
Types of COPA – Account-based and Costing-based
Dataflow to COPA
Redesigning COPA in SAP S/4HANA
Key configuration areas of COPA in SAP S/4HANA
Technical requirements
For this chapter, the following is required:
Now, we will learn the usage of COPA and how COPA can be useful to any
organization.
Usage of COPA
Let's take a look at how COPA is important to an organization:
Aspect Consideration/Question
How successful was the sales campaign
Success of marketing projects
for a specific product/service?
What is the impact of the pricing strategy
Revenue and cost structure
on a set of customers?
Contribution of individual Which is the largest and fastest growing
market segments customer?
Contribution margin goals of Have the sales force-achieved their
individual sales units contribution margin goals?
Aspect Consideration/Question
Which responsibility areas have exceeded their
Controlling
planned profit(s) in the past?
Return on net assets Which asset value is assigned to a profit center?
Contribution of What is the operating profit of a profit center or a
organizational units group of profit centers?
Managing internal What is the intercompany transactional summary?
sales and services
The accounting numbers of the organizations will not change due to using any
of the methods; however, the view will change and, hence, the strategy and the
decision-making process will be easy, based on organizational goals.
Reporting may look different in both methods having the same base and
numbers for calculation.
Reporting comparison in both methods looks as follows:
Aspects in SAP profitability
management and organization units
involved
When the profitability is analyzed in SAP, the various organizational units and
the various modules that are sent the data for contribution to the analysis are
considered:
The definition of key organizational units for quick reference are as follows:
Most of the data flows from Sales and Distribution to COPA. The following
figure shows the differences in data transfer from sales in both types of COPA:
Now, let's take a look at the overall differences in both types of COPA:
In the following figure, you can see what the P&L of an organization looks like
when different types of COPA are used, given the transactions remain the same:
COPA in SAP S/4HANA
In SAP S/4HANA, COPA is named Simplified Profitability Analysis. In SAP
ECC, it was recommended to use Costing-based COPA due to its reporting
capabilities. However, with the emergence of SAP S/4HANA, SAP
recommended using Account-based COPA, as P&L with contribution-margin
calculations is now available in Account-based COPA although it was
available only in Costing-based COPA earlier. So far, SAP has moved toward
Account-based COPA.
Integration of Account-based CO-
PA to Universal Journal
In Simplified Profitability Analysis, the information related to costing and
revenues is always updated and is fully reconciled with P&L. This results in
using the information easily and flexibly alongside transparency.
Internal order
Project
Service order
Sales order
Production order
Cost center
Now, if (except service order) there is a real account assignment to any of the
preceding cost objects, SAP can derive the statistical COPA segment. This
statistical COPA segment is known as the attributed profitability segment. In
the following scenario, the internal order has the settlement rule as CO-PA:
The following is the settlement rule:
Now, let's take a look at the different characteristics and their nature with
regard to realignment.
Characteristics that cannot be
changed
Company Code
Controlling Area
Functional Area
Business Area
Profit Center
Partner Profit Center
Segment
Characteristics that can be changed
freely
Material
Vol. Rebate Grp
Industry
Sales District
Sales Office
Sales Group
Country
Customer Group
Material Group
ABC Indicator
Form of manufacturer
Characteristics that can be changed
only if the account assignment is not
true
Sales Order
Sales Order Item
WBS Element
Cost Object
Internal Order
Cost Center
Characteristics that are changeable
if the field is initial at the time for
execution of realignment
Billing Type
Sales Organization
Distribution Channel
Division
Plant
Customer
It provides several reporting options and is easy to use, as people are familiar
with Excel:
HANA Live
HANA Live is another way of reporting. It is based on the browser and
provides access to data and standard queries:
COGS split in S/4HANA-based CO-
PA
In the past, Costing-based COPA was recommended since it was capable of
providing a detailed view on the Cost of Goods Sold (COGS), the
breakdown of Cost of Sales to cost components. However, in SAP S/4HANA,
Account-based COPA offers a similar functionality.
Defining accounts for splitting
COGS
The COGS is posted to a single account, which is defined in the account
determination settings. In this configuration step, we need to define the settings
for COGS postings to split the COGS amount so that it can post to different
accounts according to the cost components:
Once you enter the configuration node, the following settings can be done:
With this, we have completed learning about the changes to Controlling and to
CO-PA in SAP S/4HANA.
Summary
I hope that you enjoyed reading about COPA. It was a pretty detailed
discussion, and we covered almost all the aspects of the planned areas.
Additionally, we discussed the key changes in the controlling section, apart
from COPA. COPA is one of the major areas that underwent a change due to
S/4HANA innovations, and SAP is focused on account-based COPA.
Questions
1. What is COPA?
2. What are the key differences between account-based COPA and cost-
based COPA?
3. What are the table-level changes in COPA due to SAP S/4HANA?
4. What are the key features of Material Ledger?
5. What is the meaning of the COGS split?
6. How COPA is different from Profit-Center Accounting?
Impact of S/4HANA on SAP Asset
Accounting
Now that we understand the Classic General Ledger and the New General
Ledger, it's time to move on. We will discuss New Asset Accounting in detail.
However, for convenience and as a refresher, we will have a quick overview
of Asset Accounting, as it works in a classic way, and then we will discuss the
changes, the new functionalities, and, of course, the data migration part, which
is really a challenge in Asset Accounting. In this chapter, we will look at the
following topics:
Irrespective of the nature of any industry, this area works in a standard way
and the only change is with respect to countries, as each country can have its
own laws and ways of treating fixed-asset transactions. SAP Asset Accounting
is a very robust and integrated system with other components such as General
Ledger, costing, and procurement.
With the standard SAP integration, Asset Accounting transfers data directly to
and from other systems:
Features of SAP Asset Accounting
Some key features of New Asset Accounting include the following:
Client: The client is the highest level in the SAP system hierarchy. This
level denotes the specific logical system that you are working on.
Specifications that you make at this level apply to all company codes.
Company code: Company code is an independent accounting unit in SAP.
The legally-required balance sheet and profit and loss statement are
created at this level.
Profit center: A profit center evaluates the success of independent areas
that are responsible for costs and revenues within a company. You decide
whether you need to create only a profit and loss statement at the profit-
center level (document breakdown not active) or a profit and loss
statement and a financial statement (document breakdown active).
Segment: A segment is a division of a company for which you can create
financial statements for external reporting. Certain accounting principles
require companies to perform segment reporting. You can define segments
in your SAP system for this purpose and provide information on the
financial results of these business segments.
Business area: Business area is considered a separate unit for internal
reporting purposes:
Charts of depreciation
Charts of depreciation are used to manage various legal requirements for the
depreciation and valuation of assets. The keys are defined for the automatic
depreciation of assets flexibly in each chart of depreciation. Keys are based on
the elements for calculation (calculation methods, period controls, and more)
that are available at the client level. Charts of depreciation must be country-
specific, so SAP provides sample charts of depreciation for most countries.
Samples cannot be used to assign company codes directly, but these can be
copied as a reference. Changes to the copied chart of depreciation are
possible, for example, the deletion of any depreciation area that is not needed
for the organization:
Cost center
Real order
Cost center and statistical order
WBS element
Cost center and statistical WBS element
Real estate object
Objects from PSM
Integrating with General Ledger
(FI)
In Transaction AO90, the GL Accounts are assigned to the asset classes via
account determination, which integrates Asset Accounting.
Master Data
Depreciation Area
Technically, each asset can only be assigned to one asset class, and an
organization can have as many asset classes as they need. The asset class is the
main criterion for classifying assets, and asset classes are created at the client
level.
Asset classes establish a link between asset master records and their values
and the General Ledger (G/L) accounts, to which the related asset values and
depreciation are posted. You can control this link through account
determination.
Asset number ranges are also controlled by asset classes, and an asset class
can be linked to multiple charts of depreciation. This linking allows for a
globally uniform class catalog, despite there being different Depreciation
Areas.
The asset classes can be configured with default values for Master Data
information and depreciation terms for each depreciation area:
An introduction to New Asset
Accounting
With the nature of change and innovation, SAP Asset Accounting changed to
SAP New Asset Accounting. New Asset Accounting was introduced in 2013
on SAP ECC6 EhP7. Technically, it can be used without S/4HANA too, as long
as New GL and ECC6 EhP7 are implemented. Asset Accounting is one of the
key areas that was later optimized to run on S/4HANA and was named New
Asset Accounting; it comes with the integration of the ACDOCA table, replacing
classic Asset Accounting tables. New Asset Accounting is only compatible
with the New GL version. The New General Ledger is now officially renamed
SAP S/4HANA General Ledger. The baseline of Asset Accounting remains the
same, where the chart of depreciation (by country) is assigned to company
code, and the COD carries the rules for posting depreciation along with the
necessary depreciation areas. Asset classes, integration with GL (via AO90),
and other features remain the same; nothing has changed here, and values for
different accounting principles can be controlled by depreciation areas.
Key changes in New Asset
Accounting
Now that Asset Accounting is integrated with the ACDOCA table, it posts directly
to the GL, and the tables that stored postings of assets are now no longer
available. ACDOCA is the only single source of truth, and it posts to all relevant
accounting principles in real time.
Asset Accounting-sent postings are transferred to GL at the asset level, and its
detailed information on assets is now available. Also, the transaction types are
free from the limitation of the ledger-oriented approach, and new transactions
have the option of choosing depreciation areas on the screen.
Since both FI and CO are merged in SAP S/4HANA, there are no more cost
elements. The chart of accounts Master Data is adjusted with the new field for
the P&L cost elements. Categories remain the same as they were in SAP ECC.
However, the cost element category 90, which was previously used for
statistical postings in the balance sheet, is not part of this. The screen has a
checkbox in COA that allows the account assignment in Asset and Material
reconciliation accounts statistically.
Changes to transaction codes
The new transactions that were added with New Asset Accounting are as
follows:
ABAAL
ABAVL
ABZOL
ABAOL
ABST2
ASKBN
AJRW
OASV
AFAB
AS91
AFAR
ABML
An introduction to the Technical
Clearing Account (TCA)
In SAP, all subledgers are connected to the General Ledger via reconciliation
accounts. It may be Payables, receivables, or assets documents. This helps in
real-time SL and GL reconciled, and no direct posting is allowed in the
reconciliation account.
The following is an example of the posting options, which are available for
Asset Accounting, considering the reconciliation accounts that are in place:
CREDIT - Vendor
Now, what has changed? The same accounting entry shown looks like this:
Document Entry:
CREDIT - Vendor
The operational part (Ledger Group will be blank) – Document Type KR:
DEBIT - Technical Clearing Account (TCA)
CREDIT - Vendor
In valuation part (Ledger Group will have values based on the company
code setup – let's say it has leading ledger (0L) and Non Leading Ledger
(ZL)) – Document Type AA
In Ledger 0L:
DEBIT - Asset Account (Sub Ledger & General Ledger)
In Ledger ZL:
DEBIT - Asset Account (Sub Ledger & General Ledger)
Now, in summary, the TCA is net off to ZERO on both ledgers, and the asset
has a value in both ledgers along with the credit to vendor, which can be paid
off with the payment process. What does this change actually mean, and what
are its benefits?
In the case of asset acquisition via integration, the transaction is divided into
an operational part and a valuation part:
Additionally, the transaction types are not ledger-specific anymore. In all the
new transactions, which are suffixed by L, the ledger can be selected by
choosing the depreciation area or the accounting principle:
Posting to the Universal Journal
S/4HANA replaces the following tables with ACDOCA:
ANEP
ANEK
ANEA
ANLC
ANLP
New depreciation-calculation engine
The New Depreciation Engine is a redesigned version of the old one with
some major changes to meet some country-specific requirements. The new
options available are as follows:
For limited volume, you can still use transaction AS91 to create the asset
Master Data, but the takeover values button is grayed out, so you can no
longer enter values and need to use the new ABLDT transaction for the
values. ABLDT posts directly to the migration account, so you don't need
to make any additional postings.
For medium volume, use transaction AS100.
For huge volumes of data, BAPI_FIXEDASSET_OVRTAKE_CREATE can be used (for
more details, refer to the SAP Note 2208321): https://support.sap.com/en/ind
ex.html.
As the asset and General Ledger values are now in the same table (ACDOCA), the
consistency and reconciliation transactions are now obsolete and do not even
exist in S/4HANA. In S/4HANA, all the ledgers are posted in real time, hence
there is no need for period postings. For migration, it is mandatory to complete
all pending period postings; SAP does not allow us to complete these
postings after migration due to the new data structure. In SAP ECC, it worked
differently, as Master Data and postings were different (via AS91 and OASV),
but, in the new world, these old transactions are not needed.
The legacy Transaction AS91 is no longer useful for asset postings; however, it
can help to create the Master Data, and postings can be done simultaneously in
the Asset accounting and General Ledger via the ABLDT transaction.
For BAM and Cash Management, we will understand the solutions in detail,
along with the necessary configuration. However, for BPC and Fiori, we will
be discussing the solution extensively.
Technical requirements
The following is required for this chapter:
The major difference in using this functionality in SAP ECC and SAP
S/4HANA is the capability to set up an Account ID for a Business Partner's
bank master data and this Account ID maintenance is de-linked from the House
Bank setup technically.
In this step, Define Number Ranges for Bank Account Technical IDs,
define the number ranges for bank account technical IDs:
Maintaining bank account types
For maintaining bank account types, in SPRO use Define Settings for Bank
Account Master Data and also define account types on the Account Type
Definition tab:
In the configuration step, use Define Settings for Bank Account Master
Data:
If you want to learn more details about these two, refer to SAP Note 2165520
(S-user ID required): https://support.sap.com/en/index.html.
The master note: 2138445 is completely understood and all referenced notes are
implemented as per landscape suitability.
Master Data set up
Bank Master Data must be migrated/set up in order to proceed further. We have
completed this in the preceding section.
Bank statement processing
You'll find the import and export bank account functionality using Transaction
NWBC. The options available are as follows:
This step is necessary for setting up the transactional data that will be further
consumed by Cash Management applications. Sources of data consumption
include:
To use SAP S/4HANA Finance for Cash Management, make the following
configurations:
The following source applications can be integrated for real-time update into
One Exposure from Operations, and the transaction data can be consumed by
SAP S/4HANA:
Financial Operations
Treasury and Risk Management (TRM)
Consumer and Mortgage Loans (FS-CML)
Contract Accounts Receivable and Payable (FI-CA)
Materials Management (MM)
Sales and Distribution (SD)
Introduction to BPC
In this section, we will talk about BPC. What is BPC; is that you are thinking
now? BPC means Business Planning and Consolidation, but we will be
referring to it as BPC going forward. BPC existed before SAP S/4HANA as
well, but it was a separate product that was kind of integrated but not as
integrated as other products. BPC is a solution that allows the financial
planning from SAP BPC to integrate with SAP S/4HANA Finance and SAP
Fiori user interfaces (UIs) and workflows. This effectively replaces the old
financial planning capabilities in SAP ERP 6.0 or earlier versions.
What's new in this area?
SAP BPC for S/4HANA Finance has been designed to support integrated
business planning across the various finance functions, so that planning within
one area automatically updates corresponding planned values within other
areas. It uses SAP BusinessObjects Analysis for Microsoft Office, as an add-
on tool for conducting the analysis of planned data in Excel, which is
integrated in real time with the SAP system. SAP BPC for S/4HANA Finance
also uses the new Planning Modeler, which acts as the central tool for
configuring all planning applications that exist in the SAP Business Warehouse
(SAP BW) integrated planning component. In this section, we'll discuss the
architecture, configuration, authorization, and settings required to activate
embedded SAP BW, SAP BusinessObjects BI, planning services and
applications, and SAP BusinessObjects Analysis for Microsoft Office, which
are all the components required collectively to activate SAP BPC for
S/4HANA Finance.
Before and after S/4HANA
comparison
Before SAP S/4HANA, planning used to have the following features:
After the introduction of SAP S/4HANA, the following are the key features of
BPC:
SAP BPC for S/4HANA Finance comes embedded with SAP S/4HANA.
All the planning is done in the same SAP instance and server. No separate
SAP BW instance is required for planning.
SAP BPC for S/4HANA Finance allows organizations using traditional
financial planning in SAP ERP 6.0 or lower to rapidly implement while
protecting their existing investment, thus minimizing the cost and time
required to get this new functionality up and running.
SAP BPC for S/4HANA Finance provides a lot of standard planning
templates and calculations covering multiple planning scenarios, which
saves time during the planning exercise.
Applications used
BPC uses the following applications:
Cost center
Project
Internal order
Functional area
Profit center
Cost of sales
Market segment
Profit and loss items
Balance sheet items
How data flows
BPC is installed directly on the embedded SAP BW of the SAP S/4HANA
system, where no data replication is required. SAP BPC is able to access both
the master data and the actual transactional data in real time from the SAP
HANA database:
5. Fill in all the necessary details and you will see the mappings are
created:
Now, you can add the newly created tile to the relevant tile group:
So, you can create your own Fiori tile now.
Summary
With this, we have completed the four key areas—BAM, Cash Management,
BPC, and Fiori. You might not get a chance to work on all aspects as the
project will have a different consultant for each of the areas, and that makes
sense too—you cannot do everything in a project, but it is important that you
understand the functionality end to end and are aware of the areas that have
changed as compared to SAP ECC. I will not let you close the book like
this...let's have a quick test of what we have learned in these areas.
Questions
1. What is the difference between Bank Account Management and BAM
Lite?
2. What areas changed in BAM with SAP S/4HANA?
3. Describe the important of FSCM in any SAP S/4HANA implementation.
4. How does BPC help an organization in its day-to-day operation?
5. What types of Fiori apps are there?
Overview of Implementation
Scenarios
As we have now learned about the changes made in S/4HANA in all key areas,
such as the general ledger, asset accounting, profitability analysis, BPC, cash
management, and more, it's the right time to learn about the implementation
scenarios available to the customers.
In this chapter, we will focus on all the possible implementation scenarios that
are available to the customers and how they fit in with the different
communities of customers, namely, the following:
New implementation
Conversion of the system from SAP ECC to SAP S/4HANA
Landscape transformation using central finance
Technical requirements
For this chapter, the following are required:
Three scenarios are presently available for any type of customer in order to
move to SAP S/4HANA. These are as listed:
New implementation
System conversion
Landscape transformation
New implementation
This is the scenario suitable for customers who want to move from any legacy
(professional or homegrown) system to SAP S/4HANA and want a fresh start,
even if they have some part of SAP in their diverse landscape. This results in
delivering value related to process reengineering, and the advantages of the
latest innovations can be utilized.
SAP best practices can be used along with guided implementation. The fresh
start can be made without using best practices when the processes are highly
complex and customized. You can introduce SAP S/4HANA quickly and cost-
effectively, and rapidly adopt additional innovations later.
Duration of the new implementation
There are several factors that affect the duration of the project. The volume and
complexity of data migration, as well as the number of data migration objects,
affects the duration of the new implementation. The duration of the SAP
S/4HANA implementation is also impacted by the scope of the business
process along with the volume.
Approach in new implementation
If the customer is on-premise, then first the software installation needs to be
done with the software provisioning manager. Process design should be
completed, along with the relevant configuration and testing, and then an initial
data load should be performed from the source system, either through a file
upload from a legacy system, or, if the source is SAP, through a direct system
connection:
The process can be started with a model company. SAP provides various
model companies for SAP S/4HANA. This includes a model company for
marketing, project services, and enterprise management. A model company has
the benefit of having a preconfigured environment, and the processes are ready
to go. The model company contains an enterprise structure or marketing
structure, it has predefined master data, and it comes with ready-to-run
business processes, including the respective reporting content and the
integration processes to adjacent SAP cloud solutions that are relevant for
these business processes. Fit/Gap analysis can be done after doing the detailed
study on the model company.
This analysis will result in a document with a list of the relevant business
processes, and the scope and details of what is not coming or predelivered.
This will be the exit point for the scoping step and the entry to the next step. In
on-premise, the relevant business processes can be activated, as it's a customer
controlled system. On the cloud, the guided configuration capabilities are
available with SAP S/4HANA.
If the kick-off point is a SAP ERP system, migration is made easy, as the
mappings are preconfigured from the source to target systems, as both are
SAP systems, just different versions
If your kick-off point is any non-SAP system, SAP provides a canonical
format and from that canonical format, the mapping to the target business
objects in SAP S/4HANA are available
After migration, the business users need to join the ground. It may be key/super
users, who work like experts with the new solution, or end users. This is also a
time-and resource-consuming activity, as you need to classify users and the key
and end, and also, the roles and responsibilities need to be segregated:
System conversion
Now, let's focus on the system conversion, as this is one of the widely used
scenarios in recent SAP projects.
You have to handle the technical preparation steps to get to SAP S/4HANA, so
you will check for add-ons and industries using the maintenance planner to
ensure compatibility with SAP S/4HANA. A deinstallation tool is available
for enabled partners and SAP add-ons.
Another preparation step is to check for custom code. A custom code check
tool identifies the scope and data structures and conflicts, based on the
simplification database content. Finally, after all the preparation steps, you run
a test conversion. If the test conversion is successful, you perform the actual
conversion and the cut over:
A SAP Business Suite customer can move from different start releases to the
SAP S/4HANA On Premise Edition. Unicode is needed, due to technical
restrictions with the S/4 kernel:
Many of the changes are technical in nature and have no, or limited, effect on
people's work and therefore do not trigger business change management. Such
changes are mandatory when converting a system to SAP S/4HANA:
Custom code checks are based on the simplification list provided by SAP.
Running this check is not time-bound, but it should be executed before the
conversion process is started, as none of the project team would like to endure
the pain of analyzing the thousands of code lines.
How to plan a migration project?
In any migration project, the key to success is the shorter migration duration
that is possible due to minimal data load. SAP has a tool called SAP DVM
Work Center that can help in this process. SAP DVM can be used in the
following ways:
Some of the following questions need to be asked, which can help select the
right migration toolkit:
What is the SAP release and support package of the existing system?
What is the Unicode system?
Do you plan to rename the system ID (SID) of your productive SAP
system during migration?
Do you plan to reuse existing application server hardware for the target
system? Do you want to perform in-place migration?
Do you want to perform a full migration of the complete system, or do you
want to migrate only some of the data?
Do you expect a significant downtime due to a large database volume?
Key performance indicators (KPIs)
in migration
Test key performance indicators beforehand, such as the following:
Network bandwidth
Source DB read performance (SAP Note 1875778, DB-specific settings)
- crucial for overall runtime
Perform a SAP HANA performance check with a hardware configuration
check tool (SAP Note 1943937)
Test disk performance of the source DB and primary application server
Landscape transformation
In the landscape transformation scenarios, the flexibility is added around the
systems. The customers who want to consolidate their system landscape have
options, and it is even suitable for those customers who want to transform data
into a SAP S/4HANA system on filtered criteria.
Benefits of landscape
transformation
The following are some of the key benefits of this approach:
Consolidation
Migration of business units
Migration of selected applications (central finance)
Available consolidation scenarios
When we talk about the consolidation scenarios, the following are the main
scenarios:
Lack of transparency
Prolonged process execution
Service level issues
Key use cases for the central finance deployment include smoothening mergers
or acquisitions, adding new subsidiaries, consolidating instances or systems,
and adding the SAP capabilities to full or partially non-SAP ERP landscapes.
Elements of central finance
Key elements of central finance may include:
The pre-closing activities include the following, however these can differ
depending on the process:
The pre-closing activities include the following, however these can differ
based on the process:
Technical: Open the first accounting period of the new fiscal year in FI,
and perform the balance carry forward centrally in FI
MM: Perform a physical inventory count, which may be performed on a
monthly basis
Production planning (PP) or CO: Update product-cost estimates, which
may be performed more frequently
AA: Perform asset valuations and investment support
FI: Conduct balance confirmations for customers or vendors
Reporting with SAP S/4HANA
It is important to complete the reporting on time. Of course, you have to file
your tax returns on time in order to be compliant, and the reporting is the basis
of those returns, and the next year's planning and budgeting is also based on
present numbers.
Financial statement versions
For the reporting of financial statements, we have financial statement versions.
A financial statement version enables you to configure the following aspects of
the report format:
The items to be included, and the sequence and hierarchy of these items
The text describing the items
The charts of accounts and the individual accounts relevant to the report
You can use financial statement versions in the structured balance list, as
well as for planning, drill-down reporting, and transferring data to
consolidation
You can define as many financial statement versions as you need to make
reports for various purposes, such as for tax authorities, internal users,
and external users
You can use parameters to make additional specifications, such as
whether to create the report at the business-area level, segment level,
profit-center level, or company-code level
The RFBILA00 program's structured list has the following restrictions:
IT users
Analytics key users
Analytics end users
With SAP S/4HANA, this concept is supported by SAP Core Data Services
(CDS) views for real-time operational reporting. The content is represented as
a virtual data model (VDM), which is based on the transactional and master
data tables of SAP S/4HANA. CDS views are normally developed,
maintained, and extended in the ABAP layer of the SAP S/4HANA.
The system then generates SQL runtime views in SAP HANA to execute the
data read and transformation inside the SAP HANA database layer:
Closing Cockpit in SAP S/4HANA
The SAP Closing Cockpit is not a process, rather it's an application that
enables businesses to create a set of structured interfaces for the successful
execution of a list of transactions or programs that are part of the periodic
closing process (monthly or yearly). The designed structure works within the
existing organizational structure like company code/s and also with the
scenarios affecting multiple organizational structures.
With the introduction of SAP S/4HANA, the Closing Cockpit was redesigned:
With SAP S/4HANA 1709, the Closing Cockpit is part of the SAP S/4HANA
core and is embedded with Fiori. In the future, it is expected to be more
automated and intelligent.
Faster closing
Higher efficiency
More governance
Higher compliance
More transparency
Key capabilities:
Basic prechecks
Preparation and migration of customizing for General Ledger
Preparation and migration of customizing for Asset Accounting
Preparation and migration of customizing for Controlling
Preparation and migration of customizing for Material Ledger
Preparation and migration of customizing for House Bank Accounts
Preparation and migration of customizing for Credit Management
Technical requirements
For this chapter, the following is required:
With this activity, you can check whether your customizing settings are ready
for migration to SAP S/4HANA Finance. This check determines whether the
ledger, company code, and controlling area settings meet all the prerequisites
for migration.
In this customizing activity, you define that users are informed by a message
when they want to post in the system although the migration has not been set to
finished.
ALERT
Only set the migration to complete after the following conditions have been
met:
To process the data to be migrated in the minimum amount of time, the Mass
data Framework is used to execute the different migration steps. During the
migration, the framework divides the data into packages and starts parallel
jobs to process the data in parallel. The number of jobs into which the system
divides the dataset is to be migrated in this activity:
Preparation and migration of
customizing for General Ledger
In this activity, we have to do the customizing settings for General Ledger.
Transaction: SPRO:
By completing this activity, the new IMG will be activated, which will have
all the configuration nodes for S/4HANA.
Checking and adopting Fiscal year
variants
When the GL is moving from SAP ECC to SAP S/4HANA, it is important to
note that it verifies that the Fiscal year variant in FI and CO should be the
same.
In this step, SAP checks the Fiscal year variants of the Controlling area and all
of the company codes assigned to that controlling area. Technically, the Fiscal
year variant of the Controlling area and all its company codes should be the
same. Any inconsistency can be handled separately.
Company-code assignments
Currency settings
Fiscal year variants
Open-period variants
Settings for realtime FI-CO integration
Any failure or warning needs to be handled before moving on to the next step.
Defining settings for the Journal
Entry Ledger
Before executing this IMG activity, the following prerequisites need to be met:
Once these prerequisites are met, the IMG node can be executed, and this
activity results in the Ledger definition. One ledger can be leading ledger 0L
and other ledgers can be configured based on business requirements:
All company codes need to be assigned to the leading ledger 0L, and company-
code assignments to other ledgers along with currency settings, Fiscal year
variants, and open-period variants for non-leading ledgers must be completed
here.
To learn more about having different Fiscal year variants, read SAP note #1951609
(S-User ID required): https://support.sap.com/en/index.html.
Defining ledger groups
Before we start with configuration, let's understand what a ledger group is.
When we create a ledger in SAP, the system generates the ledger group with
the same name, and data to any ledger can be posted and reported using the
ledger group. Ledger groups have the following main features:
For example, a separate document type can be created that can be used for the
reposting or allocation of primary costs. For document types used in CO, you
must select the G/L account indicator under the Account types allowed section.
Standard SAP has given the CO document type as standard, and if it is required
that it is replicated, it can be simply copied and renamed:
Defining document type mapping
variant
In CO, there are several business transactions, and it may be a requirement of
an organization to segregate those transactions by document type for internal
reporting and analysis purposes.
So, if we run the GL report for GL 600100, the offsetting account will be 122100.
Now, what will happen if the accounting entry has multiple lines? See the
following:
DEBIT 600100 Sundry Expense
DEBIT 600101 Rent Expense
CREDIT 122100 Bank Clearing
CREDIT 400100 Tax
Now, the credit side has two lines, so which one is the offsetting account?
Here, offsetting is needed for reporting purposes, and each business can have
their own way of reporting. In the configuration activity, this is taken care of.
In this activity, you define the offsetting account determination for all
applications. This activity needs to be executed before the migration to SAP
S/4HANA Finance. In this case, you must select the As case 2, but including
line items generated automatically option, because it displays the offsetting
account with the highest amount, along with the line items that are generated
automatically:
Defining the source ledger for the
migration of balances
When the migration is done, we need to tell SAP which ledger is to be
migrated, based on which it will read the tables.
In this configuration activity, the source ledger is selected, and the source
database table for the balances of SAP General Ledger from which the transfer
of the opening balances is needed. The following are used:
Target ledger
Company code (mention * if it needs to be executed for all company
codes)
Start Fiscal year (by specifying year 0001, you apply the settings for all
Fiscal years):
Executing consistency checks for
General Ledger
This is the final check for customizing settings.
Transaction—FINS_CUST_CONS_CHK
This needs to be executed before the migration of transaction data, and there
should be no error message. Verify that the passed message is visible, and in
case of any error, the necessary action needs to be taken:
Activating the business functions
In this activity, the business functions necessary for migrating to SAP
S/4HANA Finance are activated. The following given business functions have
to be activated by the Transaction code—SFW5:
Once the preparatory steps are completed, the migration from Classic to New
Asset Accounting can be started. Note that this configuration section only
migrates the configuration changes and not the master/transaction data. Also,
the Asset Accounting documents are migrated as part of the migration of
documents from the SAP General Ledger.
As part of the SAP landscape, the customer must have the customizing
system as well as the downstream system (test/preproduction and production).
The following steps will be based on the system, as explained:
Migrate all the charts of depreciation that are valid for all relevant company
codes in this step:
After performing all the necessary configuration steps, check whether it is OK
to activate New Asset Accounting:
Now, if all looks good, activation can be done; if not, the errors need to be
resolved before carrying out this step:
Apart from the preceding configuration steps, you need to ensure that all
relevant notes are implemented, and there is no data inconsistency in the
present system.
Preparing and migrating
customization of controlling
In this section, we will customize the settings for controlling. The first step is
to adapt the PA characteristics:
Transaction: KEQ3
SAP Customizing Implementation Guide | Controlling | Profitability
Analysis | Structures | Define Profitability Segment Characteristics
(Segment-Level Characteristics), since this summarization function is no
longer available in S/4HANA
Transaction: KEQ7
SAP Customizing Implementation Guide | Controlling | Profitability
Analysis | Flows of Actual Values | Initial Steps | Summarization
| Summarization of Account-Based Line Items and Profitability
Segments can be utilized
For operating concerns that are defined for costing-based CO-PA only,
summarized entries are retained and can be maintained afterward with the
KEQ7 transaction. Exceptions from summarization, as were possible in the
KEQ3 transaction, are no longer supported and therefore deleted. However,
summarization exceptions for the BUKRS (Company Code) characteristic can
still be defined in the KEQ7 transaction.
If the operating concern is not yet defined for account-based CO-PA, and it is
activated for the account-based version in the next migration step, Maintain
Operating Concern, the summarization settings will be deleted during the
generation of the client-independent environment (as would be done in this
activity for operating concerns already activated for account-based CO-PA).
In case it is already in use, the preceding activity will migrate the settings done
for the Material Ledger. Note that it only migrates the configuration and not the
data:
Preparing and migrating the House
Bank accounts customization
We already discussed the migration process of house bank in Chapter
7, S/4HANA New Functionalities - Cash Management, BPC, and Fiori UX, so
we will not repeat it, and will just cover the delta settings:
In step 1, we maintain the number range for the Bank Account Technical ID.
The system automatically assigns a technical ID to a bank account once it is
created in the bank account master data:
In step 3, we define the Bank Account Types and the Import method for the bank
statement.
In this customization activity, the Credit Analyst Group as the Business Partner
of the type group is defined. The assignment of the Credit Analyst Group to a
credit representative group is done in the following step:
Here, the groups for each credit control area are defined based on their need.
In a second step, each customer can be assigned to one of these groups in the
application menu for the Credit Management master data:
1. Create your groups.
2. Assign each customer to a group via the Credit Management master data:
You can use the BUB1 transaction to assign employees to a Credit Analyst
Group. Before this is done, it's mandatory to migrate all employees as business
partners using the /SHCM/RH_SYNC_BUPA_FROM_EMPL report:
This has to be done in the production system, and the following steps need to
be executed:
Here, the target values for Credit Management that are customer-specific are
defined. These settings are needed for the migration of the Credit Management
master data:
This is the final check. Here, the system checks whether the Credit
Management customization is set up correctly for the migration. The system
issues warnings or error messages in case of missing or wrong setup of
customization:
Summary
This concludes the preparatory activities required for migration. In the next
chapter, we will look at migration activities and then move to post-migration
activities.
Questions
1. What are the key steps in the premigration of Asset Accounting?
2. Why are the Credit Management premigration steps necessary?
3. What are the primary checks you need to perform during premigration?
Migration Activities
In this chapter, we will start with activities focused on migration. We will be
covering the following migration activities:
General Ledger
Controlling
Material Ledger
Cash Management
Asset Accounting
The progress of this program can be checked using the SLG1 transaction with
the FINS_GENERATE subobject:
Analyzing transaction data and
status display
In this activity, we will check whether all transaction data is complete and
correct. The following tables are checked:
BSIS_BCK
BSAS_BCK
BSID_BCK
BSAD_BCK
BSIK_BCK
BSAK_BCK
FAGLBSIS_BCK
FAGLBSAS_BCK
BKPF/BSEG/BSEG_ADD
Zero-Balance check
Check whether all document line items have a document
Check whether line items are missing
Check whether clearing information is missing
Check whether entries are missing or duplicated in backup index tables
Check whether information about archiving or partially archived
documents is missing in backup tables of indices
Check whether the clearing specific to ledger groups field is valid in the
line item table
Check whether all the currency information of the documents matches the
currency customization
Check whether the open item management flag of the master and
transactional data are identical
Check whether the document date of the document header is a valid date
Starting and monitoring data
migration
In this activity, the data migration activity can be started and monitored, which
is needed after S/4HANA installation. This activity groups up several
activities that we will see very soon. Wherever necessary or needed, you can
reset, repeat, and, to a certain extent, reschedule the individual activities of a
data migration run:
Overview
Control
Tables
Process control
Load balancing
Status of current migration run
Tables tab
On the Tables tab, the system displays the number of entries in the most
important tables that are involved in data migration.
Since we have now discussed how the migration runs and how we monitor it,
it is important to learn what is migrated as a part of this load and how the
entire process works.
Migration of cost elements
In SAP S/4HANA, the master data of G/L accounts and cost elements are
merged. Cost elements get special G/L accounts and are maintained in the FS00
transaction (Edit G/L Account Centrally).
Before the migration of G/L accounts and cost elements, a consistency check
needs to be done as to whether the G/L accounts and cost elements are
consistent or not. An inconsistency can be, for example, that no G/L account
exists for a primary cost element. All issues needs to be resolved before
migration, otherwise G/L account master records may have the wrong account
types after migration.
Once all issues are taken care of, migration can be done, and this migration
merges the cost elements into the G/L account master data. As there is no
default account assignment in the G/L account master, the migration of account
assignments in the cost element master to default account assignments
maintained via the transaction OKB9 needs to be done. The migration of cost
elements includes the following activities in the transaction that starts and
monitors migration:
The migration merges the master data of G/L accounts and cost elements. Cost
elements get special G/L accounts. In detail, the migration of G/L accounts and
cost elements provide the new database field type of a General Ledger account
(GLACCOUNT_TYPE) in the G/L account master with the following values:
This activity also needs adjustment in authorization for the creation of cost
elements.
Technical check of transactional
data
In this step, all the transaction data is analyzed by the system. It includes the
reconciliation as well as the status display. Let's see what is included in
reconciliation:
GL Document:
There must be new GL line items for every BSEG entry and vice versa
The amount must be the same if aggregated to BSEG level (BUZEI)
Every document must have zero balance, based on the new GL line items
The value of the following attributes must be the same:
Posting date (BUDAT)
Account (RACCT)
Currency key of transaction currency (RWCUR)
There must be an index entry for every document line and vice versa (if
required)
Equality of the following important fields:
Company code (BUKRS)
Document number (BELNR)
Fiscal year (GJAHR)
Document line (BUZEI)
Posting date (BUDAT)
Document date (BL BLDAT)
Company Code Currency (DMBTR)
Account number (SAKNR)
Account number in GL (HKONT)
Vendor number (LIFNR)
Customer number (KUNNR)
Flag/mark whether the corresponding document of an application index
entry is already archived (XARCH), is set correctly, as the original content of
the application indices is saved in tables with the prefix *_BCK
CO Document:
When an output is generated, the program displays a list of all clients for
which data processing is performed. For each client, it includes the processed
data packages and their processing status. The data packages are specified
using their technical names, such as company code, ledger ID, year, and
period. If mass data processing has not yet been performed for a client, the
processing status of the client is marked with a red traffic light.
Material Ledger migration
Material Ledger migration is mandatory in SAP S/4HANA, even if it is not in
use in the existing SAP system. Activities included in migration are as follows:
Migrate Material Ledger Master Data: With this activity, the system
migrates the ML data that is active for all valuation areas. It creates
Material Ledger Master Data in all applicable Material Ledger
currencies. Additionally, all the existing inventory aggregate values
(the MBEW, EBEW, QBEW, OBEW tables) and their complete historic data (the MBEWH,
EBEWH, QBEWH, and OBEWH tables) are migrated into the new universal journal
entry table ACDOCA. Period records newer than the last period of the
previous year are converted into Material Ledger currencies using the
standard exchange rate type. Periods older than the last period of the
previous year are only migrated in home currency. During migration
execution, the balance carry forward records (BSTAT= C and MIG_SOURCE= N)
are created automatically in table ACDOCA. If the Material Ledger is already
up and running, the existing Material Ledger records are also transferred
into the ACDOCA table with all currency information.
This migration activity does not activate actual costing, since actual
costing is still optional in SAP S/4HANA. However, if you are already
using actual costing in the migration source system, ML data for actual
costing will be transferred to new data structures to enable fast and
efficient cost calculation:
Material
Ledger
Optimized data structure
Document
MLDOCCCS ,
MLKEPH CKMLKEPH , (CKMLPRKEKO) for cost components split
Cost
in ML actual costing.
Component
Split
Similar to MLDOC_EXTRACT
but with an information
per cost component.
Extraction The MLDOC_EXTRACT
of Material MLDOCCCS_EXTRACT t
Ledger be used especially to
MLDOCCCS_EXTRACT Document - calculate information
Cost about the beginning
Component inventory in a specific
Split period, by cumulating
quantities and values
from all previous
periods.
Also, for all ML costing runs created in the start release, the post closing step
needs to be finished. It will not be possible to process costing runs created
earlier in the new release. The posting logic of the new actual costing has been
changed in some details. These changes require the following adjustments in
the account determination:
Fixed Assets:
If there is a difference between the old total table and aggregated line
items, the missing depreciation line item in the ANLP table is created.
These correction lines in ANLP are created with PERAF = ‚999'.
In some cases, in statistical lines, ANEP-XANTEI had not been updated
properly. This is corrected by setting the ANEP-XANTEI field to 5.
Migration of line items
The migration of line items consists of the following activities:
New GL Line Item tables (such as FAGLFLEXA), inclusive of the Industry and
Customer tables
Cost Totals for External Postings (COSP)
Costs Totals for Internal Postings (COSS)
Document Header (ANEK) and Line Items (ANEP) for Asset Management
In addition, there are consistency checks for ACDOCA:
You must execute this step before you migrate the balances.
Migration of balances
Published financial statements were created in the past based on totals records.
New reporting with SAP S/4HANA is based on the Universal Journal (ACDOCA)
and determines the totals for reporting by aggregating on the fly to the
Universal Journal. The Migration of balances step ensures that after migration
of the documents, the aggregated view to the Universal Journal delivers the
same results as the previous totals-based reporting. For aggregation to ACDOCA,
the corresponding compatibility views (for example, COSP and FAGLFLEXT) are
used.
The migration of balances consists of the following activities in the Start and
Monitor Migration transaction:
After the migration of balances, the results of the migration are checked.
The aggregated values of the ACDOCA table are compared again with the
values from the old totals tables. If there are discrepancies, they are
displayed in the reconciliation of the total migration.
Calculation of depreciation and total
values
The determination of the cumulative depreciation of an asset and the posting of
depreciation expense takes place in the system at different points in time:
This activity is needed to initially build the planned depreciation values for
Asset Accounting and is based on the program Calculate Depreciation.
Prerequisites:
1. Run the program as a test run with extended checks and have the log
displayed.
2. Analyze the messages, resolve any errors, and consider the warnings.
3. Once any problems have been resolved, run the program again in update
(non-test) mode. If a large number of records are to be migrated, it is
advisable to execute the report in the background. You can also restrict
the operation to a set of individual ledgers.
4. Check the log and ensure that no problems are reported.
1. Select the house bank accounts that you want to migrate and specify a date
in the Opened On field.
2. To set an account type for multiple house bank accounts, select the house
bank account entries, and then choose the Set Account Type button.
3. Execute the program.
4. The system generates bank accounts based on selected house bank
accounts. You can check the migration status by checking the status icon
displayed at the end of each house bank account entry:
Green: The house bank account entry is linked to a bank account
master record, and the house bank is assigned to the bank account in
the master record.
Yellow: The house bank accounts have been migrated to or created in
Bank Account Management in an earlier version of SAP S/4HANA
Finance for cash management. You need to execute the program again
to update the data.
Red: The house bank account entry is not yet linked to a bank
account master record. If the status of a house bank account remains
red after you have executed the program for it, you can check the
migration log for more information. To access the log, in transaction
SLG1, specify the BAM_MIGRATE object:
Additionally, the following information is not stored with house bank accounts
and therefore they cannot be created by the program automatically. If
necessary, in the Web Dynpro application (transaction code NWBC), you can
manually maintain the following attributes for each bank account individually,
or use the Import and Export Bank Accounts tool to massively import data from
an XML file:
As a business partner in FIN-FSCM, the customer has only one risk class for
all segments. To ensure that the correct risk class is migrated, you should have
one consistent risk category for the customer in all credit control areas. The
credit limit of the main segment for customers is calculated according to the
following logic:
If you map a credit control area to the main segment itself, the credit limit
is migrated from this credit control are a
If you didn't map a credit control area to the main segment, and you have
maintained the central master data for the customer, the credit limit will
be taken from this central master data
If you didn't map a credit control area to the main segment, and you
haven't maintained the central master data for the customer, the credit
limit will be calculated as the sum of all credit limits of all credit control
areas of the customer:
The following programs help compare the data and key figures after the
migration with the data before the migration:
Once you execute this, the system performs the following checks:
Completed check: The system checks whether another user has already set the
migration to complete. In this case, an information message is issued, and it is
not possible to set the migration to complete again.
Customizing the consistency check: The system checks whether the ledger
settings are consistent; if an error occurs in this step, you can't set the migration
to complete.
Redirect check: The system checks whether the following tables have been
replaced by CDS-views (so-called compatibility views). As long as the
redirect hasn't been performed, the system will not work properly. The
following tables are checked—ANLC, ANLP, ANEK, ANEP, ANEA, COEP, and COVP,
(additionally, in S/4HANA—MBEW, MBEWH, EBEW, EBEWH, QBEW, QBEWH, OBEW, and OBEWH). If
an error occurs in this step, you can't set the migration to complete.
Count ACDOCA: The system checks whether the documents have been
migrated to the Universal Journal. For this, the number of records in ACDOCA is
compared with the number of records in COEP, BSEG, and FAGLFLEXA. If the number
of records in ACDOCA is not plausible, an error is issued. If an error occurs in this
step, you can set the migration to complete anyway, but you need to be sure that
this is done correctly.
Check pending packages: The system checks whether all steps of the
migration have been performed successfully. All steps must be finished, and if
errors occurred, they must be set to accept.
Summary
This concludes the migration activities that need to be performed during
migration to SAP S/4HANA. Now, we will start with the post-migration
activities.
Questions
1. What are the components of data migration?
2. What is migrated in GL allocations migration?
3. What are the prerequisites for setting migration to complete?
4. What is done in analysis of transaction data?
5. What are CDS views, and how are they important?
6. Which key components are migrated in Credit Management migration?
Post-Migration Activities
In this chapter, we will start with the activities required after migration. We
will cover the following post-migration activities:
Hold on if any errors are generated, otherwise move on. Errors need to be
checked, analyzed, and corrected before proceeding. You can use the SM37
and SLG1 transactions to complete it.
Enrichment of balance
carryforward
S/4HANA allows you to update balance carryforwards in more detail than was
possible in ERP. According to business requirements, attributes can be defined
for the balance carry forward. For example, for each reconciliation account,
the account assignments of the subledger for the balance carryforward can be
used to analyze a reconciliation account for claims by a customer account.
Settings for enrichment of balance
carryforward
In this step, for each ledger, the fiscal years of the balance carryforward to be
enriched need to be defined:
Master data
Credit-exposure data and payment behavior
Initialization of documented credit decisions
The following must be done for each unmigrated customer before you continue
with these activities:
That's how the learning journey is, and practicing more in-system will help you
to grasp hold of the steps, understanding issues, and coping with challenges.
Questions
1. Why are post-migratory steps important?
2. What is intercompany reconciliation?
3. How will you test Universal Journal?
4. List the manual activities in credit management.
5. What is an offsetting account?
6. What are the prerequisites for setting the migration to complete?
7. What is a prerequisite for the analysis of transaction data?
8. What are CDS views and why are they important?
9. Which key components are migrated in credit-management migration?
Central Finance – a No-Disruption
Approach
In this chapter, we will talk in detail about Central Finance. Central Finance
is named as a non-disruptive approach for S/4HANA implementation. We will
be covering the following areas:
Corporate controllers
FICO users
Shared services center
Business Unit Controller
Management team
IT architects
Strategy Architects
Business process owners
Solutions team
Master Data Governance and Owners
Security and authorization teams
Audit teams
Key business benefits and use cases
Central Finance offers major business benefits in the following areas, as it
combines several systems and simplifies the architecture from a reporting
standpoint:
Issue: Organizations using SAP have diverse landscapes, which include several
systems and face issues in maintaining the systems, such as synchronization.
Key objective: SAP S/4HANA with Central Finance enables customers to use the
S/4HANA functionality without disrupting the current landscape.
Central Finance comes with the following capabilities that an organization can
leverage from operational and strategy perspective:
Settlement rules for the supported cost objects mentioned are not
replicated
It is not available in standard to automatically create and map the
following:
Process Orders
WBS Elements
Fixed assets
The limitations in Central Finance with fixed assets are these:
Let's see how it changes when the SAP systems are of different releases:
Now, let's discuss the role and nature of each system involved.
Source system
In a very generic case, any release of SAP ERP and any Non-SAP system can
be connected to Central Finance, or you can say that Central Finance can
receive data from any available system. SAP S/4HANA Central Finance can
be used with all SAP ERP releases that are still under maintenance, starting
from SAP ECC 6. Read SAP Note 2323494 (https://support.sap.com/en/index.html)
for more details. Systems on release level 4.6C, 4.7, and ECC 5.0 can still act
as a source for Central Finance, but the implementation requires manual
implementation. Non-SAP systems, including SAP Business ByDesign and
SAP Business One, can be connected to Central Finance using SLT.
System Landscape Transformation
System Landscape Transformation (SLT) is the tool used as a middleware,
which extracts data from Source system, transforms it based on set rules, and
loads it into the receiving system.
In the Central Finance scenario, the initial load and delta replication (covered
in detail in the same chapter) is done by SAP SLT. DB triggers will detect all
changes (update, insert, or delete) and will send them to SLT. SLT will feed an
interface on the target Central Finance system. We can call it a technical
enabler that feeds the receiving system. Here are some of the technical options
for the Source system and DB:
Option 1: When a Source system is SAP and a DB licence is for full use:
In addition to the errors relating to, for example, the initial load for cost
objects, errors for the online transfer after initial load from all scenarios (cost
objects, FI postings, and CO secondary-posting documents) can be handled in
the Central Finance system using SAP AIF.
It provides the calendar view, where the user can hover the mouse and see the
number of messages per date:
Red: Error
Green: Successful
Grey: No data interfaced:
Central Finance interfaces
Implementing Central Finance involves several interfaces that feed the data to
the Central System extracted from the Source system after several cleansing
and changes in-between, which may be mapping, rule, or any custom build
logic. The following figure summarizes the involved interfaces:
Mapping actions:
Keep Data: In this case, the field values are not mapped at all; the data
from the sending system is retained and transferred.
Mapping Obligatory: In this case, the field values for all updated fields
must be mapped to a field. If no mapping data exists, the system will raise
an error.
Clear Data: In this case, the updated fields are always cleared and
nothing is transferred to the receiving system.
Map if Possible: In this case, the system tries to map any filled field. If no
mapping data exists, there is no error and the original data from the
sending system is transferred.
The standard SAP default setting is for all. Mapping entities that have no
mapping action marked are not mapped, and the value updated from the sender
system is carried forward to the receiving system:
Initial load and real-time replication
There are different kinds of initial loads, and those should be done in the
following sequence:
For historic data, the new tables are not filled yet. Initial load is based
on posted FI documents (the existing tables) and tries to merge
information from related CO documents:
Initial Load of Balances:
Manual Activities:
Package–KBAS:
3. Implement note 2137557 (version 20 or later, ideally the most recent) and
execute the created ABAP report, FIN_CFIN_NOTE_2137557, following the
instructions given on the start screen.
4. Confirm that the BSEC_T table type is available in the system.
This does not need to be executed as the table already exists in SAP
ECC:
Start the SE37 transaction, enter the function module name, and click
on Change
On the attributes tab, set the processing type to Remote-Enabled
Module
Save and activate the function module
Implement the given notes in the sending system. Ensure that the sequence and
prerequisite details (from the Comments column) are followed:
Sr. SAP
Details Comments
# Note #
Error in tax items with Check the latest note
1 2034029 FI_DOC_TO_ACC_TRANSFORM before implementing
Incorrect assignment of BUZEI
2 2210341 in function module Prerequisite is # 1
FI_DOC_TO_ACC_TRANSFORM
If the Source system has been enabled using OSS-note and not by applying the
corresponding support package, the CFINIMG transaction does not exist. In this
case, open the VCFIN_SOURCE_SET maintenance view using the SM30 transaction.
After the SAP Notes are implemented or after enablement via support pack,
follow these steps as applicable:
Sr
Field Description
#
Company All company codes that are part of the Central
1
code Finance implementation need to be updated here.
Enter the year from which the system is expected to
Start - start transferring balances. The system always takes
2
balances the balances starting from the first fiscal period of
that year.
Start - Enter the year from which you want the system to
3
documents start transferring documents.
Period - Enter the first period of that year from which you
4
documents want the system to start transferring documents.
Periods Last period of the FY 12.
5
Check this if GL reconciliation postings triggered in
GL CO should be replicated to the Central Finance
6 reconciliation system during initial load. Should only be set if
postings T/F secondary costs are not transferred during initial
load.
Initial load Check this once initial load is complete. This
7
finished improves performance.
8 Package size Standard SAP is 50.
In some cases, it may occur that after applying the latest content, the system is
not able to generate the runtime objects for the CFIN_ACCHD table in SLT. The abort
happens because of an error message that states that for the CFIN_ACCIT_PDS table,
no DDIC information can be retrieved. The CFIN_ACCIT_PDS table is missing from
the Source system. To solve this issue, perform the following steps:
3. In the Specify General Data tab, update the configuration name (no
spaces) and add a description, as desired:
4. Under Specify Source System, choose RFC Connection and enter the RFC
destination:
5. Under Specify Target System, choose RFC Connection and enter the target
system in the RFC destination field. In the scenario for RFC
Communication field, choose Standard RFC scenario:
In the SE38 transaction, start the IUUC_REPL_PREDEF_OBJECTS program and enter the
mass-transfer ID created by the system:
Defining the initial load object
1. Choose Copy Predefined Object and enter REPL_CFIN in the Project and
Subproject fields.
2. In the Predefined Object field, specify the predefined initial load object.
Use the value help to view all the available objects.
3. For every table, there is a load object and a replication object. The load
object contains the L (CFI_L) suffix. Select one of the load objects.
4. Under Target Object, specify the table name. Use the same table that you
specified for the predefined object. For example, if the predefined initial
load object is CFI_AUFK_L, the corresponding table name will be AUFK.
5. Ensure that the Create Predefined Load Object option is selected.
Confirm the settings.
6. Repeat the process for the other tables:
Defining the replication object
1. Choose Copy Predefined Object and enter REPL_CFIN in the Project and
Subproject fields.
2. In the Predefined Object field, specify the predefined replication object.
3. For every available table, there is a load object and a corresponding
replication object. The replication object can be identified with the R
suffix (CFI__R). Select one of the replication objects.
4. Under Target Object, specify the table name. Use the same table that you
specified for the predefined replication object. For example, if the
predefined replication object is CFI_AUFK_R, your table name is AUFK.
5. Ensure that the Create Predefined Replication Objects option is selected.
Confirm your settings.
6. Repeat the process for the other tables:
Activating the Initial Load and
Replication Objects
Now, you have to navigate back to the overview of predefined objects (with
the UUC_REPL_PREDEF_OBJECTS program) and set the status of the initial load as well
as the replication objects as Active:
Control Load/Replication using the
SAP LT Replication Server
Replication with SAP SLT:
Once the objects are activated, the SAP LT Replication Server can be
used to control the load and replication of data. In the SAP LT Replication
Server Cockpit (the LTRC transaction), enter the mass-transfer ID. On the
Table Overview tab page, the table can be stopped or started by choosing
the Data Provisioning push button.
Enter the table (AUFK, CFIN_ACCHD, COBK) for which the predefined objects are
defined and choose Start Replication.
The replication status in the SAP LT Replication Server Cockpit (the
LTRC transaction) can be monitored. On the Data Transfer Monitor tab
page, the table name is there once the initial load or replication object has
been created. Logs on the Application Log tab page can be checked.
Before the log entries can be viewed, the filter must be defined. The log
contains details about any problems that occurred during the replication
process and details about data that could not be replicated to the target
system because of incorrect settings.
S/4HANA system
In order to implement Central Finance, the S4HANA system, which will be the
Central System, needs to be ready so that scenarios for Central Finance can be
executed, including the online replication:
Sr SAP
Note details Prerequisite
# Note #
Central Finance: Collective Note for
1 2135027 2144933
Corrections
Central Finance: Collective Note for
1a 2144933
Corrections in 1503 SPS 1505 (part 1)
1b 2154524 CFIN: Error in note 2144933
Central Finance: Collective Note for SP1
2 2142433 2155340
Correction (part3)
Central Finance: CKPRCH-009 error
3 2155442
during initial load
Central Finance: Collective Note for
4 2179997 2180067
Corrections in 1503 SPS 1508 (part 2)
CO Posting Interface Enhancement for
5 2161786 SAP Simple Finance, on-premise edition 2164800
1503 SPS 1505
Central Finance: Collective Note for SAP
6 2178157 Simple Finance on-premise edition 1503 2179826
SPS1508 – CO part
Central Finance: Collective Note for SAP
7 2211878 Simple Finance on-premise edition 1503 2214462
SPS1511 – CO part
Currency Handling Fix of CO Posting in
8 2217711 Central Finance
SAP AIF is the functionality that distributes the error messages to different
users as per need. In the case of Central Finance, the errors are available under
the /FINCF namespace. Errors from all scenarios of replication (initial load
and real-time replication) can be handled here.
Here are the basic steps to be executed in order to complete the configuration:
Transports:
FINS_CFIN_AIF_GEN
FINS_CFIN_AIF_POST
FINS_CFIN_AIF_CO
Implement notes
Functional steps:
If the use of the Interface Monitoring (/AIF/IFMON) and Monitoring and Error-
Handling (Web) (/AIFX/ERR_WEB) transactions is intended and alerts are expected
via email, the following settings must be configured:
Namespace: /FINCF
Recipient for Alert: CFIN_RECIPIENT
Message Type: Application Error or Technical Error
Select the Include on Overview Screen checkbox
To successfully set up the SAP AIF, the following number ranges need to be
maintained. The number range objects are as follows:
/AIF/AH
/AIF/FNR
/AIF/SNAP
Additionally, the following number range objects are required for SAP AIF
2.0:
/AIF/IFG
/AIF/ISG
/AIF/RUN
/AIF/VPN
The following number range objects are required for SAP AIF 3.0:
/AIF/CS
/AIF/FNR
This section describes the setup to be done in the Central System in order to
use the S/4HANA system as a Central Finance system.
Basic System Setup
Normally, the decimal places are the same in the Source and S/4 systems.
For any currencies with differing numbers of decimal places, enter the
number of decimal places as defined in the Source system. For currencies
that have the same number of decimals in the source and Central Finance
systems, you do not need to make any entries:
Mapping
Click the highlighted button and the following screen will appear:
Header Details
Business System Business System
Logical System Logical System
RFC Destination RFC Destination
Logical File Path Logical File path
Download to PS Yes
Unicode Empty
Unicode Code Page 0
Disabled for replication Empty
If a central cost object exists, the system enters the relationship between
the source cost-object and the central cost-object in an assignment table
(covered in the next section).
If a central cost-object does not exist, the system creates a central cost-
object and enters the relationship between the source cost-object and the
central cost-object in an assignment table. The properties of the cost
object in Central System are derived by the characteristics of the cost
object of the Source system (from the column marked earlier).
Repeat this for all the applicable scenarios.
Clearing Functionality
ALERT: This should only be activated after the initial load is complete, otherwise it is
possible that all technically cleared items can be reopened by the FINS_MIG_CJ3
transaction in the target system so that the affected clearings cannot be processed
later on.
1. After implementing this note, start the FINS_MIG_CJ3 transaction in the target
system to reopen the items that have been technically cleared in the target
system and are still open in the Source system:
2. By using the FINS_MIG_MONITOR_CJ3 transaction in the target system, you can
check whether all the relevant documents have been successfully
processed:
Let's consider an example. Open items and clearings are transferred from
company code A in the sender system to company code B in the target system.
Company code A in the sender system has only one local currency.
Company code B in the target system has the same local currency as company
code A and an additional second local currency. If the exchange rate of the
second local currency is changed between when the invoice is posted and
when the corresponding clearing document is posted, the line item containing
the resulting exchange rate difference for the second local currency will be
missing in the clearing document in the target system.
Central Payments
Central Payment is part of the SAP S/4HANA 1709 release, and it normally
allows customers to execute centralized payments and centralized clearing
activities in one S/HANA Central Finance system rather than doing those
separately in every connected Source system. The key features of Central
Payments are as follows:
This is how the mapping to the Central Profitability UJE is done when the
Source system has Costing-based COPA:
The following is the method for mapping the characteristics:
Summary
With this, we complete our end-to-end configuration of Central Finance,
including the Source system, SLT, and Central System. We also understood the
limitations of Central Finance. This is one of the key areas that organizations
are focusing on. I would recommend you go through it once more as there is lot
of demand for this area in projects, and it's important to understand it
completely before you go to the client. Now, I have a task for you. What?
Assess yourself.
Questions
Since we have completed a detailed discussion on Central Finance, try to
answer these questions and do a self-assessment:
SAP Best Practices also cover the integration and migration basics. They are
basically designed to guide users through an optimized migration process. SAP
Activate also provides a reference solution with sample data already included
in the product with clear guidelines, and with step-by-step directions on how
to move from the current landscape to the end goal. With SAP Activate,
customers can determine whether the end objective is a new implementation, a
conversion of a system, or a transformation of the large landscape. SAP
Activate kicks off with SAP Best Practices in implementation and uses a single
methodology for all available deployment modes—cloud, hybrid, and on-
premise. The end goal of SAP Activate is to help customers take advantage of
all the key features of SAP S/4HANA to fit in with their circumstances and
business needs.
Pillars of SAP Activate
Activate has three core pillars:
Solution Builder:
Expert configuration:
From experience, I can tell you that almost no customer project can be
implemented without adjustments
Customers typically want to add new processes or adjust preconfigured
business processed delivered by SAP Activate
With expert configuration, you can create your own scope items and
(delta) building block(s) for any complementary content development at
your side:
Methodology
This includes the following:
Start fast, build smart, and run simply to accelerate the time to value,
while continuously innovating with SAP S/4HANA
Onboard simple and fast with trial offerings containing test data
SAP Best Practices provide the foundation for each implementation and
give customers a kick start to move on with
Cloud-ready:
When we use the cloud-ready version, we will have the following benefits:
Validate Solution:
At this point, we validate the solution:
Premium engagement:
Agile solution:
Introduces the agile approach as early as possible and trains the project
team
Follows the standard agile process and applies relevant principles
Focused approach on business priorities first
Frequent structured reviews with business users
Quality features are already built in for the Standard SAP system.
A quality gate provides the insight into and early-stage visibility of the
potential risks and issues. It has a profound impact on reducing risks and
ensuring value for the customer.
It's a formal way of specifying and recording the transition within stages
of projects.
Each gate ensures that acceptance is met for the deliverables required and
actions are completed for any critical piece.
Project quality gate plans are defined in project management plans.
There are four quality gates mandatory for SAP implementation projects
Within complex projects or projects with open risks that are critical,
additional Q-gates may be executed
Within agile projects, Q-gate reviews are implemented for each release
A preview at the beginning of the prepare phase is mandatory
Q-gates carried out at any time can influence the project timelines and
results
Review
Ensure that all necessary standards and approaches have been
established:
The Activate methodology structure
The methodology breakdown has four key areas:
Phase
Work stream
Deliverable
Task
Methodology:
Definition of phase:
Here is the work stream description for SAP Activate:
Now, let's learn about the accelerators and their descriptions by the phases of
the methodology. Let's start with Prepare:
The following are the roles and responsibilities at each level within an
organization from the governance perspective:
KPI ownership
Scope and budget adherence
Identification, resolution, and communication of issues and risks
Day-to-day execution of project tasks and managing documentation
Business priorities, goals, and objectives
Status reporting
Communication to project management office (PMO)
Activate journey – new
implementation (cloud)
SAP Activate can be used for new implementations on the cloud model:
Prepare phase: In this phase, the project teams conducted the initial
planning and preparation activities to get the projects started.
Explore: In this phase, the project team reviews the solution scenarios to
match them with business requirements and determine what can be met
within the solution boundaries and scope. Configuration values are
identified and added to the backlog list that can be used in the Realize
phase. Activities included are these:
Realize: In this phase, the project team uses a series of iterations to build
and test the complete business environment incrementally based on
business scenarios and process needs. Key activities are as given:
Prepare: The Prepare phase provides the initial planning and preparation
of the prophecy, including the project organization and governance as
well as the schedule, budget, and management plan. The project team is
trained, and the necessary infrastructure is set up. Once the scope is
validated, the team identifies the solution and Best Practices for customer
needs:
Explore: Here, we validate the delivered solution based on the process
documentation. In the following solution-validation workshops, the delta
scope will be prioritized and followed by delta design workshops. This
provides the basis for the Realize phase:
Realize: In this phase, the solution is built and tested incrementally based
on the scenarios and process requirements identified in the Explore
phase. Adoption activities occur and operations are planned:
Deploy: The purpose of this phase is to finalize the readiness of the
organization, its solution, and the necessary supporting tools and
processes to go live. It includes these steps:
Testing
User training
System management
All cutover activities
Activate journey – system
conversion
While using SAP Activate for system conversion, the four phases remain the
same, however, their meaning changes:
Prepare: The Prepare phase provides the initial planning of the project
with a budget, resources, and timelines. The formal project needs to be
set up, and the readiness assessment needs to be completed:
Explore: The Explore phase drives the detailed planning from the
technical aspect of the conversion. By the end of this phase, the technical
and functional conversion is planned in detail and is ready for execution.
The migration plan includes all the steps of data migration and volume
management. After the planning in the sandbox system, the validation is
planned:
Realize: The Realize phase outlines the necessary steps for migration to
SAP S/4HANA. The IT infrastructure needs to be set up, and systems
need to be completely configured, tested, and validated. Training needs to
be prepared and the custom code needs to be adjusted as needed. The
non-production environment needs to be migrated and validated in this
phase:
Here's how the work streams are aligned between these methodologies:
Summary
This concludes our chapter on greenfield implementation. We also looked at
the SAP Activate methodology, and we compared the features with previous
implementation methodologies, such as SAP Launch and ASAP. Try to answer
the following questions for self-assessment. We will discuss about NZDT in
the next chapter.
Questions
1. What are the main advantages and benefits of using SAP Best Practices?
2. Which elements are included in the guided configuration?
3. Describe the key elements and changes in the SAP Activate framework.
4. Which elements of SAP Activate are more beneficial?
5. Which methodologies are succeeded by SAP Activate?
6. List six key characteristics of SAP Activate.
The Near Zero Downtime (NZDT)
Strategy
In this chapter, we will be discussing the Near Zero Downtime (NZDT)
strategy, which is generally needed when we are migrating from SAP ECC to
SAP S/4HANA, and helps in reducing business downtime. For the sake of
usage, we will be using the term NZDT in this chapter. We will be covering the
following topics:
During the final downtime, when the project is going to be live, only some
activities are required to be executed. The phases of NZDT are as listed here:
Recording
Clone
Upgrading to EHP7 and installing the S/4HANA add-on
Initial S4HANA migration and data validation
Delta Replay
Downtime
When the recording phase is going on, there are some restrictions applied to
the business:
ISBN: 978-1-78847-036-0