RVKRED77 Issue

[Former Member]

Dear all,

when we run RVKRED77 report, we meet bellowed issue:

1) we set RVKRED77 as backjob, when someone modify sale order or delivery note or billing , the RVKRED77 will stopped and can't run again, although we set the backjob at night, so how to don't stop RVKRED77 and let RVKRED77 go on.

2) We have over 1000 customer, so it take many time to run the RVKRED77 .

thanks!

[Former Member · Accepted solution]

Please check the below notes.

Note 363343 - Parallel processing of RVKRED77 if the runtime is too long

Note 400311 - RVKRED77: Reorganization credit data

Hope it helps in stream lining the run.

Regards

Sai

[former_member131745]

In reference to note mentioned 400311 which says the following:

o To ensure an error-free run of RVKRED77, it is necessary to

completely block tables VBAK, LIKP and VBRK.As a result, the run

of the report is not possible during the current operation.

The reason why these tables VBAK, LIKP and VBRK are locked during

the report RVKRED77 is because the open credit values are totally

deleted and rebuilt new by processing all open SD documents. So, if

someone changes the document when the report is run, you will get wrong

credit value. This is standard functionality.

Report RVKRED88 is a simulation of RVKRED77 which means that it does

exactly the same but makes no changes on the database. So, you can

run this report before running RVKRED77 just to check if the values

displayed in FD32 are incorrect. RVKRED88 will display the correct

values but will not correct them (or you could use

Z_CREDIT_VALUE_COMPARE from note 666587). To correct them,

you need to run report RVKRED77.

I have also attached the following notes which may help in running the

report more efficiently:

> 363343

> 755395

I hope this helps.

Gerard

[former_member131745]

Additionally; to ensure consistent credit data, you have to run RVKRED77,

respectively RVKRED07 with NOBLOCK = ' '. This shall avoid, that

any user change any SD document during the re-build run and

causes by this 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.

I think if you have totally incorrect credit values to one

credit account, it is better to run RVKRED07 with NOBLOCK = 'X'

and to accept the risk of minor inconsistent values than to

work always with totally incorrect credit values. Additionally you

can check the correctness of the credit values after re-build

by comparing the results of RVKRED88 and the values to see in

FD32 transaction.

So maybe you could do the following in your situation:

- Determine credit accounts with incorrect credit values

(e.g. you can use Z_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.

Please ensure that you use only KNKLI, KKBER and NOBLOCK as

selection parameters (and PROTB if you want result list) !!

By using other selection parameters you will really get

incorrect credit values!!

I hope this help.

Gerard

[reazuddin_md]

Dear Gerard,

Appreciate for your post & really its very useful to all of us to know / learn more about Critical topic like Credit Management.

Once again Thank you very much.

Wish many of SDNer will take advantage of this, when needed.

Regards,

Reazuddin MD