REBATE AGREEMENTS
FUNCTIONAL DESCRIPTION
PRODUCT REQUIREMENTS PLANNING
Version 1.1
April 1998
Table of Contents
1. Introduction ....................................................................................................................................... 3
2. The Basics: Rebate Agreement Life Cycle........................................................................................ 3
2.1 Defining a Rebate Agreement ....................................................................................................... 3
2.2 Working with Open Rebate Agreements ...................................................................................... 5
2.3 Final Settlement of a Rebate Agreement ...................................................................................... 6
3. Initial Configuration .......................................................................................................................... 6
3.1 Activate Rebate Processing .......................................................................................................... 6
3.2 Define Material Rebate Group ...................................................................................................... 7
3.3 Condition Technique for Rebate Processing................................................................................. 7
3.3.1 Condition Tables .................................................................................................................... 7
3.3.2 Condition Types ..................................................................................................................... 7
3.3.3 Access Sequences................................................................................................................... 8
3.3.4 Pricing Procedure ................................................................................................................... 9
3.4 Account Determination for Rebates.............................................................................................. 9
3.5 Rebate Agreements ..................................................................................................................... 10
3.5.1 Define Agreement Types ..................................................................................................... 10
3.5.2 Condition Type Groups ........................................................................................................ 11
3.6 Passing Accruals to Profitability Analysis .................................................................................. 11
4. Rebate Index - VBOX ..................................................................................................................... 11
5. Rebates Statistics Structure – S060 ................................................................................................. 12
6. Creating a Rebate Agreement .......................................................................................................... 12
6.1 Sales Volume Dependent Rebate Condition Record .................................................................. 13
6.2 Sales Volume Independent Rebate Condition Record ................................................................ 14
6.3 Rebate Material for Settlement ................................................................................................... 14
7. Accrual Correction .......................................................................................................................... 14
8. Partial Settlement ............................................................................................................................ 15
8.1 Partial Settlement for an Individual Rebate Agreement ............................................................. 16
8.2 Mass Partial Settlement .............................................................................................................. 17
9. Final Settlement ............................................................................................................................... 17
9.1 Final Settlement for an Individual Rebate Agreement................................................................ 18
9.2 Mass Final Settlement ................................................................................................................. 19
10. Manual Accruals............................................................................................................................ 19
11. Mass Copy of Rebate Agreements ................................................................................................ 20
12. Rebate Agreement Reporting ........................................................................................................ 21
13. Recalculate Subtotals for Rebate Processing................................................................................. 22
Appendix A: Technical View of Rebate Index - VBOX ...................................................................... 23
Page 2
Product Requirements Planning
Version 1.1
1. Introduction
Promotion management represents a key business process flow in many different industries. In order
to boost sales for an existing product or to support the introduction of a new product, manufacturers
will offer special deals to their customers. Within a given promotion, companies differentiate
between deals that the customer will receive immediately when an order is placed (off-invoice
discount) versus deals which will be paid at a later date dependent on cumulative sales volume or a
particular performance (rebate agreement).
R/3 supports both off-invoice as well as rebate agreements. This paper focuses on the functionality
SAP provides in the area of rebate agreements. The first section provides an overview of the
functionality by examining a rebate agreement life cycle. The second section provides a more
detailed description looking at each of the individual features. This paper assumes that the reader has
a working understanding of the SAP pricing condition technique.
2. The Basics: Rebate Agreement Life Cycle
Rebate agreements can span weeks, months or years depending on the nature of the agreement with
the customer. In a simple process flow, a rebate agreement could be represented as follows:



