Rebates Capability, Creation of Rebate Agreements

Introduction

This article introduces key concepts of the Rebates and how to configure the Rebates Capability to allow the creation of rebate agreements. With rebate agreements, the end-users will be able to define the terms & conditions for the rebates — and be able to calculate forecasts that tells them what the end result of the rebates likely will be.

The next article describes how to further configure the Rebates to be able to calculate the rebate amounts at the end of — and during — the rebate agreement’s validity.

Rebates

A rebate is a variable amount of money that is paid back by the retailer to the buyer at an agreed date, and under agreed conditions. The amount of money is often conditional, for example:

If the customer purchases items for more than X EUR between Jan 1st 2024 and Dec 31st 2024, the retailer should pay back Y% of the total invoice price at the beginning of the next year.

Some companies refer to rebates as bonuses.

Several languages do not have a translation for the word rebate. For example, in German and Scandinavian languages, the word rabatt means discount — while there is no other word for rebate.

Rebate Agreement (RBA)

A Rebate Agreement is an agreement of one or more future rebates; the validity date, the payout dates, the parties involved, the conditions, the amounts etc. In Pricefx, this is represented by the Rebate Agreement (RBA) data type.

Figure 1. Rebate Agreements can be viewed and created by navigating to Rebates > Rebate Agreements.

The structure of the Rebate Agreement resembles that of a Quote, in that it has a Header and multiple Line Items. The header contains information about the agreement as a whole, while the Line Items contain information about the negotiated conditions of the rebates themselves.

Figure 2. The Menu bar in the Rebate Agreement detail page.

Rebate Agreement Header

In the Header section, there is

a set of fixed inputs that exists natively (Figure 3, A).
a set of customizable inputs which are generated by a header logic (Figure 3, B).

Figure 3. The Rebate Agreement detail page, where the header section opened.

Rebate Agreement Line Item (RBALI)

The Items section consists of a set of Line Items (RBALI) (Figure 4, A). Each Line Item represents rebate terms and conditions negotiated for a group of customers and group of products, commonly including impact of those conditions in the form of calculated Rebate estimations and forecasts. A Rebate Agreement may contain multiple Line Items of different types of rebates, for example:

If the customer purchases X% more than the previous year, the retailer pays back Y% of the total invoice price.
Retailer pays back Z EUR (unconditionally).

A Rebate Agreement may also contain Line Items of the same Condition Type that are parameterized differently, for example:

If the customer purchases items from product group A for more than X EUR, the retailer pays back Y% of the total invoice price.
If the customer purchases items from product group B for more than Z EUR, the retailer pays back W% of the total invoice price.

Each Line Item has a set of inputs (Figure 4, B), which are populated by the end-user, and a set of outputs (Figure 4, C) that is the result of the calculation. Typically, the inputs will specify the conditions of the rebate, while the outputs will contain forecasts.

Figure 4. The Interface for adding and editing Line Items on a Rebate Agreement.

Condition Type

Each Line Item in an Agreement references a Condition Type, which is an object that determines how a rebate is calculated.

Figure 5. Screenshot of the page for viewing and editing Condition Types, which is located under Rebates > Condition Types.

The Condition Type holds a reference to a Rebate Calculation Logic that performs the calculation. A Condition Type also has Attribute Columns that are customizable, and can be read by the Logic. Several Condition Types can thus reference the same logic, but produce different outcomes when used in a Rebate Agreement, if the Attribute Columns of the Condition Types are configured differently. In this way, Rebate Calculation Logics can be re-used.

Figure 6. Schematic representation of Rebate Agreement Line Items and Condition Types. The Line Item contains element input and outputs and a reference to a Condition Type. The Condition Type contains values of its Attribute Columns and a reference to a Calculation Logic.

Rebate Agreement Types

