SAP Simple Finance - How Do I Get Started Without Migrating

Janet Salmon

SAP® Simple Finance: How Do I Get Started without Migrating?

~ Rheinwerk®

Bonn • Boston

What You'll Learn

This E-Bite offers you a comprehensive look into Central Finance as an SAP Simple Finance implementation strategy. It explains how to approach a Central Finance project, looking at the system landscape, organizational settings, and master data you 'll need to have in place before you start, and then at how to make the transactional data flow from your local systems.

1 Introducing Central Finance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1 Consolidation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Central Reporti ng. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Central Journal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Central Finance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Inheriting SAP ERP Financials Data Structures . . . . . . . . . . . . . . 14

2. 1 Data Structu res of Old...................... . ..... 14

2.2 The Basics of SAP Simple Finance. . . . . . . . . . . . . . . . . . . . 17

2.3 Central Finance Enhancements. . . . . . . . . . . . . . . . . . . . . . 21

3 Choosing Central Finance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 New Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.2 Data Harmonization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4 Implementing Central Finance . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1 System Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2 Global Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Master Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4 Cost Obj ects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5 Transactional Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5 What's Next?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4

1 Introducing Central Finance

Many global organizations record their financial transactions on not one but several ERP systems and then combine these financial transactions for the purposes of corporate reporting. Some of the financial transactions are typically captured in SAP ERP systems, whereas others aren't. However, even using SAP ERP systems doesn't guarantee that corporate reporting is simply a matter of aggregating financial data from multiple systems. Some SAP ERP systems will inevitably have been implemented at different times using different approaches or will have been acquired along with acquired companies.

The consulting approach to deal with this disparity has often been to define a global template at headquarters and gradually roll it out to the various subsidiaries so that all parts of the organization are capturing their financial transactions within a similar framework. This typically means virtually reimplementing financials and can be a costly and time-consuming undertaking.

Another approach that is gaining favor is to set up a Central Finance system that includes the best practices that have evolved over the last several years and the technical innovations that have been made possible recently with the advent of SAP HANA and the strategic redesign of financial applications. This Central Finance system collects the financial data from each of the local systems and combines them into a harmonized form in real time.

The idea that a global organization might want to combine financial data from multiple systems in one central system is hardly new. Consolidation solutions have been gathering financial data from multiple systems, harmonizing this data, and eliminating the intercompany markups to provide a consolidated financial statement for the group as a whole for many years. Many large corporations have implemented one or more data warehouses to bring their data into a structure suitable for financial reporting.

5

Introducing Central Finance I 1

Before we delve into employing the Central Finance model. let's first review the approaches your organization is already taking and where Central Finance extends or changes this approach.

1.1 Consolidation Systems

The purpose of a consolidation system is to provide a consolidated financial statement for all affiliated companies in a group that eliminates intercompany markups. This is a highly regulated process driven by requirements such as !FRS 10 (Consolidated Financial Statements) and similar regulations.

This method isn't without its disadvantages. The challenge of the typical consolidation approach is managing timeliness of the data. The parent company must wait for all subsidiaries to prepare their ind ividual financial statements and submit their data before it can then aggregate and eliminate intercompany business to prepare the consolidated financial statements. It is the nature of this process to be looking backwards to the period just closed, and this wait time means that it can be too late to remedy any local issues by the time the information reaches headquarters. How can this be improved? Instead of taking monthly snapshots from the local systems, the Central Finance approach involves a real-time update with each and every journal entry. Headquarters has the relevant journal entry mere seconds after the transaction happened.

Another challenge of typical consolidation is that the primary purpose of financial data being collected in a consolidation system is to state the financial position of the organization as a whole and not necessarily to understand whether individual plants or market units are working efficiently. To make this sort of decision, financial data needs to be more granular- in other words, to include not just the legal entities in the group but also the reporting entities that represent the structure of the organization, such as profit centers and cost centers, and those that represent the business output of the organization, such as the products and

6


services it sells, the customers it serves, and the regions where it is active. Therefore, instead of collecting highly aggregated data at month end, the Central Finance approach collects each and every journal entry. The journal entry itself contains all the reporting dimensions available in the local system, including vendors, customers, materials, plants, profit centers, cost centers, projects, and so on. The potential to slice and dice through all the relevant dimensions for running a business is huge and is greatly facilitated by the technological advances provided by SAP HANA.

Of course, aggregating this kind of data brings its own challenges. The typical systems that many corporations use today collect their financial data using multiple charts of accounts, and their master data is far from harmonized. This means a huge transformation exercise mUist occur as part of the period close to bring the financial data into a structure that can be reported on easily.

In Central Finance implementations, these reporting structures are prepared in that central system. As part of the implementation exercise, you set up your companies, profit centers , cost centers, customer masters, material masters, and so on. This is your chance to rethink your approach for every reporting entity, whether corporate, legal, or local, and potentially fix structures to take into account lessons learned since your original implementation. It can be your chance to "start afresh" at reasonable cost. You then define business rules that determine the accounts to be updated, the profit center to be derived, and so on as each journal entry is posted. This transformation sounds daunting, but with the correct business rules in place, you will be able to harmonize on the fly to achieve a "golden" chart of accounts, cost center structure, profit center structure, and so on, and reporting will simply be a matter of selecting the correct information and displaying it in the form required.

Although most organizations welcome the idea of the perfect chart of accounts and reporting dimensions, the practical implications of keeping the business rules up-to-date to accommodate whatever entries might exist in the local systems are complex. As each journal entry arrives, it is

7


subjected to the same checks as if it were the initial journal entry. This means that you can significantly improve the data quality available for reporting purposes. Any journal entry that fails one of these validation checks is parked in an error list, where corrections can be made manually while the master data and business rules are being worked on in the central system.

Essentially, the Central Finance approach is simple: establish a trigger to recognize the creation of a new journal entry in the local system, transfer to the central system using the system landscape transformation tools, map to the correct reporting dimensions, validate, and post. However, before we dive into the detail of how to establish such a system, let's look at some of the approaches from the past so that you understand what your organization might already be doing today.

1.2 Central Reporting

Data warehouses were widely implemented to provide corporate reporting options from the late 1990s onwards. These were designed specifically to provide reports that aggregated vast amounts of data. These systems were designed differently from the operational systems, moving the data into multidimensional star schemas to enaible drilldown reporting.

This distinction is typically referred to as the difference between an online analytical processing (OLAP) system and an online transactional processing (OLTP) system. This shift in the way data could be handled revolutionized corporate reporting. In general, data is extracted from the operational system using nightly batch jobs, transformed, and then loaded into the reporting system in a process referred to as the extract, transform, and load (ETL) process. If you use SAP's own data warehouse, SAP BW, then the extract process uses business content delivered by SAP to retrieve the relevant financial data from the SAP ERP system and moves it to the staging areas in SAP BW for transformation into the reporting cubes. One of the challenges here is that the data in a data warehouse is

8


just ... data. The journal entry that is the heart of the accountant's thinking is aggregated to give totals, and organizations spend a lot of time checking that the totals that arrive in their data warehouses match the sum of the journal entries in their operational systems and hunting errors when the two don't match.

J ust as we discussed in the context of consolidation, it's rarely sufficient to simply transfer data to another system and aggregate. A transformation is required. Over time, more and more business logic was implemented to transform and check data during the data loads to the warehouse, with the result that the load times and, along with them, the latency or time lag of the information available in the central reporting system increased.

Of course, today's SAP BW is a far cry from the SAP BW of the late 1990s. You don't have to replicate data; instead, you can work with virtual loads, for which in extreme cases the SAP BW is simply a metadata layer that describes the type of data you are analyzing but does not actually hold that data. Nonetheless, with each transformation come concerns about

auditability and reconciliation. Organizations want to trust their data and in the case of financial data want to look back to a single document and understand what business transaction (sales invoice, material movement, allocation, and so on) triggered that journal entry. A consulting solution emerged to fill this need: the central journal.

1.3 Central Journal

The central journal differs from a data warehouse in that it is document based. Instead of simply looking at data, you're looking at journal entries. Every journal entry in the local system results in an equivalent journal entry in the central system. If the sending system is an SAP ERP system, then the two journal entries can be almost identical or business rules can be applied to transform, for example, the accounts or the profit centers in these documents. Nonetheless, there is an inherent connection between the source journal entry and the target journal entry; this means that a

9


business analyst or auditor can be provided with a drilldown that allows him to see the document that initiated the posting in the central system.

The building blocks of this approach are as follows:

» SAP Landscape Transformation (SLT), which provides the technical link and field mapping between the two systems

» The BAPI BAPI_ACC_DOCUMENT_pOST, used to create the new journal entry in the central jou rnal

» Error Correction and Suspense accounting (ECS), which provides error handling for documents arriving in the central system

» SAP General Ledger (New G/L) and account-based Profitability Analysis (CO-PA), which provide the basic accounting structure in the central journal

Note

The central journal approach and t he data warehouse approach are not mutually exclusive, of course. The journal entries in the central journal can in turn be transferred to a data warehouse for further reporting or to SAP Strategic Enterprise Management-Business Consolidation (SEM-BCS) to be consolidated.

It is important to understand t hat the central journal does not replace the accounting ent ries in the local system. The logistics transactions and human resources transactions in the local system continue as before and write journal entries with every invoice, goods movement, payroll posting, and so on. In order to allow SLT to "listen" for new entries in the local system, you need to ensure that all involved systems have the SAP Landscape Transformation Software Add-On instal led.

The SLT process uses a table trigger approach. It relies on the data trigger in table BKPF (the header for the accounting document) to initiate a transfer of this accounting document to the central system. You can then define business rules within the SLT process to transform the data in the

source document, thus allowing you to map from a local chart of accounts to a central chart of accounts.

10


The posting mechanism in the central journal is the BAPI BAPI_ACC_ DOCUMENT_POST, and the transferred document is validated against exactly the same rules as would apply if the document had been posted in the central system. This means that the account must exist, the account assignment must be correct, and so on, before the document can be posted.

However, substantially different settings can exist in the central journal. For example, it's common to assign documents to a single controlling area so that management reporting is possible across all documents. Although the accounts and account assignments are typically mapped from the local system, for management reporting it's worth considering what is derived within the document. Many organizations derive new profit centers that match their ideal profit center reporting structure. It's also common to set up a single operating concern with account-based Profitability Analysis and to derive new CO-P A characteristics on the basis of the transferred products and customers.

The central journal approach brings together software components that already existed to achieve the desired result without making any changes to those components. With SAP Simple Finance, SAP offers a deployment option that offers dedicated features designed to support its use as a central reporting system.

1.4 Central Finance

Without jumping too far ahead, Central Finance acts as a document-based reporting system.

To understand what this means, consider Figure 1, which shows a document that looks at first sight like any normal journal entry, for document number 10000081 7 in company code CF01 and fiscal year 2015. This document records the price differences during the settlement of a production order, as shown in the header of this document via the reference

11


transaction (REF. TRANSACTN) AUAK and the transaction code (TCoDE)

K088.

~ • Display Document: Oatil Entry View

Data Entry View

Document t~un'ber 100000817

OO<Ument Date 16 . 03.2015

Reference

Currency tUR

