Inventory, Transfers, and Serialized Stock

These tools are separate because they protect different stock records. Inventory controls quantities at one store, Transfers moves quantities between stores, and Serialized Inventory tracks individual units. Selecting the correct store before you begin is required for all three pages.

Access at a glance

• Inventory appears with inventory read access. Inventory write access adds receiving, adjustments, and par/reorder settings. Report read access adds inventory export.
• Transfers appears with transfer read access. Transfer write access adds create, ship, receive, and cancel actions.
• Serialized Inventory appears with serial read access. Serial write access adds serial creation and sale/return status changes.

Access to one page does not grant access to the other two. For example, inventory write access does not allow a user to ship a transfer, and transfer write access does not allow a user to change a serial record.

Review stock levels and the ledger

Open Catalog & Inventory > Inventory.

1. Use All to review the full inventory list, or select Low stock to show items whose on-hand quantity is at or below their reorder point.
2. Search with Search inventory when you know the product name or barcode.
3. Review On Hand, par level, reorder point, suggested refill quantity, and Status.
4. Select an item row to open Inventory Detail.
5. In the detail, review Quantity, Reorder Point, Last Counted, and Recent History. Recent History is the item ledger for receipts and adjustments.
6. Review stock across accessible locations in the location stock panel. Location records remain permission-scoped; another store may be unavailable to your role.
7. With report read access, select Export and choose CSV, Excel, or PDF.

Low-stock results depend on configured thresholds. Inventory write users can select Par and set:

• Par level (target healthy stock)
• Reorder point (alert threshold)
• Reorder quantity (suggested refill)

Leave a field blank to clear it. The reorder point must be at or below the par level.

Receive inventory

Use this procedure for stock received directly into the selected store outside the Purchase Orders receiving workflow.

1. Open Inventory and select Receive Inventory.
2. Under Product, search by product name or barcode and select the matching result.
3. Enter the received Quantity.
4. Add Notes that identify the shipment or count source.
5. Select Receive.
6. Open the product's Inventory Detail and confirm the new quantity and Recent History entry.

Inventory write access is required. For corrections rather than receipts, select Adjust, enter a positive quantity to add or a negative quantity to remove, add a required Reason, and select Adjust. Do not use two manual adjustments to represent a store-to-store transfer.

Receipts and manual adjustments are server-owned, keyed requests. If a response is interrupted, retry the saved request with its original identity; do not submit a new adjustment to compensate for an unconfirmed result. The server replays the original receipt without applying stock a second time and rejects reuse of that identity for different quantities or reasons. Lot receipts must have a strictly positive quantity.

API clients must send X-Idempotency-Key for ordinary inventory receipts, manual adjustments, lot receipts, transfer creation and receiving, and count-session creation and closing. Count entries and recounts carry their key in idempotencyKey. Keys bind the authenticated actor, scope, and immutable request. Completed inventory receipts are retained durably and replay the original result, even if stock or lifecycle state has since changed. Lifecycle capability flags do not grant permission; endpoint authorization is still enforced for every delivery.

Assistant inventory and purchase-order commands retain their own command identities. Recovery confirms a receive only from that command's matching durable receipt, not because another operator has received the transfer or increased the order's received quantities.

Lot expiry alerts on the POS

Open More > Expiry Alerts after receiving or correcting a dated lot. Opening the screen refreshes alerts from the store's current remaining lots; it does not wait for the daily background check or call notification delivery. Each card identifies the product, individual lot, printed date and date type. Sold-out, zeroed and corrected-outside-window lots are excluded. A notification-service outage does not hide the cards.

Dates are calendar dates in the store's configured time zone, not UTC or the terminal's time zone. Expired means before the store's current date, Today means that date, This Week means tomorrow through seven calendar days ahead, inclusive, and Later means eight through thirty days ahead. A date thirty-one days away is outside the default window. This is a rolling seven-day window, not the remainder of the Monday–Sunday week.

USE BY dates require removal only after their date has passed. BEST BY and SELL BY dates are informational quality/sales notices, including after their date; they are not represented as mandatory food-safety removal. A future USE BY date is not already expired. Acknowledge acknowledges all currently reached notices for that lot; a newly reached notification threshold may create a new notice later.

