Description: Currently, the Retail Barcode Labels app requires manually adding each product individually when printing labels — even after you’ve already received inventory against a Purchase Order or Transfer. This creates duplicate work in an otherwise streamlined receiving workflow.
Requested improvement: Add the ability to enter a PO number or Transfer number in the Retail Barcode Labels app and have Shopify automatically pull in all line items and quantities from that PO or Transfer, ready to print.
Why this matters: For retail stores receiving shipments regularly, this would eliminate a redundant manual step and reduce errors. The PO and Transfer data already exists in Shopify — connecting it to label printing is a natural extension of the receiving workflow. This process adds another whole step, and more opportunity for human error in the receiving process.
Expected behavior:
Search or select a PO or Transfer in the Retail Barcode Labels app
A safer interim workaround is to export the received PO or transfer, keep only the lines actually received, and use one control sheet with variant, barcode, received quantity, and labels printed. Reconcile total received quantity to total labels before printing. It does not remove the missing integration, but it avoids reselecting products from memory and catches partial receipts or backorders. If Shopify builds this, the print quantity should come from received quantity—not the original ordered quantity.
I’d definitely add one detail to this request: the label quantity should default to the actually received quantity, not the original ordered quantity.
If a PO has 50 units but only 30 arrive in the first shipment, pulling the PO directly and printing 50 labels creates a new error while trying to remove manual work.
Ideally the flow would be:
PO / Transfer → select receipt → received variants + received quantities → review → print
And then allow reprinting labels for that specific receipt later without rebuilding the list.
One edge case worth folding into this request: new products often arrive on their very first PO before anyone has assigned them a barcode, so the auto-populate step should flag line items with missing or duplicate barcodes rather than quietly printing blank labels.
Receiving is usually the moment people discover that, standing at the printer. The received-vs-ordered point above matters even more with partial shipments, since a 50-unit PO that arrives in two deliveries really needs two label runs tied to each receipt rather than one run against the PO total, which is a good argument for making the receipt, not the PO, the unit the label list is built from.
@ginger_1, does the receipt-level flow above match your current pain? When a PO arrives in two partial receipts, are you rebuilding the received product and quantity list manually for each label run, including any later reprint?
Hi there @ginger_1
This would be a useful adds-on to the Retail Barcode Labels workflow. The variants and quantities received are already in the PO and Transfer, letting the user select one and pre-fill the label queue would be eliminating manual input which means errors.
A practical workaround is to consider the received PO or Transfer as the source of truth and generate the label quantities based on the variants received. Native support for choosing a PO or Transfer would make this much quicker for stores that receive deliveries often.
On the request itself: there is no native way today to hand the Retail Barcode Labels app a PO or Transfer number and have it pull the lines in, so the manual re-entry you describe is the current reality. The request is a fair one and worth votes.
On the two points raised in the replies, both matter more than they look.
kai_xing and salor_works are right that the print quantity has to come from the received quantity, not the ordered quantity. Shopify’s shipment data exposes those as two separate fields, the accepted quantity per line and the ordered quantity, and a short or partial delivery is the common case rather than the edge case. Anything that prints off the ordered quantity will over-print on every partial delivery, and you tend to find out while holding the extra labels.
Opsloft_Team’s point about products arriving on their first PO with no barcode yet is the other half of the problem. If you generate barcodes at receiving time, generate them before the label batch is built, and preview them before anything is written, because a barcode written onto a variant is painful to walk back once labels are already on stock.
A practical interim workflow that does not wait on this feature request: receive the shipment natively, then drive the label batch off the shipment record rather than off a product list. That keeps the received quantity as the source of truth and it survives partial deliveries without any manual reconciliation.
For transparency, that is what my app (LabelCraft) does. It reads native Transfers, builds the batch from the accepted quantity per line, and can generate and preview missing barcodes for products showing up on their first PO. I am not posting a link. The native feature you are asking for would still be the better answer for everyone, so I would keep pushing the request regardless.
Disclosure first: I build Binly, an inventory app, so read this with that in mind.
The reason nothing does this natively is buried in this thread already: Shopify’s API doesn’t expose purchase orders to apps. Nobody can read your native PO, so every real solution ends up being an app with its own PO flow.
That said, the three problems raised here are exactly solvable, and worth demanding from whatever app you pick:
Labels from received quantity, not ordered. salor_works nailed the danger — a PO for 50 where 30 arrived should give you 30 labels, not 50. Default to what was actually received.
Editable counts before printing. Partial deliveries, damaged units, a box you’ll label tomorrow — you want to see every line with its count and adjust before anything prints.
Missing barcodes caught before printing, like Opsloft_Team said. New products often have no barcode at all. The app should tell you “3 of 14 items have no barcode” and offer to generate valid EAN-13s for just those — never touching products that already have one.
Binly does all three as of this week: receive a delivery on a PO, export a label file with one row per unit received (Dymo Connect prints one label per row), flip to ordered quantities when you want to prep labels before the truck arrives, adjust any line’s count, and generate barcodes for the items that lack them. Update, since things moved: it now also reads Shopify’s native transfer shipments — pick a shipment and the rows prefill from what you accepted at receiving. The native PO screen itself is still closed to every app (paragraph two), but the transfer your PO feeds is readable, and that covers the receiving flow this thread is about. Otherwise it works with POs created or imported in Binly — Stocky CSVs come across too.
If you’re set on staying with native POs and the Retail Barcode Labels app, upvoting this thread is the right move. The API gap is Shopify’s to close.
@ginger_1 I’m not with Shopify and I’m not selling anything, just
trying to understand how retailers are handling this.
You wrote that the Retail Barcode Labels app makes you add each product
manually even after you’ve already received the inventory against a PO.
How many items do you typically receive at once, and how long does the
labelling take you today?
The duplicate work you described caught my attention.
If the PO or transfer already contains the products and quantities received, having to manually rebuild that same list again for labels seems like exactly the sort of repetitive step that should disappear.
Out of curiosity, when you receive a larger shipment, roughly how many products/variants are you having to add manually before you can print the labels?