You can set up Agreements & Promotions Calculation background tasks for (re-)calculation of Agreements/Promotions and creation of new Price Records in case your source data have changed. A Price Record is calculated by a logic associated with its Agreement & Promotion Type. The logic decides how to calculate Agreement/Promotion line items as well as the Price Records for the given Agreement & Promotion Type. This is determined on the logic element level by setting the 'Groups' to which the element applies.

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

There are two main ways of determining which Agreements/Promotions are to be calculated by such a task:

Using a static filter on the set of Agreements/Promotions.
Using a so called 'feeder logic' which is a sort of algorithmic filter.

Configure Agreements & Promotions Calculations

Go to Agreements & Promotions > Calculations.
Click Add Calculation.
Define the new calculation’s Label and click Add to save it.
On the list page, click on the Calculation’s label to open it for editing.
Decide whether to use a static filter (Agreements & Promotions tab) or a feeder logic (Calculation tab).
- When using a static filter, configure it on the Agreements & Promotions tab.
- When using a feeder logic, set it on the Calculation tab. When a feeder is used, any filter set on the Agreements & Promotions 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 Agreement/Promotion filter falls short, for example if you want to: parametrize the Agreement/Promotion selection (using feeder inputs), implement an incremental calculation mechanism, perform multi-step filtering logic, etc.
  The Calculation tab also allows you to specify a 'logic', which would then be used to calculate the Agreements/Promotions (instead of the logic set on the Agreements & Promotions Type). This is an option in advanced simulation scenarios where the Price 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 Agreements & Promotions logic and can be used for multiple purposes, not just in Agreements & Promotions or Analytics calculations. In this case, though, the only application is in a Price Record calculation. A feeder that finds all Price Records in draft agreements, not re-calculated since a modification was made to those agreement can be implement (see Rebate Calculations for an attached feeder JSON example).
Save the calculation and run it (click the Run Calculation button) and/or schedule it.
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.