The supported server notification thresholds remain 30, 7 and 1 days, owned by deployment configuration (app.expiry.thresholds). There is no merchant-facing lead-time setting. Receipt/correction transactions durably queue newly due threshold notices; an independent delivery job runs every minute in batches of at most 100. Failed notices are deferred for five minutes and ordered by retry eligibility, so an unhealthy store cannot monopolize every batch. Delivery may take longer during a backlog or outage, while screen reads remain available. Retry uses the same notification identity and immutable threshold-notice copy, without re-notifying legacy alerts; open the screen for current date urgency and action. The daily check remains at 06:00 UTC (also on staging) to discover newly reached thresholds even when nobody opens the screen. Before the current-lot refresh was introduced, lots received after that check could wait until the next 06:00 UTC, nearly 24 hours. Historical API threshold records remain audit/notification records; they are not the screen's date buckets.

Record an observed stock count

A physical count is an observation, not an adjustment delta. Select the product, enter the quantity actually counted, and submit it to a server count session. The server captures expected stock, computes the variance, and applies the store's recount and approval policy. Peak Mobile does not add one to expected stock or manufacture a negative adjustment.

Count-session and entry actions come from the server's current capabilities. A submitted entry may require recount or approval rather than immediately changing on-hand stock. Resume the same saved count request after an interrupted response; a new key is for a genuinely new operator attempt, not a delivery retry. Manual adjustments remain separate explicit additions or removals with a reason.

Peak Mobile's Saved requests is a delivery-recovery queue, not count history. After the client safely consumes a confirmed receipt, completed entry, recount, and close requests are removed from that queue; the most recent confirmed session creation is retained as a navigation reference. Unconfirmed requests and confirmed receipts not yet consumed remain saved with their original bodies and keys. Review the server count session for current entries and lifecycle status.

When reopening an older count, API clients read GET /api/v1/stores/{storeId}/inventory/count-sessions/{sessionId} for the exact scoped session and its current capabilities. Its availability does not depend on appearing in the first page of count history.

Transfer stock between stores

Open Catalog & Inventory > Transfers. At least two stores must exist before a transfer can be created.

Create a transfer

1. Under Create Stock Transfer, choose From Store and To Store. They must be different stores.
2. Add optional Notes.
3. Under Items, choose a Product and enter a whole-number Quantity of at least one.
4. Select Add Item for each additional product.
5. Select Create Transfer.

The new transfer is pending. It does not complete the destination receipt by itself.

Products belong to individual store catalogs. Before creating a transfer, the destination must have an active product with the same canonical barcode; SKU and internal product IDs are not cross-location identities. If the destination has no matching product, add it there first. Creation rejects unmatched lines before any transfer is saved, and receiving rechecks the match before any inventory changes. Receipt debits the source product and credits the destination's own product so the stock can be sold, adjusted and transferred back there. The paired ledger entries retain the transfer reference, actual product IDs, employee and notes. A receipt is atomic; one invalid line prevents the entire receipt.

If a matching destination product exists but is inactive, contact catalog support before transferring. Do not add another product with the same barcode to work around the inactive entry.

Creation freezes the destination product and canonical barcode identity on every line. Editing the source barcode later does not redirect an in-flight shipment to another destination product. Receipt requires that the frozen destination product is still active at that store and retains the frozen barcode; otherwise restore that catalog entry before receiving. Historical transfers without a frozen mapping are blocked for support review rather than inferred from mutable catalog data.

Ship, receive, or cancel

1. In Transfers, select a row to open Transfer Detail.
2. Review From, To, Status, and each item's requested and received quantities.
3. While the transfer is pending:
   • Select Ship when the source store dispatches the stock.
   • Select Cancel Transfer only if it should not proceed.
4. When the server offers Receive after shipment, enter Receive quantity for each item and select Receive.
5. If fewer units arrive than requested, enter the actual quantity and explain the discrepancy. Completion records the requested and received quantities; it does not leave a second receipt open. Only the received quantities move from source to destination, with paired inventory ledger entries identifying the employee and receipt notes.

