文本文稿原創(chuàng)universal journal entry architecture

1、Universal Journal Entry ArchitectureSAP Simple Finance Add-On 2.0 for SAP Business Suite powered by SAP HANAMarch, 2015At the end of this lesson, you will be able to:Explain the idea and concept of the Universal Journal. Outline the most important architectural changes done in Simple Finance 2.0 as

2、a consequence of the Universal Journal development.Explain how SAP safeguards the customer investment through compatibility views.ObjectivesAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Append

3、ix Ledger”)Universal Journal ExtensibilityExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers The new Universal JournalAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed t

4、opicsA unified yet flexible solution (“Appendix Ledger”)Universal Journal ExtensibilityExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers Multiple sources of truth (1/2)Challenges of the architecture before Simple Finance Separate co

5、mponents due to technical restrictions in the past (without HANA) No profit center &no G/L account inAsset Accounting TotalsMaterial Ledger does not store G/L account and Profit CenterDifferent level of detail due to the 999 document lines limit e.g. 1:n documents FI/COG/L and Profitability updated

6、at different business events on different entities (e.g. account)Multiple sources of truth (2/2)Challenges of the architecture before Simple Finance Challenges:The combined content of several tables represents “the truth”. Reconciliation efforts are needed by architecture.Different level of detail s

7、tored in the respective components/tablesComponents are structured differently (e.g. fields/entities differ)Need “to move” data to the appropriate table for reporting (e.g. “settlement”)Different capabilities in the components (customer fields, currencies, multi-GAAP etc.)Multiple BI extractors need

8、ed to cover the complete truth in BI.The New Architecture with Simple Finance: Universal Journal as the Single Source of Truth (1/2)The New Architecture with Simple Finance: Universal Journal as the Single Source of Truth (2/2)The new architectureMotto: “Take the best of all worlds” (e.g. ledger, ma

9、rket segment, coding block etc.)One line item table with full detail for all components: HANA allows for this design!Data stored only once: no reconciliation needed by architectureReduction of memory footprint through elimination of redundancy.Fast multi-dimensional reporting on the Universal Journa

10、l possible without replicating data to BI.If BI is in place anyway, only one single BI extractor needed (instead of many today)Secondary cost elements are G/L accountsTechnical preparation done to enhance important structural capabilities of the Financials solution (e.g. multi-GAAP, additional curre

11、ncies)The new journal entry (header and item)The new journal entry consists of a header (table BKPF) and the respective items (table ACDOCA)There are rare cases, where entries in ACDOCA are written without a document header (e.g. carry forward, corrections in migration). These entries do not represe

12、nt standard business processes. The corresponding line items have artificial document numbers beginning with letters (e.g. A).Table ACDOCA contains all fields needed for G/L, CO, AA, ML, PAMulti-GAAP capability through “RLDNR” dimension6 digit field for line item numbering23 digits for currency fiel

13、dsBKPFACDOCAHuge benefits for our customers: Universal Journal Huge Customer BenefitsA true single source of truth for all accounting components Reconciliation as a topic of the past Big cost savings for our customersA simple but holistic data model HANA can be leveraged in the best possible manner

14、Unprecedented insight (speed and content!)The universal journal combines and harmonizes the good qualities of all accounting components Simplification of the application Very good foundation for further enhancements (to be decided)Consumable without disruptionCompatibility views safeguard customer i

15、nvestmentsAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Appendix Ledger”)Universal Journal ExtensibilityExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Pr

16、ima Nota and Document numbers Non disruptiveness: Compatibility View principleBrilliant technology provided via SE11AbapCatalog.sqlViewName: V_COEPEndUserText.label: LOCAL: Line Items COEPdefine view v_coep_view as select key mandt, key kokrs, key belnr, key buzei, perio, wtgbtr,. from v_coep_v2_l4_

17、view where wrttp = 04 or wrttp = 11 ;Non disruptiveness due to compatibility viewsSafeguarding customer investments:We provide so called “compatibility views”. Via this views the select is redirected to the new persistency in HANAIn the example given, an access to table COEP is redirected via the vi

18、ew V_COEP to the new Universal Journal EntryEffect: 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_COEPCompatibility views are a “bridge te

19、chnology”Starting point for COSP / COSSUnion with COEPNon actual data is still stored in COEPTransformation of ACDOCA into COEPMap / Calculate“ fields from ACDOCA into COEP fields (MUV-Flag, Timestamp.)Filter CO relevant data from ACDOCA (CO_BELNR)Aggregate separated positive and negative lines (SUM

20、 and GROUP BY).Material Ledger: Technical Changes with Simple Finance 2.0Usage of Material Ledger for parallel currencies and parallel valuation purposeContents of tables MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, BSIM is now stored in ACDOCA. MLHD data is stored in BKPF Compatibility views V_ (e.

21、g. V_MLIT) are provided in order to reproduce the old structuresAccess to old data in tables still possible via the views V_ORI (e.g. V_MLIT_ORI) MLHD, MLIT, MLPP, MLCR still keep prima nota information, in case of manual price changes or material debit/credit.Usage of Material Ledger for Actual Cos