An agreement is defined with a customer for a rebate of 5% on all sales of Product A within a sixmonth period.
During the agreement period, accruals are generated in financial accounting per billing document
to represent the 5% of sales that will eventually be paid out.
When the validity period is over, the user runs a settlement program that creates a payment for the
relevant amount. This payment could be made in the form of a credit memo, check, bank transfer
or some other form of payment.
SAP supports this simple example as well as more robust functionality as described below. Sections
2.1 through 2.3 are meant to provide an overview of the features R/3 provides in these areas. Further
detail on individual topics as well as system configuration can be found in later sections.
2.1 Defining a Rebate Agreement
A rebate agreement in R/3 includes the rebate recipient who will receive the ultimate payment as well
as all of the rebate records that will form the basis for the payment. Rebate agreement processing in
R/3 makes use of the SAP condition technique. This allows the user the ability to define rebate
records at various levels. For example, the user could create an agreement that is relevant for a
specific (customer / material) combination or for other combinations such as (customer hierarchy /
material) or (customer / product hierarchy). The definition of the record will determine the level at
which R/3 cumulates the sales volume to compute the rebate. Refer to Figure A for a rebate
agreement example.
In the example portrayed in the figure, an agreement has been defined for “Star Markets” that
includes two rebate condition records. The first record provides the customer with a scaled rebate
based on all purchases of Material A during the rebate validity period. Payment rates are read when
Page 3
Product Requirements Planning
Version 1.1
final settlement is carried out for a rebate agreement. The cumulative sales volume would be used to
determine a payment rate of 0, 5, or 10%.
Rebate Agreement: Q2 1998: New Products
Rebate Recipient: Star Markets
Validity:
03/01/98 - 07/31/98
Rebate Records
1: Star Markets / Material A
Accrue:
5%Payment:
from $10,000 5% from $20,000 10% 2: Star Markets / Material B
Accrue:
10%Payment:
from $10,000 10% from $20,000 15% -
Figure A: Rebate Agreement
In addition to the payment rate, the user also specifies the rate at which the system should accrue to
financial accounting. In this example, the user estimates that the customer will reach the 5% rebate
level. The accrual rate will be applied to all relevant billing documents for “Star Markets” and
Material A processed during the agreement period. The accrual rate will be multiplied by the value of
the billing document line item and passed to R/3 Accounts Receivable as an accrual. Note that the
accrual rate is a single value and is not scaled.
A second rebate condition record has also been defined specific to Material B. In this example, 10%
will be accrued per billing document with a payment rate equaling 0, 10, or 15% dependent on sales
volume. Settlement of the above agreement will lead to one credit memo generated for “Star
Markets” which will include the rebate earned for both rebate condition records. R/3 does not require
that the rebate recipient of the rebate agreement be part of the variable keys of the rebate condition
records. For example, a central head office for a customer could be defined as the rebate recipient
who could earn a rebate based on sales to a number of different customers who are listed within the
rebate condition records.
R/3 rebate agreements are additive in nature versus exclusive. This means that all rebate condition
records that apply to a billing document based on the pricing procedure will be added to the
document. As an example, assume that the following access sequence exists for a rebate condition
type and that a rebate condition record has been maintained at every level of the access sequence.
10
20
30
Customer / Material
Customer Hierarchy / Material
Customer Group / Product hierarchy
All three of the condition records would be applied to the billing document. It is not possible to work
with the exclusion indicator in the access sequence (as is available with off-invoice discounts) to tell
the system to stop after a hit has been found, for example, at access level 10.
Another difference between off-invoice discounts and rebate agreements is that rebate condition
records may overlap one another. Since rebate agreements are additive in nature, both of the
Page 4
Product Requirements Planning
Version 1.1
overlapping condition records would apply to a billing document during the period in which they
overlap. This feature allows users the ability to define, for example, an annual rebate with the
customer for 5% of sales of Material A with an additional rebate offered in the month of June for an
additional 2% rebate.
Many companies run cyclical rebate agreements with their customers that are valid for a period of
time such as a month or a year. In this situation, users require mass maintenance tools allowing them
to quickly copy outstanding agreements from an existing period to a subsequent period. This is
common at year-end when new rebate agreements should be set up for the following year using the
current year as a basis. This functionality is available in R/3 using the rebate agreement Extend
feature.
When working with bill-back promotions, companies often have the requirement to set up a rebate
agreement after the fact. For example, a rebate agreement may be defined by the marketing
department in June that should have been applicable from the beginning of the year. R/3 supports this
requirement allowing users to define retroactive agreements. When a rebate agreement is created,
R/3 compares the creation date of the agreement with the beginning of its’ validity period. If the
creation date lies after the start date, R/3 automatically flags the agreement as retroactive. Special
processing then occurs during final settlement to ensure that the system includes the sales volume that
occurred prior to the creation of the agreement. The user may also decide to immediately carry out an
accrual correction to capture the accruals that should have already been posted for the agreement.
Accrual correction is previewed in the next section.
In addition to rebate agreements that are dependent on sales volume, many companies require
functionality to pay lump sums based on a particular performance. For example, a manufacturer
could agree to pay $5000 to a retailer for a front of store display, or for advertising that a retailer is
running in a local area. R/3 supports this type of agreement as well.
2.2 Working with Open Rebate Agreements
R/3 supports a variety of features for open rebate agreements. For example, an accrual correction
may be required. An accrual correction may be necessary when a retroactive agreement is created or
when an accrual rate for a rebate record has been changed after the start of the agreement. In the
retroactive example, the system would find all of the billing documents which were processed prior to
the creation of the agreement; compute the accrual which should have been posted; and pass this
information to accounting. In the second example, R/3 would find all of the billing documents related
to the rebate agreement and compute the difference between the accrual that was posted with the old
rate and the new rate. This difference would then be posted to Financial Accounting.
Another common requirement is the ability to carry out partial settlement for a rebate agreement. In
this case, the rebate recipient would like to receive a portion of the rebate amount before the end of
the rebate period. This may be necessary based on a request from the customer, sales rep, or to clear
a customer deduction. R/3 provides a flexible tool for partial settlement allowing the user to specify
the amount that should be paid as well as the form a payment. Controls are also built in, for example,
to limit the amount of the partial settlement to the cumulative accruals of a rebate condition record.
The user also has access to a payment history to review the activity of an agreement.
R/3 rebate agreements also provide the user with a revenue overview. This allows the user the ability
to view the sales volume that has been posted for an agreement. The user is able to view the
information at a consolidated level or drill down to an individual billing document level. In addition
Page 5
Product Requirements Planning
Version 1.1
to these reporting options, R/3 also provides immediate rebate accrual visibility in CO-PA
(Profitability Analysis).
2.3 Final Settlement of a Rebate Agreement
After a rebate period has ended, the user can carry out final settlement for many agreements at once
using the mass settlement program. In this step, R/3 does the following:





Calculates the cumulative sales volume per rebate condition record.
Reads the payment scale for each record and determines the payment rate.
Multiplies the payment rate by the sales volume and then subtracts out any partial settlements to
determine the net payment.
Determines the amount of open accruals per rebate condition record.
Creates a credit memo request to pay the amount to the customer and to reverse the open accruals
in accounting. The payment method specified in the credit memo request controls how the
payment should be made. Some options include check or bank transfer.
3. Initial Configuration
This section covers the configuration steps necessary for rebate agreement processing. The topics
listed follow closely with the R/3 Customizing IMG. Rebate agreement customizing can be found in
customizing under the path: Sales and Distribution  Billing  Rebate processing.
3.1 Activate Rebate Processing
In this step, the user defines the sales organizations and billing document types that should be active
for rebate processing. When setting the flags for the billing document types, make sure that the flags
are also set for the following four standard rebate credit memo types delivered with the system.




B1 – When final settlement is carried out for a rebate agreement, a B1 credit memo is generated
by the system. Refer to section 9 “Final settlement” for additional information.
B2 – A B2 credit memo indicates a rebate correction. This document is generated, for example,
when an accrual correction is performed on a rebate agreement. Refer to section 7 “Accrual
correction” for more information.
B3 – When partial settlement is carried out for a rebate agreement, a B3 credit memo is created.
Refer to section 8 “Partial settlement” for more information.
B4 – The B4 credit memo type is used to record manual accruals for a rebate. This is used
primarily for agreements that depend on a performance, rather than sales volume. Refer to
section 10 “Manual Accruals” for a full description.
In addition to these two flags, the user must also indicate which payers are active for rebate
processing by setting the “rebate” flag in the customer master on the “Billing” screen. The system
will only apply rebate condition records to a billing document if the sales organization, billing
document type, and payer of the document are flagged for rebate processing. This step is important
from a performance perspective for two reasons. First, R/3 will avoid looking for rebate records, for
Page 6
Product Requirements Planning
Version 1.1
example, for payers that are not relevant for rebates. The second reason has to do with retroactive
agreements. In order to support retroactive agreements, R/3 makes use of an index (VBOX) which is
updated when a billing document that is “rebate relevant” is created. Unnecessary index entries can
thus be avoided by selecting only the sales organizations, billing document types and payers that are
eligible for rebates.
Note: It is possible to set one of these flags at a later date after documents have been created. The
system would then prompt the user to initiate the index (VBOX) reorganization program.
3.2 Define Material Rebate Group
The material rebate group is a field in the material master record that can be used to group materials
together from a rebate perspective. For example, a customer could get a rebate based on all materials
they purchase which are assigned material rebate group “20”. This is just one way of grouping
materials for rebates. Similar to pricing condition records, the user could also grant rebates based on
product hierarchy, material pricing group, etc. R/3 delivers the standard rebate condition type BO01
that contains an access sequence using the material rebate group. It is not necessary to use this
option.
3.3 Condition Technique for Rebate Processing
Similar to regular pricing, rebate processing works with condition tables, condition types, and access
sequences. R/3 delivers the following standard elements. Additional condition elements can be
defined if the standard entries are not sufficient.
3.3.1 Condition Tables
R/3 delivers the following rebate condition tables.
 001
