@JamesWoo was helping me with a separate /fetch_stock issue a few months ago, but after working through that, it seems like there is another issue.
When Shopify calls our /fetch_stock endpoint, it can do so in one of 2 ways.
1) with SKU information (ie. fetching stock for a particular SKU)
2) without SKU information (ie. fetching stock for the entire store). This happens every hour.
It appears as though 1) works fine, but 2) doesn't update any of the stock for the store. The JSON we pass back is 100% correct (I've checked this), and I know Shopify is getting the data, because case 1) works.
The only other thing to note is we have some things in our warehouse that we pass back that we don't have on our Shopify store. I'm assuming that Shopify would ignore SKUs that are returned that aren't in the store.
Anyone have thoughts on why 2) doesn't work?
Can you provide some examples where you've seen Shopify fail to update inventory after the hourly fetch_stock call? Ideally, if you can provide the X-Request-ID from the request headers, I can use that to pinpoint the issue in our logs. Otherwise, a shop_id, variant_id, SKU and timeframe should suffice.
@_JB Unfortunately I don't have a request ID, but I do have the other information:
shop_id = paxlabstest.myshopify.com
I've seen the SKU "C1-J12" get synced in the hourly sync, but it doesn't update in Shopify.
Thank you for your help.
I've checked our logs and I can confirm I'm not seeing fetch_stock requests for that SKU for the last few days, but when I look at fetch_stock events for that store I'm seeing lots of errors in the logs. In the last few hours I'm seeing timeouts when calling fetch_stock, as well as some empty response errors.
I noticed your test store contains a number of unfulfilled orders, which can make this hard to test. When a store has taken an order but hasn't shipped it yet, Shopify automatically accounts for those units when adjusting based on your fetch_stock response. For example, if a store had 10 of a product and received an order for 1 unit, the new inventory quantity for that unit will be 9. If Shopify calls your fetch_stock endpoint, we expect your response to be 10 (since it's assumed the unit is still physically located at the warehouse). Shopify automatically adjusts your response to account for pending unfulfilled orders, so in this case you will respond with 10, and Shopify won't make further adjustments because your response minus pending unfulfilled equals 9, which is the quantity already showing in Shopify. If you respond with 9 in this case, Shopify will adjust the quantity down to 8 to account for the unfulfilled order.
I also noticed your store currently contains 4 active fulfillment services. While this is definitely supported, the combination of unfulfilled orders and multiple fulfillment services is likely causing testing issues. In order to test this properly, I recommend removing the fulfillment services that currently exist in the test store, and also fulfilling or deleting the existing orders. Once this is done, you can re-create the fulfillment service and assign products to that service. At this point there will be no pending unfulfilled orders, so you should see quantities update right away to match your fetch_stock response exactly. After this, you should see the quantity update every hour as expected.
Please give that a try and let me know when it's done, and I can go into our logs and confirm the response is being processed correctly.
Unfortunately there are no "X-Request-ID" headers sent to our servers, so I am unable to give you specific ID.
I need to clarify, as it sound like you looked for the SKU specifically......which is not where the issue is. The issue is in the sync call (ie. when no SKU is provided). This sync returns all of the SKUs (and one of them is the SKU I mentioned). So if you're looking for fetch_stock, with the provided SKU as a parameter, you won't find it.
The timeouts may happen from time to time (we are dependent on a 3rd party inventory system which can sometimes be slow), but we leverage the same endpoint for all fetch_stock calls, so the speed shouldn't be a factor into why case #1 works, and case #2 doesn't. So the timeout should be irrelevant
As for the way Shopify is calculating stock, this is also irrelevant for the case I've provided. Our inventory system claims a stock of 196, and currently in Shopify the stock is 996 (and we certainly don't have 800 unfulfilled orders for this SKU).
As for our multiple fulfillment services, we only have one used, and its used by all products. If it makes things easier, I can remove all the others, but due to integrations, we can't simply remove and re-create our currently active fulfillment service....
Is there another way that we can get the request ID? (Or is the header key you provided for request IDs incorrect by any chance?)
Hi all we are getting exactly the same issue, sku specific request works perfectly, hourly one nothing. I have reduced the payload for the hourly one down to one SKU in order to debug any potential data issues. Still fails to update that SKU's stock. The SKU is clean and has no pending orders or anything.
Has anyone managed to resolve this? @_JB I have a full request payload from Shopify as well as the response we send back. I am not comfortable pasting that here but if you need more to go on I am happy to send this to you directly.
@marcusorjames We solved the issue. There's a backend bug that exists in the Shopify system. On the product details page in the shopify admin, there is a checkbox for "Track Quantity". This seems as though it does nothing when it should. There is also a drop down for "Inventory managed by". This also does some stuff with regards to fulfillment, but it doesn't appear to connect the dots between "Track Quantity" and the "Inventory managed by" in order to actually track quantity for inventory.
The way to solve this is to go to select all products in your product list and click "Edit Product". You'll then be taken to the Bulk Edit screen.
Here, you have to go through all the "Track quantity" values for all your products and point them to the app that you want to sync them with for inventory
Let me know if this helps.
Hi @gburgoon thank you for taking the time to help, and I hope it helps others but unless I'm missing something we already have all this hooked up, not all our products are managed by the app, so we have explicitly selected the products we wish to track by going to those products, changing the inventory managed by to the app and then checking the track quantity checkbox. Doing this then triggers an API call to our app and the stock value correctly updates.
This however is the last time it will update as the hourly call doesn't work.
Let me know if I have missed something obvious in your solution, but I think we have it set up as expected.