openSAP

Key Functional Topics in a System Conversion to

SAP S/4HANA
Week 2 Unit 1

00:00:06 Hello, my name is Sheldon Edelstein. I am a product specialist for the S/4HANA
00:00:11 Regional Implementation Group. My area of focus is Finance
00:00:15 and today I will be presenting a quick Introduction to Finance in S/4HANA.
00:00:22 Finance in S/4HANA is designed as the next- generation finance solution for SAP.
00:00:28 The data model design is based upon a single source of truth
00:00:32 for financial and managerial accounting. All financial data is stored at a detailed level
00:00:39 of granularity in a single repository. Data replication and the use of aggregated
00:00:45 and total tables are eliminated. Reporting and analysis is based on the line items
00:00:51 rather than preconfigured totals. Thus, you have the highest granularity available
00:00:56 and your analysis is not delayed by having to configure and maintain reporting aggregates.
00:01:04 Within the HANA database, you can analyze large amounts of data quickly,
00:01:09 and S/4HANA allows you to access all dimensions of that data.
00:01:13 For example, there's over 240 characteristics that can be found in a typical
00:01:18 universal journal table alone. The month-end closing process is accelerated.
00:01:25 Some steps can even be run on a daily/weekly basis rather than just at period end.
00:01:31 The S/4HANA data model is populated at a detailed level of granularity but can easily be
adaptable
00:01:38 by allowing customer specific fields. Regulatory controlled industries
00:01:43 such as banking and insurance, for example, can require adding up to 80 additional fields
00:01:49 to enhance the level of detail required. Fiori is focused on improving user experience,
00:01:56 not just within reporting, but also for all operational activities.
00:02:01 There are hundreds of predefined roles and delivered content that's available with a focus
00:02:06 on a world-class user interface and experience for the financial user.
00:02:11 And finally, S/4HANA is pioneering the use of machine learning for finance operations
00:02:17 such as account payable, allocations, and tax solutioning, freeing up the analyst to focus on
decision- making.
00:02:27 Key to the S/4HANA Finance evolution is the concept of the universal journal,
00:02:32 also sometimes referred to by its technical name, ACDOCA. This innovation evolved from the
recognition
00:02:40 that earlier ERP systems created separated data persistencies
00:02:44 for each of the various financial subprocesses, such as General Ledger, Profitability, Material
Ledger,
00:02:51 Asset Accounting, and Controlling. Reconciliation between these subprocesses
00:02:57 was resource consuming since the data was stored at different levels and each sub-process
00:03:03 had its own unique data model. Availability of the data was delayed
00:03:08 due to complex settlement processes that moved data between the subprocesses.
00:03:14 S/4HANA re-engineered this data model into the universal ledger concept
00:03:19 that takes the best from all of the subprocess worlds and combines them into one universal
solution.
00:03:26 The key benefits of this solution are: one line item table with full detail for all subprocesses.
00:03:34 Data is stored only once, no reconciliation needed, by architecture design.
00:03:40 A significant reduction of memory footprint is achieved through elimination of data redundancy.

00:03:48 And fast multi-dimensional reporting is available directly on the Universal Journal.
00:03:53 And last, elimination of data access latencies due to no need to replicate data to a BW system.

00:04:01 The universal journal enables efficient processing throughout finance.

00:04:06 Finance, Controlling, and Profitability are merged into one continuous and real-time process.
00:04:12 Real-time derivation of controlling characteristics is performed during line item entry.
00:04:18 And parallel accounting for multiple accounting standards such as IFRS and GAAP are
available.
00:04:27 There's enablement of planning and consolidation without data replication,
00:04:31 including predicative and simulation capabilities. And last, every organization must close the
books,
00:04:38 so why not automate as much as possible and quickly gain insight from a group perspective.
00:04:45 We talked about the new engineering data model for S/4HANA, but SAP recognizes that our
customers
00:04:52 have significant investments in customizations and reporting based upon legacy ERP
modeling.
00:04:59 S/4HANA protects these investments by delivering compatibility views
00:05:04 that simulate access to the same legacy data. These views are populated at runtime only,
00:05:12 meaning that they do not persist the data, but rather will access data from the new S/4HANA
tables
00:05:19 when called upon in real time. This switch is automatic; no user intervention is required.
00:05:25 This innovation allows customers to reuse their customized code
00:05:29 and reporting after migration into S/4HANA. Earlier ERP financial solutions required special
ledgers
00:05:38 to provide additional functionally separate from the primary ledger.
00:05:43 The special ledger concept required the replication of the primary ledger into the special ledger

00:05:49 resulting in an explosion of data redundancies and reconciliation problems.

00:05:55 S/4HANA introduces the concept of extension ledgers to eliminate these data redundancies
and reconciliation concerns.
00:06:05 Data is no longer replicated. Extension ledgers are logically grouped
00:06:09 with the standard ledger and are accessed using specific read and write methods.
00:06:15 As an example during the writing activities, posting data to the standard ledger
00:06:20 is persisted only once in the standard ledger. And posting data to the extension ledger is valid
00:06:26 only for the extension ledger, no effect on the standard ledger at all.
00:06:30 From a read perspective, during a read request to the standard ledger,
00:06:35 the user sees only data in the standard ledger. And a read request to the extension ledger
00:06:40 is automatically extended as a read request to both ledgers.
00:06:44 If the extension ledger is targeted on a report, the system will select data from the union of
both ledgers.
00:06:52 Multiple extension ledgers can be associated with one standard ledger,
00:06:56 enabling the use of extension ledgers for new S/4HANA concepts such as finance simulation,

2
00:07:03 predictive accounting, and statistical condition generation. S/4HANA allows the evolutionary
transition
00:07:12 from traditional hard close financial operations to new closing concepts, such as a fast close,
00:07:19 enabled by the elimination of many non-value added tasks, such as reconciliation tasks.
00:07:26 Real-time execution, as an example, posting expenses to a cost center
00:07:31 can automatically derive profitability information. And continuous execution,
00:07:36 the closing task is not gone, but it's much smoother and faster.
00:07:41 Thus, it can be easily run multiple times within the period.
00:07:46 Soft close: It's continuously being able to close the books and have immediate live insight.
00:07:52 This is accomplished by eliminating period-end tasks. Profitability characteristics can be
derived automatically
00:08:00 during item posting. No need to wait until month-end settlement is performed.
00:08:05 And predicted close: Predicted actuals can be derived
00:08:09 to predict the period-end results The new closing concepts lead us
00:08:16 to the ability to provide instant insights in our financial position.
00:08:20 With real-time derivation of characteristics, continuous close operations,
00:08:26 parallel processing across multiple accounting standards. These all result in enriched financial
statements
00:08:33 with deep access to item-level details. Here's a simple example of the power
00:08:39 of this architectural change, which brings the enhanced income statement.
00:08:44 We can view it completely classically by the account structure.
00:08:48 Then we can drill down by many dimensions, such as company code, profit center,
00:08:52 business area, functional area and the various partner characteristics as well.
00:08:58 But we can also drill down to dimensions that used to be only available by switching
00:09:02 to controlling reports, such as cost centers, work breakdown structures
00:09:07 or WBS elements, and customer groups. I hope you have enjoyed this brief introduction
00:09:13 to S/4HANA Finance. You are invited to continue your journey
00:09:17 and learn more details about S/4HANA Finance in the next openSAP session.
00:09:22 Thank you for your time.

3
Week 2 Unit 2

00:00:05 Hello, and welcome back to week two, unit two of the openSAP course, System Conversion to
SAP S/4HANA.
00:00:13 My name is Ajeet Agarwal. I am a Senior Consultant from Solution Delivery Center,
00:00:17 LoB Finance, located in Bangalore, India. I'm a part of SAP S/4HANA Regional
Implementation Group.
00:00:24 I will be your host for this unit. You have learned in the finance overview session
00:00:29 that the changes between the old SAP ERP world and the new SAP S/4HANA system are very
fundamental
00:00:36 and therefore also impact current processes. In this unit, we will go over the essential changes

00:00:44 in the Finance area from a functional and a technical perspective.

00:00:50 This will help you to understand which are the main activities you have to consider
00:00:55 in finance for a system conversion from SAP ECC to S/4HANA...
00:01:08 Let's have a closer look into the new universal journal. What are the impacts for a system
conversion
00:01:14 and which activities are therefore necessary during finance conversion?
00:01:20 First, the universal journal is based on the ledger technology that we already know
00:01:24 from the new G/L world. S/4HANA incorporates many of the functions from the new G/L.
00:01:35 However, new G/L is not a prerequisite for converting to S/4HANA,
00:01:40 and if you are using classic G/L still you can directly migrate to SAP S/4HANA.
00:01:48 It's not mandatory that first you do a new G/L conversion, then go to S/4HANA.
00:01:53 So from classic G/L also, you can move to S/4HANA, which will move all line items from
classic ledger, let's say 00,
00:02:01 or that is table GLT0 to ledger 0L in universal journal table ACDOCA.
00:02:08 And you can do the conversion in any of the periods during the year.
00:02:13 You can implement additional ledgers for parallel valuation or introduce document split
00:02:19 in a separate project after the conversion. And it requires a first fiscal-year close in S/4HANA.

00:02:26 Also you can introduce new currencies in universal journal after conversion
00:02:32 to SAP S/4HANA 1809 or higher. Please keep in mind
00:02:36 that during a conversion, you cannot implement additional ledgers
00:02:43 or document split, or you cannot switch from account-based approach
00:02:50 to a ledger-based approach. If you have extended the coding block,
00:02:56 the extension fields included in structure CI_COBL are automatically contained in ACDOCA
00:03:04 and considered by data migration. If you are upgrading to S/4HANA from a system
00:03:10 where customer fields have been added to table COEP or BSEG via an append structure,
00:03:18 please check the corresponding SAP Note; that is, 2160045. Also, secondary cost elements
are now created
00:03:27 as G/L accounts, and any posting to secondary cost element would update
00:03:32 in the universal journal also. In CO-PA, the account-based profitability analysis
00:03:39 is integrated into and migrated into the universal journal. Then it contains all CO-PA
characteristics
00:03:47 for detailed reporting and drill-down. Stock valuation data is transferred
00:03:53 from material ledger tables to ACDOCA. The last application we see here is asset accounting.

4
00:04:03 In S/4HANA new asset accounting is mandatory. Actual data from FI-AA table ANEK, ANLP,
and so on
00:04:11 is also migrated into table ACDOCA. So currencies.
00:04:21 Let's take a closer look at the currencies. What are the options?
00:04:26 In the Business Suite, ECC world, there used to be three currencies
00:04:31 in FI and two parallel currencies in CO. In CO that was CO area currency, and the second one

00:04:38 was object currency, and there were three currencies in material ledger.
00:04:43 But with S/4HANA, the universal journal supports a maximum of up to 10 currencies,
00:04:51 but in a system conversion the old currency configuration,
00:04:54 is migrated without change. You cannot introduce new a currency
00:05:03 as part of your conversion project. With release S/4HANA 1809, it is possible
00:05:09 to introduce a new additional currency type to a ledger in the universal journal, subsequent to
system conversion.
00:05:18 However, it is not possible to introduce a new BSEG-relevant currency;
00:05:23 that is, a second or third FI Currency. For detailed understanding on introduction
00:05:28 of new currencies in SAP S/4HANA, you may refer to SAP Note 2344012.
00:05:39 And there's one more note which tells you about introduction of new currency
00:05:45 that you can also take a look at. That is 2334583.
00:05:53 The table BSEG is not and will not be extended and still contains only three parallel
currencies.
00:06:00 The BSEG relevant currency type can be configured in the overview screen of the company
code assignment
00:06:07 in transaction FINSC_LEDGER in the columns to the right of first, second, and third FI
currency.
00:06:17 Currency types in the customer namespace are not allowed as BSEG-relevant currency.
00:06:23 So customer namespace currencies are allowed only in the universal journal,
00:06:26 in those 10 currencies, not in BSEG. Let's see what other changes are mandatory.
00:06:37 What are the next important applications in finance you have to consider in a system
conversion?
00:06:42 First is SAP Credit Management. Historically, SAP had two solutions for credit management:
00:06:49 Credit Management in FI, AR and SAP Credit Management in FSCM.
00:06:55 In S/4HANA, only SAP Credit Management based on FSCM is available.
00:07:00 You have to migrate from FI-AR to a basic edition of SAP Credit Management of FSCM.
00:07:08 The migration is done during the conversion. Please refer to the corresponding SAP Note
00:07:14 for more information. It also contains a task list in the attached PDF.
00:07:21 The note number is 2270544. Take a look at the SAP Cash Management.
00:07:31 Classic Cash Management is not available anymore in S/4HANA and the new solution,
00:07:36 is the new SAP Cash Management, which is based on the new One Exposure table.
00:07:41 A customer using classic Cash and Liquidity Management needs
00:07:44 to activate the new SAP S/4HANA Cash Management during conversion to SAP S/4HANA.
00:07:50 A basic version of the new SAP Cash Management is available and required
00:07:54 for bank account management in S/4HANA. It is called Bank Account Management Lite
00:08:01 or BAM Lite. It is a compact version of Bank Account Management provided
00:08:08 for customers without the license of SAP Cash Management. During the system conversion,
00:08:15 you have to migrate house banks accounts into the new Bank Account Management.
00:08:21 House bank accounts then can only be maintained via the SAP NetWeaver business client

