Rebate Record (RR)

Rebate Records, sometimes incorrectly referred to as "Payout Records", are created for each line of a Rebate Agreement.

Rebate Records are used for:

• Regular re-calculation of the rebate status during the year.

• Approval of the rebate value.

• Export of the approved payout money to the ERP system (to be paid to the customer).

• Allocation of the rebate to the archived Sales Transactions.

Reasons for separate Rebate Record entity:

• When the business user prepares the agreement, the agreement is in a draft state, so it is editable and it is possible to recalculate it. Once you approve the agreement, it will become read-only/fixed and you cannot recalculate it anymore.

• But the agreement is valid for long period of time (usually a year) and the business needs to recalculate the accruals and estimated rebate size again and again during the whole agreement validity.

• In addition, if you have more payout periods needed during the validity, it could be handy to calculate and approve the rebate money separately for those periods (e.g. semi-annually, quarterly, monthly).

When the logic calculates the Rebate Agreement line items, it also creates its RRs which will be used later for storage of results of the repetitive recalculations of the accruals and rebate estimations.

The RRs are recalculated:

• Manually by the business user, on the RR detail screen.

• By a specialized scheduled job, configured in Rebates › Calculations.

The list of Rebate Records is located in Rebates › Rebate Records.

Open

Figure 1. Rebate Records list

The Rebate Records table summarizes the status and rebate accruals across all customer rebate agreements. There is also integration status history available via an inline Rebate Record button. Admin user can also manually adjust/override RRs or generate RRs for corrections.

Open

Life Cycle

1. Creation – Rebate Records are created by the line item logic, i.e. when the logic calculates the results for the line items.

   • Most of the Rebate Record’s fields are the same as for a line item, and their values are copied automatically from the line item at the time of the RR creation.

2. Calculation – Rebate Record results (usually rebate amount estimations and others) are calculated by a Rebate Record logic and stored in the Rebate Record’s attributes.

3. Approval – The approval of Rebate Record is usually used to approve the amount of rebate money calculated, to make sure it can be paid to the customer.

4. Export – Once the rebate amount is approved, it is exported to an external system to be paid to the customer.

• Think about the Rebate Record as a storage for your calculation needs, so you can either have only one RR for the line item or many more.

• Often you use several RRs to make separate calculations for shorter time periods, e.g. when the line item validity is a year, and it should be paid quarterly, then it could be handy to create four Rebate Records, each calculating rebate for one quarter.

  • It does not have to be just time period, maybe you will need to split the calculation across different dimensions, e.g. smaller groups of products, certain countries, etc.

• You can also split RRs into more "sets".

  • One set of Rebate Records to calculate the "accruals";

  • and another set of Rebate Records for "payouts" (this payout is meant as a business term). For this purpose, you can assign each RR into a different "set".

Fields

rebateType – Rebate type associated with this RR, it is the same as the one used for the line item.

rebateRecordSet – Name of the RebateRecordSet into which this RR belongs. By default, it belongs to "Default" RebateRecordSet, but you can change it when you create the RR. That can be useful if you create different "kinds" of RRs which will be used to calculate different results at different times.

rebateRecordGroupUniqueName – Name of the RebateRecordGroup into which this RR belongs. By default, it belongs to either none or automatically created RebateRecordGroup (depends on setting in HeaderRebateType.recordWorkflowFormulaTarget), but you can change it when you create the RR. That can be useful if you want to split the RRs into groups, in which the RRs can be approved all together instead of one by one.

inputs – Inputs specific to the RR. When the user reviews the individual RR, they might need to enter certain values/setting specific for that particular values. The rebate logic (for RR) can specify those input fields.

agreementInputs – Input fields copied automatically from the line item. As the RR basically calculates the same values which were calculated during the preparation of the agreement on the line item, the RR needs access to the values entered by the user on the line item.

attribute1..100 – Fields for storage of values. The values are calculated and stored here by the Rebate Record Group Logic.

attributeExtension – Additional attributes fields, which can be used in similar was as attribute1..100 fields. See Attribute Extension fields.

status – Rebate Record Status. Represents the current lifecycle status of the Rebate Record.

agreementStatus – The status of the Rebate Agreement that the Rebate Record was created from. When an agreement revision is created, the 'Agreement Status' field on the Rebate Records for that agreement (not the status of the agreement) is set to either superseded or invalidated. All valid values are listed in the Rebate Agreement status article.

calculationBase – Filter for Datamart used for the Rebate Allocation process and also to display associated transactions on the RR detail screen. Accruals and rebate estimations are typically based on data from Datamart. To specify which transactions should get a portion of the calculated rebate money amount, you need to specify the CalculationBase filter. The Datamart name is specified later, during configuration of the Allocation Process.