Financials S4 AC110-EN-S4HANA.pdf

AC110 Collection: 03 Material Number: 50129799

SAP Accounting powered by SAP HANA © 2015 SAP SE or an SAP affiliate company. All rights reserved.

Abstract Target Group

Application Consultant

General Description

The course provides an overview of the functionality of SAP Accounting powered by SAP HANA within SAP Simple Finance.

Learning Objectives

-

Explain the scope and impact of the SAP Simple Finance On-Premise Edition 1503

-

Explain the architecture of the SAP Simple Finance add-on

-

Explain the Central Finance deployment option of SAP Simple Finance

-

Configure and use new functionalities in SAP Accounting powered by SAP

HANA Duration

Use the standard SAP Fiori applications designed for Simple Finance

2 days (classroom)

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

AC110 Unit Overview SAP Accounting powered by SAP HANA

Unit 1: Overview of the SAP Simple Finance On-Premise Edition 1503

120 minutes

Unit 2: General Ledger Accounting

180 minutes

180 minutes

Unit 3: Asset Accounting


Unit 4: Management Accounting

180 minutes

Unit 5: Further Simple Finance Integration

180 minutes

Unit 1: Overview of the SAP Simple Finance On-Premise Edition 1503

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

Unit 1 – Agenda

Introducing SAP HANA and SAP S/4HANA

Providing an overview of Reporting Options

Describing the Architecture of SAP Simple Finance

Introducing SAP Fiori

Analyzing the Universal Journal

Overview of Migration to the Simple Finance On-Premise Edition1503

Analyzing the Central Finance Option


Lesson 1: Introducing SAP HANA and SAP S/4HANA


Learning Objective

After completing this lesson, you will be able to:

 Give an overview of SAP HANA, SAP S/4HANA, and SAP Simple Finance


Scenario

Your business has to process an ever increasing flood of data. You are looking for ways to extract meaningful information from this data and to be able to report on it efficiently. You are interested in understanding how SAP HANA can help you with your data storage and analysis needs today. You also want to make sure SAP HANA is the right core to future proof your organization in preparation for the information explosion coming with the expansion of the Internet of Things. You are interested in upgrading your current system landscape to a next generation solution. You are particularly interested in the new S/4HANA suite and want to understand the scope of the solution offering and available deployment option.


Tradeoff - Broad & Deep or Speedy & Simple With existing technologies, optimizing across all five dimensions in the spider diagram is not possible.

DEEP

OR

HIGH SPEED

DEEP

HIGH SPEED BROAD

SIMPLE

REAL -TIME

SIMPLE

In both scenarios, real time updates are not possible per design; in a data warehouse environment they occur overnight via nightly batch jobs. © 2015 SAP SE or an SAP affiliate company. All rights reserved

The Vision of SAP HANA A Common Database Approach for online transaction processing (OLTP) and online analytical processing (OLAP) Using an In-Memory Column Database Hasso Plattner - Co-founder and Chairman of the Supervisory Board of SAP

Transactions + Analysis + Acceleration processes separated

One individual copy of data for Transactions + Analysis, all in Memory

SAP HANA ETL

Transact

ETL

Analyze

Cache

VS

(DRAM)

Accelerate

 3 copies of data in different data models  Inherent data latency  Poor innovation leading to wastage © 2015 SAP SE or an SAP affiliate company. All rights reserved

 Eliminate unnecessary complexity & latency  Less hardware to manage  Accelerate through innovation, simplification + in-memory

Paradigm Shift for Developers Calculation

Application Layer

Database Layer

Calculation

In traditional applications (especially from SAP), the database is largely used as a data store mechanism only. Massive queries bring large amounts of data back to the application server for processing. Lots of application execution time is spent in the application server looping over records and performing exclusions, calculations, etc. With HANA, the key to the best application performance is pushing as much of the logic execution into the database as possible. We now “trust” the database. Keep all the data intensive logic down in the database as SQL, SQLScript, and HANA Views.


SAP S/4HANA, Next Generation Business Software

SAP HANA

 In-memory platform

SAP Business Warehouse powered by SAP HANA

SAP Business Suite powered by SAP HANA

 Real-time analysis

 Real-time business

 Real-time reporting

 OLAP and OLTP together  SAP HANA Enterprise Cloud for SAP Business Suite on SAP HANA

SAP Simple Finance powered by SAP HANA  Instant financial insight  No aggregates

 Simplified data model

 Single source of truth

 New user experience  Advanced processing  Choice of deployment  Multitenancy

2011

2012

2013

2014

2015

•

S/4HANA is natively built on SAP HANA for massive simplifications (simplified data model: no indices, no aggregates, no redundancies)

•