Co(l"()any code crot FiSal Year

Postilo D-at e 31. 03 . 2015 Period

CrO...C011'4>.No.

ledger Group

~ I A Y lX) ~ • 1: . a )I e @l • 141 • <!:! . [1 IJ1i I Ill

2015

3

~ .. .. Itm PK S Account Oesa;:,tion Amount Curr. Tx Ono doc. BusA Cost Center Proft Center Material '"501 1 91 895000 Fact.output prod.ord 2.189,... EUR CFOl

2 86 231500 Loss-own prod.pr.df 2.!89,.. EUR R-1!!00 - -----· ,.. SA .,fill Account Document Document type

Ooc.Header Text

Reference

Currency

Ref. Transactn

Reference Key Ente<ed by

Entry Date

TCode

O'lanoed on Ledger Grp

ActgPmQ>Io

.. .J-'

Document Date 16 .03.2015

POStl'\0 Date 31 . 03. 2015

toR Postno period 03 I 2015

Atw< Settlement document 0000012807 10Q.SVStem Q7QCL!IT002

JIH Pirl<ed by

07 . 04 . 20 15 nne of Entry n :oo:oe

Last update

Ref.key(head) 1

SenderlooSvstem 07QCLNT002

sende:r Ooc.r,o. 4400000727

Ref.key 2

Sender CoCode CFOl

Sender FtGlfYr 201s

Figure 1 Journal Entry in Central Finance Showing Link to Local System

More important for us is the link back to the journal entry in th e local system via the new fields SENDER LOGICAL SYSTEM, SENDER DOCUMENT NUM

BER, SENDER COMPANY (ODE, and SENDER FISCAL YEAR. These fields did

not exist before SAP Simple Finance. You'll notice that the document

number 4400000727 in the sender system is different from the document

number in the central system, 100000817, because the document has

been reposted rather than replicated or copied. Th is document link is crit

ical because it ensures auditability; each document in Central Finance is

explained by the triggering document in the local system. To find out

12

Qu•ntty Unt ! ,000· • .. 1,000 • ..


more about the origin of this journal entry, you can use ENVIRONMENT • DOCUMENT ENVIRONMENT • RELATIONSHIP BROWSER to display the chain of documents responsible for this journal entry. Again, this automatic drillback did not exist before SAP Simple Finance.

In Figure 2 , first you see the accounting document from Figure 1 and then the accounting document that was transferred from the local system that you saw referenced in the header. You can see that this accoun ting document was triggered by a settlement document (1 2807) when the production order settled its costs and that this settlement document triggered a separate controlling document (7000006417) and special ledger document (1000356660) alongside the accounting document.

Document Relationship Browser

~

Relationshp Tree Descrpt n

.., ~~i:o~.~ili.OJT9.QJ~meil!.":.-.-.~~::.=~~·~:.-.-.~=:.-.-.~·· .Ci.9.Hi.9.Ci.®9.~i7~?.911~::~.~~:=~~~=~~~~=~~~~~~~--.., Account ing document CFOl 4400000727 2015

" Settlement document 0000012807 • Controlilg Document CFOl 7000006417 • Special l edger Document CFOl 1000356660 2015 5 T1

Figure 2 Document Relationship Browser in Central Finance

What you see in Figure 2 is not just a technical link between two SAP systems but also an illustration of how SAP Simple Finance is simplify ing the financial landscape and merging the contents of several documents (in this case, the accounting document, the controlling documem, and the special ledger document) in classic SAP ERP implementations into one journal en try (the accounting document in the central system).

We'll turn our attention next to how SAP has been simplifying the financial landscape.

13

Inheriting SAP ERP Financials Data Structures I 2

2 Inheriting SAP ERP Financials Data Structures

As you might conclude from Figure 1 and Figure 2, SAP Central Finance is not a totally new product, but simply a new way of deploying SAP Simple Finance. If you have a heterogeneous system landscape, you could instead upgrade and migrate your existing systems to SAP Simple Finance or consolidate your existing systems and then upgrade and migrate to one SAP Simple Finance instance. The charm of Central Finance is that you can test the waters gradually. The only difference between a journal entry in Central Finance and any other journal entry is that, as you saw in Figure 1, it includes a reference back to the original journal entry so that accountants can trace back and understand why the posting was needed. In this context, the local system continues to be the system of record.

However, it's worth taking a minute to understand the how- in other words, what makes it possible for global organizations to merge accounting data at the line-item level from multiple ERP systems (SAP and nonSAP) into a single instance. The secret lies in the fact that the existing data structures in SAP ERP Financials have been completely restructured in SAP Simple Finance. We'll now look at some of these changes to understand how it is possible to handle such large data volumes on one SAP ERP instance.

2.1 Data Structures of Old

In this section, we'll look at the basic data structures that you are almost certainly using in any existing SAP ERP implementation. You can get an idea of the complexity of these structures by referring back to Figure 2, in which several financial documents represent one business transaction: an order settlement.

14


line Items and Totals

Every business transaction in SAP ERP is represented by one or more line items. The type and number of line items will depend on the type of business transaction.

For example, a sales invoice in the SAP General Ledger will typically include a sales revenue line, a r,eceivables line, and one or more tax lines. The receivables line will also be captured as an open item by customer in Accounts Receivable along with the due date and other information relevant for managing the open item until payment is received. The revenue line will also be captured in Profitability Analysis, along with detailed information about the products sold and derived information from the product and customer, such as the region of the sale, the product group, and so on. In contrast, reporting on the sales invoice currently requires an organization to look at line items in the SAP General Ledger, Accounts Receivable , and Profitability Analysis.

To take a different example, an asset acquisition will be shown in the SAP General Ledger as an asset acquisition line, a payables item, and one or more tax lines. The payables line will also be captured as an open item by vendor in Accounts Payable along with due dates and other information relevant for managing the open item until payment is completed. The asset acquisition line will also be shown in Cost Center Accounting, where the asset will be assigned to a cost center. To report on the asset acquisition requires an organization to look at line items in the SAP General Ledger, Accounts Payable, and Cost Center Accounting.

In addition to the separate line items capturing different perspectives of the same underlying business transaction, each application creates totals records (sometimes called aggregates), which group the line items by period, so in these examples you would find the sales invoice included in the SAP General Ledger totals, the Accounts Receivables totals, and the Profitability Analysis totals, and the asset acquisition included in the SAP General Ledger totals, the Accounts Payables totals, and the cost center totals for a given period.

15


If you might input a large number of document lines into a central system, then the existence of totals records can be critical. Whereas the line item is created by issuing a new document number, inserting the record into the database and moving on to the next, each totals record requires the system to lock the relevant totals record (such as the cost center totals for the period of March), perform the update, and then release the totals record. In extreme cases, when many documents are trying to update the same cost center in March, this can result in locking issues.

However, in SAP Simple Finance there are no totals records. If information is needed on cost center spending in March, then the totals are calculated on the fly from the line-item records, leading to a substantial reduction in the amount of data being stored in the central system to achieve the same result.

Some applications also create index records to accelerate selection during both reporting and operational processes such as dunning. In these examples, indexes are created for the SAP General Ledger, Accounts Payable, and Accounts Receivable. In SAP Simple Finance, selection does not require these indexes, and again we substantially reduce the amount of data being stored on the central system.

Reporting

Although it is definitely possible to report in the transactional system using tools such as Report Writer, Report Painter, ABAP List Viewer, Infoset Queries, and so on, many organizations move their reporting tasks out of the operational systems (O LTP) and into a dedicated reporting environment for performance reasons.

In some cases, the SAP ERP tools create further aggregations for reporting purposes, so Profitability Analysis uses additional totals tables known as summarization levels to preaggregate data for reporting. You'll find summarization levels for the totals by sales organization, plant, customer group, and so on. Similarly, in Product Cost Controlling, drilldown reporting and hierarchical reporting is only possible if the data is

16


preaggregated using a data collection run at period close that creates additional aggregate data. For example, if you create a reporting hierarchy to aggregate production orders by material, material group, and plant, the data collection run will create data records for each material, material group, and plant that you are operating in. In some cases, these records can represent thirty percent of all totals records in controlling. In SAP Simple Finance, aggregated reporting can be performed on the fly for such hierarchies, again reducing the data volumes needed in the system to reach the same result.

Financial Planning

Although many organizations moved their planning activities into a data warehouse along with their reporting activities, it is definitely possible to plan in SAP ERP.

J ust as with the many line items for one business transaction, you will typically find separate planning transactions for each reporting dimension. Therefore, you might find wages and salaries being planned by cost center and then pushed into the SAP General Ledger and material expenses being planned by project and then pushed into the SAP General Ledger. Each plan and/or push requires careful reconciliation, especially when you have to change data after collection, because you have to understand exactly how each record flows into the SAP General Ledger or Profit Center Accounting in order to retrace your planning steps.

In the form of SAP Integrated Business Planning for finance, SAP Simple Finance offers new options that treat the planning line item as one line, with each of the relevant dimensions being automatically filled as the cost center manager enters his wages and salary costs.

2.2 The Basics of SAP Simple Finance

How do the basic data structures offered in SAP Simple Finance differ from those used in SAP ERP implementations? Let's take a look.

17


Universal Journal

From the description of the multiple line items that resulted! from a single business transaction, it's dear that existing SAP ERP data structures involve a certain amount of redundancy. This was necessary back in the 1990s and allowed organizations to implement each application separately, but is no longer necessary in the twenty-first century.

In SAP Simple Finance, the information in the subledgers is merged with the information in the SAP General Ledger, so there is exactly one record rather than several for each sales invoice. The journal entry includes the subledger detail but is enriched to cover all relevant reporting dimensions; this means the business transactions will automatically be assigned to the correct profit centers, functional areas, business areas, and so on. These dimensions may not lead to redundancy if you are already running the SAP General Ledger (also known as the New General Ledger), but if you are using the classic(" old") General Ledger, then you needed separate ledgers for Profit Center Accounting, Cost of Sales Accounting, and so on, resulting in additional redundancy. Thinking about how to fill the dimensions in the universal journal is one of your critical decisions as you move towards SAP Simple Finance. Be aware, however, that the focus is currently on reporting the journal entries for the sales invoice. Central Finance does not currently capture the detailed subledger information for the invoice, such as due date and payment conditions. The same applies in reverse to the transfer of a.ccounts payable and to the transfer of assets.

Earlier in this section, we also looked at the way the asset acquisition was captured in Cost Center Accounting and the sales invoice in Profitability Analysis (the SAP ERP Controlling applications). In SAP Simple Finance, the dimensions in Cost Center Accounting, Order and Project Accounting, Activity-Based Costing, and Profitability Analysis are aU part of the universal journal. These applications capture not just the business transactions that have a real-world impact through their link with invoices, material movements, and so on, but also business transactions that record how costs are moved through the organization in the form of allocations

18

Inheriting SAP ERP Financials Data Structures J 2

and settlement. If your asset has been acquired for a production cost center, its costs will be included in the charge rate used as this cost center performs work for a production order. In accounting terms, this is an allocation in which you see a sender"receiver relationship in which the produc· tion cost center (the sender) is credited and the production order (the receiver) is debited.

In the universal journal, the multiple dimensions come into play again, with this movement being represented by a shift in profit centers, functional areas, and so on. These are represented as partners in the universal journal, so if the cost center and production order are assigned to different profit centers, then you will see a posting from profit center to partner profit center. If you are using the SAP General Ledger, then you will be familiar with this idea as real-time integration, but in the SAP General Ledger, these partner postings result in postings to a reconciliation account in the SAP General Ledger under the business transaction COFI. If you have a lot of profit centers or functional areas, then the number of

COFI postings in the SAP General Ledger can be substantial. In the universal journal, the posting logic has been changed so that these reconciliation accounts are no longer needed, and the secondary cost elements used to document the allocations, settlements, and internal activity allocations are treated as accounts in the universal journal.

Reporting and Analytics

The universal journal collects the relevant data for reporting, but you'll also need various views to prepare your financial data for reporting. SAP Simple Finance includes Smart Business applications that allow you to visualize various key figures, such as revenues, contribution margins, and cash. These applications use SAP HANA live views to access their data and aggregate on the fly. You can then provide these key figures to your man

agers on their mobile devices so that they have instant insight into the state of these key figures.

19


SAP Simple Finance also includes standard reports for a trial balance, the financial statements, profit center reporting, cost center reporting, order reporting, project reporting, and market segment reporting. For the most part, these use SAP BW technology in the form of virtual TnfoProviders that must be activated on the finance system in order to transform and aggregate the data for reporting. Note that there is no replication. Every updated journal entry will show in the report with the next refresh.

Integrated Business Planning for Finance

The embedded SAP BW that provides the basis for much of the reporting is also used in SAP Integrated Business Planning for finance. This planning tool is integrated in the sense that it brings together the various planning applications that were offered in the past, such as Cost Center Planning, Project Planning, Profit Center Planning, and so on. Just as the journal entries are enriched to fill all reporting dimensions, SAP Integrated Business Planning for finance derives the relevant profit centers, functional areas, and so on automatically as you plan wages and salaries by cost center or material expenses by project.

Therefore, you can switch constantly between the aggregate view by company code and the specific views by cost center, order, project, and COPA dimension. More importantly, you can use planning functions to copy reference data from previous fiscal years, revalue the copied plan items, and so on. Because the planning process is able to work with the same SAP HANA views as the reporting process , SAP Integrated !Business Planning for finance gives you much of the flexibility that you associate with SAP Business Planning and Consolidation (BPC) on SAP HANA, without the burden of replicating master data and transactional data to a data warehouse before you start the planning process.

20


2.3 Central Finance Enhancements

You've seen that SAP Simple Finance provides a leaner architecture for capturing financial transactions, but it also offers dedicated features for the new deployment option. We'll now look briefly at what functions are available in an SAP Simple Finance system that are specific to its usage for Central Finance.

Accounting Interface

In order to allow the sort of document transfer that we looked at in Figure 1 and Figure 2, SAP has created a new accounting interface for Central Finance. This involves capturing the data before the journal entry is created in the local system an d then transferring this raw journal entry to the central system. On arrival, the documents can be transformed according to business rules and a new accounting document created that provides a link back to the original journal entry. What's important here i.s that the typical journal entry is often highly summarized to avoid posting revenue lines for every single product in the invoice. Because the new transfer structures capture the document prior to summarization, you will have all the revenue lines in the journal entry in Central Finance. We'll look at these interfaces in more detail in Section 4. This granularity is the key difference compared to the central journal approach, which used a BAPI to transfer the journal entry in its summarized form and thus could not provide the same level of detail.

If the sending system is a non-SAP system, you can use the same mechanisms to read tables, transform them so that the fields map to SAP entities (such as company code or profit center), and then initiate the creation of the relevant journal entry. The appeal of this approach is that entries that originate in non-SAP systems still feel like SAP journal entries once they have been reposted.

21


Mapping Rules

In addition to the technical transfer structure, the Central Finance system provides mapping tools to transform global parameters, such as countries and company codes, master data, accounts and materials, and even highly dynamic cost objects. This allows you to create that "golden" chart of accounts or perfect profit center structure, however heterogeneous the entities in your local system may be.

If in the past you've worked with other system connectors, such as application link enabling (ALE), you'll recognize the basic principles of intermediate document (!Doc) transfers. However, you'll find that you get significantly more flexibility in the Central Finance approach, because ALE scenarios typically create one FI document from another FI document, one CO document from another CO document, and so on, rather than the merge we see in the Document Relationship Browser in Figure 2. There, the accounting document, the controlling document, and the special ledger document in the local system merge into one accounting document in Central Finance.

Because master data plays such a major part in any Central Finance project, it also makes sense to consider the use of SAP Master Data Governance in the context of Central Finance. If SAP Master Data Governance is already in place, this mapping can be read during data transfer. If not, you can reuse some of the basic mapping tools at no extra license cost and extend via BAdl if your organization has more complex requirements.

Implementation Guide

Whereas early central journal projects involved consultants putting the appropriate systems together, Central Finance includes an implementation guide (IMG) that will walk you through the entire setup process. We'll look at this IMG in detail in Section 4. However, before we move on to how to complete these steps in detail, we'lllook at what drives organizations to take the Central Finance approach rather than migrating their existing systems directly to SAP Simple Finance.

22

Choosing Central Finance I 3

3 Choosing Central Finance

Few people would argue against the overhaul of the architecture in SAP ERP Financials, but any system change can be daunting, and the windows in which those changes are technically possible become smaller as system landscapes become more complex.

Even an organization that is running a single SAP ERP instance often interfaces many external systems into that system, and the barrier to change is huge. As we saw in Section 2, the data structures in SAP Simple Finance are quite significantly different from those in a classic SAP ERP Financials system. A move to SAP Simple Finance will involve upgrading the existing system to SAP Enhancement Package 7 for SAP ERP 6.0, migrating the underlying database to SAP HANA, and then migrating the financial applications, a process that will involve removing totals tables and index tables, merging line items of hugely different granularities, enriching these line items to include all required reporting entities, and

then ensuring that the balances match. Although the first customers have already proved that such a migration definitely can be done in a timely manner, migrations involve significant downtime and testing. More pertinently for the Central Finance discussion, a migration will change your data technically, but it won't change your reporting structures. You'll still have the same accounts, profit centers, cost centers, and so on, that you had before the migration, though admittedly your data wm be much leaner.

3 .1 New Architecture

The new architecture with the single source of the truth (in the form of the universal journal) and the new leaner reporting options are clearly two reasons to make the move to SAP Simple Finance. Let's look at these two options in more detail.

23


Universal Journal

In Section 2, we discussed the use of the universal journal instead of multiple line items. Translated into the Central Finance environment, this means that as your sales invoice arrives, it will contain the information in the FI posting in the local system, though you may potentially find more posting lines arriving if you have been using summarization locally. Now, the process of enriching the reporting dimensions in Central Finance can begin.

If you are running CO-P A, the sales invoice will already contain the customer information and derived dimensions, such as the customer group and region. These can be transferred in a one-to-one manner or mapped to different entities. The sales invoice will contain organizational information about the company code, and further organizational informationsuch as the responsible profit center and functional area-can be derived from the master data. If the transaction in question is an intercompany sale, it will contain information about the trading partners in the relationship that will be needed for intercompany reconciliation later. If the transaction is a purchasing invoice, the document will contain information about the supplier and the account assignment in management accounting, such as the cost center, order, or work breakdown structure element, and again organizational information such as the profit center and the functional area will be derived. What's important is that this journal entry will be potentially richer than the document in the sending system, because more reporting dimensions are filled regardless of whether you then start to perform data transformations. As you saw in Section 1, one business transaction in the local system may be represented by multiple documents, whereas in the central system there is a single document.

The universaljournal sounds fine in principle, but many organizations are afraid that the move to Central Finance will break the link to the business process that initiated the transaction in the local system and their logistics processes in general. The easiest way to quell this fear is to show the link

24


back from the accounting document in the central system to the triggering accounting document in the local system and all related business transactions, which provides a transparency impossible to achieve in a data warehouse.

Figure 3 shows the accounting document 4900001736 in the central system together with its sister accounting document 4900000106 in the local system. Notice that the original document here was a material document 4900013968 for the outbound delivery of a sales order and that we can see the full chain of logistics documents (the outbound delivery, the sales order, and the transfer order) as well as a controlling document 0000003114 in the local system.

Document Relationship Browser

~

Relationship Tree

v Accountng document v Account ing document

v Material Document v Outbound Deivery

• Sales Ord er v CustlndivBIIingDoc

> Out bound Delivery • Controling Document • Account ing document

• Transfer Order • Controling Document

Descriptn

FOOl 4900001736 2014 FOO l 4900000106 2014 49000! 3968 2014 0081015727 0000050426 0090019700 0081015726 COO! 0000006309 FOOl 1800000187 2014 100 0000001346 COO! 0000003114

Figure 3 Relationship Browser Showing the Two Accounting Documents and the Logistics Documents in the local System

From an audit point of view, if you select an accounting document and choose ENVIRONMENT • DOCUMENT ENVIRONMENT • ORIGINAL DOCUMENT

in the central system, you will automatically navigate to the material document for the outbound delivery, as shown in Figure 4, in which you can see details of the material document and outbound delivery document referred to in Figure 3. This gives you all the benefits of an integrated accounting system and keeps you completely auditable, because you can trace back the origins of every journal entry in your central system.

25


!!._ • Dlspkly H11ferkll Documt!nt 4900013968- Dr. H lclult!l Schmidt

III He~

Oocul"l'ltnt O~te 21. 10. 2014 Ot livery uote oo~101S72"7

Posttlo .nte 21. 1o.2ou .. olUd"i~ Kea!lerText

e c.~e""' s"' l.i'le Mlt. Short Tut Qtyn UnE E ... Sloe Bu ... G}l Account e.tdl ~l;ation ... M ... 0 Stoct Type Pht S ... l':

I jJR T>bltt (fo""od P<odu<t) PC UOtrOOOt PC UQer ODOJ

FOOl t9~15 601 - Unre.strlet.e v TOQtJ Gtrrn1

2 _JJR nb*t 2 (R'IIihed PtodtKt) fOOl eUOlS 601 • V.!!..r .. trleu .. v ToolsGerma .

( )

Amt.n loc.wr, sso. 00

Figure 4 Navigation to Original Material Document from Central Finance

SAP Fiori and Modern User Interfaces

The leaner architecture makes it technically possible to combine financial data from several ERP systems, but you'll want to make sure you leverage the near-real-time availability of your financial documents to provide instant insight to your management teams. Until now, we have only shown classic Uls , but Figure 5 shows a sample journal entry in SAP Fiori, SAP's latest approach to user interface (UI) design. Managers who have shied away from working directly with the SAP ERP Uls can be enticed into the central system with the promise of attractive Uls and the promise that they can have immediate insight instead of waiting for the typical report packs that turn up at period close when all the close tasks are signed off.

In the normal run of things , the journal entries in Central Finance are shadows of the original documents in the local systems. However, because Central Finance is a fully functional financial system, it's also worth considering where you will allow management adjustment

26

( )

Choosing Cent ral Finance I 3

postings in Central Finance and who you will authorize to make these postings. If you want to keep these journal entries separate from the operational postings arriving from the local systems, consiider implementing an extension ledger to keep these journal entries separate from the operational postings, and ibe restrictive about who can post to this ledger and under what circumstances. Also consider implementing the new UI for journal entries, just to make a visual impact.

Journal Ently (100000000) • Ently View 0

0 0 0 ~'£ACE~ ATTACHI.IEHTS NOlES M.ATEDooc::u.EifTS

Dot~ON 09 1020U ~!)Me 09 10201•

PiMOcl 101 l'OU

Jl),ottllllftoWYTyPt GtlloC.COUI'IIOOt\ll'rlti'IC(W

~Coot s.-.P A. G {0001) Tt.,._IIOII CVf('f'lfy f~

......... ~ T~on ACIQIOO<Ot'fCtq,: (8KPff)

HMOf'fff'4 Ctt~H Oy~~-et01'109 102')U

Oefaun G 0 (i

000001

000002

Figure 5 Document Display in SAP Fiori

.......

5000 ""' 000 ru:t

It's nice to be able to display individual documents, but most managers are more interested in the big picture and will be drawn towards apps such as the Financial Statement app shown in Figure 6. This E-Bite isn't the place to explain all its featmes, but it's easy to switch your selection, because the selection parameters are at the top of the screen rather than on a previous page. You can use the type-ahead function in the SELECT NODE or SEARCH areas to find the account group of interest instead of try

ing to keep your account structure in your head. Of course, there are other SAP Fiori apps of interest, including the Trial Balance, Line-Item Browser, and dedicated apps for Cost Center Reporting, Profit Center

27

0 .00 ~ $000 E~

DefaUlt 0 0


Reporting, and so on, but this app definitely provides a taste of the new reporting options.

Q. ; ........... .. 2014 2015 G) ..... ,,~ 8¥ ,.ffl 1$) Ill

