Account Determination using 1 Transparent Table instead of 9 Decision Tables

Why Transparent Table

RAR account determination involves reference to 9 standard decision tables in BRF+, namely

• Existing receivable account determination
• Existing revenue account determination
• IFRS15 revenue account determination
• Contract asset account determination
• Contract liability account determination
• Receivable adjustment account determination
• Revenue adjustment account determination
• POB determination
• SSP determination

These 9 decision tables are spread across 2 BRF+ applications. The standard applications which have been used as templates are FARR_AP_PROCESS_TEMPLATE and FARR_ACC_DETERMINE_TEMPLATE.

Usually, the account determination is recommended to happen at the POB Type level. But due to the current design of the customer system, the account determination is designed to happen at each POB level and 1 POB is mapped to 1 material and 1 company code combination. This means there are thousands of entries in each of the 9 decision tables mentioned above. This makes creation and maintenance of data matched across all the 9 tables very cumbersome, complex and error-prone.

Instead, using a single transparent table which contains all the relevant fields from all these 9 decision tables and providing a maintenance screen for the same, would ease the efforts immensely. The design for the transparent table is shown below. A 2-step maintenance screen is also provided for the table maintenance. The table is enabled for “Log Data Changes” in the Technical Settings – this is to provide a semblance of the version management feature which is available in decision tables on the BRF+ workbench.

How is this implemented?

The integration with the transparent table is implemented using the Expression type “Procedure Call” instead of Decision Tables in BRFPlus.

• Class ZCL_PROCESS_BRF is created with static methods representing each of the determination steps.

• The class constructor is used to select the data from the transparent table and save the data in a class attribute.

• The methods simulate the same behavior/functionality that is provided by the decision tables. For example, the code snippet from IFRS15 Revenue Account Determination is shown below. The methods also simulate the wild card character behavior provided by decision tables, that is, a blank in the condition field = a wild card character. An advantage of using the transparent table is that the order of maintenance of the data does not impact the result, the best match is always returned. This is unlike the behavior of the decision tables, where the order of the data maintenance has a direct impact on the data determined – the first match is always returned which need not be the best match!

• In BRFPlus the existing functions now call the new expression “Procedure Call” instead of the decision tables for determination.