S/4HANA is natively designed with SAP Fiori offering an integrated user experience with modern usability (role-based, 3 steps max to get the job done, mobile-first, consistent experience across LoBs) S/4HANA is natively built for advanced innovations (e.g. new applications predicting, recommending, simulating / processing of text, geo data, graphs, genomes.

•

•

S/4HANA is natively engineered for providing choice of deployment (on-premise, cloud, hybrid)

•

S/4HANA fully leverages the new multi-tenancy functionality enabled by SAP HANA


SAP S/4HANA, the next generation business suite

Internet of Things

People

SAP Fiori UX role-based user experience for all devices

SAP S/4HANA applications and extensions Business networks

instant insight-driven applications for all lines of business and industries Devices

SAP HANA platform in-memory platform for all data

Social networks

On-premise edition

Cloud edition

Native integration for hybrid scenarios Ariba


Concur

Fieldglass

hybris Software

SuccessFactors

Big Data

Technical & Business Values Reduced Data Footprint

Higher Throughput

Full Flexibility

S4HANA (estimate)

ERP on anyDB

ERP on HANA

S4HANA (estimate)

ERP on anyDB

No Indices No Aggregates No Redundancy

7.1 TB

1.8 TB

0.8 TB 0.5 TB ACTUALS

1

3-7x

Enterprise Software for Big Data and Agility © 2015 SAP SE or an SAP affiliate company. All rights reserved

Customer journey to SAP S/4HANA – 3 situations, 3 deployment options Choice of deployment Starting point A

New customer

On Premise

Cloud

deploy new installation

up and running with best practices in two days

On Premise

Cloud

Hybrid

Starting point B SAP Business Suite on anyDB customer

Hybrid

upgrade to latest EHP, migrate database transfer data to the cloud no migration to SAP HANA, deploy exchange innovation

Supported by predefined migration, system conversion in the cloud and deployment packages from partners and SAP

Starting point C SAP Business Suite powered by SAP HANA customer

On Premise

Cloud

deploy exchange innovation

transfer data to the cloud no migration

Innovation without disruption © 2015 SAP SE or an SAP affiliate company. All rights reserved

Hybrid

SAP Simple Finance

Instant Insight in memory-enabled

Financial Planning and Analysis

Intuitive User Experience all devices

Accounting and Financial Close


Treasury and Financial Risk

Flexible and Non-disruptive cloud or on premise

Finance Operations

Enterprise Risk and Compliance

Impact of SAP HANA on Finance: Simpler and Faster

“Personalized information for end users with granular drill down“ Business Intelligence

Renewed Managerial Roles

Renewed Transactional Roles

Web Financial Statement Web Journal Entry Analyzer SAP Analysis for Office SAP Lumira SAP Business Explorer SAP Design Studio

Chief Financial Officer Financial close manager Cash manager Receivables manager Payables manager Finance for managers

General ledger accountant Accounts receivable accountant Accounts payable accountant Collections specialist Dispute specialist


Impact of SAP HANA on Financials: Simpler and Faster

SAP Simple Finance - delivers functional completeness across all financial roles

VP of Finance

Head of Corporate Reporting

Corporate Treasurer

Chief Financial Officer

Head of Finance Operations

Chief Compliance Officer

Financial Planning & Analysis

Accounting & Financial Close

Treasury & Financial Risk Management

Collaborative Finance Operations

Enterprise Risk & Compliance Management

Develop and Translate Strategy

Accounting

Payments and Bank Communications

Receivables Management

Enterprise, Risk Management

Planning, Budgeting and Forecasting

Entity Close

Cash and Liquidity Management

Collaborative Invoice to Pay

Controls and Compliance Management

Profitability and Cost Management

Corporate Close

Debt and Investment Management

Travel Management

Access Governance

Monitoring and Reporting

Reporting and Disclosure

Financial Risk Management

Financial Shared Services

International Trade Management

Financial Close Governance

Commodity Risk Management

Real Estate Management

Fraud Management Audit Management


Key Innovations within SAP Simple Finance

SAP Accounting

powered by SAP HANA

SAP Integrated Business Planning for Finance

New product for Group Cash Management

New capabilities and enhanced integration for ERP and BPC

SAP Cash Management

powered by SAP HANA

Alternative in-memory functionality for ERP customers

Business Suite on HANA SAP HANA Platform

Aligned

Agile

Predictive

Single Source of Truth

Real time processes

Dynamic Planning and Analysis


Adoption Scenarios for Simple Finance Option 1: Upgrade and Migrate

Option 2: Upgrade, Migrate and Consolidate

(all instances)

(reduce number of instances)

SAP ERP or SAP R/3

Migrate

Simple Finance

SAP ERP or SAP R/3

SAP ERP 6.0 EhP7 on HANA

Option 3: Replicate into a Central Finance (and optionally reduce number of instances over the time) Replicate

Simple Finance

SAP ERP or SAP R/3 source system(s):  SAP (any release)  non-SAP systems


SAP ERP 6.0 EhP7 on HANA

Real-time Reconciled

Central Finance instance

Migrate

Simple Finance SAP ERP 6.0 EhP7 on HANA

Related SAP Links Where

What

Link

SAP.COM

SAP HANA

http://hana.sap.com/

Help Portal

SAP HANA Innovations for SAP Business Suite

http://help.sap.com/hibs

SAP.com

Discover SAP S/4HANA

http://discover.sap.com/S4HANA

SAP Service Marketplace

Hybrid Scenarios

http://service.sap.com/public/hybrid

SAP.COM

Help Page for SAP Simple Finance

http://www.sap.com/solution/lob/fin ance/software/cloud-erp-financemanagement/index.html


Learning Summary

You should now be able to:

 Give an overview of SAP HANA, SAP S/4HANA, and SAP Simple Finance


Unit 1 – Agenda











Learning Objective


 Explain the idea and concept of the Universal Journal  Explain how SAP safeguards the customer investments  Outline the most important architectural changes in Simple Finance  Understand the Universal Journal entry  Outline the Appendix Ledger functionality


Scenario

You want to understand in detail the underlying architecture changes to the SAP ERP application from the installation of the Simple Finance On-Premise Edition 1503. You want to understand the potential benefits these changes bring and also make sure your custom developments won’t be disrupted with the migration.


SAP Accounting Architecture Rational

A true single source of truth for all accounting components.  Reconciliation is a topic of the past bringing large cost and time savings.

A simple but holistic data model.  HANA can be leveraged in the best possible manner bringing unprecedented insight (in both speed and content!).

The universal journal combines and harmonizes the good qualities of all accounting components.  The simplification of the application is a required step and a great foundation for further enhancements.

Non-disruptive innovation and simplification.  SAP strives to provide a true next generation application with the least possible disruption, safeguarding customer investments and processes.


Multiple sources of truth (1/2)

No profit center & no G/L account in Asset Accounting Totals

Material Ledger does not store G/L account and Profit Center

Different level of detail due to the ‘999’ document lines limit e.g. 1:n documents FI/CO

G/L and Profitability updated at different business events on different entities (e.g. account)

Separate components due to technical restrictions in the past (without HANA) © 2015 SAP SE or an SAP affiliate company. All rights reserved

Multiple sources of truth (2/2) Challenges of the architecture before Simple Finance

Challenges:  The combined content of several tables represents “the truth”. Reconciliation efforts are needed by architecture.  Different level of detail stored in the respective components/tables  Components are structured differently (e.g. fields/entities differ)  Need “to move” data to the appropriate table for reporting (e.g. “settlement”)  Different capabilities in the components (customer fields, currencies, multi-GAAP etc.)  Multiple BI extractors needed to cover the complete truth in BI.


New Architecture – Universal Journal as the Single Source

 One line item table with full detail for all components. Data stored only once, so no reconciliation needed by architecture.  Fast multi-dimensional reporting on the Universal Journal possible without replicating data to BI. If BI is in place, one single BI extractor is needed.  Reduction of memory footprint through elimination of redundancy.  Technical preparation done to enhance important structural capabilities of the Financials solution (e.g. multi-GAAP, additional currencies) © 2015 SAP SE or an SAP affiliate company. All rights reserved

Non-disruptiveness

Existing programs and interfaces can still be used access via compatibility views:  Read access from custom ABAP programs or reports to prior tables will work as before  Read access is automatically re-directed to the universal journal as the new single source of truth  All programs with write access to those deleted tables replaced by CDS views will make trouble and can´t be used anymore without adaption. Remove all write accesses in by views replaced tables. Use the code inspector to find all affected parts of the code (see note 1976487).


List of Tables Replaced by Compatibility Views


Universal Journal extensibility

Universal Journal …

Standar d Field x

Standard Field x+1

zzcust01

zzcust0 2

…

Coding Block extensibility

wwprof0 1

wwprof02

…

CO-PA extensibility

 The Universal Journal can be easily extended with customer fields. Extensibility is available for all components that use the Universal Journal (G/L, CO, AA, ML).  P&L line extension using “CO-PA capabilities” is provided, both for field definition (characteristics) and the rich derivation tools from CO-PA.  The standard General Ledger coding block extensibility can be used and affects the Universal Journal  The new HANA based reporting of all components (G/L, AA, ML, CO) can access the customer fields.


Demos & Exercises

Activity

Name

Page

DEMO 1

HOW TO EXTEND THE GENERAL LEDGER CODING BLOCK

EX-3

EXERCISE 1 DISPLAY FINANCIALS TABLES IN SIMPLE FINANCE


EX-12

Summary

You should now able to:

 Explain the idea and concept of the Universal Journal  Explain how SAP safeguards the customer investments  Outline the most important architectural changes in Simple Finance


Unit 1 – Agenda











Learning Objective


 Understand the Universal Journal entry  Outline the Appendix Ledger functionality


Scenario

You want to understand the new posting logic within the accounting component. You are interested in understanding how the journal postings are handled from the various components and whether the unification into a central finance limits the flexibility you have associated with your management accounting processes.


Universal Journal Entry

 The new journal entry consists of a header (table BKPF) and the respective items (table ACDOCA) – There are rare cases, where entries in ACDOCA are written without a respective document header (e.g. carry forward, corrections in migration). These entries do not represent standard business processes. – The corresponding line items have ‘artificial document numbers’ beginning with letters (e.g. ‘A’).

    

ACDOCA table contains all fields needed for G/L, CO, AA, ML, PA All cost elements, including secondary cost elements are G/L accounts Multi-GAAP capability through “RLDNR” dimension 6 digit field for line item numbering 23 digits for currency fields


Document Numbers in Simple Finance

 Since the system now writes only one journal entry for all of the components G/L, CO, AA, ML, one document number is sufficient from a business point of view. The journal entry consists of a header (BKFP) and items (ACDOCA). The respective document number (BKPF-BELNR/ACDOCA-BELNR) must obey the legal rules of Financial Accounting. As a consequence, the document number is dependent on the fiscal year and the company code.  CO document numbers have not been year dependent. Material ledger document numbers have not been dependent from the organizational unit (e.g. company code). Both numbers did not have a legal relevance. Moreover, ACDOCA has a 6 digit field for the document line, whereas COEP has only a 3 digit field. This is still used in many user interfaces and reports. For compatibility reasons, SAP offers a new transaction number for every 999 document lines.


ACDOCA DOCLN

CO_BELNR

CO_BUZEI

000001

A00X345100

001

001082

A00X345100

999

001083

A00X345101

001

A00X345101

086

000002 …

.. 001130

Prima Nota in Simple Finance

 The Prima Nota is the source document that triggers the creation of Journal Entries. The Prima Nota is the single anchor that allows e.g. to reverse the complete process triggered by the Prima Nota.  The Prima Nota keeps the information that has been entered to the system, before derivations, enrichments, splits etc. take place in Accounting in order to create Journal Entries.  In many cases the Prima Nota is a document outside Financials. Examples are Expense Reports, Invoices, Payroll documents.  For posting within the Financials world a Prima Nota is needed as well.


Prima Nota per Financial Component

 For classical FI postings (FB01, FB50, FB60, FB70 etc.) the Prima Nota is still stored in table BSEG and the corresponding Journal Entries (can be several due to the multi GAAP capability) are written to table ACDOCA.  For classic (manual) CO postings the Prima Nota is still written to table COEP. The corresponding journal entries are written to table ACDOCA. A Prima Nota is written as well in cases, where “CO” is triggered via BAPI interfaces (AWTYP <> AFRU, CATS)  For allocation postings (assessment, settlement etc.) no Prima Nota is required and data is written to table ACDOCA only. The allocation process has its own history management (for example canceling an allocation journal entry)  Material price changes (MR21) or Material Debit/Credit (MR22) create a Prima Nota in the material ledger (tables MLHD, MLIT etc. ). The respective journal entries are posted to ACDOCA.


External Postings with Simple Finance

MM

ACDOCA

SD

BSEG

HR AA

PCA Accounting Interface

ML

Other


FI-SL

EC-CS Cost Based CO-PA

 Former COEP, FAGLFLEXA, ANEP, MLIT etc. data are stored in ACDOCA  BSEG as before Simple Finance. Can still be summarized.  Profit Center Accounting (ECPCA), Special Purpose Ledgers (FI-SL) and, Consolidation (ECCS) remain technically untouched and work as before.  Components that have been built with FI-SL technology like Joint Venture Accounting, Public Sector etc. are untouched and work as before.  Cost based CO-PA works as before

Demos & Exercises

Activity

Name

Page

EXERCISE 2 POST AND REVERSE A SIMPLE FI DOCUMENT

EX-20

EXERCISE 3 POST A CO TRANSFER POSTING AND VIEW THE RESULT

EX-30


Summary


 Understand the Universal Journal entry  Outline the Appendix Ledger functionality


Unit 1 – Agenda











Learning Objective


 Understand the motivation for the Central Finance solution  Get an overview of the Central Finance solution  Explain implementation options and requirements


Scenario

You are managing a complex and varied ERP system landscape. You want to find a solution to improve financial reporting and processes, both in speed and accuracy. A large transformation and migration project to completely new systems is out of the question due to time, cost, complexity and business continuity requirements. You want to understand if and how the SAP Central Finance solution can help transform and modernize your Finance reporting and operations.


Business Challenges

 Consolidated entity reporting

latent, high-level, aggregated management information

 Central process execution

missing economies of scale, no shared services

 Business model pressure

organic and non-organic growth mandate

 Heterogeneous IT landscapes

unyielding to modernization or transformation

 SAP and non-SAP ERP systems

high consolidation, harmonization, reconciliation effort

 Relational database designs

data duplication, data redundancies

 Productivity & Effectiveness

people can’t get the data they need to make a decision


The Central Finance Solution Central Finance helps companies report on financial figures sourced from different systems. These systems might be running Classic G/L, new G/L, or might not be SAP at all. They probably have different customizing settings and un-harmonized master data: With the Central Finance solution , there are three interfaces that feed data from the source systems into the target system’s Accounting Interface.  An interface for reposting FI/CO postings: Financial documents that are posted in the source system get reposted as new FI documents in the central finance system. If these postings are relevant to CO (expenses on cost elements), CO will be updated, too  An interface for reposting CO postings: This interface reposts CO postings where the CO document is the loading document. In contrast to the interface for FI/CO postings, these are postings that are not necessarily reflected in Financials in the source system (sometimes only for reconciliation purposes). For example, postings on secondary cost elements.  An interface for replicating certain cost objects (such as production orders, internal orders, QM orders etc.). The posted documents are stored in the universal journal of the SAP Simple Finance system. It is possible to take advantage of new G/L features within SAP Simple Finance as well as the ability of flexible reporting based on line-items instead of pre-aggregated totals. Furthermore beautiful Fiori User Interfaces and reporting tools can be used in the Central Finance. Reporting with the speed of HANA is available on lineitem levels.


System Landscape

Simple Finance

Real-time Reconciled Harmonized

Suite on HANA

ERP

SAP HANA

ERP(s)

source system(s):  SAP (any release)  non-SAP systems  old, out-of-maintenance  over-customized

(platform)

plan, consolidate, report

A dedicated Simple Finance system (Suite on HANA, Simple Finance at its core) and SAP planning, consolidation and reporting capabilities (optional) connected to one or more ERP systems

central finance instance


on-premise

OR cloud

Key installation components

Required:  SAP HANA hardware (on-premise, cloud, private cloud) and software (database / appliance)  SAP Landscape Transformation (LT) Replication Server (plus partner products like Datalytics for non-SAP ERP systems)  SAP S/4HANA (ERP with SAP Simple Finance)  SAP HANA Live/Fiori and Smart Business Cockpits etc.  SAP Business Intelligence tools like Analysis for Office  Additional Simple Finance products like Integrated Business Planning, Cash Management, or Fraud Management etc. (optional)


Deployment

 A Central Finance can be established on-premise or in the cloud.  In a cloud deployment scenario data is replicated using the same mechanisms used in on-premise installations (SLT). The respective SLT portions will have to be available on both, the sending (on-premise) and receiving system (cloud).  Non-SAP reporting and analytics (as well as additional SAP Simple Finance or partner products) need to be connected to the cloud instance or be made available within the cloud installation as required.  Special considerations in the cloud scenario include but are not limited to wide area network (WAN) throughput and firewall/security requirements.

DEPLOYMENTS

On Premise

Hybrid

Cloud


Inbound posting interfaces (Finance, Controlling) Central Finance

FI/CO Postings FI CO Document Document

CO Postings

CO Document

Universal Central Journal Entry Finance Suite on HANA Accounting Interface

Cost Object Mapping Reposting harmonizes data but retains line item-based detail

SAP HANA Central Finance instance


Sender data fields for document drill back

New “Sender” data fields that explicitly track source

Double-click to navigate back to FI document in source system Sender system


Central Finance system

Master data creation for CO cost objects Cost Object Mapping Framework manages short-lived cost objects

Central Finance Long-Life Master Data Stable, only need to be harmonized once Examples: Company Code, Plant, Material, Cost Center Managed by SAP Master Data Governance

Short-Life Cost Object

Central Cost Object Reporting

Production Order1

Expense1 Cost Object Mapping

Expense2

Production Order2

Central Product Cost Collector

Production Order3

Primary and Secondary Cost Postings

Expense3

Source System

Similar to transactional data, generated frequently

Expense1

Expense2 Expense3

Examples: Production Order, Internal Order, Service Order… Managed by Cost Object Mapping Framework

SAP HANA Central Finance instance

A cost object in the source system is mapped to an automatically generated cost object in Central Finance


Implementation

Realization  Implementing the Central Finance is not a “ERP-from-scratch” effort; and could be as low 10 - 15% of a traditional ERP implementation effort and duration  Most if not all business processes most likely already exist in one of the existing SAP systems and can be re-used / re-applied. Lessons learned from previous implementations can be incorporated.  The actual roll-out effort varies based on data harmonization applied, business transformation desired, and the number of systems and processes touched

Roll-out  Incremental - based on processes, business areas and source systems selected  Not a typical ERP implementation - No Big Bang !!!

Timeline  Phased in quarterly (milestone-based) increments; first roll-out possible in as little as 3 months

Skills / Resources  Basis/Admin (system setup, security setup)  Technical (HANA / HANA Live / SLT replication, ABAP)  Functional (configuration, processes, master data, data harmonization) © 2015 SAP SE or an SAP affiliate company. All rights reserved

Restrictions

 Centrally executed processes must not result in back-postings to the source systems in order to maintain the integrity (completeness etc.) and legacy system status of those systems.  The amount of configuration, customizing, and master data synchronization required in the central instance depends on the type of process desired. Many scenarios, especially core GL scenarios, are achievable with limited effort. More complex scenarios, or scenarios beyond (core GL) Finance might be challenging or in selected cases not feasible.


Summary


 Understand the motivation for the Central Finance solution  Get an overview of the Central Finance solution  Explain implementation options and requirements


Unit 1 – Agenda











Learning Objective


 Explain the different options that are offered for analytics in Simple Finance  Explain which option to use for a given use case


Scenario

You want to make sure you have a good overview of the reporting options for Simple Finance. You want to see how you can leverage your existing infrastructure but also understand what other options are available. You want to make an optimal choice for both your backend and frontend reporting and analytics tools so that you effectively report on the data posted to the system.


SAP HANA Live With SAP HANA Live, you have RealTime operational reporting directly on your S/4HANA system without any redundancy or latency.

AO

Lumira

SQL

SAP HANA Live Views


Smart Business

Reporting options + All SAP Smart Business Apps + Open architecture + 3rd party / customer UIs + Data sources from logistics etc.  No hierarchy support  User management in HANA

Performance considerations + Very lean stack + No overhead  No load balancing  Pure SQL statements Criteria to choose  Smart Business  SAP UI 5 / HTML 5 Apps  Cross area reporting  3rd party interface

Embedded BW Embedded BW directly supports:  business processes in the SAP Business Suite like integrated business planning for Finance,  analytics in the SAP Business Suite for typical SAP BW OLAP scenarios

AO

Lumira

Design Studio

Crystal Report

BW Query

Transient ODP / Virtual Provider

SAP HANA Live Views

Plan


Reporting options + Hierarchy support + User management in NW + Flexible report design in BW Query + Real-time data + Transient (on the fly) BW objects  BW technology stack Performance considerations + ABAP code injection possible + HANA optimization used + Load balancing on App Server + BW caches  BW technology overhead Criteria to choose  Operational FIN reporting  Lists, drilldown, dashboards,…  Plan / actual reporting for planning scenarios on new embedded planning architecture

SAP BW on HANA With SAP BW you can integrate, transform, and consolidate relevant business information from productive SAP applications and external data sources.

AO

Design Studio

Lumira

Crystal Report

BW Query

Virtual Provider SAP HANA Live Views SLT

ETL © 2015 SAP SE or an SAP affiliate company. All rights reserved

Reporting options + Warehousing capabilities  Not real time (best near real time)  BW Content management  BW system TCO

Performance considerations + Separation of OLAP / OLTP load  Replication overhead & load  Split of OLAP & OLTP processes Criteria to choose  Data consolidation and cleansing  Data enrichment

Backend Reporting Tool Decision matrix SAP HANA Live

ODP based reporting

Virtual Provider

BW on HANA

Usage of hierarchies (for display, selection, authorization)

++

++

++

Plan data integration (New sFIN integrated planning scenarios)

O

++

O

Cross system reporting including data harmonization

--

No End User access to DB server

++ ++

++

++

Real Time reporting

++

++

++

You are already using BW for Financials reporting

O

+

++

++

You do not yet use BW for Financials reporting

++

++

-

--

You are already using Smart Business

+

O

O

O

Report to report navigation

--

++

++

O

Access by non SAP tools

++

O

O

O

Report / selection variants

--

+

+

+

TCO/TCI

+

+

O

-

Extensibility and adaptability

O

-

-

O


Data Consumption Tools

Discovery and analysis

SAP Solution

Purpose

Discover. Predict. Create.

Dashboards and apps

Reporting

Build engaging experiences

Share information

 Discover areas to optimize your business



Deliver engaging information to users where they need it



Securely distribute information across your organization

 Adapt data to business needs





 Tell your story with beautiful visualizations

Track key performance indicators and summary data

Give users the ability to ask and answer their own questions



Build custom experiences so users get what they need quickly



Build printable reports for operational efficiency



Design Studio Analysis Pattern

Design Studio



Web Intelligence





Lumira



Dashboards (a.k.a., Xcelsius®)



Crystal Reports



Explorer



Smart Business



Fiori Analytical Applications



Analysis for Office


Frontend Reporting Tool Decision matrix

There are several distinct types of reporting, specific requirements need specific frontends. Use Case

Recommended Frontend

Customizable Alternatives

Characteristics

Interactive Drill Down

Design Studio3

AO1,2, BO Explorer2, BeX1,2, FPM Grid

Flexible analysis on any level of detail combined with easy adaptability to the customer setup

Plan data entry

Design Studio3

AO1,2, FPM Grid

Integrated plan and actuals, flexible planning levels and forms

(Work)lists

Design Studio3 or Fiori

KPI Reporting

Smart Business, executive edition

Excelsius1,2, Design Studio2

High level graphical visualization of KPIs with basic drill down capabilities, primarily for management

Explorative Ad Hoc Reporting4

Lumira2

BO Explorer2, APF

Easy to build and share graphical visualization of individual reports

Legal Reports4

Globalization Services Legal reporting tool

Formatted reporting4

Crystal reports1,2 or Adobe

1 not cloud ready

Predefined lists with focus on insight to action

Creation and management of legal reports like Securities and Exchange Commission (SEC) filings Web Intelligence2

2 separate license required


Reports with high requirements on exact formatting, anything requiring something beyond normal output management

3 limited runtime license included in Simple Finance license 4 no content shipped

Reporting Outlook for Simple Finance

Simple Finance S/4HANA Analysis Office

Design Studio

Lumira

Crystal reports

APF

Enterprise Dashboard

Smart Business

Target for Simple Finance in S/4HANA 3rd party

Fiori Apps

Design Studio

Smart Business

Fiori Apps

oDATA BW Query ExtView

ODP / Virtual Provider

SAP HANA Live Views


oDATA CDS View

Query CDS View CDS VDM Views

Links to videos for analytics tools What

Link

SAP BusinessObjects Design Studio Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYWFt-ixnVgxsUGvQpR9E8hI

SAP BusinessObjects Dashboards 4.x Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYUA748i26Z9Y0Z2dXw3s29E

SAP BusinessObjects Analysis 1.x, edition for MS Office Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYXTVP--IvbjaTJF0enYv6kK

SAP BusinessObjects Explorer 4.x Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYW9NthcmsyCMSMNwJhF6QP5

SAP BusinessObjects Web Intelligence 4.x Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYUjNLyWJR2g2U2aSWPzJBou

SAP Lumira 1.17 - 1.23 Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYWqmHlnbAB6gSQ3b39JzWLa

SAP Crystal Reports 2011 / 2013 Tutorials

https://www.youtube.com/playlist?list=PLs5htBIw ERYULWPdq3xdVb6R68Up_kCFu

SAP Smart Business Example

https://www.youtube.com/watch?v=sRjrhralEHE


Summary


 Explain the different options that are offered for analytics in Simple Finance  Explain which option to use for a given use case


Unit 1 – Agenda











Learning Objective


 Understand the importance of the user interface (UI) design  Present the technical component landscape  Explain the basic Fiori application tools


Scenario

You want to make sure your users have the best possible experience when interacting with the Business Suite. You want to ensure users can access business critical applications on any device without compromises. Finally, you want to assure the solution will integrate into your existing IT system landscape and can expand to cover your specific needs. You want to make sure SAP Fiori covers these requirements.


Great User Experience

Why focus on User Experience?

Gain productivity Increase user adoption Decrease user errors Save training costs


$

SAP Fiori User Experience Paradigm

Role-based

Decomposition into task-based experience

Responsive

Simple

Coherent

All sizes, devices, versions, channels

1-1-3 (1 user, 1 use case, 3 screens)

Apps that speak the same language


Instant Value

Low barrier to adoption

Key benefits of SAP Fiori - Improving customer’s user experience

Increase productivity

Improve time to value

Lower risk

Reduce TCO

 Employees are able to get the job done anytime, anywhere

 Faster implementation

 Implementation aligned to business value and feasibility

 Managers can streamline processes, impact business results

 Better quality assurance/reliability

 Supportability by SAP

 Reduce customization and integration complexity via SAP Fiori toolkit and rapiddeployment offerings

 Standards-based, flexible software framework

 Future-proof investment

 Apps coherent and easy to use  Additional features (example: mass approvals) to accelerate handling

 Predictable implementation timeline

 Instant roll out capabilities to different devices

 IT helps improve employees satisfaction by addressing their business needs in a timely manner © 2015 SAP SE or an SAP affiliate company. All rights reserved

 SAP validated and tested  Continuous innovation

 Lower maintenance costs  Reuse of skill sets  Intuitive usage significantly reduces learning effort and cost

Technical Architecture of Smart Business and Fiori


Fiori Launchpad – One Entry Point for the User

Role based & personal centric

Search, collaboration and feeds

Theming and branding Personalization Stable URLs for bookmarking and sharing

Multiple Platforms Multiple Devices


SAP Fiori Active Tiles, Provides the most impactful real-time information and KPIs at a glance

Fiori Launchpad User Personalization End users can personalize the tiles in their Fiori Launchpad environment.

Add new tile to catalog

Enter the Title of the new tile and threshold

Search the new tile in the catalog and add to Launchpad

 For example: The group cash manager would like to create a new Cash Position app which monitors the cash position for the German subsidiary only as that is a market of interest for him.


SAP Fiori Launchpad Designer

The Fiori Launchpad designer is the standard tool for:  Configuring the tiles for static app launchers, dynamic app launchers, and target mapping.  Creating pre-configured groups and catalogs for the Launchpad home page.  Transporting the configurations via correction requests / packages or customizing workbench.

Fiori Launchpad Designer help doc (https://go.sap.corp/fldhelp) © 2015 SAP SE or an SAP affiliate company. All rights reserved

SAP Fiori Theme Designer

An administrator uses the tool to design custom themes for the Launchpad.


Related SAP Links

Where

What

Link


Note 2117719 Release Information Note: SAP Fiori for the SAP Simple Finance On-Premise Edition 1503

https://css.wdf.sap.corp/sap/suppo rt/notes/2117719


Demos & Exercises

Activity

Name

EXERCISE 4 CUSTOMIZE YOUR LAUNCHPAD AND MANAGE CUSTOMER ITEMS


Page EX-35

Summary

You should now be able to:  Understand the importance of the user interface (UI) design  Present the technical component landscape  Explain the basic Fiori application tools


Unit 1 – Agenda











Learning Objective

After completing this lesson, you will be able to: •

Understand the possible starting points for migration

•

Give a brief overview of the migration process


Scenario

You are currently running a system on classic G/L, new G/L, or Simple Finance 1.0 and want to upgrade to use the functionalities of the latest version of the Simple Finance add-on. You want to know if your current system configuration meets the prerequisites and what kind of changes will you need to prepare for.


old Asset Accounting

old Asset Accounting

new Asset Accounting

Data Takeover

Simple Finance 1.0 (New GL, new Asset Accounting) Installation & SFIN Migration

New GL,

Installation & SFIN Migration

New GL,


Classic GL,


New SAP customer – Accounting in NonSAP System

From where can I migrate to Simple Finance?

SAP Accounting in Simple Finance On-Premise Edition 1503

New SAP customers starting with SAP S/4HANA will take over their legacy data using classic migration tools. The SAP Simple Finance migration tools work only for existing customers/system. Depending on the active applications in the source system, different preparation steps are relevant. The description can be found in the SAP online help.


Migration to the Simple Finance Add-On is Fast and Easy

 The duration and effort is relatively small. It can be executed at any period end.  It is supported by a migration guide and monitor.  No New G/L (or other) Migration Service is needed to migrate to SAP Accounting powered by SAP HANA  Migration scope is comparable to migration to new G/L scenario 1 (Merge of the FI ledger)  Changes to coding blocks, external interfaces, security, reporting etc. are optional


Classic General Ledger Migration Constraints

Migration to Accounting on HANA from a classic G/L setup does not support the following scenarios: •

Implementation of Document Splitting

•

Balance Sheets at the Profit Center Level

•

Migration from Special Purpose Ledger to New General Ledger Accounting

•

New Implementation of Parallel Accounting

•

New Implementation of Segment Reporting

•

Implementation of the Ledger Approach for Parallel Accounting

•

Change in Chart of Accounts and Conversion of Chart of Accounts

•

Inclusion of Customer Fields

•

Transfer of Quantities to New General Ledger Accounting

Note: If you have started or are in the planning phase to start a migration to new GL using the SAP General Ledger Migration Service, SAP recommends that you complete the new GL migration project before installing the Simple Finance Add-On.


Length of the Migration Project It is not possible to make an exact statement here. Factors that could influence the duration: •

Support from the customer themselves (how many people, how quickly can you set up a test system etc.)

•

Experiences of project members and consultants

•

Quality of data, size of the system etc.(Migration of a system with goLive 2013 might obviously be easier than a system with goLive 1996.)

•

A delta migration scenario is planned to optimize (minimize) downtime.

The first test migration will give a good first impression for the duration and potential setbacks during the migration project


Sequence in Test and Productive Environment

Import

Test/Development System Installation of SAP Simple Finance Add-on

Customizing for Migration

Checks:

Installation of:

Customizing for:

•

Cost Elements

•

Cold Store

•

Data comparison

•

•

•

General Ledger

•

•

Reporting checks

Asset Accounting

•

Process tests

•

Line Items

Add further information to documents

•

•

Enrich items/ documents

•

Balances

System Preparation Phase

Pre-checks

•

SAP Simple Consistency & Finance AddData Clean-up On Custom Code • HANA Live

•

Closing:

•

Activities

•

Reporting

•

•

•

Controlling

Fiori


Data Migration

PostMigration Activities

Data Checks and Process Tests

Migration Check Completeness

C o p y

Imports

Preparation

Uptime

Installation

DOWNTIME

Productive System

Summary

You should now be able to: • Understand the possible starting points for migration • Give a brief overview of the migration process


Unit 3: General Ledger Accounting


Unit 3 – Agenda

GL Accounts and Cost Elements in SAP Accounting powered by HANA Managing Ledgers in SAP Accounting powered by HANA


GL Accounts & Cost Elements in SAP Accounting powered by HANA


Learning Objective

After completing this lesson, you will be able to:  Understand the new master data maintenance model  Explain the handling for Asset and Material accounts  Understand the impact on authorizations and the posting period lock


Scenario

You have traditionally kept G/L Accounts separate to your Cost Elements. With the move to Simple Finance you will now only maintain G/L accounts, you want to understand how this works on the system architecture level and also how this might impact your processes for master data maintenance and other transactions.


Classic Data Model for the Master Data G/L Account and Cost Element Management Accounting Cost Elements (Chart of Account) CSKA MANDT KTOPL KSTAR

Financial G/L Account Master Accounting (Chart of Account) SKA1 MANDT KTOPL SAKNR

Cost Elements (Controlling Area) CSKB MANDT KOKRS KSTAR, DATBI

G/L Account Master (Company Code) SKB1 MANDT BUKRS SAKNR

Cost Elements (Description) CSKU MANDT SPRAS KTOPL, KSTAR

G/L Account Master (Description) SKAT MANDT SPRAS, KTOPL SAKNR

Creation of cost elements updates the tables CSK*. Creation of G/L accounts updates the tables SK*. For CO relevant external postings you need both master data records. © 2015 SAP SE or an SAP affiliate company. All rights reserved

New Data Model for both Master Data in SAP Accounting SAP Accounting Cost Elements (Chart of Account) CSKA Fields: MANDT KTOPL KSTAR

G/L Account Master (Chart of Account) SKA1

NEW FIELD

Fields: MANDT KTOPL, SAKNR GLACCOUNT_TYPE

Cost Elements (Controlling Area) CSKB Fields: MANDT KOKRS KSTAR, DATBI

G/L Account Master (Company Code) SKB1 Fields: MANDT BUKRS SAKNR

Cost Elements (Description) CSKU Fields: MANDT SPRAS KTOPL, KSTAR

G/L Account Master (Description) SKAT Fields: MANDT SPRAS, KTOPL SAKNR

Only one master data record is required: the G/L account. G/L accounts from type ‘Secondary Costs or Revenues’ update all CSK* and SK* tables! © 2015 SAP SE or an SAP affiliate company. All rights reserved

Cost Element Categories for G/L Accounts from Type ‘Primary Costs or Revenue’

The cost element category specifies which transactions can use this cost element.


Cost Element Categories for G/L Accounts from Type ‘Secondary Costs’

Accounts of type ‘Secondary Costs’ can be used only for internal CO allocations.


Cost Element Category 90 for Balance Sheet Accounts in Financial Accounting “Statistical” cost elements of category 90 are created automatically when: 1) You create a Balance Sheet G/L Account. 2) The Account Group is one used for fixed asset or material accounts. 3) The account is a reconciliation account for assets or material. 4) The accounts have been setup in the Asset or Material management account assignment. 5) You select the checkbox “Apply Acct Assignments Statistically in Fixed Asset Acct / Material Acct”.


