Documentation

# Inventory

Inventory in the platform tracks physical stock movement and on-hand balances. The current workflow is transfer-first for finished beer inventory.

# Inventory model overview

  • Inventory Items usually represent finished beer lots by beer + format + date code.
  • Tracked casks represent one vessel use per inventory item so each cask can follow its own lifecycle.
  • Returned goods are recorded as separate quarantined inventory, not merged back into saleable lots by default.
  • Transfers represent movement requests and warehouse fulfillment actions.
  • Orders represent commercial records (sales/purchase intent), while linked transfers represent inventory execution.

# Finished beer lifecycle

  1. Packaging creates inventory items in the packaging facility/location.
  2. A transfer is requested (internal move, order fulfillment, buyback, etc.).
  3. Warehouse allocation selects specific inventory items/date codes.
  4. Transfer completion records movement transactions and updates on-hand by facility/location.

# Goods status

Beer On Hand defaults to Finished Goods, which shows inventory where is_finished_goods is not false. This keeps conditioning casks and quarantined returns out of normal finished inventory views.

Use the Goods Status filter to review:

  • Finished Goods: normal saleable inventory.
  • Unfinished Goods: inventory that is visible operationally but not ready for finished-goods reporting, such as conditioning casks or quarantined returns.
  • All Goods: finished and unfinished inventory together, when available.

# Tracked casks

Casks are tracked as one inventory item per vessel use.

  1. Filling a cask creates a visible inventory item for that cask with quantity 1.
  2. The filled cask starts as unfinished goods while conditioning or finishing.
  3. Marking the vessel use Ready to Tap promotes only that cask to finished goods.
  4. Transfers allocate casks by cask number instead of date code.
  5. Transfer completion updates inventory location and keeps the vessel-use movement history aligned.

Use transfers for cask movement between facilities or locations. The vessel record tracks the vessel lifecycle and contents, but the transfer remains the operational inventory movement record.

# Taproom POS consumption workflow

Taproom POS days convert sales data into inventory consumption movements. The POS day is used to review product mapping and inventory availability, while the linked transfer remains the operational record for allocation, completion, and inventory impact.

Auto POS depletion is configured per taproom facility in Settings -> Facility Management -> Taproom Operations. The taproom must be linked to an active Square POS location in Settings -> Integrations before auto depletion can be enabled.

  1. POS data is loaded for a taproom day.
  2. POS items are mapped to beer + package format SKUs.
  3. The system builds or rebuilds a linked taproom consumption movement.
  4. The movement is allocated and completed from the source location configured for that taproom.
  5. Inventory impact is applied from the completed movement.

# Kegs on tap

Draft and cask consumption can use a virtual "keg on tap" record when beer has already been moved into the taproom for service. POS categories such as Draft Beer and Cask Beer can use this service-lot flow.

  • Already on tap means the POS day consumed from an existing keg on tap.
  • Put on tap means the POS day opened a new keg on tap from source inventory.
  • The Qty Available column shows source inventory plus a green keg-on-tap chip when existing tapped beer is available.
  • The keg-on-tap tooltip shows before, consumed, and after quantities.

If the mapped/default draft format is exhausted but another keg format is available, the POS day highlights the row as Review format and shows a Switch format warning. Edit the row mapping and rebuild the movement so consumption can use the available keg format and preserve correct beer-volume depletion.

# Inventory exceptions

When inventory is missing or insufficient but the sales record is valid, record an inventory exception instead of deleting or skipping the inventory demand.

Inventory exception types tell the system whether follow-up is needed:

  • Pending inventory impact: inventory is expected to be recorded later. Use this when the inventory demand is real, but the package log or future package event has not created the lot yet. The system tracks an inventory obligation and can automatically deduct from matching inventory after the lot is created.
  • Inventory reconciliation required: the discrepancy is documented, but a manager still needs to review or resolve it manually. This keeps the item visible in inventory reconciliation instead of treating it as closed documentation.
  • Other documented discrepancy: the discrepancy is documented and no future reconciliation is expected. A written explanation is required.
  • Historical opening inventory gap: legacy or catch-up-only inventory that was physically available but absent from opening inventory records. Use this for historical documentation only; it does not create a follow-up reconciliation item.

The exception picker shows context for each type:

  • Auto reconciliation means the system will watch for matching inventory and apply the pending impact when possible.
  • Manual reconciliation means the exception should stay visible for follow-up in the inventory reconciliation workflow.
  • No reconciliation means the exception is accepted documentation and should not appear as an active follow-up item.

For taproom catch-up, the POS day provides a bulk close-with-exceptions action. The accepted exceptions are written to the linked movement so the transfer remains the plan of record.

# Pending inventory impact

Pending inventory impact is designed for timing gaps. Common examples:

  • A presale or POS day happened before the package log was entered.
  • A package log is known to be coming, but the transfer or taproom consumption movement needs to stay visible now.
  • A future package event will create inventory within the normal matching window.

When selecting this type, choose why inventory is deferred:

  • Package log pending: the beer is already packaged, but the package log has not been entered yet. Enter the expected date code or keg fill date. Matching is exact for that date.
  • Not yet packaged / preorder: the beer will be packaged later. The system looks for matching lots created near the movement impact date.

Pending inventory impact may show as Waiting for inventory in transfer follow-up while the system waits for a matching lot. If the matching window expires, the package log is overdue, or automatic resolution fails, it changes to Needs review.

From Inventory -> Shortages, use the reconciliation action to deduct a pending quantity from a selected inventory lot. This resolves only the pending exception quantity; it does not reallocate other movement lines.

# Inventory reconciliation required

Use Inventory reconciliation required when a discrepancy is real and documented, but should not be treated as resolved. This is useful for catch-up periods where the source event is in the past and you want the exception to remain visible until an audit, count, or manager review closes it.

This type requires an explanation and appears as follow-up in inventory reconciliation. It does not expect the system to find a future package log automatically.

# Returned inventory and quarantine

Most credit memos are financial-only and do not affect inventory. When returned beer is physically received, the credit memo can be marked as an inventory return and linked to an inbound customer return transfer.

Returned inventory is received into the selected facility/location as quarantined, non-saleable inventory. It is excluded from default Beer On Hand and normal allocation until it is manually reviewed and released, disposed, or adjusted.

The system records quarantine status, but physical marking remains an operational responsibility. Tag returned beer or place it in a clearly marked area so the physical stock matches the electronic record.

# Active inventory behavior

The system supports querying inventory "active as of date." Active rows use a far-future inactive date sentinel (9999-12-31) until inventory is fully depleted.

# Where to work with inventory

  • Inventory -> Transfers for movement requests and allocations
  • Inventory -> Beer On Hand for current balances and format-level inventory views
  • Taprooms for POS day mapping, availability review, keg-on-tap decisions, and taproom consumption movement rebuilds
  • Batch Packaging for creation of new finished inventory

← Transfers →