''r-.ui~~Vei')Cirl 'Pn!l.tte 1)~ ·Kev~ Kev~Pfr1CMJ 'o..-rent)·

a ~ .... , 201e. t~(~nyOo v

..... _ ....... 0. .. " ""'"- Go\.AtCOI.IAI Ptl'10o8allftet COm!) PtfloO 8a1Wf' ~~Met

~ A.SSETS ., 06718$ 11:J..$7 ~ C:Utfenta55els ·I 0671$S 11l87

)

""'"""' ·<173<1~900.00

) ActounllrH""llill' Mil 3667.11418613 ~ LIA81LITIE$ 106118$113..$7

) Sl«~s"cqllt)' ·131:te®IH7$

> ....... 2 380 cos 2M-$)

~ Pf(IO"W~b$$$1~1 U2$$~11ot0.0$ ~ ............. tl~./3/UOOS

~ Qf0$tt,.......,. 12$6712000000 ~

"'"'"''

_,_ ••:n260-CCIO.OO

s.s ~nut$. oomt~ • ~·:1¥ ... U~~ ·I teOOOO.OO ·I !292<10000.00 I 12726000000 ) Forei;JR ~<A8Nn<f1 I1.13$560CIOO-OO

) S.itt<I$0U(OOf'lt ·<11<1$216t~

) ~lnrwet'IIOIY

' ""' ' "" Figure 6 Financial Statement in SAP Fiori

Plenty of managers and controllers prefer Microsoft Excel as a frontend, so you might want to consider displaying your reports in SAP BusinessObjects Analysis for Microsoft Office, as shown in Figure 7, though this will have license implications. The navigation panel offers drilldown options for all the dimensions in the universal journal without the need to move data into a dedicated warehouse. Essentially, any managers who can work with a pivot table can use a report like this one to access the detail they need for their work.

However, architecture and VIs alone probably won't provide sufficient benefits to make a good business case. The Central Finance approach begins to score highly when you have a heterogeneous system landscape with untidy accounting structures. In this context, data harmonization and the associated costs can be a huge driver for change.

28

Default 0 0 ---·i90

· 100)

'"' .. o ·100.6

•u 1000 ,. ... ... ...

· 1000

'"' ""'

Choosing Central Finance J 3

!iii.- ... ..... .

2 I .I • Salub-....ab_.. . , ' II

" , "' "' .. .. ., .. .. .. eo 12·-...o... .. >J

" .. ., .. .. .. .• , '" IU

