cancel
Showing results for 
Search instead for 
Did you mean: 

/SAPAPO/SDRQCR21 program is not working correctly if we run the program for range of material and plant wise

Former Member
0 Kudos

Hi APO Experts,

In our project, we have received more sales order inconsistencies which is not clearing by CCR program and it is clearing by  program /SAPAPO/SDRQCR21 with option as Build Reqmts from Doc. Flow, So We have decided to schedule the background job on daily basis for program /SAPAPO/SDRQCR21 with option as Build Reqmts from Doc. Flow, performing the testing in our quality system and observed the below strange behavior. 

When I am running the program /SAPAPO/SDRQCR21 with Range of products and some location range with option as Build Reqmts from Doc. Flow, in Background job. In output it is suggesting to delete one sales order. If I checked that Sales order in ECC, it is for an different location, that is not part of my selection and the order is open. In MD04 the Qty is showing 1 ( as per sales order) but in APO RRP3 view the order qty is showing Zero. I have run the CCR, it is coming in different in content and if I push, the different is not going to APO.

I have tried running the program /SAPAPO/SDRQCR21 with plant which is mentioned in that sales order with option as Build Reqmts from Doc. Flow, in Background job , it is suggesting this sales order under update option correctly.   

Can you please help me understand why it is behaving differently like the location is not part of my selection and why it is suggesting the wrong action. And also whether is it advisable to run the /SAPAPO/SDRQCR21 with option as Build Reqmts from Doc. Flow at plant range and material range in background job.

Thanks & Regards,

Sundaram Radhakrishnan

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Sundaram,

It sounds to me like the sales document records in the OLTP and in APO were created at different times.  This is common in Dev and Qual environments when the systems are commonly created at two different times, and each was a copy of an existing system that contained sales data.  The order number you see in //rrp3 is somewhat irrelevant; system generally uses the guid for many activities.

FYI during Dev and Qual refreshes, if you are copying from a production environment that contains data, it is always best to create the OLTP and SCM images at the same time, and to copy them both to the Dev and Qual systems at the same time.  If you don't do this, you are faced with the additional tasks associated with getting the copied systems back into synch.

If this is Dev or Qual, I suggest that you just completely wipe out all sales orders in APO and rebuild them using the CIF.

If this is a mature production environment, the only time I have ever seen this issue is due to improperly created CIF enhancements.  Speak to your developers to find the root cause, and correct this problem.  Then, wipe out all sales orders and rebuild with CIF.

Best Regards,

DB49

Former Member
0 Kudos

Hi DB49,

Thanks for your response. I have identified that order numbers through /SAPAPO/RRP1. Actually these orders were present for those locations for which I executed the report. Actually these orders were came from production system refresh in APO.

And also can you please help me understand if any other negative impact if we run this report on APO on daily basis.

Thanks & Regards,

Sundaram Radhakrishnan

Former Member
0 Kudos

Sundaram,

???  There is no negative impact to running //SDRQCR21 on a daily basis, although in most mature production implementations I have seen, it is run weekly; or even less often.  If you are getting many errors in a productive system during each daily run, that would be a good sign that something is wrong with your Core Interface design.

On a related subject: during a 'refresh' you will get many odd symptoms within PP/DS if the ECC and the APO system were not refreshed at the same time.  For me, I usually allow myself a few days to 'synch' the two systems before I proceed with any new development or testing.  Depending upon the nature of the 'refresh', it may be desirable to dump all transactional data, and all master data, from the newly refreshed APO system, and repopulate it via the CIF.

Best Regards,

DB49