Customer / Material
 002
Customer / Rebate Group
 003
Customer
 004
Customer Hierarchy
 005
Customer Hierarchy / Material
Rebate condition records are unique and must be stored in condition tables specifically created for
rebates. As a result, if a user already created a new condition table for pricing with the variable key
(Customer / Product Hierarchy), and would like to use the same key combination for rebates, an
additional “rebate” condition table must be created.
3.3.2 Condition Types
R/3 delivers the following rebate condition types with their associated access sequences.
 BO01
Group Rebate
BO01
 BO02
Material Rebate
BO02
 BO03
Customer Rebate
BO03
 BO04
Hierarchy Rebate
BO04
 BO05
Hierarchy Rebate/Material
BO05
Page 7
Product Requirements Planning
Version 1.1

BO06
Lump Sum Rebate
BO03 (as of release 3.0A)
Rebate condition types are identified using Condition Class “C”. There are two other fields in the
condition type definition specific for rebates. Both of these fields are available as of release 3.0A.

Rebate procedure. This field defines whether the condition type will be dependent or
independent of sales volume. Sales volume independent condition types are used for lump sum
agreements. Lump sum agreements depend on a performance, such as an advertising campaign,
rather than the amount of business a customer does. Standard condition type BO06 is delivered
with indicator “A” to identify it as sales volume independent. The other standard condition types
have a value of “blank” in this field.

Accrual correction. Here, the user defines how the accrual correction program should affect
rebate records with this condition type. The possible entries include:
 “Blank” - Leaving the field blank will indicate that the accrual correction program should
always correct accruals when a discrepancy exists. This value is used with condition types
that are dependent on sales volume and where the user does not plan to make any manual
accrual adjustments.
 “A” - Value “A” indicates that the accrual correction program should never correct the
accruals. This value is used for condition types that are independent of sales volume.
 “B” - Value “B” indicates that the system should correct accruals as long as no manual
accruals have been posted for the rebate condition record. This value is used with condition
types that are dependent on sales volume and where the user plans to make manual accrual
adjustments. This indicator ensures that postings made by the user are not overwritten by the
accrual correction program. Refer to the section 10 “Manual Accruals” for more information
on this option.
3.3.3 Access Sequences
R/3 delivers the following rebate access sequences.
 BO01 Material Rebate / Rebate Group
10
Customer / Material
20
Customer / Rebate Group
 BO02 Material Rebate
10
Customer / Material
 BO03 Customer Rebate
10
Customer
 BO04 Rebate Hierarchy
Access 1 – 7 with levels of the customer hierarchy
 BO05 Rebate Hierarchy / Material
Access 1 – 7 with Material and levels of the customer hierarchy
As mentioned earlier, rebates are additive in nature. As a result, the “exclusion” indicator available in
regular pricing access sequences is not available here. Users are, however, able to make use of the
“Requirement” formula in the access sequence. The requirement formula is used to determine under
which circumstances the system excludes an access to a particular condition type.
Note: When a new access sequence is created for rebates, make sure to label it with category “1” –
Relevant for rebates.
Page 8
Product Requirements Planning
Version 1.1
3.3.4 Pricing Procedure
Rebate condition types are configured in the same pricing procedure as other condition types.
Following is a simple configuration example of a pricing procedure including rebate condition types.
Step
11
400
500
800
901
902
903
904
905
906
Ctyp
PR00
KA00
BO01
BO02
BO03
BO04
BO05
BO06
Description
From Mdt
Price
X
Rebate Basis
Sales Deal
Item Net Value
Group Rebate 400
Mat. Rebate
400
Cust. Rebate
400
Hier. Rebate
400
Hier.Rebate/Mat 400
Lump Sum Reb.
Stat
SubTot. Reqt.
2
7
2
2
24
24
24
24
24
25
AcctKy Accruals
ERL
ERS
ERB
ERB
ERB
ERB
ERB
ERB
ERU
ERU
ERU
ERU
ERU
ERU
The following points are notable when including rebate condition types in a pricing procedure.
 It is not necessary to flag rebate condition types as statistical. They are automatically considered
statistical by definition.
 Rebate condition types that are based on a value rather than a quantity need to have a basis step
assigned in the “From” column. The step that is referenced MUST have one of the “Subtotal” 1-7
assigned to it. Subtotal “7” is delivered specifically for rebates, however other ones may be used.
In the above example, all of the rebate condition types reference step 400. Step 400 has its value
stored in subtotal “7”. The user could likewise reference some of the rebate condition types to
step 800. This would be done if some of the condition types should, for example, be based off of
gross value minus discounts.
 The “Alternative calculation type” and “Alternative condition basis” formulas are not supported
in the pricing procedure for rebate condition types.
 Requirement 24 can be assigned to sales volume dependent rebate condition types in the pricing
procedure to aid in performance. If this requirement is set, the system will only search for rebate
condition records in the billing document. If it is left blank, the system will determine them in the
sales order as well.
 Requirement 25 should always be assigned to sales volume independent rebate condition types in
the pricing procedure. This ensures that lump sum rebates are only valid in rebate settlement
documents.
 Rebate condition types work with two account keys. The first account key is used to derive the