"'"""""'

'Jl' 'V> " :~ ~= c::'..:'-!0 ~· Rfltt'*' ~.,...,_ •

o.-. ... ~ \.t'l! oftf#'

H ,_, ~171.000.00

11.000.00

...... ,.-oo.oc 4$1,~00.00

1,000.00

t.ll ·~ ·2,.00.00

li,·COII:<IIU... o~ ..... ..,OIIel"llii!Or·~ · l SI,AOO.OC ·Ls->.00

0000199999 tOOT._ASTt •1S..SU,A10.00 <:~ ...... ____ 0000+00000 · ),000.00

U....,Co-rec:t ~)0000

~.~ ... ·C~t~er~~-~ ~-"".--t -s.aoo.oc ~ : .soo.oc

·::ao.oc ,...._....,.,[·-- 1.680.00

•12.880.00

~-~- •.aoo.oc

,_.,,., lOM Eltd'wo •r.e CM'Ier- OOOO:UOOOO

:o.soo.oc 20..)0000

•I,:ZOO.OC

· 2.1100.00 •I,I,U.ll)

•$90.00

·HO.OO

Figure 7 Financial Statement in SAP BusinessObjects Analysis for Microsoft Office

3.2 Data Harmonization

·-• MX1,.10t

. eo-.c.

Organizations running a data warehouse typically solve the problem of heterogeneous reporting structures by performing a huge mapping exercise as they move data between systems. Although this transformation works on paper, it can make reconciling the relevant data extremely challenging, and most data warehouses can't provide a drilldown to the original documents with the detail that we saw in Figure 3.

Central Chart of Accounts

Probably the most common corporate initiative is the move towards a central chart of accounts. The idea here is that you can compare apples with apples and that everybody who is posting freight is posting to the same account rather than treating freight variably as a separate item or as part of material costs, to give just one example. The posting logic in the

29


local system remains as before, so you don't have to revisit your SAP ERP Materials Management account determination (or whichever account concerns you). As the freight line arrives in the central system, a business rule assigns it to the correct freight account. This might be a 1:1 shift (freight to freight), for which you would need to put a simple mapping in place, or might involve a more complex shift to determine what part of the material costs can be considered freight, for which you would need to define a BAdl to determine the correct account assignment.

Central Profit Centers and Cost Centers

Probably the next most common corporate initiative is the shift to one controlling area . Plenty of European organizations created a one-to-one relationship between their company codes (the legal entities) and the controlling areas (the management reporting entities) so that the controlling area values would be available in their local currency. In the meantime, many of these controlling areas are operating in Euros, and the organizations are stuck with the fact that cross-controlling area reporting is only possible in a data warehouse.

These organizations are exploring the option to map their various controlling areas to one controlling area operating in their group currency in the central system. Of course, this harmonization comes at a price. All entities making journal entri,es in the central controlling area have to use the same chart of accounts, but as we just explained, this is often the intent. If country-specific accounts are needed, they can be handled using an alternative chart of accounts that only applies for individual countries. Be aware, however, that all entities making journal entries in the central controlling area have to use the same period structure, which can be a challenge in some countries.

The use of a single controlling area also has implications for master data maintenance, because the profit centers and cost centers are always defined with reference to a controlling area. This can be the driver for change in tidying up the profit centers and cost centers in the central

30


system. As you think about changing your cost centers, you can take essentially the same approach as with the G/L accounts, establishing business rules to make the switch for you.

If you are using the SAP General Ledger in your local system, then you can take the same approach for your profit centers and switch the assignment as the journal entry is created in the central system. If you aren't using the SAP General Ledger or even Profit Center Accounting at all in the local system, then you can consider a different option. Instead of transferring the profit center, transfer only the cost center (or order, project, or whatever) and have the system derive a profit center from scratch as the journal entry is created in the central system.

If you have completely new profit center and cost center structures, you're also going to have to rethink the structure of your profit center and cost center hierarchies. This can be the moment to make some fundamental choices about how you want to look at your business to create consistency across the whole organization. If you cannot describe your organization wholly in terms of cost centers and profit centers, fear not: you can also introduce reporting dimensions, such as responsibility centers, that don't exist in SAP ERP at all, and create derivation rules to fill these dimensions as journal entries are created in the central system. Remember as you do this that you will probably transfer not only cost center expenses but also orders and projects, and you'll want to set up a consistent derivation approach for all these objects.

Central Operating Concern

Disparate controlling areas often go hand in hand with disparate operating concerns.

The arguments for creating operating concerns for profitability reporting with different characteristics are many: each country has its specific reporting needs; each line of business has its specific reporting needs; business to business is different from business to consumer; and so on. Even if you have it right for a while, you may acquire a company that

31


looks at its customers and products differently and then struggle to get a complete picture of your organization. As you configure your central system, you can set up a single operating concern with a consistent set of characteristics for reporting.

Of course, this is easier said than done. Looking at your existing operating concerns is generally a good place to start. They will probably all use the standard characteristics delivered by SAP, such as product hierarchy, customer group, and sales office, and will have added several of their own, such as brand and sub-brand in the consumer products industry. If you are lucky, the operating concerns in your local systems will have different technical keys but a substantial degree of overlap in their choice of characteristics. If you have grown by mergers and acquisitions, you may have a zoo of characteristics in your operating concern and will need to have some hard talks to reach a consensus. Nonetheless, having all participating entities reporting according to the same characteristics will reduce your transformation effort at period close. The better your derivations are as each journal entry arrives, the less you'll have to face at period close.

Remember also that in account-based CO-PA, the characteristics are part of the universal journal entry. If you are only using costing-based CO-P A in the local system, then the characteristics can be derived from scratch as your invoices, sales deductions, and cost of goods sold postings are made

in Financial Accounting. By contrast, allocations and settlements that originate in Controlling will arrive in the central system with an assignment not to the relevant characteristics but only to the reconciliation object, used as a receiver to balance the posting in Cost Center Accounting and Order and Project Accounting. If you want to transfer such details, consider activating account-based CO-P A in the local system to ensure the necessary line-item detail.

Central Material Masters

For most organizations, the idea of having consistent material masters is the holy grail of harmonization.

32


In the local system, you are forced to be consistent; otherwise, you won't be able to transfer materials between plants. As soon as you move data to different systems there are no such checks, and it's entirely possible to have the same product going by two different material numbers or a sin· gle material number being used differently in two different systems.

If you're already feeling faint at the idea of harmonizing your material masters, remember that there is no reason to harmonize everything. Central Finance doesn't need to know about your settings for warehouse management or production, but it does need a consistent numbering scheme, consistent product hierarchies, material groups, and any other material grouping that you want to use in reporting. It makes sense to go through the material masters for each material type and identify those fields that you'll want to use for reporting. You will then need to understand where you can keep the material keys as they are and where you will need to make a key mapping to create unique material numbers with the correct numbering scheme in Central Finance. If you have SAP Master Data Governance in place for your materials, you already have the mapping you need in place. It also can be worth looking at the master data schemes used in your data warehouse as a blueprint for your design.

Central Customers and Vendors

You'll want to take a good look at how you currently handle customers, vendors, and other business partners. As you draw up this list , don't just look at external customers and vendors, but look also at intercompany relationships, in which individual plants and distribution centers act as customers and vendors within the supply chain. As of the time of writing (fall 2015), you can transfer the open items for Accounts Payable and Accounts Receivable, but you cannot perform any kind of clear ing against them. Instead, they are technically cleared on transfer to Central Finance.

This will be enhanced in future releases to allow you to centralize your payment processes and use the new Uls for Accounts Payable and Receivable in SAP Fiori.

33


3-3 Scope

We've talked a lot about Central Finance as a reporting tool that uses the most granular data available (the line items) as its starting point, but this can lead to the impression that Central Finance is no more than an "accounting BW." The greater your current investment in data warehouses, the harder it can be to make the business case for Central Finance. What's important to note is that Central Finance can be a starting point for further process centralization and that accountants and business analysts can gradually do more and more in the central system. As you think about this journey, it's worth looking at what else you can add to the equation to tip the balance.

Intercompany Reconciliation

One obvious next step is to activate intercompany reconciliation on your central system and match payables and receivables from affiliated companies as early as possible instead of waiting for the period close to tidy your books.

Figure 8 shows the intercompany reconciliation cockpit that is available as part of the SAP ERP license. Technically, intercompany reconciliation matches payables and receivables from affiliated or partner companies by group account, with an option to match additionally by partner profit center. From a UI perspective, the intercompany reconciliation cockpit is a set of Web Dynpro applications that you need to activate. Earlier versions of the product used a special ledger to store the relevant items, but from SAP Business Suite powered by SAP HANA, the intercompany reconciliation takes place direcdy on the financial documents.

You might think that a special ledger is hardly a huge burden, but even moving the relevant data to a special ledger typically results in a latency of half an hour. Now, each invoice is available for matching as soon as the accountant refreshes the cockpit. This simple addition can be a great way of getting buy-in to a project from your key stakeholders at headquarters.

34


ll * 04-0WI ...... _, ... 04.k(~~ o--·\-OiiMofl ........ __ Atw.lllr<:..--lvtnoorOfP ...,...__

.. __ ,__,

~--Figure 8 SAP Intercompany Reconciliation

0. .... .. ..

l'*Sti.,_,.DI'hrtne•

,_._llodOCI!IOOIS O..t_.,M 1!.-YCO

1000l•IIOO -

Integrated Business Planning for Finance

It's also worth doing your financial planning on the central system so that you can easily see whether you are meeting your objectives as you execute this plan.

Figure 9 shows a sample planning application for the profit and loss statement. This will look familiar, because we're using SAP BusinessObjects Analysis for Microsoft Office as the frontend, as we did in Figure 7. You'll notice from the naming on the other Excel tabs that SAP Integrated Business Planning for finance pulls in data from Cost Center Planning and Market Segment Planning to provide a complete picture, with more options available for Project Planning, Profit Center Planning, and Order Planning.

35

---


A B c 0 E --Plan P&L ~ Company Code FOIO

F iscal Year: 201 4 Version: 2

Copy Actual to Plan I I [+] Total Actual 2013 I!+] Total Plan 2014 loifference Plan - Actual

G/L Account - - EURI EURI EUR

[-]Re venue !NT OAS-REVE1 -4.964.813.298,99 -2.015 .722.754,46 2.969.090.544,53

[ +] External revenue ! NT OAS-REVENl -2.339.023.089' 71 -562.516.086,95 1 .776.507.002,76

[ +] Intern.revenue from ! NT OAS-REVCAP -2.645 .790 .209,28 -1.453.206.667,51 1.192.583.541,77

[ -] Personnel costs !NT OAS-PERS1 2 .476.420.747,41 37.621.451,06 -2.438.799.296,35

[ + ] Labor costs !NT OAS-LAllCOS 1.321.194 .306,10 13.748.608,26 -1 .307.445.697,64

[ +] Salary OH costs !NT OAS· SAL1 264.155 .246,48 13 .287 .001,81 -270 .868.244,67

[ +] Employee benefit cos !NT OAS-EMPBEN 871.071.194,83 10.585.640,99 -860.485.353,64

[ +] Consumpt.raw and aux !NT OAS-CONRA W 2 .259. 700 .584,38 23.243.432,39 -2.236 .457.151 ,99

[ -] ~1iscellaneous costs !NT OAS-MISCOl 4.296.726.342,31 52.729 .045,15 -4 .243.997.297,16

[ + ] Energy and water cos ! NT OAS·ENWA 703.682 .640,33 8 .372.003,57 -695.310.636,76

[ + ] Lease and occupancy ! NT OAS-LEASEl 3.341.810.185,28 40.576 .443,04 -3.301.233.742,24

[+]Taxes !NT OAS-TAX1 251.233.516' 70 3.780.598,54 -247.452.918 ,16

[ +] Secondary costs ! NT OAS-SECOS 156.614 .798,17 1.998.516,52 -154.616. 281,65

~ Revenue on Market Segments Functional Expenses (±)

Figure 9 Integrated Business Planning for Finance

SAP Cash Management

When looking for a system on which to run Central Finance, don't forget that you might already own a dedicated treasury or cash system whose usage can be expanded with the appropriate upgrades to cover Central Fi nance. Of course, if you do this you'll have to be careful to ring-fence adjustment entries coming out of your treasury system and being sent to the local systems in order to prevent circular relationships.

It's also worth looking at the new version of SAP Cash Management delivered with SAP Simple Finance, which enables the group treasury or cash department to manage cash and liquidity centrally. It offers complete SAP


Fiori coverage; all the features needed for bank account management and cash management are available as new-look Uis. SAP Cash Management has already been optimized for use in the context of Central Finance. Whereas a pure cash system must call into the local systems to collect information about the cash-relevant payables and receivables, SAP Cash Management can access the relevant information directly from Central Finance. In the future, the basic cash management functions will be expanded to capture further details about the organization's financial exposure.

SAP Financial Closing Cockpit

As you think about centralizing close processes, it's worth looking at the SAP Financial Closing cockpit that allows you to start period close processes in any of the attached systems, though it does require an additional license. Installing the SAP Financial Closing cockpit won't force you to change any of your period close processes; it merely makes them more transparent and allows you to start and monitor them centrally. However, it can be the first step on a mental journey towards centralization.

One example of a transaction that could be performed centrally is topdown distributions in CO-P A (Transaction KE28), in which you are simply making corrections to your CO-PA assignments with no influence on your financial statements. This is a relatively easy transaction to begin with, because you're posting with reference to actual data that should already be captured in Central Finance. Figure 10 shows a number of Smart Business tiles that display close key figures from the SAP Financial Closing cockpit.

37


1P.1 J ~ 1-l jl

Dec 2012 Closing

•1 h Delay

2.c 0132 ~· eompleted

~ lit

Net Order Entry

•$20M 1.

F<1sl FlndncJ,JI Close · ·.·•·

Actual I Planned Spend

•$0.5M

• NET CASH POSITION AT

•€5,1M 1ft

Dec 2012 Closing

T 4 h Delay -10 Of 32 tul(t COf'I'IPI;tt~

GROSS MARGIN IS DOWN TO

7,8 °/o .r.:l

Figure 10 SAP Smart Business Tiles for SAP Financial Closing Cockpit

3.4 Deployment

As SAP offers more and more options to work in the cloud rather than in the classic on-premise approach, it's also worth calculating which approach makes the most sense for your business .

The one we are all most familiar with is the on-premise approach; Figure 11 shows your basic options.


SAP R/3 4.6C I J.

6 Database trigger

SLT Replication Server

SAP Master Data Governance

SAP Simple Finance

Noo-SAP ERP I Central Finance ........,

Accounting ~ Interlace

Business ...3lo.

Mapping "7"

Error Correction Suspense ~

Accounting

Internal Accounting

l nterfat~~ (ECSl

J.

l HANA

I Universal I JoumaJ Entry

Figure 11 Central Finance Architecture

In addition to your existing systems (shown on the left in Figure 11), you will need the following:

» SAP Landscape Transformation server to make the technical connections between the local systems. Because SLT works on the database level, it is easier to integrate non-SAP systems, as only the database of the non-SAP system needs to be accessed without having to implement modifications on its application server. SLT can be installed as a separate system on top of any of the source systems or the Central Finance system.

» SAP Simple Finance powered by SAP HANA as the Central Finance system. Once the data is fed into the Central Finance interfac·e, it can be mapped in order to harmonize master data between the systems. This mapping either needs to be maintained manually or, if SAP Master Data Governance is used for distributing master data, can be retrieved from the SAP Master Data Governance tool. SAP Master Data Governance is

optional, however!

It is also possible to install the Central Finance instance and the necessary SLT replication server on the SAP HANA Enterprise Cloud. This can make

39

Implementing Central Finance I 4

sense if you don't want to include a new system instance in your existing landscape and are willing to consider new service options for cloud operations in your thinking.

Now that we've covered what setup you're coming from and what you should consider when evaluating Central Finance, let's get into the details and take a good look at how to implement Central Finance.

4 Implementing Central Finance

SAP Simple Finance is the first software release to include code designed specifically for use in Central Finance. In order to use Central Finance, you will need to install SAP Simple Finance 1503. The complete software stack includes the following:

» SAP Enhancement Package 7 for SAP ERP 6.0

» SAP NetWeaver 7.4

» SAP HANA

Recall from Section 3 that you don't necessarily need to start with a new system. It's also possible to repurpose an existing system and upgrade it

before departing on your journey. In this context, it's important to understand the difference between a migration of an existing system and a move to Central Finance. If you repurpose an existing system, such as a treasury system, you'll have to perform a migration for any journal entries already in that system in order to remove the totals records and indexes and merge related line items into a single universal journal entry. Then, you'll need to make an initial data load to bring the journal entries from your local systems into Central Finance. You don't need to transfer all the journal entries from the local system but can move company code by company code if you prefer. Going forward, you will then transfer new journal entries to Central Finance in real time. The essence of this initial load and the transfers going forward is that you can transform and

40


harmonize the reporting structures in Central Finance. A pure migration on your local systems will be a technical transformation of your existing journal entries into the structure of the universal journal but won't change any of your reporting dimensions.

As we discussed in Section 2, the heart of SAP Simple Finance is the universal journal, which collects all financial transactions. It's important to understand that for any individual document the universal journal is likely to be wider (captures more dimensions) and deeper (includes more posting lines) than the journal entry in the sender system. For this reason, the transfer structure for Central Finance does not capture the accounting document as posted in the local system, but instead collects the raw data for this document so that you have access to all the required lines. The arriving sales invoice might include lines for each material number invoiced, the arriving payroll record might have lines for each cost center to which employees are assigned, and so on- but these lines are typically aggregated in the journal entry in the local system, with the materials in the invoice only being included in the CO-P A document and the cost centers in the payroll document only included in the controlling document. For Central Finance, we are interested not only in the information that historically has been in the accounting document but also in the details that have been captured in the other documents.

On your central system, the code for the transfer is included in a new development package, FI N_C FIN_IN TEGRAT I ON . Figure 12 shows the header table C F I N_ACCHD that will act as the trigger for the replication of the new tables for the transfer. Notice that the associated tables listed on the left are not just for the document itself, but also for the profitability segments that will be needed for a posting to CO-PA, a cost component split if you are valuing your cost of goods sold with the standard costs from a cost estimate, withholding tax, clearing information, and so on.

These tables provide the transfer structure for the FI documents. If you want to transfer CO documents, you'll need to create an additional trigger for table COBK (the controlling document). For Order Accounting and Cost

41


Object Controlling, you'll also need to create a trigger for table AU FK (the order header).

"'--[lrMM:~

A~•o--.,......,., ...... s,_em c!J..,_ ti; T~C)I~

Q TWJ( Itfi*II.OIY

fi((JWJfTEW.TJOII' ~

~ - l&fl. ,rtl • • OJ £1 --... . 1111_(1111-"T'(WflQN

--~.-.c;tlfi«J • f".,.CfiHJiftGAAfi)NJI'T

.. . O<tlorlwvOtltotCIS •• oaa~MM nt111t1

. ""-"'="' " ""-"""' " ""-""' " ""-"""' " ""-""" •Uf'C,Jitm..,.W . cnvcat .. (X$ • UJ(Jt«fr,:Nr • <:m..Jt«<A_OtM . ""'-"= · <FJ'Uol,.~QJI • cnt_OOPA • (fflJ4:1SJ(IG • CfJULT_mlM · (F~t

• !!11Yilt8

lrrnt/ .. Ublfftt~IIK.~ ............. ~~,...."'~ r:::;'_Tllfllf .. t*t frN«l'll*fotA.CCIT T~~toM:Uf ACCIT.O::S TIWI'e~llelt (S)f\\'I:HICIII:I ... tD frWtl'tlDIIilofco-fA em--, ........ ~-A(p)f cntT,.,.....tltolt !or~QA(Qum;Ht)

T..W.TM!ofCO·PA~ I'ICO

lOOtiMOY.o<~ SUO. c..-.._ .. NJ.T«t~tWrllf lll....,...,.._~

Sr.tii'!OifooiiAfMiff'IWII I'I~Seultl·-

,...,.... .... ~~~~ p AaM

Short~ ACOCITo ........ ao~t

Attmlt:ft ~rMIIIIM't..anc:t ~ liCY~(htd ~JOAI'Itbftetl1

Ill •sSJ~ .A s.e~~Heb ntlil l:t'fh,., Dl(a~ l)f(IT,sN~ W91;fo 0.0,., $hot~

S!!!!! V "!!!!!!! J Ca.K

l"U.I~r:11rnt:

ru.ut ~D!S'!!.IIJ ·"'M!

"n•""'"Ull) IT.U

n• ~r:• !'U..n.l. CUJ

rtlcrttn.: .. ur x

>;::s "" ~ $11,.

~ CLII'l

""" -~ ""

v!IU.'! CO.»: ;.;$! ....

u.rs ~ TUG

,..,.., "" ~

·~~II"Wto~fNrwttcf~~

.: ~attUTC!_..,.~,!wlrt~tt"•Ml"P"M 0 , .. <:. ...... t-.~u-o.~~,<r<-·

:Q ,,. .. ..._, ~t---

:' (~'""""··~...., ..... :t ClJ)oo(JIS.,.-:""'

I CT~'•..fWJICOP•"Jttjjillt~

c con.on..o.tof(lli""''Of'...:JI9f~fi,I(O~

Figure 12 Transfer Structure for Accounting Documents

As we continue in this section, we'll be looking at the technical settings you'll need to establish the system connections. We will also examine the business logic with which you can convert journal entries; as we saw in Section 3, this is a key part of the value proposition for Central Finance. It is important to know how to assign these postings to the proper G/L account and account assignments (cost center, order, and so on) and to derive other reporting dimensions, such as profit centers, functional areas, and so on, via these account assignments.

Before we do that, let's get an overview of the various steps involved in implementation by looking at the IMG for Central Finance shown in Figure 13. You'll find this menu under FINANCIAL ACCOUNTING (NEW) • CENTRAL FINANCE. It covers the system settings to define your local systems as logical systems for the integration and to establish remote function call (RFC) connections in order to call back from Central Finance into the local systems. You' ll notice settings for the initial data load, because you'll want to bring historical data for the last several years into the central system as well as each new journal entry going forward. We 'll discuss the


mapping options given in this menu and also help you understand what else has to be in place in the form of organizational units and master data before you can start transferring journal entries from the local systems. Finally, BAdls give you a lot of opportunities to extend the SAP-delivered logic to ensure that the newly created journal entries meet the needs of your organization.

Display IMG

~ ~ Existing BC Sets <S(f BC Sets for Act it) <S(f ctJated BC Sets for Actfitv

Structure

if~~tiai·i:~~s~ General Settings

rsa Activat e Bus11ess Function rsa ~ Choose ECS Environment rsa ~ Set up RFC Destinat ion rsa ~ Define LogiCal System rsa ~ Assign logical System to Client rsa ~ Assign RFC Destination to' Logical System

Initial Load Settings rsa ~ Choose LogiCal System rsa ~ Define Oeamg and Substitution Accounts rsa ~lake Conf~guration Settirngs in Source System rsa ~ Extract Data for Initial load rsa ~ ~1onitor Data Extraction rsa ~ Post Int ial Load Data rsa ~ ~1onitor Posting

Mapping rsa Settings for Mapping rsa ~ Define Mapping Actions for Mapping Entities rsa Define MDG Mapping rsa ~ Define Mapping Entities (Enhanced Confgurat ion) rsa ~ Define Scenarios for Cost Object Mapping rsa ~ Define Mapping Rules for Cost Object Mapping Scenarios

BAdls: Cent ral Finance rsa ~ BAd!: Deternine Mapping Action rsa ~ BAd!: Enhance Standard !Processing of Posting Data rsa ~ BAd!: Preparation of Management Accounting Secondary Posting rsa ~ BAd!: Mapping of Cost Object Master Data

Figure 13 Implementation Guide for Central Finance

Let's start by looking at the settings for your system landscape both in Central Finance and in the local systems.

43


4.1 System Landscape

To establish your system connections, choose the GENERAL SETIINGS folder, shown in Figure 13. Although the settings are for a whole system, you can start with a couple of company codes to get a feeling for the potential of the new system without worrying about the complexity of your entire corporate landscape.

Central Finance

The first step is to activate the business function FI NS_CFIN (Central Finance). Note that this business function has license implications beginning in Q3 of 2015 and that you will need to ensure that your organization has licensed stock-keeping unit 7018254 SAP Simple Finance, Central Finance Foundation, which also includes the settings for SAP Master Data Governance that map the master data in the various systems. We'll return to this topic in Section 4.3.

While you're at it, activate two further business functions: F I N_GL_ERR_

CO RR and FIN_GL_ERR_CORR_SUSP for Error Correction and Suspense Accounting. These will ensure that any journal entries that arrive from the local systems carrying G/L accounts and account assignments that have not yet been created in the central system will be parked as work items in an error list. No extra licenses are required for this. SAP delivers a standard ECS environment for this context, called CFIN for Central Finance. We'll return to this error list in Section 4.3.

The definition of the system landscape proper begins with the entry of an RFC destination. We looked earlier at the navigation from the journal entry in Central Finance to the supporting documents in the local systems (Figure 2 and Figure 3). The link that you see in the Document Relationship Browser is enabled by an RFC to the sender system. You'll also need RFCs to select data from the local systems during the initial data load and to create the master data mappings from the local to the central systems.

44


Because these two functions will almost certainly be performed by different users (the initial load in the hands of a system administrator and the document links in those of a normal accountant or analyst), you may want to create different RFCs in order to differentiate the user types.

You'll also need to define each attached system as a logical system. The idea behind a logical system is to have a unique definition for each system/client combination across your system landscape so that when we look at the document header in Figure 1, for example, it's clear which system/client combination was the source of the sent document. Finally, assign the logical system to the Central Finance client and the RFC destination to your logical system.

local System

Ensure that the add-on DMIS 2011_ 1_700 or higher is installed on both the source and the target systems (Support Package [SP] 08 is recommended) and that you have implemented SAP Note 2124481 (SLT SP 08, Correction 3) on these systems.

Unless your organization is on a very modern support package, you will need to implement some code changes in your local systems to ensure that they can prepare the journal entries for transfer to Central Finance. You'll find this coding in the following SAP Notes:

» 2111634 (Enable Sender Systems for a Central Finance Scenario)

» 2108225 (One-Time Data for Process Event Beleg/Project)

» 2115885 (Interface Data for One-Time Customers is Incorrect)

» 2137557 (Central Finance Source System Enhancements)

» 2141237 (Enhance CO-P A Posting for Central Finance)

» 2122455 (Preparation for Transfer of Document to SAP Central Finance)

» 2147776 (Central Finance Source System Enhancements Needed for Document Change Transfer)

45


Note

The information in this section is evolving, so check the contents of SAP Note 2148893 (Central Finance: Implementation and Configuration) regularly to stay abreast of changes as further enhancements are added.

SAP Landscape Transformation

As we discussed in Section 3, the glue that holds the various systems

together in the Central Finance scenario is SAP Landscape Transformation, which is essentially a server that collects postings from the local system and routes them to the central system. The license for the SLT replication server is included in the Central Finance license, and we discussed the business content needed to establish the various database triggers earlier, provided that the attached systems are SAP systems.

Setting up the SLT replication server is beyond the scope of this E-Bite, but you can find general details at https://help.sap.com/saplt20. Also refer to SAP Note 2154420 (SAP LT Replication Server for Central Finance) for information specific to the load to a Central Finance system.

SLT works at the table level and uses an initial load object and a replication object for each table to be transferred. You'll use triggers for table CFIN_ACCHD (the table shown in Figure 12) for the transfer of FI documents, table COBK to prepare the CO documents for transfer, and table AUFK to transfer the orders. However, you don't need to set up these links by hand, because they are delivered as SLT content with the latest version of SLT.

We could continue now with the mapping and the initial data load, but remembering our discussions about business transformation in Section 3, it makes sense to think about each of the organizational units and the master data that you'll put in place in Central Finance before you move on to the next steps. We'll start by looking at the organizational units.


4.2 Global Parameters

The global parameters (such as countries and company codes) shown in this section will look familiar, because you are probably using all of them in your existing implementations. In some cases, you will make a one-toone transfer of these parameters to Central Finance, and in other cases you'll need to make a transformation. Because these parameters are essentially stable, you'll create a value mapping following the steps in the IMG for SAP Master Data Governance. This approach also covers customizing settings, such as the dunning areas and payment terms to which a customer might be assigned.

Decide on Participating Countries

Let's start with the countries that you want to include in Central Finance. To maintain these, choose SAP NETWEAVER • GENERAL SETTINGS • SET COUNTRIES • DEFINE COUNTRIES. You will almost certainly be able to copy these settings from your local systems, unless of course you are bringing new countries online. Make sure that you are aware of any country-specific concerns for these countries so that you can be clear on what can be centralized and what is best considered local statutory reporting.

Decide on Participating Companies

It makes sense to decide how you will prepare data for consolidation (eliminating intercompany markups) and perform intercompany reconciliation (matching payables and receivables or open items between affiliated companies) in Central Finance. This setting is essential if you intend to implement the SAP Intercompany Reconciliation for SAP HANA app, as described in Section 3, but it's also worth thinking about which affiliated companies will be coming online in Central Finance and in what sequence. Ensure that you identify business transactions that cross company codes and understand the data flow for these transactions, because you will need to ensure that you have adequate master data in place to capture all intercompany transactions.

47


To define which affiliated companies will be participating as trading partners in your intercompany transactions, choose ENTERPRISE STRUCTURE • DEFINITION FINANCIAL ACCOUNTING • DEFINE COMPANY. Figure 14 shows the parameters for a sample trading partner. You 'll also need to link these trading partners with the company codes for the appropriate legal entities by choosing ENTERPRISE STRUCTURE • ASSIGNMENT • FINANCIAL ACCOUNTING • ASSIGN COMPANY CODE TO COMPANY.

Display View nrnternal trading partnersn: Details

Company

Company name

Name of company 2

r~FOl , t.: .J

Tools Inc. Europe

Figure 14 Definition of Company as Internal Trading Partner

Decide on Participating Company Codes

Moving onto company codes, you are not only transferring the sort of attributes needed by a reporting solution but also making settings that will influence the update of the entries in the universal journal. The following are the most important settings to think about in the context of Central Finance:

» The chart of accounts If you intend to move to a central chart of accounts as we recommended in Section 3, then you should enter that chart of accounts here. Also ask yourself whether you need a local chart of accounts for local reporting purposes or whether you will continue to perform this sort of reporting only in your local system (COUNTRY CHART/AccTs).

» The fiscal year variant The fiscal year variant determines the number of fiscal year periods and special periods you will be working with. Remember that if you are moving to a single controlling area you will also have to settle on one fiscal year variant for all entities that will be part of that controlling


area. If you have countries with different fiscal year structures, then you will need to create additional ledgers with the appropriate fiscal year variants for these countries.

To check the global parameters for your company code, choose FINANCIAL ACCOUNTING • FINANCIAL ACCOUNTING • GLOBAL SETTINGS • COMPANY CODE • ENTER GLOBAL PARAMET!ERS. Figure 15 shows sample settings for a company code. Notice the global chart of accounts (and the option to add a country chart of accounts) and the fiscal year variant K4.

Display View "Company Code Global Data": Details

~ Additional Data ~ ~ g

Company Code

Country key

r. "'= J:FOlJ~~Jools Inc. Europe

DE Currency

Account ing organization

Chart of Aerts I NI

Company CFOl

Credit control area 0001

Ext. co. code

Ccrfllany code IS productr:e

Waldorf

EUR Language Key

Count ry Chart/ Aerts

FM Area CFOl

Fiscal Year Variant K4

Global CoCde

VAT Registration No.

Figure 15 Global Parameters fo r the Company Code

DE

Within each company code, you can define ledgers. If you are already using the SAP General Ledger, you will be familiar with the concept of

ledgers as a way of separating postings that refer to different accounting principles, such as IFRS and a local GAAP. In this context, you'll notice

the absence of settings to activate the update of profit centers, segments, trading partners, functional areas, and so on in the ledger settings. These settings are obsolete in SAP Simple Finance because the universaljournal

includes all these fields by default.

As you define your ledgers, it's important to think about the currencies you will use in each ledger. The local currency for your company code

will more than likely be the one you are already using in the local system

49


for that company code, but you will certainly want to think about intro

ducing a global or group currency if you haven't already done so, and you

may want to make some changes to your non-local currencies if you oper

ate internationally and need a functional currency. To set up your ledgers,

choose FINANCIAL ACCOUNTING (NEW) • FINANCIAL ACCOUNTING GLOBAL

SETTINGS (NEW) • LEDGER • DEFINE SETTINGS FOR JOURNAL ENTRY LEDGER, as

shown in Figure 16. We have included a company code currency and a

group currency for controlling purposes.

0/spt.y W..w 'Compilny Code Sdtlngs for- L«<g~·: Debt/Is

.,_ ~ !Hl

DDioo Strurtllre v Clledoer for the un~ JoulmlEnttY

.., ~ (orq~any Code Stt\19 fOf tht ltd5Jer · D Accountno Pm(f)IM for Ledow and Cof'l'cloany Co6e ~Code crot Gon'o¥ly Harne

~COde s~pfOt the Ledoer

Type ~Y «<de a..rency v Qltrency taR EUIO

Exd'lanoe late TWit StJndard trJn.*ltion at avtQOt ~-"' T11nslltx:tn O~te Type Toos!Won date ..,

Source Omency

Type Gloup a men<v .., Qltrency ttlR Euto

Excf'lanoe late TvPt Stlndard troln.slaltion at ~oe ~-... T11nslllb0n Date Type Toos!Won date v

Source Q.lrre.'lcy

tst AddtiOna! OJrren<v ,,, .. &d'lar.oe bte TWit

Source O.~~re.'lcy

FISQI YUt 'hrlant Cll Year. 4 S9.ml P~s

Po$tng ~II!Xt Va~nt V~'L v

v Qltrency

v T~nsbtx:tn Date Type

Figure 16 Currency Settings for the Company Code and Ledger

Notice also the assignment to the accounting principle on the left of the

screen. If your local systems are running the SAP General Ledger, then

you can transfer documents from a local ledger to a central ledger. If your local systems are running the classic or "old" General Ledger, then these

documents won't contain a ledger, and the default is to update ledger OL

(the leading ledger) in Central Finance. If you do report according to dif

ferent accounting principles in the local system, then you will usually

have a group of special accounts for the postings that are specific to each

accounting principle (typical examples include asset depreciation and

50


reserves for pensions). You can, of course, keep the same logic in Central

Finance and have all accounts update the leading ledger. Alternatively, you can move to the ledger approach in the central system, by identifying

the special accounts and implementing a method within the BAdl BADI_ FINS_CFIN_AC_INTERFACE to determine the posting logic. Before implementing such a BAd!, be sure that the accounting documents transferred

are ledger-specific and do not contain postings to several accounting principles.

While you are thinking about ledgers, it's worth asking yourself whether

you have a use case for an extension ledger to make adjustment postings over and above the legal differences in the two accounting principles in Central Finance. To do this, create an additional ledger that references the base ledger (such as OLin Figure 16) and flag it as an extension ledger.

Define Your Controlling Area

We have deliberately written "controlling area" in the singular, since life

will be easier if you can merge all your data into one controlling area in Central Finance. Just as we saw for the company code, the critical settings are as follows:

» Currency (notice that the currency type for the group currency is now part of the settings)

» Chart of accounts (again containing the accounts and cost elements)

» Fiscal year variant

It's also important to choose (ROSS-COMPANY-CODE COST ACCOUNTING, because your controlling area will cover several company codes (see ASSIGNMENT OF COMPANY CODE(S)). Remember also that the controlling

area is part of the key for your cost centers, so think carefully about the structure of the standard cost center hierarchy in this screen. To define

your controlling area, choose ENTERPRISE STRUCTURE • CONTROLLING •

DEFINITION • CONTROLLING AREA. Figure 17 shows sample settings for a controlling area.

51


Disp/11y View "&lsic d11fll ": Detlli/s

~ ~[}~

COntJolnO Area v ~SaSiedata

• ClAct~te corrponents/control indicators • ~Assignment of corrc>anv code(s)

Contro.-.g Area

r~ame

Person Responsble

Assignment Control

COCd->CO Area Cross-coi'Jl)any-.code cost accountno

CUrrency Setting

30 Group curreney CUrrency Type

CUrrencv CUrr/Val Prof.

[ OR European Euro .J Dtf CCode CUrrencv

Figure 17 Controlling Area Settings

Other Settnos

Olart of Accts

Fiscal Year Valiant

CCtr Std. Hierarchy

ZOIE

Illt

K 4

Hl

ZOTEST_C+V_PROFILE Af9'..,e

Sai'Jl)le chart o·f accounts

COt Year, 4 Special Periods

HI

In addition to these basic financial settings. the controlling area will also determine which entities you can report on in Central Finance; it is here that you specify which account assignments will be active in your journal entries (cost center, order, and so on). Here, we've activated the components COST CENTERS, ORDER MANAGEMENT, ACTIVITY BASED COSTING, and

PROFITABILITY ANALYSIS. Notice that we've activated both costing-based and account-based ProfitabiEity Analysis so that the revenues and costs

will be assigned to characteristics in CO-PA (we'll return to this topic shortly). You can reach Figure 18 by choosing ACTIVATE COMPONENTS/ CONTROL INDICATORS, shown in Figure 17. You'll need these settings for the universal journal, because all expense postings to cost centers, orders, projects, business processes, and CO-PA characteristics (the accounting documents) and all allocations and settlements (the controlling documents) will be made with reference to a controlling area.

Notice that we didn't activat e PROFIT CENTER AccoUNTING as a separate

account assignment, because we want to handle Profit Center Accounting within the universal journaL We didn't activate COMMITMENT MANAGE

MENT, because we will have only the journal entries in Central Finance, not the purchase orders, and so would initiate a commitment in logistics.

52

~


Change View "Activate components/ control indicators": Details

~ New Entries lb fo tO:) &) ~ ~

Controllilg Area v D sasic data

• e Act1vate components/control ndicatc · D ASsignment of company code(s)

Controlng Area

i'"EGI Year

Activate Components

CfOl Wafdorf

2014 t o 9999

Cost Centers t-:I Co::::mp= onc.:e:.:.:nt c:ca<W:::·:..:e ____________ ~v~ <./ AA: Activity TY!le

Order Management Component a<We

eonmt.. Management Component not a<We

Proflt:Analysis Component active for both (Yiles of Profitabity Analysis

Acty.f!ased Costilg Component Active for Par.~ llel and Integ r.1ted calculatiln

Profit Center Acctg

<./ Projects

<./ Sales Orders

Cost Objects

<.1 Real Estate Mgmt

Other Indicators

V A Cumancii?S

Vaflances

<.1 CoCd Va datoon

W. Commit. Mgt

Figure 18 Account Ass ignments (Components) Active in the Control ling Area

Define Your Operating Concern

If you are going to use the universal journal to its full potential, you will want to activate account-based Profitability Analysis (see Figure 18). For primary costs and revenues, this will ensure that every revenue posting, sales deduction, and cost of goods sold posting included in the accounting documents can automatically be posted to a combination of CO-P A characteristics, such as product, customer and region, and so on. For secondary costs, this will ensure that overhead can be allocated or settled via the controlling documents to these CO-PA characteristics to give a complete picture of your organization's profitability.

The settings for account-based CO-PA are largely linked with the controlling area, which may come as something of a surprise if you've mainly worked with costing-based CO-P A in the past. In this context, your operating concern does no more than define the number of characteristics that

53


you can use in your analysis. To define your operating concern, choose CONTROLLING • PROFITABILITY ANALYSIS • STRUCTURES DEFINE OPERATING CONCERN • MAINTAIN OPERATING CONCERN. Figure 19 shows the settings for our operating concern. Bear in mind that there is an additional setting to activate Profitability Analysis for the controlling area, and make sure that you also choose CONTROLLING • PROFITABILITY ANALYSIS • FLOWS OF ACTUAL VALUES • ACTIVATE PROFITABILITY ANALYSIS and set the flag for the controlling area.

In this example, we've activated CoSTING-BASED CO-PA as well. This will result in the system updating value fields for revenues, sales deductions, and so on in accordance with the settings in the operating concern. We'll look at this process in more detail in Section 4.5.

Maintain Operating Concern

1J '* D Actions D oata structure li:iJ

Operating Concern Icro1EOI Cent ral Rnance

Status CXD

Descr~tion

Type of Profltabfiity Analysis

v Cost1ng-based

v Account-based

Data structure

Environment

Central Finance

I¢ Display Status

Figure 19 Settings for Operating Concern

As we mentioned in Section 3, the more interesting discussion concerns the characteristics to be included in this operating concern, because plenty of organizations have built operating concerns that are specific to

54


individual countries or lines of business and now struggle to consolidate the different reporting entities. Of course, the SAP standard fields, such as MATERIAL GROUP, CUSTOMER GROUP, and PRODUCT HIERARCHY, are likely

to be the same in all your systems, but where there has been a degree of freedom in the subsidiaries it will more than likely have been used to the full and you'll probably find all manner of disparate characteristics. Don't get drawn too far into discussions about unlimited dimensionality in SAP HANA, because there are still some interfaces that are restricted to fifty characteristics in CO-PA (see SAP Note 1029391). Remember however

that you can use SAP HANA live views to bring in additional master data attributes during reporting.

To enter the characteristics, choose CONTROLLING • PROFITABILITY ANALYSIS • STRUCTURES DEFINE OPERATING CONCERN • MAINTAIN CHARACTERIS

TICS . Figure 20 shows the characteristics in a test operating concern. These are substantially fewer than you would find in a full implementation and missing the WW fields that distinguish customer-specific

characteristics. If you refer back to Figure 12, you'll notice a transfer structure CF I N_ACCPA_CHAR , which will capture the local characteristics. There are essentially three ways to handle the assignment of CO-PA characteristics:

» The characteristic values are identical in the local system and in the central system (this might be the case for organizational units, such as sales organizations and plants).

» The characteristic values in the local system are mapped to characteristic values in the central system (this might be the case if you are harmo

nizing your product codes in the central system).

» The characteristic values do not exist in the local system and should

be derived afresh in the central system (this might be the case if you want to work with completely new product hierarchies in the central system).

In the context of CO-P A, you will find different document n1llmbers but

also different entries for PAOBJNR (number of the profitability segment)

55


in the sender system and in the receiving system, because a new document is being created with a potentially different set of characteristics.

D~pmy~auderiRi~:o~wrew

~ ~ ro 6C ~ ~ w ~ ~J. a~ rn Char. Desc~tion Short text

~DRNR , f ddress Address

BRSCH IndustJy Industry

BZIRK Sales diStrlct DiStrict

KDGRP CUstomer group Cust.group

Figure 20 Characteristics within Operating Concern

DT... Lgth. Origin Table Origin field d

CHAR lOI<NAl ADRI<R

CHAR 4l<NA1 BRSCB

CHAA 61<NVV BZIRK

CHAR 21<NVV KDGRP

As you prepare your list of characteristics, make sure that you understand how you will derive these characteristics; this will give you a picture of what master data needs to be in place in Central Finance. If you are capturing the product and want to derive a material group (MA TKL) and a product hierarchy (PROD H), you are going to have to make sure that you maintain not only a material master for each of your products but also the relevant material groups and product hierarchies in Central Finance. The same applies also to characteristics that can be derived from the customer, such as the customer group (KDGRP) and the sales district (BZIRK), as shown in Figure 20. We'll come back to this as we look at the relevant master data.

Map Organizational Units

The global parameters for the countries, companies, company codes, and so on are usually handled using value mapping. This approach is also used for customizing settings that are usually set up at the start of a project and then remain stable, such as the dunning areas and payment terms for a customer. If you refer back to Figure 13, you'll see a menu point MAPPING • DEFINE MDG MA!PPING. The instructions in this step will take you to the step GENERAL SETTINGS • VALUE MAPPING • MAINTAIN VALUE MAPPING. If you are using standard SAP fields, you won't need to touch


this list, but you will need to add entities if you are including your own fields or fields from an external system.

With these settings completed, the main organizational structures are in place for Central Finance. We'll now look at how to maintain the master data that will populate the financial documents.

4.3 Master Data

As you think about Central Finance, you need to distinguish between long-living master data (such as accounts and profit centers , for which you will typically have a strong master governance process in place) and more dynamic master data (such as orders and projects that tend to get created in the field as needed). We'll look at how to handle orders and projects in Section 4.4. For master data such as customers, materials, vendors, and G/L accounts for which new master data is being added on a regular basis, you'll perform a key mapping.

As we discussed in Section 3, the case for implementing Central Finance can be driven by the case for cleaning up master data. If you have implemented SAP Master Data Governance, you will already have been through such an exercise and can reap the benefits, because Central Finance can read these mappings. SAP Central Finance reuses some of the mapping tables in SAP Master Data Governance, so even if you don't use SAP Master Data Governance today, you will be potentially paving the way for a later implementation. You can use the master data mapping tables without licensing SAP Master Data Governance separately.

Alternatively, you can look to your data warehouse as a guide to preparing your master data, because your organization may have harmonized your master data by defining transformations as you transfer data to the data warehouse. The entities listed next are the main focus of reporting. Don't forget that you can also map business areas, functional areas, and any other reporting dimension that you want to include in your journal entry. Essentially, the contents of every field in the journal ent ry that you

57


are sending will have to be available as master data in the central system, so you'll also need master data for tax procedures, payment conditions, and so on.

Define G/L Accounts

Before you maintain a single general ledger (GIL) account, it's worth taking a moment to think about the posting logic in Central Finance.

In your local systems, you use MM account determination to determine which accounts are updated as you post goods movements, SD account determination to determine which accounts are updated as you post invoices, and so on. Each of these business transactions will trigger a journal entry in the local G/L under the selected accounts.

What happens as this journal entry is transferred to Central Finance is that a new journal entry is prepared, either using the accounts from the original journal entry or using new accounts that you'll dlefine in your mapping rules in Central Finance. You will only be able to post if the accounts in your journal entry exist in Central Finance. If not, the journal entries will be parked in an error list.

If you're preparing for a proof of concept, draw up a list of the key business processes that you want to investigate and identify the accounts updated in these processes. To prepare a full list, use the trial balance from the local system, which is simply an unstructured list of all the accounts that have been postted in your GIL. You'll also need a list of the cost elements you currently use.

Primary Cost Elements as AccoiUnts

SAP Simple Finance brings Financial Accounting (structured by G/L

accounts) together with Controlling (structured by cost elements) by merging the account and cost element entities.


Figure 21 shows a sample profit and loss account. You 'll notice that

instead of only being able to choose between the account types BALANCE SHEET ACCOUNTS and PROFIT AND LOSS ACCOUNTS as in previous releases of

the software, there are now settings for PRIMARY CosTS AND REVENUES and SECONDARY Cosrs as special types of profit and loss accounts.

r~~ Display G/ L Account Centrally

~ ~ 'W I:) Edit financial statement version Edit set

G/ L Account I4oooool I O!Jeonsumpt ion, raw material 1

Company Code CFOl Tools Inc. Europe oSlf ,? D D Wit!l Template f8J w 1 • I • Control Data I Createjbank/int erest I Key word/ translat ion I 1...m

Control in Chart of Accounts

Account Type Primary Costs or Revenue

Account Group r~aterials management accounts

Detaned Control for P&l Statement Accounts

Functional Area

DescriPt ion in maintenance language (DE)

Short Text Verbr. Rohst:offe 1,0

G/L Acct Long Text Verbrauch Rohstoffe 1,0

Consotidation data in chart of accounts

Tradilg partner l

Figure 21 SAP General Ledger Account Showing New Account Types

Let's start with the balance sheet accounts. These are used to store assets, inventories, liabilities, and owner's or stockholders' equity. In a normal balance sheet, additional subledgers provide full details of the assets, the inventories, the accounts payable, and the accounts receivable, together

with the cash applications. In Central Finance, there is less detail in Asset

Accounting, because the item detail is only in the local systems and we only transfer the reconciliation accounts to the central system. As we

59


discussed earlier, the open items for Accounts Payable and Accounts Receivable are transferred but technically cleared, so you can't run payment processes centrally as of the time of writing. If you have SAP Cash Management running centrally, then you can potentially have both on the central system. In addition to the balance sheet entries that are triggered either locally or by the cash applications, you will also find adjustment journal entries that are made by accountants in Central Finance.

The profit and loss accounts cover revenues, cost of goods sold, and operating expenses. A few of these are treated solely as accounts. These might be for losses and gains on financial exchange markets or other items that are outside of operational accounting. Most profit and loss accounts, however, have a link with Controlling, so salary expenses will be linked with cost centers, material expenses with orders and projects, and so on. In the past, a sister primary cost element was created for each of these profit and loss accounts, but now the two master data records are merged into one. This means that there is a separate record not for the cost element but only for the account, as shown in Figure 21.

If you are new to account-based Profitability Analysis, bear in mind that you will also need to define primary cost accounts for all your revenue postings, sales deductions, and cost of goods sold in Central Finance. It can be worth revisiting your account determination settings in Sales and Distribution (SD) to be sure that you know which accounts you will be collecting and to make sure that you are aware of any statistical sales conditions. These won 't automatically be reflected in Central Finance, but they are included in the transfer structure; if they are important, consider implementing a BAdl to change the posting logic.

To ensure that the account assignments in Controlling are activated properly, you also need to activate the cost element settings on the CONTROL DATA tab as shown in Figure 22.

60


--eyl~ Display G/ L Account Centrally

Edit financial statement version Edit set

G/ L Account

Company Code

I4oooo~ I~ consumption, raw material l

cro1 Tools Inc. Europe * ,? D D With Template

l Type/Description • ' t . . Create/bank/int erest l Key word/translat ion l I...lfi

Account control in company code

Account currencv

Only balances 1n loca l crey

Tax category

Post1no 1 thout tax allo 1ed

Alternative Account No.

EUR 8uropean Euro

Only linput tax allowed

Account Management in Company Code

Open Item Management

Sort key

Accounting clerk

008 Cost center

Account Settings in Controlling Area CFOl Waldorf

CEiem ategory Record Quaotlty

Int . meas. unit

Prmarv costs/cost·reducing revenues

Figure 22 Account Contro l Data Showing t he Link to t he Cost Element Category

) ~

The following are the main cost element categories for which you need accounts in Central Finance:

» 01: Primary Costs/ Cost-Reducing Revenues Check your trial balance and the settings for your contro!Eing area to identify all accounts/cost elements for wages and salaries, asset depreciation, material movements , and so on.

» 11: Revenues Again, go back to the trial balance to identify all accounts/cost elements for revenues both with external customers and internal trading partners.

61

Implementing Cent ral Finance I 4

» 12: Sales Deductions Here, it makes sense to compare your trial balance with the sales con

ditions that will be used to invoice your customers .

» 22: External Settlement You'll want to understand here where you have capital expenses that

are being settled to assets under construction, or production orders and so on that are being settled to finished goods inventory.

If you are using product costing, the goods delivery posting in your local system will be made to a single cost of goods sold account instead of being broken out into its cost components (raw materials, internal activities, overhead, and so on) as it is in costing-based CO-PA. However, in

SAP Simple Finance you can split this posting according to the cost components in the standard cost estimate of the material sold. What will happen is that the standard cost estimate itself stays in the local system, where the bills of material and routings used to calculate the standard costs are maintained, but the transfer structure (see Figure 12) includes table C F I N_ACC IT _CCS, in which the cost component split (CCS) for the

standard cost estimate in the local system will be stored for transfer.

To receive this split in Central Finance, create the relevant subaccounts for raw materials, internal activities, overhead, and so on, and then define

how these accounts will be updated by choosing FINANCIAL AccoUNTING (NEW) • GENERAL LEDGER ACCOUNTING (NEW) • PERIODIC PROCESSING •

INTEGRATION • MATERIALS MANAGEMENT • DEFINE ACCOUNTS FOR SPLITTING THE COST OF GOODS SoLO in the IMG. This will result in multiple COGS lines being created as each cost of goods sold posting is transferred.

Secondary Cost Elements as Accounts

Because the whole idea of creating G/L accounts for secondary cost elements will go against the grain for experienced SAP users, it's worth

walking through the various types of cost elements that you will need in Central Finance.

62


Start by making a list of the cost elements you currently use (you'll find these using Transaction KA23 - Cost Elements: Master Data Report), understanding the process by which each cost element is updated, and then deciding whether you want to keep the same cost element granular· ity for the process in Central Finance or need to map differently.

Postings for the following cost element categories currently can be transferred to Central Finance:

» 21: Internal Settlement Review the settlement structures in your local system to determine which cost elements are used to send costs from orders and projects to other receivers in Controlling.

» 41: Overhead Rates Review the costing sheets in your local system to determine which cost elements are used to send costs from cost centers to orders and to projects in Controlling.

» 42: Assessment Review the assessment cycles in your local system to determine which cost elements are used to send costs from cost centers to other cost centers in Controlling.

» 43: Internal Activity Allocation You'll need to prepare a list of activity types and business processes used in your local system to determine which cost elements are used to send costs from cost centers to orders and to projects in Controlling.

Define Profit Centers and Segments

Before you can perform any sort of Profit Center Accounting, you'll need to make sure that the appropriate profit centers and segments exist in Central Finance. Remember as you do this that you don't necessarily need to be running Profit Center Accounting in the local system. If you are running classic Profit Center Accounting in a separate ledger in the local system, be aware that manual documents created using Transactions 1KEL und 9KEO aren't currently transferred to Central Finance.


Remember that because profit center assignments are derived from cost centers, internal orders, projects, and so on, you can transfer journal entries that only contain these account assignments and derive new profit centers on the fly using the entries in the sending account assignments.

Define Cost Centers

The cost center is the one piece of master data that you will almost certainly transfer to Central Finance alongside the account. In some organizations, the cost center is used strictly as a resource to represent a machine, a building, or people working in a department. In other organizations, the cost center is used more flexibly to represent what many practitioners would consider profit centers, and statistical revenues are posted to the cost centers alongside costs.

One challenge as you move to a single controlling area can be to identify which cost centers belong to which company code for ease of reporting, allocation, and so on, so consider putting an appropriate numbering system into place. It's also important to understand whether the same cost center key can exist in multiple systems to avoid conflicts as different local systems come online. Because the attributes in the cost center masters will also determine the assignment of your cost centers to functional areas, profit centers, and business areas, think carefully about these assignments; they provide the basis for your management reporting.

Caution

Be careful as you maintain the cost center attributes; it 's the profit center or functional area derived from t he cost center that will win over any mapping of profit center A to profit center B or functional area A to functional area B in the mapping tables.

Define Material Masters

The idea of centralizing and harmonizing material masters can be a daunting one. However, remember that you're only interested i.n a subset of


that master data in Central Finance. All the settings that control MRP, production, procurement, warehouse management, and so on in the local systems can stay exactly where they are. The main items to consider are the following:

» Naming/ numbering conventions This won't be a problem as you bring your first local system online, but failure to act early can cause problems later, unless you've already tidied your material masters. Remember that you are potentially preparing the way for consistent inventory reporting and a central material ledger, even if you don't bring all this detail into Central Finance in the first wave.

» Assignment to product hierarchies Because the product hierarchies are one of the main ways of looking at how families of similar products aggregate in CO-P A, it's worth devoting some time to this topic. However, deciding whether you are going to deliberately leave "untidy" product hierarchies in the local system because they are being used in sales conditions and so on and move to a different structure in Central Finance, or whether you are going to harmonize your product hierarchies, is not something that can be determined by the finance department alone.

» Assignment to material groups The concerns for product hierarchies apply similarly to material groups. You should also understand whether you have other material attributes that you need for central reporting in your material masters, such as spend categories.

Define Vendors and Customers

The master data for vendors and customers can be fairly minimalistic, because you won't initially need any of the settings that govern operational processes, such as payments or exports.

As far as customers are concerned, you are mainly interested in attributes such as customer group that you will need for management reporting in


Profitability Analysis and those such as trading partner that govern intercompany trading if you plan to perform intercompany reconciliation centrally, as we discussed in Section 3.

For vendors, focus also on the settings needed for intercompany reconciliation. As you draw up the sequence of entities to come online, be careful

to identify intercompany vendors and customers in cases in which one party is not going to be moving to Central Finance.

l<ey Mapping for Master Data

Now that we've created the key master data for Central Finance, it's time

to think about whether there is a one-to-one relationship between the sender and receiver system and where a shift will take place. Figure 23 shows the list of entities that can be mapped. To view this list, choose CENTRAL FINANCE • MAPPING • DEFINE MAPPING ACTIONS FOR MAPPING ENTITIES in the IMG.

Dlsphly V/.ow "Hilpp/ng Enttty•: O~rv/.ow

£HH~

Otabo SWcture .., C M~pl)hg Ent:ty

· • Stt NJ:'IOhO Mtbn of M~OPi'IO Ef'ltlY

Na119no Erttv M~PPhO EntrY ~l:fG_FRl!lt:ll'l.t Atl tvl:Y _ rrn: _1 o

.,. tt:I(J. Enttv Oeser. .jAccou~ Ptna~le

-TypeiD(ERP)

uncz Jd.f,ntller fOf ~order

!ILUI Oo<ument type

!SaiL PO$U'IQKt')'

!m<R! COiroa'V c..lt CCMPA.'tY_I D Cofro.lnv J)

COST_ctm'Rt_ ID Colt Cent9r 10 {SU')

COST_tltMtlfT_ID Cost ~nt 10 (ERI')

COST<H:R_lD ERSI O..stomtf tlui'Ttl• (ERP)

DUSQI. P~nt mttl'lod E~_ID ER9 Pureh~ FUI'Idi)tlai i.Ml (ERP)

tRP _l.OOISliC_.AUA_ID ER9 LOQimes Area D (ERP) ro\~.1. _ t.DGR.P Ledger Gtouo nNS_crL'f_IAX_ JQ.l.Slo! CFII: TaX procedure

n<UR Fui'ICtbnil Atea

81JShessArea

Oedc control ilrn

Con~Aru

OUMnOAIU

MaterQI 10 {ntemitl fOfl'TIIJt) (ERP)

Counto><:od<

lQ ........... l Entry 1 of 51

Figure 23 Mapping Entities in Central Finance

66


If you do nothing, the system will assume that there is a one-to-one rela

tionship between the entities in the sender and in the receiver systems (the KEEP DATA option) and will post providing the appropriate master

data exists in the central system. Bear in mind as you think about master data, that you'll also need to make sure that the appropriate document types, posting keys, and so on exist in the central system, since these are

all part of a standard journal en try. If you want to override this for one of the entries in the list, you need to select that entry and define a mapping action. You have the following mapping options under SET MAPPING ACTION OF MAPPING ENTITY:

)} KEEP DATA

This is the default. Field values of this kind are not mapped at all, and the entities transferred from the sending system are retained.

)} MAPPING OBLIGATORY The field values for all filled fields must be mapped. If no mapping data exists for the data in the FI documents, an error is raised that can be cor

rected via an error-correction system (ECS). Note that the ECS does not

yet handle CO documents.

)} MAP IF POSSIBLE The system tries to map any filled field. If no mapping data exists , then no error is raised and the original data is used as transferred from the

