You can set up Rebate Record Calculation tasks for (re-)calculation of Rebate Records in the background. A Rebate Record is calculated by a logic associated with its Rebate Condition Type. The rebate logic decides how to calculate Rebate Agreement line items as well as the Rebate Records for the given Rebate Condition Type. This is determined on the logic element level by setting the 'Groups' to which the element applies.

The guiding principle when writing a rebate logic is to keep the computation complexity down for the Rebate Agreement line items. The reason is that Rebate Agreements are calculated within a user session (in the UI page) and the user expects an immediate response. The agreement-level logic prompts for inputs (customer(s), product(s), negotiated terms...) and returns information, potentially including some guidance on the past performance, that allows the user to complete a negotiated agreement with a customer.

The Rebate Record, on the other hand, carries the heaviest part of the calculation. In order to determine the rebate accruals, a potentially large volume of actual transaction data is processed. This heavy lifting cannot normally be done in real time, hence the need for background/batch jobs. It is also a process which is typically completed at the end of a (financial) period, i.e., less frequently. The vehicle for these batch calculations is the Rebate Calculations, accessible in the main Rebates menu.

 Users are not allowed to delete the default Rebate Calculation (since it is necessary to have it for the Rebate Records Mass Submit action).

There are two main ways of determining which Rebate Records are to be calculated by such a task:

1. Using a static filter on the Rebate Record set.

2. Using a so called 'feeder logic' which is a sort of algorithmic filter.

Step-by-step Guide

1. Go to Rebates > Rebate Calculations.

2. Click Add Rebate Calculation.

3. Define a label and decide if the set will be default or accrual.

4. Decide whether to use a static filter (Rebate Records tab) or a feeder logic (Calculation tab).

   Open

   

   • When using a static filter, configure it on the Rebate Records tab.

     Open

     

   • When using a feeder logic, set it on the Calculation tab. When a feeder is used, any filter set on the Rebate Records tab is ignored.
     A feeder can have inputs just like any other logic, but in this example all the inputs are provided by the logic.

     A feeder can be used where a static Rebate Record filter falls short, for example if you want to: parametrize the Rebate Record-selection (using feeder inputs), implement an incremental calculation mechanism, perform multi-step filtering logic (first find relevant agreements, then Rebate Records within those agreements), etc.
      The Calculation tab also allows you to specify a 'logic', which would then be used to calculate the Rebate Records (instead of the logic set on the Condition Type). This is an option in advanced simulation scenarios where the Rebate Record calculation logic deviates too much from the regular accruals calculation logic.
     Feeders are created under the Generic Logic header – the reason for this is that they do not (always) implement specific Rebate logic and can be used for multiple purposes, not just in Rebates or Analytics calculations. In this case, though, the only application is in a Rebate Record calculation. A feeder that finds all Rebate Records in draft agreements, not re-calculated since a modification was made to those agreement can be implement like this (feeder JSON example attached).

5. Save the calculation and run it (click the Run Calculation button) and/or schedule it.

   During the calculation, Rebate Records are locked. Administrators can, however, unlock selected Rebate Records on the list page if needed.
   When configuring the schedule, among the available options are:

   • Time Zone – This option ensures that the calculation job will always run at the selected local time even after switching to/from the daylight saving time. Check the Next Run column to verify that your setting is correct.

     The reason for making the setting here is that the Default Timezone option in General Settings sets only the offset from UTC. This offset and the UTC remain the same when your time zone switches to/from the DST. It means that if you set the start time, for example, to 10 AM CET in the winter (UTC+1) then after switching to the DST (UTC+2), your job will run at 9 AM CEST because your offset from the UTC remains +1.

   • Period – Select if the calculation job will run every X minute, hour, day, month or year.

   • Interval – Represents the number of repetitions in the selected period (e.g., if you set Period = day and Interval = 1 and Start Date = 27/11/2015 10:00, the calculation job will run every day at 10:00 AM, starting on 27/11/2015). You can also enter "0" for jobs that you want to run just once.