This note is intended to point out the most frequent problems associated with rebate processing. On the one hand, you can use the note to gain a better understanding of rebate processing, on the other hand, it is intended to help you analyze any errors that may occur and provide possible solutions to these problems.
Some differences between the 'old' and 'new' rebate procedure are highlighted below. For more information about the 'new' procedure, and to enable a better understanding of this procedure, see Note 105681.
If you experience any problems with rebate processing, you can first try to solve the problems using this note.
If you have more general questions, you should read over the first section on the relevant functional area. The problem may be that your particular requirement is not covered in the standard system. In this case, consider the second section, which deals with functional restrictions.
You can also use Note 76444 to determine whether the problem may be attributed to a known program error.
The note is intended to provide additional information for customers requiring consulting on this topic as well as provide solutions to certain program errors.
a) Customizing/master data
I. Relevance to rebate
The following settings are preconditions for including a billing document in a rebate arrangement.
- Sales organization (TA OVB1)
- Billing type (TA VOFA)
- Payer (customer master record, billing view)
II. Pricing procedure
The requirements for the pricing procedure (TA V/08) depend on which calculation type and scale base type the conditions have. Special consideration is required for percentage calculation types as well as value scales. For all other conditions, it is sufficient to include the condition type in the pricing procedure.
The case of conditions with a percentage calculation type (A, H, or I) or with value scales (scale base type B) is outlined below. The following special settings should be made in the procedure (see the example):
1. The rebate condition type must refer to a subtotal, with the step number (STUNB) specified.
2. The reference subtotal must be stored in a subtotal field in the VBRP table. To ensure this, one of the alternatives '1', ... '7', must be entered in the V_T683S-KZWIW field.
3. Note that multiple use of the same subtotal field causes a cumulation in the corresponding field of the VBRP table. Try to avoid this.
Example: KART From ... Subtotal ...
800 Subtotal X 7
901 0 ZB01 Rebate 1 800 ...
902 0 ZB02 Rebate 2 800 ...
III. Condition type
Customizing of the condition type itself is restricted for rebate conditions. Some fields are not available. For the other fields, consider the following: Set ' ' for the condition type. Other condition types may trigger special logics in pricing (for example, 'O' variant condition, 'Q' - Costs, and so on). Since no pricing is carried out when creating or evaluating the rebate index, any special logic for arrangements set retroactively is lost. For this reason, unexpected and inconsistent results may occur, if such special logic is expected.
For exclusion and scales see below.
IV. Access sequence
The access sequences for rebate conditions (Transaction V/07) differ only slightly from the access sequences for other conditions.
You only need to remember that the function is restricted with regard to -> Requirements and the ->Exclusive indicator within the 'old' rebate procedure.
V. Condition table
For rebate conditions, separate condition tables are used, that is, not those used for pricing conditions (usage A) (for example, A004). The condition tables for rebate (usage E, for example, KOTE001) differ from the pricing condition tables in that they also contain the arrangement number in the key. As a result, at the same point in time, several condition records (in different arrangements) can exist for the same condition type and variable key.
If you change Customizing settings for existing rebate arrangements, this can cause serious problems. Often these problems cannot be traced and are extremely difficult to correct. You should refrain from making these types of changes (for example ->Relevance for rebate, -> Pricing procedure, ->Access sequence and so on). If you nevertheless make changes, then a ->Rebate index recompilation is usually required. In the 'new' procedure, the arrangements also need to be updated using the SDBONT06 report (see Note 105681).
If the subtotal field used in the pricing procedure is changed, then you can use the RV15B003 report to redetermine the subtotals in the affected documents (see also Note 88703).
b) Retroactive rebate arrangements
You can create a rebate arrangement with a validity period start that starts in the past. The system then takes into account all billing documents relevant for rebate that were created between the start date of the validity period and the final date you have specified in the rebate arrangement.
When creating retroactive rebate arrangements, three important points must be taken into account:
I. Within the 'old' procedure, ->Performance may be much worse than that for rebate arrangements that are not retroactive. In principle, you are advised not to create retroactive arrangements where they can be avoided.
II. If ->Customizing (relevance to rebate, access sequences, and so on) for rebate processing is incorrect, it may be necessary to run a ->Bonus index recompilation.
III. For the 'new' procedure, the arrangement has to be updated using the SDBONT06 report (Transaction VBOF). In general, we recommend you to make this update as soon as possible after creating the arrangement.
Rebate accruals enable Accounting to retain an overview of outstanding rebate payments to customers.
Often the accruals amount is set so that it corresponds to the later payment amount (estimation), however, it is not binding for the actual payment in any respect. Anyhow, for retroactive 'old' arrangements, no accruals are carried out for billing documents created in the past. (->Rebate correction).
In Accounting, accruals can be posted to two different G/L accounts. These accounts are determined in accordance with the two posting keys ERS (sales deduction) and ERU (accruals).
d) Material for rebate settlement
Since, in rebate credit memos, items are created according to the condition records, a material for settlement is required for each condition record. Since a rebate may not refer to a material (for example, material pricing group, customer group, customer hierarchy and so on), it is necessary to maintain the material for settlement. If a material is already used in the condition record, this is used automatically. In the material master record, the data for Sales and Distribution and Accounting must be maintained.
When creating a credit memo for the settlement of this rebate arrangement, important material master data (for example, on account assignment, tax determination) is determined in accordance with the material for settlement.
Problems regarding performance can occur for different aspects of rebate processing. Problems may always occur if the system has to read information from individual billing documents. This can apply for the following functions:
- Determination of the sales volume/payment amount ('old' procedure)
- Drill-down ('old' procedure)
- Billing update (SDBONT06, 'new' procedure)
- Rebate index recompilation
The runtime for these functions depends essentially on the number of billing documents the system must read. Further relevant values include the number of conditions in the pricing procedure as well as the number of accesses in the corresponding access sequences. Under certain circumstances, complex requirements or formulas may also cause problems.
The different problems and possible options to improve the performance of the individual functions are explained below.
I. Determination of the sales volume/payment amount
The way in which the system determines a sales volume or payment amount depends essentially on whether the rebate arrangement is retroactive or not.
Whereas the calculation method for non-retroactive rebate arrangements has no critical effect on performances (use of statistics S060), the calculation for ->retroactive rebate arrangements can take a very long time depending on the volume of documents to be read. In the most unfavorable cases, this may result in a TIMEOUT.
The calculation of aforementioned values is carried out in the following cases:
- Display sales volume
- Create settlement
- Manual partial payment
The RV15C001 report (or TA VB(7) can help you deal with TIMEOUT errors. With this report, sales volume verifications are created and rebate arrangements are fully settled. This report does not perform the calculations any faster, but its advantage is that it can be executed in the background (menu Program -> Execute in background), which prevents a termination due to TIMEOUTs.
In this report, you can still select several arrangements and therefore perform an action for more than one arrangement.
Problems can also occur if manual partial payments are allowed in Customizing of the arrangement type (TA VB(2). In this case, the system determines the sales volume accumulated so far as soon as you access the arrangement (TA VBO2). In turn, this can cause a TIMEOUT. You should check whether manual partial payments are used at all.
TIP 1: If a rebate is to be granted for a certain period, but the extent of the rebate is not defined at the validity start date, then it may be advisable to create the rebate at the start of the period anyway, that is rather than creating the rebate retroactively, and entering any condition rate as a temporary rate. When a final condition rate has been decided on, you can easily adjust the initially entered rate, that is the temporary rate at the appropriate time. The sales volume remains unaffected by this change.
TIP 2: You should also remember that a long validity period can further aggravate any performance problems.
If you expect that the system will need to read a large number of billing documents for the arrangement, perform appropriate tests with a realistic document volume, before creating the required rebate in the production system. If the number of documents proves too high, shorten the validity period accordingly.
When you call up the drill-down for a rebate arrangement, then irrespective of the display level and irrespective of whether you want the drill-down for retroactive arrangements, the system always reads the information from the relevant billing documents. If the system has to read a large number of documents, a TIMEOUT may occur. (This applies to the 'old' procedure only. In the 'new' procedure, the drill-down is read from the S136 statistics table.)
The RV15C001 report (or TA VB(7) can help you with this problem.
III. Arrangement update (applies to the 'new' procedure only)
An update of the arrangement within the new rebate procedure is always required, if the arrangement was made retroactively. It is also required, for example, when validity periods were changed subsequently. All billing documents that might be relevant for this arrangement are read, and a new pricing for rebate conditions is carried out (see also Note 456458). The runtime of the report mainly depends on the number of billing documents to be updated. For this reason, this update should be carried out as soon as possible after creating the arrangement since then the number of billing documents concerned is at its lowest.
IV. Rebate index recompilation
First you should ask yourself whether recompilation of the rebate index is really necessary. In this connection, please refer to the point on ->Rebate index recompilation.
The runtime required for the recompilation depends essentially on the total number of billing documents contained in the system. In addition, certain Customizing settings influence the size of the rebate index and consequently also the runtime for the recompilation. These settings include:
- Relevance to rebate (sales organization, billing type, payer)
- Number of potential accesses to the rebate condition tables in the access sequences
Furthermore, a database index may be missing. For more information, see Note 51822. For Release 2.2, Note 37267 provides a faster variant for index recompilation.
For questions regarding scheduling a background job, refer to the point ->Rebate index recompilation.
f) Rebate index recompilation
I. General information
Basically, the system uses the rebate index (table VBOX) to determine any document items that may be relevant for a rebate condition. The index is updated when a billing document is released to Accounting. Here, it does not matter whether a billing document contains a rebate condition or not. The possibility that at some point a rebate condition may exist, which might be relevant for this document item, is the determining factor. This behavior is necessary because the system supports retroactive rebate arrangements. Moreover, the rebate index is required for the drill-down.
II. When should a rebate index be recompiled?
You should only recompile the rebate index if at least one of the following settings has changed:
- Relevance to rebate of a sales organization
- Relevance to rebate of a document type
- Relevance to rebate of a payer
- Access sequences for rebate conditions
Of course, recompilation is only necessary if the system already contains billing documents affected by these changes.
Recompilation may also be necessary if you implement program corrections (corrections in a note) or changes to customer modifications (user exits, user-defined fields, requirements).
You can use the RV15B001 report (or Transaction OVB3) to recompile the rebate index.
If you want to run the report in a productive system, schedule it at a time with a lower system load (for example, at night). Since recompilation can take a very long time, the report is configured so that it suspends processing after a predefined maximum time and automatically reschedules processing for the following day.
g) Rebate correction B2/comparison of statistics - rebate documents
For basic information on the rebate correction document B2, see Note 35325.
B2 rebate correction documents can be created in two ways: manually (using the RV15B002 report or TA VOB3) or automatically during final settlement.
The two types only differ with respect to one point. With manual creation, the system not only corrects the sales volume in the statistics but it may also set up accruals.
h) Hierarchy rebate
In Sales and Distribution, it is possible to define a rebate so that payment is made on the basis of sales volumes of customer hierarchies.
Maintain the customer hierarchy nodes (maintenance using TA VDH1) as customers. These must then be indicated as being relevant for rebate.
IMPORTANT: If you need to make changes concerning relevance to rebate in the customer master, after you complete the changes, you must branch to maintenance of the customer hierarchy to update it and include this change.
In accordance with the Customizing settings for partner determination, the system determines the hierarchy nodes at a higher level than the customer in the corresponding documents. These are then available for pricing or for rebate processing (fields: HIEBOxx).
IMPORTANT: Since no new partner determination is subequently possible for documents, these cannot be updated. That is, changes to the customer hierarchy no longer affect partners in existing documents and therefore no longer affect existing sales volumes within a rebate arrangement.
i) User-defined fields
Depending on the business process involved, it may be necessary to define further key fields (characteristics). Here, in addition to the settings required for standard fields, make the following adjustments:
- Extend structures KOMG and optionally KOMP or KOMK (ideally only in either the KOMPAZ or KOMKAZ structure, since these are used as Includes in KOMG and KOMK or KOMP).
- Extend the field catalog for rebate
- Fill the fields with user exit RV60AFZZ,
The most suitable data for filling the new fields is the data from the the structures XVBRK and XVBRP. The structures VBRK, VBRP, VBAK and VBAP are not suitable. These are not filled at all relevant times, which may lead to the occurrence of errors that are very difficult to to trace. Refrain from using these structures (see also Note 130417).
j) Date of services rendered
To determine whether a document item is relevant for a rebate condition, the system always uses the date of services rendered (VBRP-FBUDA field). It is NOT possible to use another date.
a) Condition exclusion/exclusive indicator/requirements
Owing to the special handling of rebate conditions (for example, the option to include documents retroactively), the pricing function is not yet fully supported. In particular, this affects all possibilities for the mutual exclusion of conditions (with exclusion groups or requirements). For information on the exclusive indicator, see Note 24368. This restriction does not apply to the 'new' procedure (see also Note 105681).
For information on conditions, see Note 156230. For rebate processing, only the KOMP and KOMK fields may be used in conditions. KOMT1 fields, for example, are not available.
Also note that standard condition 2 (pricing relevance - PRSFD) is always checked using the VBOX rebate index in rebate processing, regardless of whether it is stored in the pricing procedure.
Scale type D (to interval scale) is supported as of Release 4.6C.
When maintaining a rebate recipient, note the following:
In all rebate credit memos created for a rebate arrangement, the rebate recipient is used as the sold-to party, as the payer and also as the ship-to party. The system behavior in respect of these three partner functions is predefined and cannot be influenced. For example, the the system does not determine an alternative payer from the customer master record of the sold-to party.
Take this behavior into account when you maintain the rebate recipient.
d) Foreign currencies
In releases prior to Release 4.0, basic problems occur if the arrangement currency differs from the local currency. Since sales volume is initially cumulated in the local currency and it is paid in the arrangement currency at settlement, differences may be due to exchange rate fluctuations. To avoid the problem, refer to Note 45832.
e) Taxes on the payment
Basically, when determining taxes in the payment document, the ->Material for settlement is the relevant factor. This generalization may cause problems, for example, if the sales volume for a condition record is calculated from materials with different tax rates.
You can avoid the problem, for example, by creating a separate condition record for the materials with a different tax rates (for example, with material pricing groups).
f) Credit/debit memos
If you want to include credit and debit memos/returns in rebate arrangements, please consider the following:
I. Copy control
If credit or debit memos/returns are created with reference to a source document, you should consider that the ->Date of services rendered is relevant for granting the rebate. If you copy this without making any changes, you run the risk that the relevant arrangement (in which the source document was probably included) has already been settled. In general, you are advised to reset the date of services rendered, at least you should check the date when you enter a document. In addition, rebate conditions should be redetermined when you create a document with reference (that is, at least pricing type G).
Another problem may occur in connection with credit or debit memos if these documents do not reflect any actual goods movements, but still have quantities not equal to 0 (for example, owing to subsequent price changes).
For rebate conditions with relative calculation types or scale bases (C, D, E, F), the unwanted effect may result in the document influencing the base. This problem is compounded by the fact that for rebate conditions with a percentage calculation type (A, H, I) or scale base types, the document should influence the base.
In this situation, check whether a sales volume quantity not equal to 0 is really required. If the answer to this question is yes, you may find adding a requirement to the pricing procedure can help avoid the problem. This requirement should stipulate, for example, that the system should not access a rebate condition for certain document types (or item categories) (for example, for a condition with a relative calculation type).
g) Sales variants
The use of a variant condition (VARCOND) is not yet supported.
Consulting/troubleshooting for rebate processing
SAP Updates Failures Impact the Efforts of CompaniesUpgrading SAP processes is more often than not considered as a costly, time consuming and inefficient function for businesses, thereby leading to a scarcity in SAP updates. Over 33 percent of companies using the popular Oracle E-Business Suite have failed to upgrade their modules. 40...
SAP Energises Extreme Sailing SeriesMost of us can only relate to Sailing as an adventurous activity which leads to massive adrenalin rush however "Sailing" also is related to the various activities which are specifically meant for cloud computing and data analytics. Sailing is just not restricted to the high yachts which can be...
Top 10 Rising SAP Modules for Year 2016By the turn of the year, many things change. Numbers go upward and down letting in new trends to play the game of the day. SAP (Systems, Applications, Products in Data Processing) as an industry is no different in this regard. Google trends show a total revamp in the modules that is going to be...
SAP Does It Again, Acquires AribaSAP a well- known German company did it once again, for delivering the very best to all its partners and customers the company acquired Ariba in the year 2012! The company has acquired brands like Fieldglass, SuccessFactors, Hybris and Ariba. SAP aimed at rebranding all four of these brands. Going...
Difference between SAP S/4HANA and SAP Suite on HANASAP S/4HANA Vs. SAP Suite on HANABetween SAP Suite on HANA and SAP S/4HANA, some level of confusion still exist which I got know after speaking with a large number of people. For those who are wrestling with the differences between the two products let me provide some clarity. Before making any...
- How to do rebate processing
Rebates Processs in SAP is divided into three components 1) Configuring Rebates 2) Setting Up Rebates 3) Managing rebate agreeeements and payments Pre-requsiistes- Check the following: ...
- Difference between Rebate and Discount
Rebate vs DiscounttRebate is a partial repayment, whereas a refund is a repayment of the total purchase pricetDiscount is reduction in PricetDiscount means ...it happens on a single...
- What is the New rebate procedure.
When you use rebate processing, only part of the pricing functions are available. This affects for example: Condition exclusion (via groups or exclusion indicator) Exclusive...
- How to Create and Process Rebate Agreement?
Following explains how to create a rebate agreement, test it using a sales order and billing it. Then settling it partially or fully using a rebate credit memo. Please use the basic procedure and...
- Rebate Process with Ref. to SO
If I need to make a rebate for a customer what is the process involved. I am providing some info on rebates which I know. Rebate agreemnts is based on agreement types.Conditon records which...
- Rebate Agreement
1. Which agreement type I should consider, is this custmer rebate(0003), material rebate(0002) or Rebate on the basis of sales volume(0005), because here client is not offering rebate on Sales...
- SD Questions About Pricing Condition
What is the difference of VK11 and VK31 (condition records)? My condition type is PR00 and Access sequence is PR02. And in this access sequence table 304 is available. Now when I was entering...
- SAP SD Tree Menu
Sap tree_SD SAP standard menu | |-- Office |-- Logistics | | | |-- Materials management | |-- Sales and distribution | | | | | |-- Master data | | | | | | | |-- Business...
- SAP SD Intercompany Sales Processing & Billing
In SAP sales & distribution module, an intercompany sales occurs when the selling organization belongs to a different company code than the delivering plant. The transaction path for accessing...
- SAP SD TCodes For India
Transaction Action: J1I2 - Prepare a sales tax register J1I3 - Create outgoing excise invoices in batches J1I5 - Update the RG 1 and Part I registers J1IEX - Incoming Excise Invoices...
- Steps for SD Variant Configuration
Steps for SD Variant Configuration in Detail. SAP SD Variant configuration overview using motorbike product as an e.g. The procedure is as follows: tCreate a Material - KMAT type with Item...
- SAP SD Sales & Distribution Concepts - The Delivery Process / Delivery Creation Process VL01 VL04
In SAP SD, one can create delivery either individually from a sales document or individually via the menu path or via the delivery due list. I am discussing each of these different types of...
- Important Tips for Interview for SAP SD
Let me share some important tips for interview for SAP SD: 1. Please be through with the projects you have mentioned in your resume. 2. Remember all the versions you have worked upon. 3. If...
- SAP SD Credit Management
All business have their own credit management needs, SAP allows you to specify your own automatic credit checks based on a variety of criteria. You can also specify at which critical points in the...
- Error VK304 occurs, while creating rebate credit memo.
When you create a rebate credit memo, an error occurs: VK304 "Error creating rebate credit memos (see next warning message)" Afterwards one of the following error messages can occur: ...
- Job Profile & Salary Package for SD Consultant
A SAP SD Consultant is responsible for helping in development of requirements and specifications, in implementation of prodcut to delievery chain process.SD consultant is responsible for the sales...
- What is the difference between sales process and business process?
A normal scenario of identifying the customer and getting the money for what we sold to him or gave him service is called Business Process.It includes a lot of activities like Sales Order, Delivery...
- SAP SD Course & Certification Fee
This course brings the clear picture of the building blocks of sales and distribution departemnt. The topics covered in this course are: Overview of SAP navigation, ERP system, Sales and...
- How to Improve System performance in SD while processing large number of documents
When you process large SD documents or a large number of documents in a collective processing, the processing time increases disproportionately faster than the number of items to be...
- Third Party Process SAP SD
- Not Getting Condition Base Value and Scale Value when Updated in Rebate Documents
- Not Getting Condition Base Value and Scale Value Updated in Rebate Documents
- Replicate Rebate Agreements from ECC to CRM?
- Text Determination SAP-SD
- Transaction VB(D the Rebate Settlement Status= Open, nothing is displayed....)
- Comprehensive SAP SD User Manual
- Patch Level Up-gradation from LEVEL 80 to 90 for IT Rebate 2000
- Often Asked Interview Questions for SAP SD (Sales and Distribution).
- How to Calculation Rebates
- white Paper - Rebate implementation Challenges
- Effective SAP SD PDF Book Free Download
- SAP SD Configuration Guide PDF
- Lockbox process Configuration
- SAP CRM SERVICE PROCESS
- Dunning Configuration & Processing Manuual
- Branching to List Processing
- Internal Tables Processing
- Business Processes Operational Solutions for SAP Implementation
- SAP SD Credit Management Free PDF
SAP SD Consultant
Exp :5 - 15 years | City : Noida
Urgent requirement |SAP SD Techno functional
Exp :5 - 11 years | City : Bangalore
SAP FICO Consultant | 4 - 6 yrs | Kolkata | Softlogique IT S
Exp :4 - 6 years | City : Kolkata
SAP SD Consultant | 4 - 8 Years | Noida, Delhi/NCR | Shell I
Exp :4 - 8 years | City : Delhi
SAP SD | 4 - 8 Years | Ahmedabad | Gi Group
Exp :4 - 8 years | City : Ahmedabad
SAP FICO lead Professionals | 7 - 11 Years | Kolkata | Genpa
Exp :7 - 11 years | City : Kolkata
SAP FICO / SAP HCM/ SAP SD | 5 - 7 Years | Chennai | Hinduja
Exp :5 - 7 years | City : Chennai
SAP Functional and Technical Analyst | 2 - 3 yrs | Bangalore
Exp :2 - 3 years | City : Bangalore
Sr. SAP ABAP FI Developer | 8 - 13 yrs | Hyderabad / Secunde
Exp :8 - 13 years | City : Hyderabad
SAP SD Testing Experts | 5 - 10 Years | Chennai | Ciber Inc,
Exp :5 - 10 years | City : Chennai