22、ting purposeMLIT, MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD are used as before Simple Finance 2.0MLHDMLITMLPPMLPPFMLCRMLCRFBSIMCKMI1MLCDACDOCABKPFAsset Accounting: Technical Changes with Simple Finance 2.0Actual itemsActual data of ANEK, ANEP, ANEA, ANLP, ANLC is now stored in table ACDOCA. ANEK data is

23、stored in BKPF.Compatibility views FAAV_ (e.g. FAAV_ANEK) are provided in order to reproduce the old structures.Access to old data in tables still possible via the views FAAV_ORI (e.g. FAAV_ANEA_ORI) Non actual itemsStatistical data (e.g. for tax purposes) previously stored in ANEP, ANEA, ANLP, ANLC

24、 is now stored in table FAAT_DOC_ITPlan data previously stored in ANLP and ANLC is now stored in FAAT_PLAN_VALUES ANEKANEPANEAANLPANLCACDOCABKPFFAAT_DOC_ITFAAT_PLAN_VALUESControlling (CO): Technical Changes with Simple Finance 2.0Actual ItemsActual data of COEP (WRTTP = 04 and 11) is now stored in A

25、CDOCA Needed actual data for long running orders/projects from COSP_BAK, COSS_BAK is stored in table ACDOCA. Currently, COBK is written as before. Target is to replace COBK through BKPF.Compatibility views V_ (e.g. V_COEP) are provided in order to reproduce the old structures.Access to old data in t

26、ables still possible via the views V_ORI (e.g. V_COEP_ORI) Non actual itemsValue types other than 04 and 11 are still stored in COEP, COSP_BAK, COSS_BAKCOEPCOSP_BAKCOSS_BAKCOBKACDOCABKPFGeneral Ledger: Technical Changes with Simple Finance 2.0CommentsData previously stored in FAGLFLEXA, FAGLFLEXT (c

27、arry forward) is now stored in table ACDOCA.Data of New G/L industry tables for Public Sector and Joint Venture Accounting ( FMGLFLEXA/T, PSGLFLEXA/T, JVGLFLEXA/T) is now stored in table ACDOCA.Data of customer created New G/L tables ZZT, ZZA is now stored in table ACDOCA.A compatibility view is pro

28、vided for table FAGLFLEXA: FGLV_FAGLFLEXA. This compatibility view redirects select statements to FAGLFLEXA to ACDOCA.Compatibility views for the New G/L industry tables are provided: V_A, V_TCompatibility Views are provided for customer created New G/L tables. The views are numbered sequentially: Z

29、FGLV_GLTT_Cx (totals) and ZFGLV_GLSI_Cx (line items), where x is a number. FAGLFLEXTFAGLFLEXAACDOCAZZTTZZAAGeneral Ledger: Technical Changes with Simple Finance 2.0CommentsFAGLFLEXT is defined as (compatibility) view. The old data of FAGLFLEXT is stored in table FAGLFLEXT_BCK (accessible e.g. via SE

30、16)The old data of all other SAP delivered New G/L tables (e.g. FAGLFLEXA, FMGLFLEXT etc.) remains in these tables. Access to the old data is still possible via the views V_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

31、 data dictionary. As template, V_FAGLFLEXA_ORI can be used.FAGLFLEXTFAGLFLEXAACDOCAZZTTZZAAAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Appendix Ledger”)Universal Journal ExtensibilityExterna

32、l Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers The new and the old Ledger master The Universal Journal ledgers have own master recordsThe new master record key FINSC_LEDGER-RLDNR is technically compatible with the FI-SL/New G/L ledger k

33、ey (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

34、modules have a compatibility mode that might help customers to leverage their own code for Universal Journal ledgers.Modify Operations on table COEPBefore Simple Finance 2.0:With Simple Finance 2.0*:With simple Finance, data previously stored in table COEP is now stored in table ACDOCA for value typ

35、es 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 fo

36、r this purposeOn the left, you can find a coding example.Detailed TopicsAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Appendix Ledger”)Universal Journal Extensibility External Interfaces and J

37、ournal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers Universal Journal enforces disciplineCOG/L“I want to post despite closed periods in G/L”“I have to close the fiscal period”Universal Journal“Periods cannot be open and closed at the same time”“I have to clos

38、e the fiscal period”How can we offer flexibility in our solution without introducing again a reconciliation issue?Extension e.g. for specific management adjustments or realignments“Appendix”We need a unified yet flexible solutionUnified FI and CO (e.g. according to IFRS) “Standard” (”Base”)“Regular”