5
00:08:26 or using SAP Fiori in S/4HANA. You can find the feature scope document,
00:08:34 which explains the difference between BAM Lite or Bank Account Management Lite version
00:08:38 versus fully fledged Cash Management version with the note 2270400.
00:08:49 Okay, then Trade Finance. Regarding finance, the letter of credit processing
00:08:55 has been replaced by Trade Finance in SAP Treasury and Risk Management, that is TRM.
00:09:01 It is integrated with SAP S/4HANA Sales. A migration has to be done during the accounting
conversion.
00:09:08 For more information, see SAP Note number Real estate, revenue accounting,
00:09:19 and business partners. Let's say what's there in S/4HANA.
00:09:25 For customers who are using Real Estate Classic need to migrate to Real Estate Flexible, RE-
FX.
00:09:33 So as part of a migration project, it is not possible to migrate after switching to S/4HANA.
00:09:40 You have to do this migration prior to starting your S/4HANA project.
00:09:45 Migrating data from Classic Real Estate to Real Estate Flexible
00:09:49 is not a simple technical conversion. This conversion must be planned as a project
00:09:55 and executed similar to legacy data transfer. Migration programs are available as technical
support
00:10:02 for the data transfer project. For more information, you may refer to SAP Note 2270550.
00:10:11 The existing Revenue Recognition solution in SD has been deprecated due to its limitations
00:10:16 and will not be working in SAP S/4HANA. It cannot be used for new accounting standard
IFRS15.
00:10:24 The new solution in SAP Revenue Accounting and Reporting is compatible with SAP
S/4HANA.
00:10:30 A migration to SAP S/4HANA Revenue Accounting and Reporting needs to be done
00:10:34 before you upgrade your system to SAP S/4HANA. This is very important
00:10:39 because after conversion to SAP S/4HANA, you cannot migrate your revenue,
00:10:46 existing revenue regression to a new area. So you are to so this conversion prior
00:10:51 to starting your S/4HANA project. You need to migrate all sales orders
00:10:56 and contracts that are in process. For more information, you may refer to
00:11:01 SAP Note 2225170. Let's see what there are in the business partner
00:11:11 because this is one of the major important points, which affects every customer
00:11:15 who's migrating to S/4HANA. As you may be aware,
00:11:20 there is now a single transaction code BP which takes care of all your customer
00:11:27 and vendor creation. But before that,
00:11:29 what about our existing customer and vendors? Those have to be migrated to our business
partners.
00:11:35 So these business partners and customer vendor integration
00:11:38 are now mandatory in S/4HANA. Before you do the technical installation
00:11:42 of S/4HANA you have to do a business partner migration. You will learn more about how the
business partner
00:11:50 migration happens in a separate unit. But you can refer to SAP Note 2695353
00:11:58 for more insight about this. Let's see what other important areas are
00:12:06 in Asset Accounting, new G/L, and accrual engine. New Asset Accounting was already
available
00:12:13 as of SAP ECC 6.0 EHP 7 with business function.
00:12:20 The business function's name was FIN_AA_PARALLEL_VAL. It was introduced to portray
parallel valuation based
00:12:29 on the new G/L ledger approach. You can migrate from SAP ECC new G/L or classic G/L to

6
00:12:37 SAP S/4HANA universal journal. Please note that the number of ledgers
00:12:41 and the configuration of its currency will stay. It is not possible to introduce new ledgers
00:12:47 or new currencies during the migration to S/4HANA. If classic general ledger was used,
00:12:53 the ledger 00 is migrated to new leading ledger 0L of the universal journal.
00:13:00 If you have not used the new general ledger before, that means that you still have used
00:13:05 the classic general ledger before migrating to SAP S/4HANA.
00:13:09 Please be aware that the handling of the foreign currency evaluation,
00:13:13 the line item display, and the balance carried forward has slightly changed.
00:13:17 Please make yourself familiar with the new handling of them in new G/L
00:13:24 before the migration. So for more information,
00:13:27 you may refer to SAP Note 2270339. Accrual engine:
00:13:34 In release S/4HANA 1809, a new accrual engine was developed. It is called S/4HANA accrual
engine.
00:13:42 The accrual engine supports all currencies of the general ledger.
00:13:46 Postings can be performed on ledger level instead of only accounting-principle level.
00:13:52 The number of database tables has been reduced. For example, the original document of the
accrual posting
00:13:59 is now contained in the universal journal table, that is ACDOCA.
00:14:04 With S/4HANA release 1809, you need to migrate the content of the old database table
00:14:11 of the old accrual engine into the new table of the S/4HANA accrual engine.
00:14:16 This affects customizing table as well as transactional tables of the accrual engine.
00:14:25 For more information, you may refer to SAP Note 2582884. Let's see what is there
00:14:36 in the machine learning space, accelerated close, and predictive accounting.
00:14:41 Let's talk about the machine learning. Financing is most prone to automatization
00:14:47 by cutting-edge technologies. So cash application is a classic example,
00:14:54 which empowers business to focus on developing innovative strategies
00:14:59 and growth plans with intelligence receivable matching automation
00:15:04 that handles manually intensive financial processes. Some other machine learning applications

00:15:12 are, for example, GRIR reconciliation, tax compliance smart automation, and so on.
00:15:20 This machine learning uses Cloud Platform to enable necessary computational power.
00:15:27 What is there in the accelerated close? S/4HANA helps in accelerating the period-end
00:15:34 closing, year-end closing. and some of the examples are unified financial, statutory,
00:15:40 And managerial accounting into a single source of truth. So everything is stored in a single
source of truth;
00:15:45 that is, the universal journal ACDOCA. Significant reduction in reconciliation effort
00:15:52 and batch jobs resulting in lower costs. Real-time derivation
00:15:57 of attributed profitability characteristics and updated into universal journal or on a real- time
basis.
00:16:04 So no need to wait for the month end and then after settlement,
00:16:07 you may see what the profitability characteristics are, and so on, but you can analyze the
characteristics information
00:16:16 in real-time on the universal journal using this attributed profitability analysis.
00:16:21 SAP S/4HANA Financial Closing cockpit makes sure of perfect planning,
00:16:26 automation, and monitoring. Then automate consolidation of multiple currencies
00:16:32 and reporting standard to reduce manual effort and error. These are some of the important
things,

7
00:16:40 and you may refer to SAP Note 2332547 for a better understanding.
00:16:49 Predictive accounting: This enables you to look at
00:16:53 and analyze data using a forecast of future results based on the most up-to-date data.
00:17:00 It enables you to have a better understanding of your results at the end of the quarter,
00:17:06 period, or maybe year. And when a sales order is created,
00:17:11 predictive accounting creates the corresponding goods issue and invoice.
00:17:18 The results of the simulation are stored as journal entries in an extension ledger.
00:17:23 Entries created during sales order are posted into the extension ledger,
00:17:29 not into the main ledger. So this is how it is designed, okay?
00:17:36 Then the current data from the underlying base ledger, enables you to see a forecast, for
example,
00:17:42 of the revenue for one product. To see the forecast, and analyze the data,
00:17:53 SAP offers two Fiori apps, which you can implement
00:17:59 and then for further detailed understanding, you can refer to this SAP Help document on this
area.
00:18:10 Consolidation: So what has changed with consolidation? SAP's group reporting tool facilitates
00:18:20 not just in the preparation of financial statements as per statutory regulations,
00:18:25 but also has added capabilities for facilitating managerial consolidation and analytics.
00:18:32 The new group reporting tool combines the best of the features and capabilities
00:18:37 of existing consolidation solutions. So that is like EC-CS, BCS, BPC, Embedded BPC,
00:18:45 and well-integrated with SAP Analytics Cloud. Some key capabilities of group reporting
include:
00:18:53 local and group close in the same tool; flexible rules for data validation:
00:18:59 currency translation; inter-unit elimination; consolidation of investments;
00:19:05 data collection options; release from universal journal;
00:19:11 flexible upload of reported financial data; or published APIs from other SAP or customer
applications,
00:19:19 so you can also get the data from other applications which are not part of S/4HANA,
00:19:24 and you can load to APIs; record ownership information using journal entries
00:19:30 on statistical items. Plan consolidation is based on the integration
00:19:35 between SAP S/4HANA and SAP Analytics Cloud. A mandatory prerequisite for running group
reporting
00:19:42 is to install the SAP Best Practice configuration content. That scope item is 1SG for the
solution.
00:19:50 You can only make configuration settings in SAP Customizing for SAP S/4HANA
00:19:54 for group reporting IMG after that. Once you've implemented 1SG,
00:20:01 then only you can basically do the configuration changes. SAP group reporting
00:20:07 is SAP's strategic consolidation solution moving forward, in particular for customers
implementing SAP S/4HANA,
00:20:13 irrespective of deployment option, whether it is cloud or on-premise.
00:20:18 With this, we come to end of this unit, I hope you enjoyed this unit.
00:20:24 Thank you.

8
Week 2 Unit 3

00:00:05 Hello, and welcome to week two, unit three of the open SAP course System Conversion to
SAP S/4HANA.
00:00:13 My name is Ajeet Agarwal. I am a Senior Consultant from Solution Delivery Center, located in
Bangalore, India.
00:00:21 I am a part of SAP S/4HANA Regional Implementation Group. I will be your host for this unit.
00:00:27 You have learned last week essential changes in finance in SAP S/4HANA.
00:00:32 In this unit, we will go over the essential changes in Controlling from a functional and technical
perspective.
00:00:40 This will help you to understand which are the main activities you have to consider
00:00:44 in Controlling from a system conversion. SAP S/4HANA brings financial accounting
00:00:53 and management accounting closer together. One line item table, ACDOCA, introduced with
SAP S/4HANA,
00:01:01 which contains complete details of Finance and Controlling components together.
00:01:07 The reconciliation between financial and management accounting is no longer needed,
00:01:11 as this is reconciled by design. All cost elements are created as a G/L account,
00:01:18 including secondary cost elements as well. I will explain more on this topic in the next slide.
00:01:25 In CO-PA, the account-based profitability analysis is integrated and migrated into the universal
journal.
00:01:33 The ACDOCA then contains all CO-PA characteristics for a detailed reporting and drilldown,
00:01:40 which makes it possible to take real-time multi-dimensional reporting without replicating data to
BI.
00:01:48 If BI is in place, then only one single BI extractor is needed compared to many as in SAP ECC
today.
00:01:58 You can still use costing based CO-PA, but we recommend activating
00:02:03 the new account-based CO-PA in S/4HANA. You cannot migrate from cost-based CO-PA
00:02:12 to account-based CO-PA, but you can start with account-based CO-PA
00:02:17 in S/4HANA directly after the conversion. Technically enhanced important structural
capabilities
00:02:25 of the financials solution to support multi-GAAP, additional 10 currencies are supported.
00:02:33 As already mentioned, for valuated stock material ledger is obligatory in S/4HANA.
00:02:39 Stock valuation data is transferred from material ledger tables to ACDOCA...
00:02:53 The master data transactions for cost elements, for example KA01, KA06, and so on,
00:02:59 are outdated and can no longer be used in S/4HANA. Only one master data maintenance for
G/L accounts
00:03:06 and cost elements is available. You can use that transaction code FS00.
00:03:14 The universal journal contains postings from all cost elements, including secondary cost
elements,
00:03:20 and these secondary cost elements are now created as a G/L accounts in SAP S/4HANA.
00:03:27 It also means that you have to include the secondary cost elements in the profit and loss
structure
00:03:34 of FSV in FI for reporting. Otherwise, it will be showing as nothing.
00:03:41 CO postings also create an FI document, and you have to do some Customizing
00:03:46 like the FI document type for CO postings... ACDOCA stores full details of actual CO postings
also.
00:04:04 Actual data stores in former tables – that is, COEP, ANEP, MLIT, and so on – is now stored in
ACDOCA.

