Create Calculated events

The manageable events can be classified into two groups:

  • those which, for the “Accrual” event, they simply have to register a precise value per account and do not need a rule to tell the system how they must be created. Within these, Tagetik has already defined a series of events that cover the vast majority of the entries necessary to manage financial planning. The management of the various event types can be accessed from the administrator-user’s web interface, by following the path Setup & Admin > Data Processing > Cash Flow Planning > Advanced Financial Rules > Event types; Navbar > Data Processing > Cash Flow Planning > Advanced Financial Rules > Event types;
  • those which are inferred from other events and therefore need a rule in order to be created. For example, consider the advanced quarterly billing for rents entered in the accounts at the start of every quarter. In this case the entry in the accounts does not match the accrual and it is therefore necessary to tell the system that the “accounting” event must be calculated on the basis of the accrual event. In this way, entry in the accounts is subordinate to the rule defined and the system will create the event as if it had been set within that rule, instead of setting a manual entry to be made subsequently from the Projected P&L management window

The management of those rules is accessible from the administrator-user’s web interface by following the path Setup & Admin > Data Processing > Cash Flow Planning > Financial rules > Event rule.

Navbar > Data Processing > Cash Flow Planning > Financial rules > Event rule;

Every rule is identified:

  • by a code
  • by a description
  • by the grouping method with which the event with respect to the source event must be generated. This grouping can be defined by means of a bundling type, as is the case for advanced bimonthly billing, i.e. by means of a weight, as is the case for taxes accrued where the amount booked at the year-end can be unpacked into twelfths leading to a flat amount of taxes being entered on the P&L every month.
  • BUNDLING. The user must indicate:
  • a frequency which specifies the frequency with which the event must be created in relation to the source event. The classic case is wanting to shift from accrual to bimonthly billing, and in this case we will set the bundling type to bimonthly. It is possible to use monthly (this makes sense if the source event has daily or weekly granularity), annual, bimonthly, quarterly, four-monthly or six-monthly frequencies
  • a type indicating whether the bundling takes place in advance or deferred. If the user selects the Advanced option, the system creates the event on the first day of the bundled period (this is the case for advanced bimonthly billing), but if the user selects In arrears the system creates the event on the last day of the bundled period (this is the case for deferred bimonthly billing)
  • the start month which is the period from which the source event (generally accrual) must start to be bundled; this period is generally the first planning month but in specific cases it may be different
  • WEIGHT. The user must indicate:
  • a type to be used to weight the amount relative to the event
  • the data processing method associated with the weight (Method). If the user selects the Keep annual values option, the system keeps the annual total unchanged (this is typically used to change the monthly splitting), while if the user selects Keep monthly values, the system keeps the period total unchanged (this is typically used to split down into days)
  • by a potential shift in time which indicates the amount of time by which the calculated event must be shifted in relation to the original event. The shift can be:
  • “general”, with the same shift being applied to all periods. In this case it is necessary to indicate the percentage, the months and/or the days
  • “by period”, where the shift is performed on individual months and differently for each month. In this case the number of days by which the event must be shifted over time must be specified for every period

In caso di accorpamento, le date in cui il sistema accorpa devono appartenere ad uno scenario periodo del processo.

The user can therefore define a rule which provides for:

  • bundling or the use of a weight;
  • a shift only;
  • bundling or the use of a weight plus a shift.

Example. Let us suppose we need to define an Event Creation Rule with advanced bimonthly billing and a shift of 29 days

Once the code and description of the rule have been indicated, it is necessary to specify:

  • the frequency. Because the rule to be set up must have a bimonthly entry, the user must indicate “Bimonthly”;
  • the type. Because the rule to be set up must have advanced bimonthly entry, the user must indicate “Advanced”; this makes the system “group” the monthly amounts on a bimonthly basis and book the bundled entry on the first day of the bundled month;
  • the start month. This indicates the month from which the bundling must take place; the start date is typically always January, then, depending on the type of process that we are carrying out (Budget, 1st Forecast, 2nd Forecast), the system will subordinate that start date to the simulation start period;
  • shift days equal to 29. The bundled amount, which without this indicated would be registered on the first day of the bundling month, is shifted by 29 days.

Therefore, given an accrual basis split monthly over 12 months, this rule generates the following accounting event: