Give every sellable item its own identity
A simple product can retain UPC, custom SKU, and numeric SKU values alongside its name, price, cost, category, brand, tax, and inventory detail. For a configurable product, those identifiers belong to the individual sellable variant, so a size, color, flavor, or strength can resolve independently instead of deducting stock from a generic parent.
Scan into a register built for the code
The retail sale screen includes a dedicated barcode input. A compatible scanner can send its code into that field, or the cashier can enter the code manually and submit it. Scanner behavior and connection method are verified with the merchant's chosen station and hardware during rollout.
Resolve one exact match—or stop
The lookup compares the submitted code exactly against UPC and custom SKU, and against numeric SKU when the code is numeric. One match returns that sellable item to the register. No match produces a not-found result. Multiple exact matches produce an ambiguity error rather than silently ringing an alphabetically convenient product.
Carry the item from the cart into operations
Once the exact item or variant is in the cart, the sale retains its product identity through the transaction and inventory record. Product search can also use name, SKU, or barcode when a scan is not the best path, while pricing, customer assignment, discounts, tax, card, cash, receipts, and split tender when included in the merchant's payment setup remain part of the same checkout.
Use inventory pressure to drive the next action
Low-stock visibility helps surface products that need attention. Suppliers, purchase orders, full or partial receiving, inventory history, and transfers between locations provide the operational path after the sale. Those workflows remain connected to the product catalog, but they should not be described as scanner-driven unless that exact behavior is demonstrated.
Prove the scanner and symbology in the rollout
Bring the merchant's actual scanner, station, sample UPCs, custom SKUs, numeric SKUs, and difficult variants into acceptance testing. That focused proof confirms the exact lookup, hardware, symbology, and catalog behavior the operation will use.
Scan or enter an exact code, confirm the resolved variant, and trace the sale into inventory. Availability can depend on enabled modules, hardware, payment setup, role, location, and rollout configuration.
Move from the feature to the operation
This capability shares customer, employee, product, location, transaction, and reporting context with the rest of LiftedPOS. The value is not a checked box. It is the handoff the operation no longer has to rebuild.