Dimensions/financial rules relationships

Once the accounting models have been defined, it is necessary to associate them to each account, or specify how the curves defined in the accounting model must be generated for each account.

This association is done by means of relating the dimensions to financial rules. In particular, the accounting model contains the definition of the curves provided for by that model and the default accounts which generate certain entries.When relating dimensions to financial rules, the accounting model is associated with each account in the chart of accounts, specifying any accounting/financial rule that the user wants to generate and indicating any indirect tax policy. It is therefore during this step that the system replaces the default accounts defined in the accounting model with the effective accounts associated with the account being set up.

The management of the relationships between dimensions and financial rules can be accessed from the administrator-user’s web interface, by following the path Setup & Admin > Data Processing > Cash Flow Planning > Dimensions mapping - financial rules.

Navigation panel> Data Processing > Cash Flow Planning > Dimensions mapping - financial rules.

This association can be defined for all of the managed dimensions, in addition to by account. It can be defined:

  • by individual entity - entity hierarchy nodes;
  • by individual account - account hierarchy nodes;
  • by individual custom dimension 1 - custom dimension 1 nodes;
  • by individual custom dimension 2 - custom dimension 2 nodes;
  • by individual custom dimension 3 - custom dimension 3 nodes;
  • by individual custom dimension 4 - custom dimension 4 nodes;
  • by individual custom dimension 5 - custom dimension 5 nodes;
  • by individual CTP entity - CTP entity hierarchy nodes;
  • by individual CTP custom dimension 2 - CTP custom dimension 2 nodes;
  • by individual currency;

The following attributes should be managed:

  • Accounting model. This is how the system is told which curves must be generated for the account in question. Accounting models of a purchases and sales type can be related to P&L and variation accounts, and accounting models of credit and debit type can be mapped to balance sheet accounts

All Planning accounts must have an associated accounting model; therefore, all those actual balance sheet accounts on which no entries are typically made (e.g. the share capital which, except in cases of capitalisation, remains stable for the entire simulation period) must also have an associated accounting model where it is recorded that that account’s event is the “Initial Balance Sheet” type event ($GIB). The same actual account on which collections/payments are made by means of the cash schedule will be subject to another accounting model where the “Initial Balance Sheet” type event is registered first and the “cash schedule” event ($GSCP) is registered next. The account / accounting model association, and therefore the event, is very useful in the data analysis phase because it identifies which P&L event generated that specific value (for example, if an amount of -100 is associated with a description of the “cash schedule” event, one can easily infer the origin of that value).

  • Event rule. The rule to tell the system how the events included in the accounting model associated with the account must be created. The rule can only be indicated if the accounting mode allows two manual events. If the accounting model allows more than two manual events then the phrase “Multiple values” appears in this field.
  • credit terms rule to be associated with the account
  • Indirect tax policy to be associated with the account
  • Indirect tax rate. Percentage to be applied to the amount for the tax calculation
  • Other indirect tax policy. Any other indirect tax policy in addition to VAT
  • Other indirect tax rate. Any other tax rate in addition to VAT.
  • Payment calendar. If credit terms have been specified, this allows the user to subject the payment / collection of the account in question to certain dates, following a specific calendar
  • Weight. If credit terms have been specified, the account in question can be subjected to a specific weight on which basis to perform certain calculations
  • Non-deductible percentage. If the indirect tax is subject to a certain degree of non-deductibility, it is necessary to set the respective non-deductible percentage

To complete the definition of the relationships between dimensions and financial rules it is necessary, for every variation type P&L account or balance sheet account, to tell the system how the events included in the accounting model associated with the account must be created. In the event that the accounting model provides for two manual events, the definition can be accessed directly from the relationships window, changing the “Event rule” field; if there are more than two manual events, this definition can be accessed from the Define events rule link.

The accrual event is always manual because it is the users themselves who perform the manual data entry of accrual basis items. The accounting event can be created by means of a rule, and specifically the event creation rule, which indicates how that event must be created. For example, we could have a rule of the billing type = accrual + 15 days shift”.