sending system.

)} CLEAR DATA

Just occasionally, the sender system will transfer a field for which you have no use in the Central Finance system. If you have fields that you don't want to transfer, then you'll need to use this setting to ensure that

these fields are cleared or removed from the document.

The most common mapping is a pair mapping, in which account A in the

local system maps to account B in Central Finance. To prepare this pair mapping, use the Web Dynpro application MDG_BS_WD_ID_MATCH_ SERVICE.


Figure 24 shows the key mapping for the plant keys in the local and the central system. A key mapping is used for all those entities that are added on a regular basis, such as vendors, customers, materials, and GIL accounts. If you need a more complicated logic than the pair mapping defined here, consider using the BAdi BADI_FINS_CFIN_MAPPING_ RULE, shown in the IMG in Figure 13. Also remember that any new doc

uments you create will pass through the accounting interface , so you have all the usual options to perform substitutions and derivations and imple

ment user exits as you create your documents.

Key Mapping Plant : P001 .---

Save

Object Selection

* Business Object Type: Plant

* Bustness System: 0 91_820

* Object ID Type/Object ID: Plant ID (ERP)

I Show I Mapped Objects

l Add Row I Cl'lange Row I Delete Row L..n o C d .;lo

OJ v II P0011

t:J ' No. •system ID

