SAP Simple Finance Add-On

Non disruptiveness: Compatibility View Principle

Non Disruptiveness due to compatibility views

Safeguarding customer Investments:

 We Provide so called “ Compatibility Views “
 Via this views the select is redirected to the
new persistency in HANA
 In the example given, as access to table
COEP is redirected via the view V_COEP to
the new Universal Journal Entry
 Effect : Customer ABAP Programs that read
directly “ COEP” via select statements
continue to run as before
 From the perspective of an ABAP program
„COEP” exists as before ( read access)
Sample of a compatibility view : V_COEP
Compatibility views are a “ bridge technology”
General Ledger : Technical changes with Simple Finance 2.0

 Data previously stored in FAGLFLEXA, FAGLFLEXT ( carry forward) is now stored

in table ACDOCA.
 Data of New GL 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)>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.
 FAGLFLEXT is defined as compatibility view. The old data of FAGLFLEXT is stored
in table FAGLFLEXT_BCK (accessible via SE16)
 The old data of all other SAP delivered New G/L tables ( e.g. FAGLFLEXA. etc.)
remains in these tables. Access to the old data is still possible via the views
V_<TABLENAME>_ORI ( e.g. V_FAGLFLEXA_ORI)
 Customers who want to access old data in customer defined New G/L tables have to
create views in the data dictionary. As template, V_FAGLFLEXA_ORI can be used.
Asset Accounting : Technical changes with Simple Finance
2.0

Actual Items
• Actual data of ANEK,ANEP,ANEA,ANLP and ANLC is
now stored in ACDOCA. ANEK data is stored in BKPF
• Compatibility views FAAV_ Table Name (eg.
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

Non - Actual Items

• 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
Controlling (CO) : Technical changes with Simple Finance
2.0

Actual Items
• Actual data of COEP ( value type ‘04’ and ‘11’) is stored in
ACDOCA
• Required actual data for long running orders
projects/orders from COSP_BAK, COSS_BAK is stored in
table ACDOCA
• Currently COBK ( header table) is written as before. The
Target is replace COBK with BKPF
• Compatibility views V_(TABLENAME) ( e.g. V_COEP) are
provided in order to reproduce the old items.
• Access to old data in tables still possible via the views
Non – Actual Items
• Value types other than ‘04’ & ‘11’ are stored still in COEP,
COSP_BAK, COSS_BAK
Material Ledger: Technical changes with Simple Finance 2.0

Usage of Material Ledger for Parallel currencies and

Parallel Valuation purpose
 Content of Tables MLIT, MLPP, MLPPF,MLCR,MLCRF,MLCD, CKMI1.
BSIM is now stored in ACDOCA. MLHD data is stored in BKPF
 Compatibility views V_<TABLENAME> ( 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_
<TABLENAME>
 MLHD, MLIT,MLPP, MLCR, still keep prima nota information, in case
of manual price changes or material debit/credit.

Usage of Material Ledger for Actual Costing purpose

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

Finance 2.0
The New and the old Ledger Master

 The Universal Journal Ledgers have own Master

Records
 The New Master Record Key FINSC_LEDGR-RLDNR
is technically compatible with 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.
Modify Operations on table COEP

 With Simple Finance, data previously

stored in table COEP is now stored in
table ACDOCA for value types „04‟ and
„11‟ other value types are still stored in
table COEP.
 If customers have written programs
manipulating data in COEP directly e.g.
via INSERT statements, the
corresponding statements must be
replaced.
 SAP Provides the class
CL_FCO_COEP_UPDATE with the methods
INSERT, UPDATE, MODIFY, DELETE for
this purpose.
 On the left, you can find a coding
example.
Universal Journal enforces discipline
We need a unified yet flexible solution
A unified yet flexible solution: Implementing the
Appendix as “ Appendix Ledger”
Several appendix Ledgers pointing to one Description & Benefits:
Standard Ledger  The bulk of data resulting from integrated business process
is stored in the standard ledger ( in our example IFRS data).
Only adjustments are stored in appendix ledgers. One
appendix ledger for one purpose.
 Besides creating a Master Record, appendix ledgers need no
additional configuration. Reporting on the appendix ledger
always includes the standard ledger.
 Currently, customers need fully loaded ledgers (e.g. FI-SL
ledgers) in order to get flexibility. This increases the memory
footprint and creates new reconciliation challenges through
the posting of redundant data. The appendix ledger
approach is non-redundant: It does not unnecessarily
increase the memory footprint and does not need
reconciliation
 Several appendix ledgers can point to one Standard ledger
 Authorization on appendix ledger level is easily provided or
discarded.
Appendix Ledger: Technical Implementation of the
read access
Universal Journal extensibility with customer fields

Capabilities:

 The Universal Journal can be easily extended with customer fields in a uniform manner
 P&L line extension using “ CO-PA capabilities “ is provided, i.e. field definition including the
rich derivation tools from CO-PA ( Transactions KEA5/KEA0)
 Standard Coding Block extensibility can be used and the respective customer fields are
added automatically to the Universal Journal (OXK3)
External Interfaces

• Technically, the Universal Journal development did not affect

the external interfaces.
• External Interfaces to FI/CO like BAPI‟s or direct calls of the
Accounting Interface have been kept stable.
• Validations/Substitutions work as before.
• There have been some “ internal “ enhancements to the
Accounting Interface ( see next slide)
Non Disruptive enhancements of the Accounting
Interface
Document Summarization

 BSEG summarization is still in place

and can be used as usual
 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 ( BSEG- BELNR has only
3 digits). This can be done, since
ACDOCA has a 6 digit field for line item
numbering.
External Postings with Simple Finance 2.0 ( including
AA and ML)

 Former COEP, FAGLFLEXA,ANEP,MLIT etc.,

data are stored in ACDOCA
 ACDOCA stores full detail.
 BSEG as before Simple Finance 2.0 can be
summarized.
 PCA, FI-SL,EC-CS technically untouched and
work as before
 Components that have been build with FI-
SL technology like Joint venture
Accounting, Public Sector etc., are
untouched and work as before.
 Cost based CO-PA work as before.
FI Postings with Simple Finance 2.0

 ACDOCA 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 as before Simple Finance 2.0
 PCA, FI-SL, EC-CS technically
untouched and work as before.
 Components that have been build with
FI-SL technology like Joint Venture
Accounting, Public Sector etc. are
untouched and work as before.
 Cost based CO-PA works as before.
CO postings without specifying ledger groups

 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 code postings)
 PCA, FI-SL work as before. In case FI-SL was posted via
activity “COFI” ( real time integration CO-FI), Secondary cost
elements ( which are now G/L accounts) are posted directly
and no mapping to a primary cost element is done.
 EC-CS as before with New G/L real time integration, but now
including secondary cost elements ( which are G/L accounts).
The System works now with original CO Activities like RKU1
instead of using the activity “ COFI”.
 Components that have been build with FI-SL technology like
Joint Venture accounting, Public Sector etc., work as before.
 Cost based CO-PA works as before.
CO postings specifying ledger groups

 With Simple Finance 2.0 CO processes are enabled to

post into ledger groups
 On the UI this is enabled for KB11N, KB41N and KB15N.
Other Processes can be configured in the IMG to post with
ledger groups
 ACDOCA is posted in any case taking the respective
ledgers into account.
 BSEG is only written in case of open item managed
accounts are affected ( e.g. cross company postings) and
the ledger group contains the leading ledger.
 Other components ( PCA, FI-SL, Cost based COPA,
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.
Postings into Appendix Ledger

 ACDOCA stores the data for all appendix

ledgers
 BSEG does not store the appendix ledger
data
 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.
Prima Nota in Simple Finance2.0

• The Primary Nota is the source document that triggers the creation of
Journal Entries. The Primary Nota is the single anchor that allows e.g. to
reverse the complete process triggered by the Primary Nota
• The Primary Nota keeps the information that has been entered into 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. Example
are Expense Reports, Invoices, payroll documents.
• For Posting within the Financials world a Prima Nota is needed as well.
• 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 mutli GAAP capability) are written to table ACDOCA.
Prima Nota in Simple Finance2.0

• For classical ( manual) “ CO Postings “ like

• Reposting of costs and revenues ( KB* Transactions)
• Manual Activity allocation in CO ( AWTYP= “COBK” and VRGNG =“RKL”)
• Manual re-posting with reference ( KB61, KB65)
• A Primary Nota is written as well in cases, where CO is triggered via BAPI Interfaces (
AWTYP<>AFRU,CATS)
• Material Price Changes (MR21) or Material Debit/Credit (MR22) create a Prima Nota
in the ML and the same has been posted in ACDOCA.
• Manual Allocations ( KB15)
• The Prima Nota is still written to table COEP. The corresponding Journal entries are written to
table ACDOCA. The used value type for the Prima Nota in table COEP is  “ U4 Source
Documents – Actuals”.
• A proper “ CO document number “  using CO number range object – is only needed for the
described case of a Primary Nota. In other cases, we use a transaction number ( see section
below)
• 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, i.e.
Cancelling an allocation journal entry is done this way.
Document Numbers with Simple Finance 2.0

• Since we write only one journal entry for of the components G/L, CO, AA,
ML one document number is sufficient from a business point of view.
• The journal entry consists out of a header (BKPF) and items (ACDOCA).
The respective document number (BKPF-BELNR, ACDOCA- BELNR)
obeys the legal rules of Financials. As a consequence, the document
number is dependent of 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 organization unit (
e.g. Company code). Both numbers didn‟t have legal relevance.
• For compatibility reasons a “ Transaction Number “ is needed in CO and ML that
has the same technical qualities than the previously used document numbers
(e.g. monotonously increasing)
Document Numbers with Simple Finance 2.0
Moreover, ACDOCA has a 6 digit field for the document line, whereas COEP
has only a 3 digit field, which is used in many user interfaces and reports.
For compatibility reasons, we have to offer a new transaction number for
every 999 document lines.

Example for a document with

more than 1000 lines