Nucleo POS

Nucleo POS keeps your retail network's stock honest. It reads locations, stock and transfers directly from your commerce platform and adds what store teams actually need: a guided receiving flow, zone-based inventory counts, and an alert center that surfaces discrepancies instead of burying them in lists.

Getting started

Open the POS module from the workspace selector after signing in. The sidebar is short on purpose — store staff should find things in one glance:

  • Home — your landing page with key numbers and an ask bar.
  • Movements — every stock movement across the network, in one list.
  • In transit — only the goods currently moving.
  • Inventory — Stock (live stock per location) and Inventory count (counting sessions).
  • Alerts — open discrepancies, overdue transfers and off-list items.
  • Configuration — locations, transfer rules, notifications and permissions.

The POS module works alongside your commerce platform, not instead of it: locations, stock levels and transfer documents stay there and are read live. Nucleo adds the operational layer on top — receiving, counting and alerting.

What you see is filtered by your assigned locations: an administrator decides which stores each person works with, and stock, transfers and counts show only those.

Stores & locations

Configuration → Locations lists every location synced from your commerce platform — warehouses, hubs and stores — so you can verify at a glance what the module sees. Locations are not created here: the sync is the source of truth.

Location roles and transfer rules

In Configuration → Transfer rules you classify the role of each known location (warehouse or store). The movement type is then derived automatically from the route: goods leaving your warehouse for a store are an Inbound, store-to-store is a Transfer, store-to-warehouse is a Return. No manual tagging on the source documents — the rules do the reading.

People and permissions

Configuration → Permissions lists the real members of your workspace with their role and their assigned locations. Assign locations per user: the Stock view, transfers and counts then show each person only the stores they are responsible for.

Store stock

Inventory → Stock shows the available stock of one location at a time, read live from your commerce platform. Pick the location from the dropdown (your first assigned location is preselected), and the table lists its products with image, SKU and on-hand quantity, 25 rows per page.

  1. Open Inventory → Stock.
  2. Choose the location from the dropdown.
  3. Search by SKU or product name to jump to a specific item.
  4. Read the on-hand quantity — what you see is what the platform sees, right now.

Inventory counts

Inventory → Inventory count manages physical counting sessions. Each session belongs to one location and is organized in zones — count the floor, the stockroom and the window separately, and let the module do the math.

  1. Click New inventory count and pick the location.
  2. The count opens on its first zone, ready to scan.
  3. Scan barcodes (each scan adds one unit) or search the catalog and add items manually — everything is counted at variant level, SKU plus size.
  4. Add zones as you move through the store; each zone keeps its own tally.
  5. Close the count when every zone is done.

Count by zone and reconciliation

The Count by zone view shows what was counted where, with an All tab aggregating every zone. The Reconciliation table compares your total against the expected stock, row by row: expand a variant with a difference to see exactly which zones it was counted in — the fastest way to decide where to recount.

Counts work per variant, never per parent product: a size missing from the shelf is a real difference, even when the product as a whole looks fine.

Transfers & movements

Movements is the unified list of every stock movement in the network. Each row shows the reference, the type, origin and destination, the number of units, the status and — once closed — the outcome.

  • Types — Inbound (warehouse to store), Transfer (store to store) and Return (store to warehouse), derived automatically from the route.
  • Statuses — Draft, In transit (goods on the move) and Completed (closed on the platform).
  • Outcomes — Matched when everything arrived as expected; otherwise one badge per issue: Short, Over, Not found or Off-list.

Filter by type, status and store, or use the In transit page for the short list that matters on the floor today: what is about to arrive. Click any movement to open its detail.

Receiving

Opening an in-transit movement starts the receiving flow. The packing list shows every expected line — product, size, expected quantity — and you record what actually arrives.

  1. Open the movement from Movements or In transit.
  2. Record the accepted quantity per line as you unpack.
  3. Mark items you cannot find as not received.
  4. Got something that is not on the list? Add it as an off-list item: search the catalog, pick the size and quantity.
  5. The discrepancy panel keeps a running summary — extra items received and expected items still missing — until the movement closes.
"Not found" is deliberate wording: the store is not rejecting a piece, it simply is not in the box. The sending warehouse is notified so claims and corrections can start immediately.

Alerts

The Alerts page is the module's real value on transfers: instead of re-reading lists, you get one entry per thing that needs attention, with counters for open, overdue and resolved alerts at the top.

  • Short — fewer units arrived than expected.
  • Over — more units arrived than expected.
  • Not found — an expected item was not in the shipment.
  • Off-list — an item arrived that was not on the packing list.
  • Overdue — a transfer has passed its expected arrival without closing.
  • Partial — a movement received only in part, expandable to see what is missing.

Filter alerts by type, store and status (Open or Resolved), and click through to the movement behind each one.

Notification settings

Configuration → Notifications controls the thresholds: how many hours after the expected arrival a transfer becomes overdue, how often reminders fire, and who gets notified for each alert type — the sending warehouse, for example, needs to know about extra or missing pieces to start corrections on its side.