091_820

070_002

·s usiness Object Type Object ID Type

Plant

Plant

Figure 24 Key M apping for Object Plant

Error Correction and Suspense Accounting

Plani iD (ERP)

Plant ID (ERP)

' Objeci iD

P001

P001

As you think about mapping your master data, consider what will happen if things should go wrong. The errors might apply to all documents arriving, such as when a period has yet to be opened in Central Finance or to specific master data, such as a locked cost center or an incorrect mapping. If you have activated the business function for Error Correction and

Suspense Accounting, you 'll find the submenu under AccouNTING • FINANCIAL ACCOUNTING • GENERAL LEDGER • DOCUMENT ENTRY • ERROR

68

Implementing Central Finance 4

CORRECTION AND SUSPENSE ACCOUNTING. Figure 25 shows a list of documents that could not be posted and have been captured as errors in the worklist. You can correct errors in the short term by selecting an item as shown in Figure 26 and making a manual correction to the master data or correcting the mapping rule and refreshing.

Em:H' CtNr«:tkM •nd ~ A«<Untln(l: HMwl C«r«tfon

~ .. ... '\1 • 6l ,i1 14J II <GI ~ l>SQt\-~ e., ll ~Sr~- ~ - ~.- OO..Oilt - ~<tl)'o.A«t AniWil O'ro6ln'OOII'«llt.QJ C)'IJ.CXtl ot~JJ~,QI' OK.Ni>. ~ l'ftd(O(Ot 1'0Jt901tt I'Oittcl~-- - RICllt (Untl'q Qot,l'ltJ\

Q1Q(UITotl 1001 1001~ 16.01.2015 - ... .., ....... """' ~IS 0011 -- - ... 16.07.1015 ,.,, .. .., -""" ,.., lOU 0011 -·- - "" IU1,201S .... 2015 ootl ... ,_ ... 16M.l0l$

~100061 .. , tS.01.lOtS ...... ....,,_ ...... -- - UAJ'.lOIS ....... - IS.«J'.lOlS ....... '""· -·- - IS.o1.101S

'""'· -- .... 15.«7.20-JS , .... 191100

,_ lOISOOtl -- .... ... ,_. 2.160.1(1 20tSOOtt -- - ...

l.160AG .... """ l.I60,M lOU OOtl -- - "" I)M.lOU ·- 2.16UO 20tSoott ........ ... tSA.7.lOlS

l .OGO,OO --191100 l .(lti)AO lOIS ootl -- - "" ISM.lOJ.S ,_ ..... 20150011 -- - "" I)A)',lOl) ..... )01$ OOtl --.. .., -- ISN.J!GJS ..... -- IS.W.lOlS ....... --19'1100 ....... ....,,_ ...... ..... --..... -- -""" ..... 201) 0011 -- - "" I)MI.lOl) ·- ..... lOtSOOtt ........ ... tW.lOlS ...... --...... --Figure 25 Error Correction and Suspense Accounting: Manual Correction List

Figure 26 shows an error that we've selected from the list. It is not possible to post the document, because the material ZZZ1-HP002 has not been created in the central system. As you can see, you can manually correct the customer number to a customer that does exist in the central system and save. In the long term, of course, you'll want to either create the customer in the central system or change your mapping so that material ZZZ1-HP002 is no longer addressed.

Note that as of the time of writing Error Correction and Suspense Accounting only covers errors in the FI document. If errors occur in the CO document- for example, because an activity type does not exist in the central system- then you will get an error in SLT.

=-::~ ., .... ... . ..

.... 191101 ... .... ... .._ '" .... "' ....

191100 '" ,._ "' ,.,.. '" """ '" .._ ...

1911ot "' '"'" "' .... """ "' 0001

.. _ '"

.... """ "' .... .. _ "'

ECS Item: ~tall VIew

&) t) .C ~ ~Post and Next Item ~Text ~Addition•l nputfiells

