Too many outbound queue failed entries in APO prod

[Former Member]

Hi,

We have too many failed outbound entries in APO prod. More than 7000 failed entries for past 3 months. Error messages are mostly the following:

No authorization for maintaining shipments in transport.planning point 61

No authorization for maintaining shipment type ZRPD

Shipment 0010896967 is currently being processed

Deletion flag for service agents OMID: ONTARIO MIDLAND RAILROAD

Read Shipment ........

I am a Basis Admin and I have to find reason how it is failing, causes, and recommend best practise to business. Please help with these.

Thanks,

Kavitha Rajan.

[Former Member · Accepted solution]

Kavitha,

The only two items that might remotely be the responsibility of Basis are the two authorization issues. Even here, the functional consultant who set this up originally should have anticipated authorization requirements, and requested the appropriate objects to be added to the RFC Userid. Actually, the authorization issues should have become evident during integration testing prior to going live. This was tested by the functional experts, and by the business people key users, right?

Between APO and ERP exists an RFC link. Unless your company is using the 'trusted system' model, there is only one Userid that is actually executing all the transactions that are sent by APO to ERP. Go to SM59, find the RFC connection that is used to connect to ERP, find the Userid. This Userid currently has inadequate authorization to manage the shipments in ERP. When troubleshooting such issues, I usually create a dummy Userid which is an exact copy of the RFC Userid, but 'Dialogue', and have a functional expert log on with that Userid in ERP and manually execute all the transactions that APO will be required to send back to ERP. Authorization deficiencies can then be easily discovered, and changed, until the dummy ID works flawlessly. Then, move the additional auth objects to the RFC Userid.

The "....currently being processed" message is seldom an error. It usually just needs to be reprocessed after the conflicting transaction has been cleared. Also possible from time to time is that the system has an orphaned 'lock' on some object that should have been released, but for one reason or another has not. Just log onto ERP and execute SM12. If this happens regularly, then there is probably a custom program that has not been properly designed that is the culprit.

"Deletion Flag...' indicates that APO has sent transactional data to ERP, against a Master data object that has had the deletion flag set. This is a policy and procedure problem, which is usually the responsibility of Business users (and not Basis). Before setting a deletion flag, all transactional data should first be deleted or canceled. Master data problems are by far the biggest culprit in APO queue failures.

Easiest way to solve queue failures that result from poor Master data maintenance practices is to make the business users responsible for monitoring all queue failures, and initiating the search for root cause. Seldom does Basis actually need to intervene.

You also should look at SAP's BP docs. There are jobs that can be run that will reduce some of the problems. Here are a few docs I have found useful....

http://service.sap.com/~sapidb/011000358700000491282008E

http://service.sap.com/~sapidb/011000358700000567062006E

http://service.sap.com/~sapidb/011000358700002213412003E

http://service.sap.com/~sapidb/011000358700000715082008E

http://service.sap.com/~sapidb/011000358700007382642002E

Best Regards,

DB49

[Former Member · Accepted solution]

Hi,

Your advice is very helpful and I will follow the same. I will also make sure the business follows the best practise as mentioned by you. I really appreciate your help. Also, I found many entries with following waiting and error message. Please let me know how to fix these type of entries too. Or what would be the best practise to avoid these errors.

Wait for queue SCEM_0010891195

Central posting block for the service agent TZPR:VENDOR OBSOLETE

Read shipment error

Thanks and Regards,

Kavitha.

Edited by: Kavitha Rajan on Mar 28, 2011 10:55 PM

[Former Member]

Hi,

Your advice is very helpful and I will follow the same. I will also make sure the business follows the best practise as mentioned by you. I really appreciate your help. Also, I found many entries with following waiting and error message. Please let me know how to fix these type of entries too. Or what would be the best practise to avoid these errors.

Wait for queue SCEM_0010891195

Central posting block for the service agent TZPR:VENDOR OBSOLETE

Read shipment error

Thanks and Regards,

Kavitha.

[Former Member]

Kavitha,

'Waiting for....' queue messages mean exactly what they say - they are waiting for another queue to complete.

Many of the Bits of data within SCM that get sent to ERP are dependent upon other bits of data being processed in the proper order. Queue management software keeps track of these dependencies and holds a queue in WAITING status until all of the dependent queues are processed.

In the case you mentioned, you have to find out why SCEM_0010891195 hasn't processed. Once SCEM_0010891195 has processed and updated ERP, then the dependent queues will automatically re-process on their own.

'Central Posting Block' sounds again like a master data error. I have never seen that exact error, but it sounds like someone has placed a block on a vendor or customer in ERP, and this block will not allow the SCM-originated transaction to be completed in ERP.

Again, these are not normally considered to be Basis issues. Connectivity of the systems (a genuine Basis issue) does not seem to be the problem here. Someone from the business side should be responsible for managing all master data errors. The SCM functional IT person responsible for the installed module(s) (PP/DS? SNP? TP/VS? GATP?) normally would understand the relationship between master data and transactional data, and would be pointing the business people in the right direction to fix these logical (not technical) errors.

Best Regards,

DB49

[Former Member]

Thank you.

Kavitha.

Edited by: Kavitha Rajan on Mar 29, 2011 9:45 AM