sales deduction expense account for rebate payments made to the customer. The second account
key is used to derive the accrual account and a possible “expected rebate expense” account.
Refer to the next section for more information on account assignment.
3.4 Account Determination for Rebates
Rebate condition types make use of standard account determination. As discussed in the previous
section, rebate condition types are assigned two account keys in the pricing procedure. The standard
system delivers key ERB for the rebate sales deduction and ERU for the rebate accrual. Within a
regular billing document (F2), R/3 only uses the ERU account key. This determines the accrual and
Page 9
Product Requirements Planning
Version 1.1
expense account that the system should post to. Within account determination, the user lists, for
account key ERU, the accrual and expense accounts that should be posted to.
Within a rebate settlement document (B1, B3), R/3 uses both the ERU and ERB account keys. The
ERU is used to derive the accounts where the reversing entries should be made. The ERB account
key is used to derive the rebate sales deduction account. The rebate sales deduction account
maintained with ERB in account determination could be the same one that was maintained with ERU.
R/3 permits them to be different allowing users to differentiate between “expected rebate payments”
and “actual rebate payments”.
3.5 Rebate Agreements
Rebate agreements provide the ability to group several rebate condition records together for a single
rebate recipient. This helps the user to better manage multiple records for the same customer. Within
this area of configuration, the user defines the necessary rebate agreement types as well as the rules
that control which type of rebate condition records can be created within a particular agreement.
3.5.1 Define Agreement Types
R/3 delivers the following rebate agreement types.
 0001
Group Rebate
 0002
Material Rebate
 0003
Customer Rebate
 0004
Hierarchy Rebate
 0005
Independent of Sales Volume
The above agreement types are mainly differentiated by the condition type groups assigned to them.
Condition type groups are explained in the next section. If the user wanted to create a rebate
agreement that was dependent on customer hierarchy, for example, they could use the delivered
agreement type “0004”. To create a lump sum agreement, agreement type “0005” could be used. It is
possible for users to create their own rebate agreement types with their own condition type groups. In
this section of configuration, the user also defines the relevant number ranges.
Below is a description of the fields / sections within the agreement type definition.
 Proposed valid-from / valid-to. The user defines the proposed valid-from and valid-to date
rules for the agreement. Options include “first day of current month”, “end of current year”, etc.
This will be the defaulted dates for the header of the agreement. The condition records within the
agreement may have their own validity periods or have the dates from the header. This is
controlled in the next field.
 Different validity period. Indicator controls whether the condition record dates can vary from
the header dates.
 Payment method. This is the default payment method. This will control how the rebate partial
and final settlements will be paid. This is a default value and can be changed in the agreement for
each partial settlement and final settlement.
 Default status. The status of the agreement can be used, for example, to control whether the
agreement has been released for settlement. The user can default “blank” or set a “released”
status to avoid having to later set this indicator in every agreement.
Page 10
Product Requirements Planning
Version 1.1