COnwund ErrOl Cit. co.COde of Pitd Doc. 0001

Sevetty Hatd Error Posted Ftsc.al Yeat 2015

Status New Posted Doc. No.

ECS Item Oeited On 16.07.2015 COCode of Corr.Ooc.

Qeated Bv OHIS_RFC Corr. Doc. FY

ECS CNnoed on t»te 16.07.2015 corr. ooc. No. Chanoed 8y OMIS_ItfC

@ l A 'I' (X) 'iif . l liL • l o5i><f)J . ~ . -§ . 1 1Ji i [IJ


Po5tilo one Posted Account

Posted COSt center

Posted Proft Ctnter

ECS Document trull'tltr 100000445

ecs Elltered tl Year 2015

Run 10

Posted 'hkles Coed Postno Date va.e Date • G/t Account COSt Ctnte:r Proft Ctnter Tr.prt Ct<t Amount Ordet customer ~OftlhJI Vak.l ts ~ 0001 16.07.2015 16.07.2015 7 281100 EUR 0,17 Posted \hUes

Correct Val.Jes 0001 16.07.2015 16.07.2015 7 281100 EUR 0,17

60' . I .1. Y 00 ~ .' I" -. ._ o5i> <f)J . 141 . II!I I[Giil o·l:e: I!I.C. o Dol T ... MeSS3ge Text lTxt :e: The motmiZZZI-HPOOl does not exilt or • not •"">ted O

Figure 26 ECS Item: Showing Correction Options

Perform the Initial Data Load

"Consistency" is the key word for the initial data load to Central Finance.

You want to make sure that any data you transfer from the local system is clean, and you don't want to have users adding new journal entries or scheduling jobs while you are making the load. With this in mind, you'll

want to lock the periods for transfer against postings to prevent accidental updates during the initial load.

To ensure that the data in your sender systems is clean, there are various reports that you should run prior to the initial data load to Central Finance:

» To prepare to transfer your asset postings, perform closing for periodic asset postings using program RAPE RB 2 0 0 0 and execute the periodic depreciation posting run using program RAPOST2000.

» Ensure that the index tables and transaction figures in the SAP General Ledger are consistent by running Report RFINDEX for all fiscal years in

70

0\T\' KFOO

KFOO


the local system, but restrict the selection to the company codes you want to transfer to Central Finance.

» Ensure that the figures in the SAP General Ledger match those in the subledgers by running Report TF(_COMPARE_ VZ or choosing Transaction FAGLF03.

» If you're running the SAP General Ledger in your local system, ensure that the figures in your various ledgers are consistent by running Report RGUCOMP4 or choosing Transaction GCAC for the company codes that you want to transfer to Central Finance.

» Ensure also that the values in SAP ERP Material Management are consistent with the figures in the SAP General Ledger by running Reports RMO?MBST and RMO?MMFI for the company codes that you want to transfer to Central Finance.

» Prepare your balance carry forwards for all currencies and all ledgers. For Accounts Payable and Accounts Receivable, run Report SAPF010; for SAP General Ledger accounting, run Report SAPFGLBCF.

» Prepare an extract of your financial statements (program RFB I LAO 0) .

the totals per cost center (Transaction S_ALR_87013611), the G/L account balances for the relevant company codes (Report RFSSLDOO), and the document journal (Report RFBEUOO).

You are now ready to make the settings shown in the INITIAL DATA LOAD folder of the IMG (see Figure 13). Start by entering the logical system from which you will select data for the initial load. Then, define clearing and substitution accounts for each company code that will be used to create offsetting entries during the data load. Once the data load is complete, the balance on these accounts should be zero.

You can now execute the steps iExTRACT DATA FOR INITIAL LoAD and MoNITOR EXTRACTION from the IMG. This will move data from the local system into a preliminary table in the Central Finance system.

71


When you are happy with the result of this step, execute the steps PosT INITIAL LOAD DATA and MONITOR POSTING in the IMG. This will create journal entries within Central Finance. Once you are finished, run Report RFINS_CFIN_MATCH_FI_TO_CO to check the consistency of the CO postings. Also, run the same check steps that you ran locally in Central Finance to make sure that everything has transferred correctly- that is, check your financial statements (program RFB I LAOO), the totals per cost center (Transaction S_ALR_87013611), the G/L account balances for the

relevant company codes (Report RFSSLDOO), and the document journal (Report RFBEUOO).

The preceding steps describe the initial load of the FI documents. Once they're complete, you'll need to load the CO documents. This step will check whether the CO documents are already available as part of the universal journal (in other words, all primary cost postings) and then transfer all other CO documents. There is also a separate load process for the CO objects.

4.4 Cost Objects

In addition to the long-living master data that we looked at in Section 4.3, you '11 also want to take account of more short-lived master data, particu

larly for projects and orders. Although projects and orders technically have master data, it can be cumbersome to create the master data prior to every posting, especially if you create new orders on an almost daily basis. For this reason, the system will dynamically create the relevant master data based on your configuration settings.

It's rare to have a full master data governance process in place for any but the most strategic capital investment projects. Occasionally, one will exist for product cost collectors if they are considered part of material master maintenance, but mostly production orders, maintenance orders, and

72


quality management orders are simply created locally as needed. With this in mind, instead of replicating orders to Central Finance prior to the first posting, create the order dynamically based on the scenarios for cost object mapping in the IMG (see Figure 13).

Order Management

Figure 27 provides an overview of the delivered scenarios for cost object mapping. In each case, local characteristics (the fields for th e relevant object in the local system) can be mapped to central characteristics (the fields for the new object in Central Finance) as the relevant object is created.

D/$p/Jiy W..w "HIIIntJIIn ~nllrios for Obj«t HllpplfJ{I": OVtmtlt!w

,. a a a Dealoo Structue "' !:1 Natttih SCeBariOs fot Object Mapphg

· c:lloal ~cttristic · ~Central Olaracterf>tlc

Nin~n Scei\¥0S f01 Object Mapphg

S<en.,.

~COl ..... , Sl.PtO'

S.UOOI

., Seen¥» Oescrotion Table tlame Loal Object erteoorv Centtal Ob;ect Qtegory Qrdnalt'( Ad).oe 0 } AP Ttl1'1)4att: ProductiOn ()fdeJ to P .. FINS_CflliiC'_SMP_ PToclu<:t1oo Orckr " Pf'<l®Ct Cost Coll _ v N : 1 " ../ "

