cancel
Showing results for 
Search instead for 
Did you mean: 

Long runtimes while performing CCR

0 Kudos

Hello All,

After running the delta report job we found some inconsistency for stocks when we try to delete or push to apo ( once performing the iteration ) the entries are not being deleted nor pushed  and is taking long runtimes. We dont see this issue for any other elements except stocks. Please let me know the reasons on why this would be happening and also please let me know if there is any way in which we can rectify this inconsistency for stock b/w ECC and apo .

Thanks

Uday

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Uday,

I had one experience several years back with long CCR runtimes for Stock elements that might apply to you.

For CCR, you have 6 categories of stocks to check.  If any of these stock category elements is not actually contained in any of your integration models, the CCR search can take a long time searching through ALL integration models trying to find a 'hit'.

There are two possible solutions.  Ensure that you ONLY select CCR stock types that are contained in your CFM1 integration models.  If possible, deselect the CCR stock types that have no actual stocks within the integration models (where such stocks do not actually exist in ECC).  If this does not meet your business requirement, then try performing your CCR ONLY on the integration model(s) that contain the stock entries.  Do not leave the CCR field "Model Name" blank.

With respect to the stock inconsistencies, 'how bad is it'?  It is common to have one or two Stock inconsistencies every day if you have hundreds of thousands of stock elements to keep in synch.  The most common reason I see for excessive stock entries in CCR is improperly coded enhancements.

Best Regards,

DB49

0 Kudos

Hello Dogboy,

Thanks for you helpful answer , Considerably we were able to reduce the run times by giving the Model name .

Issue still partially remains with sales order stocks not being completely pushed to APO and they are in huge numbers . When we push them to APO , Hardly 2 to 3 gets pushed every 5 mins . inorder to rectify this i am verifying the below notes.

1060916 - CCR STK: Reconciliation of sales order stock takes long time

721878 - CCR: Resending sales order stock takes a long time

Please let me know your thoughts on this...

Thanks

Uday

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Uday,

I hope its not a queue stuck issue. Your system is tKing long time while processing stock model in CCR.

It might be due to large size of change pointers/ records considered inthe variant.

Try to decrese volumme of records in CCR variants related to stocks. Also you limit it with =stock_sel in t.code box and try to limit size of stock variants. I am not sure of the note. Number, It was suggested i  the SAP note.

Thanks,

Bala.

0 Kudos

Hello Kannan,

Thanks for your valuable inputs , will check the stocks in postprocessing and will let you know the status.

One basic question : Can we activate and generate the integration model for stocks by including the the materials and plant for which there is an inconsistency to rectify the issue at that moment, Will this work.

Please let me know your thoughts!!!!

marianoc
Active Contributor
0 Kudos

Hi Uday Sagar,

Yes, you can. You can:

1- Exclude the materials that are blocking the CIF.. in order to keep your main IModel variant running without issue.

2- Generate a new iModel only for your materials with issue. This way you can even run this new iModel and debug in orther to find what is wrong with those materials.

Kind Regards,

Mariano

Former Member
0 Kudos

Hi Uday,

Try pushing the remaining stock entries via CIF post processing.You can check here.

In your case stocks value will also come in the in house production.Also ensure your Queues are empty you can check it via SCM Queue manager.

Hope it helps.

Regards,

Kannan