Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
In this Blog let us try to answer the crucial question: Is there a Single Source of Truth with Universal
Journal?
I have tested this concept in SAP S/4HANA Finance, On-Premise edition 1.0 on SAP system which will
be released to market in Nov 2015.
Interestingly, SAP has changed the name of Simple Finance (again). The name 'SAP S/4HANA Finance'
has been introduced in September 2015 and replaces the former name 'SAP Simple Finance'. So you
start seeing this new terminology in my blogs.
SAP Single Source of Truth with Universal Journal
Before we answer this question, let us get a small introduction. The Universal journal entry eliminates
the need for the separation made previously between Financial Accounting (FI) and Controlling (CO)
(single source of truth). There is a combined FI and CO document linked with a logical document. All
the information is recorded in 1 line item table (ACDOCA).
Since financial accounting and managerial accounting are reconciled constantly, there is no longer any
need for reconciliation between FI and CO or between FI-GL and FI-AA. Nor is there any need for the
real-time integration of these components. The reports in all components use data from the same
journal and thus known as Universal journal.
For this functionality to work there is a change in master data, architecture of the tables and also in
configuration. Let us see the major changes in these areas. All cost elements (primary and secondary)
need to be portrayed as G/L accounts. Consequently, we no longer need to enter the master data for
cost elements separately; instead, we only need to create G/L accounts from now on. You will not find
any transactions related Cost elements. Below screen-prints between ECC EHP7 for SAP ERP 6.0 and
S4HANA ON PREMISE 1.0
Now, let us see what does the one source truth means in SAP system.
I posted a FI document which triggered entries in BSEG, FAGLFLEXA, FAGLFLEXT, COBK, COEJ and COEP
tables (and some more BSIS, etc) in ECC. Compare it with a posting in S4HANA ON PREMISE 1.0, all the
information is recorded in BKPF (header) and ACDOCA (line items). Thus reducing the foot print
drastically.
What will happen to old tables? Updates are no longer made to these old tables. Nevertheless, you can
continue to use reports that use data from these old tables. This is because compatibility views for a
data request from one of these tables read the data from ACDOCA.
Let us compare the views in these ECC tables with ACDOCA.
FI tables
CO Tables
Now, let us review with one use case by posting FI document to a P&L acct with cost object as
profitability analysis. Note this S4HANA ON PREMISE 1.0 system had Account Based COPA active.
There is no separate COPA document visible in the accounting document workflow (refer the screen
print), a controlling document is a logical document. Real-time integration is no longer applied.
Instead, CO transactions are posted directly as an universal journal entry (ACDOCA). As secondary cost
elements are also contained in the chart of accounts, account assignment to a different account is no
longer necessary.
Analysis on ACDOCA:
This universal journal can easily be extended with the coding block and adding CO-PA characteristics
(refer the below screen print). Also, actual data posted will be stored in ACDOCA with all the
Characteristics defined in the operating concern. These standard coding block extensibility and
customer fields are added automatically to the universal journal.
Adding to the advantage, reporting based on the ACDOCA data is fast and flexible. Business
Intelligence (BI) frontend tools can be used for operational reporting, thus the benefits of BI tools are
inherited by the transactional system. Also, each journal entry contains the ledgers to which the
business transactions are posted.
The below table will give an snap shot of what has changed in COPA area.
Since SAP has redesigned their architecture on account based costing, the tables impacting are also on
account based.
Architectural Analysis:
COEP table will still exist and be written with entries except for Value type 04 and 11. ACDOCA will
get updated with 04 and 11 value type.
Compatibility views for tables are available on all traditional tables. E.g.: V_COEP. This is very helpful;
since customers who have build programs with these traditional tables can still use them. Via this view
the select is redirected to the new table ACDOCA.
Access to old table data is still possible with V_tablename_ORI e.g. : V_COEP_ORI, V_FAGLFLEXA_ORI,
etc.
COBK still will be written as before.
COSP and COSS will all be written directly to ACDOCA.
New tables COPS_BAK: Primary cost: Planned cost and commitments and COSS_BAK : Secondary cost
: Planned cost and commitments, will be updated with entries other than value types 04 and 11.
Conclusion:
Is there a Single Source of Truth with Universal Journal? Friends, if you have reached till here in this
blog, then you would be able to answer this question easily. Yes, SAP has delivered what they promised
in this area. Further to my explanation above, the universal journal entry has its own currency fields.
This brings the currency concepts used in FI and CO closer together. Also, to substantiate this answer,
a big advantage of this universal journal is that reconciliation efforts are enforced by design.
There are few things to improve in future from my view. As explained above, the Universal Journals can
be extended with customer COPA characteristics this means if a customer has multiple operating
concerns then all the characteristics will be included in the journal. This might cause an issue and will
increase the fields unnecessarily. Also, the idea of keeping CE4XXXX table is unclear now since there is
only one table to navigate and all the characteristics are filled directly in Universal Journal. There is no
use of this table anymore. Having said this, still this concept has enormous advantage for customer.
Overall, after a long wait, SAP has successfully completed the task of brining different sources into one.
Thus, with S/4HANA Finance/Simple Finance has a Single Source of Truth with Universal Journal.
AP Simple Finance
G
Previous postNext post
Hi Friends, I am starting this blog series to provide details on some of the key new features of Sfin 2.0
/ Simple Finance 1503 on premise edition.
Today I want to talk about the changes Parallel ledger and functionality of using Appendix ledger.
We will talk about the change in customizing, feature and how it helps in reducing data volume.
Change in Configuration
To assign additional ledger to company code in the Simple Finance, these is few change in the location
of customizing nodes
So if you see the above node, the assignment of Ledger to Company code is moved from the ledger
menu.
Now the assignment is going to be done under the initial preparation steps for Simple Finance
Migration
The node is "Define Settings for Journal Entry Ledger"
Standard: A standard ledger contains a full set of journal entries for all business transactions.
Appendix: An appendix ledger is assigned to a standard ledger and inherits all journal entries
of the standard ledger for reporting. Postings made explicitly to an appendix ledger are visible in that
appendix ledger but not in the underlying standard ledger. This concept can be used to avoid
duplication of journal entries if many business transactions are valid for both ledgers and only a few
adjustments are required in the appendix ledger.
G
For our example we will define another ledger A1 and use it. We will define it as an Appendix ledger.
When you define an Appendix ledger , it also should have a base ledger which is the main ledger for
the appendix ledger. For our example we will keep base ledger as "0L".
Now we do a normal FB50 posting and see its affect on ACDOCA table:-
Note We see entry for both 0L and N1 ledger but not A1 as it is an appendix ledger.
Now we will do a ledger specific posting in ledger A1 itself using FB50L and compare how ACDOCA
looks like
G
Now as you can see the ledger specific entry gets posted only to A1 ledger, which is similar to behavior
in SAP New GL.
The key difference is that for appendix ledger entries do not flow in all cases, only when ledger specific
posting are made.
A short answer would be It doesn't . It would be great if someone from SAP too confirms it.
To demo this, we first assign an accounting principle to our Ledger & Company Code combination
Next we will try to change our COD / Chart of Depreciation and see if we can use / assign this
accounting principle
G
Once we try to save it gives an error as the Target group is already assigned to main accounting
principle / GAAP.
So for the appendix ledger and its assigned accounting principle the ledger group will always be 0L or
the base ledger.
Hence it will mean that we cannot use appendix ledger (only) for the new asset accounting as you
would always have 0L assigned to your main GAAP.
This is another criteria to evaluate your use of Appendix ledger
Another criteria will be the use of New asset accounting and having cases where we have some asset
posted to only a single GAAP / Accounting principle.
If these scenarios are present, then you cannot use appendix ledger to maintain those.
So these are the two main criteria for business / consultant to check before using appendix ledger.
Hope this blog helps, I will take up another concept in the next blog in the series.
Next Blog in the series:SAP S/4 Finance blog series-2-Reporting options with COPA as use case
IBP Setup and overview
SAP S/4 Finance blog series-3-SAP Integrated Business planning-Overview & Setup
G
Depending on customers requirements and roadmaps there are different transition paths to SAP
S/4HANA. The following figure displays an (abstract) roadmap of a specific customer on his journey to
SAP S/4HANA, on-premise edition. This customer is planning to move to SAP S/4HANA with a roadmap
which goes over several years. First the customer moved to SAP Business Suite on HANA, now he plans
to go to SAP Simple Finance, on-premise edition and then as a third step to SAP S/4HANA, on-premise
edition which does include application innovations in logistics area.
Figure 1: Move to SAP S/4HANA, on-premise edition a possible customer Roadmap in several steps
In addition to the technical move to SAP S/4HANA this specific customer is simplifying their overall
system landscape. Currently, several SAP Business Suite Systems are used in the different regions;
however, a central SAP S/4HANA system per region is planned as a target.
For a different customer, a different roadmap might be applicable. The following figure gives an outlook to
the to SAP S/4HANA, on-premise edition 1511 (Q4/2015 delivery). Here, it is planned to offer a path
where the customer can move to SAP S/4HANA, on-premise edition 1511 (Q4/2015 delivery) from a SAP
Business Suite start release (for example SAP ERP 6.0) still on anyDB.
Figure 2: Move to SAP S/4HANA, on-premise edition 1511 (Q4/2015 delivery) a possible futureroadmap
Today (as of June 2015) a customer can join the SAP S/4HANA family by installing SAP Simple Finance.
In different documents you can find the term exchange innovation add-on, because SAP Simple Finance
replaces the classic ERP Financials with application innovation in the financial area.
More information about SAP Simple Finance, on-premise edition can be found here:
Compatibility of enterprise extensions, industry solutions, and add-ons can be found in SAP
Note 2119188.
With the installation of SAP Simple Finance on-premise edition, several software units are installed.
One-Step Procedure for customers on anyDB, ABAP AS 7.0x, SAP ERP6.0 EHPx
One-Step Procedure for customers on SAP HANA, ABAP AS 7.40, SAP ERP6.0 EHP7
Figure 4: SAP Simple Finance, on-premise edition 1503 - One-Step Procedure for customers on anyDB, ABAP AS 7.0x, SAP
ERP6.0 EHPx
Figure 5: SAP Simple Finance, on-premise edition 1503 - One-Step Procedure for customers on SAP HANA, ABAP AS 7.40, SAP
ERP6.0 EHP7
Figure 6: SAP Simple Finance, on-premise edition 1503 - One-Step Procedure for customers on SAP Simple Finance add-on 1.0
Additional Remarks:
It is planned to deliver further innovations for SAP Simple Finance in 2016. It is planned to
provide appropriate migrated paths then.
With the SAP S/4HANA, on-premise edition 1511 (Q4 / 2015 delivery) it is planned to enhance the
functional scope with application innovation and simplification in the logistics area. Now with application
innovation in financials and logistics area we could speak of the SAP S/4HANA Core. More application
G
innovations are planned to enhance the SAP S/4HANA Core then in future. In addition to the application
simplification in financials and logistics area the SAP S/4 HANA Core consists of the SAP Fiori user
experience (UX), and innovations for the digital economy based on SAP HANA.
To ensure a smooth transition to SAP S/4HANA, on-premise edition traditional features will stay available.
Besides application specific functionality, just the SAP GUI based user interface technology should be
listed as still available functionality after the move to SAP S/4HANA.
SAP S/4HANA core components (including simplified financials and simplified logistics)
One-Step Procedure for customers on anyDB, ABAP AS 7.0x, SAP ERP6.0 EHPx
One-Step Procedure for customers on SAP HANA, ABAP AS 7.0x, SAP ERP6.0 EHPx
One-Step Procedure for customers on SAP HANA, ABAP AS 7.40, SAP ERP6.0 EHP7, SAP
Simple Finance add-on 1.0 / SAP Simple Finance, on-premise edition 1503
These constellations are displayed in the following figures:
Figure 8: SAP S/4HANA, on-premise edition 1511 - One-Step Procedure for customers on anyDB, SAP ERPx
Figure 9: SAP S/4HANA, on-premise edition 1511 - One-Step Procedure for customers on SAP HANA, SAP ERP6.0 EHP7
Figure 10: SAP S/4HANA, on-premise edition 1511 - One-Step Procedure for customers on SAP Simple Finance
Additional Remarks:
An explicit upgrade to Enhancement Package 7 is not required for the move to SAP S/4HANA,
on-premise edition 1511. See figure 8 and figure 9 above.
Customer using older SAP Business Suite Releases (for example still on Non-Unicode) can move
to SAP S/4HANA, on-premise edition 1511 in a two-step transition approach.
The installation of the SAP Fiori UI software components are a separate installation step and
typically installed on a separate, central gateway server. Due to simplification reasons the figures above
do not visualize this aspect.