Supply Chain Management Blogs by Members
Learn about SAP SCM software from firsthand experiences of community members. Share your own post and join the conversation about supply chain management.
cancel
Showing results for 
Search instead for 
Did you mean: 
ramachandra_ar
Discoverer
Many times, in support projects, we face issues with stuck queues. If there is any issue with same batch of material pulled from different vendors will get stuck in SMQ2. While working in support project I learned one thing. It is important to resolve the issue but it is even more important to analyze the situation and keep business informed.

This blog post explains the simple process of analysis and resolve queue that was stuck due to the same batch of material pulled from the different vendor.

 

Here’s a scenario how the inbound stuck queue is typically handled in SAP:

issue:

The below SMQ2 queue is stuck due to Deficit of BA Unrestricted-use 2 EA : 10006180 1001 AFS 0000416486


Replicating the issue:

  1. Transaction SMQ2

  2. Input stuck queue number.

  3. Error is raised.


 

Cause:

Please find the analysis in below scenario.

however, we can see that sufficient stock in MMBE for same batch 0000416486 with two vendors as shown in below screenshot.



This issue is due to PGI stuck because the same batch for a material was picked from two different places in the warehouse and they were assigned for different vendor numbers. The root cause for it is in a customer return that was incorrectly received under vendor number 10000123 consignment stock.

 

Solution:

As a last resort we need allow just 1 EA instead of 2 to be taken from the vendor no. 10000054 consignment stock via debug LUW.

hence, here removing all the relevant references related to vendor no. 10000054 from below table parameters of BAPI to process the queue.

Below is the screen shot of BAPI:



In this case we are removing references from below table parameters,

ITEM_DATA

HEADER_DEADLINES

HANDLING_UNIT_ITEM

SUPPLIER_CONS_DATA

ITEM_DATA_SPL



 

Conclusion:

Using the above process, the typical SMQ2 queue failures can be addressed via debug LUW.

This process will help the respective support teams to take the appropriate action once they receive such issue.

Please share if any feedback or thoughts in a comment!

 

Note: All the images are created by me and these are free to use/share.

 

 
1 Comment
Andreas_Mergler
Contributor
Hi Ramachandra,

thank you for highlighting the issue of queues stuck in SMQ2 (on the ERP side in your example) and the importance of getting the underlying problems resolved as soon as possible.

Without knowing the details of your example I would still be careful with changing parameter values using debugging.

In my experience in most cases you get inbound queues because either you have a temporary problem (e.g. a dependent order is enqueued by another process) or you have a problem with master data or a predecessor process having gone wrong.

  • If the former is the case you simply have to wait (or make sure that the dependent order is dequeued) and reprocess the queue.

  • If the latter is the case you should to try to fix the underlying problem. Unless there is a problem with the code (SAP or custom) you should be able to do so. In some cases "queue editing" can be a solution. Have a look at note 2244179 which has a how-to-guide attached to it.


Your example seems to be a predecessor process having gone wrong as you mention a customer returns not being posted to the correct vendor consignment stock. My first attempt would be to "roll back" the customer returns postings, do a stock correction (i.e. a physical inventory) or do a posting change in order to correct the stock situation.

Best regards

Andreas

 
Labels in this area