delete via API works a couple of times then dies

[Mike.Sheen]

Also, to entertain exactly your steps, I repeated the process again but instead of using Postman to delete the item I used Swagger as in your steps:

And the response was exactly the same:

[JuiceyBrucey]

before I document everything, which I will do, no problem, let me address a couple of things here:
"Do you think it possible that someone else added the item you created to a stock transfer?"
Yes, I did. I did not use the method described, I used the JIWA interface that shows products being transferred. No one would have touched this product anyway. It is clearly marked as "TESTING, PLEASE IGNORE, BRUCE". The ladies in the office know I am running all sorts of tests.
The status of the inventory item changes to "locked" or "being transferred" etc, as soon as it is viewed. I can patch any item after viewing, or do several other operations, but I cannot delete.

In your step 2, the newly created inventory item was not pulled, so it was not locked.
Then it follows that it has not been viewed and therefore it can be deleted without any problem.

For the item to be locked, it must have been pulled via the plugin.
This item: 2ea9e7a0db2449a08f44 was not pulled, so it was not locked, so it can be deleted.
"Step 2. Perform a GET on the /Custom/GetAllInventoryMinFields route - you never provided what parameters so I used /Custom/GetAllInventoryMinFields/1/5"
Try pulling ALL data by using /Custom/GetAllInventoryMinFields/0/3000 or a number that ensures every single item in the inventory list is pulled. Then try to delete.
Thank you.
Cheers

[Mike.Sheen]

"Do you think it possible that someone else added the item you created to a stock transfer?"
Yes, I did. I did not use the method described, I used the JIWA interface that shows products being transferred. No one would have touched this product anyway. It is clearly marked as "TESTING, PLEASE IGNORE, BRUCE". The ladies in the office know I am running all sorts of tests.

But you still didn't run the SQL script I provided to prove that it is not present on a stock transfer document. Run the damn query and report the result.

The status of the inventory item changes to "locked" or "being transferred" etc, as soon as it is viewed. I can patch any item after viewing, or do several other operations, but I cannot delete.

No, you are incorrect. Just viewing the item does not change it. That inventory ID has to be on a stock transfer to get that error. If you run SQL Profiler to log all SQL queries during a call to your route you would see that. Have you tried that?

In your step 2, the newly created inventory item was not pulled, so it was not locked.
Then it follows that it has not been viewed and therefore it can be deleted without any problem.

No, you are incorrect. Your plugin which introduces the /Custom/GetAllInventoryMinFields route merely performs a select query on IN_Main and this will not perform any locking and it won't put it onto a stock transfer document. By the way, that query is redundant as we already have built-in queries to retrieve exactly the same information.

For the item to be locked, it must have been pulled via the plugin.
This item: 2ea9e7a0db2449a08f44 was not pulled, so it was not locked, so it can be deleted.

That is incorrect, it is not locked. And even if it was, my lack of issuing the right API call is entirely your fault - I asked you for exact steps to reproduce and you failed to provide the parameters necessary to reproduce your scenario.

You need to listen to what I am telling you and follow my guidance. Just pretend for a bit that I have some experience in how to troubleshoot, and also have a sound knowledge of the Jiwa platform.

I can guarantee that if you follow my guidance exactly and without alteration we'll find what you're doing wrong pretty quickly. Assuming I'm the idiot here and ignoring every second question or instruction I ask of you because you have incorrectly deduced that it couldn't possibly be relevant is not going to solve the problem.

My current likely reasons for your issue are:

1. Your delete operation is using the wrong InventoryID
2. Your delete operation is operating on the wrong database
3. The inventory item is on a stock transfer (and / or other documents) after all

[Mike.Sheen]

For the item to be locked, it must have been pulled via the plugin.
This item: 2ea9e7a0db2449a08f44 was not pulled, so it was not locked, so it can be deleted.

Nope - see screenshots below disproving this theory.

[Mike.Sheen]

By the way, that query is redundant as we already have built-in queries to retrieve exactly the same information.

/queries/IN_Main?Fields=InventoryID,PartNo,Description,Aux2&OrderBy=Description&Skip=0&Take=5 is the route we ship with by default which performs the same as the route your plugin introduces:

[JuiceyBrucey]

"You need to listen to what I am telling you and follow my guidance. Just pretend for a bit that I have some experience in how to troubleshoot, and also have a sound knowledge of the Jiwa platform."
Yes, that is what I should have done. But I didn't. And now I have wasted a lot of your time and probably frustrated you as well. Not probably, definitely.
You are correct, of course, items that cannot be deleted are on transfer.
Very sorry to have put you to so much trouble. Some of this just did not make sense to me.
Next time I will just follow your instructions exactly.

So my next question, should be how do I identify the transfer id so I can use the API to remove the item from transfer?
Or is there some other process?
Sorry for putting you to so much trouble.
Wont happen again.