Condition type group. This controls which types of condition records can be created in the
agreement. This is a “display only” field in this transaction. The assignment is made in a
separate configuration step.
Verification levels. Within a rebate agreement, it is possible to call up a sales volume report.
The favorite level of detail can be proposed here. It is possible to choose other levels within an
agreement.
Manual Accruals Order Type / Manual Accruals. The user should select the manual accruals
flag and enter the relevant order type if manual accruals are to be used with the agreement type.
Please refer to Section 10 “Manual accruals” section for more information on this feature.
Arrangement calendar. R/3 provides the user with mass copy functionality to support cyclical
agreements. The user specifies here a calendar that defines the cyclical interval. Refer to Section
11 “Mass Copy of Rebate Agreements” for more information.
Manual Payment. To configure partial settlement for the agreement type, the user defines a
payment procedure, partial settlement document type, and whether accrual reversal should take
place. Refer to the section 8 “Partial settlement” for additional information.
Settlement. This section defines the two sales document types used for final settlement as well
as the minimum status the agreement must have to permit final settlement. Refer to the section 9
“Final settlement” for more information.
3.5.2 Condition Type Groups
This area of configuration allows the user to create their own condition type groups if the standard
delivered groups are not sufficient. A condition type group is simply a list of rebate condition types
and condition tables. Users are only able to create condition records within a rebate agreement if the
condition type / table combination is listed here. The user also assigns a condition type group to a
rebate agreement type in this section of configuration.
3.6 Passing Accruals to Profitability Analysis
Similar to other Sales & Distribution condition types, it is possible to transfer to values of rebate
conditions within a sales document to CO-PA (Profitability Analysis). This allows the ability to
recognize rebate accruals in CO-PA as soon as they are passed to Financial Accounting. The accrual
values are then reversed and replaced by the actual rebate payment during the settlement process. To
initiate this process, it is necessary to assign the rebate condition types to the related value
components in the CO-PA Operating Concern. This can be done via the IMG path:
Controlling  Profitability Analysis  Actual Postings  SD Interface  Assign value fields
4. Rebate Index - VBOX
One of the key components of R/3 rebate processing is the rebate index. The rebate index is necessary
in order to support features such as retroactive agreements and the accrual correction program. As
an example, consider a rebate agreement that was created in June, but should be valid for the entire
calendar year. In order to support this scenario, R/3 requires a means to quickly identify all of the
billing documents that were missed from January through May. The rebate index provides R/3 with
this instant link between a rebate condition record and all relevant billing documents, even if the
rebate condition record did not exist when the billing document was created.
Page 11
Product Requirements Planning
Version 1.1
This is accomplished by writing entries to an index whenever a “rebate relevant” billing document is
created. A billing document is “rebate relevant” if the sales organization, billing document type, and
payer are all configured as relevant for rebates. The basis for the index is the rebate access
sequences. Entries are made in the index per item for every level in the rebate access sequences,
regardless of whether a rebate condition record currently exists for that access of not.
It is possible to rebuild the rebate index. This would be necessary if, for example, a user flags a payer
as “relevant for rebates” after the fact and wishes to define rebate agreements that should consider
past sales volume. The rebuild process can be started in configuration using the option
Sales and Distribution  Billing  Rebate processing  Create rebate processing index
For a more detailed look at the rebate index, please refer to Appendix A – “Technical View of Rebate
Index – VBOX”.
5. Rebates Statistics Structure – S060
In order to streamline the rebate settlement process, R/3 makes use of a Logistics Information System
info structure (S060) that stores the cumulative sales volume and accruals per rebate condition record.
The S060 structure is updated automatically from billing documents that contain rebate condition
records. This includes regular invoices, such as F2, as well as rebate settlement documents B1
through B4.
To show how the S060 structure is used, consider the following example. A user creates a rebate
agreement on May 1st that should be valid from June 1st until the end of the calendar year. As billing
documents are processed in the six-month period, the system updates the sales volume and accruals
per rebate agreement condition record in S060. When the year ends and the final settlement program
is run, the system can access S060 directly to determine the total relevant sales volume and accruals
for the period. This is multiplied by the payment rate and the credit memo is generated. This is only
possible if the rebate agreement is not retroactive.
If the agreement is retroactive, the system cannot rely on S060 having all of the relevant sales volume
information. Recall that the rebate index is updated independent of whether a rebate condition record
exists or not. S060 is updated only when a rebate record applies to a billing document. In this
retroactive example, the system makes use of the rebate index VBOX during the settlement process to
determine all of the relevant billing documents and their sales volume.
6. Creating a Rebate Agreement
This section will describe how to create a rebate agreement. This section assumes that the
configuration steps outlined above are complete. To create an agreement, follow menu path:
Logistics  Sales / Distribution  Billing
Rebates  Rebate Agreement  Create
Page 12
Product Requirements Planning
Version 1.1
First, the user selects the relevant rebate agreement type. Next, the user can select the “organizational
data” push button to define the sales area for the agreement. This sales area will be used to validate
the rebate recipient of the agreement and will be used in all rebate credit memos generated by the
system. On the header of the agreement, the system proposes some of the fields from the agreement
type definition. This includes the header validity period, payment method, status and verification
level. The user can change these defaults. The rebate recipient is also entered on the header screen.
The system will check to ensure that the customer is marked “relevant for rebates” in the customer
master.
Note: It is necessary that the customer that is entered as rebate recipient be configured in the system
as a sold-to, ship-to, and payer. This is required for the rebate credit memos that are created during
the life cycle of an agreement.
The user can also enter descriptive text in the header. The description can be used in the rebate match
codes to search on agreements. There is also a field to store an external description. This could be
the customer’s identifier for the agreement.
The next step is to create the rebate condition records. Recall that all rebates earned within the
agreement will be paid to the header rebate recipient. To create condition records, select the push
button labeled “Conditions”. The system will read the condition type group that is assigned to the
rebate agreement type and will list the possible condition type / table combinations. The user can
select a combination with a double-click and the system will take the user to a fast entry screen.
If the condition table contains the field “customer”, the system will propose the rebate recipient from
the header. As mentioned earlier, this can be changed. The way in which a rebate condition record is
created depends on whether the record is dependent on sales volume or not.
6.1 Sales Volume Dependent Rebate Condition Record
When defining a rebate condition record which is dependent on sales volume, the user can enter an
accrual rate and payment rate / scale. For example, a rebate could be offered to customer “Right
Stores” for all purchases of Material 55 during the calendar year. Based on the cumulative sales
volume, “Right Stores” can earn the following rebate.
From
From
From
10,000 Cases
20,000 Cases
30,000 Cases
2 USD per Case
4 USD per Case
6 USD per Case
This is the payment rate scale. If the cumulative sales volume were 25,000 cases for the year, the
customer would earn 4 USD X 25,000 or 100,000 USD. If the customer orders 5,000 cases, then no
rebate would be earned. The payment scale can be defined by selecting a condition record line and
selecting the “Scales” push button.
In addition to the payment rates, the user can define the rate at which accruals should be calculated
during the rebate period. The accrual rate is one value (not a scale). The accrual rate will be applied
to all billing document line items that match the condition record key during the rebate validity
period. The system uses the services rendered date in the billing document to determine whether a
rebate condition record applies or not. For a non-service item, this is equal to the goods issue date.
The accrual rate should be based off of the user’s estimate as to the level of sales the customer will
Page 13
Product Requirements Planning
Version 1.1
reach. In the above example, the user may decide to maintain an accrual rate of 4 USD per case. If
the payment rate were not scaled, then the user would make the accrual rate equal to the payment rate.
6.2 Sales Volume Independent Rebate Condition Record
Sales volume independent rebate conditions are created to represent a lump sum to be paid to the
customer based on a performance rather than a level of sales. A performance could be a front of store
or end-of-aisle display. A rebate condition record is considered sales volume independent based on
the condition type the user selects. The standard delivered condition type BO06 is one example.
When maintaining this type of condition record, the user simply enters the lump sum amount. No
scale is relevant here. In addition, the accrual rate is not open for input since the record has nothing
to do with sales volume. Accruals for lump sum records are posted using the manual accrual feature.
This feature allows the user to create an accrual posting for exactly the lump sum amount on the
desired date. Refer to the Section 10 “Manual Accruals” for more information.
6.3 Rebate Material for Settlement
You may want to create rebates that do not depend on one material, but instead, for example, on:



Customer alone
Customer hierarchy alone
A group of materials such as product hierarchy
In order to do this, it is necessary to maintain a material for settlement in the detail screen of the
condition record. The system uses this material whenever a rebate document (B1 – B4) is created that
refers to the condition record in question. R/3 needs this material number as a “technical vehicle” to
create the credit memo line item.
When creating the material master to be used, it does not matter which material type and material
application type that is used. It is necessary that the sales and accounting views be maintained for the
material. It is advisable that a meaningful number and/or material text be used so that it will be easier
to keep track of the rebates that are paid out.
7. Accrual Correction
During the life cycle of a rebate agreement, it may be necessary to correct the accruals for the
agreement. An accrual correction is necessary in the following two scenarios.


Retroactive agreement. For example, an agreement is created in June that should be valid for the
entire calendar year. Accruals will be missing in financial accounting for the January to May
period.
The accrual rate in a rebate condition record has been changed after the start of the rebate validity
period.
Page 14
Product Requirements Planning
Version 1.1
In order to work with accrual correction, a sales document type must be maintained in configuration
of the rebate agreement type in the field labeled “Correction” in the “Settlement” section. The
standard delivered document type for this use is ‘B2’.
The accrual correction can be initiated per rebate agreement using the configuration feature:
Sales and Distribution  Billing  Rebate processing  Compare rebate basis and correction of
statistical data.
When accessing this option, the user enters a rebate agreement number and selects the “Execute”
push button. The system will then produce a screen comparing:


