cancel
Showing results for 
Search instead for 
Did you mean: 

Credit management - Large number of customers-RVKRED77 does not help

Former Member
0 Kudos

Hi,

We have recently discovered that for a particular credit control area we have a large number of customers with discrepancy(around 400). We are not able to use RVKRED77 as this locks VBAK,VBAP etc and it is not possible to get more than 45 minutes without any users processing sales transactions. Due to the large numbers we would need a considerably long "quiet time". We have found that we can use program RVKRED07 to do the re organization with the "No Block" option turned on and this allows us to do the correction without locking VBAK etc. Would this be the SAP recommended way to do this or is any correction to RVKRED77 possible? Will running RVKRED07 with "No block" cause any issues?

Regards,

Hari.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

As far as I know, you should always run RVKRED77 in the background... Try to schedule a job for this and let me know if it works...

The problem with credit master would be mainly due to problems in info structures S066 & S067.. there are few OSS notes on this particular issue if you search them on marketplace...one of them is OSS-666587 which will give you tha exact solution in this situation.

Do let me know..

Hrishi

Former Member
0 Kudos

Thanks, but our issue is that we are not able to use RVKRED77 due to a large number of customers. The locking time required is too long that we cannot stop transactions for such a long time. This is why I was enquiring is using RVKRED07 with "NO BLOCK" option is safe.

Also RVKRED77 calls RVKRED07 in background but with the no lock option turned off.

Former Member
0 Kudos

Hi,

I checked with the program and it seem that if you put "X" in NO BLOCK field then it means it will run in simulation mode {same like RVKRED88} evenif users are working on system..

Hope this will help.

Hrishi

Former Member
0 Kudos

No, I ran in the test enviornment. The option "TRACS" is for simulation, if TRACS is initial and "NO BLOCKS" is not it will re organize the credit data but will not block the tables. We can do this but wanted to confirm that there are no negative impacts.

Former Member
0 Kudos

Hi there,

You need to schedule RVKRED77 to run overnight - this is what all big corporations do around the world.

Former Member
0 Kudos

Unfortunately we do not have a time(apart from a 45 minute on Sunday) when no one is in the system. During week days, US Asia or Europe one region is always logged in and we have Asia warehouses that work 24X7 .

Former Member
0 Kudos

Do you only have 45 minutes on Sunday? Then you have a ig task at hand, because you will need to split the customer database, into slots and run several batches - one every Sunday - until such time your data is synchronised.

Former Member
0 Kudos

But in that case when we calculated it would take us almost 2 and a half years to complete the process.

Then we found that RVKRED07 , the old credit re organization tool can be run with parameter u201CNO BLOCKu201D = X which will not lock VBAK etc while it does the re organization and we can execute this even when users are in the system.It also allows us to run by sales orgs, so that I can limit the impacts to some extent.( The draw back to running without blocking the tables is that an order, delivery or billing doc could be created while the program is running and mess up the value). I am just trying to find out if there is any other issues that may come up by using RVKRED07.

Former Member
0 Kudos

The reason why no one would suggest the use of RVKRED07 is because, yes, you may select it with "NO BLOCK" option, however if there are sales transactions being carried out while the reorg program is running, you will end up with serious reorg issues.

I strongly suggest you get system down time to do this. Or if this customer is so big, surely you can ask SAP themselves for assistance with this solution.

BUT PLEASE REMEMBER MY SUGGESTION ABOUT RVKRED07 - dangerous.