on 02-26-2010 8:10 AM
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
Thanks Andy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
can u CIF SNP planned orders to ECC ? I thought u could CIF just the PPDS planned orders.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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
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
User | Count |
---|---|
12 | |
4 | |
3 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.