Label printing

What the feature delivers

From a retailer's portal, two ways to print:

Bulk print

Drop a CSV or Excel file (the kind a distributor packing list, POS export, or stock-receiving manifest already gives you), or paste rows directly. Column auto-detection picks the SKU and quantity columns from common header names in English and Swedish. Pick a template, preview, download ZPL or PDF, send to your printer. Used for warehouse-scale workflows: receiving from a manufacturer, prepping a distributor shipment, relabeling stock with internal codes.

One-click print

Every row in My Parts and My Catalog has a small printer icon. Click, set quantity, print. Uses the tenant's default template and SKU source so no template-picker friction. Used for incidental prints: a returning customer needs a missing label, a single SKU got relabeled, a damaged label needs replacing.

Lookup-to-print

Internal YMM Lookup (concept doc) gives the operator a Year/Make/Model search inside the portal. Each result row has the same printer icon, perfect for label-printing during a receive-goods workflow where you only know the vehicle, not the SKU.

The SKU-source layer

Every part has more than one identifier in real-world commerce: a canonical manufacturer SKU, the SKU your major distributor expects, a retailer POS code, sometimes a legacy supplier number. Different labels need different SKUs.

PowersportOS solves this with a structured AliasSource field on each SKU alias. When a label template renders, it asks "give me the alias for this part where source = the distributor this template targets". If found, that's what prints. If not, the label falls back to the canonical SKU and the pre-flight check warns the operator.

Internal warehouse use

Canonical SKU. Default for generic templates.

Shipping to a major distributor

Distributor-tagged alias. The distributor's template targets that source automatically.

Other distributors

Each gets its own AliasSource enum value. Aliases tagged with the right source; templates pick them up automatically.

Multi-language retail labels

Canonical SKU; the language differentiation is handled in template-level copy, not the SKU itself.

Templates: code-based, extensible, design-iterable

Templates live as TypeScript modules in the platform: a metadata object (id, dimensions, default source) plus a renderZpl(data) function that produces the ZPL string. Adding a template means writing the file. Visual iteration on existing templates means editing the ZPL.

v1 ships four starter templates (25×25 EAN, 50×25 warehouse SKU, 70×40 extended product, plus a 76×25 mm format aligned to a major European distributor's spec). Visually they're plain; they're starting points expected to be redesigned as customer needs surface. Distributor-specific templates for other channels are added one-per-distributor when the first customer on that channel brings the spec.

Per-tenant custom templates (where one retailer's brand styling overrides our defaults) are on the roadmap. Until then, custom design work is a Studio engagement.

How prints reach the printer

PowersportOS gives you a downloadable file (ZPL or PDF). Getting it to your printer is your local infrastructure. We document four bridges in the portal help:

<strong>PrintNode</strong>

Recommended default. Hosted service with a small client installed in your warehouse. Works for any printer brand. Supports multi-operator workflows. From ~$25/mo.

<strong>Zebra Browser Print</strong>

Free, Zebra-only, single-workstation. Best for a single warehouse operator with one Zebra printer.

<strong>WebUSB</strong>

Browser-native. Requires per-session USB permission grant. Backup option for occasional prints.

<strong>Manual download + Zebra Setup Utilities</strong>

Always-works fallback. Download .zpl, send to printer manually.

We don't lock you into any specific bridge. Customer credentials and printer configuration live entirely client-side; PowersportOS just generates the file.

The major-distributor wedge

Large European distributors require their own SKU format on supplier labels. Suppliers historically deal with this via custom Excel macros, one-off Electron apps, or by ignoring the requirement and getting shipments rejected. We absorb the workflow: configure the AliasSource-tagged aliases once, the distributor's template prints compliant labels every time, no Excel macro to maintain.

Strategically this is a wedge into the distributor-channel network: a retailer who becomes a PowersportOS user for label printing alone gets the full bundled platform in the process. Distributors who want their entire supplier base on a consistent label format have a reason to recommend us. See the distributor track for the full strategic framing.

What goes on a label

Templates have the full part record available when they render. Beyond the obvious (SKU, brand, name, category, EAN, OEM ref, dimensions), two warehouse-flavoured fields ride along on every label:

Bin / warehouse location

Tenant-owned, per-part. Free-text label for where the part lives in your storage (A-12, RACK-3, etc.). Editable inline on My Catalog and My Parts. Each Multi-Store child carries its own bin, child A's RACK-3 is unrelated to child B's RACK-3, because each store has its own physical layout.

Print date (UTC)

YYYY-MM-DD stamp generated at render time. Useful for FIFO: older labels on the shelf are visually older. Not stored on the part; generated each print run.

Where to learn more

Customer-facing operational details (how to set defaults, how to wire up PrintNode, how to handle missing aliases at print time) live in the customer-portal help under the Labels section, accessible to logged-in tenants. The technical architecture details (template registry, Labelary integration, schema) live in the admin help for platform operators.