Inventory Transaction Log

1. WHAT YOU SEE — THE TRANSACTION LOG SCREEN

Inventory → Transactions shows a searchable, filterable list of every stock movement:

• Date, SKU/Item, Location, User (who performed it), Reference, and a Reconcile ID when the movement came from a physical count.
• Prev Qty → New Qty → Change, so you see exactly what the number was before and after, not just the delta in isolation.
• Type — every movement is tagged with a specific reason (a sale shipping vs. a purchase arriving vs. a manual adjustment vs. a transfer), so "Inbound Movements" and "Outbound Movements" totals stay meaningful instead of collapsing into a generic plus/minus pile.
• Filters for date range, location, SKU, entry user, reference, and reconcile ID let you answer a specific question fast — e.g. "show me everything that touched Location B's stock of this SKU last week."

2. WHAT HAPPENS BEHIND EVERY STOCK CHANGE (why you can trust the number)

Every module in the system — Sales, Purchasing, Production, Transfers, Reconciliation, Adjustments — funnels through one shared, central engine to actually change a stock number, and no screen is allowed to edit stock directly. That single choke point is what makes the following guarantees hold everywhere in the product, not just in some modules:

• No double-counting. If the same sale or receipt is accidentally submitted twice (a page refresh, a retried request), the engine recognizes it's already recorded that exact transaction and refuses to post it again.
• No lost updates under concurrent use. If two people (or two processes, like a website order and a warehouse scan) touch the same item's stock at literally the same moment, the engine locks that item's row before doing any math, so the second change waits for the first to finish instead of both silently overwriting each other. This matters more than it sounds like it should — it's the exact bug class behind "the system said 5 in stock but we actually sold 7" in cheaper inventory tools.
• All-or-nothing movements. A transaction with multiple line items either fully succeeds or fully rolls back — there's no state where half an order's stock impact posted and the rest silently didn't.
• Reversals are honest math, not guesswork. If a transaction needs to be undone (say, a shipped sales order gets deleted), the system doesn't try to "restore what it used to be" — other changes may have happened to that item since then, and blindly restoring an old number could wipe those out. Instead it posts the exact opposite of the original change as a new, dated entry. The original stays in history, just marked as reversed — nothing is ever deleted, so the trail stays complete.

3. MOVEMENT TYPES — WHY THE HISTORY ACTUALLY MEANS SOMETHING

Roughly 25 distinct movement types are used across the system, so the log tells a real story instead of an undifferentiated list of pluses and minuses. A few examples of what you'll see tagged in the log:

• A Purchase Order being approved reserves incoming stock before it physically arrives (so you can plan around it); the actual delivery is recorded separately, as the receipt.
• A Sales Order being placed holds stock aside; the shipment itself is a separate, later movement, so you can always tell the difference between "promised" and "gone."
• Production runs are tracked as raw materials consumed and finished goods completed — two distinct entries.
• Transfers between locations are recorded as a paired issue (leaving one warehouse) and receipt (arriving at another).
• Manual adjustments (damage, shrinkage, found stock) and physical reconciliations (a count correcting the number) are both clearly labeled and traceable back to the adjustment or count session that caused them.
• If you sync with an online storefront like Shopify, the storefront's reported count is trusted as authoritative for that channel and recorded as its own distinct movement type, so you can always tell "this changed because of a POS sale" apart from "this changed because Shopify said so."

4. HOW IT CONNECTS TO THE REST OF THE SYSTEM

• Every other stock-aware screen — Products, Reports, Reconciliation, Available-to-Promise on Sales Orders — reads numbers this ledger produced, so there's one consistent truth across the whole product.
• The Stock Movements / Stock Adjustment reports summarize this same ledger for management reporting, so a summary report and this raw log always agree — two views of the same data, not two separately maintained numbers.
• Reconciliation sessions (physical counts) write their corrections here too, tagged with the reconcile ID, so a count that changed a number is always traceable back to exactly which count session did it.

5. WHY IT SCALES FROM SMB TO ENTERPRISE

Quick Reference

  Transaction log .......................... Inventory > Transactions
  Filter by item/location/date ............. Transaction log > filter bar
  Related: Stock Adjustments ............... Inventory > Adjustments
  Related: Stock Count & Reconciliation .... Inventory > Reconciliation