S/4HANA Finance 1610 offers a wide range of financial tools for a company to use, but finding the best ways to employ those tools so that a business can benefit from them the most requires a little more know-how. Here are a handful of methodologies to consider when implementing S/4 HANA Finance 1610.
Using Currency Adjustment
Finance 1610 offers users eight (8) currencies that may be defined by the user. There is a need for real-time adjustment of those currencies if the functional currency being used is changed. SAP S/4HANA Finance 1610 offers a simple solution to this with an included SAP Fiori application that allows for currency adjustments. The solution retains accounting and gives users more flexibility over their ledger postings. The standard and user defined currencies can both be used in the application. The application doesn’t reference exchange rates, however.
While the ACDOCA single source of truth table supports ten (10) currencies, the downstream functions and tables only support the minimum of three (3). The current parking tables follow the same three-currency setup and in order to extend this, we can extend the classic BAPI_ACC_DOCUMENT_POST as well as the BAPI_ACC_DOCUMENT_CHECK functions to deal with handling ten currencies instead of three. If we’re posting currency adjustments, however, we can’t park, since the adjustments require inclusion of an approval process before they can be accepted.
Using BAPI Functions
As mentioned before, we can adjust the BAPI_ACC_DOCUMENT_CHECK and BAPI_ACC_DOCUMENT_POST entities to enable support for up to ten currencies. This is dependent upon the how ledger-specific postings occur. The extensibility can only happen if the posting follows the same standard as our ten-currency system throughout the entire workflow.
The reporting arm of our system contains a few reports that do not support ten currencies at all, and this stems from how they were constructed (using BSEG as opposed to being derived from the ACDOCA tables). Whether the freely defined currencies are available in our reports or not comes back to how those reports were built based on website usability. The reports are based on a data model and if we can edit that data model to support the ten currencies then we can have access to them in our reports.
Valuation of Foreign Exchange
Inception posting as well as simulation ledger now form part of the SAP S/4HANA Finance 1610 suite. Simulation ledger, as the name suggests, can be used to test potential exchange rates between defined currency pairs (even custom defined pairs). Inception posting delivers the initial value to the valuation area for testing with the simulation ledger. These entries are marked with a U because they are only accessible by ACDOCA views, but unable to be fetched by BSEG views.
Universal Journal Entries
ACDOCA is something like a master table, designed to be the table from where all views draw their information. This reduces the database footprint while at the same time making the system more efficient as all accessible data is in one place. However, there are elements within HANA that do not support the ACDOCA and these need to be noted since they will be limited by their access to BSEG defined values. Additionally, not every SAP Fiori app supports the ACDOCA table layout and the model defined for the OData may need to be adjusted to reflect new fields in the table in order to generate the correct display of fetched information.
Financial statements can be viewed with transaction code F.01 or through the Fiori application Financial Statements, depending on website usability issues. Sadly, the reports presented through these media can be neither exported nor downloaded, meaning that the snapshot is basically an instantaneous look at the financial soundness of the company. There are also small issues with displaying data, such as an inability to display accounts with a balance of zero within the application. The Financial Statements application is very much an impromptu view of the financials of the company.