To guarantee an error free execution of report RVKRED77, a complete block on sales tables VBAK, LIKP and VBRK is necessary. This requires a shutdown of all sales related activities. Due to limited periods of downtime, running correction report RVKRED77 is not always a possibility. So, what options are available to those with a short to zero time window?
Firstly, the performance of report RVKRED77 will depend largely upon how many open sales orders, deliveries and billing documents there are to process.
To ensure the processing will be completed within a time period, the selection criteria should be reduced and tested accordingly. See note 400311.
The shortest run time will be attained if the report is executed for a single credit account (KNKLI) within a single credit control area KKBER). This is the smallest possible selection entry for this report.
It is also possible to run the report in parallel mode, see OSS notes 363343 and 755395 on this process.
Unfortunately, it is not recommended to use the report without a block. To ensure consistent credit data, you have to run RVKRED77, respectively RVKRED07 with NOBLOCK = ' '. This will avoid that a user updates an SD document during the rebuild, which could result in inconsistent credit values again.
Normally this risk is minor, but you have to decide by yourself, if you want to bear this risk or not. If you have totally incorrect credit values for one credit account, it may be better to run RVKRED07 with NOBLOCK = 'X' and to accept the risk of minor inconsistent values, than to always work with totally incorrect credit values. Additionally, you can check the consistency of the credit values after a rebuild by comparing the results of RVKRED88 against the values in trx FD32.
So, maybe you could do the following:
- Determine credit accounts with incorrect credit values (e.g. you can use CREDIT_VALUE_COMPARE from note 666587).
- Run RVKRED07 with NOBLOCK = 'X' for such credit accounts with big inconsistencies. Run the report for single credit accounts and not for a range of credit accounts. This will lower the runtime and minimize the risk of again inconsistent credit values.
- Afterwards you can check for the processed credit account again for incorrect credit values.
Always ensure that you use only KNKLI, KKBER and NOBLOCK as selection parameters (and PROTB if you want a result list). By using other selection parameters you will really get incorrect credit values!!