COPA in SAP SIMPLE FINANCE

In the past, SAP advised companies to use costing-based CO-PA rather than, account-
based CO-PA.

The main reason for this was:

Companies wanted a contribution-margin report with a breakdown of their cost-of-

sales down to the cost components level for each cost bucket
They wanted a production variance report by variance categories
They wanted a breakdown of the individual cost buckets beyond the total value that
was posted to the general ledger.
This functionality was not available in COPA account based before and therefore
most of the companies used Costing Based COPA.
The biggest issue with Cost based was the reconciliation effort, because costing
based COPA did not use a direct alignment to the general ledger accounts.

SAP�s latest SAP Simple Finance product , uses SAP HANA as its primary database,
and opened up new options to build a COPA structures aligned with the general
ledger. Due to this SAP enhanced Account-based CO-PA in SAP Simple Finance to
provide:

Detailed information on the cost of goods, break down cost-of-sales to the cost
component of each cost bucket
Production variances by variance categories
Invoice quantities
Reconciliation between COPA and the GL at Account level
Due to this new functionality in Simple finance SAP is now advised companies to
use account-based CO-PA and not costing-based COPA

New Features in Simple Finance for COPA

Define Accounts for Splitting the Cost of Goods Sold

By default, the cost of goods sold is posted to a single COGS account as defined
in the account determination settings for material movements.

In this Customizing activity, you can refine the settings for COGS postings to
split the COGS amount and post it to different accounts according to the cost
component elements

Steps

Create new G/L accounts on which you want to reflect the single cost components of
the COGS posting.
Specify a splitting scheme for your chart of accounts and assign a cost component
structure.
The cost component structure groups the costs for each material according to cost
component (such as material costs, internal activities, external activities, and
overhead)
3. For each splitting scheme, specify the following information:

Account to which all cost of goods sold are posted according to the account
determination settings for material movements
Cost component structure
New COGS target account for the specified cost component (profit account or loss
account
4. Assign the splitting scheme to the relevant companies.

To activate this split, follow IMG menu path Financial Accounting (New) > General
Ledger Accounting (New) > Periodic Processing > Integration > Materials Management
> Define Accounts for Splitting the Cost of Goods Sold in the IMG

Define Additional Quantity Fields

In financial accounting, reporting mainly focuses on amounts but sometimes you

also want to include quantities in your reporting. For example, in the consumer
goods industry it is common to store not just the quantity in the sales document
(for example, box or pallet) but also to convert that quantity into a quantity that
is common across all product lines (for example, pounds weight). This allows for
the aggregation of quantities across product lines. You can then use these common
quantities as drivers for management accounting (CO) allocation.

In Customizing, a standard unit of measure can be defined to ensure that the

quantities can be totaled and is required if you want to use totals as drivers in
allocation or top-down distribution. If you specify a standard unit of measure,
updates to the line item table of the record are done using this standard unit of
measure.

Activities

Assign a dimension to the additional quantity fields you are going to use.
If you want to allow the aggregation of quantities in order to use them as drivers
in allocation or top-down distribution, specify a standard unit of measure
3. Implement the logic to fill the additional quantity fields in the BAdI
FCO_COEP_QUANTITY for a specific controlling area.
Example

Assign dimension Mass to an additional quantity field. Implement coding to fill

the additional quantity field in the BAdI FCO_COEP_QUANTITY. For example, calculate
mass according to the entered number of pieces.

Define Accounts for Splitting Price Differences

In this Customizing activity, you can refine the settings for splitting variance
categories into general ledger (GL) accounts. This allows you to do detailed
analysis on prices differences in your income statement. When the costs of
producing materials are valuated based on standard prices, production variances can
occur on production orders where there are differences between the actual costs and
the target costs. These production variances are calculated in Product Cost
Controlling (CO-PC) and are split into different variance categories. Depending on
the reason for the differences, the system calculates the production variance, for
example, price variances, quantity variances, lot-size variances, and scrap. With
the settlement of the production orders, you can post the production variances to
Financial Accounting (FI) and Profitability Analysis (CO-PA). The amount settled to
CO-PA can be settled to different variance categories so that after settlement you
can display the single-variance categories in different value fields in cost-based
CO-PA. The amount settled to FI is normally shown as one total amount on a G/L
account for price differences. This account is defined in the account determination
settings for material movements. The variance categories and therefore the reasons
for the variances can normally not be reflected in this FI posting. With this
customizing activity, you can refine the FI posting to show the different variance
categories for each cost element on different G/L accounts allowing you to show,
for example, in your income statement, the reasons for the production differences.

Requirements

The following prerequisites must be met:

You work with standard prices for producing materials.

You have executed the variance calculation in CO-PC.
You have defined a settlement profile that allows the settlement of variances for
your order type.
For settlement to cost based CO-PA, you have defined a profitability accounting
(PA) transfer structure.

Activities

For a refined posting of production variances on different G/L accounts in FI, you
have to make the following settings:

1. Create new G/L accounts on which you want to reflect the postings of the
different production variance

2. Choose the Customizing activity Define Accounts for Material Management.

In the view Configuration Accounting Display, choose transaction PRD Cost (Price)
Differences your chart of accounts.
Assign the G/L accounts where price differences are normally posted to for the
relevant valuation classes of your materials.

3. Specify a splitting scheme for your controlling area and your chart of accounts.
4. Enter a cost element, cost element interval, or cost element group and/or a
variance category and assign one of the newly created G/L accounts where you want
to reflect these differences.

Multiple cost elements and/or variance categories can be reflected at the same G/L
account.
5. Select the Default checkbox for one of the entries. If no target account is
specified for a cost element/variance category, the system automatically posts
these amounts to the default G/L account.

6. Assign the splitting scheme to your company code and enter a valid from date.

Assigning Scenarios to Ledgers not required in S/4

Previously Scenarios need to be assigned to Ledgers (for eg: Segment,Cost Center,
Profit Center). This is no More required because ACDOCA contains all those Fields.

Real time Integration between FI and CO is Pre- built Functionality in S/4 because
CO is posted to the same journal entry Ledger Table (ACDOCA) as FI at the same
time.

Not Required to to Specify the Document number range for a local ledger Postings,
it always uses the leading ledger now.

SAP New Asset Accounting : Posting with the Accounts Approach

Set up company code / Chart of Depreciation with the accounts approach, and created
an asset and posted a credit to the vendor, and debit to the asset.

31 Vendor $4,000

70 Asset $4,000

And the result was 3 transactions:

As in the ledger approach, it posted to the 'Technical Clearing account' 199999.

The 2nd document generated posted the asset's APC and offset the Technical clearing
account.

The 3rd document generated highlights how the Accounts approach works with New
asset accounting:

I set the ledger group IFS2 to Depreciation area 05. I created another APC account
to post to account 160061 rather than 160060 . Keep in mind, Ledger group IFS2
posts to Leading ledger 0L.

With the accounts approach, SAP requires a contra account from the account
assignment, in this case, it's 199997 .

As with the old accounts approach, keep in mind you have to set up a new Financial
statement version with the correct accounts set up .

Above is the posting as viewed from one accounting principle (i.e. IFRS).

Above is the posting as viewed from the GAAP accounting principle.

What's going to into what tables?

The concern was, how would our extracts work if everything is going into the
Universal table - both FI and CO? What was happening to Results Analysis postings,
Allocations. Does BSEG still exist? etc.

I did a few different postings for testing

1. FB60 Invoice

2. Activity Allocation

3. RA calculation

FB60:

Not much different here, except for the obvious - ACDOCA gets posted.

Activity Allocation:

The question here was, for a CO only transaction, such as an activity allocation or
assessment, what gets posted to ACDOCA? Does BSEG get posted (Answer: No)?

I set up a simple activity allocation, transferred a few hours from one cost center
to another .

1. COEP is still posted , as does COBK.

2. BSEG does not get posted

3. ACDOCA does get posted. The secondary cost element is stored in the
same field as a regular GL Account would be.

As you can see the table entries above, ACDOCA not only stores the secondary
postings, but also the GL postings (balancing entries). The RACCT (Account Number)
stores both primary and secondary.

ACDOCA does keep track of what kind of posting it is -

RA Calculation:

I did a simple RA calculation on a WBS element that had costs post to a Primary
Cost element, and at period end you run KKA2 to calculate WIP. The question that
was asked, is where do the RA calculations go?

The simple answer is, they go where they have always gone: COSB. Since they are not
really postings, the RA values are calculates and stored on their secondary cost
elements and still kept in table COSB. There are no postings to the ACDOCA table.

When listing documents in FB03 - The Below Warning message in the earlier version
is not displayed in S/4.
Transaction Code FI12 is no more used for House Bank

SAP has taken away the ability to create a House bank account using the FI12
transaction using the SAP Gui.

Note in the House bank views, you won't find the node anywhere to create the banks.
You have to create the accounts using the delivered Fiori app.

Must choose the role SAP_SFIN_CASH_MANAGER)

