Rebate definitions allows you to define and maintain Rebate agreements with the customers whose activities earn the rebates, the organizations that receive the rebates and how they are rebated, and the rates at which the rebates are calculated for various types of transactions. The rebate definition details may be changed at any stage. If the rebate definitions are changed then the following actions must be taken to reflect the new definitions.
- Re accumulate sales to determine new level of rebates
- Generate further accruals that correct the accruals generated against the old definition details then give effect to the new rebates
- Generate new payments taking into account previous accounts and new rebates.
Add rebate definition details
- In the menu, expand Other Modules > Rebate & Commissions > Maintenance and double-click RB Definition Maintenance. RBW100 Rebate Definition Maintenance panel appears.
- Click function Add. RBW120 Rebate Definition Maintenance panel appears.
| Field | Description |
| Rebate number | System generated number to uniquely identify the rebate definition agreement (RB-RDN). |
| Rebate company/currency | Rebate agreements are setup by company (owner) and only customers belonging to the rebate company will have its sales included in the rebate calculation. The rebate agreements will have its own currency. |
| Rebate type | The Rebate type and Rebate groups form part of a hierarchy for classifying Rebate contracts. TMSRB/RB-TYPE is used to define the list of valid rebate types. |
| Rebate group | A Rebate group is similar to a Buying Group. Buying groups created for Rebates will probably be the same or similar to TMSDS/CC-BG, but does not have to be. |
| Rebate group level | Once the Rebate group has been entered in the previous field, this Rebate group level will default and can be overridden. An example of levels is: INDIVIDUAL STORES SALES DIVISION DISTRIBUTION CENTER HEAD QUARTER BUYING GROUP Buying Groups typically have several levels as each member of a group may itself consist of a sub group. Rebates can be applied at each/any level and may replace or be in addition to rebates at other levels. All rebate definitions may be given a level within the Buying Group where that level can then be used to specify whether the rebate is in addition or replaces rebates at other levels. The rebate level is applied at the rebate definition, it is NOT necessary to code customers with a Buying Group level class. |
| Rebate at higher level/Skip to level |
Rebates may be applied at any level in the Buying Group’s hierarchy. Rebates will always add to rebates at lower levels in the hierarchy
With option 3 = skip to a specific level, nominate the Skip to level. |
| Trade agreement/status | Trade agreement can be an agreement number or text to identify the agreement with the customer. Rebates may be flagged as Active or Inactive. Active rebates can be accumulated, accrued and paid, inactive rebates can not. After activating an Inactive rebate you must rebuild the rebate to ensure that it’s accumulated sales and rebates earned are corrected for any activity that happened during the period a rebate was inactive. |
| Start date/period | Starting date and period of the rebate cycle. |
| End date/period | Ending date and period of the rebate cycle. |
| Targeted period | This is the number of periods in the rebate cycle as defined in system control TMSRB/RB-PAY. |
| Monthly sales profile | The monthly sales profile code is mandatory and is used to spread the accrual over a period of time which could be a year, 3 months, etc. Note: Monthly sales profit must be blank if not selected in the accrual method/rate field. |
| Targeted accrual rate |
This is the method by which the rebate accruals are calculated and if Method 5 is selected, the rate must be entered. If this field is changed during the life of a rebate the first run after the change may produce a large change in the amount of any rebate accrued. Depending on the nature of the change it may be necessary to perform a complete rebuild of the rebate to get the correct accrual. It is necessary to do a rebuild if the accrual is to be spread over time rather than taking the change in one hit on the first day after the change. |
| Apply on differential |
The method of applying the rebate defaults and can be overridden. Codes to apply Rebates on Differential or Absolute are established in TMSRB/RB-ARDA. The system codes are: 1=differential b/w current & prior target 2=absolute value of sales Rebates may have several steps or targets. For example: 0 = 100,000 1% 100,000 = 150,000 2% 150,000 = 200,000 3% 200,000 = 300,000 4% If the customer achieves sales of $175,000 then with a rebate applied: on target differential, the rebate would be: 1% of $100,00 + 2% of $50,000 + 3% of $25,000 on absolute, the rebate would be: 3% of $175,000 |
| Include tax | Specify if tax is to be included in rebate calculation. TMSRB/RB-TAX can be setup to ignore the tax rule defined in TMSRB/RB-TYPE. |
| Rebate targets are | Nominate if rebate is to be targeted from sales value or sales quantity. |
| Rebates amount is | Rebate amount can be based on a percentage of sales or $ value per unit sold or a fixed $ value upon reaching a certain target. |
| Payment method |
The Payment method can relate to Accounts Payable or Accounts Receivable. Payment may be made via:
The rebate definition file provides options to control whether the individual customer (or his nominated agent) receives the payment or it is paid to a nominated customer such as the Buying Group’s head office. If the Payment method is credit note, there is no interface to Accounts Payable. |
| Payment frequency | How often the rebate will be paid out. This will default but can be overridden. |
| Apportion payment to | The Apportion Payment code defaults and can be overridden. Rebates may be paid to a nominated account (for example the buying group head office) or the actual customers earning the rebate. Regardless of this setting the underlying rebate is recorded at the lowest level of customer earning the rebate. This setting is only used when the rebate payment is actually made. |
| Nominated customer |
If the payment method is 1 = Cheque via AP then nominate a customer that is linked to a creditor or link a creditor via function Link. The creditor linked to the nominated customer will receive the rebate payment via AP. If the payment method is 2 = Credit note via AR then nominate a customer to whom the rebate payment is to be allocated to. For example if the stores earn the sales but the payment is to be made to the head office. You can also nominate an agent for the nominated customer to receive the rebate via function Link. If an agent is linked to the nominated customer then the agent will be allocated the rebate instead of the nominated customer. |
| Last cycle paid | Display field for the last payment. |
| Function | Description |
| Link |
If the payment method is 1 = Cheque via AP then use this function to link a creditor to the nominated customer. The creditor linked to the nominated customer will receive the rebate payment via AP. If the payment method is 2 = Credit note via AR and the rebate is to be allocated to an agent of the nominated customer rather than the nominated customer then nominate the agent via this function. |
- Enter the required details and click OK. RBW120 Rebate Definition Details panel appears for movement and target details entry.
- Enter the applicable Movement for the rebate definition and the corresponding targets and rates.
- Click OK. RBW200 Rebate Customer Definition Maintenance panel appears.
- Enter the selection for Customer, Branch, Region etc. that applies to the rebate definition and click OK.
- Enter any Classification types and Classification codes if applicable and click OK to save the rebate definition.
