s4f01e

Notas curso S4F01e – Financial Accounting in SAP S/4HANA
Tabla de contenido
1. Overview of Financials for SAP S/4HANA .................................................................................. 2
1.1 Explain SAP HANA, SAP S/4HANA ....................................................................................... 3
1.2. Describe SAP S/4HANA Finance ....................................................................................... 12
1.3. Describing the new Architecture of Accounting .............................................................. 20
1.4. Introducing SAP Fiori ........................................................................................................ 40
1.5. Getting an Overview of Financials Migration to SAP S/4HANA ..................................... 105
2. General Ledger Accounting ................................................................................................... 111
2.1. Managing GL Accounts and Cost Elements in SAP S/4HANA ......................................... 112
2.2. Managing Ledgers in SAP Accounting powered by SAP HANA ...................................... 197
3. Asset Accounting ................................................................................................................... 238
3.1. Analizing the Posting Logic of new Asset Accounting .................................................... 239
3.2. Configuring New Asset Accounting ................................................................................ 327
4. Reporting ............................................................................................................................... 339
5. Other Topics .......................................................................................................................... 463
5.1. Understanding Central Finance ...................................................................................... 464
5.2. Introducing Cash Management powered by SAP HANA ................................................ 473
6. Post-Assessment ................................................................................................................... 486
1. Overview of Financials for SAP S/4HANA
1.1 Explain SAP HANA, SAP S/4HANA
Con la arquitectura actual hay que elegir una de las siguientes opciones:
Esto implica que la información no está disponible en tiempo real, sino que se actualiza
durante las noches en procesos batch.
SAP ha reescrito la business suite para aprovechar las nuevas capacidades de hardware que
proporcionan los avances en tecnología.
La tecnología cloud permite que los clientes no necesiten invertir en hardware y tengan un
landscape tecnológico más sencilo. Existen servicios de suscripción para esta opción.
En SAP HANA los procesos OLTP y OLAP están juntos. Anteriormente los procesos de base de
datos estaban optimizados para OLTP u OLAP, pero no para ambas opciones.
Hasta ahora era habitual que los datos no se tuvieran hasta el día siguiente. Sin embargo, con
SAP HANA los datos están disponibles en tiempo real, puesto OLTP y OLAP comparten un
mismo modelo en SAP HANA.
Con SAP HANA ya no se necesitan agregados ni índices, lo que reduce la replicación de datos
del modelo de datos tradicional. Este modelo de datos tradicional, complicaba la integración
con otras aplicaciones.
Además, en SAP HANA se pueden calcular las agregaciones “on-the-fly” en pocos segundos.
SAP HANA utiliza almacenamiento por columnas, lo que permite que los índices no sean
necesarios (se pueden crear, pero la mejora en rendimiento normalmente es mínima).
Al eliminar los índices y agregados se puede suprimir mucho código, que estaba
específicamente desarrollado para trabajar con ellos. Gracias a esta simplificación del código y
el modelo de datos es más sencillo mejorar las aplicaciones y añadir funciones adicionales.
SAP ha reescrito sus aplicaciones de negocio cada vez que se ha producido un cambio
tecnológico importante. La diapositiva recoge algunos momentos clave:
•
1979: SAP inventa ERP. “R/2” soporta las principales tareas de negocio en tiempo real
e incluye soporte multi-país y multi-moneda. La “R” significa “tiempo real”. Existió un
“R/1” pero “R/2” es considerada la primera release importante.
•
1992: Con la llegada del ordenador personal se reescribe el software para hacer uso
del modelo cliente-servidor. Se renueva la interfaz gráfica para mejorar la experiencia
de usuario.
•
2004: La web se consolida como una red de negocios y los clientes demandan mayor
integración entre las aplicaciones de negocio y la web. SAP desarrolla una nueva
plataforma de integración denominada SAP Netweaver para permitirlo. Desde este
momento todos los programas de SAP funcionan sobre una misma plataforma y los
clientes pueden integrar aplicaciones existentes mediante tecnología web estándar. El
nombre de SAP R/3 cambia a SAP ERP y pasa a formar parte de una familia de
aplicaciones denominada “SAP Business Suite” (incluye otras aplicaciones, como por
ejemplo SAP CRM).
•
2015: Una nueva ola de avances en hardware proporciona potencia de procesado
masiva a costes en descenso. Llega una mayor cantidad de memoria y multi-procesado
para conseguir mayor potencia. Las aplicaciones SAP existentes no están preparadas
para aprovechar al máximo esta potencia, por lo que es necesaria una re-escritura
completa de la business suite. La nueva versión de la business suite se denomina SAP
S/4HANA.
SAP S/4HANA no es un único producto, sino que cubre diferentes aplicaciones. Los clientes
pueden empezar con los componentes básicos y añadir otros después. S/4HANA Enterprise
Management es el “core” simplificado y puede ser considerado el sustituto de SAP ERP.
Proporciona el soporte para todos los procesos de negocio principales, como “quotation to
cash”, “procure to pay”, etc. Para muchos clientes este es el punto en el que la adopción de
S/4HANA comienza.
S/4HANA puede ser integrado fácilmente con S/4HANA soluciones LoB (Line of Business). Estas
opciones pueden ser añadidas en cualquier momento.
En el pasado había muchas aplicaciones alrededor del “core” con solapamientos de
funcionalidad y redundancias (Ej: CRM y SRM). Actualmente, los solapamientos y las
redundancias han sido completamente eliminados en S/4HANA.
S/4HANA está diseñado para funcionar exclusivamente y óptimamente sobre la plataforma
SAP HANA.
SAP S/4HANA está construido sobre SAP HANA y, por lo tanto, hereda todas las posibilidades
de esta potente “in memory” plataforma de gestión y aplicaciones. Esto incluye minería de
datos, análisis de productividad, simulaciones y potente soporte para decisiones en tiempo
real, con acceso a cualquier tipo de datos en tiempo real.
Se proporciona una nueva experiencia de uso para mejorar la productividad y experiencia de
los usuarios de negocio. Además, se incluye una interfaz que proporciona una experiencia de
uso optimizada para cualquier dispositivo.
SAP S/4HANA puede ser distribuida on-premise, en formato cloud o una combinación de
ambos, para proporcionar opciones de adopción flexibles a los clientes.
El modelo de datos ha sido simplificado. Esto implica que las tablas innecesarias se han
suprimido y, por supuesto, también los datos en esas tablas, para reducir el tamaño de la data
footprint dramáticamente. Esto simplifica el diseño de aplicaciones y su extensibilidad.
Debido a esta simplificación del modelo de datos, se puede pasar de una base de datos de 7.1
TB a menos de 1 TB. Esto se consigue con compresión de datos y simplificación de la
arquitectura del sistema. Además, contribuye a conseguir un incremento en la eficiencia de
procesado de datos de 3-7x.
Es muy flexible, sin índices ni consolidaciones preconfiguradas, lo que permite utilizar los datos
de formas que hasta ahora no era posible. Es software empresarial diseñado con big data y
agilidad en el “core”.
1.2. Describe SAP S/4HANA Finance
(Scroll vertical)
Tradicionalmente las aplicaciones financieras de SAP han estado separadas en diferentes
componentes (contabilidad financiera –FI-, contabilidad de gestión –CO-,…). Estos
componentes tienen, a su vez, subcomponentes como contabilidad de activos fijos –FI-AA- .
Cada componente tiene su propia arquitectura de datos y esto genera ineficiencias.
Con la re-escritura de S/4HANA se ha revisado el modelo de datos para reducir ineficiencias.
Se hace un repaso del esquema de la parte superior. A tener en cuenta: En 2014 se puede
instalar el add-on Simple Finance 1.0, pero esto es parte de SAP ERP, no de S/4HANA.
En 2015 se finaliza el camino de simplificación del modelo de datos con la llegada de S/4HANA
1503.
SAP HANA hace que la gestión de finanzas sea más sencilla y más rápida. Los usuarios reciben
información personalizada con la posibilidad de bajar desde datos generales hasta datos a
nivel de línea. Hay diferentes formas de analizar los datos, dependiendo de las soluciones
implementadas.
SAP proporciona una plataforma totalmente integrada, basándose en las últimas tendencias
de tecnología para permitir que desde finanzas se lidere la transformación al negocio digital.
La imagen muestra la funcionalidad completa de S/4HANA Finance. Todos los aspectos de
todas las áreas funcionales y roles son soportados.
En la imagen anterior se muestra el alcance de las innovaciones en finanzas. SAP Accounting es
el núcleo de las innovaciones de finanzas en S/4HANA.
Preguntas[DBE1]
Summary
1.3. Describing the new Architecture of Accounting
Exercise: Display Financial Tables in the SAP HANA Backend[DBE2]
Explain how SAP safeguards the customer investments
Pregunta[DBE3][DBE4]
Pregunta[DBE5]
1.4. Introducing SAP Fiori
Exercise: Customize your Launchpad and generate your own tiles[DBE6]
Exercise: Post a Simple FI Document[DBE7]
1.5. Getting an Overview of Financials Migration to SAP S/4HANA
(Scroll vertical del texto)
Pregunta[DBE8]
2. General Ledger Accounting
2.1. Managing GL Accounts and Cost Elements in SAP S/4HANA
When the G/L type primary costs or revenue is chosen, you can update account settings
for the controlling area.
The cost element category specifies which business transactions can be used with which
cost element. The following business transactions can be selected:
•
•
•
•
•
•
01 Primary costs/cost-reducing revenues
03 Accrual/deferral per surcharge
04 Accrual/deferral per debit = actual
11 Revenues
12 Sales deduction
22 External settlement
Secondary Costs accounts types can be used for internal CO allocations only. The
following business transactions can be selected:
•
•
•
•
•
•
•
•
•
21 Internal settlement
31 Order/project results analysis
41 Overhead Rates
42 Assessment
43 Internal activity allocation
50 Project-related incoming orders: Sales revenue
51 Project-related incoming orders: Other revenues
52 Project-related incoming orders: Costs
61 Earned value
In SAP Accounting, a default account assignment can be defined using transaction
OKB9 or through substitution rules only. Default account assignments maintained in
former cost element master data are migrated to transaction OKB9 as part of the
migration process.
•
•
The CO object (investment order or WBS element) is entered in the asset master
record as an investment account assignment (in the time-Origin).
The indicator for statistical updating of the order or WBS element is set in the
definition of the transaction types used for asset transactions (indicator: Relevant
to budget).
Note: This indicator is already set in the standard transaction types.
o
•
•
The balance sheet account for asset APC values must be created in CO as
cost elements (select the Apply Acct Assignments Statistically in Fixed
Asset Acct / Material Acct checkbox). You can select the Checkbox:
o When you create an Account - G/L Account Type: Balance Sheet G/L
Account.
o When the account is a reconciliation account for assets.
o When you add the account in the asset account assignment in the Bal.
sheet account: Acquisition and production costs field.
In the field status variant of the corresponding fixed asset balance sheet account,
the CO/PP Order field or the PSP Element field must be set as an optional entry:
see the Additional Account Assignment group. The same applies for the
Investment Account Assignments field group in the screen layout rule of the asset
class.
The Investment Order and the Investment Project account assignment objects
must be activated. After that, you can specify the account assignment types for
activated account assignment objects.
There are redundant object models in the traditional SAP ERP system. In SAP ERP, the
vendor master and customer master is used. In S/4HANA, the (mandatory) target
approach is the Business Partner approach. Business Partner is now capable of centrally
managing master data for business partners, customers, and vendors. With current
development, Business Partner is the single point of entry to create, edit, and display
master data for business partners, customers, and vendors.
It is planned to check the introduction of the customer/vendor Integration in the prechecks and the technical transition procedure of SAP S/4HANA 1511. For a system
where the customer/vendor integration is not in place, the transaction is declined. The
Business Partner Approach is not mandatory for the SAP S/4HANA Finance, 1503.
The user interface for SAP S/4HANA Cloud and On Premise is transaction BP. There is
no specific user interface for customer/vendor in SAP Business Suite (transactions
XD01, XD02, XD03 or VD01, VD02, VD03 / XK01, XK02, XK03 or MK01, MK02, MK03, and so
on, are not available). Calls to these transactions are redirected to transaction BP. For
clients who implemented Financial supply chain management (FSCM), the business
partner functionality is not something new that used to take care of credit management,
collections, and so on.
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).
Demostración[DBE9]
Exercise: Create a primary account[DBE10]
Exercise: Create a Business Partner[DBE11]
Demonstration: How to create a Vendor and Customer[DBE12]
In SAP Accounting CO relevant postings do not check the CO Period Lock (OKP1)
only as in the past. You must also check the G/L period opening/closing (OB52).
Therefore, you have to allow postings to accounts from the Secondary Costs account
type in the G/L period opening/closing.
In the CO Period Lock, you need to specify which transactions you want to lock and for
which periods.
In SAP Accounting, it is also necessary to open accounts from the Secondary Costs
account type for FI postings.
In transaction OB52, for each variant you can specify which posting periods are open for
posting. You can choose period intervals 1 between and 3.
You can use period intervals 1 and 2 for all normal posting processes in regular and
special periods.
For period interval 1, you can enter a group of authorized users. This means that for
month-end or year-end closing, for example, you can open posting periods for specific
users only. You make the necessary authorization settings in the optional authorization
object Accounting Document: Authorizations for posting periods (F_BKPF_BUP). We
recommend using period interval 1 for special periods because authorizations can only
be managed here.
Period interval 3 is used for postings from Controlling (CO) to Financial Accounting
(FI). If you do not make an entry for period interval 3, the check on these postings is
made against period intervals 1 and 2. If you make an entry for period interval 3, the
check on these postings is only made against period interval 3. For each interval, you
specify the lower and upper limits of the posting period as well as the fiscal year.
You can also use the report RFOB5200. You want to use authorizations to control who
is allowed to execute the program RFOB5200 for the opening and closing of posting
periods in the background. See SAP Note 2251160.
Which accounting period version is checked? The leading ledger works with the
accounting period that is assigned to the accounting area. Non-leading ledgers can be
assigned different posting period variants.
Should the version of the not leading ledger not only be checked at ledger group
specific bookings but also for bookings with ledger group blank you have to determine
this by marking the field "Manage Posting Period" in the global parameters of the
company code.
Pregunta[DBE13]
Demonstration: How to Maintain Posting Periods[DBE14]
2.2. Managing Ledgers in SAP Accounting powered by SAP HANA
In the general ledger, everything is entered according to accounting rules. The posting periods
are locked after the month-end closing. The accounting rules cannot be changed.
In new General Ledger Accounting, different accounting principles are mapped using
the accounts approach. In addition to accounts, the new G/L also lets you use different
ledgers to save the different valuation approaches. This is called the ledger approach.
In an account approach, there is only one ledger, the leading ledger 0L. In a ledger
approach, there is next to the leading ledger other not leading ledgers. These ledgers are
all called standard ledgers. A standard ledger contains a full set of journal entries for all
business transactions.
In addition, other extension ledgers can be added. Extension ledgers are based on an
underlying ledger.
An extension ledger is assigned to a standard ledger and inherits all journal entries of
the standard ledger for reporting. Postings made explicitly to an extension ledger are
visible in that extension ledger but not in the underlying standard ledger.
An extension 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 (IFRS or Locale GAAP). Besides creating a
master record, Extension Ledgers do not need additional configuration. Reporting on
the extension ledger always includes the data of the underlying ledger (in the figure).
Multiple extension ledgers can point to the same underlying ledger. Benefit of reduced
data footprint and zero reconciliation effort as only delta values are kept.
Extension ledgers are stored in the universal journal - same as standard ledgers.
Extension ledgers can be assigned own booking period variants. This means the
standard ledger can be closed and the assigned extension ledger can be open.
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 in other ledgers.
With extension 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.
The underlying ledger has to be a standard ledger.
Only manual postings are allowed to the appendix ledger. Use the transaction with
which you can explicitly add the ledger group to the expending ledgers, for example,
KB11N, KB41N, FB50L, and FB01L.
ACDOCA stores the data for all extension ledgers.
BSEG does not store any extension ledger data, because you can only book ledger
specific onto the extension ledger the table BSEG_ADD is filled.
Implementing the BADI BADI_FINS_APPL_RELEVANCE allows you to feed
components like PCA, FI-SL, EC-CS with the data posted to extension ledgers. This
functionality should be handled with care. The BADI implementation must clearly
separate extension ledger data from the other data.
BSEG summarization can be used as usual (see SAP Note 2179270). BSEG is used for
storing open item and clearing details, so you can be aggressive with the summarization.
ACDOCA stores the full detail that is needed for all components that on ACDOCA
(G/L, AA, ML, CO, PA).
Summarize the BSEG table as much as possible. Conversely, summarize the ACDOCA
table as little as possible so that reporting that is differentiated as possible in the
ACDOCA table.
The summarization in the ACDOCA table can be as large as that of the table BSEG
since line items in the ACDOCA table cannot be summarized further than the
corresponding line items in the BSEG table.
In SAP Accounting powered by SAP HANA 1503, on-premise Edition, SPS 1511, or
S/4HANA 1511 or corresponding higher releases, a function has been implemented to
summarize the line items in the table ACDOCA and to summarize CO-PA profitability
segments.
You can find these, along with additional documentation, in Customizing by choosing
Financial Accounting (New) → Financial Accounting Global Settings (New) →
Document → Document Summarization. From here, you can also access the
summarization of the table BSEG described in SAP Note 36353.
Since the account-based CO-PA line items including the profitability segment number
and the resolved characteristic vector are stored in the table ACDOCA, the same
summarization settings are used for CO-PA profitability segment determination too.
You can find these settings along with documentation and the existing summarization
for costing-based CO-PA line items by choosing Controlling → Profitability Analysis
→ Flows of Actual Values → Initial Values → Summarization.
Pregunta[DBE15]
Exercise: Create an Extension Ledger and Post a document[DBE16]
In Customizing, choose Financial Accounting (New) → Financial Accounting Global
Settings (New) → Ledgers → Ledger → Define Settings for Ledgers and Currency
Types.
•
•
•
Transaction: FINSC_LEDGER
First Level:
o Master Data of Ledger
o Define the Leading Ledger
o Define additional Ledgers, Standard or Extension
o Set a Ledger as underlying Ledger only for the Extension Ledgers
Second Level
o Company Code Assignment to Ledger
o For the Leading Ledger: 0L
o All companies are assigned to the leading ledger.
The following currency fields are available:
•
•
•
•
•
•
Local Currency (Field HSL)
o Currency Type: always „10"
o All settings are fix.
Global Currency (Field KSL)
o Currency Type: always Currency Type of Controlling Area not used in
FI
Freely Defined Currency 1 (Field OSL)
o Currency Type: Standard Currency Type or Customer Defined Currency
Type
o Constraint: Standard Currency Type must also be configured in Leading
Ledger
Freely Defined Currency 2 (Field VSL)
o Currency Type: Standard Currency Type or Customer Defined Currency
Type
o Constraint: Standard Currency Type must also be configured in Leading
Ledger
Freely Defined Currency 3 (Field FSL)
o Currency Type: only Customer Defined Currency Type possible
Standard Currency Types
o 10 - 60
o Transactional currency conversion in all processes (filled online during
posting in all journal entries).
o Same restrictions as ERP and SAP Simple Finance, on-premise edition
1503 you can use maximal 3 Currencies in FI and 2 in CO.
o
All standard currency types must be configured in leading ledger.
You can configure up to 3 freely defined currencies per ledger.
In Period end, close the currency remeasurement run fills these currency fields.
Only the Standard currencies of FI/CO are transactionally converted.
Customer Defined Currency Types
•
•
•
•
•
Use the Namespace Y* and Z* .
The Customer Defined Currency field filled by Foreign Currency Valuation Run
(Transaction FAGL_FCV). Manual Valuation Posting (FIORI App) or BAPI
ACC_DOCUMENT_POST
No transactional currency conversion in all other processes (filled with 0,-).
No dependency on leading ledger, you can configure other customer defined
currency types in non-leading ledgers.
Use Case: Currency conversion in period end close with average respective
closing rates.
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 posting periods. Basis for check of leading ledger and
representative ledger in ledger group.
Parallel Accounting using G/L Accounts
In an account approach this spot has to be marked.
Third Level
Entries are only necessary for parallel financial reporting with an accounting
principle. Look at example Fi-AA.
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 ZZ<CUST>T, ZZ<CUST>A 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_<Industry>A,
V_<Industry>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.
Pregunta[DBE17]s
In the FAGLFTEXT totals table in the New General Ledger, the updated profit center,
segment, business, area, cost-of-sales accounting fields are also updated in S/4HANA
accounting in the universal ledger.
All known scenarios from the New General Ledger are turned on in S/4HANA
Accounting.
Customers who wish to draw up financial statements by business areas, profit centers,
or segments have to activate document splitting.
Note: The subsequent enablement activate document splitting is not available with SAP
Simple Finance, on-premise edition 1503 SPS 03 (11/2015) or SAP S/4HANA 511.
Document splitting is only for customers who have to or want to enter a further
characteristic. For example, a customer may want to enter a segment on the balance
sheet in addition to the company code.
A financial accounting document always has two views in S/4HANA Accounting: The
Data Entry and the General Ledger View.
Besides the leading ledger, you may also see the document in other, non-leading ledger
or Extension ledger in the General Ledger view.
You can display the profit and loss statement using the following objects:
•
•
•
Profit center
Business area
Segment
Line items are not displayed split in the Entry View.
The line items are displayed split in the General Ledger View, when using document
splitting.
For the entities defined as splitting, characteristics are inherited in posting lines where
the characteristics were not specified. In the figure, the balance of the profit center and
segment characteristics is zero.
The figure also shows the vendor and tax lines in the General Ledger View. The vendor
and tax lines (items 1 and 4) are split in accordance with the expense lines.
Document splitting, also known as an online split, enables companies to create complete
balance sheets for objects.
If you do not activate document splitting, then there is no difference between the Entry
View and the General Ledger View.
[DBE18]
An integrated app with all journal-related reports as well as some reports for audit
purpose.
This app consists of two parts:
•
•
Compact journal
Journal
The following functions are integrated:
•
•
•
•
Display Document Changes.
Check Multi-referenced Invoices.
Check Gaps in Document Numbers.
Display Updated Termination.
Pregunta[DBE19]
3. Asset Accounting
3.1. Analizing the Posting Logic of new Asset Accounting
New Asset Accounting is the only asset accounting solution in SAP Accounting on SAP
HANA. Classic Asset Accounting is no longer available. 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 EA-FIN Note:1498047).
Actual items:
•
•
Actual data of ANEP, ANEA, ANLP, ANLC is now stored in table ACDOCA.
ANEK data is stored in BKPF.
Compatibility views FAAV_<TABLENAME> (that is, FAAV_ANEK) are
provided to enable non-disruptive reporting on old tables.
After migration, access to the content of old tables is still possible via views
FAAV_<tablename>_ORI.
Non-actual items:
•
•
•
•
Statistical Line Item in Asset Accounting (for example, calculation for tax
purposes) are now stored in table FAAT_DOC_IT.
Planned Depreciations and Revaluations (previously ANLP and ANLC) are now
stored in FAAT_PLAN_VALUES.
Year-dependent attributes for depreciation are now stored in FAAT_YDDA.
Benefits from the Universal Journal integration.
The Universal Journal integration provides the following benefits:
•
•
•
•
•
•
•
No redundancy in data storage
Reconciliation between G/L and AA is ensured by design
No reconciliation step in financial close required
All non-statistical items are updated as Universal Journal Entries
Reporting for previous fiscal years is possible due to compatibility views
even after migration
Transparent assignment of depreciation area to accounting principle
Depreciation posted with all details: accumulated depreciation and depreciation
cost by asset
(Scroll vertical)
The simplification of Posting Logic provides the following benefits:
•
Auditability and simplicity
Independent and complete depreciation areas of equal power
•
Simplified Chart of Depreciation
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
Simple close, fast close, soft close
Transparency throughout the period
Asset balances in real time - APC posting run no longer required
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: The beginning and end of FY –Financial Year– must be equal.
Pregunta[DBE20]
[DBE21]
[DBE22]
For an integrated asset acquisition posting, the system divides the business transaction
into an operational part and a valuating part. For the operational part (vendor invoice),
the system makes a posting to all ledger groups against the technical clearing account
for integrated asset acquisitions. For the valuating part (asset posting with asset
capitalization), the system generates ledger-group-specific documents that it also posts
against the technical clearing account for integrated asset acquisitions.
For each ledger group that is assigned in your chart of depreciation, the system creates a
corresponding ledger-group-specific document. In this way, the system ensures that the
technical clearing account for integrated asset acquisitions has a balance of zero (for
each ledger and account assignment object) for every ledger group assigned in the chart
of depreciation. So that the system can ensure the zero balance, manual postings cannot
be made to the account. The account does not appear in the balance sheet, but in the
notes to the financial statement (since it has a zero balance).
Automatic postings are made to the technical clearing account for integrated asset
acquisitions for the following transactions: asset acquisition and investment support
measures.
Pregunta[DBE23]
The ledger approach results in three documents:
•
•
•
Technical Clearing Account Acquisition (TCA) to Vendor (The Ledger Grp and
Account. Principle fields are blank.)
Asset to TCA (Ledger Grp: 0L and Account. Principle: IFRS)
Asset to TCA (Ledger Grp: N1 and Account. Principle: LOCA)
To post transactions such as corrections, you no longer need a transaction type limited
to specific depreciation areas.
You can choose the accounting principle or depreciation area (transaction AB01L)
directly in the transaction view.
For secondary depreciation areas in the accounts approach, the account is posted to
Contra Account: Acquisition Value Posting, which is assigned in the account
determination, instead of the Technical Clearing Account. This approach results in
three documents:
•
•
•
Technical Clearing Account Acquisition (TCA) to Vendor (The Ledger Grp and
Account. Principle fields are blank.)
Asset to TCA (Ledger Grp: 0L and Account. Principle: INT)
Asset to TCA (Ledger Grp: LO and Account. Principle: LOC)
With an account approach there is only one ledger 0L. The ledger group 0L and LO
book in the leading ledger 0L.
Only relevant accounting principles are represented on the asset (or on the asset class)
by their corresponding depreciation areas.
All postings issued within FIAA affect those accounting principles that are relevant for
the involved assets only.
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 is 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 G/L, the system issues an error. This error notification can be changed into a
warning, in which case the statistical areas in FI-AA are updated.
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 also generated from Controlling.
For 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 are calculated automatically for the new
year after performing the balance carry forward.
See SAP Note 220832: FAQ for legacy data transfer in SAP_FIN 720 and subsequent
releases.
In the new solution, the master data continues to be created in transaction AS91 and
changed in transaction AS92. However, the takeover values are posted separately in the
new posting transaction ABLDT. When you do this, a posting is made to the transfer
clearing account immediately. In other words, the manual step for the summary writeoff is no longer required.
BAPI_FIXEDASSET_OVRTAKE_CREATE and transaction AS100 (which calls the
BAPI internally) have been fully adjusted to the new logic.
Transaction ABLDT uses an input-enabled ALV grid control. Therefore, according to
SAP Note 311440, it does not support batch input.
As an alternative, you can use BAPI_FIXEDASSET_OVRTAKE_CREATE. (See SAP
Note 2252940.)
In the case of assets under construction (AuCs), you cannot transfer cumulative APC or
accumulated depreciations.
In the manual case, with transaction AB01 (not transaction ABLDT) or, as of SAP Note
2294012, via the new transaction ABLDT_OI.
In the case of a transfer using BAPI_FIXEDASSET_OVRTAKE_CREATE, do not
enter the values into the CUMULATEDVALUES table; enter them into the
TRANSACTIONS table instead.
Pregunta[DBE24]
(Scroll vertical)
The Display Asset Worklist app provides an overview of the Fixed Asset Masters that
you are responsible for. Your area of responsibility can be defined by a flexible set of
filter values for company code, asset class, and other asset attributes.
From any single asset, you can do the following:
•
•
•
•
•
•
•
Navigate to other actions from any assets to other actions such as the Change
Asset Master or Display Asset Master.
Display the Asset Master Record Segment and the time dependent Asset Master
assignments in a personalized set of Asset Masters.
Focus on incomplete, in process, capitalized, or retired assets if needed. Display
the number of incomplete assets depending on the configured default filter
already on the launchpad.
Download selected assets to excel, e-mail a link to the personalized list or share
it by mail.
Save a personalized and filtered list as a tile to your home page.
Role: Asset Accountant
Target Segment: Financial Department
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.
Planned depreciation is determined and updated with each asset master record change
and each posting to the asset. The depreciation run posts the precalculated 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 view is simplified as the Reasons for posting run (planned depreciation
run, repeat, restart, unplanned posting run) are no longer relevant.
Exercise: Post Integrated Asset Acquisitions[DBE25]
3.2. Configuring New Asset Accounting
In Asset Accounting (New), the system must ensure that all ledgers in which the
company code updates its balances in the general ledger are also updated via Asset
Accounting. (See SAP Note: 2147666.)
For every additional currency type defined on the company code, set up a
corresponding depreciation area. In Asset Accounting (New), the system ensures that all
currencies that update balances in the general ledger are also updated via Asset
Accounting. For every additional currency type defined on the company code, a
corresponding depreciation area must be set up. (See SAP Note: 2180591.)
Ensure that both settings are correct before migration.
All depreciation areas representing the same accounting principle are assigned to the
same accounting principle (and ledger group). 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 cannot be initial (blank). The same
accounting principle can be assigned to several depreciation areas, as long as the areas
represent the same valuation. For every additional currency type defined on the
company code level, configure a corresponding depreciation area.
With Asset Accounting (New), the Posting Indicator supports four different values:
•
•
•
•
Area does not Post
Area Posts in Real-time
Area Posts Depreciation Only
Posts APC Immediately, Depreciation Periodically
For the depreciation areas, adjust the Posting Indicator.
For the ledger approach, the leading area of the parallel valuation also contains the Area
Posts in Realtime option.
The accounting principles (AccP) GAAP refer to Ledger Group 0L. Ledger Group 0L
includes the Ledger 0L.
The accounting principles LOGA refer to Ledger Group L6. Ledger Group L6 includes
Ledger L6.
The second leading area of the parallel valuation receives the option Posts APC
Immediately, Depreciation Periodically.
In Customizing, choose Financial Accounting (New) → Financial Accounting Global
Settings (New) → Ledgers → Parallel Accounting → Assign Accounting Principle to
Ledger Groups
In Customizing, choose Financial Accounting (New) → Financial Accounting Global
Settings (New) → Ledgers → Ledger → Define Settings for Ledgers and Currency
Types
In this Customizing path, Company Code Parallel Account Approach is used and the
accounting principles are assigned.
The Accounting principles LOGB refer Ledger Group XB includes to Ledger 0L.
The Accounting principles LOGC refer Ledger Group XC includes to Ledger 0L.
This is different to the classical account solution where the carrying costs and valuation
accounts have to also use the identification reconciliation account. You can set this
identification for already booked control accounts in Customizing by choosing
Financial Accounting (New) → Asset Accounting (New) → Preparations for Going Live
→ Production Startup → Accounts Approach: Set/Reset Reconciliation Accounts for
Parallel.
The clearing accounts cannot be OP leading accounts.
(Scroll vertical)
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.
You get the entry 00 when the current value is deleted. In the system, push Enter to set
the value to 00. This is not optional.
The valuation area, which portrays the parallel values, receives identical marks.
Deduction can now be carried out from a higher number.
Characteristics of the 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
o Ledger approach: always balances to zero per ledger group and account
assignment.
o Account approach: always balances to zero together with the account
Contra Account: Acquisition Value Posting in your financial statement.
Different Technical Clearing Account for Asset Acquisition for specific account
determinations are possible, for example, to set different field status for the text
field.
The following prerequisites must be met:
•
•
•
The account is a balance sheet account created as a reconciliation account for
fixed asset accounts.
We recommend that you do not allow the management of line items because
the account is a reconciliation account.
The account cannot be defined in the account determination for Asset
Accounting (for example, tables T095, T095B, T095P).
In this activity, you specify which depreciation area you want to use for updating
quantities. This setting is especially relevant if you are using collective low-value
assets.
The quantities in the asset master record are only updated if postings are made to the
specified area.
For the purpose of compatibility with earlier versions of Asset Accounting, the system
uses depreciation area 01 for updating quantities unless you have configured different
settings.
If you change the depreciation area used for quantity update, the quantity information in
the asset master records is not changed. Asset subledger posting documents to which
postings were made before the conversion, keep their quantity information and the
quantity is reflected in the asset master record. When a document that was posted before
the conversion is reversed, the quantity is also adjusted regardless of whether postings
are made to the depreciation area that is now being used for quantity update.
Also note that any quantity adjustments made in the asset master record by means of a
report, can only include the quantity in the header of the asset subledger document and
that the configuration specified cannot be evaluated. If you are unsure of how to
proceed, we recommend that you adjust the quantity information by maintaining the
asset master record (transaction AS02).
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. For example, if you use a document split or when external number ranges for FIdocuments are used for logistics invoice verification.
In this step, you specify at company code level how the system is to distribute revenues
arising from asset retirements. That is 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.
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 (For example, legal requirement in France - French Retirement):
The restriction of the posting logic to certain depreciation areas was done in classic
Asset Accounting using area types.
In new Asset Accounting, it is not possible and also not necessary to restrict transaction
types to depreciation areas. You restrict the 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.
Note: After a system migration, all transaction types previously restricted to
depreciation areas should be set to obsolete.
4. Reporting
With embedded analytics in SAP S/4HANA, everything is on the same technical stack and uses
the same user interface. This structure improves the time to customer (TCO) and helps the
user to be more efficient. The embedded analytics are available inside the business processes,
making the processing more efficient. The simplified data model reduces the redundancy of
data and so more space is available to keep a longer data history. The simplified data model
reduces the number of tables, making it easier to create Virtual Data Models.
SAP S/4HANA blends transactions and analytics allowing operational reporting on live
transactional data.
With SAP S/4HANA, this concept is supported by SAP Core Data Services (CDS
views) for real-time operational reporting. The content is represented as a Virtual Data
Model (VDM), which is based on the transactional and master data tables of SAP
S/4HANA. CDS views are developed, maintained, and extended in the ABAP layer of
the SAP S/4HANA system. The system generates SQL-Runtime-Views in SAP HANA
to execute the data read and transformation inside the SAP HANA Database Layer.
The database developer defines the data-persistence and analytic models that are used to
expose data in response to client requests via HTTP. With CDS, you define a
persistence model that includes objects such as tables, views, and structured types. The
database objects specify what data to make available for consumption by applications
and how that data is made available.
Note: For more information on CDS view:
http://help.sap.com/hana/SAP_HANA_Core_Data_Services_CDS_Reference_en.pdf
SAP provides the following out of the box:
•
Consumption Views: Consumption views are public domain-specific views for
analytics, search, and transactional applications.
The Consumption Views can also be consumed via oData services on the SAP
Gateway. The oData services allow SAP Fiori, SAP BI Tools, and third party
UI/Clients to access the Consumption Views directly or via the Analytical
Engine.
•
•
•
Interface Views: Interface views are public, stable, and reusable views for any
consumer.
Private Views: Private views are auxiliary technical helper views. They are not
part of the public interface.
Customer-Defined Extensions: Customer-defined extensions to SAP-provided
objects are possible.
Note: For more information, see
https://wiki.wdf.sap.corp/wiki/display/SuiteCDS/VDM+CDS+Development+Guideline.
At the bottom we have the SAP Business Suite tables in SAP HANA. On top of these
tables we have the CDS view. These CDS views are ABAP Objects and are defined and
handled in ABAP, but they also create SAP HANA views (code push down).
In the ABAP application layer, the Analytical Engine and the Enterprise search use the
CDS view. The transactional logic can use CDS views with the new applications, but
some old applications still access the Business Suite tables directly.
The Analytical Engine is the SAP BW component available in every SAP Business
Suite system. It provides functionality that is not yet available in SAP HANA such as
pivoting, hierarchies, aggregations, and formula execution.
The frontend applications use mostly oData as a communication protocol inside the
SAP Fiori interface. There are some exceptions that use the InA protocol because they
have no oData implementation currently: such as Lumira, Design Studio, and Search.
You require data consumption tools that help you discover and analyze areas to
optimize your business, with which you can adapt data to your business needs. You
want to visualize a story with this data so that you can present it. These requirements are
covered by SAP solutions such as SAP Lumira, SAP BusinessObjects Explorer, and
Analysis for office.
Dashboards and applications are also available to build engaging experience to deliver
engaging information to users when they need it, Track key performance indicators and
summary data and build custom experiences so users get what they need quickly.
Consolidated concise information is thus updated and provided to the user directly. For
this, you can use design studio, dashboards (Xcelsius), and smart business.
On the reporting end, to share information you need to securely distribute information
across your organization, give users the ability to ask and answer their own questions,
and build printable reports for operational efficiency. For this you can use for example
Web intelligence, Crystal reports, or even FIORI analytical applications.
The SAP S/4HANA for Analytics roadmap shows three types of users. Depending on
the role inside a company, a user will fall into one of the following user roles categories:
•
•
•
The IT user who develops CDS view, new apps, and planning functions.
The Analytic key user who creates, maintains queries, predefined reports, KPIs,
dashboards tiles, and enables the end users to find the right reports.
The Analytic end user who works with the different analytical tools to consume
the data, perform analysis, and act accordingly.
There are several distinct types of reporting, according to these specific requirements
you should utilize specific frontends. SAP offers a clear frontend recommendation for
each type of report, grouping reports into as few report types as possible.
The table in the figure helps you, based on specific requirements, to decide on the
frontend tool to use.
For example:
•
•
•
•
•
For interactive drill-down, the recommended frontend is SAP BusinessObjects
Design Studio. Alternatives include SAP BusinessObjects Explorer, SAP BEx
Analyzer, and so on.
For planning data entry, use SAP BusinessObjects Design Studio.
For reporting, use SAP Smart Business, executive edition.
For explorative ad hoc reporting, the best tool is SAP BusinessObjects Lumira.
For formatted reporting, use SAP Crystal Reports or an Adobe forms solution.
(Scroll vertical)
https://www.youtube.com/playlist?list=PLs5htBIwERYWFt-ixnVgxsUGvQpR9E8hI
https://www.youtube.com/playlist?list=PLs5htBIwERYUA748i26Z9Y0Z2dXw3s29E
https://www.youtube.com/playlist?list=PLs5htBIwERYXTVP--IvbjaTJF0enYv6kK
https://www.youtube.com/playlist?list=PLs5htBIwERYW9NthcmsyCMSMNwJhF6QP5
https://www.youtube.com/playlist?list=PLs5htBIwERYUjNLyWJR2g2U2aSWPzJBou
https://www.youtube.com/playlist?list=PLs5htBIwERYWqmHlnbAB6gSQ3b39JzWLa
https://www.youtube.com/playlist?list=PLs5htBIwERYULWPdq3xdVb6R68Up_kCFu
https://www.youtube.com/watch?v=sRjrhralEHE
SAP S/4HANA Analytics together with SAP Business Warehouse (SAP BW), provides
the best-of-breed suite of analytical services.
Requirement examples covered by SAPBW include:
•
•
Consolidated, de-normalized reporting on data collected from several SAP and
non-SAP applications, and for data governance
Aggregated reporting on historical data that might not be online in the
underlying SAP Business System
For a case study with implementation scenarios of SAP BW together with SAP
S/4HANA Analytics see: http://scn.sap.com/docs/DOC-55312
Pregunta[DBE26]s
Demonstration: Test Analytical Queries with Transaction RSRT[DBE27]
Exercise: Output a Financial Statement[DBE28]
Exercise: Use Analysis for Office Trial Balance[DBE29]
Exercise: Use SAP BusinessObjects Lumira to visualize data[DBE30]
5. Other Topics
5.1. Understanding Central Finance
Customers with large distributed system landscape lack full insight into the entire
company. There is usually no trustworthy consolidated source of truth that provides
insights with a harmonized view. Often the process is to load financial data from
distributed systems into various data warehouses, for example, SAP Business
Warehouse (SAP BW), in order to report on figures for the entire company. In order to
load the data to the data warehouse, long batch-jobs must be scheduled regularly to
extract data, to transform the data, and to load data into the data warehouse. This
typically does not happen in real-time, but rather once a day, week, or even month. The
consolidated data available in the data warehouse that is used for analysis and to make
business decisions is never up-to-date.
The data quality provided by the source systems is often very poor as a data warehouse,
in contrast to an ERP system, accepts the data without checking whether it is correct. It
also takes enormous effort to reconcile the data that is aggregated, transformed, and
consolidated with the data available in the source systems. Many customers develop
custom-logic to improve the data quality, performing similar checks like what the
Financials component of SAP ERP performs when a document is posted.
Business challenges include:
•
•
•
•
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 and effectiveness: people do not receive the data they need to make
a decision
The benefits of SAP S/4HANA Finance are clear but how do you get there? The bigbang project it would take to adopt SAP's latest innovations would be too large and
expensive to get through a budget committee and too taxing to the daily operation of the
departments.
Central Finance offers a non-disruptive step towards system consolidation. It helps
companies report on financial figures sourced from different systems. These systems
might be running Classic G/L or the New G/L. The systems may have different
customizing settings and diverse master data such as Chart of accounts, Controlling
Areas, Operating Concerns, Material Numbers, Product Hierarchies, and so on.
Reposting through the Accounting Interface to a Central Finance system harmonizes
data but also retains line item-based detail.
A Central Finance system can be established either On Premise or in the Cloud. In a
Cloud, deployments scenario data is replicated using the same mechanism, which is
used in On Premises installations.
Therefore, the respective SLT portions have to be available on both the sending and
receiving system. Non-SAP reporting and analytics as well as additional SAP Simple
Finance or partner products need to be connected to the cloud instance or should be
made available within the cloud installation as required. Special considerations in the
Cloud scenario include the bandwidth and throughput of the WAN Network and
firewall security requirements of the IT Department.
On the left of the figure, you see the source systems - these are the SAP ERP systems
that you do not want to change. They can be on any release of SAP (out-of-the-box
functionality supports systems down to ERP 6.0 - older releases have to be integrated in
a services project), or a non-SAP system. Often they have been over-customized,
making it too expensive to migrate or upgrade the system to take advantage of new
innovation.
Data is replicated into the Central Finance instance using the SAP Landscape
Transformation Replication Server (SAP SLT). The SLT can be located on premise or
in the SAP HANA Enterprise Cloud. It pulls the data directly from the database without
having to adapt to programs of non-SAP applications.
There is a Central Finance Accounting Interface, which reposts documents and creates
certain more ephemeral cost objects.
Next, master data is mapped, either using SAP Master Data Governance (MDG) or
another MDG solution (which can be in the same system or somewhere else in the
landscape, or in the case of SAP MGD, deployed in SAP HANA Enterprise Cloud); for
customers that do not have an existing Master Data Governance solution, there are basic
mapping tables in the solution for key master data (chart of accounts, customers,
suppliers, etc). There is also a Business Add-In (BAdI) which can be used for customerspecific mapping logic.
Error correction capabilities for FI documents are provided by the Error Correction
Suspense Accounting functionality; this provides a worklist-based approach for
correcting replication errors or mapping errors. Once the mapping and checks have been
completed, all postings go through the standard internal Accounting Interface into
FI/CO (in the SAP HANA database).
Through SLT there are three interfaces that feed data from the source systems into the
Accounting Interface of the target system:
•
•
•
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 are
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 entry of the SAP S/4HANA
system. It is possible to take advantage of New-GL features within the Central Finance
system as well as the ability for flexible reporting based on line-items instead of preaggregated totals. Furthermore SAP Fiori user interfaces and reporting tools can be used
in the Central Finance. Reporting with the speed of SAP HANA is available on lineitem levels.
If SAP MDG is not used by the customer, the mapping is maintained manually in a user
interface. There are two kinds of mapping entities:
•
•
Keys: these are the master data that are typically created every day distributed
throughout the system landscape, such as customer, material, vendor, G/L
account.
Values: these are rather like customizing and more stable. They are often used
within master data that is distributed (for example, a customer is assigned to
certain dunning areas, payment terms, and so on).
In the document header of the newly posted FI document in the Central Finance system, new
fields have been added to reference back to the original FI document. By double-clicking on
the reference document number, it is possible to navigate back to the source SAP ERP system
to view the original FI document.
The new posting offers improvements to the current Business Application Programming
Interface (BAPI) (better extensibility, industry solution inserts, custom fields and so
on), it is not limited to 999 line item limit anymore and is purpose built for Central
Finance use.
Master data harmonization in existing distributed landscapes is a real challenge.
Documents have to be "forced to fit" and stocks are reposted or transferred. One major
benefit of Central Finance is that master data mappings are performed before reposting
in the central system. This allows harmonizing the different master data of the various
source systems on the fly. As a consequence a harmonized financial reporting can be
achieved across the entire group. The new system will be "clean".
The main restriction when implementing is for the centrally executed processes to not
result in back-postings to the source systems to maintain the integrity (completeness and
so on) and legacy system status of those systems.
When implementing Central Finance, the amount of configuration, customizing, and
master data synchronization required depends on the scope of the processes desired.
Many scenarios, especially core G/L scenarios, are achievable with limited effort. More
complex scenarios, or scenarios beyond (core G/L) Finance might be challenging or in
certain cases not feasible.
5.2. Introducing Cash Management powered by SAP HANA
The figure shows how SAP Cash Management powered by SAP HANA has three major
components: Cash Operations, Liquidity Management, and Bank Account Management. These
components are part of Cash and Liquidity Management.
Integrated Treasury and Cash Platform is a solution built on the SAP HANA platform.
It is a part of the SAP Simple Finance on-premise edition and One Exposure serves as
the technical foundation. Upon that we have Bank Account Management, Cash Mapped
Operations and Liquidity Management for SAP Cash Management powered by SAP
HANA. SAP Treasury and Cash Solution also provide the solution functionality
relevant to payments, transactions, in-house bank, bank statements, monitoring, and also
signatory management.
SAP Treasury and Cash Management also provides transaction management such as FX
management, Debt Management, and so on. The market place information and market
data accounts can be imported by the interface into the Treasury and Cash Management
solution. The solution can be connected to the Banks via different channels, for example
by Swift and SAP FSN. With respect to integration, SAP Treasury and Cash
management can integrate with other SAP and non-SAP systems through One
Exposure.
In the figure, the dark blue parts are contained in SAP Cash Management powered by
SAP HANA. The other treasury applications are installed on top, and work as before,
and when combined form a treasury workstation.
SAP Cash Management powered by SAP HANA is a part of SAP Simple Finance on-premise
edition for SAP Business Suite powered by SAP HANA. There are two other products, SAP
Accounting powered by SAP HANA and Integrated Business Planning. SAP Cash Management
powered by SAP HANA provides the major functionality of centralized bank account
management, daily cash operations, cash position, liquidity forecast, actual cash flow analysis,
and rolling liquidity planning. The whole solution provides an instant insight by leveraging SAP
HANA to the end users as part of the suite. Meanwhile, it provides intuitive user experience to
support different devices like laptops, iPads, and smartphones. The solution can be deployed
in cloud or on-premise.
By using Bank Account Management, the customer has a centralized bank account
management platform to manage all the bank accounts within the company especially
for the heterogeneous system landscapes comprising of SAP and non-SAP systems.
Customers can also manage the life cycle of bank accounts, for example, opening bank
accounts, changing, reviewing and closing bank accounts. In the new solution, the bank
account master data is no longer configured - that means the master data for the banks
account can be fully changed by the business users instead of seeking support from IT
colleagues in the future.
In cash operations, we provide short term cash position analysis from the same
application, the Cash Manager can make or track bank transfers directly. In Liquidity
Management, we provide mid term and long term liquidity forecasts with dimensions
for analysis of liquidity and actual cash flow analysis to identify the use and source of
actual cash movements. The embedded Rolling Liquidity Planning can help the
customer to manage the rolling liquidity planning process and there are also various
analysis tools to do the actual forecast and plan analysis.
In the new solutions, we provide SAP Fiori (a HTML5 user interface) and the KPI
cockpit - SAP Smart Business for Cash Management record. This solution is aimed at
manager who perform high-level analysis. The solution is also integrated with FI, SAP
Fiori, BCM and IHC components. As an example of these features, if you perform
transactions in the TRM component, the cash relevant information is created
immediately in the cash management site and is displayed in the cash position.
In the Bank Account Management, many attributes that reflect the information and
controls for both the bank and company are provided.
Customers also have the flexibility to extend attributes according to their own special
requirements.
The solution provides bank hierarchy to reflect the bank structures. There is also a free
style bank account group in which to group the bank accounts according to different
views of the end users.
The signatories maintained in the new Bank Account Management master data can be
integrated with BCM payment approval simplifying signatory management.
For the approval process for opening, changing, and closing bank accounts, we provide
the workflow to manage the approval process in the company. SAP delivers predefined
workflow steps. These workflow steps are flexible so customers can change or define
the workflow according to their requirements.
The bank accounts review process helps the customer to review bank accounts yearly or
quarterly. The Cash Manager can initiate the review process. Later, the internal contact
person can review the bank accounts and finish the workflow. The cash manager can
have a very quick review of all the review processes for the bank accounts.
We also provide the Upload and the Download Bank Accounts functionality to help the
customer, for example, to migrate of bank accounts or to perform mass change of bank
accounts. All bank accounts can be downloaded into an Excel file, where the change can
be performed. The Excel file can then be uploaded to the system.
For Simple Finance customers who do not purchase the SAP Cash Management
powered by SAP HANA license, we provide a light version of Bank Account
Management, called BAM Lite. Here we provide the basic functionality of maintaining
bank accounts including house bank accounts.
The cash operations solution for the day-to-day management of the cash can help the cash
manager to monitor the status of incoming bank statements. This is critical information for
cash position analysis. Using this analysis, the cash manager can prepare the daily forecast of
cash receipts, disbursements, and expected closing balance. We also provide functionality to
help the cash manager to oversee the bank risks such as how much money is in the bank with
low, high risk, or low rating. We also provide the functionality to initiate the bank transfers
from the cash position analysis. There is also a functionality to approve and monitor the
payments.
Liquidity Management provides the complete lifecycle management of rolling liquidity
planning.
The system also provides the reference data to help the cash manager to plan the
liquidity precisely and easily. The reference data includes the liquidity forecast data, the
actual data, and also the planning data from previous planning cycles.
Liquidity Management also provides functionality to plan hedging of operating
activities for foreign currencies.
For analysis purpose, Liquidity Management provides Plan/Plan, Plan/Actual and
Plan/Forecast comparisons. We also provide functionality to alert, if there is significant
difference between the plan and the actual. There are alerts to inform the cash manager
to take at the root cause.
Liquidity Management also provides the liquidity forecast for mid-term forecast of
liquidity for the company and also the actual cash flow analysis to find the root, use,
and source of cash flow.
(Scroll vertical)
The figure provides a list of transactional and analytical SAP Fiori apps for different
major components in Cash Management. You can also find here the detailed
information of all the SAP Fiori and Smart Business Apps in the following link:
https://go.sap/kya
All apps, no matter whether they are Web Dynpro, HTML GUI or SAP Fiori apps, can
be executed in the SAP Fiori launchpad so end users do not need to switch UI clients.
(Scroll vertical)
Bank Account Management is a brand new function in SAP Cash Management powered
by SAP HANA. In classic Cash Management, there are House Bank and House Bank
Account. However, they are configurations and there is no equivalent function for cash
manager to manage bank accounts as master data.
For Cash Position, the new Cash Management provides several SAP Fiori and Smart
Business apps to perform position and liquidity analysis including Cash Position Smart
Business, Cash Position Details, Analyze Payment Details, and so on.
For Liquidity Forecast, there is currently only the e Smart Business app for high-level
analysis of liquidity. Soon, we will provide the SAP Design Studio-based version of
Liquidity Forecast for professionals. This app will allow cash managers to analyze
forecasted cash flows using different dimensions with drill-down capability for payment
details.
For actual cash flow analysis, in the new Cash Management, we have cash flow analysis
for professional users. In SAP ERP, we have Liquidity Planner as a separate component
from Cash Management for FF7A and FF7B. The analysis dimension is different
between the classic Cash Management (FF7A and FF7B) and the Liquidity Planner. In
the new Cash Management, we have simplified and unified the data model into one
which means that we have unified analysis dimensions for cash position, liquidity
forecast and cash flow analysis.
The new Cash Management provides a Rolling Liquidity Plan function with an
embedded planning framework. This means customers do not need to set up a separate
and standalone BPC server for planning, nor is it necessary to set up the ETL tool to
regularly import the master data and transactional data into the planning application.
With the embedded liquidity planning, master data and transactional data are retrieved
real time directly from the system.
For Memo Records, in the new Cash Management we enhanced the classic SAP GUI
transaction FF63 with additional important information of House Bank, House Bank
Account, and Liquidity Item. The end user can directly enter any information when they
create the memo records and the memo records will be displayed in the relevant cash
analysis reports.
For Transfer Cash functionality, we have Make Bank Transfer and Track Bank Transfer
in the new Cash Management, while in the classic Cash Management we have two
transactional codes for the same. From the user experience perspective, Make Bank
Transfer and Track Bank Transfer is simple and easier to use.
See Release Scope Note 2149337: https://css.wdf.sap.corp/sap/support/notes/2149337
(Scroll vertical)
Here you can find the relevant information and you can check in detail the release information
note, release scope note, and also the configuration and data setup guide. The data set up
guide is used to guide the customer to migrate the existing transaction data in the context of
Cash Management.
6. Post-Assessment
(Scroll vertical)