Current behavior: When creating a PO, there’s no visibility into current stock levels — you have to open a separate Inventory tab to cross-reference quantities before deciding how much to order.
Requested behavior: Display the on-hand and available quantity (by destination location) for each variant directly in the PO line item row, similar to how Cost auto-fills from previous POs.
Business impact: Forces merchants to work across multiple screens, slowing down the reordering process — especially for large catalogs with many SKUs and locations.
It becomes a real pain when I have to keep several tabs open across two screens to create one purchase order. This seems like a fix that will save time and frustrations.
FyreTrail’s Draft purchase orders (PO) show this information at the time you add the product to the PO.
I’m guessing you’re asking Shopify to add this to their POs, but who knows when they’ll add it (or even if they ever do). If you need it now, I just wanted you to be aware that FyreTrail provides this out of the box and it’s available right now - with a Free tier and 14-day no risk trial as well.
Worth knowing why this one can only come from Shopify, because it changes how you write the request.
Native purchase orders are not exposed in the Admin API. I went through the current Admin GraphQL reference on this a few weeks back and PurchaseOrder and Supplier both come back as 404, while InventoryItem sits there as normal. So no app, no script and no browser extension can add a stock column to the PO form you are using. That is also why every PO tool you get pointed at is a full replacement of the flow rather than a fix to the native one.
Small thing on the cost auto fill you mentioned, because there are two separate behaviours there. The form pulling a cost from a previous PO is not the same as it pulling from the variant’s Cost per item field, and that second one is its own open request that a few of us have been pushing on already. Shopify native Purchase Orders don't auto-populate line item costs Worth pointing at it so the two do not get logged as unrelated small asks.
One thing I would add to your ask. On hand by itself will still let you double order. If you raised a PO last week for the same SKU and it has not landed yet, the on hand number looks low and you order it again. What you actually want on that row is on hand together with whatever is already on order for that location. Asking for the single number is the version that is cheap to ship and still leaves you flipping between tabs.
How many locations are you ordering across? Past two or three the on order half matters a lot more than the on hand half.
We are only ordering from one location. I just want a column that shows the available quantity in shopify, not whats on hand as there may be orders. I also do not want to use another app to do this. I want it to be native to shopify
Ok, thank you for clarifying. It handles that too, but I understand now you want this in basic functionality of Shopify and not interested in an app that does it - even if it’s free.
You’re right that available is the number to ask for rather than on hand, and for the reason you gave. On hand includes units already committed to orders you haven’t shipped.
Available still won’t stop the expensive mistake though, and that’s the part I’d get into the request.
Available only describes what’s in the building. It doesn’t know about the PO you raised nine days ago that hasn’t landed yet. So the number sits there looking low, and it looks low every single time you check until the shipment arrives. That’s how people order the same thing twice. It isn’t a locations problem, so being on one location doesn’t get you out of it. It’s a timing problem.
The other half is that a buying decision isn’t really about a stock number at all, it’s about how long that stock lasts. Thirty units is three weeks on one product and two days on another. So even a perfect available column on that form still leaves you flipping to something else to work out whether thirty is a lot.
What I’d do in the meantime, no app needed. Before you build a PO, pull up the purchase orders list and look at what’s still outstanding for that supplier. Then build. It’s still two screens, but it’s the screen that stops the duplicate order rather than the one that’s easy to see.
And if you’re adding to the request anyway I’d ask for two columns instead of one. Available, and quantity already ordered but not yet received. The second one isn’t on any other screen at the moment you’re actually making the decision, which is what makes the tab flipping feel so pointless.
Fair point on the single location, that part of what I wrote does not apply to your setup.
One thing worth putting into the request though, because it makes it much harder to wave away. Incoming is not a new number you would be asking Shopify to invent. It is already a first class inventory state in the platform, sitting alongside available, committed and on hand. Shopify’s own docs describe it as inventory that is on its way to a location, surfaced at the destination location, and it is the only state that represents units not physically present. Available is defined to exclude it.
So the ask can be written as available and incoming on the PO line, both read off the same inventory record the form is already reaching into for cost. That reads as a display change on numbers the platform computes anyway rather than a new feature, and it is the pair that actually stops the double order instead of just describing the shelf.
Does your Inventory section already show incoming filled in against these SKUs once a PO is marked as ordered? If it does, that is worth saying in the request. It proves the number exists and that only the PO form is missing it.
I agree that available is more useful than on-hand for the immediate decision, because it already accounts for stock committed to customer orders.I would add one more piece of context to the request: the expected arrival date for quantities already on order.
A low available number does not always mean “buy more now” if a supplier delivery is due before stock will run out. Without that date, incoming stock is useful but still incomplete for a purchasing decision.The most useful PO line would therefore show available, incoming, and the next expected receipt date for that location.
That gives the buyer enough context to distinguish a genuine stock risk from inventory that is already covered but still in transit.For a single location, that may sound like one extra column. In practice, it is the difference between using the PO screen to make a decision and using it only to record a decision made somewhere else.
Your clarification narrows this well: one location, native only, and “available” rather than “on hand.” That means this is not really an app-comparison problem; it is a purchasing-decision context gap inside the native PO screen.
One number I would still ask Shopify to place beside available is incoming. If a SKU has 2 available but 12 already on an open PO, available alone can still cause a duplicate order. A compact line-item view could be Available / Incoming / Next expected receipt.
For the business-impact part of the request, roughly how many line items are on a typical PO, and how often are you placing them? That would give Shopify a concrete time-cost case rather than only a UI preference.
Hi there @Rmsoko78DS
This would be a great enhancement, especially for multi store owners. Quantity on hand and Available quantities should be visible at the line item level in each PO line for easier decisions on replenishment, and less toggling between Inventory and Purchase Orders.
A good workaround is to have the Inventory view filtered to the pertinent location open in another tab while creating the PO, but I agree that having these quantities natively in the PO workflow would make a lot more sense.
Having the information on the same screen would certainly remove a lot of unnecessary checking.
The part I’d also watch with a large catalog is whether the manual cross-referencing creates exceptions — for example ordering something because the quantity you checked was stale, overlooking stock at another location, or discovering the discrepancy only after the PO is created.
Do those kinds of mistakes actually happen in practice, or is the main issue currently just the time spent switching between screens?
Small disclosure: I’m the founder of VedaSuite and we’re working on Shopify operational intelligence around problems that merchants otherwise have to manually detect. Mentioning it because this workflow is directly relevant to what we’re researching.