/SAPAPO/CCR - background

[Former Member]

Hello Folks,

On our SCM environment we got a considerable transactional data volume. For instance: BOP considers around 70.000 orders on the daily routineu2026

Anyway, what I would like to know if there is a way to executed /SAPAPO/CCR in background. I remember that I already read in some posts about a BADI that turns available the execution in background.

Has someone already implemented?

Thanks in advance.

[Former Member · Accepted solution]

Bruno,

??? Nothing special here. Run CCR in the background just like you would any other program.

You will not get this program to automatically perform the actual reconciliations in the background, it only does the comparisons. You must call up the results of the background job, and examine them, and then make appropriate decisions. Not every problem can be managed the same way.

You will need to create one or more variants for the background job in /SAPAPO/CCR transaction. At the bottom in the 'Background Processing' box, select 'Save Results' and give a name to the results. Probably also a good idea to select 'Execute iteration' if the job will be running over an extended period. Once your variants are saved, you use SM36 to create a job. Program name is /SAPAPO/CIF_DELTAREPORT3, use a different variant for each step of your job.

The current project I am working on has a similar amount of orders as you have, and our CCR jobs take about two hours to run. We run them at the slowest time of the day. For us, it is after the end of US west coast business hours, but before the beginning of Asian business hours. Once the jobs have run, you can call up the results in /SAPAPO/CCR, select the 'Load results of comparison' tab.

It makes sense to check these as often as every day. Once you are in control, It should only take a few minutes, unless you are facing some massive problems. It is important to stay right on top of this issue, since bad data piles up quickly in SCM.

You can delete the old lists of comparison results using transaction /sapapo/ccrr. This can also be committed to a job...

For more info about CCR, read SAP online help.

http://help.sap.com/saphelp_scm70/helpdata/EN/58/e0f33822ddb270e10000000a11405a/frameset.htm

If you are running big BOP jobs, don't forget to run SDRQCR21 in ECC and /SAPAPO/SDRQCR21 in APO occasionally as well.

Best Regards,

DB49

[Former Member]

Hi are you looking for CCR to be run in background or CCR results corrections in background?

[former_member205075]

Dear Kondapaneni,

I am after only CCR to be run in background.

The baseline question is exclusively regarding parallel processing and more particularly, parallel processing in R3.

In SM51 (and SM66) I clearly see in APO how processes are split and I'm able to identify parallel processing easily. I would like to understand if the same behavior can be obtained in R3 and therefore what is the ultimate purpose of having parallel process profiles customized for the partner R3 system.

Thanks for your swift reply

Salvador

[Former Member]

Hi ,

We do have parallel profile in ECC but didn't get much performance out of it,  so we divided the selections into multiple and ran in parallel .

Thanks,

Chandra

[former_member205075]

Yes, this is actually what my point was about. Even if I define parallel processing profiles, I never see parallel processes on R3 side... so what is the point of setting that one up?

I was hoping somebody had seen this actually working (even if finally performance-wise there was more or less improvement)

Thanks a lot again Chandra

[former_member205075]

Dear experts,

does anybody have experience setting up parallel processing for CCR?

I did create 2 parallel profiles in customizing (1 for APO and 1 for R3) and I executed the report in background.

Most of the performance time that the report uses is spent on R3 side reading tables like VAPMA and VLPMA, so ideally I would like to see how SM51 in R3 shows parallel processes that reduce the performance time significantly.

Unfortunately I always see one unique process being used and never.

Is there a specific setting I need to maintain to achieve this process parallelization? Is it even possible to split it in R3? and if not, what is the purpose of having Parallel Process profiles for R3?

Thanks for your support

Salvador

[Former Member]

Can you please work with and your Basis and DB team to get trace of the SQL on those tables and pt index based that to improve performance.

Thanks,

[Former Member]

Hubert,

Could you explain more about your technical solution to support it? I'll appreciate.

Thanks in advance.

[hubert_spohn]

Hello Bruno,

there's nothing special on it, I just did some debugging to see how SAP handles all that in online CCR:

- read table /SAPAPO/CIF_DTCL to get the saved results from CCR

- use import to read cluster data and get table with CCR results (error code, object type, etc)

- loop on imported table and trigger corresponding action for those which shall be done automatically

Keys for error codes , send methodes etc can be seen in includes /SAPAPO/CIF_DELTA3_INCFORM and /SAPAPO/CIF_DELTA3_INC0. Used functional modues are:

/SAPAPO/CIF_DELTA3_ORD_DEL for deletion of orders in APO

/SAPAPO/CIF_DELTA3_DEL_STOCK for deletion of stock

/SAPAPO/CIF_DELTA3_REFRESH_STK for re-send of stock to APO

/SAPAPO/CIF_DELTA3_REFRESH for re-send of orders to APO

/SAPAPO/CIF_DELTA3_REFR_APO_R3 for re-send of orders to R/3

BR

Hubert

[Former Member]

DB49,

First of all thanks for your attention. But I think that we are not on the same page...

The question how to manage //CCR is ok. No doubts about it. The point is: I cannot active the reconciliations in background, but only list the inconsistencies.

So, for some objects, such as sales order, I donu2019t want analyze the results before active the reconciliation. I would like to do it in background in a daily routine. But //CCR I cannot do it.

As I said I already read in some posts related //CCR that there is a BADI to executed this perform (reconciliation) in background.

Thanks.

[Former Member]

Bruno,

You will not get any advice from me about automating the reconciliation. I personally believe that this is the worst action a business could possibly take to address this problem.

If your system is configured properly, and your userexits have been properly developed and tested, there will be few or no errors to correct. This includes running BOP against 70K rows. If the quantity of your errors is high, then you must address the root problem(s). CCR shows you the errors, but you still have to determine the problem and create the final solution. When the reconciliation is automated, it still means that your system is inconsistent from the time the error originates until the time the program automagically corrects the inconsistency. In my shop, a large volume of inconsistencies (even temporary ones) would be totally unacceptable.

Best Regards & Good luck,

DB49

[hubert_spohn]

Hello Bruno,

I also agree that you always should try to find the root cause for the deviations if you have to much of them.

However there are situations where an automatic CCR can be useful. We for example use it mainly in our test environment

when there was a system refresh on R/3 side. Therefore I have implemented a report which is reading the saved

results from background CCR and then triggers the corresponding actions (deletion, re-transfer to R/3, re-transfer to APO).

It's som ework to do but at least it works.

Br

Hubert