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

• Validity period


• Accrual amount


• Deletion indicator

Because retroactive conditions mean that revenue data may not becurrent, these conditions and their agreements are excluded fromprocessing in the rebate due list. Agreements of this kind cannot besettled, for example.
To update revenue, all potential extracts must be reprocessed and therevenue 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 consideredduring the next run.
You can tell that an agreement has been flagged as changed, becausemessage BEA_R1115 (agreement contains retroactive conditions) appearswhen 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. Forthis reason, in Customizing for Rebate Integration with Accounting, itis extremely important to assign an accounting document type withinternal number assignment to the extracts.

Prerequisites
Basically, the billing due list should always be updated whenrebate-relevant data is changed. It is important to bear in mind thatthe system cannot check whether rebate-relevant changes are made outsideof agreement maintenance (e.g. changes in BAdI implementations or accesssequences). In this case, you should be sure to determine whether anupdate 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 noticethat the update is necessary until the settlement time, thereforedelaying payment.
You must also remember that the program can require significant runtimes(depending on data quantity). It is important to find a compromisebetween performing the update frequently enough, but not too often. Youshould therefore always be aware that changes to agreements can make itnecessary to update the billing due list (especially before settlement).

Features
Depending on its parameters, the program first determines a quantity ofextracts. The system then performs a new rebate determination run forthese extracts.


• If the program reaches a different result for the determined rebate
conditions, the determination result is updated (this then applies toall changes, even if they also apply to other agreements). Conditionsfor 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 / agreementintervals
Preset data


• Posting date

Here, you can preset the posting date for document corrections. Thisdate is used for forwarding to Financial Accounting (FI), among otherthings..
Log

• Error log

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

• Changed records

When this option is selected, all changes are logged and issued as alist at the end of processing. This list is also created duringsimulation.
Controlling

• Retroactive agreements

This parameter allows you to control whether the program only considersextracts of agreements that contain retroactive conditions. Usually,this parameter shuld be activated, becaue restricting the program tochanged agreements improves runtime. This paramter should only bedeactivated if rebate-relevant changes are made outside of agreementmaintenance. 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 asmuch as possible, to avoid very long runtimes.
You should also remember that with other changes, the extract referencesneed to be recreated, because these are used to determine the relevantextracts. To redetermine the extract references for affected documents,you must process the extracts again. Changes that requireredetermination of the extract references are any changes that affectaccess 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 tothe extracts and it does not create accounting documents.

Activities