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.