9
00:04:12 However non-actual are still stored in CO table; that is, COEP.
00:04:17 BSEG is only written in case open item-managed accounts are affected.
00:04:23 So BSEG's primary purpose is handling of open items for payables, receivables, and taxes.
00:04:29 Profit center accounting: FI special purpose ledger works as before.
00:04:34 In case FI special purpose ledger was posted via activity COFI, real-time integration,
secondary cost elements,
00:04:43 which are now G/L accounts, are posted directly and no mapping to a primary cost element is
required.
00:04:51 So EC-CS is like Enterprise Controlling- Consolidation System works as before with the new
G/L
00:05:00 real-time integration, but now including secondary cost elements, which are G/L accounts.
00:05:06 The system works now with the original CO activities like RKU1, instead of using the activity
COFI,
00:05:13 which was the case in ECC. Costing-based profitability analysis works as before.
00:05:19 However, there is no plan to enhance costing-based COPA in future.
00:05:24 Rather, most of the enhancement would be on account-based profitability analysis,
00:05:30 and it's recommended to activate account-based COPA... What about custom code and
reports,
00:05:43 those we are using in old tables, so in the ECC environment?
00:05:50 So from the perspective of an ABAP program that requires read access, nothing has changed,

00:05:55 as SAP provides compatibility views. These compatibility views redirect

00:06:01 the select statement to the new persistency in S/4HANA. As a result, custom ABAP programs
00:06:07 that read directly from tables like FAGLFLEXA or COSP via select statements continue to run
as before.
00:06:22 However, there is one exception to this statement; that is, for example, in material ledger
00:06:28 due to the fundamental changes in actual costing, the new solution is not backwards
compatible,
00:06:33 and there is no compatibility view available, specifically for the material ledger actual costing
side.
00:06:42 Line item table COEP is still available for non- actual data. It is still stored in COEP.
00:06:48 So non-actual data will be stored in the COEP table in S/4HANA as well.
00:06:53 However, actuals are now stored in ACDOCA. This is the main difference
00:06:57 with actual and non-actual data. So if you view entries in SE16 or read data from COEP
00:07:04 in a custom program, the selection is redirected to a view that reads actuals from ACDOCA
00:07:12 and non-actual data from COEP, the existing table. So how can you see the original content
00:07:22 from table COEP after conversion? To get the original content,
00:07:27 you have to use the corresponding view that we deliver. For example, the view V_COEP_ORI
for entries in COEP.
00:07:37 Our original content is still stored for any reference.
00:07:42 During a conversion, data from tables or index tables that are not used in S/4HANA anymore,
00:07:48 like FAGLFLEXT or GLT0, are moved into backup tables that is _BAK for CO at the end and
_BCK for FI at the end.
00:08:02 Again, the CO tables COSS_BAK and COSP_BAK are still used for non-actual data, as I
mentioned before.
00:08:13 the BSEG table is still used to keep the prime note for the document entry view.
00:08:20 Please note that BSEG doesn't contain all G/L postings anymore in S/4HANA.
00:08:27 The long-term vision is that table BSEG will be used only for open item management.

10
00:08:34 As a first step towards this vision, postings from Controlling like assessments, distributions
00:08:41 do not create entries in table BSEG. These entries are created directly in the universal journal;

00:08:48 that is, ACDOCA. Also foreign currency valuation postings

00:08:53 don't create entries in table BSEG anymore. So we recommend adapting custom reports
00:09:00 to the new table; that is, ACDOCA. If material ledger is not already active
00:09:09 it has to be activated during the accounting conversion process.
00:09:13 The material ledger can store up to three currencies and uses the currencies defined for the
00:09:18 leading ledger in financials. Stock valuation in parallel currencies
00:09:24 is automatically activated during migration. Prices and stock values are automatically
translated
00:09:31 into parallel currencies. After the conversion, you might see,
00:09:35 depending on your system setup, multiple currencies in MM02:
00:09:40 for example, values in company code currency and global or controlling area currency.
00:09:47 In MR21, material prices can then also be maintained in parallel currencies.
00:09:55 For more understanding about this material ledger, you may refer to SAP Note
00:10:04 Another important thing is actual costing in the material ledger.
00:10:08 So actual costing is still optional. It's not mandatory, like your material ledger is mandatory,
00:10:14 but actual costing is still optional in S/4HANA. And there is no need to switch to the standard
price.
00:10:20 It is also not possible to activate actual costing during conversion.
00:10:24 Data structure for actual costing has been simplified, and the steps at the period end for actual
costing
00:10:31 has been completely redesigned from the 1610 version onwards.
00:10:36 If actual costing was active, material ledger data is migrated into the new tables MLDOC and
MLDOCCCS
00:10:44 during accounting conversion. But all results are finally available
00:10:49 in ACDOCA as the universal journal. For detailed understanding, you may refer
00:10:54 to SAP Note 2354768. Transfer pricing: So if multiple valuations are active,
00:11:05 the values for legal, group, and profit center valuations are stored in the same ledger.
00:11:12 These valuations are stored in a separate amount column in the same ledger,
00:11:17 in the universal journal. That approach is called multi-valuation ledger,
00:11:22 and this is the default option for a system conversion. For detailed understanding on available
options
00:11:30 on transfer pricing, please check this SAP Help document... This is very important to
understand
00:11:46 in terms of when we talk about material ledger is obligatory versus actual costing is optional.
00:11:51 So because there is a lot of myth in the market, so we wanted to clarify what the customer
understood
00:11:57 and what SAP wanted to say. We never needed ML, and now we have to use it.
00:12:05 A lot of extra work in implementation. Extra work for each month-end closing.
00:12:10 Standard price and moving price are no longer available. This was the kind of discussion
00:12:16 among customers and partners. But none of these statements are true
00:12:21 when we talk about the reality. But what we wanted to say is,
00:12:26 material ledger and finance are now responsible for material valuation.
00:12:30 Only one solution as a principle of one. We said, okay, we'll not store the data in two different
tables,
00:12:36 ML separate and FI separate, so data will be stored only in the material ledger table.

11
00:12:44 That is why it has become mandatory. But there is no extra work at each and every month
end,
00:12:50 that will alarm it. So the reality is that most customers will experience
00:12:55 no consequences of the SAP development decision. When we talk about actual costing,
00:13:07 this is the status of the actual costing data model and processing steps in SAP S/4HANA,
00:13:12 which you must be aware of if you're using actual costing. Until SAP S/4HANA 1511 releases,
this was the status.
00:13:20 However, this has been simplified drastically with SAP S/4HANA 1610 onwards,
00:13:25 which you will see in the next slide. This new data model for actual costing
00:13:33 is valid from SAP S/4HANA 1610 version onwards. So what is the motivation behind this
simplification?
00:13:42 Acceleration: a new magnitude of acceleration of the overall settlement.
00:13:47 We observed very significant reductions in runtime of the whole closing cockpit, CKMLCP.
00:13:54 That is minutes instead of hours, you can imagine. So ML close should be achievable on a
single working day,
00:14:02 including rework and resettlements. Simplified processes: So if you see separate process
steps,
00:14:11 like single-level settlement, multi-level settlement, revaluation of consumption, and WIP,
00:14:18 these four processes are merged into one single step that is called settlement.
00:14:26 Then, of course, simplified data structure. So more than 20 relationally coupled tables
00:14:33 are replaced by only two column store tables. That is how it has been simplified technically
also.
00:14:41 Simplified calculation logic: Algorithms are unified and better reproducible.
00:14:48 Minimized rounding errors, less non-distributed values. No need for a constant preliminary
value.
00:14:56 No rescaling of differences in alternative valuation run. So these are some other important
parameters.
00:15:04 Of course, there are fewer restrictions, so you can change the standard price,
00:15:10 during the period anytime, even after goods movement. So some of the other key changes,
00:15:22 let's have a look at this. New period interval: new period interval 3
00:15:28 introduced with S/4HANA in finance open/close period transaction OB52,
00:15:33 which specifies the open and closed posting periods, which are coming from
00:15:39 Controlling to Financial Accounting. So this controls that.
00:15:43 Then default account assignment: Default account assignment, which would be maintained
00:15:48 in cost element in ECC environment, for example. So that has been removed,
00:15:54 and now default account assignment can be maintained with transaction OKB9 only.
00:16:01 And if you have some default account assignment already maintained in cost element in SAP
ECC world,
00:16:07 so those will be move to OKB9 automatically as part of your finance conversion steps.
00:16:15 Then optimized transactions. These HANA optimized transactions
00:16:21 for Controlling period-end closing are developed in line with the new data structure,
00:16:26 and these transaction codes are ending with H. So, for example, we were using KO8G.
00:16:34 Instead of using KO8G, we'll be using KO8GH, so it is optimized.
00:16:39 Similarly we have other transactions, KKS1H, CO88H, so for detailed understanding,
00:16:46 you may refer to SAP Note, 2541629. Enhancement of profitability analysis:
00:16:58 SAP recommends account-based CO-PA, as we mentioned before also, in S/4HANA,
00:17:03 based on some key innovations such as COGS split, variance posting category wise,
00:17:09 additional quantity fields, reconciliation by design and realtime analytics

12
00:17:15 in account-based CO-PA is possible. The account-based COPA uses cost elements
00:17:20 to store the same values for various attributes like revenue, cost of goods sold, and so on.
00:17:28 However, the posting logic in traditional account- based COPA was such that cost of goods
sold and variances
00:17:37 could only be mapped to a single GL account/cost element. This was the case in ECC.
00:17:42 So now this has been simplified and improved. This was one of the basic reasons
00:17:48 why most SAP customers were preferring to use costing-based COPA instead of account-
based COPA.
00:17:55 However, this has been enhanced with S/4HANA, and now you can have the same break up
00:18:00 in account-based COPA, which which was available only in costing-based COPA.
00:18:07 The usage of account-based COPA in SAP S/4HANA ensures that there are no more time-
consuming
00:18:14 painful reconciliation required to be done anymore. Of course, you can still use the costing-
based COPA
00:18:24 in addition to account-based COPA. And for detailed understanding,
00:18:29 you may refer to FAQ note 2176823... This universal allocation:
00:18:42 Existing allocation method lacks some of the key features and hence this was decided
00:18:47 to build a universal allocation tool to address the existing challenges.
00:18:51 That is, organizations struggle to understand their allocation processes.
00:18:58 Analysts struggle to answer allocation questions. Tools lack simulation capabilities.
00:19:07 Tools lack state-of-the-art visualizations. We will build the single platform, universal allocation
00:19:13 covering General Ledger, Profit Center Allocation, Cost Center Allocation, Profitability
Analysis,
00:19:19 Joint Venture Accounting, Special Purpose Ledger, and Intercompany.
00:19:22 So these are the processes which will be part of universal allocation.
00:19:26 This is our vision. However, we are not fully there yet. However, as a first step, profit center
00:19:32 as well as cost center allocation is planned to be delivered with the SAP S/4HANA 1909
release.
00:19:43 Planning: So what has changed with respect to planning? If you're looking for a planning
application
00:19:49 tightly integrated with SAP S/4HANA. SAP Analytics Cloud should be your first consideration,

00:19:55 as it is our strategic direction for overall analytics, bringing together planning, reporting,
00:20:02 and analytics capabilities in one single platform. BPC version for B/WHANA is recommended
00:20:09 as a solution for on-premise planning and consolidation. And you can still use BPC for real-
time planning
00:20:17 on SAP S/4HANA on-premise as well. So your investment in BPC is protected
00:20:23 and you can move capabilities to SAP Analytics Cloud when you are ready.
00:20:29 With this, we come to the end of this unit, I hope you enjoyed this unit. Thank you.

13
Week 2 Unit 4

00:00:05 Hello, and welcome to week two, unit four of the openSAP course on System Conversion to
SAP S/4HANA.
00:00:12 My name is Martin Schmidt. I am an S/4HANA Product Expert,
00:00:15 and I'm your host for this unit, Conversion of Accounting – Overview.
00:00:19 In this unit, I will give you an overview of finance-related conversion activities
00:00:24 in conversion of accounting, sometimes referred to as a finance data migration.
00:00:29 It is the part of a system conversion when transactional and some of the master data in finance
applications
00:00:34 is transformed into the new data model of the universal journal.
00:00:38 It is probably also one of the most critical parts of any conversion to S/4HANA.
00:00:43 First of all, it's important to understand what is the position of finance data migration
00:00:48 in the overall SAP S/4HANA system conversion. To answer this question, let's quickly look
00:00:53 at conversion process and see when exactly finance conversion comes into play.
00:01:00 So here, on the picture, you can see an overview of the phases of a system conversion
00:01:05 with all tools involved. Last week, you already learned that the conversion project
00:01:10 has two main phases; the Preparation phase, with application-specific activities,
00:01:15 and the Realization phase, again, with application-specific follow-on activities.
00:01:20 In the Preparation phase, first, you need to make sure that your source system fulfills
00:01:24 all the system requirements on operating system version, database version, and the patch
level.
00:01:31 Then you run the maintenance planner, which is our cloud-based tool for system landscape
planning.
00:01:39 The maintenance planner will check the status of business functions in your system
00:01:44 and if add-ons installed on your system are compatible with SAP S/4HANA.
00:01:48 If an add-on is not supported, the conversion would be stopped.
00:01:52 If all checks are successful, the maintenance planner generates mandatory XML stack file
00:01:58 for consumption by the Software Update Manager tool. Then you run the detailed simplification
item check,
00:02:04 which will analyze your system and give you a detailed overview
00:02:07 of simplification items relevant to your system. In addition, it will run consistency checks
00:02:13 for configuration, master data, and in some cases, also for transaction data.
00:02:19 After that, you need to analyze your custom code to identify parts which need to be adapted to
the SAP S/4HANA model.
00:02:29 In parallel, you must perform application-specific preparation activities.
00:02:34 In finance, it starts with reviewing simplification items. I recommend not to take this step lightly.

00:02:42 With S/4HANA, there are significant changes to functional scope when compared to SAP ERP.

00:02:48 In certain cases, things go as far as to replace the whole application components with new
solutions.
00:02:56 In some cases, the new solutions might use different concepts, which might impact
00:03:00 your business processes. Also, for components which have not been replaced
00:03:05 with new applications in SAP S/4HANA, you can expect some extensive functionality changes.

00:03:12 In the next step, you need to first check your configuration settings
00:03:18 and adapt Customizing to make sure that all prerequisites are met.

14
00:03:22 You might consider, also, archiving data which is obsolete or which is no longer used.
00:03:29 You need to check transaction data and correct any data inconsistencies.
00:03:36 Finally, as a part of cutover for conversion, you perform closing activities
00:03:41 and document your financial closing for later comparison. Once all preparations are complete,

00:03:48 it's time to run Software Update Manager. This is the tool which does the actual technical
conversion
00:03:54 with all the tasks, such as database migration, installation of software update,
00:03:59 and application data migration in logistics. With the start of Software Update Manager,
00:04:06 you are also entering the Realization phase, and it is also the start of downtime.
00:04:13 Now, in contrast to logistics, the conversion of accounting is not done during the SUM phase,
00:04:18 but must be executed from the Implementation Guide menu after finishing Software Update
Manager.
00:04:24 The SUM tool only creates the necessary tables, such as Universal Journal table ACDOCA,
00:04:29 but it leaves them empty. You can see on the slide that conversion of accounting
00:04:35 has three main stages; preparation and migration of customizing, data migration,
00:04:40 and activities after migration. So let's take a closer look at them
00:04:48 To execute conversion of accounting, you need to log on to the technically already
00:04:53 converted SAP S/4HANA system, go to IMG, and perform the activities step by step
00:05:00 and in the right sequence. The first stage is preparation and migration of Customizing.
00:05:08 Before you start with data migration, you need to perform certain Customizing
00:05:12 for relevant application areas, such as general ledger, Asset Accounting, CO-PA, material
ledger,
00:05:19 house bank accounts, credit management, and trade finance. Some of the configuration is
concerned
00:05:25 with settings for migration itself. Some of the configuration is needed
00:05:29 because of functional changes in SAP S/4HANA. To make the entire process easier for you,
00:05:35 SAP provides programs for automatic migration of some configuration settings.
00:05:41 The second stage of conversion of accounting is data migration.
00:05:45 Here, transactional data is transformed into the new data model of the universal journal.
00:05:51 In addition, some of the master data is migrated as well. For instance, secondary cost
elements are merged
00:05:58 into the G/L account master data and house bank accounts are migrated
00:06:02 to the new bank account master data. Most of the migration activities
00:06:08 are integrated into the Start and Monitor transaction. This is the main transaction to carry out
00:06:15 and monitor the results of data migration to universal journal.
00:06:20 The transaction will execute the data migration activities and ensures the right sequence of
them.
00:06:27 It provides an overview of all performed migration runs. You can analyze errors.
00:06:32 You can repeat and reset migration activities. Now, once you finished all data migration
activities,
00:06:39 you set migration to completed. This will trigger last checks for consistency
00:06:43 and completeness of the migration. If there are no relevant errors, the migration is completed
00:06:49 and postings in the system are again allowed. Technically, this means the end of system
downtime.
00:06:55 The last stage conversion of accounting are activities after migration.
00:07:01 After data migration and when you have set the data migration to completed,
00:07:07 there are still some more activities to be done. For example, you need to fill Due Date fields

15
00:07:13 and Offsetting G/L Accounts fields in relevant document tables, or you can enrich
00:07:18 balance carryforwards with additional dimensions, for example from a material ledger
00:07:23 or Asset Accounting, and so on. These activities do not necessarily have to be performed
00:07:28 during downtime, but if possible, I would recommend conducting them
00:07:33 before allowing users to use the newly converted system. As already mentioned, during the
first two stages,
00:07:42 no postings are allowed in the system, and business users are normally locked out from the
system.
00:07:51 Now, during the conversion, always, the entire system is converted to SAP S/4HANA.
00:07:56 Software Update Manager is able to perform the conversion for all clients within the system.
00:08:02 However, conversion of accounting must be executed for each client separately.
00:08:08 Moreover, there is no option to explicitly exclude a company code from finance data migration.

00:08:14 In standard S/4HANA conversion scenarios, all company codes must be migrated.
00:08:21 Still, there might be valid reasons why you don't want to bring over data from certain company
codes.
00:08:27 For instance, company codes might be obsolete and no longer in use.
00:08:32 Understandably, you do not want to spend time and effort on preparation tasks for such
company codes.
00:08:38 In addition, data might not be in the best shape and you don't want to spend time with error
messages
00:08:45 for irrelevant company codes before or during finance data migration.
00:08:52 Currently, there are only two options available for how to handle obsolete company codes.
00:08:58 The first one is to archive. If you wish to completely exclude
00:09:02 an existing company code from migration, the only solution available is actually
00:09:07 to fully archive the company code data before conversion. The second partial solution is to
mark
00:09:13 a company code as a template. So if you want to disable some of the migration prechecks
00:09:19 in the general ledger area, you can mark obsolete company codes as templates in the
transaction code available,
00:09:25 which is available after installation of S/4HANA. However, please note that these settings do
not impact
00:09:34 checks in other areas, such as Asset Accounting. In addition, there is a special scenario which
is called
00:09:40 company-code-specific conversion to SAP S/4HANA. Its main purpose is to move company
code data
00:09:47 from the SAP ERP system into an already existing S/4HANA system. However, this scenario is
not generally available
00:09:56 and requires paid service from SAP. It is done using so-called
00:10:00 SAP Landscape Transformation software, and there are a number of additional prerequisites.

00:10:11 Let's talk now about consistency checks and data inconsistencies, which are one of the areas

00:10:18 where our customers face the biggest challenges during conversion of accounting.
00:10:23 In order to successfully complete the finance data migration part of an S/4HANA conversion,
00:10:28 you need to have clean and consistent data. Unfortunately, no matter how well you manage
00:10:34 the integrity of your data, chances are that you are going to have some errors in it.
00:10:40 How does a company end up with inconsistent data? Well, there are many reasons for that,
00:10:45 for example inconsistent updates made by custom-developed programs or interfaces,

16
00:10:51 improper Customizing or master data changes, for example switching on
00:10:56 and switching off open item management or the line item display for G/L account master data
00:11:02 without following the proper procedures. Then, you may have made direct updates to standard
tables,
00:11:09 or we can also have application errors in our software. In general, you are more likely to run
into problems
00:11:17 with inconsistent transactional data if your company has a large volume of data, a lot of
custom code,
00:11:24 history of data conversion projects, such as new G/L migration or euro conversion,
00:11:30 and if you do not reconcile data regularly during the year-end close process.
00:11:36 Now, given that data closing is normally an expensive process,
00:11:40 it is important to identify any data quality problems well in advance before
00:11:45 your S/4HANA conversion project starts. In SAP ERP
00:11:50 and S/4HANA, therefore, we have various tools available for checking financial data before,
during,
00:11:57 and after the conversion. In the source SAP ERP system,
00:12:02 there is, for example, a simplification item check, which helps us to detect
00:12:06 any inconsistencies in the configuration. In addition, in SAP ERP, we have a group of
programs
00:12:13 for reconciling totals between general ledger and various subledgers.
00:12:19 There is also a couple of programs available for some extensive technical checks of tables in
finance.
00:12:25 I will talk about them in more detail in the next unit. Another set of tools for detecting
inconsistencies
00:12:34 in financial data is available after the installation of S/4HANA.
00:12:38 Before starting data migration, you need to run the program Analyze Transactional Data,
00:12:44 which performs checks for transactional data consistencies. Then we have a number of checks

00:12:49 which are executed automatically during finance data migration after each migration activity.
00:12:57 What is important is that consistency checks, which are available in the SAP ERP system,
00:13:03 are different from mandatory consistency checks accessible after installation of S/4HANA.
00:13:08 The S/4HANA checks are more advanced and able to detect data errors which may slip
through
00:13:14 the standard set of checks in SAP ERP. There is a chance that, during finance data migration,

00:13:21 you end up with error messages that were not detected during initial checks in the source SAP
ERP system.
00:13:29 It means that some data inconsistencies might be uncovered only after the first test cycle of
S/4HANA conversion.
00:13:38 This is also one of the main reasons why we recommend performing several iterations
00:13:43 of test financial data migrations, always using the latest of copy of the production system.
00:13:50 Then, during each iteration, you will be able to detect all inconsistencies in SAP ERP
00:13:56 and consequently correct them directly in the production environment until the system
00:14:01 is ready for productive conversion. Another important topic is different adoption paths
00:14:10 for so-called new G/L functionality in the converted S/4HANA system.
00:14:15 It's been some time since the new G/L solution was introduced in Financial Accounting.
00:14:21 The new G/L has brought many functionalities, such as the possibility to map parallel
accounting

17
00:14:26 via parallel ledgers, document splitting, real-time integration of CO into FI, and segment
reporting.
00:14:33 However, there are still many SAP customers who didn't migrate to new G/L
00:14:38 and are still using classic general ledger functionality. The good news is that new G/L is not
00:14:44 a mandatory prerequisite for S/4HANA conversion. In general, there is no need to run a new
G/L migration
00:14:52 before the conversion of accounting to SAP S/4HANA. However, you need to be aware, that
with the S/4HANA conversion,
00:15:00 you do not get all new G/L functions automatically. If you are converting ERP with classic G/L,

00:15:07 you will get only core new G/L functionality. Totals tables will be migrated into universal journal

00:15:13 with leading ledger 0L activated. However, there is no transfer to parallel ledgers
00:15:21 or activation of document splitting. If you are converting ERP with new G/L, in SAP S/4HANA,

00:15:28 you will get the new G/L functionality you had already activated in the source system.
00:15:34 If you had document splitting or parallel ledgers in the source system, the functionality
00:15:39 will be available also after the conversion. If not, the conversion itself
00:15:44 will not activate these functions. It means that you might want to have a possibility
00:15:49 to implement these functionalities after conversion. So what options do we have?
00:15:54 The good news is that, since SAP S/4HANA release 1709, we have a solution for subsequent
introduction
00:16:02 of document splitting. The tool is available in the system at no extra charge.
00:16:09 In addition, since SAP S/4HANA release 1610, we have a solution to add further accounting
principles,
00:16:17 in other words, to introduce additional non- leading ledgers and migrate data from source
ledger
00:16:23 to a newly introduced ledger. However, this tool will only help customers already
00:16:28 using parallel ledgers functionality to introduce additional ledgers or accounting principles.
00:16:35 If you are still using the so-called accounts approach to map parallel accounting principles, it
will not help you.
00:16:42 Currently, the only option to move from the accounts approach to parallel ledgers is new a G/L
migration
00:16:48 before starting with the S/4HANA conversion. Here on the slide, you can see where you can
find
00:17:00 more information about finance-related activities in a system conversion.
00:17:05 The overall conversion guide for SAP S/4HANA is available on help.sap.com
00:17:11 and explains the conversion process. This guide contains a list of important
00:17:16 application-specific preparatory and follow-on steps and where to find their documentation.
00:17:22 For finance, there is also a guide available, Converting Accounting Components to SAP
S/4HANA,
00:17:28 that is attached to SAP Note 2332030. You can find more information about migration
00:17:38 of SAP Credit Management in SAP Note There is a task list attached to this note
00:17:45 where you can find all tasks for migration of Credit Management.
00:17:50 As far as Cash Management is concerned, you need to go to SAP Help to find activities
00:17:55 necessary for migration or, in other words, initial upload of data.
00:18:00 You will not find these activities in the IMG folder, Conversion of Accounting to SAP S/4HANA,