Convergence of GL Master and Cost Element Master

We will look at the convergence of long standing pieces SAP ERP finance master
data, the GL Account and the Cost Element. As anyone that has worked with SAP CO in
the past knows the cost element is key to the controlling side of SAP. It in an
object that allows you to identify the type of activities that can be done within
controlling with that account. They are generally divided into Primary and
Secondary cost elements.

� Primary cost elements have an associated GL account and are generally expense or
revenue accounts.

� Secondary cost elements exist only in CO and are used for internal settlements,
assessments, and allocations.

When creating a new revenue or expense account in the GL you have to create a
corresponding cost element in CO and typically all you were doing was selecting a
Cost Element Category.

With the Simple Finance , the traditional cost element create, change and display
transactions are gone. The functions have been combined in FS00 - Manage G/L
Account Centrally. This greatly simplifies the act of creating a new account and
eliminated the need to maintain separate masters.

On the Type/Description screen there is a new field called account type. If you
select either "Primary Costs or Revenue" or "Secondary Costs" a new field will
appear on the Control Data tab for you to enter the Cost element type.

Primary Cost Example:

Secondary Cost Example:

Functional aspects of the migration to Simple Finance

Another important point is that the new GL is not a pre-requisite for an

implementation of the GL
In SAP Accounting. You can perform the migration straight from the classic GL to
the GL in Simple Finance.

The GL in SAP Accounting is very similar to the New GL in SAP ECC: it provides the
same capabilities as new GL and leverages its data structures, but it is further
optimized for HANA, for example no totals tables, convergence with CO, better
reporting, etc. Existing PCA (profit center) and SL (special ledger) functions and
features from classic GL can remain in place.

However, be aware of one limitation when migrating from classic GL: document
splitting and parallel ledger cannot be implemented yet (this restriction is
planned to be lifted later on with a Support Pack). So, if for example you wanted
documents split now in sFIN, you would have to migrate first in new GL, activate
the document split, and then migrate to sFIN. Finally, the migration also moves you
to New Asset Accounting (NAA).

Modifications to the ERP data model:

Here is the list of FI/CO tables removed in SFIN:

Index tables removed:

BSIS Index for G/L Accounts

BSAS Index for G/L Accounts (Cleared Items)

BSID Index for Customers

BSAD Index for Customers (Cleared Items)

BSIK Index for Vendors

BSAK Index for Vendors (Cleared Items)

BSIM Index, Documents for Material

FAGLBSIS Index for G/L Accounts � New G/L

FAGLBSAS Index for G/L Accounts � New G/L (Cleared Items)

Aggregate tables removed:

GLT0 General Ledger: Totals

GLT3 Summary Data Preparations for Consolidation

FAGLFLEXT New General Ledger: Totals

KNC1 Customer master (transaction figures)

LFC1 Vendor master (transaction figures)

KNC3 Customer master (special G/L transaction figures)

LFC3 Vendor master (special G/L transaction figures)

COSS Cost Totals for Internal Postings

COSP Cost Totals for External Postings

The remaining physical tables are fully Line Items based. All dimensions are
available for fast analysis with SAP HANA. There are no more limitations by pre-
defined totals or aggregates as before. Data structures can be easily enhanced with
custom dimensions (just update the line item table).

Please note that all those deleted tables are replaced by HANA CDS views. So those
suppressions will not affect existing custom ABAP code as long as such code is not
writing in one of those tables: custom programs and reports with read access to old
tables will continue to work.

Optimized transactions:

Many period close transactions have been optimized for HANA in SFIN:

Settlement (plant selection) CO88 -> CO88H

Settlement (make-to-order sales orders) VA88-> VA88H

Settlement (internal orders) KO8G-> KO8GH

Settlement (projects) CJ8G -> CJ8GH

Results Analysis KKAK

-> KKAKH

(POC method or revenue-based)

WIP Calculation at Actual Costs KKAO

-> KKAOH

Variance Calculation w. Full Settlement KKS1-> KKS1H

Variance Calculation for Cost Centers KSS1-> KSS1H

Harmonized External and Internal Reporting in SAP ERP:

� Link on line item level (1:1) between Financial Accounting (FI) and
Management Accounting (CO)