The sales volume and accruals which “should have been” recorded based on the billing
documents.
Versus
The values that were actually recorded so far in the statistics structure S060.
The system determines the “should be” data using the rebate index VBOX. If any discrepancies exist,
the user should select the “Correct statistics” push button. The system will create a correction
document (B2) for the user. This “B2” document should be carried through to financial accounting.
Running the correction program after this has been done should then show no discrepancy.
8. Partial Settlement
Partial settlement functionality was delivered with R/3 Release 3.0A. Partial settlement is necessary
to support the requirement where the customer would like to receive some of the rebate payment prior
to the close of the defined validity period. This could be the result of a direct request from the
customer, sales rep, or a deduction. R/3 provides a flexible solution for this “payment on demand”
allowing the user to make a payment from a pool of available money. An automated form of partial
settlement is available as of Release 4.0A. This feature is described below.
Prior to working with partial settlement, a number of configuration entries are necessary in the
definition of the rebate agreement type (Section 3.5.1). These entries can be found in the section
labeled “Manual Payment”. Manual payment and partial settlement are used here interchangeably.
The first relevant field is the payment procedure. This field is used to limit the amount of money
that can be paid out in a partial settlement. For example, the user may be limited to the accruals that
have been posted so far for the agreement. Possible entries in this field include:




“Blank”
“A”
“B”
“C”
Manual payment is not allowed
Payment allowed up to the accruals value
Payment allowed up to the value of a pro forma settlement
No limits for manual payment
For option “B”, the user will be limited to the amount that would be paid out if final settlement were
carried out that day.
In addition to the payment procedure, the user must specify a sales document type that the system
should use for partial payments. Sales document type “B3” is delivered in the standard system for
Page 15
Product Requirements Planning
Version 1.1
this purpose. The user also indicates whether accruals in the amount of the partial payment should be
reversed when a partial payment is made. If this field were not checked, then all accruals would be
reversed during final settlement.
A special authorization activity is delivered along with the partial settlement feature. This ensures
that only authorized users carry out this function. The manual payment screen is only accessible in
the rebate agreement if the rebate agreement type allows manual payment and the user has the
authorization. In order to grant a user manual payment authorization, ensure that activity “A2” –
“Pay” is maintained for authorization object V_KONA_VKO - “Agreement: Authorization for Sales
Area / Agreement Type” in their user master profile.
8.1 Partial Settlement for an Individual Rebate Agreement
Manual payment is carried out from within the rebate agreement in change mode.
Logistics  Sales / Distribution  Billing
Rebates  Rebate Agreement  Change
Enter the agreement number and go into the agreement. The payment method for the partial
settlement will be taken from the header of the agreement. From the rebate header screen, the user
accessed manual payment using the menu path:
Payment  Manual Payment
On this screen, the user can enter the necessary payment amounts in the “Amount to be Paid” field
next to each condition record. Partial settlement is possible for lump sum as well as sales volume
dependent records. Partial payments should be entered as a negative value. If customizing limits the
amount that can be paid, the system lists the maximum amount per condition record. An error
message will be displayed if the payment exceeds this limit.
To display payment information about an individual condition record, select the condition record and
press “Payment Data”. The system displays information such as the amount already paid for the
condition record, as well as the amount of accruals posted and reversed. If the user would like to pay
the maximum amount for particular condition records, this can be achieved by selecting the relevant
records and choosing the menu path:
Edit  Pay maximum amount
The system will transfer the value from the “Maximum Amount” field to the “Amount to be Paid”
field for the selected records.
When all partial payment have been entered, the user should save the rebate agreement to initiate the
payment. R/3 will automatically generate a “B3” rebate credit memo document that will include all
of the payments as well as any accruals to be reversed. This document should be transferred through
to financial accounting.
Page 16
Product Requirements Planning
Version 1.1
When working with partial settlement, it is sometimes necessary to have access to payment history to
get an overview of a rebate’s activity. The user can call up the payment history within an agreement
with the menu option:
Rebate payments  Rebate documents
The system will produce a popup window listing the four types of rebate documents that can exist for
a rebate agreement. These include (1) Final settlement, (2) Partial settlement, (3) Correction, and (4)
Manual accruals. To see a history of partial settlements, the user should select that option and select
enter.
8.2 Mass Partial Settlement
Release 4.0A provides a new feature that allows users to carry out partial settlement for many
agreements at once. This function is only supported for rebate agreement types that have a partial
settlement payment procedure equal to:


“A”
“B”
Payment allowed up to the accruals value OR
Payment allowed up to the value of a pro forma settlement
Running the mass partial settlement program will pay out the maximum amount allowed based on the
particular rule that is chosen. For example, if rule “A” were configured, the system would make a
payment equal to the open accruals for the agreement. This option does not allow the user to specify
a fixed amount for the payment. This is only possible with the manual payment option within a
rebate agreement. To initiate mass partial settlement, select the following menu path.
Logistics  Sales / Distribution  Billing
Rebates  Rebate Settlement
The system presents the user with a screen allowing the user to define which rebate agreements
should be considered. The user could, for example, list a number of agreements, or choose all
agreements for a particular rebate recipient. Under the “Actions” section of the screen, the user
should select the option labeled “Carry out partial settlement”. After executing the report, the system
will select the relevant agreements and create the necessary partial settlement credit memo requests
(standard document type B3).
9. Final Settlement
After a rebate agreement period has ended, the user carries out final settlement. The final settlement
program does the following per rebate agreement.


Cumulates the sales volume per rebate condition record in the agreement. If the condition record
was created retroactively, the system uses the rebate index VBOX to determine this value. If the
condition record was not retroactive, the system reads LIS structure S060 to obtain this data.
Using the sales volume, the system reads the payment scale for the condition record to determine
the payment rate.
Page 17
Product Requirements Planning
Version 1.1






