Explicit stock identity labels

Choose the pieces.
Review the whole batch.

Prepare an ordered set of one to twenty private item-link QR labels. Keep the complete selected identities visible before the abbreviated 50 × 30 mm label reaches a print dialog.

Early access · explicit selection and browser printing

Illustrative queue · not a print resultA ring, a chain and a bar.
01

Select

Add each current-location identity deliberately.

Ordered queue; no default selection or select-all
02

Review

Read full fresh titles, SKUs and checked location.

Complete batch preparation or no new preview
03

Recheck and print

One prepared page per selected item.

Dialog copies, media and physical output remain operator checks

A workflow illustration, not a printer/reader certification, physical count or live item batch.

A search result is not a print selection.

A jeweler may need a few replacement tags without printing every item on a search page. The batch workspace opens separately from inventory, so selecting labels does not reset an inspection, buying draft or another open editor. It begins with an empty queue and no prepared labels.

Find an item by exact case-sensitive SKU or a canonical item link from the configured app, then add the found identity explicitly. Enter only performs that field's lookup. It does not open a scanned address, add the item automatically or start printing. Unsupported outside links are not fetched or rewritten into a different item.

The same workspace can browse the existing live inventory search in bounded fifty-record pages. A title/SKU search or recorded-status filter narrows the browsing view; it does not select everything visible. Paging and filters keep the separately chosen queue. A location change clears that selection and preview so old-store results cannot become a new-store batch.

Three pieces, in the order the operator chose.

Imagine selecting a hypothetical estate ring ER-104, then a chain CH-221 from another inventory page, then a bar BAR-019 found by its exact code. Their queue order remains ring, chain, bar. The application prepares one identity-label page for each selected item in that order; it does not sort them by a later search result.

Adding the ring again produces a clear already-queued result, not a duplicate selection or an extra copy. There is no app copy-count field or select-all shortcut. One to twenty distinct identities is the supported batch scope. A larger choice requires an explicit removal before another item can be added.

Removing the chain leaves ring then bar, and invalidates the old prepared preview. Clearing the queue is also deliberate. Neither action changes an item record, quantity, stock state, asking price or audit history. This is preparation of identity pages, not a physical count, inventory allocation or batch stock movement.

Keep the complete SKU; abbreviate the title visibly.

The 50 × 30 mm design contains the Troctolite name, complete SKU, a short title and a QR for the private item record. It adds no asking amount, cost, customer field, notes, weight or recorded status. The selected title itself is identity text to review; it is not a place where the app silently substitutes another label description.

The printed title uses the first thirty-two Unicode characters with a visible ellipsis when abbreviated. The separate prepared-facts review shows the entire fresh title and complete SKU for every selected item. Queue text remains a selection-time reference, so a renamed ring can be distinguished from the name that originally led to its selection.

This label format requires a complete printable ASCII SKU of one to sixty-four characters. It does not shorten a long SKU, transliterate an unsupported identifier or print only the members that happen to fit. If any selected member cannot be labelled safely, the complete preparation fails and the queue stays available for review or explicit removal.

A changed record deserves another look.

Prepare the complete queue, then review the fresh location name, all full titles and SKUs and the label previews. The app checks the complete requested identity set, order and private targets. An unsupported or missing member does not become a partial success with a quietly omitted tag.

Choosing Print verified batch makes another complete authorized request. If the checked facts differ, including a changed title beyond the abbreviated portion or a changed location name, the full new preview replaces the old one and the operator must review it and choose Print again. A changed result never prints automatically.

Editing the queue while a request is pending invalidates that request's preview. Late results from an old queue or location cannot replace the newer selection. A failed connection keeps the queue, shows an error and requires another explicit complete check; there is no background retry or automatic print.

These checks do not reserve stock or freeze physical custody. A piece may move after the response or while a dialog is open. Open the live record when the current location or state matters; a printed identity label is not proof that the item is still present.

The application prepares pages; the dialog controls output.

Use the workspace's Print verified batch control after reviewing the complete preview. The print layout isolates label pages from the picker, queue and application controls. Each prepared label has its own named 50 × 30 mm page, with a page break after each except the last. Other browser print shortcuts do not arm these pages for the app's verified-print flow.

Check media size and actual-size scaling in the browser and printer dialog. Review orientation, margins and any browser-added headers or footers in that dialog rather than assuming a driver profile. Test a single label before committing a batch, keeping the white space around the QR clear.

A prepared page per selected identity is not a claim about physical label count. Dialog copies, printer settings, the roll or sheet and hardware behavior can change output. The application cannot confirm that a label printed or was attached to the right piece. Browser/device/printer acceptance has not been performed, and this release supplies no ring-tag, 1D-reader, dedicated-driver or hardware certification.

The QR is a locator behind the existing sign-in boundary.

Use a 2D reader for the QR. A keyboard-wedge reader can place a trusted item link into the focused lookup field; a phone can open the private app link. The link itself does not grant access, verify ownership or make the record public.

On a phone, sign in and rescan if login does not retain the destination. No new redirect or authentication behavior is added. A later custody change can affect which location may read the current private item, even though the tag still contains the same identity link.

Single-item labels remain available separately. The batch queue is held by its mounted page, without saved templates, reload persistence or a history of printed copies. Use the inventory and handoff guide for operational stock questions, inventory snapshots for recorded store position and availability for the exact current boundaries.

The same printed tag can appear in two accepted events.

A physical label represents a recorded item identity. During a count, its first expected observation covers that frozen identity once. A later deliberate scan remains another event, not another expected piece. An original-request retry should recover the same event rather than manufacture a repeat.

The history reader keeps that sequence reachable beyond the latest fifty observations. An old label can remain meaningful against the frozen count roster after a current SKU changes; history does not replace its captured code with the new label or fetch a stored scan URL.

Printing, observing and investigating stay separate. Neither a printed page nor a duplicate tag observation adjusts inventory or proves quantity, ownership or scanner performance. Read how old labels remain part of count evidence →