cancel
Showing results for 
Search instead for 
Did you mean: 

CCR Error 156

Former Member
0 Kudos

Hi EXperts,

I create SNP Planned order in APO, it is immediately transfered to R/3 and visible in MD04.

But, APO is not getting updated with Number generated in R/3.

When I run CCR, I get an Error code 156 (Order 000000032523 difference for number: 000000032523(APO) <-> 9000002104).

When I check SMQ1 in R/3 (Outbound Queue), I can see entry there with READY status.

If I activate the LUW, Error goes and planned order number gets updated in APO.

Please help.

Vipul Shah

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

Thanks Andy.

Former Member
0 Kudos

can u CIF SNP planned orders to ECC ? I thought u could CIF just the PPDS planned orders.

Former Member
0 Kudos

Hi Vipul,

Please check the following

1. If you have defined queue type as Inbound in R/3, you have to maintain entry in SMQR in APO

2. Check transaction /SAPAPO/C4 in APO, and see if Recording is set to Default / Do not collect changes (if you are using SNP and not PPDS)

Hope this helps.

regards,

biplab

Former Member
0 Kudos

Hi Biplab,

Thanks for your reply.

Settings are correct.

I have observed that Planned orders are getting processed but it is very slow. It is taking around 15-20 mins to clear one Queue.

I also checked CFC3 setting for planned order

Filter Block size: 256

Block Size for Data Object Selection: 1000

Both are defult/Standard settings.

Any other setting to be checked?

Vipul

Former Member
0 Kudos

Hi Vipul,

Please check if queue type is Outbound in APO, transaction /SAPAPO/C2. It will help reducing the load on R/3 by processing the outbound queues in APO.

regards,

biplab

Former Member
0 Kudos

Not sure if this is the problem but it was for me. Take a look in SMQ1 in your R3 system. If there are lots of entries (depends on system ~ 10,000 or 100,000 to 1,000,000 or even more) then this can slow down transfer to APO even though the destination is not APO. If you do have lots of entries that are old (even recent if you have to) you need to delete them (contact appropriate team if not your own queues or a different system/destination) and once the number is down to an acceptable level things will speed up in the transfer to APO. I have seen the responce speed up from 15-20 minutes to the normal 10 seconds by having queues deleted and this is very dependent on your environment. There are underlying RFC tables that become large and slow down the transfer process to any system. If there are lots of queues then someone should monitor and reconcile why so many queues are building up. NOTE: Communication with other teams is important if the queues are for other systems or data source extracts.

Regards

Andy

Former Member
0 Kudos

Hi Andy,

Thanks for your reply.

I checked R/3 outbound queue.

There are around 360,000 entries with 90% entries are for MCEX -Destination NONE.

Does this MCEX queues are creating any problem?

Any idea what is MCEX queues? Why is it generated with NONE destination?

Thanks again,

Vipul Shah

Former Member
0 Kudos

Yes these MCEX queues can be causing the problem. It is the volume of queues that can slow down qrfc regardless of which queue type or which destination. I do not know the specifics of your system but the volume of queues you have can definitely be impacting the performance of qRFC and CIF. I cannot be sure that this is the source of your problem, or just a contributing factor. I recommend contacting BASIS and asking them to delete queues in order to speed up qRFC, then see if the problem goes away or is minimized. BASIS may want to investigate why queues are not processing and they may contact owners of the queues before deleting anything current.

It doesn't matter what the different queues do, what matters is the volume of unprocessed or errored queues. MCEX could be system updates or business events and the NONE in the destination means it is processed within the same system.

Regards

Andy