Account Determination for Asset and Material Accounts  You add the account in the Asset account assignment in the field “Bal. sheet account: Acquisition and production costs” (T095-KTANSW).

 For a material account you can check, if this account is defined as a material account in Customizing under Configure Automatic Postings. Choose Goto  Account Assignment. Here you choose the line ‘Inventory posting’. On the next screen there should be an entry for your account for the relevant valuation modifier and valuation class.


Impact on Default Account Assignment

In SAP Accounting a default account assignment can be defined only using transaction OKB9 or through substitution rules. Default account assignments maintained in former cost element master data are migrated to transaction OKB9 as part of the migration process.


Impact on Authorizations

The merge of cost elements and G/L accounts requires adjustments to authorizations for creating cost elements:  If you want to maintain accounts of the account type Primary Costs or Revenue, you need to have authorization to create or change cost element master data.  If you want to maintain accounts of the account type Secondary Costs, you need to have authorization to create or change G/L accounts.

To check or change the authorizations, use transaction PFCG. The standard delivered SAP Role is: FUCN_GL_ACCOUNTANT (G/L Accountant) The relevant authorizations are:     

Controlling, CO-CCA: Cost Element Master (K_CSKB) Financial Accounting, G/L Account: Change Authorization for Certain Fields (F_SKA1_AEN) Financial Accounting, G/L Account: Account Authorization (F_SKA1_BES) Financial Accounting, G/L Account: Authorization for Company Codes (F_SKA1_BUK) Financial Accounting, G/L Account: Authorization for Charts of Accounts (F_SKA1_KTP)