The payment amount is determined by multiplying the payment rate by the sales volume. For
lump sum agreements, the payment is equal to the lump sum amount.
The system takes the payment amount and subtracts out any partial settlement payments to
determine the final payment amount.
Open accruals are cumulated and reversed.
A final settlement document (standard document type B1) is created per rebate agreement. This
document contains the payment and accrual reversal entries for all condition records within the
agreement. The rebate recipient is in the header of the document.
In addition to the “B1” final settlement document, the system may also create a “B2” correction
document during final settlement. This is done if the system determines that the rebate LIS
structure (S060) does not have the full volume related to an agreement. This could be possible if
the agreement was created retroactively. The “B2” correction document is then created to update
S060 with the necessary information. This is done so that the LIS structure has the complete
picture of an agreement after final settlement.
Both the “B1” and the “B2” sales documents should be passed through to accounting. This step
is necessary for the “B2” correction document as well since S060 is updated at the point in time
when the sales document is transferred to accounting.
Final settlement can be carried out for an individual rebate agreement from within the rebate
agreement transaction or in mass for several agreements.
9.1 Final Settlement for an Individual Rebate Agreement
To carry out final settlement from within a rebate agreement, select the following menu path.
Logistics  Sales / Distribution  Billing
Rebates  Rebate Agreement  Change
After selecting the relevant rebate agreement number and entering the header of the agreement, the
user has two ways to initiate final settlement. The first way is to select the push button labeled
“Execute Settlement”. This will create the necessary credit memo documents in the background and
issue a message. The user may want to edit the final settlement credit memo generated by the system.
For example, the user may wish to change the final payment amounts or insert text in the header of
the credit memo. The credit memo can be accessed directly in the rebate agreement with the menu
path:
Rebate payments  Credit memo request  Change
After any edits, the user returns to the rebate agreement.
Note: The credit memos will not be saved however, until the user saves the rebate agreement. If the
user exits the agreement without saving, final settlement will be cancelled.
The second way to carry out final settlement within an agreement is to follow the menu path:
Rebate payments  Execute settlement  Using payment screen.
Page 18
Product Requirements Planning
Version 1.1
Users can choose this option when they want to get a quick overview of the final payment amounts all
on one screen with the option to quickly adjust them. With this feature, the system carries out final
settlement and then takes the user to the same screen that is used for partial settlement. In this case
however, when the user saves the rebate agreement, the system creates a final settlement document
(B1) instead of a partial settlement document (B3).
9.2 Mass Final Settlement
R/3 also supports the ability to carry out final settlement for many agreements at once. To access this
feature, follow the menu path:
Logistics  Sales / Distribution  Billing
Rebates  Rebate Settlement
The system presents the user with a screen allowing the user to define which rebate agreements
should be considered. The user could, for example, list a number of agreements, or choose all
agreements for a particular rebate recipient. Under the “Actions” section of the screen, the user
should select the option labeled “Carry out final settlement”. After executing the report, the system
will select the relevant agreements and create the necessary final settlement credit memo requests
(standard document type B1). As mentioned earlier, some “B2” rebate correction documents may be
generated as well.
10. Manual Accruals
Manual accrual functionality was introduced with R/3 Release 3.0A mainly to support lump sum
agreements. Since lump sum agreements do not depend on sales volume, but rather on a particular
performance, standard accrual posting logic can not be used. For example, consider a lump sum
rebate of $5000 that will be paid to customer “Super Store” based on a front-of-store display in the
customer’s store. With traditional accrual logic, accruals would be posted based on the sales orders
the customer placed. In this example, it could be possible that the customer does not place any orders
during the lump sum rebate period. If they did, it would be unlikely that the accruals posted would
add up to $5000. In order to support the ability to post accruals for lump sum agreements, the manual
accrual functionality was developed. This feature allows the user post accruals for the exact amount
and at the correct point in time
Depending on the business scenario, accruals for lump sum agreements may be posted in different
ways. As an example, consider the above lump sum agreement for $5,000. It will be assumed that
the validity period of the agreement is for the month of June with the front-of-store display running
the second and third week of the month. Accruals could be posted in a number of different ways:



Immediately when the rebate agreement is created for the total amount.
Weekly in the amount of $1,250.
Only after the sales representative confirms that the front-of-store display has actually been
done.
Manual accrual functionality can be used for all of these examples.
Page 19
Product Requirements Planning
Version 1.1
A special authorization activity is delivered along with the manual accrual feature. This ensures that
only authorized users carry out this function. The manual accrual screen is only accessible in the
rebate agreement if the rebate agreement type allows manual accruals and the user has the
authorization. In order to grant a user manual payment authorization, ensure that activity “A1” –
“Accrue” is maintained for authorization object V_KONA_VKO - “Agreement: Authorization for
Sales Area / Agreement Type” in their user master profile.
Manual accruals are carried out from within the rebate agreement in change mode.
Logistics  Sales / Distribution  Billing
Rebates  Rebate Agreement  Change
Enter the agreement number and go into the agreement. From the rebate header screen, the user
accesses manual accruals using the menu path:
Go to  Manual Accruals
The user receives a screen that lists all of the rebate agreement condition records. The user is able to
post or reverse accruals per condition record. To build accruals, the user should enter a negative
value. To reverse accruals, the user should enter a positive value. Reversal of accruals need only be
done in special situations since final settlement will automatically reverse any open accruals. It is not
possible to reverse more accruals than actually exist for a condition record. To display accrual
information about an individual condition record, the user can select the condition record and press
the push button labeled “Payment Data”. The user can see the total accruals posted for the condition
record as well as the accruals that have already been reversed.
Once all accrual information has been entered, the user saves the rebate agreement to initiate the
process. The system will automatically create a rebate sales document (standard document type B4)
which will be used to post the accruals. This document should be forwarded through to accounting.
Although manual accrual functionality was developed primarily to support lump sum agreements, it is
also available for sales volume dependent rebates. This feature should only be used for sales volume
dependent records in the following two situations:


If the automatic accrual rate is not maintained for a rebate condition record
To post a deliberate discrepancy to the automatic accrued value. If a deliberate discrepancy is
posted, the user will want to avoid that the accruals correction program resets the accrual amount
back to the original value. This can be realized by setting the “Accrual Correction” flag to “B”
in the configuration of the rebate condition type. This tells the system to ignore rebate condition
records in the accrual correction program if a manual accrual has been posted for the record.
11. Mass Copy of Rebate Agreements
Many companies may run cyclical rebate agreement with their customers. For example, a
manufacturer may have a standard annual rebate program that they run with a particular customer.
Near the end of the year, it would be helpful to have a program that could take existing agreements
and copy them into new agreements for the following year. This is possible using the rebate
agreement extend functionality.
Page 20
Product Requirements Planning
Version 1.1
The first step of this process is to assign a calendar to the rebate agreement type in configuration. The
calendar defines the duration of the cyclical agreement. This could be, for example, one month, six
months, or a year. The calendar is defined in the field labeled “Arrangement calendar”. When a
rebate agreement is created, the system copies the calendar into the agreement. The following
calendars are delivered in the standard system for this purpose.


