Hey Kanishka,

which version of IFS are we talking about? when you mention ASC to you mean customers using the ASC VAP or just Automotive customers in general?

The situation you are describing should not happen as shipment inventory is used after you pick a line from a shipment. Once you deliver that shipment the stock will be gone. Invoiced/Closed lines with reservations should also never happen. I would say the “ in Most Cases, we don’t know how they end up having such unusable Stuck Inventory Reservation.” is what you need to investigate by recreating their processes. 

You cannot remove the reservations from a closed line (which should be impossible to exist) and make the stock available either. That stock has been picked so i doubt it should be shown as available.

If the answer to the question at the beginning is that customers are using the ASC module/VAP then the issue is likely related to this. Try to recreate it and report the issue to IFS. I haven’t encountered this in any ASC projects yet though. Any chance the customer(s) have customizations in that area?

Regards,

Johannes

My Customer is using IFSAPPS9 and they have ASC module/VAP.

I too agree with you on the fact this should not happen, and if that happens, we should investigate how and why? But, sometimes we can’t trace down to the bottom of the issue without knowing what exact steps Customer users are following until they encounter this issue. This is because, if the Customer/Case caller is unsure of what exact steps their users followed around a given error instance, and whatever the information available in the Case/we find through our Support investigation isn’t good enough to identify the root cause (thus identify a way to reproduce the issue).

If that is found to be the case, we’ll have to conclude it a genuine one-off type issue for which reason could not be identified just by analyzing Past data. In such a situation, a Data fix would be the only viable solution I should say. Again, I know this should not happen in an ideal world, but these issues tend to happen over and over again throughout all IFS versions (No matter whether it is just CORE, or there are VAPs, Customizations, etc..), and support persons would know how cumbersome troubleshooting these data errors are. Sametime, they cause a lot of problems for our customers, and that’s why I’m checking whether someone has seen this before, and managed to fix this specific issue through a Data repair.

We are also facing the same issue. Have you figured out which steps to take to data repair it?

I’m still looking for the best solution/answer, but I would like to suggest below action plan to get over this if that is applicable to your scenario,

=============================

Situation:

‘Q1’ No of units of Part ‘P1’ is stuck in Site ‘S1’ Shipment Location ‘L1’

=============================

Steps to FOllow:

1. Create a DUMMY Customer Order in Site S1. Use an Order Type that is set-up to use ‘Shipment Inventory’.
2. Add a Line. User Part P1. Quantity say Q2
3. Process this Customer Order till ‘Report Picking’ via Shipment Inventory. Use Shipment Location L1
4. This will Increase the Quantity in the Shipment Location from ‘Q1’ to ‘Q1+Q2’
5. Now you need to increase the Customer Order Sales Quantity, Reserved Quantity, Picked Quantity Values to ‘Q1+Q2’ through a Data fix (In customer_order_line_tab, customer_order_reservation_tab, etc..)
6. Then It should allow you to return the Full Quantity (Q1+Q2 Units) back to Picking Location through ‘Handle Parts in Shipment Inventory’ functionality
7. Cancel the DUMMY Customer Order when done

This method includes a data fix in the middle of a Functional Solution, so we need to work closely with Customer Users and make sure that the Data fix is applied at the correct time. That’s why I’m looking for a better solution (Probably a Direct data fix). Frankly speaking, I haven’t tried this method as yet, but it should work.

If the customer is in App8 or App9, you can return parts which are stuck in shipment inventory to picking location by calling inventory_part_in_stock_api.move_part_shipment  method in YVVDA_PICK_SHIPMENT_API via script/db

For that you need to know  values for below values and set qty_reserved_ =0

catch_quantity_, from_contract_, part_no_

configuration_id_, from_location_no_  ,lot_batch_no_  

serial_no_, eng_chg_level_       ,        waiv_dev_rej_no_

activity_seq_     ,expiration_date_                      to_contract_     

to_location_no_, qty_returned_   qty_reserved_ 

 This is how we sorted such issues in the past.

Thanks for the reply.

Up to now, I had this problem with Apps8 or Apps9 customers only.

So, I tried this with sample Test data in a Customer Local DEV instance and system moved the Stock out of Shipment Location upon executing above method call. It also created PICK-OUT, PICK-IN Transaction pair to record that movement, so it is certainly an option here I should say.

For non ASC flow, how would you unreserve a part stuck in a shipment location? I see calling the above method is not a possibility.