# Transfers
Transfers are the operational record for inventory movement. They are used for internal movements and for warehouse fulfillment linked to sales or buyback workflows.
# Why transfers
- Separate warehouse execution from sales/order data entry
- Allocate by real inventory item and date code
- Keep inventory updates auditable and reversible
# Transfer statuses
- Requested
- Request details can be edited
- No inventory movement is applied yet
- Allocating
- Warehouse selects inventory items to fulfill requested quantities
- Partial allocation is allowed
- Completed
- Fulfillment is finalized
- Inventory movement is fully applied
- Canceled
- Transfer is retained for audit history
- Inventory impact is removed and not re-applied
# Common transfer types
- Internal: facility/location to facility/location
- Order Pickup / Order Delivery: outbound fulfillment linked to sales
- Distributor Buyback: inbound movement from external source
- Customer Return: inbound movement for credit memos explicitly marked as physical inventory returns
# Requested vs allocated items
- Requested items describe what was asked for.
- Allocated items connect those requests to specific inventory item IDs/date codes.
- In completed mode, requested and fulfilled values are compared and highlighted if mismatched.
For tracked casks, allocation uses cask numbers instead of date codes. The allocated item stores the inventory item and vessel-use metadata so the transfer can move the cask inventory and keep vessel tracking aligned.
# Cask transfers
Cask movement between facilities or locations should be completed through transfers. The vessel record tracks lifecycle and contents, but the transfer is the inventory movement record.
When allocating a cask line:
- Select from available cask numbers at the source facility/location.
- Confirm the requested and selected casks match.
- Complete the transfer to update inventory location and append the matching vessel-use movement history.
Completed movement views show cask numbers for cask allocations rather than date-code summaries.
# Customer return transfers
Customer return transfers are created from credit memos marked as Inventory return. They are inbound transfers from the customer/distributor into the selected receiving facility and location.
Completing a customer return transfer creates separate quarantined, non-saleable inventory. Returned beer is not merged back into the original saleable lot and is excluded from default finished-goods views and normal allocation until it is manually reviewed.
Financial-only credit memos should not create transfers. If an old generated transfer exists for a financial-only credit memo and it has not been completed, it can be canceled or cleared during cleanup. Completed historical transfers should be reviewed rather than silently deleted.
# Inventory exceptions
Inventory exceptions explain why a requested line was not fully fulfilled from tracked inventory. They are stored on the transfer because the transfer is the operational record for inventory execution.
Use an exception when demand is valid but tracked inventory is missing or insufficient. Examples include catch-up periods where opening inventory was incomplete, or rare cases that require a written explanation.
Available exception types:
- Pending inventory impact: use when a future or late-entered package log is expected to create the inventory. This creates an inventory obligation and can be resolved automatically when matching inventory appears.
- Inventory reconciliation required: use when the discrepancy is documented but still needs manual follow-up, audit review, or later correction.
- Other documented discrepancy: use when the discrepancy is documented and no future reconciliation is expected. A note is required.
- Historical opening inventory gap: use only for legacy or catch-up inventory that was physically available but missing from historical opening inventory. This is documentation only and does not create active reconciliation follow-up.
In allocation mode, under-allocated lines can be marked with an item-level exception. If a line is later fully allocated, the stale exception is removed when the movement is saved.
Taproom POS days can pre-seed exceptions in bulk, but the same exceptions can be reviewed and edited from the linked movement.
# Exception follow-up states
The Inventory Follow-up column in transfer lists summarizes whether a movement still needs attention:
- Waiting for inventory: a pending inventory impact is open and the system is waiting for a matching package log or inventory lot.
- Needs review: manual reconciliation is required, automatic reconciliation failed, or a pending obligation is overdue.
- Documented: accepted exceptions remain on the transfer, but they do not require active reconciliation.
Historical opening inventory gaps are hidden from follow-up because they are catch-up documentation, not current work.
# Resolving pending inventory impact
Pending inventory impact can resolve in two ways:
- Automatic reconciliation: when matching packaged inventory is created, the system deducts the pending quantity from the matching lot.
- Manual reconciliation: from Inventory -> Shortages, choose the reconciliation action and select the lot and impact date to deduct only the pending quantity.
Manual reconciliation is useful when the package log or inventory lot already exists but was created before the obligation was recorded, or when automatic matching needs operator review.
Resolving a pending impact does not reallocate unrelated movement lines. Other allocations on the transfer remain unchanged.
# Editing and correction workflow
- Use Re-open allocation to make corrections after completion.
- Save progress in allocating mode for partial work.
- If a line request changes, allocation can be adjusted at line level.
- Use item-level inventory exceptions when a requested quantity should remain visible but cannot be allocated from tracked inventory.
- Canceling a transfer removes inventory impact while preserving the transfer record.
# Shipping documentation
Shipping docs can include BOL PDF handling, photos, and signatures in a collapsible documentation section on the transfer record.
# Best practices
- Complete request edits before final fulfillment when possible.
- Allocate specific inventory/date code intentionally for traceability.
- Use cancellation instead of hard deletion when the movement should not proceed.