SAP Tef'l"(tttte: Product cost ColectoLrl)fS_Cri)IC_SMJI- Pl'Oefuc~ Coat Coll .. v P~Ct; Con Coll ,. v l : 1 v ../

SAP Teii"CCItt: Inter~! Order to lnte_r nrs_CFINC_SMP .. Inu:n.t 0:-der v lnoternel Order ""1 : 1 v .J

SAPTelfl)tJte : MJttten~nceordefto_nJfS_Cflli:_SXi .. KI1nttD&Dct Ordu v XJtnttoatct Or<ttr v N : 1 v .t !ArtCUZ SAP Te111M:Jte: Maintenance Ordef to_Z.SAF004 ~.ai.ntenance Order v Ma.intenar.-ee Order v N : 1 v V

SAP005 Qua1tyManagemtntorder toQualty FINS_CflliC_SMP_ (lH Order vf.H Order vN: 1 v ../

Figure 27 Scenarios for Cost Object Mapping

SAP currently delivers the following standard scenarios for Order Management:

» SAP001: Production Order to Product Cost Collector Here, short-living production orders are mapped to more stable product cost collectors in Central Finance that live for as long as that production version is manufactured. Note in Figure 27 that the cardinality between multiple production orders and a single product cost collector is N:1.

» SAP002: Product Cost Collector to Product Cost Collector If you already have product cost collectors in your local system, then you can map them to a product cost collector in Central Finance. This will mean that as a product cost collector is created in the local system,

73


a new product cost collector will be dynamically created, maintaining the 1:1 relationship between the two product cost collectors.

» SAP003: Internal Order to Internal Order Here, longer-living internal orders are mapped in a 1:1 relationship between the local and central system.

» SAP004: Maintenance Order to Maintenance Order Again, maintenance orders are typically very short-lived and can therefore be mapped to a longer-lasting maintenance order in the central system.

» SAP005: Quality Management Order to Quality Management Order Again, quality management orders are typically very short-lived and are mapped to a longer-lasting quality management order in the central system.

You can add more entries to this list by copying the existing entries and adjusting the fields, so if you have a need to aggregate internal orders instead of replicating 1:1, you can copy SAP003 and change the cardinality settings.

Figure 28 shows the entries for the first scenario (Production Order to Product Cost Collector) in table F I NS_CF I NT _AS GMT. Notice the pairing between the objects in the local system- in this case, the production orders (PROD_ORD)-and th e objects in Central Finance-in this case, product cost collector (PCC). This table is especially useful during testing, as new order numbers will be created dynamically in the central system for the new objects.

74

Implementing Central Finance 4

FINS_ CFINT_ASGHT: Displlly of Entries Found

fll&

Table to be searched FINS_ CFINT _ ASGMT Assignment

Nurrber of hits 24

Runtine Maxirrum no. of hl:s soo

~ ~~ ro ~ 'iil . ll • .g. (!)) • ~ • <i'.!l . 11 1:l.!] ll!i I [!:[1 &loetals

13\ Scenario logical system lObJ. cat. Object ID Order Order Order Order Order Obj. C.t. Order Order Order Order SAP001 Q7QCUH002 PROD_ORD 000001007300 1007300 PCC 700020

SAP001 Q7QCI.NT002 PROD_ORD 00000100738-2 1007382 PCC 700121 SAP001 Q7QCI.NT002 PROD_ORD 000001007464 1007464 PCC 700121 SAP001 Q7QCI.NT002 PROD_ORD 000001007721 1007721 PCC 700121

SAPOOI Q7QCI.NT002 PROD_ORD 000001007862 1007862 PCC 700142

SAP001 Q7QCI.NT002 PROD_ORD 000001007882 1007882 PCC 700142 SAP001 Q7QCI.NT002 PROD_ORD 000001007884 1007884 PCC 700020

SAP001 Q7QCI.NT002 PROD_ORD 000001007885 1007885 PCC 700121


SAPOOI Q7QCI.NT002 PROD_ORD 000001007922 1007922 PCC 700024 SAP001 Q7QCI.NT002 PROD_ORD 000001007960 1007960 PCC 700020

SAPOOI Q7QCI.NT002 PROD_ORD 000001007962 1007962 PCC 700020 SAP001 Q7QCI.NT002 PROD_ORD 000001007963 1007963 PCC 700020 SAP001 Q7QCI.NT002 PROD_ORD 000001008080 1008080 PCC 700142

SAPOOI Q7QCI.NT002 PROD_ORD 000001008100 1008100 PCC 700142 SAP001 Q7QCI.NT002 PROD_ORD 000001008101 1008101 PCC 700142



SAPOOI Q7QCI.NT002 PROD_ORD 000001008142 1008142 PCC 700142


SAPOOl Q7QCI.NT002 PROD_ORD 000001008240 1008240 PCC 700121 SAP001 Q7QCI.NT002 PROD_ORD 000001008241 1008241 PCC 700020

Figure 28 Assignment between Production Orders in Local System and Product Cost Collectors in Central Finance

Project Management

Dedicated scenarios for Project Management do not yet exist in Central Finance, but you can use the existing ALE scenarios for master data distribution to transfer project master data and the related WBS elements between systems. If you want to keep the same WBS elements as in the local system, you can keep this master data within your posting, as we discussed when we looked at mapping options in Section 4.3. Alternatively, consider using the BAdi BADI_FINS_CFIN_AC_INTERFACE to transform your project assignments as you prepare the data for posting.

75


4.5 Transactional Objects

Although the universal journal treats Financial Accounting and Controlling as one, the local systems will still represent the old split, so you'll have one set of database triggers watching for changes to the accounting documents and another watching for changes to the controlling documents.

Note

Because Central Finance relies on the creation of a new document as the trigger for document transfer via SLT, it will not pick up on document changes in the source system. This gap can be closed as part of a customer implementation project. A standard solution is planned for delivery with SP 02.

Accounting Documents

For accounting documents, it 's common practice to use document summarization to summarize in such a way that the individual vendors, customers, assets, and materials are not included in the journal entry in order to ensure that the document does not have more than 999 line items. Because the Central Finance interface captures the data before the summarization process takes place, your document in Central Finance may

have more lines than the original document in the local system.

Open items for Accounts Payable and Accounts Receivable are transferred to Central Finance, but as of the time of writing (fall 2015) they are technically cleared. This means that the payment process currently has to take place locally where the genuine open item resides.

Bear in mind that your accounting documents are not purely entries to the SAP General Ledger but will also update the account assignments in Controlling (cost center, order, WBS element, business process, and so on). Therefore, CO documents with business transactions COIN, COlE, and so on will not be transferred separately but will be treated as part of


the accounting document. Similarly, if you have activated costing-based CO-PA in Central Finance (see Figure 19), CO-PA records of type F (invoicing) and B (direct posting to FI) won't be transferred separately,

but the assignment to the relevant CO·PA characteristics will be made during the reposting of the new accounting document.

Controlling Documents

As you approach your controlling documents, think about which allocations you will perform and where in the long term. The fo llowing CO business transactions are currently updated from the local systems to Central Finance:

» RKU1 (Reposting Costs) and RKU2 (Reposting Revenues) These transactions capture corrections to the account assignments in Central Finance, such as a reposting of travel costs from one cost center to another. You may also choose to allow this kind of correction posting directly in Central Finance.

» RKL (Actual Activity Allocation) These transactions are triggered by the work performed on the shop floor or captured in time sheets, so you are unlikely ever to perform these allocations in Central Finance. Instead, you are more likely to collect all the postings that result from order confirmations and back flushing in production planning and time recording in human resources. You will also need to ensure that you create master date for the relevant activity types are in Central Finance.

» RKLT (Actual Template Allocation [Used for Activity Based Costing]) These transactions typically use drivers in the local system, such as the number of components in a bill of material or the number of work center changes in a routing, and therefore are unlikely to move to Central Finance. As you prepare your master data list, you'll need to check whether you are sending business processes or just cost centers and activity types.

77


» RKIV (Distribution of Primary Costs) These transactions are typically used to transfer your utility costs from a supporting cost center to the operational cost centers while keeping the original account/cost element constant. Technically, you could perform this allocation centrally, but it's often needed locally for further processing on the operational cost centers. In such a case, you will want to send the results of distribution to Central Finance.

» RKIU (Actual Assessment) These transactions are used to transfer costs between cost centers , but with an aggregation under a secondary cost element so that all the costs on a shared service cost center are aggregated under a single cost element. Technically, you could perform this allocation centrally, but it's often needed locally for further processing, such as inclusion in the activity rate. In such a case, you will want to send the results of the allocation to Central Finance.

» RKIL (Inverse Activity Allocation) These transactions work like the assessment cycles discussed previously, but use activity quantities rather than amounts, so a utility cost center might split its total kilowatt hours based on the amount of work performed by each production cost center.

» KSPA (Assessment to CO-P A) With this transaction, you genuinely have the option to perform your allocations locally and send the results to Central Finance or to perform them only in Central Finance, provided that all base data needed for the allocation is available centrally. As you think about this business transaction, also consider the option to perform derivations in real time; you could make an early assignment of the costs for a marketing cost center to the segments served that would later be refined as more detailed information became available on the drivers at period close.

» KZPI (Overhead Calculation) This is a classic period close transaction to apply overhead to orders and projects as a percentage of the underlying costs. Bear in mind,


however, that you have the option to activate the business function CO_ALLOCATIONS and perform these postings in real time in the central system as the relevant primary and secondary postings are created. If this business function were active in the local system, the results would be transferred as KZPR.

» KOAO (Settlement) For now, you will probably continue to perform your settlement locally and send the results to Central Finance. However, as you think about these business transactions, consider the option to perform derivations in real time; you could make an early assignment of the costs for a research and development order or project to the segments served that would later be refined as more detailed information became available at period close.

» KTDA (Top-Down Distribution) If you post bonuses at the end of the year to a region in CO-P A, you might use top-down distribution to break down these bonus costs to the products sold. Because this transaction takes place solely in CO-P A, you actually have a choice as to whether you perform this step locally and transfer or perform it centrally.

» RKS (Statistical Key Figures) If you are considering performing allocations in Central Finance, then you will want to transfer statistical key figures, such as headcount and square footage of office space.

» KSIO, KSI1, KSI2 KSI3 (Actual Cost Center Split) These transactions are used to break out the cost center expenses to the activity types on the cost center.

CO-PA Documents

When we looked at the settings for the operating concern in Section 4.2, we noted that Central Finance could accommodate both account-based CO-P A and costing-based CO-P A. If you only activate account-based COPA in Central Finance, then you will be transferring accounting

79

documents for invoices, cost of goods sold, or direct postings or controlling documents for allocations and settlement according to the procedures we explained in the previous sections. The only difference will be that the account assignment is a market segment or PAOBJNR.

If you also activate costing-based CO-P A in Central Finance, then your invoices will result in CO-P A documents of type F (billing), and your cost of goods sold and FI postings will result in CO-P A documents of type B (direct postings). You can also transfer costing-based CO-P A documents of type C (settlement) and D (assessment) to Central Finance. This will give you the full line-item detail for each allocation. It is not yet possible to transfer other record types from costing-based CO-P A to Central Finance.

As of the time of writing, many organizations are using costing-based COPA in isolation in the local system. Although the FI documents will be assigned to CO-PA dimensions properly, any allocations and settlement documents that you transfer will only include reconciliation objects (with the object type AO) as receivers, so you might have a credit to a cost center (KS) and a debit to a reconciliation object (AO) for an allocation, or a credit to an order (OR) and a debit to a reconciliation object (AO) for a settlement. It is not yet possible to break out these reconciliation objects to show details of the real receivers (such as the product lines that received marketing costs in the assessment cycle).

5 What's Next?

In this E-Bite you learned how to set up a Central Finance system that combines the best practices from decades of financial management with recent technical innovations made possible by SAP HANA. So once you take the Central Finance route and arrive at SAP Simple Finance, what can you do with it?

8o

What's Next? I 5

Recommendation from Our Editors

Learn what SAP Simple Finance can do and what business value this innovative new solution offers your organization. The fi rst of its kind, SAP Simple Finance: An Introduction teaches you how you can use SAP Simple Finance applications for account ing, planning, consolidation, and compliance to accelerate decision making and streamline critical processes. Visit www.sap-[press.com/3 793 and take the next steps toward a successful SAP Simple Finance implementation.

In addition to this book, our edlitors picked a few other SAP PRESS publications that you might also be interested in. Check out the next page to learn more!

81

SAP PRESS E-Bites SAP PRESS E- Bites provide you with a high-quality response to your specific project

need . If you 're looking for detailed instructions on a specific task; or if you need to

become fam iliar w ith a small, but crucial sub-component of an SAP product; or if you

want to understand all the hype around a certain product: SAP PRESS E-Bites have you

covered. Authored by the top professionals in the SAP universe, E-Bites provide the

excellence you know from SAP PRESS, in a digestible electronic format, delivered (and

consumed) in a fraction of the time!

Janet Salmon

Accounting Entries in SAP ERP Controlling

ISBN 978-1-4932-1301-6 I $9.99 I 84 pages

Eli l<lovski

Configuring Funds Management for SAP Public Sector

ISBN 978-1 -4932-1302-3 1 $14.99 1 95 pages

Narayanan Veeriah

Configuring FI-TV for Business Travel

ISBN 978-1 -4932-1283-5 I $9.99 I 58 pages

The Author of this E-Bite

Janet Salmon is currently chief product owner for management

accounting at SAP SE and has accompanied many developments to

the Controlling components of SAP ERP Financials. as both product

and solution manager. She regularly works with key customers and

user groups in the United States and Germany to understand their

Controlling challenges and requirements, and recently contributed

to the first introduction to SAP Simple Finance. Learn more about

Janet at https:/ /www .sap-press .com/sap-simple-fri nance-how-do-

i-get -started-without -migrati ng_3 93 7 /author/.

SAP Simple Finance - How Do I Get Started Without Migrating

Documents

Transcript of SAP Simple Finance - How Do I Get Started Without Migrating