Consulting/troubleshooting for rebate processing

GENERAL
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.

HANDLING
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.

    1. Consulting

        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.

                       VI. Changes
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.

        c) Accruals

                       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.

        e) Performance

                       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.

                       II. Drill-down
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).

                       III. Handling

                       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,
    USEREXIT_PRICING_PREPARE_TKOMK or
    USEREXIT_PRICING_PREPARE_TKOMP
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.

                      

    2. Restrictions

        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.

        b) Scales

                       Scale type D (to interval scale) is supported as of Release 4.6C.

        c) Partners

                       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).

                       II. Quantities
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.