Welcome to the Part 2 of Universal journal blog series. In this blog, we are going to discuss about the functional impact of ACDOCA in Finance business processes. How several modules have been integrated into single table and reconciled on real time? If you want to read the technical aspects, here is the link to the blog.
- Reconciliation of several modules
As described in the first blog, tables from Asset Accounting, CO, Material Ledger, Profitability Analysis have been removed and replaced by ACDOCA. Hence, there is no need of reconciliation to be performed at the period end. It is no longer necessary to reconcile the general ledger with the subledger of Asset Accounting as from now on Asset Accounting is permanently reconciled with the general ledger automatically. The programs for reconciliation that existed until now (RAABST01, RAABST02 and FAA_GL_RECON) are therefore no longer available in SAP S/4HANA
- BSEG & ACDOCA – A comparison on the data flow
- Though transactions from AR, AP, GL are now available in ACDOCA, BSEG is still there. There are several applications such as sales and purchasing components which use the interface to BSEG, and SAP has not yet converted all applications to divert to ACDOCA from BSEG. The long-term vision is that table BSEG will be used only for open item management – and postings that do not related to open items will no longer create entries in table BSEG. However, BSIS, BSAS, BSID, BSAD, BSIK, BSAK are index tables, which stored duplicate data in ECC for faster access to open item/ cleared items processing. With the computing power of S/4HANA based on the in-memory database and columnar storage, these index tables are no longer needed as the data is extracted from database on the fly in real-time
- Actual values from tables ANEP, ANEA, ANLP, ANLC are saved in table ACDOCA in new Asset Accounting. The values from table ANEK are saved in tables BKPF and ACDOCA in new Asset Accounting. Postings are still made to the table BSEG.
- As of release SAP S/4HANA 1809, the BSEG table will no longer be updated with the depreciation run (transaction AFAB, AFABN). (See also SAP Note 2383115.) It is also no longer possible to subsequently activate this update. You can still use program RAPOST2001 (transaction AFBP) to display depreciation runs in the Schedule Manager. However, the selection screen of the program was adjusted to the new program logic for posting depreciation.
- Different accounting principles or valuations are represented – as in new General Ledger
Accounting – in separate ledgers (for the ledger approach) or in a separate set of accounts
(for the accounts approach).The depreciation areas have equal status. Separate accounting-principle-specific documents are posted for each accounting principle or valuation.
A business transaction created using integration is split by the system into the operational
part and the valuating part. A posting is made in each case against a technical clearing
account. For the asset acquisition using integration you require a new technical clearing
account for integrated asset acquisition; however, for the asset retirement using
integration the existing clearing accounts asset retirement with revenue and asset
retirement clearing are used. The operational part is posted across accounting principles,
the valuating part is posted accounting-principle-specifically.
- The journal entries are updated in ACDOCA at asset level. The entry also contains the asset number.
- Table ACDOCA stores carry forward transaction postings and correction line items from migration. However, Table BSEG does not store these lines.
- Integration with Controlling
In SAP S/4 HANA the totals records for primary and secondary costs have been removed
and the universal journal includes all actual cost postings, both primary and secondary.
This ensures for primary postings that there is a single source of truth, such that all general ledger items with an assignment to cost centers, orders, WBS elements, business processes, or CO-PA characteristics are treated as one data record which is enriched with the relevant profit center, functional area, segment, and so on. Since Financial Accounting and Controlling will always be in synch, the company code is checked during all postings to an account assignment in Controlling and that it is no longer possible to remove the flag “CoCd Validation” in the controlling area.
For secondary postings this ensures that all sender-receiver relationships that are triggered by allocations, settlement, and so on are captured in the universal journal along with the partner profit centers, functional areas, and so on that are affected by the allocation.
1. Actual data of COEP (WRTTP = ‘04’) is now stored in ACDOCA.
2. Actual statistical data of COEP (WRTTP = ‘11’) is stored in ACDOCA using additional columns for the statistical account assignments and in COEP for compatibility access.
3. Actual data needed for long-term orders/projects from COSP_BAK, COSS_BAK is stored in table ACDOCA.
4. Currently, COBK is written as before.
5. Compatibility views V_ (for example, V_COEP) are provided to reproduce the old structures.
6. Access to old data in tables is still possible via the views V_*_ORI (for example, V_COEP_ORI).
7. Value types other than ‘04’ and ‘11’ are still stored in COEP, COSP_BAK, COSS_BAK.
Profit Center Accounting:
In SAP S/4HANA, PCA is mapped in the universal journal by default. This means, if you still use classical PCA, Profit Center Accounting in the universal journal is also always active in parallel. To stop using classical PCA you have to deactivate it as described in SAP note 2425255. It is not necessary to migrate data from classic PCA (tables GLPCA/GLPCP/GLPCT) to the universal journal, that is, to the table ACDOCA, when deactivating classical PCA
COPA / Margin Analysis in S4 HAHA:
SAP recommends using Margin Analysis in SAP S/4HANA. Margin Analysis has been extended broadly over the past releases and we continue to conduct new developments in this area only. It is perfectly integrated into the overall concept of the Universal Journal and is therefore fully in line with our Financial Accounting development strategy. Margin Analysis is active if there is an activation flag for ‘account-based’ in the IMG procedure mentioned above.
In addition to Margin Analysis, SAP also offers Costing-based CO-PA. Before the conversion to SAP S/4HANA on-premise, SAP recommends that you verify whether Margin Analysis can already cover all requirements and costing-based CO-PA can remain de-activated.
The universal journal (ACDOCA) is the heart of Accounting and includes all Margin Analysis characteristics in order to allow multi-dimensional reporting by market segment. The universal journal includes columns for the standard characteristics and all additional characteristics included in an organization’s operating concern (up to sixty characteristics, including the fixed characteristics). If you have already configured an operating concern for Margin Analysis, columns will be created for each of the characteristics during migration.
The benefit of this approach is that all revenue and cost of goods sold postings are automatically assigned to the relevant characteristics at the time of posting and that allocations and settlements are made to the characteristics at period close. It is also possible to configure some expense postings such that the characteristics are derived automatically, so that material expenses assigned to a WBS element (account assignment) are automatically assigned to the characteristics entered as settlement receivers for the WBS element. This automatic derivation of the characteristics can
reduce the number of settlements and allocations to be performed at period close and provide real-time visibility into spending during the period. There are also no reconciliation issues between the general ledger and Margin Analysis. Be aware, however, that revenue is recognized at the time of invoicing and cost of goods sold when the delivery is made. If there is a time gap between delivery and invoicing, costs may be visible in Margin Analysis for which no revenue has yet been posted (matching principle). A new approach to delay the cost of goods sold posting until the invoice is posted is currently available in S4HC.
This simplification makes it obligatory to use the Material Ledger (ML) which is now part of the standard and automatically active in all SAP S/4HANA systems. The content of most of the former Material Ledger database tables is now stored in table ACDOCA which allows simpler and faster (HANA optimized) access to the data. The attributes of the ML data model that are relevant for the inventory subledger functionality are now part of table ACDOCA. The former tables are obsolete. Therefore the following tables must not be accessed anymore via SQL statements. In most cases a corresponding access function or class has been provided that must be used instead.
This activity ensures that the material ledger is activated for all valuation areas, since it is mandatory in SAP S/4HANA. The activity creates material ledger master data (tables: CKMLHD, CKMLPR, CKMLPP and CKMLCR) in all material ledger currencies for periods more recent than the last period of the previous year. In addition, all existing inventory aggregate values (tables MBEW, EBEW, QBEW, OBEW) and their complete historic data (tables MBEWH EBEWH, QBEWH, OBEWH) are migrated into the new universal journal entry table ACDOCA and ACDOCA_M_EXTRACT. Period records more recent than the last period of the previous year are converted into material ledger currencies using standard exchange rate type ‘M’. Periods earlier than the last period of the previous year are only migrated in home currency. During migration, balance carryforward records (fields: BSTAT = ‘C’ and MIG_SOURCE = ‘N’) are created in ACDOCA. If you are already using the material ledger, existing material ledger records (tables CKMLPP and CKMLCR) are transferred into ACDOCA and ACDOCA_M_EXTRACT with all existing currency information. This migration activity does not activate actual costing, since actual costing is still optional in SAP S/4HANA. However, if you are already using actual costing in the migration source system, ML data for actual costing will be transferred to new data structures to enable fast and efficient cost calculation.
- Manual Accruals / Accrual Engine:
The S/4HANA Accrual Engine is seamlessly integrated with the General Ledger. The number of database tables has been reduced. For example the original document of the accrual postings is now contained in the Universal Journal Entry, table ACDOCA.
- Currency Fields & Corresponding Amount fields in ACDOCA
Situation in ECC
In the Business Suite (ECC) there used to be up to 3 parallel currencies in FI (table
T001A / transaction OB22) and 2 parallel currencies in CO (TKA01 / transaction OKKP): CO area
currency and object currency. The currencies of non leading ledgers in New GL (T882G) were a subset of the currencies in the leading ledger (T001A). One of the CO currencies needed to be the local currency, but it was not necessary that the other currency in CO was also configured in FI.
Situation in S4 HANA
With the universal journal and the common line item table ACDOCA for FI and CO, there is also a central currency configuration for the universal journal. As the currency configuration depends on the universal journal ledgers, there is a combined view cluster for ledgers and currencies, transaction FINSC_LEDGER.
IMG menu path:
Financial Accounting( New ) – Financial Accounting Global Settings (New) – Ledgers – Ledger – Define Settings for Ledgers and Currency Types.
WSL, TSL, HSL and KSL mandatory currencies in all ledgers. KSL is filled, if the company code is assigned to a controlling area. The currency type for KSL is defined by the setting in the controlling area. In S4 HANA, 8 additional parallel currencies can be defined per company code.
The second and third parallel currencies of FI (BSEG-DMBE2 or BSEG-DMBE3) correspond to 2 amount fields of KSL – GSL according to configuration in transaction FINSC_LEDGER. Table BSEG is not (and will not be) extended and still contains only 3 parallel currencies; the BSEG relevant currency types can be configured in the overview screen of the company code assignment in tx FINSC_LEDGER in the columns on the right side (1st / 2nd / 3rd FI Currency). Here you can choose from the configured currency types the BSEG relevant currency types. Currency types in customer name space are not allowed as BSEG relevant currency.
When a currency type is marked as BSEG relevant in the leading ledger (2nd or 3rd FI Currency) and this currency type is also configured in a non-leading ledger, then it needs to be a BSEG relevant in the non leading ledger as well.
ACDOCA has new fields to store all currencies and corresponding amounts.
- No Limitation of 999 Document Line Item: Due to the 999-document line item posting limitation, table BSEG is usually aggregated. This limitation doesn’t exist in table ACDOCA.
Information has been extracted from S4 HANA Simplification items and this blog contains ACDOCA related simplifications only.
Thank you for reading. Let’s learn together and help each other.
You can reach out to me directly in Linkedin for any suggestion or help. https://www.linkedin.com/in/theratulchakraborty/