AJ Yearly agreements from 1st of year to end of year.
AM Monthly agreements from 1st of month to end of month
It is also possible for the user to define additional calendars for this use. New factory calendars can
be maintained in configuration using the menu path:
Global settings  Maintain calendar
When assigning a calendar to a rebate agreement type, the user must also select option “6” for the
“Proposed valid-to” field. This allows the system to determine the end date automatically based on
the assigned calendar. In addition, the user is not able to configure that the dates of the rebate
condition records can vary from the header when a calendar is used.
As mentioned above, the system copies the calendar into an agreement when it is created. It is
possible, however, to disable the feature for an individual agreement. This can be accomplished
within the agreement using menu path:
Extras  Agreement calendar  Remove
To initiate the mass copy process, the user chooses the following from the main menu:
Logistics  Sales / Distribution  Billing
Rebates  Extend
The user will receive a screen allowing them to select, for example, all agreements for a specific
rebate recipient or agreement calendar. Executing the report will initiate the process. The system
will select all of the agreements and copy them to the next period using the defined calendar. The
user receives a protocol listing all of the new agreements.
12. Rebate Agreement Reporting
At any given time, the user may be interested in receiving a list of rebate agreements for a particular
customer or sales area. To access rebate list processing, follow menu path:
Logistics  Sales / Distribution  Billing
Rebates  List
The user receives a selection screen similar to the one offered for rebate settlement and rebate extend
functionality. It would be possible, for example, to retrieve a list of all agreements for rebate
Page 21
Product Requirements Planning
Version 1.1
recipient “Star Markets”. After the selection criteria are entered and the report is executed, the
system will produce the list.
Within the list screen, a number of features are available using the report push buttons.




Display rebate agreement – The user can branch directly to view the entire agreement.
Display rebate recipient – Customer master information can be viewed.
Display verification level – The verification levels give an overview of business volume for
a particular agreement. By selecting different levels, the user can drill down to the business
volume per billing document or get an overview at a customer or condition record level.
Print – This allows the user to print the list.
The above functions are also available from within an individual rebate agreement.
13. Recalculate Subtotals for Rebate Processing
As discussed in section 3.3.4 “Pricing Procedure”, rebate condition types must be assigned a basis
value in the “From” field of the calculation procedure that is assigned to a subtotal value. Subtotals
1- 7 are stored in the sales document. In the following situations, these document values may need to
be recalculated.


An installation that is already “live” would like to configure rebate processing and work with
retroactive agreements. A subtotal (for example “7”) that has not yet been used by that
installation has been defined in the pricing procedure for the rebate basis. In this case, the value
for subtotal “7” would not exist in any of the existing sales documents.
An existing pricing procedure is changed with the effect that the rebate basis is calculated
differently. In this case, the subtotal values stored in the existing sales documents may not be
correct.
To allow for these situations, R/3 provides a program to reset these values. To access this program,
choose the following menu path in configuration.
Sales and Distribution  Billing  Rebate processing  Recalculate subtotals for rebate processing
Note: After this program is run, it is necessary to rebuild the rebate index VBOX. This procedure is
described in section 4. Also, if the user is in Release 4.0A, or a Release prior to Release 3.1I, OSS
Note 88703 must be applied to the system prior to using this program.
Page 22
Product Requirements Planning
Version 1.1
Appendix A: Technical View of Rebate Index - VBOX
As described earlier in this paper, the rebate index is used to support R/3 functionality related to
retroactive agreements and accrual correction. In both cases, the system requires a quick access to all
of the billing documents to which a rebate condition record could / did apply. The rebate index is
written every time a rebate relevant billing document is created and transferred to accounting. A
billing document is relevant for rebates if the sales organization, billing document type, and payer in
the document are configured as rebate relevant.
The rebate index contains the following notable fields:





Rebate condition table – This is the number of the condition table used in the access
sequence. “001” for example would indicate the ‘Customer / Material’ table.
Variable key – This is the combination of key fields for the rebate condition record.
Services rendered date – This is the services rendered date from the billing document. The
services rendered date is the date R/3 uses to find the rebate agreements that should apply to
a billing document item. The services rendered date is equal to the goods issue date for non
service items.
SD document number – This is the billing document number.
SD document item number – This is the billing document item number.
Notice that the index is written independent of a particular condition type or access level.
To show this in an example, assume that a pricing procedure exists which contains the rebate
condition types BO01, BO02, BO03. Collectively, the access sequences for these condition types in
the standard delivered system include the condition tables:



001
002
003
Sales Org / Distr. Channel / Division / Customer / Material
Sales Org / Distr. Channel / Division / Customer / Rebate Group
Sales Org / Distr. Channel / Division / Customer
Customer “Star Markets” places a sales order that leads to the following billing document.
Billing Document:
Sales Area:
Goods Issue Date:
90000815
0001 / 01 / 01
07/20/96
Item 10:
Rice Cereal
20 Cases
Item 20:
Cookies
25 Cases
R/3 would make the following six entries in the VBOX index for this billing document.
Page 23
Product Requirements Planning
Version 1.1
Table
001
002
003
001
002
003
/
/
/
/
/
/
Variable Key
Serv. Rend. Date
0001/01/01/STAR/RICE CEREAL / 07/20/96
0001/01/01/STAR/20
/ 07/20/96
0001/01/01/STAR
/ 07/20/96
0001/01/01/STAR/COOKIES
/ 07/20/96
0001/01/01/STAR/20
/ 07/20/96
0001/01/01/STAR
/ 07/20/96
/
/
/
/
/
/
Billing Doc. Billing Item
90000815
/ 0010
90000815
/ 0010
90000815
/ 0010
90000815
/ 0020
90000815
/ 0020
90000815
/ 0020
If a retroactive rebate agreement is later created for customer “Star markets” and material “Cookies”,
R/3 can read the VBOX index to find the relevant billing document items. R/3 also uses this index
for the accrual correction program. This program also needs a link back to the original billing
documents to compute the accrual difference that needs to be posted.
To read the index, R/3 takes the variable key and table number of the condition record in question and
reads all entries in VBOX which fit this key and have a services rendered date which falls within the
validity period of the condition record. The system then uses the billing document data to access the
billing document file to get the relevant document information.
Page 24
Product Requirements Planning
Version 1.1