Transfer write access is required for all four lifecycle actions. An organization-wide effective transfer-write grant covers both stores without separate store memberships. A store-scoped grant requires membership at both stores and transfer-write access in the selected store scope. The server supplies the current caller's Ship, Receive, and Cancel Transfer capabilities together with remaining receipt quantities; clients do not infer permission from a status label. An interrupted receive is replayed using the original request identity without receiving the same stock twice.

A permission rejection is not an unknown outcome. The portal and POS name the transfer's source and destination stores in the access message, and hide lifecycle actions that the server does not allow for the current caller. A first request rejected with HTTP 403 is retired. If an earlier delivery was unconfirmed and its retry is denied, the client retains that original request identity internally without offering resume or new-attempt recovery controls; the rejection does not prove whether the earlier delivery applied.

On the POS Android app

Open More > Stock Transfers. The register's location is the source; it cannot be selected as its own destination.

1. In Create, select a destination by its location name. Only locations in the same organization admitted by the transfer-write authorization policy are offered. If another location is missing, confirm the employee's membership at both locations; general catalog access alone is not transfer authority.
2. Search the existing catalog by name or SKU, or scan a product barcode. Select products and enter a positive whole-number quantity for each. Internal product and store IDs are not manual-entry fields.
3. Submit transfer creates a pending record. Open Sent, review its products and destination, and Mark shipped when the stock leaves.
4. At the destination register, open Receive, choose an incoming shipped transfer, and verify every line's received quantity. Enter zero for missing stock and record receipt/discrepancy notes.
5. Confirm receipt and complete applies the actual received quantities and records the audit trail. Pending and shipped states alone do not change inventory. Received quantities cannot exceed the sent quantity; at least one line must have a positive receipt.

If submission says the destination has no product with a barcode, add that product to the destination catalog first. If the matching destination product is inactive, contact catalog support instead; do not create a duplicate barcode. If a product needs a barcode, set it at the source before transferring. These catalog checks reject creation without saving a transfer; correct the catalog rather than shipping unmatched stock.

If a create or receive response is interrupted, use Resume pending. It preserves the original destination, products, quantities, reason and request identity; do not enter another transfer to compensate for an unknown result.

Track Serialized Inventory

Open Catalog & Inventory > Serialized Inventory. The page is scoped to the selected store and lists each serial's Status, product, received date, and sold date.

Create a serialized item

A product must already require serial tracking before it appears in this workflow.

1. Under Create Serialized Item, choose the Product.
2. Enter the unique Serial Number.
3. Optionally enter Notes and Required Forms.
4. Select Create Serial.

The new serial is added to the selected store. Serial write access is required.

Find and update a serial

1. Enter the exact serial in Lookup Serial, then select Lookup. You can also select a row from the serial table.
2. In Serial Detail, review Status, Sale transaction, Received, and Sold.
3. When the server offers Mark Sold, optionally enter Sale transaction only when matching the available serial to a completed sale, then select Mark Sold.
4. For a sold serial that has physically returned, select Mark Returned.

Serial read access allows lookup and review. Serial write access is required for Mark Sold and Mark Returned. The server supplies these actions from the current serial lifecycle: only an available serial can be sold, and only a sold serial can be returned.

An unmatched lookup shows Serial not found below the lookup controls. Correct the serial and select Lookup again; the creation product, serial, notes, and required-forms draft stay available. Editing the lookup, selecting a table row, or changing the selected store prevents an older lookup response from replacing the current result. Permission, connection, and service failures retain the error-and-retry flow rather than appearing as no match.

Leaving Serialized Inventory discards pending lookup results, so returning with Back does not reopen an old detail or show an old lookup error. Close a detail with Close dialog or Escape. Lookup has no separate Cancel action; editing the serial, choosing a row, or leaving the page supersedes the pending result without changing inventory.

The portal recognizes no match only from HTTP 404 with code NOT_FOUND on the serial lookup request. This API code is also used for generic missing routes, so a missing lookup route returning that same envelope cannot currently be distinguished from an absent serial. Uncoded 404s, other error codes, and errors from other requests are not treated as no match.