SAP S/4HANA Finance 1610

By Sridevi Pattabiraman, Senior Manager-S/4 HANA Finance, Cognizant Technology Solutions, USA

SAP S/4HANA Finance 1610 provides users with the flexibility of using two main currencies plus eight freely definable currencies. Practical Tips for an Implementation The translation of the user-defined currencies, whether real-time or not, is based on the currency configuration completed after executing transaction code FINSC_LEDGER. The eight freely definable currencies allowed by SAP S/4HANA Finance 1610 are available in all ledgers (leading, non-leading, and extension), but they are not available in the material ledger or Asset Accounting (FI-AA). These currency types still follow the traditional three-currency (document, local, and group) setup as in SAP ERP Central Component (SAP ECC).

 I now describe the impact on currency from these five processes:

• Currency adjustment postings
• Business application programming interface (BAPI) functions
• Parking
• Foreign exchange (FX) valuation
• Reporting

Currency Adjustment Postings

The traditional transaction codes such as FBB1 still support only three currencies (with eight currencies available in SAP S/4HANA Finance 1610, posting adjustments for three currencies is outdated), whereas transaction codes such as ABF1 are no longer valid. With multiple currencies, there is a real-time need for currency adjustment in each of the eight currencies — especially during migration. The currency adjustment is needed if the functional currency of the entity is changed (because of the Financial Accounting Standard Board Accounting Standard Codification (ASC)’s definition of functional currency — not necessarily the need to be the legal currency of the country, but the primary currency with which the entity transacts). Regarding the ASC definition of functional currency, few currency adjustment postings are necessary to support a period-end closing. For this process, SAP S/4HANA Finance 1610 provides users with an app called Post Currency Adjustments (app ID F1606).

(Note: For currency adjustment postings in SAP S/4HANA Finance 1610, only the SAP Fiori Post Currency Adjustments app is available, and there is no transaction code available for such adjustment postings.)

Here are the key features of this app:

As the name suggests, the purpose of the app is to post currency adjustments — that is, posting without involving any exchange rates. The user can enter (manipulate) the value in each currency.

• The app allows the user to select the ledger group during posting.
• Although manipulated, the core of accounting is still valid (that is, the total of the debit should be equal to the total of the credit). Therefore, SAP provides a feature so that users can decide for which currency the debit/credit total check should be performed.
• The Debits/Credits Cur. (debits/credits currency) field provides users with an option of standard and user-defined currencies (Figure 1). The chosen currency then becomes the main currency, and all other currencies appear in the Details section of the line item.

Consider this example. In the Transaction Currency field in Figure 1, enter CHF (Swiss francs). The settings for the Debit (Company Code Currency) and Credit Company Code Currency fields are USD.

Enter $100 in the Debit Company Code Currency field and $50 in the freely definable currency Amount field as shown in Figure 2. The rest of the currency values are left as $0, as this is an adjustment posting.

Figure 3 shows an example of a document posted using the SAP Fiori Post Currency Adjustments app.

