Will try to explain my problem as simple as possible. We got 5 locations and one of those is our main location managed by a third party logistic firm (3PL). Lets call main location A and dropshipping locations B-E.
Problem becomes exponational as we have 18 as sellable stock, when we infact should have 19. If we sell 10 we will infact have 0 and stop selling that specific product 50% ahead of time (panic).
We get a return of the above order sent from B and that return ALWAYS goes to A. 3PL recieves the order and notice they have an unfullfilled order (as their system pulled the initial order data before it was fullfilled), issue an order and it goes out to the customer (a second time) and stock goes down with 1 more at A and we now also have to issue a 2nd return to get our product back. (if we even notice)
I don't know where the problem is. The app that pulls the data or the fact that we have to have (do we?) have two locations on all products (as any return will end up at A, no matter what location originally shipped the product). Also seems like the API isn't bi-directional so a Shopify fullfilled product will send a "ping" to the app to delete the dormant rest-order located inside the 3PL system.
Basically they end up with as many rest-orders as we sell orders where location A is included on the Product (not the order) and that is obviously a catastrophy.
How can I backtrack this is in best possible way to find what is causing this problem? Critical need of help...
Based on what you have explained it sounds like the issue is how your cart integration is setup to your 3pl. This is how it is typically setup :
Shopify Shopping Cart
3plwarehouse management software
Location A,B,C,E should have specific SKU’s that they download from your cart based on only what they stock at their location. If not they will download all your orders and diminish your inventory because they’ve pulled products that don’t exist at that location. It is a nightmare to fix but can be done, I recommend that all rest orders be electronically filled and process returns for all of them. When processing the return select the location that actually stocks the items in inventory, as the return address. This should replenish your inventory through the returns process.
I Operate a large 3PL, but we’re never big enough to answer questions. You can contact me directly if you ever need help.
Thx for the reply, but not really. We got an app, it is working, but there is no value to pair with it turns out.
Found the .json addition (didn't know it worked in admin)
Problem is much simpler and much bigger. The Shopify API has no info about stock location before you actually fullfill an order. This will make it impossible to do any type of integration or app for any store where you have stock of the same product on more than one location.
As the key is "null" then every order (where a product has more than one location) will be fetched (correctly) as there is nothing in the API to distinghish the order lines
I have no clue why this isn't in the api per order, before it's fullfilled (as you can choose it in the dropdown in the backend) but it's not.
We "cant" have unique skus as it's in fact the same products across multiple locations. We have our own stock of products that for example another location (the vendor) offer dropshipping from. So depending of split orders or not, we have to fullfill from different locations. Unique SKU's would add to the nightmare.
Sorry, but not even close. It's not a settings problem, it's an API problem. Will try to explain my problem better.
When you update fullfilment location on an order, you actually isn't updating fullfillment location on that order, only in the GUI of the admin (the API still shows "NULL" for fullfilment location id. It is ONLY when you actually fullfill an order you will write down the current (in the admin) fullfillment location id to the order. That might not sound like a big deal, but it's HUGE.
If you, like me, have multiple locations and will have the same SKU on multiple locations, you will in fact either have to query each order line individually (read API call limit reach) or you will end up with duplicate fullfillments. This, due to the 3rd party logistic and app/api will not know what orders to fullfill, so you will have to fetch them all. That will also make all orders dormant in the WMS. What happens when you get a return on a SKU included in a dormant order? It will flag as OK and be delivered (duplicate delivery for that customere).
This MUST be a bug in the API. I can't imagin this should be excluded by purpose