This FAQ covers the controls I use to keep a cannabis ecommerce menu lined up with POS inventory, the stock actually on the shelf, and traceability records.
What is menu accuracy?
Menu accuracy means every sellable product shown online can be mapped to an active POS product, an available inventory package, and a physical location that can be picked. The menu is not the source of truth. It sits downstream of the POS catalog, package inventory, room assignments, reservations, and the sync process, and it is only as correct as those inputs.
Which systems have to reconcile?
At a minimum you compare four numbers: physical shelf count, state traceability package quantity, POS sellable quantity, and ecommerce menu quantity. If any one of them is off, you can take an online order you cannot fill cleanly.
physical_qty | traceability_qty | pos_sellable_qty | menu_qtyWhat causes menu drift?
Most of the time it comes back to one of these:
- A POS-to-menu sync job failed.
- A package split was not mapped to the ecommerce product.
- A room or location assignment is excluding sellable stock.
- A return created an inventory record the menu does not recognize.
- A reservation went stale.
- Duplicate SKUs, or a manual product edit that broke the catalog link.
What should the sync monitor show?
It needs the last successful sync timestamp, the failed sync timestamp, how many products were updated, how many were rejected and why, the affected location, and the affected package or product IDs. A generic "last updated" value does not prove that every product actually synced.
sync_started_at
sync_completed_at
sync_status
store_id
products_attempted
products_updated
products_failed
failure_reason
package_uid
product_idHow often should inventory be reconciled?
Watch sync status continuously. Run POS-to-menu quantity reconciliation daily, and add a same-day exception queue for high-volume stores. Only physically count the flagged exceptions, not the whole catalog every day. Once a week, do a root-cause review to classify the recurring errors and assign the system fixes.
What does the daily reconciliation file need?
The reconciliation file needs stable join keys and an explicit reason code for every mismatch. Package UID is the preferred join key when available. Product ID alone is weaker because one menu product can represent multiple packages, lots, or rooms.
store_id | product_id | package_uid | pos_qty | menu_qty | physical_qty | mismatch_reason | owner | resolved_atHow should mismatches be classified?
Use a small controlled vocabulary so the exception queue can be analyzed over time. Recommended reason codes include sync_latency, sync_failure, package_split_missing_map, duplicate_sku, room_assignment_error, reserved_inventory_stale, discontinued_product, return_record_unmapped, and physical_count_variance.
What metrics should be reviewed weekly?
Track mismatch count, mismatch rate, average age of unresolved exceptions, failed sync count, products affected by failed syncs, out-of-stock order rate, substitution rate, cancellation rate by reason, and the top recurring mismatch reasons. Reading them together tells you whether you have a catalog hygiene problem or an integration reliability problem, which usually get fixed in different places.
What is the minimum SOP?
- Check sync status before the menu opens for online orders.
- Export POS inventory and ecommerce menu inventory daily.
- Join records on package UID first, product ID second.
- Flag every non-zero quantity mismatch.
- Physically count flagged items and record the physical quantity.
- Assign a mismatch reason code and owner.
- Resolve the inventory, catalog, room, reservation, or sync issue.
- Review recurring reason codes weekly and remove the root cause.
What is the technical rule?
Show a product as orderable only when all of these hold: the product is active, the mapped package is sellable, the sellable quantity is greater than the reservation buffer, the location is eligible for ecommerce fulfillment, and the latest sync completed without a product-level failure.