Effect on Period Lock In SAP Accounting CO relevant postings do not check only the CO Period Lock as in the past but as well the GL period opening/closing. Therefore you have to allow postings to accounts from account type ‘Secondary Costs‘ in the GL period opening/closing. Period Lock FI in SAP Menu Financial Accounting


Period Lock CO in SAP Menu Controlling

Period Lock in CO In CO you need to specify which transactions you want to lock, and for which periods. Example: you lock periods 1 and 2 against actual overhead assessment postings. All other postings in this periods are allowed!


Period Lock in FI In FI you need to specify which accounts for a specified account type you want to allow for postings, and for which periods and fiscal years. Example: you allow postings for all G/L accounts (account type S) for a specified timeframe. All other postings (other accounts or periods) are not allowed! In SAP Accounting it is also necessary to open accounts from account type Secondary Costs for FI postings.


Fiori Application for Period Lock

In the Fiori application you can in addition lock the period per ledger, especially useful for working with appendix ledgers. A single unified maintenance should be available in the future.


Demos & Exercises

Activity

Name

Page

DEMO 2

HOW TO CREATE A PRIMARY COST ACCOUNT

EX-55

EXERCISE 5 CREATE A SECONDARY COST ACCOUNT

EX-63

DEMO 3

EX-69

HOW TO CREATE AN ASSET ACCOUNT AS A STATISTICAL COST ELEMENT

EXERCISE 6 CREATE A DEFAULT ACCOUNT ASSIGNMENT

EX-75

DEMO 4

EX-81

HOW TO USE THE PERIOD LOCK TRANSACTIONS


Summary

You should now able to:  Understand the new master data maintenance model  Explain the handling for Asset and Material accounts  Understand the impact on the posting period lock


Unit 3 – Agenda

GL Accounts and Cost Elements in SAP Accounting powered by HANA Managing Ledgers in SAP Accounting powered by HANA


Managing Ledgers in SAP Accounting powered by HANA


Learning Objective

After completing this lesson, you will be able to:  Understand the enhancement to Ledgers with the Universal Journal  Configure Ledgers in SAP Simple Finance


Scenario

You manage multiple parallel accounting principles in your system and need to be able to report on each separately. You also are afraid that with the universal journal, the previously independent components lose some of their flexibility being bound by the legal restrictions of financial accounting. You want to understand the Ledger capabilities with SAP Simple Finance and be able to configure ledgers to meet your needs.


The Universal Journal enforces discipline

G/L

“Periods cannot be open and closed at the same time”

“I have to close the fiscal period” Universal Journal

CO

“I want to post despite closed periods in G/L” © 2015 SAP SE or an SAP affiliate company. All rights reserved

“I have to close the fiscal period”

How can we offer flexibility in our solution without reintroducing a reconciliation issue?

Requirement: Unified and flexible solution

Extension e.g. for specific management adjustments or realignments

“Appendix”

Unified FI and CO (e.g. according to IFRS) “Standard” (”Base”)

 “On top” - usually manual postings.  Report on extension always includes the embedded “Standard” to provide the full picture  Less strict rules (e.g. different period lock)  Use of standard FI/CO UI’s and reports.  “Appendix” authorization needed .

 “Regular” universal journal entries serving FI, CO, AA, ML, with e.g. IFRS valuation.  Posting of consistent standard processes.  Strict standard rules (e.g. standard period lock) have to be obeyed

Several extensions possible to one “base”: More flexibility than previously through FI and CO separation


Appendix Ledger – Basic Idea Each specific ledger is self contained, has a special purpose and provides a specific view on financial data. A ledger usually stores a lot of redundant data to other ledgers. With Appendix Ledgers you can “staple” ledgers on top of each other, providing the different views you need. This minimizes the data footprint and provides new flexibility for easily creating additional views.


Appendix Ledger – Use Cases Universal Journal

Appendix Ledger A “Post into closed periods for restatement purposes”

Appendix Ledger B “Distribute revenues differently on org units than in legal view”

Appendix Ledger C “Adjustments for consolidation purposes”

 An appendix ledger stores delta values and points to another ledger – thus providing a flexible mechanism for adjustments and reporting.  An important use case is for management views on top of legal data.  Besides creating a master record, appendix ledgers need no additional configuration.  Reporting on the appendix ledger always includes the data of the base ledger (in the figure: IFRS ledger).  Multiple appendix ledgers can point to the same base ledger.  Benefit of reduced data footprint and zero reconciliation effort as only delta values are kept.

Ledger IFRS Ledger Local GAAP


 Appendix ledgers are stored in the universal journal – same as “normal” ledgers.

The transaction data is “mapped” to the corresponding Ledger © 2015 SAP SE or an SAP affiliate company. All rights reserved

View for Data Selection

Persistence

Technical implementation of the read access

Postings into the Appendix Ledger

ACDOCA

 ACDOCA stores the data for all appendix ledgers.  BSEG does not store any appendix ledger data.

CO: KB11N PCA

RWIN FI: FB01L FI-SL


 Implementing the BADI BADI_FINS_APPL_RELEVANCE allows to feed components like PCA, FI-SL, EC-CS with the data posted to appendix ledgers. This functionality should be handled with care. It is up to the implementation in the BADI to clearly separate appendix ledger data from the other data.

The new and the old Ledger master  The Universal Journal ledgers have own master records  The new master record key FINSC_LEDGER-RLDNR is technically compatible with the FI-SL/New G/L ledger key (T881-RLDNR)  The FI-SL technology is used in a lot of components (FI-SL, EC-PCA, New G/L, Public Sector etc.).  Parts of this technology has been enabled for the Universal Journal ledgers. Both “worlds” can be mapped e.g. via the function modules G_GET_LEDGER_INFO and G_GET_ORGANIZATIONAL_DATA. The modules have a compatibility mode that might help customers to leverage their own code for Universal Journal ledgers.


Document Summarization

BSEG

MM

Document Summarization

SD Accounting Interface

HR

ACDOCA

…


 BSEG summarization works and can be used as usual. BSEG is used for storing open item and clearing details, thus you can be quite aggressive with the summarization.  ACDOCA stores the full detail that is needed for all components that base on ACDOCA (G/L, AA, ML, CO, PA).  Summarizing BSEG “aggressively” will bring relief with respect to the 999 line item limitation (BSEGBELNR has only 3 digits). This can be done, since ACDOCA stores the full detail and ACDOCA has a 6 digit field for line item numbering.

Master Data Maintenance for Ledgers

Transaction: FINSC_LEDGER First Level: Master Data of Ledger  Define the Leading Ledger  Define additional Ledgers, Standard or Appendix  Set a Ledger as Base Ledger only for the Appendix Ledgers


Company Code Assignment to Ledgers Second Level  Company Code Assignment to Ledger  For the Leading Ledger: – All Company Codes are assigned. – Company Code Assignments for Leading Ledgers are defaulted in the view maintenance. Do not forget to save the defaulted entries.


Company Code Settings for Ledgers Second Level – Detail Screen – Currency Settings  Local Currency – ACDOCA-Field HSL – All settings are fix

 Global Currency for GL & CO – ACDOCA Field KSL – Curr. type of controlling area – Special case: only rel. In CO Curr. type not used in FI

 1st additional Currency – ACDOCA Field OSL – Leading Ledger defines settings – Non-Leading Ledgers inherit settings

 2nd additional Currency – ACDOCA Field VSL – Only available in the special case you saved the object currency in CO.


Additional Company Code Settings for Ledgers Second Level – Detail Screen – Other Company Code Settings  Fiscal Year Variant – In the leading ledger is inherited from the controlling area setting – Non leading ledgers may have deviating fiscal year variants

 Posting Period Variant – Defines open periods – Basis for check of leading ledger / representative ledger in ledger group

 Parallel Accounting using G/L Accounts – Flag switches off the check, that Ledger / Company is assigned to max. one Accounting Principle


Assignment of Accounting Principle to Ledgers per Company Code Third Level  Assignment of Accounting Principle to Ledger / Company Code  By default you assign one Accounting Principle per Ledger / Company, unless you use Parallel Accounting with the GL Account Approach.


General Ledger Technical Changes compared to new GL

FAGLFLEXA

FAGLFLEXT

ZZT

ACDOCA ZZA

T

A


 Data previously stored in FAGLFLEXA, FAGLFLEXT (carry forward) is now stored in table ACDOCA.  Data of New G/L industry tables for Public Sector and Joint Venture Accounting ( FMGLFLEXA/T, PSGLFLEXA/T, JVGLFLEXA/T) is now stored in table ACDOCA.  Data of customer created New G/L tables ZZT, ZZA is now stored in table ACDOCA.  A compatibility view is provided for table FAGLFLEXA: FGLV_FAGLFLEXA. This compatibility view redirects select statements to FAGLFLEXA to ACDOCA.  Compatibility views for the New G/L industry tables are provided: V_A, V_T  Compatibility Views are provided for customer created New G/L tables. The views are numbered sequentially: ZFGLV_GLTT_Cx (totals) and ZFGLV_GLSI_Cx (line items), where x is a number.

Demos & Exercises

Activity

Name

Page

DEMO 2

POST SECONDARY COST TO FINANCIAL ACCOUNTING

EX-91

EXERCISE 5 CREATE AN APPENDIX LEDGER AND POST A DOCUMENT TO IT


EX-105

Summary

You should now able to:  Understand the enhancement to Ledgers with the Universal Journal  Configure Ledgers in SAP Simple Finance


Unit 4: Asset Accounting


Unit 4 – Agenda

Providing an Overview of new Asset Accounting Functions

Analyzing the Posting Logic of new Asset Accounting

Configuring new Asset Accounting




Learning Objective

After completing this lesson, you will be able to:  Outline the features of new Asset Accounting in SAP Accounting powered by SAP HANA


Scenario

You want to find out more about new asset accounting to understand if there are benefits beyond the fact that it is a requirement for the SAP Simple Finance OnPremise Edition.


New Asset Accounting and SAP Accounting on HANA

 New Asset Accounting is the only Asset Accounting solution in SAP Accounting on HANA, classic Asset Accounting is not available any more

 Configuration and activation is on the client level.  Both multiple valuation approaches are possible: Ledger Approach and Account Approach  Usage of the new Depreciation Calculation Engine is mandatory (based of extension EAFIN)


Technical Changes to the Tables Actual items ANEK

ANEP

ANEA

BKPF ACDOCA