The Journal entry attribute is set as U (Posting in General Ledger only). (This value is not shown in any of the figures. The SAP S/4HANA Finance 1610 system sets the document status internally in the header. Technically, this means that document details are available only in table ACDOCA, and they are not stored in table BSEG.

There are standard variants available during posting. Depending on the general ledger (G/L) involved, the user needs to select the appropriate variant for posting so that the field status is enabled and necessary data is captured correctly.

Here are some points to be aware of during implementation of this app:

• The main aim of the app is to post currency adjustments without referencing exchange rates. This means that it becomes necessary for the system to store a currency setting’s value independently in the respective currency fields of table ACDOCA. This step is possible only when ledger-specific postings are created. Therefore, there is no real difference between the entry view and the G/L view while the user displays the document.
• When the system creates a ledger-specific posting, it brings in a limitation that open item managed G/Ls cannot be posted or adjusted using this tool. This limitation becomes tricky during migration or a period end, especially when an entity’s functional currency is changed and adjustment postings are necessary.
• Posting using this tool always has a zero value posted against the document currency. Although the transaction currency is entered, the value cannot be populated. The user needs to be cautious using this tool, as it skews the value during FX valuation during a period end. For example, this transaction might be shown as 0.00 CHF = 100 USD.

BAPI Functions

The proven classic BAPIs BAPI_ACC_DOCUMENT_CHECK and BAPI_ACC_DOCUMENT_POST support freely definable currencies. However, if the ledger-specific postings are handled (using accounting principles), then the limitation of open item managed accounts continues in custom objects as well.

Parking

The single source of truth table ACDOCA supports all 10 currency settings. However, the downstream tables or functionalities still remain with the traditional table BSEG setup. For instance, the parking tables (VBSEG*) follow the three-currency structure. To overcome the limitation of currency adjust postings, the classic BAPIs BAPI_ACC_DOCUMENT_CHECK and BAPI_ACC_DOCUMENT_POST could be used to solve the issues. However, you cannot park and post currency adjustment entries. Entries such as currency adjustments in real time warrant the need for an approval process, as there is so much deviation from the standard value determined using an exchange rate. However, building workflow in SAP S/4HANA Finance 1610 is not straightforward, as the traditional parking tables do not support multiple currencies.

 

FX Valuation

A few additional features, such as simulation ledger and inception posting, are now part of SAP S/4HANA Finance 1610. As the name suggests, the simulation ledger is used to simulate FX valuation based on different exchange rates or currency types combinations, and inception posting is used to post initial values of the FX run in the valuation area — which is later used in subsequent FX valuation runs. The valuation area also can be defined using the freely definable currency. The SAP system stores ledger-specific postings with a document status set to U. This is true as well for FX valuation postings — a status setting of U denotes that documents are available only in table ACDOCA and not in table BSEG. This means any report using the Entry view does not fetch these documents.

Consider this example. For G/L account 8040003 (Foreign Exchange Losses Unrealized), note the difference in reports using Entry and G/L views. (To execute these reports use transaction code FAGLL03.) The Entry view is based on data in table BSEG and therefore results in zero records (Figure 4); the G/L View is based on table ACDOCA in which all the FX valuation documents are displayed (Figure 5).

Reporting

A few of the standard reports do not support the freely definable currencies. Only traditional currency types are available in the selection screen and in the report output. One of the reasons could be that such reports are built using table BSEG and not table ACDOCA. However, even the SAP HANA-based transaction codes such as FBL3H do not have different currency options in their layouts (Figure 6).

The availability of freely definable currencies in the reports depends on how the reports are made available. The reports in the SAP Fiori application library can be a standard SAP GUI transaction enriched for an SAP Fiori view or a native SAP Fiori application that has a back-end Open Data Protocol (OData) service provider. The service provider is maintained with a data model and can read only the fields maintained in the data model. The data model cannot be enhanced to bring in the user-defined currencies without modifications (for example, KSB1, MB51, MB52, and MB5L).

SAP Fiori-based reports are really good for analysis. Apps such as Trial Balance support cross-tab reporting and provide users with the flexibility to define the columns needed for the rows or columns and to add them by just using the drag-and-drop feature (Figure 7).

Certain SAP Fiori-based reports are very helpful. For instance, instead of using an SAP GUI- based transaction code (FBL3N or FBL3H), apps such as G/L Account Line Items are helpful in bringing in user-defined currencies in the report output (Figure 8).

(Note: Users should carefully choose between the traditional transaction code and the new SAP Fiori apps. Every traditional report is not yet fully converted to an SAP Fiori app with new features.)

The Universal Journal Entry Table

One of the major changes that SAP made in SAP S/4HANA Finance 1610 is bringing in table ACDOCA — the universal journal entry table — thereby eliminating the need for a multitude of tables. This is a major step in reducing the database footprint and thereby enabling faster access time. Here are some points to consider regarding the practical use of table ACDOCA:

• The validation and substitution options in SAP Fiori do not support table ACDOCA. These options are still designed based on the standard BKPF, BSEG, and SYST tables (Figure 9).
• Account-based CO-PA fields are enhanced in table ACDOCA. Any common fields created earlier using a coding block cannot be added again (for example, CO-PA characteristics created in SAP ECC can be added as a coding block. However, in SAP S/4HANA Finance 1610, if both these characteristics are the same, they cannot be added to table ACDOCA. This function prevents using this field in validation and substitution.

Table ACDOCA stores currency information at the ledger-specific level. The user needs to be careful from a simple aspect such as number range setup. For instance, the number range might be set up frequently as external to match the Financial Accounting (FI) document to have the same numbering as the material document. With a technical clearing account concept in FI-AA in place, such an account assigned purchase order (PO) invoices errors out (that is, it can’t be completed due to an error) because numbering could not be determined separately at the ledger group level if the numbering is made external. This is because FI-AA postings are always at the accounting principle level — meaning ledger specific.

Not all traditional GUI reports or native SAP Fiori apps support all fields of table ACDOCA. Either the database query or the fields available in the model defined for the OData should have the new fields fetched. If not, then it needs modifications to the standard reports. To an extent, this can be achieved using ERP accelerators — transaction code HDBC in field configurations.

Financial Statements

Although the above two sections deal with the generic setup of SAP S/4HANA Finance 1610, I need to discuss the financial statements, as they are the key reports used by any controller. Financial statements provide a real-time picture of the financial soundness of a company. Traditionally, financial statements can be viewed using transaction code F.01, and now an equivalent SAP Fiori app named Financial Statements is available. Next, I compare the features of the traditional transaction and the SAP Fiori app.

Financial statements generated with the traditional transaction code F.01 do not support user- defined currencies. The financial statements still have the old currency types only available in the Financial Statements selection screen (Figure 10).

The SAP Fiori app supports displaying of financial statements in freely definable currencies and also greatly helps in forward navigation to the line items. However, it has these limitations:

• A Special evaluations tab available in financial statements generated with transaction code F.01 is not available in the SAP Fiori app. For example, a requirement to display an account with a zero balance is no longer possible in the app. The documentation of the app clearly mentions this limitation. This is a noted as a limitation as some localization demands a zero balance value to be visible in the statements.
• The report cannot be exported or downloaded, so a finance department cannot pull data and perform detailed analysis.

There are minor changes between how the transactions behave in the SAP GUI versus the SAP Fiori app — for instance, transaction code FB41, which is used to post directly to a tax-payable account. Traditionally, this transaction allows the user to post a G/L with a tax category enabled, although the need is quite contradictory. (Executing transaction code FB41 is for adjusting tax accounts — that is, a value entered directly instead of a value determined by the system based on the rate from the tax codes. Therefore, using transaction code FB41 is unnecessary if the system again asks for the tax code, but does not use it.) These features are now streamlined in the corresponding SAP Fiori app named Post Tax Payables.

(For more information on SAP S/4HANA 1610 read these SAPinsider articles:

“You Can Now Do Realignments in Account-Based CO-PA with SAP S/4HANA 1610“

“You Are Now a Step Closer to Real-Time Profitability in SAP S/4HANA Finance with Fewer Settlements“

“Plan Your SAP S/4HANA Finance Migration with These Tips”

“Demystifying the Ledger, Currency Setup, and Currency Conversion in SAP S/4HANA Finance 1610“

“SAP S/4HANA: First Steps Toward Real-Time Profitability Analysis“