39、 universal journal entries serving FI, CO, AA, ML, with e.g. IFRS valuation.Posting of consistent standard processes.Strict standard rules (e.g. standard period lock) have to be obeyed“On top” - usually manual G/L account postings. Report on extension always includes the embedded “Standard” to provi

40、de the full pictureLess strict rules (e.g. different period lock)Use of standard FI/CO UIs and reports. “Appendix” authorization needed . Several extensions possible to one “base”: More flexibility than previously through FI and CO separation Physical TableStandard Ledger IFRS A unified yet flexible

41、 solution: Implementing the Appendix as “Appendix Ledger” Several appendix Ledgers pointing to one Standard LedgerDescription and BenefitsThe bulk of data resulting from integrated business processes is stored in the starndard ledger (in our example IFRS data). Only adjustments are stored in appendi

42、x 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. T

43、his 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 standa

44、rd ledger. Authorization on appendix ledger level is easily provided or discarded Purpose: Financial Statement for IFRSAppendix Ledger A“Post into closed periods”Appendix Ledger B“Distribute Revenues differently on org units than in legal view”Appendix Ledger C“Adjustments for consolidation purposes

45、”Appendix Ledger: Technical implementation of the read accessPersistenceView for Data Selection The transaction data is mapped“ to corresponding LedgerAgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible soluti

46、on (“Appendix Ledger”)Universal Journal ExtensibilityExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers Universal Journal extensibility with customer fieldsUniversal JournalStandard Field xStandard Field x+1zzcust01zzcust02wwprof01ww

47、prof02Coding Block extensibility“CO-PA” extensibilityCapabilities: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/K

48、EA0)Standard Coding Block extensibility can be used and the respective customer fields are added automatically to the Universal Journal (OXK3)AgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Appe

49、ndix Ledger”)Universal Journal ExtensibilityExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers External InterfacesTechnically, the Universal Journal development did not affect the external interfaces. External Interfaces to FI/CO lik

50、e BAPIs 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).Accounting InterfaceNon disruptive enhancements of the Accounting InterfacePrepared for future

51、scenariosBSEGACDOCAFI-AAMLPrepared for future processesOptimized for mass data“New Accounting Interface”SDMMCRMBAPIsCOFI-GLFI-AAFI-GLCOMLFI-AAFI-ARFI-APStable InterfacesStable Interfacesinternal redirectDocument SummarizationAccounting InterfaceMMSDHRACDOCABSEGDocument SummarizationFull detailBSEG s

52、ummarization 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 b

53、e done, since ACDOCA stores the full detail and ACDOCA has a 6 digit field for line item numbering.AgendaThe new journal entryIdea and BenefitsCompatibility views and obsolete tablesSafeguarding ABAP codeDetailed topicsA unified yet flexible solution (“Appendix Ledger”)Universal Journal Extensibilit

54、yExternal Interfaces and Journal Entry SummarizationData flows with Simple Finance 2.0 Prima Nota and Document numbers External“ Postings with Simple Finance 2.0 (including Asset Accounting and Material Ledger)Accounting InterfaceMMSDHRAA“ACDOCA”PCAFI-SLEC-CSCommentsFormer COEP, FAGLFLEXA, ANEP, MLI

55、T etc. data are stored in ACDOCA.ADOCA 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

56、 before.Cost based CO-PA works as before.“BSEG”Cost Based CO-PAMLOtherFI Postings with Simple Finance 2.0Accounting InterfaceFI“ACDOCA”PCAFI-SLEC-CSCommentsACDOCA posted via the Accounting Interface similarly to FAGLFLEXA (New G/L) in the past. ACDOCA stores full detail.Former COEP, FAGLFLEXA, ANEP,

57、 MLIT etc. data are stored in ACDOCA.BSEG as before Simple Finance 2.0PCA, 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 be fore.Cost based CO-PA works as before.

58、“BSEG”Cost Based CO-PACO Postings“ without specifying ledger groups with Simple Finance 2.0Accounting InterfaceCO“ACDOCA”PCAFI-SLEC-CS“BSEG”Cost Based CO-PACommentsACDOCA is posted via the Accounting Interface similarly to FAGLFLEXA (New G/L) in the past. ACDOCA stores full detail.Former COEP, FAGLF

59、LEXA, ANEP, MLIT etc. data are stored in ACDOCA.BSEG is only written in case open item managed accounts are affected (e.g. usually for cross company postings).PCA, FI-SL work as before. In case FI-SL was posted via activity “COFI” (real time integration CO-FI), secondary cost elements (which are now

60、 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 the original CO activities like RKU1 instead of using the activity “CO