ANLP

ANLC

 Actual data of ANEK, ANEP, ANEA, ANLP, ANLC is now stored in table ACDOCA. ANEK data is stored in BKPF.  Compatibility views FAAV_ (e.g. FAAV_ANEK) are provided to enable non-disruptive reporting on old tables  After migration: access to content of old tables is still possible via views FAAV__ORI.

Non actual items:

FAAT_DOC_IT FAAT_PLAN_VALUES FAAT_YDDA


 Statistical data (for example calculation for tax purposes) are now stored in table FAAT_DOC_IT.  Plan data (previously ANLP and ANLC) are now stored in FAAT_PLAN_VALUES  Year-dependent attributes of Fixed Assets are now stored in FAAT_YDDA.

Benefits from the Universal Journal integration

Fixed Asset Accounting based on Universal Journal:  No redundancy in data storage  Reconciliation between G/L and AA is ensured by design – No reconciliation-step in financial close needed anymore. – All non-statistical items are updated as Universal Journal Entries.

 Even after migration, reporting for previous fiscal years is possible due to compatibility views.  Transparent assignment of depreciation area to accounting principle  Depreciation posted with all details: Accumulated depreciation and depreciation cost by asset


Benefits from Posting Logic Simplification

Auditability and simplicity:  Independent and complete depreciation areas of equal power – Simplified Chart of Deprecation: Only one depreciation area per valuation necessary – no further depreciation areas (Delta areas) necessary to portray a parallel valuation

 New document display: explain the detailed impact of any transaction to the books  New transactions for ledger group (depreciation area) specific documents  Flexible account determination


Benefits from Changed Closing Processes

Simple close, fast close, soft close: Transparency throughout the period  Asset balances in real time - APC posting run not needed anymore  Plan values in real-time – updated with every master data change and every asset transaction.  Elimination of reconciliation steps  Fast depreciation posting run due to simple processing logic, new data structures and parallel processing  Navigation and drilldown per accounting principle  Posting to different periods possible (restriction: beginning/end of FY needs to be equal)


Out of Scope for new Asset Accounting

The new architecture prerequisites are  Usage of the New Depreciation Calculation Engine is mandatory

The new architecture does not support the following feature (and vice-versa)  Joint Venture Accounting (JVA) (officially released for ledger-solution via Business Function as of EhP6) (1)  Lease Accounting Engine (LAE)  Real Estate Classic (RE Classic)  Public Sector Management – Funds Management (PSM-FM) using requests (2)  Application Link Enabling (ALE): transfer of assets  Transaction “Post transfer between depreciation areas” (ABUB)

(1)

Will be investigated to be supported in a future support package

(2)

A check is necessary to see if new Asset Accounting can be used with installed industry components


Demos & Exercises

Activity

Name

EXERCISE 9 CREATE ASSETS


Page EX-112

Summary

You should now be able to:  Outline the features of new Asset Accounting in SAP Accounting powered by SAP HANA


Unit 4 – Agenda







Learning Objective

After completing this lesson, you will be able to:  Understand the posting logic in new Asset Accounting


Scenario

You want to understand the changes implementing new Asset Accounting brings for your end-users. You want to understand the posting logic with new Asset Accounting to be able to explain and use it.


Posting Logic in new Asset Accounting

Universal Journal

The system generates several documents:  The Operational Entry Document posts to a technical clearing account. The Operational Entry Document does not update the asset values, the asset data is only used to perform checks.  Accounting principle specific documents (1 to n). The accounting principle specific documents post to: – the technical clearing account in each view (balancing to zero) – the asset reconciliation account (and update the asset line items) © 2015 SAP SE or an SAP affiliate company. All rights reserved

Sample Posting – Ledger Approach

Both depreciation areas 01 and 30 will be posted to in real-time *

* Screenshot is a combination of two simulated entries

Result: 3 documents (Technical Clearing Account Acquisition = TCA)  TCA to Vendor (Ledger group blank and Account. principle blank)  Asset to TCA (Ledger group 0L and Account. principle IFRS)  Asset to TCA (Ledger group N1 and Account. principle LOCA)


Sample Posting – Account Approach

Both depreciation areas 01 and 30 will be posted to in real-time *

* Screenshot is a combination of two simulated entries

Result: 3 documents (Technical Clearing Account Acquisition = TCA)  TCA to Vendor (Ledger group blank and Account. principle blank)  Asset to TCA (Ledger group 0L and Account. principle INT)  Asset to TCA (Ledger group LO and Account. principle LOC)


Example: Integrated Acquisition with different amounts per Accounting Principle

AP Reconcilation

Tech.Clear.Acc.Acqu.

1) 10.200

1) 10.200 2a) 10.200

Asset Reconcilation.

Freight expenses

2a) 10.200

LGAAP

Asset Reconcilation

1) 10.200

1) 10.200 2b) 10.200

IFRS

2b) 10.200 3)

200

3) 200

Transaction vendor invoice 1) “Technical Clearing Account Acquisition to Vendor” ledger group and accounting principles Blank

2a)“Asset to Technical Clearing Account Acquisition” ledger group and accounting principle IFRS 2b)“Asset to Technical Clearing Account Acquisition” ledger group and accounting principles LGAAP

Transaction correction freight cost 3) “Freight expenses to Asset” ledger group LGAAP


Additional Information on Integrated Posting

 The technical account always balances to zero.  The operational entry document will be posted by the entered document type, the rest can be posted under a different document type (for example AA)  Accounting Principle specific documents will always be created  Using different reconciliation account per accounting principle is possible  Technical clearing account will be always posted, even if a certain accounting principle is not represented on the asset*.

* There is a small difference between ledger and account solution. The account “Contra account: Acquisition value posting” assigned in the account determination will be posted to instead of the Technical Clearing Account for secondary depreciation areas in the accounts approach. © 2015 SAP SE or an SAP affiliate company. All rights reserved

Assets activated for specific accounting principles

Behavior during integrated asset acquisitions after deactivation of non-required depreciation areas:

The screenshot is a combination of two simulated entries © 2015 SAP SE or an SAP affiliate company. All rights reserved

Assets activated in only some accounting principles e.g. in-house developed software  Only relevant accounting principles need to be represented on the asset (or on the asset class) by their corresponding depreciation areas  All postings issued within FIAA will only affect those accounting principles which are relevant for the involved asset(s).  P&L postings for all other accounting principles can be handled manually by the end user.  If a certain accounting principle is not represented on the asset by an area which posts APC online to general ledger, the posting will be re-directed to “Account for non-operating expense“ (field T095-KTNAIB)  If no accounting principle is represented on the asset by an area which posts APC online to GL, the system issues an error. This error message can be changed into a warning, in which case the statistical areas in FI-AA are updated.


New Settlement for Assets under Construction

 It is possible to assign the settlement rule for each line per depreciation area posting to the general ledger (transaction AIAB).  Accounting principle specific postings are generated from Controlling as well.


New and obsolete programs for FI-AA Changes after installation of SAP Simple Finance On-Premise Edition 1503:  Periodic APC postings: – RAPERBxxxx – obsolete and deleted

 Reconciliation postings: – RAABSTxxxx – obsolete and deleted

 Post depreciation – RAPOSTxxxx is replaced by program FAA_DEPRECIATION_POST


Calculating and Posting Depreciations The determination of the depreciation values of an asset and the posting of depreciation expense takes place in the system asynchronously: 1. Calculate depreciation:  The planned depreciation is determined with each master record change and with each posting on the asset and updated in the database directly.

2. Post depreciation:  The depreciation run adopts the planned asset values and posts them in Financial Accounting.


New Depreciation Run How does the depreciation run work?  Planned depreciation is determined and updated with each asset master record change and each posting to the asset.  The depreciation run posts the pre-calculated planned values.  The journal entry is updated in financials on the asset level.  Period end closing can be performed even if there are errors on individual assets.  A test run can be performed but still with the restriction for 1000 assets.  The Selection screen is simplified as the “reasons for posting run” (planned depreciation run, repeat, restart, unplanned posting run) are no longer relevant.  .


No longer relevant

Simplified Selections

Further Topics Year end closing:  There is no separate balance carry forward needed in asset accounting, the general balance carry forward transaction of FI transfers asset accounting balances by default.  The most current planned depreciation values will be calculated automatically for the new year after performing the balance carry forward.

Resetting data (test data):  Resetting data in asset accounting should only be performed in case all Accounting data will also be reset.


Demos & Exercises

Activity

Name

Page

EXERCISE 9

CREATE ASSETS

EX-112

EXERCISE 10 POST INTEGRATED ASSET ACQUISITIONS

118

EXERCISE 11

POST A PARTIAL SCRAPPING TO AN ASSET

133

DEMO 5

EXECUTE A DEPRECIATION POSTING RUN AND ANALYZE THE LOG

139

EXERCISE 12 MANAGE DEPRECIATION RUNS


147

Summary

You should now be able to:  Understand the posting logic in new Asset Accounting  Explain Period-End process


Unit 4 – Agenda







Learning Objective

After completing this lesson, you will be able to:  Understand the customizing of New Asset Accounting  Perform the customizing for New Asset Accounting


Scenario

Asset Accounting (new) has to be configured in your system with Simple Finance On-Premise Edition 1503. You need to be able to understand and execute the additional and changed customizing steps in new Asset Accounting.


Required Customizing for New Asset Accounting

The following customizing steps and checks are required:  Check and create accounting principles and ledger groups.  Assign accounting principles to ledger groups for both approaches: – Ledger Approach – Account Approach

 For every additional currency type defined on the company code a corresponding depreciation area needs to be set up.  Account approach: Define Asset Balance Sheet Accounts of Parallel Valuation as Reconciliation Accounts.  Define account “technical clearing account” for integrated asset acquisition.


Optional Customizing for New Asset Accounting

The following customizing steps and checks are required:     

Quantity update: define depreciation area. Integrated transactions: specify alternative document type for ledger postings. Choose between revenue distribution for retirement by APC or net book value. Post net book value instead of Gain/Loss during retirement. Make any Transaction Types that post to specific depreciation areas obsolete.


New Asset Accounting in Preparation Status for New Asset Accounting has to be “In Preparation”

IMG: Asset Accounting (New) -> Migration Asset Accounting (New) -> Activate Asset Accounting (New)


Chart of Depreciation All depreciation areas representing the same accounting principle will be assigned to the same accounting principle (and ledger group):


Explanation of the Parallel Valuation Approaches Companies often reports the following accounting regulations:  International GAAP  Local GAAP  Tax GAAP

There are different objects to indicate these requirements:  Valuation areas (FI) are used for: – Closing activities like Foreign Currency Valuation, Sorting/Reclassification (New) or Further Valuations

 Accounting Principles are used for: – The New Asset Accounting to combine different depreciation areas to a accounting principle – Accrual Engine

 Ledger Groups are used for: – Manual postings in FI (e.g. FB50L Enter G/L Account Document for Ledger Group) – Manual postings in CO (e.g. KB11N Manual Reposting of Costs)


Explanation per Approach to Parallel Valuation  Account Approach:

 Ledger Approach:

 All objects are linked via customizing. Combinations of n ledgers to one ledger group is possible, e.g. to post IFRS and US-GAAP together


Depreciation area assigned settings

 You have to assign an accounting principle to each depreciation area, even to non-posting depreciation areas or to delta depreciation areas that are only for reporting. (The accounting principle is not allowed to be initial (blank).)  You can assign the same accounting principle to several depreciation areas, as long as the areas represent the same valuation.  For every additional currency type defined on the company code level, a corresponding depreciation area needs to be configured.


GL Update Settings for Depreciation Areas With Asset Accounting (New), the Posting Indicator supports five (4) different values. For the depreciation areas the Posting Indicator need to be adjusted.  The leading area of the leading valuation always contains the Area Posts in Realtime option.  The following applies to the ledger approach: The leading area of the parallel valuation also contains the Area Posts in Realtime option.  The following applies for the accounts approach: The leading area of the parallel valuation receives the option Area Posts APC Immediately, Depreciation Periodically (or Area Posts APC and Depreciation Periodically).


Adapt value take over and parameter take over

Value take over can only be done within a set of depreciation areas which are assigned to the same accounting principle. Leading areas need to be set to 00. © 2015 SAP SE or an SAP affiliate company. All rights reserved

Reconciliation Accounts (only for Account Approach) There is a program to automatically switch all accounts of parallel valuations to reconciliation accounts:


New account technical clearing account for integrated asset acquisition Characteristics of the new account “technical clearing account for integrated asset acquisition” as balance sheet account:

Balance behavior:  Ledger Approach: Always balances to zero per ledger group and account assignment.  Account Approach: Always balances to zero together with the account “Contra account: Acquisition value posting” in your financial statement.

Is defined as a reconciliation account, but not managed on line items. Different “technical clearing account for asset acquisition” for specific account determination are possible, e.g. to set different field status like for the text field.


Quantity Update Define depreciation area for quantity update:  In the asset master data the quantity will only be updated in case a posting is performed to the depreciation area  In case this IMG activity is not manually maintained, the system will by default update the quantity when a posting is made to depreciation area “01”