With Rebate Agreement Types you can speed up the process of creating new Rebate Agreements. A Rebate Agreement Type is a template that specifies the header, Condition Type filtering and workflow logics and the JSON configuration for dynamic tabs. You can define several Rebate Agreement Types and then quickly create Rebate Agreements based on these types.

Create a Rebate Agreement Type

Go to Rebates > Rebate Agreement Types and click Add Rebate Agreement Type.

Give the new type a name, which must be unique. Note that Rebate Agreement Types cannot be renamed once they are created – you can only change their label.

Optionally, define a label. The label must be unique and it also cannot be the same as an already existing Rebate Agreement Type name. The label can be changed anytime. If a Rebate Agreement Type has a label, it will be displayed on the Rebate Agreement list and detail pages instead of the name.

Select the desired header and Rebate Agreement workflow and Rebate Record workflow logics. The drop-down lists contain only active logics – you can, however, type any logic’s label into the field.

Select a filtering logic that will offer only some Condition Types for the user to select from when creating a new Rebate Agreement.

In the Configuration text box, you can define the tabs of the Rebate Agreement in JSON format. This way, you can add a tab that will work with the values entered on other tabs – for example, you can have a tab with a dashboard whose inputs will use the values entered by the user on the Items tab. See the Knowledge Base article Detail Page Layout and Dynamic Tabs for details.

You can limit which Rebate Agreement Types the user will see when creating a new Rebate Agreement by adding a user group in the User Group (View Details) column. Similarly, you can determine which users will be able to edit a Rebate Agreement Type. Remember that certain rules apply to the combinations of user group entitlement settings.

Click Add.

Calculating Rebate Agreements

During the negotiation of a Rebate Agreement, the end user can click on the Recalculate button on the Rebate Agreement detail page.

Figure 7. The button for Recalculating a Rebate Agreement with the Line Items as Context.

When this button is clicked, then

the Rebate Header Logic is executed in PrePhase mode
for each Line Item, the system will execute that Rebate Calculation Logic, which is associated with the Rebate Type of the Line Item
the Rebate Header Logic is executed in PostPhase mode
the results/outputs are returned back to UI and displayed to user.

When submitted, the Rebate Agreement is locked for editing, recalculated and saved, the approval workflow steps generated and workflow steps are executed.

Once the Rebate Agreement is locked for editing, it cannot be recalculated manually. It will only be recalculated each time you open it on the screen, but only within the "agreement read-only" context of the calculation logic. Such result is not saved, only displayed in the UI.

Figure 8. The sequence of events up until the Rebate Agreement is submitted.

Because the Logics are executed during the negotiation of the Rebate Agreement, i.e. before any transactions have taken place, the rebate amount cannot be calculated yet. Therefore, this calculation typically results in forecasts and estimations of what the final rebate amount may be.

Figure 9. Illustration of the calculation that is performed when the end-user recalculates the Rebate Agreement during the negotiation, (on the Rebate Agreement detail page).

In order for the rebate amount to be calculable, the Logic needs to produce at least one object of the type Rebate Record (RR). This is achieved with the Groovy API method rebateRecords.add(). The Rebate Record holds a reference to the Line Item’s Rebate Type, and copies of all the Line Item input and output values. How the Rebate Record is used to calculate the rebate amounts is described in the next chapter.

Summary

A Rebate Agreement represents a contract between buyer and seller.
A Rebate Agreement has multiple Line Items, which corresponds to sets of rebate amounts.
Each Line Item references a Condition Type, which describes how to calculate a set of rebates (among other things, such as forecasts). Each Rebate Type references a Calculation Logic.
Several Rebate Types may share reusable parts in the same Calculation Logic. To make it possible for the Logic to behave differently for different Condition Types, use the attribute columns on the Condition Type to pass “settings” to the logic.
During the negotiation of the Rebate Agreement, the Rebate Calculation Logic typically outputs forecasts.
When a Rebate Agreement is submitted for approval, the Rebate Calculation Logics will produce Rebate Records, which are necessary to later calculate the Rebate amounts.