18
00:18:07 but you need to go to the specific folder for Cash Management. For a list of the most frequently
occurring
00:18:14 error messages during data migration, you may refer to Knowledge Base Article
00:18:23 Here, you will find not only the list of error messages, but also possible causes and our
recommendations.
00:18:31 One last remark: It's essential that finance data migration receives
00:18:35 proper attention during planning of an S/4HANA conversion because conversion of accounting
to SAP S/4HANA
00:18:44 can be more challenging in terms of effort and runtime than the Software Update Manager
phase.
00:18:51 So with this, we come to the end of this unit. Thank you for your attention and enjoy the next
unit. Goodbye.

19
Week 2 Unit 5

00:00:05 Hello, and welcome back to week two, unit five of the openSAP course on System Conversion
to SAP S/4HANA.
00:00:12 My name is Martin Schmidt, I am an S/4HANA Product Expert, and I am your host for this unit,
Conversion
00:00:17 of Accounting – Preparation in SAP ERP. In the previous unit,
00:00:22 I gave you an overview of finance-specific activities in a system conversion project
00:00:27 and explained when exactly conversion of accounting comes into play.
00:00:31 In this unit, we will take a closer look at the Preparation phase and required tasks
00:00:37 you have to do in the source SAP ERP system before starting a system conversion.
00:00:45 So, how can you start preparing for an S/4HANA conversion? As a first step, you should
review simplification items
00:00:52 relevant to your system. You need to understand which major changes you will face
00:00:56 when moving to S/4HANA, and which activities are required from you
00:01:00 to react to these changes. Secondly, consistent and correct Customizing settings
00:01:07 is a mandatory prerequisite for a finance conversion. You can check the consistency of your
finance configuration
00:01:13 by running the simplification item check. Based on the results of the check,
00:01:18 you need to make the necessary adaptations. Thirdly, to minimize the runtime of the
conversion
00:01:24 and to reduce effort spent dealing with data quality issues, we recommend archiving data from
previous fiscal years.
00:01:34 In the previous unit, I already talked about how important for successful financial data
migration
00:01:39 it is to have clean and consistent transactional data, how a company can end up with data
inconsistencies,
00:01:46 and what impact it can have on the conversion project plan. In SAP ERP, there are a number
of reports available
00:01:54 which will help you to identify data quality issues in your transactional data.
00:01:59 You should be sure to plan enough time for the detection and especially cleansing of data
inconsistencies
00:02:05 in the Preparation phase of the conversion. All these activities I mentioned
00:02:10 you can perform well in advance, before the actual conversion project starts.
00:02:15 Then, just before the start of downtime, as a part of cutover, you will execute period-end
closing activities.
00:02:21 We also recommend documenting your financial data for later comparison.
00:02:27 To make this comparison possible, you have to carry out the selected reports
00:02:31 for current year just before conversion. You can run the reports you normally use
00:02:37 to document your financial closing like financial statement, like the open line item lists,
00:02:43 list of G/L account balances, and so on. You can store the results, for example in a local file,
00:02:49 and after the conversion, generate the same list and compare the results.
00:02:57 As I mentioned, a good starting point for finance-related preparation activities
00:03:02 is to run the simplification item check. The simplification item check
00:03:06 will examine the consistency of your company code, ledger, and controlling area settings.
00:03:13 It will also inspect Asset Accounting configuration and check if closing activities were
completed properly.
00:03:22 The result of the simplification item check will help you to answer the question

20
00:03:26 like are my SAP ERP configuration settings consistent? Are all mandatory prerequisites met?
00:03:33 What do I need to change in my Customizing before starting with the conversion?
00:03:38 Another type of check contained in the simplification item check
00:03:42 is the so-called relevance check. It will give you a detailed overview of
00:03:46 which simplification items are relevant for you based on transactions you used,
00:03:51 based on the data you've got in those tables, based on the configuration.
00:03:55 So you will get a list of functional and technical changes, you need to go over this list in detail,

00:04:02 and determine what is the impact. In the previous unit, we already mentioned
00:04:08 that some of the functional changes are extensive with an impact which can be compared
00:04:13 to implementation of a new component. For instance, classic Cash Management has been
replaced
00:04:20 with the newly developed solution S/4HANA Cash Management. This is a new application
which, of course,
00:04:26 has to be deployed and configured. Even if you want to continue
00:04:29 using the classic Cash Management scope of functionalities in S/4HANA,
00:04:33 you still need to set up parts of the new Cash Management configuration
00:04:38 and perform an initial data upload. Then we have SD Credit Management,
00:04:43 which was replaced with SAP Credit Management, technically, FSCM Credit Management.
00:04:49 Again, you need to understand what the changes are when compared to SD Credit
Management,
00:04:55 and you have to have the right skills to be able to configure the solution.
00:05:00 There are some activities during conversion when you need to migrate Customizing,
00:05:04 master data, and credit exposure, but it's not only about the technical task.
00:05:10 You need to have a resource in the team with SAP or FSCM Credit Management functional
skills.
00:05:19 Another topic for statutory and tax reporting, we have a new solution called advanced
compliance reporting,
00:05:26 which replaces the classic tax reporting based on ABAP reports.
00:05:31 There are plans to slowly sunset the old reports which have been replaced with the new
solution,
00:05:38 and you need to incorporate this into your conversion planning.
00:05:42 For financial planning, customers are recommended to use SAP Analytics Cloud or BPC.
00:05:49 Both of these are new components different from the old planning engine within core SAP
ERP.
00:05:58 In all these cases, you should to get familiar with the new functionalities and solution,
00:06:02 evaluate technical prerequisites, you might need to migrate the existing data,
00:06:08 train people, and also adapt business processes. One of the most important functional
changes
00:06:19 in finance coming with S/4HANA is mandatory introduction of new Asset Accounting.
00:06:24 The new Asset Accounting is a functionality for handling parallel valuations.
00:06:28 It's not completely new. It has already been available for customers
00:06:33 with new G/L active since SAP ERP Enhancement Pack 7. However, now in S4/HANA,
00:06:39 the new Asset Accounting is mandatory, and if you do not have it active in your SAP system
yet,
00:06:45 it must be activated during the conversion process. And for this, there are certain prerequisites

00:06:51 which need to be met. So first, you need to have a new depreciation

21
00:06:56 calculation engine in place. The engine has been available since 2005,
00:07:01 but we still see many customers who don't have it activated. So what is it?
00:07:06 It's a functionality which replaces the old logic for calculation of depreciation,
00:07:11 which is based on asset movements, with the new calculation logic
00:07:15 which is based on period intervals. Activation of new depreciation engine
00:07:20 doesn't require any migration, you just need switch on generic business function EA-FIN.
00:07:28 And, if you have some custom enhancements of your depreciation calculation,
00:07:33 you need to transfer them from old user exits into newly provided business add-ins.
00:07:40 You need to make sure that you set up a depreciation area for each of your parallel currencies

00:07:45 which are assigned in the company code settings of the general ledger.
00:07:50 Parallel currencies are also known as the second and third local currency.
00:07:55 In Financial Accounting, you can manage a company code in up to two additional local
currency types.
00:08:01 In Asset Accounting, for each additional local currency, you have to manage a separate
depreciation area.
00:08:08 This was also a requirement in the past, in classic Asset Accounting,
00:08:12 but the checks were less strict then. Now, in new Asset Accounting, due to the design change,

00:08:19 it's a mandatory prerequisite for activation of new Asset Accounting.

00:08:24 So in order to set up a new depreciation area, you need to do the necessary configuration
00:08:29 and then run the report RAFABNEW which adds a newly created depreciation area
00:08:37 to existing asset master data. What is important is that implementation
00:08:42 of the new parallel currency depreciation area must be done in the SAP ERP system
00:08:47 before you run Software Update Manager. It is not possible
00:08:51 to create additional parallel currency areas in S/4HANA after you perform technical
conversion.
00:09:02 Before conversion, we also recommend that you archive all Asset-Accounting-relevant data
00:09:08 of the inactive company codes. It means all company codes
00:09:12 which in Asset Accounting Customizing have the status "Company code deactivated -
00:09:16 later reporting allowed", for each of such company codes,
00:09:22 you need to fully archive all data. If the data is not fully archived,
00:09:27 you will get an error message during the prechecks, and you will not be able to continue with
the conversion.
00:09:34 You need to execute archiving before the technical installation of S/4HANA,
00:09:39 so still in the SAP ERP system. Besides mandatory prerequisites,
00:09:46 you also need to be aware of several important limitations. One of them is that the new Asset
Accounting
00:09:52 is not possible for depreciation areas to have fiscal year variants
00:09:58 with different starting and finishing dates. If in your SAP ERP, you have fiscal year variants
00:10:04 with different start and end date assigned to the ledgers used in Asset Accounting,
00:10:09 you will not be able to continue with the conversion. A possible solution involves
00:10:14 the introduction of an additional ledger, which normally requires undertaking a separate new
G/L migration project.
00:10:21 The other limitations are concerned with real estate and lease accounting.
00:10:26 In the past, SAP has provided two versions of the real estate solution.
00:10:30 The older version is Real Estate Classic and the new version is called Real Estate Flexible.

22
00:10:36 If you use classic real estate, you won't be able to activate new Asset Accounting.
00:10:42 Also, the Lease Accounting Engine doesn't support the new Asset Accounting.
00:10:47 Now, let's move to the preparation activities in area of general ledger and Controlling.
00:10:54 In this part, there is also a simplification item check, which will help you to analyze
00:11:02 what are the mandatory prerequisites. So it will evaluate,
00:11:06 for example currency settings for company code and controlling area if they are maintained
correctly,
00:11:12 are there any user exits or BADIs implemented that are possibly incompatible
00:11:18 with the ledger concept of S/4HANA? Are company codes correctly assigned to controlling
areas?
00:11:25 Are the fiscal year variants in the company code identical with the fiscal year variant
00:11:30 of the controlling area? For example, in the classical ERP system,
00:11:35 it was allowed that fiscal year variants differ in the number of special periods.
00:11:41 But this difference is not allowed anymore in S/4HANA since FI and CO are sharing the same
database table
00:11:48 for storing the postings. Now, if you have material ledger already activated
00:11:54 in your source SAP ERP system, there are some Customizing activities
00:11:58 you need to perform already in SAP ERP before starting S/4HANA conversion.
00:12:03 You have to define explicitly the currency and valuation types
00:12:08 that are relevant for the material ledger. In S/4HANA, separate currency Customizing of the
material ledger
00:12:14 has become obligatory. It is not allowed to use a material type
00:12:20 that references to currency settings defined in FI or CO. If you do not adapt Customizing,
00:12:28 you can still do it at a later stage as a part of preparation
00:12:32 and migration of Customizing activities. Actual costing is still optional in S/4HANA,
00:12:38 and it is also not possible to activate actual costing during the conversion.
00:12:43 Therefore, it's recommended that you review your actual costing settings
00:12:48 as a part of preparation for the S/4HANA conversion already in the SAP ERP system...
00:12:58 Okay, here on the slide, you can see the consistency check and transactional data which you
can run
00:13:05 in the source SAP ERP system before installation of SAP S/4HANA.
00:13:13 These checks include a bunch of programs for reconciling general ledger with various sub-
ledgers
00:13:21 and components such as Asset Accounting, Material Management, and special ledgers.
00:13:25 Most of these programs are well-known and commonly executed on a regular basis
00:13:30 as part of the closing process in Finance. We have two dedicated data consistency check
programs
00:13:36 for Asset Accounting: transaction code ABST and ABST2. First, you execute ABST2
00:13:45 which compares asset G/L account balances with the asset summary records in table ANLC.
00:13:52 This check identifies all G/L accounts where there is a discrepancy
00:13:57 between G/L account balance and asset values. The output of the program is a list of G/L
accounts
00:14:02 per company code with differences in amounts between Asset Accounting and general ledger.

00:14:08 In the next step, individually for each of the affected G/L accounts,
00:14:13 you run transaction ABST. Here in the first step,
00:14:16 the asset line items for each fixed asset are compared with the asset summary records.

23
00:14:22 In the second step, asset line items of a fixed asset are summarized per each document
number
00:14:27 and compared with general ledger account line items posted to this fixed asset.
00:14:33 In addition, you may find standard asset reports such as Asset History Sheet or Asset
Balances helpful
00:14:41 when evaluating the consistency of data in Asset Accounting. Then, we have two checks
available
00:14:47 to reconcile materials management with general ledger, transaction MBL5 and
FAGL_MM_RECON.
00:14:57 Both of them compare the stock G/L account balances with the total of stock values
00:15:02 as recorded in materials management or material ledger. They display the total value of the
stock
00:15:08 together with stock G/L account balance and any deviations between them.
00:15:14 The program FAGL_MM_RECON is primarily designed to read stock values from the material
ledger.
00:15:22 If the material ledger is not active, it reads values from MM tables.
00:15:25 Then, we have transaction GCAC, which compares the totals records of any two ledgers.
00:15:34 You can use this program to compare standard general ledger totals with any standard
00:15:40 or customer-defined special ledger totals table. Because it's a generic transaction,
00:15:46 it works with all applications which are based on the special ledger concept
00:15:50 including classic Profit Center Accounting ledger, EC-CS, consolidation staging ledger, or
consolidation ledger.
00:16:00 Then, we have two comparative analysis reports: SAPF190 for a system with classic general
ledger
00:16:08 and TFC_COMPARE_VZ for a system with new general ledger implemented.
00:16:15 They are used to compare values from document line items, tables with transaction total
tables,
00:16:21 and with the secondary application index tables. The FI consistency check program RFINDEX

00:16:30 performs another collection of checks in the AR and AP area where it compares for example
document headers
00:16:38 with the line items, searches for missing document headers, checks clearing transactions, and
so on.
00:16:47 The disadvantage of these two prechecks, RFINDEX and comparative analysis reports,
00:16:54 is that they might list inconsistencies which do not have any impact on conversion.
00:16:59 It means that not all errors reported need to be corrected for conversion.
00:17:05 Therefore, the tool requires a certain level of technical expertise
00:17:09 to correctly interpret the results. Also, run times of FI consistency checks
00:17:18 and FI comparative analysis reports can be significant. As one of the last steps of preparation
activities,
00:17:27 you execute the financial close. There is no requirement to execute the conversion
00:17:31 at the beginning of a fiscal year, and the conversion itself
00:17:34 can be performed any time during the current year. However, the previous fiscal year must be
fully closed,
00:17:42 and this is especially relevant for the use of Asset Accounting.
00:17:47 In Asset Accounting, you are not allowed to reopen previous fiscal year
00:17:50 and post any adjustments after conversion to SAP S/4HANA. First, you need to make sure that
you have carried forward
00:17:58 all balances in all applications and ledgers to the current fiscal year.

24
00:18:04 Then, just before the start of downtime, as a part of cutover, you need to carry out
00:18:09 the usual period-end closing activities for the previous fiscal period.
00:18:14 In Asset Accounting, you perform periodic asset postings completely,
00:18:18 run the recalculation of planned depreciation, do your depreciation runs,
00:18:23 make sure there are no update terminations, and once more,
00:18:27 reconcile Asset Accounting with general ledger. In Controlling, if you already use
00:18:32 account-based profitability analysis, you perform a delta upload to SAP BW
00:18:38 for all account-based CO-PA data resources for which you use the delta procedure.
00:18:44 This is necessary because otherwise, account-based CO-PA line items
00:18:48 that are not extracted before the migration might be ignored after the migration
00:18:54 when the new delta is loaded. If you are on classic G/L,
00:18:59 you reconcile the reconciliation ledger in Controlling with FI. In the material ledger,
00:19:04 if you already have actual costing active, complete all costing runs
00:19:08 before the system conversion is started. After the system conversion to S/4HANA,
00:19:20 it will not be possible to do any changes on costing runs created before the system conversion.

00:19:26 In general ledger, if you have been using the valuation for balance sheet preparation function
00:19:31 as a part of the classic general ledger to valuate foreign currencies,
00:19:36 you have to set the valuation difference in the open items to zero.
00:19:40 This means that you have to reset the valuations for all periods in the current fiscal year
00:19:44 by using the foreign currency valuation program. If you do not reset the valuation,
00:19:50 this could result in incorrect values after migration. And finally, lock all periods in Finance and
Controlling,
00:19:57 and document your financial data for later comparison. As a last step before starting SUM,
00:20:04 I recommend running the simplification item check once again to make sure that everything is
green.
00:20:12 Now, some of the finance preparation activities, especially for Customizing and cleaning up
data
00:20:18 can be addressed well in advance, even before starting the SAP S/4HANA conversion project.

00:20:23 For instance, I recommend that you consider setting up separate pre-projects for data
archiving,
00:20:29 cleanup of data inconsistencies, cleanup of vendor/customer master data,
00:20:35 and activation of customer/vendor integration. Also, we can do a separate pre-project
00:20:41 for a new depreciation engine activation, you can even activate new Asset Accounting
00:20:47 before starting with the conversion. You can do other required adaptations
00:20:53 of Customizing in Finance. For example, setting up new depreciation areas
00:20:57 for parallel currency as a separate pre-project, and you can also consider moving from the
accounts approach
00:21:03 to parallel ledgers as a separate project. So, with this, we come to the end
00:21:08 of the preparation activities in the SAP ERP system. We are now ready to hand over the
system to technical team
00:21:17 to run Software Update Manager to perform the technical conversion.
00:21:21 Once the technical conversion is completed, we will continue with conversion of accounting.
00:21:27 Thank you for your attention, and goodbye.

25
Week 2 Unit 6

00:00:05 Hello, and welcome back to week two, unit six of the openSAP course on System Conversion
to SAP S/4HANA.
00:00:12 My name is Martin Schmidt. I am an S/4HANA Product Expert, and I'm your host
00:00:16 for this unit, Conversion of Accounting – Customizing for Migration.
00:00:20 In the last unit, I talked about the Preparation phase of a conversion project.
00:00:25 You got an overview about the activities in the source SAP ERP system, and what you have to
do
00:00:30 before the conversion of the system. In this unit, I will explain in more detail
00:00:35 which activities have to be performed in the first phase of conversion of accounting.
00:00:43 So imagine, we are now at the stage of the conversion process when Software Update
Manager has already completed
00:00:49 the technical conversion, all the necessary software components are installed,
00:00:54 and new finance tables are created but still empty. We are still in the downtime phase, but the
S/4HANA system
00:01:00 is ready for finance experts to log on and execute the data migration activities.
00:01:06 But before you can start with the migration of transactional data, you need
00:01:10 to migrate or manually perform Customizing for relevant application areas.
00:01:15 Now there is an important difference between the migration of Customizing
00:01:18 when compared to migration of transactional data. You create the settings and migrate content

00:01:24 of existing Customizing tables in the development system. The Customizing settings are
recorded
00:01:31 and can be later transported into the production system during the cutover procedure.
00:01:37 Therefore, conversion during the conversion of the production system,
00:01:41 you just need to import the relevant transport requests and do not have perform the
Customizing settings
00:01:46 from scratch. In contrast to Customizing, the transactional
00:01:51 and master data need to be migrated in each system separately.
00:01:55 This means in each system, whether it's development, test or production.
00:02:02 In the S/4HANA system, you will use the following activities in the IMG under the node
Preparation
00:02:10 and Migration of Customizing. The first one is to check Customizing settings
00:02:15 prior to migration. With this activity, you can check once more
00:02:20 whether your Customizing settings in finance are ready for migration.
00:02:26 Then we have the second activity, which is Number of Jobs.
00:02:30 You can set the number of jobs for each migration activity of the mass data framework here.
00:02:35 Data migration works in such a way, that the different jobs during migration
00:02:39 are performed in parallel using the so-called mass data framework.
00:02:46 The rest of the Customizing activities are grouped according to application areas.
00:02:50 So let's look at each area one by one. Let's start with general Ledger.
00:02:56 Here, the necessary Customizing activities can be divided into three main groups.
00:03:02 The first group consists of settings for parallel accounting. As all ledger Customizing has been
redesigned,
00:03:09 SAP provides a program to automatically create and migrate ledger Customizing
00:03:14 into new configuration tables. Afterwards, some manual Customizing activities are required.

26
00:03:20 For example, you need to review automatically created assignments
00:03:25 of accounting principles to combinations of ledger and company code.
00:03:30 In addition, companies coming from classic general ledger have to manually define
00:03:35 and assign accounting principles and valuation areas. The next group of settings is concerned

00:03:42 with the CO Customizing for universal journal. With S/4HANA, we are bringing FI and CO
together,
00:03:49 and they both post to the same line item table ACDOCA. As a result, we need to configure CO

00:03:59 to be able to post to universal journal. Therefore, here you might need
00:04:03 to create new document types for CO postings, for example for the manual reposting of
primary costs.
00:04:10 You define default values for use in CO business transactions whose user interfaces
00:04:17 do not allow you to enter a document type or a ledger group for posting purposes.
00:04:22 You assign general ledgers to CO versions. Also, if you have not done so already
00:04:30 in the Preparation phase, you need to check and adapt Customizing of the CO area.
00:04:42 The third group of settings relates to Customizing for finance data migration itself.
00:04:47 Here, you define what offsetting accounts the system will fill into the document table,
00:04:53 what ledger should be used as a source for migration of balances, and what currency
translation method
00:04:59 should be used for currencies which in SAP ERP system were used only in CO.
00:05:10 Let's move to the preparation and migration of Asset Accounting Customizing.
00:05:16 Now, if you have not already done so in SAP ERP, this is the time to activate new Asset
Accounting.
00:05:23 First, you need to migrate charts of depreciation. You can do it either manually
00:05:28 or you can run the program Migrate Charts of Depreciation. The program will automatically
assign the accounting principle
00:05:35 to each depreciation area. It will adjust the settings for posting
00:05:39 to the general ledger for depreciation areas which are leading or derived.
00:05:46 It will adjust the settings for transfer of APC and depreciation terms.
00:05:51 Here in S/4HANA, in new Asset Accounting, it's only possible to transfer values within a set
00:05:57 of depreciation areas to which the same accounting principle is assigned.
00:06:03 In the next step, you need to perform some manual settings to define the technical clearing
account
00:06:08 for integrated asset acquisitions. If you were using, for example, transaction types
00:06:13 that were restricted to certain depreciation areas, then you can no longer use them in
S/4HANA.
00:06:22 You need to check whether your existing transaction types that are not restricted
00:06:26 to depreciation areas are sufficient for your purposes. If all of this is done,
00:06:32 then you activate the new Asset Accounting. Consequently, the system will perform some last
checks,
00:06:38 and if everything is green, then the new Asset Accounting is activated.
00:06:46 Now, even if you were already using new Asset Accounting in SAP ERP there is some
Customizing work
00:06:52 to do before migration. Again, you can do it either manually
00:06:56 or you can run the program Adjust Parameters in Chart of Depreciation.
00:07:00 The program will support you to assign, for example, accounting principles
00:07:04 to each depreciation area. The program derives the accounting principle

27
00:07:09 from the relevant ledger group that is already assigned to that depreciation area.
00:07:14 It will also change the posting indicator for postings to general ledger
00:07:19 for depreciation areas that until now posted periodically, for example special reserve
depreciation areas.
00:07:30 Let's move to the preparation and migration of Customizing in Controlling.
00:07:38 If you haven't done so in the preparation in SAP ERP, you can perform delta extract to BW
00:07:44 for account-based CO-PA. In S/4HANA, we have also only one summarization mechanism
00:07:51 for profitability segments which is common for both, account-based and costing-based CO-PA.

00:07:57 As a result, the Summarization settings for profitability characteristics have to be adapted.
00:08:03 In order to do so, you have to run the program. If an operating concern is defined
00:08:08 for account-based CO-PA only, the program will delete the settings.
00:08:13 This is because in universal journal, by default each profitability segment contains
00:08:19 all available characteristics. For operating concerns that are defined
00:08:24 for costing-based CO-PA only, summarized entries are retained
00:08:28 and can be maintained afterwards. In the next step, you need
00:08:33 to activate the data structures and regenerate the environment.
00:08:38 At this point of time, you can also activate account-based CO-PA.
00:08:43 Before activation, I recommend getting familiar with all differences between costing-based
00:08:48 and account-based CO-PA. Also, depending on your processes,
00:08:52 there might be some additional Customizing needed. If you currently work with costing-based
CO-PA,
00:08:59 you can continue to run both approaches in parallel, by making the appropriate settings per
controlling area.
00:09:07 Please note there is no migration from costing-based CO-PA to account-based CO-PA
available.
00:09:17 Now, regardless whether you have the material ledger implemented in your SAP ERP or not,
00:09:22 you have to run the program Migrate Material Ledger Customizing. The activity will activate the
material ledger
00:09:29 for all valuation areas and assign material ledger types to valuation areas.
00:09:34 You should review the automatically created configuration and adapt it if necessary.
00:09:43 Let's move to house bank Customizing. House bank accounts are managed now in S/4HANA
master data.
00:09:54 The idea here is that it is a cash or treasury department, rather than IT, which should own
bank account master data.
00:10:03 So in S/4HANA, business users can maintain bank accounts, it is not a configuration activity
anymore as in the past.
00:10:11 Therefore, the new master object bank account was introduced with many additional attributes,

