All articles

Utilities

Quantity Reconciliation

Compares each inventory item's stored In Stock / On Memo / Carat values to what they should be based on every invoice, memo, return, scrap, and quantity adjustment in history. Reports any item whose stored quantities disagree with the line-item history so you can investigate or apply a one-click correction.

JewelTrak tracks In Stock and On Memo quantities (and carats, for stones) on every inventory item. Every action that moves inventory — writing an invoice, issuing a memo, processing a vendor return, scrapping, recording a count adjustment — updates those quantities.

The Quantity Reconciliation page at Utilities → Quantity Reconciliation recomputes those quantities from scratch by walking through every transaction on each item, and shows you any item whose stored quantity doesn’t match. It’s an integrity-check / safety net.

When to run it

  • Monthly as part of period-close, as a hygiene check
  • After a known-disruptive event — database restore, importing a new tenant, a code change that touched inventory flows
  • Investigating a discrepancy — if a physical count doesn’t match the In Stock value and you can’t find the cause from the item’s Transaction History

What it does

For each inventory item, the page computes the expected values from history:

  • In stock = quantity purchased + quantity adjustments − invoiced − on memo (open) − returned to vendor − scrapped
  • Carats for stones, the same way using carat weights
  • On memo computed from open memo lines (issued but not yet returned or invoiced)

Each item’s stored value is compared. Differences are listed.

Investigating a discrepancy

For any flagged row, click the small history icon to open the Transaction History drawer. It shows:

  • The full calculation (every contributing number, with the running result)
  • Every contributing invoice line, memo line, vendor return, scrap entry, and quantity adjustment, with links back to the source records

Whichever leg of the calculation produces an unexpected number is the one to investigate. Common patterns:

  • Pre-import items where the legacy system used a different quantity-tracking mechanism that didn’t map cleanly to the new schema
  • A flow that updated the stored value but didn’t create a matching transaction record (or vice versa)
  • A transaction that was deleted directly in the database, bypassing the audited delete

Applying corrections

Two ways:

  • Apply All Fixes — overwrites every flagged item’s stored quantity with the value computed from history. Use when you trust the line-item history more than the stored quantity (typical after a fresh import).
  • Apply Selected — tick the checkbox on individual rows, then Apply Selected. Use when you’ve spot-checked the rows and want to fix just those.

Each correction is recorded in the Audit Log with the before-and-after values, so you can see exactly what was changed and revert any individual fix if needed.

Tips

  • Run this against your production data before commercial go-live to catch any legacy data carryover.
  • Items marked Returned or Scrapped are no longer active inventory, so the reconciler trusts their stored quantities and won’t flag them as discrepancies even if the history doesn’t add up — there’s no useful action to take on a retired row.
  • The reconciler is read-only by default — you have to confirm before any fix is written. Safe to run as an audit anytime.
  • If a recently-active item shows a discrepancy (not pre-import data), that’s a signal a flow somewhere isn’t pairing its quantity update with the matching transaction record — worth investigating before applying the fix.