The system automatically opens the event, of a “P&L / variation” type, linked to the selected account’s accounting model. The user must specify:

  • a reference event. This tells the system the event on which basis the same event is created (if for example an “accounting” event is being defined, then the reference event is the “accrual” event)
  • the event creation rule that the system must utilise to create the event itself on the basis of from the reference event.

EXAMPLE 1

Let’s look at an example of how, based on the accounting rule defined, the system creates entries related to the “Purchases” account.

Let us suppose that the accounting model associated with the “Purchases” account (identified in the example by code “50110”) allows the management of accrual, accounting, credit terms and manual payment / collection events, and that the credit terms are 30 / 45 days.

By analysing the details of the accounting model associated with the account in question it is possible to identify, for each managed event, the asset-related and financial entries that the account creates.

(1) Accrual Event

“original account” ($ACCOUNT) A “Original account credit accrual” ($ACCRUAL_CR)

where:

  • $ACCOUNT represents the “Purchases” account
  • $ACCRUAL_CR represents the account which, in the Accounts elements table (Setup & Setup & Admin > Data Model > Dimensions > Account > Elements > Rules tab) (Navigation panel> Data Model > Dimensions > Account > Elements > Rules tab) has been indicated as “Accrual Account: credit”

Let’s suppose that the “accrual account: credit” associated with the “Purchases” account is the “Other assets / liabilities - Variations” account, we will have the following wording

Purchases A Other Assets/Liabilities-Variations

(2) Accounting event

“original account credit accrual” ($ACCRUAL_DR) A “original credit/debt variation account: credit” ($ARAPVARIATION_CR)

where:

  • $ACCRUAL_DR represents the account which, in the Accounts elements table (Setup & Setup & Admin > Data Model > Dimensions > Account > Elements > Rules tab) (Navbar > Data Model > Dimensions > Account > Elements > Rules tab) has been indicated as “Accrual Account: debit”
  • $ARAPVARIATION_CR represents the account which, in the Accounts elements table (Setup & Setup & Admin > Data Model > Dimensions > Account > Elements > Financial Planning tab) (Navbar > Data Model > Dimensions > Account > Elements > Financial Planning tab) has been indicated as “Credit / Debit variation Account: credit”

Supposing that the “accrual account: debit” associated with the “Purchases” account is the “Other assets / liabilities - Variations” account and that the credit/debit variation account: credit is “Trade payables - Variations”, we will have the following wording

Other assets / liabilities - A Trade payables - Variations

Let us also suppose that the accounting model allows VAT to be managed for this event. In this case, when entered in the accounts, the VAT entry for the purchase is also created

VAT receivable A Trade payables - Variations

This entry:

  • writes off the Accrued Liability account adjusted in the accrual event

  • records the VAT generated by the purchase

  • adjusts the debit account indicated as the balance sheet contra-entry during the account setup

(3) Generic credit terms

“original account credit/debit variation” ($ARAPVARIATION_DR) A “liquidity variation: credit” ($CASH_CR)

where:

  • $ARAPVARIATION_DR represents the account which, in the Accounts elements table (Setup & Setup & Admin > Data Model > Dimensions > Account > Elements > Financial Planning tab) (Navigation panel> Data Model > Dimensions > Account > Elements > Financial Planning tab))has been indicated as “Credit/Debit Variation Account: debit”
  • $CASH_CR represents the account which, in the Accounts elements table (Setup & Setup & Admin > Data Model > Dimensions > Account > Elements > Financial Planning tab) Navigation panel>Data Model > Dimensions > Account > Elements > Financial Planning tab has been indicated as “Liquidity Variation Account: credit”

In cases of manual payment, the date to which to attribute the event must be indicated in the projected P&L while, for automatic payments, the event will follow the credit terms rule indicated in the account’s accounting model; in both cases, the following double-entry record is generated:

Trade payables-Variations A Bank c/a Main - Variations

This record highlights a liability financial entry against the closing of the debt resulting from the accounting event

EXAMPLE 2

Now let us suppose that, for the “Purchases” account, credit terms of 60 days are applied to the “Antivirus” product (A01), in contrast to those indicated above. To obtain this outcome, or to manage the exception, it is necessary to enter a row following the previous row in the accounting rule definition, indicating both the “Antivirus” product and the credit terms of 60 days.