Document types for integrated transactions It is possible to indicate a different document type to be used by the system for the automatically generated accounting principle specific documents in asset accounting on the client level (use of document split can be a reason or external number ranges for FI-documents used by logistics invoice verification.

or on the company code level:


Revenue distribution for retirement by APC or net book value for mass retirement

 In this step, you specify at company code level how the system is to distribute revenues arising from asset retirements: either based on the net book value or on APC. In the standard system, the distribution is based on the net book value.  Check the distribution of revenue for your company codes, and adjust the distribution to meet your requirements.  Customizing Menu Path: IMG: Asset Accounting (New) -> Transactions -> Retirements -> Gain/Loss Posting -> Define Revenue Distribution for Fixed Asset Retirement


Post net book value instead of Gain/Loss

 In this step you specify that you want the system to post the net book value of an asset being retired to the account "Clearing of revenue from sale of assets" and "Clearing or revenue from internal sale". No profit/loss (from sale) or loss from asset retirement (after scrapping) is then posted.  Post Net book value (e.g. legal requirement in France – French Retirement): IMG: Asset Accounting (New) -> Transactions -> Retirements -> Gain/Loss Posting -> Post Net Book Value Instead of Gain/Loss  The restriction of the posting logic to certain depreciation areas was done in classic Asset Accounting using area types.


Check Transaction Types  In new Asset Accounting, it is not possible and also not necessary to restrict transaction types to depreciation areas. You restrict posting to a depreciation area or accounting principle directly in the posting transaction.  If you were using transaction types that were restricted to certain depreciation areas, then you can no longer use these transaction types. Check whether your existing transaction types that are not restricted to depreciation areas are sufficient. Investment support and also revaluation and new valuation are an exception.

Exceptions:  The transaction types for investment support and revaluation are automatically generated by the system when you create a corresponding measure, and therefore are restricted to the depreciation area to be posted to.  The transaction types for revaluation and new valuation that relate to transaction type group 81/82/89 can continue to be restricted to depreciation areas.


Marking Transaction Types as Obsolete  A task only required when migrating an existing system.  All transaction types, restricted to depreciation areas, should be set to obsolete.  Do not delete it.


Summary

You should now able to:  Understand the customizing of New Asset Accounting  Perform the customizing for New Asset Accounting


Unit 5: Management Accounting


Unit 5 – Agenda

Understanding the new Architecture of Management Accounting Understanding the Material Ledger and Cost of Goods Sold handling in SAP Simple Finance Explaining Profitability Analysis in SAP Simple Finance Outlining new Period Closing Programs for Management Accounting


Understanding the new Architecture of Management Accounting


Learning Objective

After completing this lesson, you will be able to:  Understand the Architecture for Management Accounting  Perform customizing for Management Accounting


Scenario

You want to understand how the Financial and Management Accounting harmonization works in SAP Simple Finance. You also need to understand what new customizing activities are required for the new architecture to work.


Controlling – Technical Changes with SAP Simple Finance Actual Items COBK

BKPF COEP

ACDOCA COSP_BAK

COSS_BAK

 Actual data of COEP (Value Types ‘04’ Actual and ‘11’ statistical actual) is stored in ACDOCA  Required actual data for long running orders/projects from COSP_BAK, COSS_BAK is stored in table ACDOCA.  Currently, the header table COBK is written as before. The target is to replace COBK through BKPF.  Compatibility views V_ (e.g. V_COEP) are provided in order to reproduce the old structures.  Access to data in the old tables is still possible via the views V__ORI (e.g. V_COEP_ORI)

Non-actual items  Value types other than ‘04’ and ‘11’ are still stored in COEP, COSP_BAK, COSS_BAK © 2015 SAP SE or an SAP affiliate company. All rights reserved

CO Compatibility Views Provide Non-Disruptiveness

 In the figure, an example access to table COEP is redirected via the view V_COEP to the new Universal Journal Entry.  Any custom ABAP programs that read table COEP directly via select statements continue to run as before . © 2015 SAP SE or an SAP affiliate company. All rights reserved

CO Postings without specifying ledger groups

“ACDOCA”

“BSEG”

CO

Accounting Interface

PCA

FI-SL

EC-CS

Cost Based COPA


 ACDOCA is posted via the Accounting Interface similarly to FAGLFLEXA (New G/L) in the past. ACDOCA stores full detail.  Former COEP, FAGLFLEXA, ANEP, MLIT etc. data are stored in ACDOCA.  BSEG is only written in case open item managed accounts are affected (e.g. usually for cross company postings).  PCA, FI-SL work as before. Where the FI-SL was posted via activity “COFI” (real time integration CO-FI), now secondary cost (G/L accounts) are posted directly and there is no mapping to a primary cost element.  EC-CS as before with New G/L real time integration, but now including secondary cost (G/L accounts). The system works directly with the original CO activities like RKU1 instead of using the activity “COFI”.  Cost based CO-PA works as before (with the SAP HANA accelerators of course).

Document type and Ledger Groups in Controlling  With Simple Finance CO processes are enabled to post into ledger groups and you can also specify the document type.  On the UI this is enabled for KB11N, KB41N and KB15N. Other processes can be configured in the IMG to post with ledger groups.


CO Postings when specifying ledger groups

“ACDOCA” Filter: ledger group contains “leading ledger”

CO

Accounting Interface

“BSEG”

PCA

FI-SL

EC-CS

Cost Based CO-PA


 ACDOCA is posted in any case taking the respective ledgers into account.  BSEG is only written in case open item managed accounts are affected (e.g. for cross company postings) and the ledger group contains the leading ledger.  Other components (PCA, FI-SL, Cost Based CO-PA, industry solutions like public sector and joint venture accounting etc.) are only posted, if the ledger group contains the leading ledger. The BADI BADI_FINS_APPL_RELEVANCE allows customers to overrule this behavior.

General Management Accounting Customizing  Align Fiscal Year Variants between controlling areas and the assigned company codes.  Define the document type for CO postings.  Define one or more Document Type Mapping Variants (pre-delivered: 000001) and assign these to the company codes.  Specify default ledger group – Ledger group is only for manual re-postings on the UI (KB11, KB41) – If no ledger group is entered in CO transactions the default ledger group is taken. – If no default ledger group is configured all ledgers are updated

 Define Intercompany Clearing Accounts for CO cross company postings


Check and Adopt Fiscal Year Variants  The Fiscal Year Variants of all productive controlling areas and their assigned company have to be the same.  Example 1 FI: K4 Cal. Year, 4 Spec. Periods / CO: K1 Cal. Year, 1 Spec. Period

 Example 2 FI and CO: both Cal. Year, 4 Special Periods, but different keys


Define Document Types for Postings in Controlling  This activity is the same one used in Financial Accounting to create document types. Controlling now uses document types when posting to FI as well. It is recommended to have a separate document type for Controlling postings with only the indicator “G/L account” set in the account type.  With the Simple Finance On-Premise Edition 1503 all Controlling business transactions use document types.


Define Document Type Mapping Variants for CO Business Transactions Assign the document type for postings in Controlling to a document type mapping variant. You should copy the provided sample to a customer specific entry. The entry will be created automatically in case you already use real-time integration in new G/L The document types can be specified on the following levels:  Company code via different document type mapping variants  Controlling business transactions (for example KAZI – “Actual cost center accrual” can have a separate document type  Normal postings and cross-company postings can have separate types per business transaction as well.


Ledger and CO – SAP Simple Finance Parallel actual versions are currently not supported:  Version 0 must be assigned to the leading ledger in all company codes assigned to the controlling area. Therefore CO reads from the leading ledger (reporting and allocations).  CO writes to the manually specified ledger group. In case no ledger group is entered and no default ledger group is set in customizing it is posted to all ledgers. Usually CO should write into Leading Ledger (because this is the source for reading).


Check and Define Default Values for Postings in Controlling  Default settings are necessary for postings where there is no possibility to manually define the document type and leger group in the Controlling business transaction.  The major question here is “which ledger should Controlling update”


Define Intercompany Clearing Accounts  Posting transfers between cost objects belonging to different company codes now update the Universal Journal and so you need to assign Clearing G/L accounts for the transaction and for each combination of Company Codes such postings occur.


Demos & Exercises

Activity

Name

Page

DEMO 6

HOW TO CHECK THE CONFIGURATION OF THE INTEGRATION OF CO WITH FI

EX-150


Summary

You should now able to:  Understand the Architecture for Management Accounting  Perform customizing for Management Accounting


Unit 5 – Agenda



Understanding the Material Ledger and Cost of Goods Sold handling in SAP Simple Finance


Learning Objective

After completing this lesson, you will be able to:  Understand the scope and enhancements to the Material Ledger


Scenario

You need to closely control your inventory balances in multiple currencies. You want to understand the Material Ledger solution integration and scope in SAP Simple Finance.


Inventory Accounting and the Universal Journal

Material Ledger Material Inventory

Actual Costing optional Revaluation of stock value with actual price (with real cost of goods receipt or cost of goods manufactured)

Parallel Currencies

Parallel Valuation

Valuate with historical exchange rates for multiple currencies

Transfer Prices Company

Legal ProfitCenter

 Classic Material Valuation provides balances per inventory account in company code currency – these values are now included in the universal journal.  The Material Ledger provides balances per inventory account in multiple currencies – these values are now included in the universal journal  Material Ledger also provides options to perform multilevel actual costing. This will be performed using a costing run as before (not in scope for the Universal Journal). © 2015 SAP SE or an SAP affiliate company. All rights reserved

Technical Changes to the ML with SAP Simple Finance Usage of Material Ledger for parallel currencies and parallel valuation purpose

MLHD

MLIT

MLPP

MLPPF

MLCR

BKPF

ACDOCA

MLCRF

 Contents of tables MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, BSIM is now stored in ACDOCA. MLHD data is stored in BKPF  Compatibility views V_ (e.g. V_MLIT) are provided in order to reproduce the old structures  Access to old data in tables still possible via the views V__ORI (e.g. V_MLIT_ORI)  MLHD, MLIT, MLPP, MLCR still keep prima nota information, in case of manual price changes or material debit/credit.

MLCD

Usage of Material Ledger for Actual Costing purpose

CKMI1

 MLIT, MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD are used as before Simple Finance

BSIM


Price Determinations in Material Ledger Multiple Valuations – Price Determination 2  Prices and Values shown in the Material Master are taken directly from the Universal Journal

Multilevel Actual Costing – Price Determination 3  No Change – Costing Run Needed to Update Inventory Values at Period Close


Material Price Analysis Material Price Analysis (CKM3) is widely used to analyze all factors contributing to the cost of a material.  Material Price Analysis initially displays data from aggregated data sets (MLCD) and then drills down to the document level (MLIT, MLPP)  You can switch between valuations and currencies and navigate between periods in this view. In SAP Simple Finance this data is read directly from the universal journal.


Cost of Goods Sold Postings in SAP Accounting

To provide more details in the income statement, a refinement of the posting mechanism for COGS is required to reflect the standard cost component split on the G/L account and to distinguish fixed and variable values:

Income Statement Sales COGS -

Details - Costing

2.400.000 Labor

800.000

COGS - Material

700.000

COGS - Overhead

300.000

COGS overall

1.800.000

Net Income …

1000EA

Labor

150

External Labor

650

Material fix

400

Material variable

300

Overhead

200

Administration

100

Total


1.800

Prerequisites

•

Create GL accounts for COGS and detailed COGS (e.g. COGS material COGS labor etc.).

•

Set up account determination for material movements by specifying transaction keys BSX (to determine the inventory account) and GBB (to determine the COGS/inventory change account).

•

Set up customizing for the refinement of COGS.

•

Ensure that the costing run is executed and prices in the material master are up to date.


Refinement of COGS in SAP Accounting powered by SAP HANA – Customizing Steps

•

Create new G/L accounts on which you want to reflect the single cost components of the COGS posting.

•

Select your chart of accounts and enter every COGS account that should be refined.

•

Select the cost component structure and the cost component and assign it to a refinement GL account. One or more cost components can be assigned to one refinement account.

•

Tag one refinement account as the default account (flag ‚Default‘). Unassigned cost components are automatically posted to that default account.

•

Assign your splitting scheme to the relevant company code with a valid from date.


Account Determination Cost of Goods Sold (COGS) for I/S by Function and I/S by Nature Income Statement by Function

Income Statement by Nature

894010 Changes in Inventory 893010 Cost of Goods Sold

Depending on the income statement method used, the account for the debit line represents: • Changes in Inventory of Finished Goods for Income Statement by Nature • Costs of Goods Sold for Income Statement by Function


Refinement of COGS in SAP Accounting powered by SAP HANA SAP Accounting powered by SAP HANA provides an optional customizing activity to refine the COGS posting in GL and account-based CO-PA. The COGS amount is refined according to the cost component split. The fixed value of the COGS amount is stored in the corresponding value field in the CO line item table. The assignment of the customizing is time dependent.


Demos & Exercises

Activity

Name

Page

EXERCISE 13 PROCESS PURCHASE TO INVOICE (MATERIAL LEDGER UPDATE)

EX-156

DEMO 7

EX-178

HOW TO CHECK THE CUSTOMIZING FOR THE COST OF GOODS SOLD SPLIT

EXERCISE 14 POST AND ANALYZE THE COST OF GOODS SOLD


EX-180

Summary

You should now able to:  Understand the scope and enhancements to the Material Ledger


Unit 5 – Agenda



Explaining Profitability Analysis in SAP Simple Finance


Learning Objective

After completing this lesson, you will be able to:  Understand the improvements to Profitability Analysis with SAP HANA  Understand the specific innovations for Account based Profitability Analysis with SAP Simple Finance


Scenario

You need analysis of profitability on the market segment level and flexibility to define your own reporting characteristics. You are interested in understanding the scope of the Profitability Analysis component in SAP Simple Finance and what options you have for implementing it.


The Purpose of Profitability Analysis The business purpose of Profitability Analysis (CO-PA) is to provide the company with profitability-oriented information on the performance of its market segments or sales channels. This information is used to support corporate planning and decision-making, especially in the areas of sales and marketing. CO-PA allows you to define market segments and performance figures, with maximum flexibility in market evaluation.  The definition of a market is configured in the system by selecting the characteristics that are the subjects of analyses.  Performance figures may be based either on profit and loss accounts (Account Based CO-PA) or freely-defined value fields (Cost Based CO-PA).


Profitability Analysis with Simple Finance  Account-based CO-PA is the recommended approach.  Cost-based is fully supported but is not integrated in the Universal Journal.  You can use both approached in parallel, for ne customers you have to evaluate if there is a need for cost-based CO-PA.  For derivation of customer specific profitability attributes CO-PA offers advanced derivation functionality, this can be used for both types of CO-PA. For example: – Posting on cost center -> derives the product group through the CO-PA derivation tool. – Posting on Sales order item -> all Market segment information is already provided automatically.


HANA Acceleration of CO-PA – Report Execution In both types of CO-PA, you will see a great speed improvement in processing when comparing to a non-HANA DB system. CO-PA data quantity structure:

Analyzed CO-PA drilldown reports:

 85 Million line items  33,000 customers  27,000 articles

 Sales margin analysis  Cost allocation analysis ERP without SAP HANA (1)

ERP with SAP HANA (2)

Acceleration factor (1)/(2)

Sales margin analysis – initial report

280 sec

7 sec (DB 2.8 sec)

40

Sales margin analysis – drilldown by cost center

620 sec

5 sec (DB 2.9 sec)

124

45 sec

5 sec (DB 3.4 sec)

9

260 sec

7 sec (DB 3.3 sec)

37

Cost allocation analysis – initial report Cost allocation analysis – drilldown by cost center © 2015 SAP SE or an SAP affiliate company. All rights reserved

HANA Acceleration of CO-PA – Process Execution The below example shows the processing time for an assessment run:

Runtime with HANA

Runtime without HANA


Real-time Account Based Profitability in Simple Finance  The Universal Journal as a single source of truth in Financials provides profitability attributes for every P&L line item.  The Operating Concern generation appends the CO-PA characteristics to the Universal Journal.  Profitability attributes are derived online  Profitability attributes can be enriched by further processes such as settlement or allocations

Reconciled Profitability Reporting at any Time


Example – P&L for Legal and Management Reporting

Legal Reporting on GL account or functional area


Profitability Reporting by Market Segment

Refinement of COGS in SAP Accounting powered by SAP HANA – CO-PA Line Item

The cost component structure of Cost of Goods Sold (COGS) will be posted in the Account Based Profitability Analysis and Financial Accounting as well. The values are stored on line item level in the universal journal table (ACDOCA) and the accounts are updated on the basis of total costs. The COGS with fixed and variable cost will continue to be posted in the Costing Based COPA on different value fields. The contribution margin can be calculated in the Costing Based COPA. © 2015 SAP SE or an SAP affiliate company. All rights reserved

Demos & Exercises

Activity

Name

Page

DEMO 8

HOW TO CHECK THE CONFIGURATION OF THE OPERATING CONCERN

EX-191


Summary

You should now able to:  Understand the improvements to Profitability Analysis with SAP HANA  Understand the specific innovations for Account based Profitability Analysis with SAP Simple Finance


Unit 5 – Agenda

Understanding the new Architecture of Management Accounting Understanding the Material Ledger and Cost of Goods Sold handling in SAP Simple Finance Outlining new Period Closing Programs for Management Accounting Outlining new Period Closing Programs for Management Accounting


Outlining new Period Closing Programs for Management Accounting


Learning Objective

After completing this lesson, you will be able to:  Understand the new Architecture of the Period Close Programs  Use the Period Close transactions


Scenario

You currently have very long processing times for your Management Accounting period close activities, you want to understand if and how processing speed is improved with Simple Finance.


HANA Coding Options

HANA views are used to select the relevant costs from the line item table HANA procedures are used to handle the calculation logic in the close transactions.

ABAP application (calculation logic)

HANA Views

Totals

HANA Views are used to select costs from the line item tables rather than the totals tables

ABAP application

HANA Procedure HANA Procedures are used to handle complicated calculation logic

(Calculation logic)

Line Item


Line Item

Period Close Transactions Traditional approach 1. Selection of objects

2. Selection of costs, status, configuration,… sequentially per object

3. Update results per object

Transactions: Settlement (CO88, VA88, KO8G, CJ8G), WIP at actual costs (KKAO), results analysis on sales orders (KKAK), variances with full settlement (KKS1), cost center variances (KSS1)

HANA-optimized approach 1. Selection of objects, costs, status, and configuration directly from database

2. Update results per object

New Transactions: Settlement (CO88H, VA88H, KO8GH, CJ8GH), WIP at actual costs (KKAOH), results analysis on sales orders (KKAKH), production variances (KKS1H), cost center variances (KSS1H)

Results in performance Improvements between 10% and 60% (depending on volumes & configuration) © 2015 SAP SE or an SAP affiliate company. All rights reserved

New Period Close Transactions in SAP Simple Finance

 Results Analysis

KKAK

KKAKH

 WIP Calculation at Actual Costs

KKAO

KKAOH

 Variance Calculation (Production)

KKS1

KKS1H

 Variance Calculation (Cost Centers)

KSS1

KSS1H

 Settlement (plant selection)

CO88

CO88H

 Settlement (make-to-order sales orders)

VA88

VA88H

 Settlement (internal orders)

KO8G

KO8GH

 Settlement (projects)

CJ8G

CJ8GH

 Generate settlement rules (projects)

CJB1

CJB1H


Results Analysis for Sales Orders (Transaction: KKAKH) As a cost accountant dealing with the need to account for long-term contracts in the balance sheet, you need to run results analysis to prepare the appropriate postings for each accounting period. Depending on local legislation and sometimes corporate guidelines, the degree of progress towards completion is measured based either on the revenue or the incurred costs. Severe performance issues can occur due to the volume of sales order items to be handled in each period.  In the first release, KKAKH supports two commonly used methods 01 revenue-based RA and 03 cost-based RA (out of 17 methods).

Not supported:     

Some expert methods Customer enhancements; Other 15 methods (Besides 01 and 03 methods); Multiple result analysis versions See SAP Note 1939621 for further details


WIP Calculation (Transaction: KKAOH) At period-end close, the production controller calculates the value of the work in process for the unfinished products. The number of production orders to be processed can result in long-running jobs.  KKAOH values production orders only, at actual cost for the selected plant with defined legal valuation for a single result analysis version.

Not yet supported:     

Customer enhancements; WIP calculation for product cost collectors; WIP calculation for process orders; Multiple result analysis versions See SAP Note 1939621 for further details


WIP Calculation: UI Differences between KKAO and KKAOH  The buttons “With Product Cost Collectors” “With Process Orders” and “All RA Versions” are suppressed.  Collective Processing is only valuated at actual cost with Production Order for selected plant by single version.  You can only choose “With Production Orders” and a single version in the screen.


Business Scope: Variance Calculation for Production Orders (Transaction: KKS1H) Cumulative variance calculation compares the target costs with the cumulative control costs.  The target costs are calculated by adjusting the standard costs for the actual quantity delivered.  The control costs are calculated by subtracting the work in process and the scrap variances from the actual costs.

Currently product cost collectors, production orders and process orders are supported but only target version 0 is supported Refer to SAP Note 2027639 for details of further limitations


Business Scope: Variance Calculation for Cost Centers (Transaction KSS1H) Variance calculation for Cost Centers provides you with detailed cost information at the activity level. The variance calculation function does the following:  Shows the variance between target costs and control costs (the control costs can be the net actual costs, for example)  Determines the difference between the actual costs debited to the object and the credit from other controlling objects(total variance)  Show how the cost is split at the activity level  Categorize the variance into the different variance category

The system updates the variances by object for each cost element, or for each cost element and origin.


Settlement Transactions Costs that arise from processing an order, or project (for example, costs for material, personnel or external services) are transferred to the settlement receiver specified in the settlement rule in the master record of the object. Both the selection statements for order and project settlement and for the generation of project settlement rules have been reworked to improve performance. With SAP Simple Finance, a mass settlement run can be executed in the foreground, where you used to only be able to perform background processing. Note that to use the new transactions (CO88H, VA88H, KO8GH, CJ8GH) you will need to create new selection variants that offer less selection options than the original selection variants. If the new variants do not meet your requirements, then you can of course continue to use the existing non-optimized transaction.


Demos & Exercises

Activity

Name

Page

DEMO 9

HOW TO CHECK THE CONFIGURATION FOR SPLITTING PRICE DIFFERENCES

EX-196

EXERCISE 15 POST PRICE DIFFERENCE – VARIANCE CATEGORIES OF PRODUCTION ORDER


EX-198

Summary

You should now able to:  Understand the new Architecture of the Period Close Programs  Use the Period Close transactions


Unit 6: Further Simple Finance Integration


Unit 6 – Agenda

Outlining the Functions of SAP Cash Management powered by SAP HANA Outlining the Functions of Integrated Business Planning for Finance (IBPF)


Outlining the Functions of SAP Cash Management powered by SAP HANA


Learning Objective


 Understand the position of SAP Cash Management powered by SAP HANA in the overall Treasury solution map of SAP  Understand the main functions and business values of this product  Understand the main features of Cash Operations  Understand the main features of Bank Account Management  Understand the main features of Liquidity Management


Scenario

You are interested in the solution of SAP Cash Management powered by SAP HANA, you want to get an overview of the functions and features that can help the company run better in the Cash Management area. You are particularly interested in understanding what benefits you can gain from implementing the SAP Cash Management powered by SAP HANA in your SAP ERP system.


End-to-End Treasury and Risk Management Treasury Solution Map Payments and Bank Payment Operations Communications Cash and Liquidity Management Debt and Investment Management Financial Risk Management

Suite Capabilities

Foundation

Workflow and Signatures

Electronic Bank Statements

Front Office Deal capture

Cloud

Cash Operations

Mid Office Risk Controlling

Risk Identification Type and Origin of Risk

Shared Service Center

Monitoring and Status Tracking

HANA Platform

Liquidity Management

Bank Account Management

Back Office Correspondence & Settlement

Risk Quantification Exposure Mgmt Working Capital Management

Bank and SWIFT Connectivity

Payment Factory

Risk Analysis

Governance Risk and Compliance

Analytics

Accounting

Risk Management Hedge with Financial Instruments

Commodity Risk Management

Mobile

Rapid Deployment Solutions (RDS)

SAP Cash Management powered by SAP HANA Treasury Solution Map, Edition 2014 © 2015 SAP SE or an SAP affiliate company. All rights reserved

Integrated Treasury and Cash Platform SAP Treasury and Cash Solution    

Market Places

FX Management Debt Management Investment Management Correspondence Framework

   

Limit Management Exposure Management Hedge Management Risk Management  Payments  In House Bank  Bank Statements  Monitoring  Status Management  Signatory

Liquidity Management Market Data

Cash Operations Bank Account Management

One Exposure SAP HANA Platform + SAP Simple Finance Add On AP/AR

SAP


Others

…

Banks

SAP FSN

SAP Cash Management powered by SAP HANA

Instant Insight on SAP HANA

SAP Cash Management powered by SAP HANA Centralized Bank Account Management

Intuitive User Experience all devices

Daily Cash Operations and Cash Position

SAP Accounting powered by SAP HANA

Liquidity Forecast

Cash Flow Analysis

Integrated Business Planning

SAP Simple Finance On-Premise Edition 1503

Flexible and Non-disruptive cloud or on premise © 2015 SAP SE or an SAP affiliate company. All rights reserved

Rolling Liquidity Planning

Business Suite on HANA

SAP Cash Management powered by SAP HANA: Benefits  Bank Account Management – Centralized Bank Account Management – Better Lifecycle Management for Bank Accounts – Master Data Fully Charged by Business Users

 Cash Operations – Short Term Cash Positions Analysis – Make and Track Bank Transfers

 Liquidity Management – Mid and Long Term Liquidity Forecast – Actual Cash Flow Analysis – Embedded Rolling Liquidity Planning and Variance Analysis  New Fiori (HTML5) user interface, and KPI cockpit – SAP Smart Business for Cash Management.  Integrated with FI, TRM, BCM (Bank Communication Management) and IHC (InHouse Cash). © 2015 SAP SE or an SAP affiliate company. All rights reserved


Function Overview of Bank Account Management

2. Fuzzy Search 3. Bank Account Group

1. Bank and Bank Account Hierarchy

（free style) 5. Overdraft Limits

6. Payment Signatures Bank Account Management

4. New Bank Account Master Data

9. Workflow for Bank Account

7. Attachments 8. Change History

 Plenty of attributes reflecting controls on both bank and company sides  Bank Account standard hierarchy and free style group

 Signatory integrated with BCM Payment Approval  Approval process for Bank Accounts Opening, Changing and Closing activities  Bank Accounts Review process

10. Review Process

12. Upload and Download

Centralized Bank Account Management

11. Cash Pooling


 Upload and Download Bank Accounts  Bank Account Management Lite

Function Overview of Cash Operations

Cash Operations  Cash Operations for the day to day management of the corporates working capital  Monitoring status of incoming bank statements  Preparing a daily forecast of cash receipts, disbursements and expected closing balances  Overseeing bank risk  Initiating bank transfers and payments  Approving and monitoring payments


Function Overview of Liquidity Management

Liquidity Management  Complete lifecycle management of Rolling Liquidity Planning  System provides reference data to help Cash Manager to plan the liquidity precisely and easily  Functionality to plan hedging of operating activities for foreign currencies  Plan/Plan, Plan/Forecast and Plan/Actual comparisons  Overview suspicious plans  Liquidity Forecast  Cash Flow Analysis


List of Transactional and Analytical Fiori apps and Others Bank Account Management:

Cash Operations:

 Manage Bank Accounts (Webdynpro)  My Sent Requests (Webdynpro)  My Bank Account Worklist (Webdynpro)  Maintain Signatory (Webdynpro)  Initiate Review Process (Webdynpro)  Monitor Review Status (Webdynpro)  Create Bank (HTMLGUI)  Change Bank (HTMLGUI)  Manage House Banks (Transactional)  Bank (Factsheet)  House Bank (Factsheet)  House Bank Account (Factsheet)

        

Bank Statement Monitor (Analytical) Cash Position (Analytical) Cash Position Details (Transactional) Analyze Payment Details (Transactional) Make Bank Transfer (Transactional) Track Bank Transfers (Transactional) Approve Bank Payments (Transactional) Bank Risk (Analytical) Payment Statistics (Analytical)

Liquidity Management:    

Develop Liquidity Plans (Transactional) Liquidity Plans (Analytical) Liquidity Forecast (Analytical) Cash Flow (Analytical)

You can find detailed information of Fiori and Smart Business apps in following URL: https://go.sap.corp/kya © 2015 SAP SE or an SAP affiliate company. All rights reserved

Deployment Options for SAP Cash Management powered by SAP HANA Client

Client

Client

Client

Client

SAP ERP

SAP ERP Fin Acc Mgmt Acc

BCM

Payment

IHC

SD

TRM

MM

Any DB


Simple Finance Add-on

SAP HANA DB

Business Suite on HANA

Fin Acc Mgmt Acc Payment

SD

MM

Any DB


BCM

IHC TRM

Simple Finance Add-on

SAP HANA DB

Side-by-side Scenarios Accelerated Analysis and Detailed Insights


Extended Functionality through Integration of Single Processes

SD MM SD MM

SAP Cash Mgmt powered by SAP HANA SAP Accounting powered by SAP HANA

BCM IHC TRM

SAP HANA DB Integrated Scenario

Full Integration of Business Suite on SAP HANA

Related SAP Links

Where

What

Link


Configuration Guide for SAP Cash Management

http://service.sap.com/erp-inst -> SAP ERP Add-Ons -> SAP Simple Finance Add-On for SAP Business Suite powered by SAP HANA -> SAP Simple Finance Add-On 2.0


Data Setup Guide for SAP Cash Management powered by SAP HANA

Same as above


Note 2149337 Release Scope Information - SAP Cash Management powered by SAP HANA

https://css.wdf.sap.corp/sap/suppo rt/notes/2149337


Demos & Exercises

Activity

Name

OPTIONAL MANAGE HOUSE BANK ACCOUNTS EXERCISE 16


Page EX-212

Summary


 Understand the position of SAP Cash Management powered by SAP HANA in the overall Treasury solution map of SAP  Understand the main functions and business values of this product  Understand the main features of Cash Operations  Understand the main features of Bank Account Management  Understand the main features of Liquidity Management


Unit 6 – Agenda

Outlining the Functions of SAP Cash Management powered by SAP HANA Outlining the Functions of Integrated Business Planning for Finance (IBPF)


Outlining the Functions of Integrated Business Planning for Finance (IBPF)


Learning Objective


 Understand the Functions of Integrated Business Planning for Finance (IBPF)  Explain the Benefits of Integrated Business Planning for Finance (IBPF)


Scenario

In your current system environment all planning processes are performed in the ERP environment. It is hard to maintain and execute a logical planning workflow and to achieve consistent planning on the various planned attributes. You want to understand how Integrated Business Planning for Finance can help you streamline and simplify the planning process.


What problems does IBPF address? Problem: Can’t plan across the organization in time, don’t have the right information, and can’t test assumptions Finance: “How’s our overall margin impacted by our growth in BRIC?”

Sales Mgmt: “Can we support this new account?”

Finance Sales

ERP

GM/CXO: “How do we make Operations sure we don’t miss the quarter?”

Consequences  Miss the quarter  Lose a high-profile customer  Lose market share  Errors And Omissions

CRM

Marketing

Marketing: “How will a pricing change impact demand of my highest volume product family?”


SCM

Supply Chain: “Where/when am I going to source this new product?”

What Does Integrated Business Planning for Finance (IBPF) Do?  Enables the financial planning capabilities provided by SAP Business Planning and Consolidation to be seamlessly integrated in SAP ERP user interfaces and workflows, effectively replacing the current planning capabilities in SAP ERP.  Overcomes limitations when planning in ERP through the SAP GUI  Eliminates Data replication.  Retracts Plan data developed in SAP Business Planning and Consolidation to SAP ERP for variance analysis and SAP Business Planning and Consolidation will be able to access real time master data and actuals maintained in SAP ERP.  Provides end-to-end simulation capabilities.


Why Use IBPF?  Integrated Business Planning for finance comes embedded with the SAP Business Suite on SAP HANA where SAP Simple Finance is being utilized.  Provides significant functional off the shelf content including templates and calculations covering multiple planning scenarios  Allows Companies using traditional financial planning within ERP to rapidly implement while protecting their existing investment. (Minimizes cost and time to implement)  Takes advantage of HANA views that support direct real time access to ERP Master data and the FI-CO document tables.  Optimal for organizations who have a significant portion of the data upon which they perform planning within the SAP ERP on HANA system and are planning against “traditional” FI and CO data structures yet at the same time provides for truly integrated planning across finance.


Functional Advantages of IBPF SAP Hana Driven Line Items  Fast plan data reporting and plan/actual comparisons  Fast plan data processing through planning functions of PAK (Planning Application Kit)

Integrated FI and CO  Unbeatable bottom-up and top-down planning capabilities integrating data from high level expense group level down to most detailed market segmentations  Plan data are available at any level without the need of replication between applications

Seamless upgrade possible:  CO Historic Plan Data can be migrated to the new solution (currently not GL).  Existing Plan Data processes remain unchanged (Tariff Calc., Allocations & Distributions, …)

Enhanced Reconciliation Capabilities  Same granularity as in General Ledger: Every plan data record (even if it has been recorded at a higher level) is stored on company & account level.  No distinction between G/L Accounts and Cost Elements: Reconciled by Design


Conceptual Overview (Traditional Architecture)

EHP6 Architecture

BPC*

BW-IP**

ERP

BPC*

BWIP**

OLTP

any DB

any DB

any DB

* SAP Business Planning and Consolidation ** SAP Business Warehouse Integrated Planning


Traditional Pain Points

XLS files

 Separate Systems for ERP-based planning and standalone planning tools  Planning silos with separate data stores  Peer-to-peer transfer programs and ELT between different planning applications  Long running batch jobs / Simulation impossible  Many manual steps / Long planning cycles

Simplified Planning Integration Today in ECC

Integrated Business Planning

     

   

Planning silos with separate data stores Long running batch jobs Peer-to-peer transfer programs Cumbersome process Many manual steps – fault prone Simulation impossible

Expense Planning

Profitability Planning

P&L Planning

Common Financial Planning model Leverage In-Memory-planning capabilities Faster planning cycles Better decisions through end-to-end simulation capabilities

Expense Planning

Profitability Planning

HANA Views Common Planning Model


P&L Planning

Comparison: Data Sources Where do my planned data “typically” come from ?

P&L Planning

+ Profit Center Planning

+ Project Planning

+ Cost Center Planning

+ Internal Order Planning


Integrated Business Planning for Finance Cube

Content delivered with IBPF Integrated Business Planning for finance includes templates that provide support for:        

Cost Center Planning Internal Order Planning Project Planning Profit Center Planning Cost of Sales Planning P&L Planning Market Segment Planning Liquidity Planning

Integrated Business Planning for finance also includes:     

Queries Planning Functions Sequences Info-Objects Info-Providers


What are the pre-requisites for Integrated Business Planning for Finance? Licensing

Installation

 SAP ERP Foundation starter plus appropriate named user licensing  SAP Accounting Powered by SAP HANA license  SAP Cash Management for Finance (Liquidity planning is a part of Cash Management )  SAP HANA Limited Runtime edition for Applications or other appropriate HANA licensing  SAP Business Planning & Consolidation, version for SAP NetWeaver license  SAP BusinessObjects Analysis Edition for Office (soon to be included in the above)

   


SAP HANA 1.0 Platform SAP NetWeaver 7.40 SAP ECC Release 6.0EhP7 SAP Simple Finance 1503

Limitations and Outlook Current solution limitations:  Enterprise Performance Management (EPM) Add-In client not available yet  Finance driven master data administration/management not available where master data not maintained directly in ERP  Currently no equivalent to IBPF for Consolidation (you need to use standalone BPC for this functionality).

High level development roadmap direction:    

Legal & Managerial Consolidation Investment Planning Improved Simulation Improved Process Administration


Related SAP Links Where

What

Link


Consolidated SAP information note for IBPF: 2081400

https://css.wdf.sap.corp/sap/support/notes /2081400

Youtube

IBPF Demo

https://go.sap.corp/IBPFDEMO


Demos & Exercises

Activity

Name

OPTIONAL PLAN COSTS USING IBPF EXERCISE 17


Page EX-223

Summary


 Understand the Functions of Integrated Business Planning for Finance (IBPF)  Explain the Benefits of Integrated Business Planning for Finance (IBPF)


© 2015 SAP SE oder ein SAP-Konzernunternehmen. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP SE oder ein SAP-Konzernunternehmen nicht gestattet. SAP und andere in diesem Dokument erwähnte Produkte und Dienstleistungen von SAP sowie die dazugehörigen Logos sind Marken oder eingetragene Marken der SAP SE (oder von einem SAP-Konzernunternehmen) in Deutschland und verschiedenen anderen Ländern weltweit. Weitere Hinweise und Informationen zum Markenrecht finden Sie unter http://global.sap.com/corporate-de/legal/copyright/index.epx. Die von SAP SE oder deren Vertriebsfirmen angebotenen Softwareprodukte können Softwarekomponenten auch anderer Softwarehersteller enthalten. Produkte können länderspezifische Unterschiede aufweisen. Die vorliegenden Unterlagen werden von der SAP SE oder einem SAP-Konzernunternehmen bereitgestellt und dienen ausschließlich zu Informationszwecken. Die SAP SE oder ihre Konzernunternehmen übernehmen keinerlei Haftung oder Gewährleistung für Fehler oder Unvollständigkeiten in dieser Publikation. Die SAP SE oder ein SAP-Konzernunternehmen steht lediglich für Produkte und Dienstleistungen nach der Maßgabe ein, die in der Vereinbarung über die jeweiligen Produkte und Dienstleistungen ausdrücklich geregelt ist. Keine der hierin enthaltenen Informationen ist als zusätzliche Garantie zu interpretieren. Insbesondere sind die SAP SE oder ihre Konzernunternehmen in keiner Weise verpflichtet, in dieser Publikation oder einer zugehörigen Präsentation dargestellte Geschäftsabläufe zu verfolgen oder hierin wiedergegebene Funktionen zu entwickeln oder zu veröffentlichen. Diese Publikation oder eine zugehörige Präsentation, die Strategie und etwaige künftige Entwicklungen, Produkte und/oder Plattformen der SAP SE oder ihrer Konzernunternehmen können von der SAP SE oder ihren Konzernunternehmen jederzeit und ohne Angabe von Gründen unangekündigt geändert werden. Die in dieser Publikation enthaltenen Informationen stellen keine Zusage, kein Versprechen und keine rechtliche Verpflichtung zur Lieferung von Material, Code oder Funktionen dar. Sämtliche vorausschauenden Aussagen unterliegen unterschiedlichen Risiken und Unsicherheiten, durch die die tatsächlichen Ergebnisse von den Erwartungen abweichen können. Die vorausschauenden Aussagen geben die Sicht zu dem Zeitpunkt wieder, zu dem sie getätigt wurden. Dem Leser wird empfohlen, diesen Aussagen kein übertriebenes Vertrauen zu schenken und sich bei Kaufentscheidungen nicht auf sie zu stützen.


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


Financials S4 AC110-EN-S4HANA.pdf

Recommend Documents