00:10:17 some of them are available only when full-scope Cash Management is activated.
00:10:23 To create, change, or close house bank accounts you can use the Fiori app Manage Bank
Accounts.
00:10:29 There is no SAP GUI transaction available anymore in S/4HANA.
00:10:34 Later on, during the Data Migration phase, the existing house bank accounts stored as entries

00:10:41 in configuration tables are migrated into new bank account master data tables.
00:10:46 But now we have to prepare configuration first. So what you have to do,
00:10:53 you have to create number range intervals for bank account technical IDs

28
00:10:57 and for change requests using the Bank Account Management. Here, you also need to define
different types
00:11:03 of bank accounts: For example, it might be current account or it might be savings account.
00:11:10 Account types can be used later as a reporting dimension, or they can be used also
00:11:18 in the definition of approval patterns for payments in Cash Management.
00:11:23 Before the migration, you need to make sure that you have specified Activate Directly
00:11:28 for the Bank Account Revision settings. This is to make sure that migration
00:11:32 will not trigger a workflow for each change or creation of a bank account.
00:11:37 When the migration has finished, and you plan to use SAP Cash Management
00:11:41 you can alter the settings according to your business needs. To influence the logic for deriving
bank account numbers
00:11:50 from house bank account data, you can use the provided BAdI.
00:11:54 By default, the system copies the value of the House Bank Account Number field
00:12:00 from house bank account configuration to Bank Account Management as the bank account
number
00:12:05 of the new bank account master. If you want to rather map, for example,
00:12:11 Alternative Bank Account Number field in the house bank account data, you can implement it
00:12:18 via this BAdI, which is provided. Let's move to Customizing for migration
00:12:26 of the accrual engine. The accrual engine underwent a massive redesign
00:12:31 in S/4HANA release 1809. The data model has been simplified,
00:12:36 configuration has changed, and new functional capabilities such as purchase order accruals
00:12:42 and Excel upload, have been added. As a consequence of the data model change,
00:12:47 the transactional data and Customizing settings of manual accruals need to be migrated
00:12:52 from the old accrual engine to the new S/4HANA accrual engine.
00:12:56 The migration of the accrual engine Customizing for manual accruals is mandatory only
00:13:01 for those customers who have been using the manual accruals already before the conversion
00:13:07 or before upgrade to 1809. What you need to do is to migrate existing Customizing,
00:13:14 adapt custom code, and configure the accrual engine for migration.
00:13:22 Now we provide a tool again which is able to help you with migration
00:13:26 of Customizing, but still some activities need to be done manually.
00:13:31 The program for automatic migration of Customizing will switch configuration
00:13:36 to ledger-based configuration and replace accounting principle with ledger
00:13:40 in most of the configuration tables. The migration program for the Customizing migration
00:13:47 will not activate the multiple currency feature in the S/4HANA accrual engine
00:13:51 and it doesn't migrate account determination. This needs to be done manually.
00:13:58 In addition, if you have developed your own programs or other repository objects for manual
accruals
00:14:04 that are using the old accrual engine objects, adoption effort will likely be required
00:14:09 to replace the usage of those objects. For example, in the new accrual engine, function
modules
00:14:16 for custom-developed specific accrual methods are not supported anymore, and you need
00:14:21 to redevelop the logic of these function modules as ABAP classes.
00:14:26 In the old accrual engine, the customer could activate the validations
00:14:30 in order to validate the data of an accrual object during its creation or change.
00:14:35 This validation cannot be used anymore. Instead, a new BAdI is offered
00:14:39 where you can code your validation. Also, the old BAdIs for postings are not called
00:14:46 by the new S/4HANA accrual engine anymore. Instead, a new BAdI is provided,

29
00:14:52 where you need to redevelop your custom code. After you migrated the Customizing,
00:15:00 you need to configure the system for later migration of accrual engine transactional data.
00:15:05 What you need to do, you need to create a mass data project
00:15:08 and assign it to relevant company codes. You need to define dummy G/L accounts
00:15:13 for migration of postings. The migration will generate technical line items
00:15:18 in the universal journal using this dummy G/L account. They balance to zero, and their only
purpose
00:15:24 is to bring the reference to accrual objects into the universal journal table.
00:15:33 Let's move to Customizing for migration of credit management.
00:15:38 If you are using SD Credit Management in your source SAP ERP system,
00:15:44 you need to move to SAP Credit Management. For that reason, during the Data Migration
phase,
00:15:50 you will have to migrate credit accounts, configuration, credit exposure data,
00:15:56 and create so-called documented credit decision cases for credit blocked sales orders.
00:16:03 So how do we prepare for migration? Firstly, you need to set up default parameters
00:16:11 for credit account master data migration. So we have to tell the system what parameters
00:16:17 should be filled for credit scoring and credit limit, credit schedule rule
00:16:22 in the business partner master data. Secondly, you need to migrate parts
00:16:27 of the SD credit management Customizing. The program Migrate Credit Management
Customizing
00:16:34 will help you here. It will create and assign to every credit control area
00:16:40 a new credit segment with the same ID. In addition, for every risk category
00:16:45 in old credit management, a new risk class with the same ID is created.
00:16:50 Also, the necessary Customizing entries for documented credit decisions are made
00:16:55 by this automatic program. In the next step, you can define credit analyst group
00:17:08 and credit customer group in SAP Credit Management and map it to the respective
organizational object
00:17:13 in old credit management such as credit representative group and customer credit group.
00:17:18 Then, during migration, the system is able to create relationships between a credit analyst
group
00:17:24 and business partners automatically. Now, even in a single system landscape,
00:17:30 SAP Credit Management is, to a certain extent, decoupled from other components.
00:17:36 It uses XML messages to communicate and integrate with Finance and SD, usually via web
services.
00:17:44 Now, even though SAP made it easier in S/4HANA, and we deliver default configuration
00:17:51 and web services with generic proxies, there is still some technical setup which needs to be
done.
00:17:59 Finally, you need to adapt custom code. You need to replace, for example, snippets of code
00:18:09 which are referring to obsolete tables and objects. If you have custom specific credit checks,
00:18:14 you should redevelop these from user exit into the newly provided BAdI for credit checking.
00:18:21 In addition, I recommend reviewing and compare the predelivered credit checks available
00:18:26 in SAP Credit Management with the credit checks available in old Credit Management.
00:18:31 There are some differences which might require additional Customizing
00:18:36 or custom development. For example, in S/4HANA, not all credit checks
00:18:41 are segment dependent. Let's move to preparation for migration
00:18:49 of financial documents into trade finance. In S/4HANA, functionality of financial documents
contained

30
00:18:55 in SD foreign trade has been moved into Treasury trade finance. As a result, the existing
letters of credit
00:19:04 should be migrated into trade finance. You have an option to decide if migration
00:19:10 is needed depending on whether you want use trade finance to manage letters of credit, or you
wish to go
00:19:16 for another solution, for example the SAP Global Trade Services product.
00:19:22 Therefore, we provide Customizing for the customer to decide if migration is needed on their
own.
00:19:29 In case you set migration as needed, users can create trade finance transactions
00:19:34 in Treasury only after migration is set to completed. So what do you need to do to prepare for
migration?
00:19:44 You have to define different mappings. You have to map the financial document type
00:19:50 in SD foreign trade to the product type in Treasury. You have to map presented document
types
00:19:57 in SD to Trade Finance document types. You have to make sure that basic Customizing
00:20:04 in Treasury trade finance is done. For that, we provide a check program which is able
00:20:09 to identify the missing Customizing settings. Based on the result of this check,
00:20:14 you might need to go the IMG for Treasury and add the required configuration.
00:20:22 Now, the letter of credit in trade finance provides the same level of integration with sales order

00:20:27 and credit management processes as the previous functionality of financial documents
00:20:32 in SD foreign trade. There is some Customizing around this.
00:20:36 You need to define Incoterms location types. Here, we deliver default proposed values.
00:20:42 You can configure the processes for releasing blocked sales orders in Treasury,
00:20:47 and you can define forms of payment guarantee. So, with this, we come to the end of
preparation
00:20:54 and migration of Customizing activities, and also to the end of this unit.
00:21:00 In the next unit, I will be talking about data migration and activities which are to be done after
completion
00:21:07 of data migration. Thank you for your attention and goodbye.

31
Week 2 Unit 7

00:00:06 Hello, and welcome back to week two, unit seven, of the openSAP course, System Conversion
to SAP S/4HANA.
00:00:13 My name is Martin Schmidt. I'm an S/4HANA Product Expert, and I'm your host
00:00:16 for this unit, Conversion of Accounting – Data Migration. In the last unit, I talked about
00:00:21 the preparation and migration of Customizing, which is the first phase of conversion of
accounting.
00:00:27 In this unit, we will take a closer look at the data migration itself, and I will explain
00:00:32 the activities which need to be done during, but also after, data migration.
00:00:37 I will also show you a short demo of the data migration cockpit, which is our main tool for
performing data migration.
00:00:46 Imagine we are at the stage of the conversion process where Software Update Manager has
completed
00:00:51 the technical installation of S/4HANA, and finance experts have already logged into the
S/4HANA system
00:00:58 and made all the necessary Customizing settings for data migration and in the relevant
application areas.
00:01:05 Now it's time to start the data migration. Data migration is the phase during which transactional
data
00:01:12 and some of the master data are transformed, migrated into new data model, into new tables.
00:01:19 The data migration phase consists of around 10 main steps. All these steps are executed from
the Implementation Guide,
00:01:26 where you can also find the documentation of the activities. So, first, you must regenerate
CDS views and field mappings.
00:01:35 This is a technical step where you need to run a program which generates the redirection of
read accesses
00:01:41 from outdated finance tables to the new corresponding column compatibility views.
00:01:48 The program also generates the customer-specific fields in the CDS views.
00:01:54 In the second step, you run analyze transactional data. This is a program which checks if your
finance
00:01:59 and transactional data is complete and correct. What is recommended is that you execute the

00:02:05 analyze transactional data program during initial test cycles of the S/4HANA migration
00:02:11 to check whether FI documents are consistent. Use the results of these checks to correct
inconsistent
00:02:17 documents directly in your productive environment. Then, during the productive data migration,

00:02:22 you can skip this step since you have already identified and corrected all data inconsistencies

00:02:28 in your productive environment. As already mentioned in the previous units,

00:02:33 one of the common problems when planning the conversion of accounting is that the precheck
tools available
00:02:39 in the SAP ERP system are not able to detect all migration-relevant data inconsistencies.
00:02:46 The only way to detect all inconsistencies was to run S/4HANA test conversion on a copy of
productive data.
00:02:54 And this might be a little bit late for some of the conversion projects.
00:02:59 Therefore, recently SAP released a new pre- check tool which is able to detect data
inconsistency

32
00:03:06 directly in the source SAP ERP system. The new program is called reconciliation prior to
00:03:11 S/4HANA conversion and contains the subset of checks which are normally executed during
data migration.
00:03:19 You can download the tool into your SAP ERP by implementing SAP Note 2755360.
00:03:28 The checks are now available on the source system, which allows you to cleanse your data
00:03:33 before starting the conversion. At the moment, only general ledger checks are covered
00:03:38 as a part of the new tool. For other finance applications, such as Asset Accounting,
00:03:45 still the best way to make sure that migration- relevant data inconsistencies are discovered is
to carry out
00:03:51 one or several iterations of S/4HANA conversion tests. In the third activity, you display the
results
00:04:00 of the analyze transactional data program. Four, you execute start
00:04:07 and monitor data migration cockpit. This is the main transaction to carry out and monitor
00:04:13 the results of data migration to a universal journal. So let's explore it in more detail.
00:04:20 The start and monitor migration transaction is basically a cockpit which is responsible for
executing the data
00:04:28 migration activities one by one and in the right sequence. In addition, it provides monitoring
capabilities
00:04:35 and some error handling capabilities. You can also roll back failed migration activities
00:04:44 and restart them again from this migration cockpit. Now I will show you
00:04:55 a start and monitor migration cockpit in a short demo. Okay, you can find the data migration
activities
00:05:05 in the IMG guide under the node Conversion of Accounting to SAP S/4HANA.
00:05:10 Now let me open Start and Monitor Data Migration Cockpit. From here, you can see an
overview of all performed
00:05:23 data migration runs in the system. And in the lower part of the screen, you can see also
00:05:29 the list of individual migration activities which are part of this migration run
00:05:35 together with the information about the status. To get an indication of the volume of your
financial data
00:05:45 in your system which needs to be converted, you can switch to another type of tables, where
you can find
00:05:53 the list of finance application tables and the number of records in each of them.
00:06:00 So you can see that in our table BSEG, we have 4.7 million entries.
00:06:05 In table COEP, we have almost three million entries. We have some entries in the fixed asset
table
00:06:13 and in material ledger tables, but the table ACDOCA, which is our universal journal entry line
item table,
00:06:21 is still empty at this moment in time. Now the reason for that is that we haven't started data
00:06:28 migration yet, and this is what I'm going to do right now. I will switch to the Control tab
00:06:36 and press the Start migration pushbutton. Now what happens next is that the migration cockpit

