I will give you a general picture of the case of the use of an extension ledger in the latest SAP S/4Hana 1909 release. This use case will give you a clear idea about Ledger usage. However, before we start, we need to understand what Isan's Ledger Extension is. You may be very aware of the standardization of standard ledgers in SAP ERP. Because of various regulations and requirements, the majority of companies currently issue financial statements in accordance with various accounting standards in parallel. Starting from SAP ERP with the news you can use standard ledger functionality where separate ledgers are stored in a system for each accounting standard. There are 2 types of ledgers - leading ledgers integrated with all subsidiary ledgers and controllers. Then you have a parallel ledger called a ledger that does not lead. This parallel ledger is always managed as a complete ledger. This means that all posts that are relevant to specific assessments are always posted completely. At present, parallel ledgers are fully supported in the ledger and fixed asset accounting, but its vision is that all financial applications based on universal journals will be able to work with parallel ledgers
What is an extension ledger?
In SAP S/4Hana, we have a new type of ledger - an extension ledger. The extension ledger, different from the standard parallel ledger, is the Delta ledger. This means that only the difference between the assessment posted into the extension ledger. Because the Delta post only means in combination with original posts, the extension ledger must have a standard ledger assigned as an underlying ledger. Posting to the underlying ledger also applies to the extension ledger. Every time you report the extension ledger, data from the underlying ledger is always accessed and displayed together with the Delta post.
Based on what type of journal entry you want to post to the extension ledger, you can define 3 types of extension ledgers:
- Standard Journal Entry - save journal entries with real document numbers. This journal entry cannot be deleted and must be reversed if needed. Cases of use - management adjustment, tax adjustment, rearrangement
- P - Line items with technical numbers /no removal (previous predictions) - save journal entries with technical numbers only, without document numbers. They cannot be deleted and must be reversed if needed. Cases of use - predictions, commitment, statistical sales conditions.
- S - Line items with technical numbers/possible deletion (previous simulation) - save journal entries with technical numbers only, without document numbers. They can be deleted. Use cases - simulations, posts
You can also find what is called the V -Journal extension ledger entry for differences in assessment, which is not ready but is made in an accidental configuration.
Advantages of an extension ledger
- Flexibility - This may be the biggest advantage of the extension ledger when compared with a standard ledger. Preparing a new extension ledger is easy, no need to do all types of data migration, only configuration is needed, this is activated by the concept of an extension ledger because it only inherits historical data from the underlying ledger. You can activate or deactivate the extension ledger in a productive system at any time throughout the year without having to migrate data as well as standard ledgers.
- Research Reports available - All reports that support the work of the standard ledger as well as the extension ledger. This applies to the new Fiori Analytical Application and the SAP GUI Classic Report as well.
- Reducing data traces - because only the delta value is stored in the extension ledger
Standard ledger replacement with extension ledger
It is important to realize that the extension ledger is not a substitute for standard parallel ledgers. Still has many limitations in terms of functionality. You can post to the extension ledger through
- Posting Manual (eg transactions BF50L, FB01L, KB1, KB41, or FIORI applications that are appropriate such as general journal entry)
- interface
- Allocation of General Books (FAGLGA15, FAGLGA11, FAGLGA31, FAGLGA35) Works on the extension ledger.
However, in contrast to the standard ledger, the extension ledger is not integrated with a subsidiary ledger, and many important financial processes such as the process of assets and open items are not supported.
Restrictions on extension ledger
- There are no posts for vendors or customer reconciliation accounts
- There is no post to the GL account with open items management
- There is no integration with asset accounting
- Only a few automatic processes work with extension ledgers (allocations GL)
What are the cases of using the existing extension ledger?
Adjustment of the ledger
In addition to preparing GAAP financial reports, many companies have quite rich management reporting requirements. Most of the information needed comes from a standard ledger but usually, data must be re-grouped, improved, or refined. In the past, in SAP ERP you can use a special ledger, the second parallel ledger, or just add objects to overcome this kind of requirement. However, none of these solutions is optimal and each comes with problems and limitations. Now, in S4hana we have a better solution - an extension ledger.
You can set the extension ledger, for example, to record:
- Adjustment of Internal Management Reporting
- Adjust the entry after the book is closed.
- Topside adjustment
- Adjustments for tax purposes to achieve profit or loss adjusted to a tax
Predictive Accounting
Predictive accounting is a functionality that allows bottom-up predictions from future financial results. If you look at the ERP system, you can see that there is a lot of information that can make predictions. There are documents such as sales orders or purchase orders that are not yet relevant, but we can assume that one day they will generate posts. In addition, these documents already contain the amount and date expected when they will be converted into relevant accounting documents. For example, if you look at orders for the cash process, we have sales quotes, sales orders, goods problems, invoices, and payments. However, only the issue of goods, invoices, and relevant payments for accounting. Other documents also exist in the system, but they have no impact on accounting. The first scenario of predictive accounting available at SAP S/4hana is for incoming sales orders. The idea here is quite easy: When sales orders are made, the system will simulate the following documents on the problem of goods, and billing documents, and make predictive journal entries in the extension ledger-P. The best part is that the appropriate document is displayed in the system as if they are real data. All subsequent financial processes such as the separation of documents, derivations, and separation of the costs of goods sold are also triggered.
Statistical Sales Conditions
Statistical sales conditions, for example, guarantees can be posted to the extension ledger during the collection of sales orders. This can allow improved SG & A reporting in the P&L statement by allowing the inclusion of projected sales warranty costs.
Purchase Commitments
A commitment of Management Functionality in SAP S/4Hana Update Purchase Commitment in the Extension Ledger. Purchase commitment represents the obligation to pay vendors for the delivery of goods or services in the future. Commitment is triggered when the purchase request or purchase orders are made in the system. At this point, there is no actual payment recorded against the GL account, but the reservation (commitment) must be made to the budget. Activation of reform commitment in Universal Journal makes sense, especially regarding the control of the availability of new budgets available since the release of 1909. Until the release of 1809 commitments are stored in the COOI special line item table, and the total is stored in the COSP table. Since S4hana 1809, commitment has now been updated in the Universal Journal (ACDOCA table). To distinguish them from actual, they are stored in a separate extension ledger that must be defined as a prediction ledger. For compatibility reasons, the commitment continues to be updated in the old commitment table as well.
Conclusion
These are some cases of the use of extension ledgers that have been developed and successfully implemented by customers. And there are more releases in the future. Some of the upcoming improvements are already on the road map, for example, allowing predictive accounting for purchase orders. Some future concepts include the possibility of using an extension ledger for simulation closing activities or simulation reorganization. I want to hear your opinion in the comments below. What do you think about the case of using an extension ledger? Should we add more?
For more information visit: www.convista.in
0 Comments