� Link from CO line items to dimension table in profitability analysis (CO-

PA)

� Enhancements of account-based CO-PA (detailed postings for cost-of-goods-

sold and variances)

� Logical document (HANA view) for analyzing the converged data

� New detailed analysis of Work in Process

� Real-Time Operational Reporting in SAP ERP

� No need for time-consuming extraction into and separate (delayed)
reporting via SAP BW

� Reporting across multiple SAP or non-SAP ERP systems with deployment

option �central journal�

New Fiori User Interface: SAP Gateway prerequisite:

SFIN introduces a brand new user experience, simplified and ergonomic, to Finance
with Fiori.

You must know however that Fiori has technical requirements of its own. The
prerequisite of Fiori for an ABAP based application is the middleware SAP Gateway.
SAP Gateway is part of Netweaver 7.4, so it is automatically installed with ECC.

But for a production system, SAP recommends that you use a Central Hub Deployment
of SAP Gateway. This means you install SAP Gateway independent of ERP on a
standalone system, either behind or in front of the firewall. You therefore
separate back-end components from front-end components. For production systems, SAP
does not recommend the Embedded Deployment option.

So you will need to plan for installing Gateway if it is not already in place in
your SAP landscape.

Finally, be aware that the old retired transactions replaced by redeveloped Fiori
applications will not be accessible anymore through the SAP GUI. If you attempt to
start them, you will get a pop-up redirecting you toward the Fiori Launchpad of
Simple Finance.

SAP Single Source of Truth with Universal Journal

Before we answer this question, let us get a small introduction. The Universal
journal entry eliminates the need for the separation made previously between
Financial Accounting (FI) and Controlling (CO) (single source of truth). There is a
combined FI and CO document linked with a logical document. All the information is
recorded in 1 line item table (ACDOCA).

Since financial accounting and managerial accounting are reconciled constantly,

there is no longer any need for reconciliation between FI and CO or between FI-GL
and FI-AA. Nor is there any need for the real-time integration of these components.
The reports in all components use data from the same journal and thus known as
Universal journal.

For this functionality to work there is a change in master data, architecture of

the tables and also in configuration. Let us see the major changes in these areas.
All cost elements (primary and secondary) need to be portrayed as G/L accounts.
Consequently, we no longer need to enter the master data for cost elements
separately; instead, we only need to create G/L accounts from now on.

You will not find any transactions related Cost elements. Below screen-prints
between ECC EHP7 for SAP ERP 6.0 and S4HANA ON PREMISE 1.0
Now, let us see what does the one source truth means in SAP system.

I posted a FI document which triggered entries in BSEG, FAGLFLEXA, FAGLFLEXT, COBK,

COEJ and COEP tables (and some more BSIS, etc.) in ECC. Compare it with a posting
in S4HANA ON PREMISE 1.0, all the information is recorded in BKPF (header) and
ACDOCA (line items). Thus reducing the foot print drastically.

What will happen to old tables? Updates are no longer made to these old tables.
Nevertheless, you can continue to use reports that use data from these old tables.
This is because compatibility views for a data request from one of these tables
read the data from ACDOCA.

Let us compare the views in these ECC tables with ACDOCA.

FI tables

CO tables