00:06:45 automatically starts migration activities one by one. So, in the first activity, Check Consistency
of G/L Accounts
00:06:55 and Cost Elements, the system is checking whether your G/L account and cost elements are
correct.
00:07:05 We can see that this activity has been completed without any errors successfully.
00:07:11 It means that the migration cockpit moves automatically to the next activity.
00:07:16 If there is an error in the activity, the activity will be stopped, and you have two options how to
proceed.

33
00:07:25 You can either correct the error and reset and repeat the migration activity
00:07:30 or you can decide to accept the error, and continue with data migration.
00:07:37 So... We can see that in the next migration activity, the system we'll merge primary cost
elements with G/L accounts
00:07:53 and automatically create new G/L accounts for existing secondary cost elements.
00:07:59 In addition, account assignments from cost element master data are transferred into new
settings
00:08:09 of default assignments, which are maintained via transaction OKB9.
00:08:15 We can see that all these migration activities were completed successfully, and the migration
copied
00:08:20 moves to the reconciliation on transactional data. Now, the reconciliation of transactional data
program
00:08:27 will do some extensive technical checks to check your consistency of your transactional data.

00:08:36 Now we can see that we got some data quality issues in this activity.
00:08:40 Now I would like to know more about these errors, so I will click on the activity Reconciliation
of Transactional Data.
00:08:49 And on the next screen, I can see the results divided per application areas.
00:08:58 I can see that we have more than 1000 error messages in our general ledger.
00:09:04 Again, I will click on the issues found. I will press Show Error Overview,
00:09:12 and you can see the display of error message numbers which are reported during this
migration activity
00:09:20 together with the number of occurrences. Now, I will pick one of the error messages.
00:09:27 I will select the first one to make it easier because there is only one incorrect document
reported.
00:09:34 I will press Show Detail... And I will display the long text of the error message.
00:09:46 Already the long text of the error message can provide sufficient information to resolve the
error.
00:09:52 Here I can see that for this particular document, we have differences in values between some
of the fields.
00:10:01 So we have differences between table BSEG, which is our document table,
00:10:05 and former application index table BCAS. Now the question is: How should we proceed?
00:10:13 Can I just continue with the migration and ignore the error, or do I have to correct the error,
00:10:20 and how can I correct the error? Now, in general, each error must be investigated.
00:10:26 You should try to determine the root cause, and you should evaluate the impact on the
migration,
00:10:33 data migration, and also correct the error, if possible. A good starting point for analysis
00:10:40 of error is the SAP Knowledge Base Article, which you can find in Node 2714344.
00:10:53 So now I will open the Note. And here, in this Knowledge Base Article,
00:11:00 you can find the list of the most frequently occurring error message during data migration.
00:11:05 You will find here also the possible root causes. You will find here also the impact of the error
messages
00:11:13 on the data migration process. And you will find here also the recommendation
00:11:18 from SAP on how to correct this error. I will search for my error message using message
number...
00:11:38 And here I can see some more details about this particular error message.
00:11:45 So if I read the recommendation from SAP, it says that if the BSEG table is correct
00:11:52 and BCAS is incorrect, technical repair of the data might not be necessary.

34
00:11:57 The reason for that is that BCAS is an old table, which is not used in S/4HANA anymore.
00:12:04 Therefore, in this case, we can accept this error and continue with the migration without
correcting it.
00:12:12 So, I will go back. I will close the long text.
00:12:23 And I'm going to accept the error. I will select the error.
00:12:33 And you can see that the details about my decision – it means data, time, and user who made
these decisions –
00:12:40 are saved into the error log. I will go back...
00:12:52 You can see that we still have another error message number where we have more than 1000
error messages.
00:13:00 So there are probably more than 1000 wrong documents. Now, for this demo, I will accept also
this error message;
00:13:10 but, of course, in the real conversion project, you have to investigate the error and decide
00:13:17 whether to correct the error or accept the error. I will accept this error.
00:13:29 I will go back... And you can see that the status
00:13:42 has changed from red to green. Now this allows me to resume the migration again.
00:13:55 So I press the Resume migration pushbutton, and the migration cockpit starts automatically
the next
00:14:04 activity, which is the enrichment of transactional data. Enrichment of transactional data is the
activity
00:14:13 where migration cockpit is adding some fields into tables, for example company code and
profit center fields
00:14:19 are being added to CO line item tables as a preparation for merging FI and CO data...
00:14:31 So we can see that enrichment and the subsequent checks have finished successfully, and the
system is moving
00:14:42 to the next activity, which is the data migration into unified journal line items, which typically
00:14:49 is the most time-consuming part of data migration. It migrates documents from general ledger,
Controlling,
00:14:55 and different sub-ledgers into the universal journal. In other words, this is the activity where
entries
00:15:02 in the table ACDOCA are created by merging the line item tables of various applications,
00:15:08 such as GL, CO, CO-PA and Asset Accounting. Now, because this activity is very time-
consuming,
00:15:18 it's very important to set the right number of jobs for each activity.
00:15:23 Now in the middle part of the screen, you can see the important details, where you can see
how many
00:15:30 jobs are being used by this particular activity. You can see...
00:15:41 You can see also the current CPU's utilization, and you can also edit upper limit CPU
utilization here.
00:15:50 Now, the migration cockpit is based on so-called mass data framework, which is a tool
00:15:55 for processing large volumes of data. And this tool, in the first step,
00:16:00 at the start of each migration activity, organizes the data to be processed into work packages.

00:16:07 The size and number of packages is calculated automatically based on the various criteria,
00:16:12 which can slightly differ for each activity. Now, in the second step, mass data framework
00:16:19 executes parallel processing of packages using either a default or predefined number of
processes.
00:16:26 Now, you can set the number of processes in the IMG activity Set Number of Jobs for
Activities in Mass Data Framework

35
00:16:33 during the first phase of the conversion of accounting. Or you can also change the number of
jobs for each activity
00:16:41 during the migration run directly here in this cockpit. Now the optimum number of jobs, of
course, depends
00:16:53 on the different factors, such as hardware and resources.
00:16:59 Normally, there is no direct way how to calculate the optimum number of jobs,
00:17:04 and you need to establish the correct number via testing. So what I will do now,
00:17:12 I will increase the number of jobs to seven.
00:17:21 And you can also observe that current CPU utilization is being increased.
00:17:35 Okay, for the sake of time, I have completed the rest of migration activities offline,
00:17:41 so I will explain them only verbally. In the next steps, migration cockpit
00:17:46 checks migration of journal entries into ACDOCA. Then there are two activities
00:17:51 for migration of the material ledger. After the migration of the material ledger,
00:17:56 the activity for migration of balances posts balance delta adjustments into ACDOCA table.
00:18:03 In S/4HANA, totals are not stored in tables, but are calculated on the fly from line items in
ACDOCA.
00:18:10 However, there can be differences between totals calculated on the fly and the total values
00:18:16 in the original totals tables in SAP ERP, for example because historic line items
00:18:21 have been archived or as a result of a conversion. Therefore, in this step, deltas are posted in
ACDOCA.
00:18:28 So in the end, migrated line items plus balance adjustments from migration equal the original
totals.
00:18:35 And, finally, the last migration activity in the migration cockpit will calculate planned
00:18:41 depreciation for all assets in Asset Accounting. Now I will go back to my presentation...
00:18:56 Let's continue with migration steps which in release 1809 have not been
00:19:01 integrated into the migration cockpit yet. It means they still need to be triggered manually
00:19:06 by starting the respective programs. So, after the migration cockpit,
00:19:12 you need to migrate general ledger allocations. This migration step adjusts the definitions
00:19:19 of G/L allocation cycles. This is necessary because an allocation cycle
00:19:24 references a sum table that has been replaced by the universal journal entry table.
00:19:31 In step six, you migrate the existing house bank accounts configuration
00:19:35 into the new bank account master data. For your information, both migrate G/L allocations,
00:19:43 and migrate house bank programs are planned to be integrated into the migration
00:19:47 cockpit as of S/4HANA release 1909. In step seven, you convert SD foreign trade letters
00:19:55 of credit into letter of credit data in TRM trade finance. Here, in the Customizing activity,
00:20:04 you will find multiple programs for migrating financial document master data, for assigning
sales orders
00:20:10 to financial documents, and also for initialization of trade finance risk check decisions for
blocked sales documents.
00:20:22 In step eight, if you have SD credit management in place, then you can migrate it to SAP
Credit Management.
00:20:30 You migrate credit control customer master data fields, like risk category and credit limits,
00:20:36 into business partner master data. The business partners must be already created
00:20:40 before technical installation of S/4HANA in customer vendor integration.
00:20:45 You will find here also programs for rebuilding credit exposure from existing open sales
documents
00:20:52 and for creation of documented credit decisions for credit blocked sales documents.

36
00:20:59 In step nine, before setting migration to completed, you validate the results of conversion by
reconciling
00:21:05 and comparing the results before and after migration. Step 10, at the end, when you have
successfully finished
00:21:13 all activities, you can set migration to completed. This will trigger last checks for consistency
00:21:20 and completeness of migration. If there are no relevant errors, the migration is completed,
00:21:25 and postings in the system are again allowed. Technically, this means the end of business
downtime.
00:21:34 Now, after completion of a migration, there are some more activities you can or have to do.
00:21:41 Downtime is not required, but I recommend it for some of these activities.
00:21:45 First, you can transfer application index tables to the cold area of the database to reduce
memory consumption.
00:21:52 Then, fill the new due date fields in the relevant line items and fill
00:21:57 the offsetting account in FI documents. You can enrich balance carryforward
00:22:01 of G/L accounts with Open item Management activated with the additional dimensions that
were not available in G/L before migration,
00:22:10 for example from material ledger or Asset Accounting. Manual activities for trade finance
00:22:16 and manual activities for credit management are required for rework of unmigrated data.
00:22:23 In the next step, you migrate accrual engine. The migration of accrual engine transactional
data
00:22:28 can be performed after the migration of all other postings in the system.
00:22:33 Technically, it is independent, and it's based on the mass data processing cockpit.
00:22:41 The advantage of this separate migration is that it is possible to use the system
00:22:48 and perform all kinds of posting already, despite the accrual engine not yet being migrated.
00:22:54 Only applications that are using the accrual engine will not work until the accrual engine has
been migrated.
00:23:02 Then the accrual engine can be migrated at a different point in time, for example, on a
separate weekend.
00:23:08 Please note that customers upgrading from a release lower than S/4HANA 1809 need to also
migrate the accrual engine.
00:23:22 In the next step, to reduce memory and database footprint, you can deactivate the
reconciliation ledger
00:23:29 that is no longer needed in S/4HANA. You can remove outdated tables from the hot store
00:23:36 and also from the database because the entries in the old finance tables have not been
deleted by the migration.
00:23:44 For that, you have to execute the report and check the corresponding SAP Note for more
information.
00:23:51 Finally, after you have completed the more technical part of the conversion, you can think
about implementation
00:23:56 of new functionalities in SAP S/4HANA, for example subsequent introduction of document
splitting
00:24:02 or introduction of accounting principle or ledger in a separate follow-up project.
00:24:08 You can also consider all the new innovations in finance that come with SAP S/4HANA,
00:24:17 pick out important ones and implement them within the conversion project or plan follow-up
projects.
00:24:25 So with that, I will close this part of the openSAP course about conversion of accounting.
00:24:30 This also concludes the unit of week two. Thank you for listening and goodbye.

37
www.sap.com/contactsap

© 2019 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.