Ansicht
Dokumentation

BETR_RDL_REPROCESS - BETR_RDL_REPROCESS

Addresses (Business Address Services)   Vendor Master (General Section)  
This documentation is copyright by SAP AG.

Purpose

When maintaining rebate agreements or the corresponding conditions, if you change data that can affect existing documents, the corresponding condition records are flagged as changed or 'retroactive'. This happens, for example, if you create retroactive agreements or make changes to the following fields in the condition record:

• Validity period

• Accrual amount

• Deletion indicator

Because retroactive conditions mean that revenue data may not be current, these conditions and their agreements are excluded from processing in the rebate due list. Agreements of this kind cannot be settled, for example.

To update revenue, all potential extracts must be reprocessed and the revenue is then adapted accordingly.

When all the extracts in an agreement have been processed successfully, the flag is removed so that the agreement can be settled again.

In a standard system setup, these agreements will not be considered during the next run.

You can tell that an agreement has been flagged as changed, because message BEA_R1115 (agreement contains retroactive conditions) appears when you process the corresponding billing due list.

Integration

Retroactive agreements can cause extracts to be processed several times, possibly causing them to be forwarded to Accounting several times. For this reason, in Customizing for Rebate Integration with Accounting, it is extremely important to assign an accounting document type with internalnumber assignment to the extracts.

Prerequisites

Basically, the billing due list should always be updated when rebate-relevant data is changed. It is important to bear in mind that the system cannot check whether rebate-relevant changes are made outside of agreement maintenance (e.g. changes in BAdI implementations or access sequences). In this case, you should be sure to determine whether an update is required or whether the extract references need to be updated. (See also comments on the 'Changed agreements' parameter).

We also recommend that you perform the update as early as possible (i.e. when a retroactive agreement is created). Otherwise, you may not notice that the update is necessary until the settlement time, therefore delaying payment.

You must also remember that the program can require significant runtimes (depending on data quantity). It is important to find a compromise between performing the update frequently enough, but not too often. You should therefore always be aware that changes to agreements can make it necessary to update the billing due list (especially before settlement).

Features

Depending on its parameters, the program first determines a quantity of extracts. The system then performs a new rebate determination run for these extracts.

• If the program reaches a different result for the determined rebate conditions, the determination result is updated (this then applies to all changes, even if they also apply to other agreements). Conditions for which final settlement has already been performed are not adjusted, however.

• If these changes affect accruals then another accounting document is created, which adjusts the accruals.

• If errors arise when processing errors, the extract cannot be updated (see error log).

• When all selected extracts have been processed correctly, the flag for retroactive conditions is removed.

Selection

Agreement & organizational data

Processing can be restricted here to specific agreements / agreement intervals

Preset data

• Posting date

Here, you can preset the posting date for document corrections. This date is used for forwarding to Financial Accounting (FI), among other things..

Log

• Error log

When this option is selected, the system writes errors arising during processing to an error log.

• Changed records

When this option is selected, all changes are logged and issued as a list at the end of processing. This list is also created during simulation.

Controlling

• Retroactive agreements

This parameter allows you to control whether the program only considers extracts of agreements that contain retroactive conditions. Usually, this parameter shuld be activated, becaue restricting the program to changed agreements improves runtime. This paramter should only be deactivated if rebate-relevant changes are made outside of agreement maintenance. These include:

• Rebate relevance

• Formulae/conditions for rebate condition types

• Condition type

• Coding (e.g. in BAdI implementations)

In each case, if you have deactivated the 'retroactive agreements' paramter, you should try to restrict the agreements to be considered as much as possible, to avoid very long runtimes.

You should also remember that with other changes, the extract references need to be recreated, because these are used to determine the relevant extracts. To redetermine the extract references for affected documents, you must process the extracts again. Changes that require redetermination of the extract references are any changes that affect access to conditions in the pricing procedure, e.g.

• Adding/removing rebate condition types in the pricing procedure

• Access sequences

• Adding/changing/deleting accesses

• Requirements

• Coding changes that affect filling of access fields

• Simulation

When this parameter is activated, the program does not update changes to the extracts and it does not create accounting documents.

Standard Variants

Output

Activities

Example

ABAP Short Reference   BAL Application Log Documentation  
This documentation is copyright by SAP AG.

Length: 7174 Date: 20240531 Time: 113433     sap01-206 ( 115 ms )