In Shopify POS when looking at a product or a variant in Inventory, there is the “Incoming” status. I had thought this would work similar to my last software; as soon as I created an open purchase order, that product would be marked as “On Order”. That way, if we were out or low on stock of an item, my staff could easily look and see that we would be getting more and inform interested customers.
Am I misunderstanding the purpose of “Incoming” for Shopify? No matter what I do, “Incoming” never changes from zero. We are using Stocky to create and send purchase orders, which as far as I understand is a Shopify-based app.
One last note:
We have two shops on the same physical site (in two separate buildings), and we only receive inventory at the primary store. Each has their own Shopify location, so we transfer inventory between the two. Would this affect what the second store can see as Incoming?
The overall goal would be for both locations to view anything on a confirmed purchase order as Incoming.
For us the useful part of “incoming” is not just showing one number — it’s knowing what stage that stock is actually at.
Ideally staff should be able to distinguish:
Ordered: 100 Invoiced: 100 Received: 60 Still incoming: 40
and ideally see the expected location as well.
Especially with multiple stores/locations, “40 incoming” only helps if the team can see where it is expected to arrive and whether it is still on order, partially received or actually in transit.
I think that visibility is more useful operationally than simply adding all open PO quantities into one incoming figure.
Curious whether anyone has found a replacement that exposes this clearly to POS staff rather than only to whoever manages purchasing in Admin.
Incoming counts units on native Shopify documents only. That is why yours never moves.
It reads transfers and purchase orders living inside Shopify that somebody marked as on their way, so an order raised in a third-party app stays invisible to it, however confirmed that order is, because Shopify holds no record of it existing at all. Stocky worked the same way. The POs you were sending never fed the POS number. The one route open to an outside app is writing an incoming transfer into Shopify itself, and some do.
So ask directly.
“We track incoming stock” usually means inside their own screens. Incoming also works per location, so stock heading for the primary store shows nothing at the second one until the transfer between them exists.
@Denyslg has the answer to the original question. One thing to add, because it is the part that catches people after they have understood that much, and it speaks to what @salor_works is asking for.
The incoming number carries no date. Shopify exposes it as a single quantity and nothing else - no arrival date, no document it came from, no split by which order. So even for a native transfer or purchase order that does feed it, “40 incoming” means forty units are expected at some unspecified point. It could be tomorrow or March.
That matters more than it sounds if you plan reorders off it. A quantity with no date can honestly reduce how much you still need to buy, and it cannot honestly move the day you run out - so an app that lets incoming push the stockout date later is guessing, and it will tell you a product is fine on the strength of a container that has not left yet. Worth checking how whatever you use treats it.
@salor_works the staged view you describe - ordered, invoiced, received, still incoming, and where it is expected - is not something any app can read out of Shopify, because none of those stages exist in the data. Incoming is one scalar. An app can show you that breakdown only from purchase orders it holds itself, which is also why those numbers then disagree with the POS: they are two different records of the same delivery, and only one of them is inside Shopify.
On whether this ever changes: Shopify announced a Physical inventory feature preview on 17 July that lets apps read native purchase orders and their line items and supplier. That does not make third-party POs feed the POS number, and it is unstable and dev-store only today, so nothing you can install now uses it. But it is the first time an app could show Shopify’s own incoming documents next to its own records rather than beside them, which is the shape of what you are asking for.
Disclosure: I build an inventory forecasting app, so the paragraph about stockout dates is a thing I had to decide rather than a neutral observation.
@juhyun_han Thanks, this explains the limitation much better.
The fact that Shopify’s “incoming” is just one quantity with no date or source document is probably the key thing I was missing.
Operationally we do think of these as separate stages — ordered, invoiced, physically received, and still outstanding - because they can diverge quite a lot in real life.
So I guess for now any useful staged view has to live outside Shopify and then only the final received quantity becomes Shopify inventory.
The Physical Inventory preview sounds interesting though. If apps can eventually read Shopify’s native PO lines and supplier data, that could at least reduce the duplication between Shopify’s record and the app’s own purchasing record.
@salor_works that is the right conclusion, and there is one consequence of it worth knowing before you rely on the arrangement, because it is the way it actually breaks.
Once the staged view lives in an app and only the received quantity reaches Shopify, you have two records of the same delivery and they can disagree. The dangerous direction is not the app falling behind Shopify — it is the app writing to Shopify twice. A slow response, a refresh, a retry of a request that actually succeeded: each of those can push the same receipt again, and stock quietly doubles. Nothing looks wrong afterwards, because an inflated number is a perfectly ordinary number.
The fix is that the purchasing record has to hold two figures per line rather than one: how many arrived, and how many of those have already been written into Shopify. Writing the difference between them makes a second press compute zero and do nothing. If you are evaluating apps for this, it is a fair question to ask directly — “what happens if I press receive twice” — because the answer is invisible from the outside and expensive to find out on your own stock.
On the preview reducing duplication: it reduces it in one direction only, and that is worth being precise about. Apps will be able to read Shopify’s purchase orders, so the app can see Shopify’s record. There is still no mutation to create or update one, so Shopify cannot see the app’s. The two records do not merge — one of them just stops being invisible to the other, which is genuinely useful and is less than it first sounds.