ACDOCA (Universal Journal

Now, let us review with one use case by posting FI document to a P&L acct with cost
object as profitability analysis. Note this S4HANA On Premise 1.0 system had
Account Based COPA active.

There is no separate COPA document visible in the accounting document workflow

(refer the screen print below), a controlling document is a logical document. Real-
time integration is no longer applied. Instead, CO transactions are posted directly
as an universal journal entry (ACDOCA). As secondary cost elements are also
contained in the chart of accounts, account assignment to a different account is no
longer necessary.

Analysis on ACDOCA:

This universal journal can easily be extended with the coding block and adding CO-
PA characteristics (refer the below screen print). Also, actual data posted will be
stored in ACDOCA with all the Characteristics defined in the operating concern.
These standard coding block extensibility and customer fields are added
automatically to the universal journal.

Adding to the advantage, reporting based on the ACDOCA data is fast and flexible.
Business Intelligence (BI) frontend tools can be used for operational reporting,
thus the benefits of BI tools are inherited by the transactional system. Also, each
journal entry contains the ledgers to which the business transactions are posted.

The profitability segment are stored in CE4XXXX tables as before.

The below table will give an snap shot of what has changed in COPA area.

Since SAP has redesigned their architecture on account based costing, the tables
impacting are also on account based.

Architectural Analysis:

� COEP table will still exist and be written with entries except for Value
type 04 and 11. ACDOCA will get updated with 04 and 11 value type.

� Compatibility views for tables are available on all traditional tables.

E.g.: V_COEP. This is very helpful; since customers who have build programs with
these traditional tables can still use them. Via this view the select is redirected
to the new table ACDOCA.

� Access to old table data is still possible with V_tablename_ORI e.g. :

V_COEP_ORI, V_FAGLFLEXA_ORI, etc.

� COBK still will be written as before.

� COSP and COSS will all be written directly to ACDOCA.

� New tables COPS_BAK: Primary cost: Planned cost and commitments and
COSS_BAK : Secondary cost : Planned cost and commitments, will be updated with
entries other than value types 04 and 11.

Further to my explanation above, the universal journal entry has its own currency
fields. This brings the currency concepts used in FI and CO closer together. Also,
to substantiate this answer, a big advantage of this universal journal is that
reconciliation efforts are enforced by design.

There are few things to improve in future from my view. As explained above, the
Universal Journals can be extended with customer COPA characteristics this means if
a customer has multiple operating concerns then all the characteristics will be
included in the journal. This might cause an issue and will increase the fields
unnecessarily. Also, the idea of keeping CE4XXXX table is unclear now since there
is only one table to navigate and all the characteristics are filled directly in
Universal Journal. There is no use of this table anymore. Having said this, still
this concept has enormous advantage for customer.

Overall, after a long wait, SAP has successfully completed the task of brining
different sources into one. Thus, with S/4HANA Finance/Simple Finance has a Single
Source of Truth with Universal Journal.

The Universal Journal table, provides a single source of truth in accounting and
controlling where:

� All financial transactions are written including transactions from

accounts payable, accounts receivable, general journal, material ledger, asset
accounting and COPA sub ledgers.

� All reports are based, from high level financial statements to detail
level accounts payable summaries and daily check log to apply against accounts
receivable transactions.

� Transactions can be tracked from original purchase order of raw materials

to final sale of finished goods.

The following topics below describe actions that can be taken even if your company
will or will not migrate to SAP HANA:

- Data centralization: Analyze your system landscape around your current ERP system
and check data storage duplication, for example, legacy system storing same
information as your ERP in another database. There is no sense to apply SAP HANA
with a system landscape with a lot of legacy system and databases integrated by
interfaces.

- Process redesign: some process cannot be applied in your current system due to
data processing and management. For example, production process and online back
flush in a repetitive manufacturing sometimes is not possible due to the high
volume of database lock designing the current production process to have
asynchronous generating WIP materials when actually it does not exists. At this
point raise ideas that could be implemented or improved with in-memory technologies
resources.

Refresh and redirect your knowledge: your functional skills will be enlarged and
not lost with SAP HANA technology. It's the chance to redirect ways of working so
far to in-memory technologies and suggest improvements currently undelivered for
technical limitations. This way of think will refresh your knowledge and prepare
yourself for the near future.

- Integration and cross-business process understand: the goal to delivery real-time

information across all business process will require from us the cross-business
understand. The information will be triggered and integrated in real-time all
business areas involved. It will be necessary to understand the information from
the start until the end.

1- Pre-requisite :

In order to show finance posting analysis, we need.

� SAP Simple Finance system fully configured

� SAP HANA LIVE Studio with the standard package imported

� SAP Lumira connected to SAP HANA

� SAP Lumira map extension activated

� Esri GEOMAP account

� Your financial posting

For instance, the following finance posting has been done in the SFIN System.

Company 1 with 14 888 550 euro of turnover

Company 2 with 17 780 000 euro of turnover

2- HANA LIVE Data model creation:

Create or extend a standard calculation view (based on ACDOCA table) in order to

extract turnover data.

A relevant data selection can be performed.

3- SAP Lumira analytics :

Add a new dataset getting the financial report based on the calculation view below.

Your report is ready, you can display it and breakdown data as needed.

The first screen is a global turnover view �by country�.

Then you can breakdown it to display turnover by country and G/L account.

In conclusion, thanks to those new features, CFOs can benefit from turnover
geolocation presentation on any device which is very important in the big data era.

In MRP logistics processes, for example, stock can be displayed by store or by

region which can help for appropriate replenishment.