Bar–Warehouse Link

Every time a player places a bar order in IZI, the system automatically creates a warehouse deduction — no action required from staff. IZI uses the FIFO method (first in, first out): the oldest batch with available stock is consumed first, and its purchase price is captured as an immutable cost snapshot on the order line. This snapshot powers bar margin calculations in analytics. If an order is later cancelled, the admin chooses whether to return the item to stock or log it as a write-off. The entire chain — from placement to delivery and cancellation — is visible in the Warehouse → Operation History section and can be audited at any time.

Order lifecycle and warehouse operations

The clearest way to understand the bar–warehouse connection is to follow a single order from start to finish.

Step 1 — Order placement creates a SALE operation

When a player adds an item to their order and confirms it, IZI immediately creates a SALE warehouse operation. This happens before staff see the order on their screen. At this moment:

• The item’s balance decreases by the ordered quantity.
• IZI selects FIFO batches: the oldest batches with a non-zero balance are consumed first.
• The purchase price from the selected batch is written to the cost field of the order line — this is a snapshot that will not change.
• If there is not enough stock, the order is blocked and the item cannot be added.

Stock decreases at placement, not at delivery. If two players simultaneously try to order the last unit of an item, only the first order goes through — the second player simply cannot add that item.

Step 2 — Staff manage order status

After placement, the order appears in the Bar Orders section of the CRM. Staff see the list of items and move the order through statuses:

Action	CRM button	Order status
Accept the order	”Take to work”	PENDING → PREPARING
Mark as ready	”Mark as ready”	PREPARING → PREPARED
Hand to the player	”Delivered”	PREPARED → DELIVERED

These transitions update the order status only — they do not change warehouse balances, because the SALE was already locked in at placement.

Step 3 — Cancellation: RETURN or write-off

If a line item must be cancelled (the physical stock ran out, the player changed their mind, or the item was damaged), the admin opens the line item card and chooses:

• Return — the item is physically back in stock. IZI creates a RETURN operation that restores the corresponding FIFO batch. The balance increases.
• Write-off — the item was already consumed or spoiled. No stock is restored. A write-off operation is logged. The admin can select a reason: Broken, Expired, Damaged, Technical write-off, or Other.

When a line item is cancelled, any payment for it is refunded to the player’s balance — this is a separate process handled independently from the warehouse.

How FIFO selects batches

The FIFO (first in, first out) method works as a queue of batches sorted by receipt date. On each order IZI:

1. Finds all batches of the ordered item at that club where the balance is greater than zero.
2. Takes the oldest batch and deducts the required quantity from it.
3. If one batch does not cover the full quantity, it moves to the next batch by date.
4. Records the batch reference (sourceReceiptItemId) on each SALE operation line.

When a quantity spans multiple batches, the cost used for analytics is the weighted average across all batches involved.

Accuracy of margin reports depends directly on how carefully purchase prices are entered at each goods receipt. A zero or approximate cost in a receipt produces an incorrect margin in analytics.

What the operation history shows

The Warehouse → Operation History section (requires the WAREHOUSE_READ permission) displays all warehouse events as a chronological feed. For each operation you can see:

• Type: RECEIPT (goods received), SALE (bar sale), RETURN (cancelled and returned), ADJUSTMENT_IN / ADJUSTMENT_OUT (manual correction)
• Date and time
• Line items with quantity, stock before, and stock after (stockBefore / stockAfter)
• Cost from the FIFO batch (unitCost)
• Who or what created the operation (for SALE — a link to the bar order)

Filtering by type “Sale” lets you quickly verify that all bar sales during a shift were correctly reflected in stock.

Required permissions

Permission	What it allows
WAREHOUSE_READ	View operation history and current stock balances
WAREHOUSE_RECEIPT	Create goods receipt operations (RECEIPT)
WAREHOUSE_ADJUSTMENT	Create manual corrections (ADJUSTMENT_IN / ADJUSTMENT_OUT)
MANAGE_BAR_ORDERS	Manage bar order statuses (accept, mark ready, deliver, cancel)

Bar sales (SALE) are created automatically by the system — no separate permission is required to trigger them.

Common situations and how to read them in IZI

”Why didn’t the balance change after I pressed Delivered?”

Because the SALE was already created at order placement. By the time you pressed “Delivered”, the balance had long since been updated. If you see a discrepancy, check the operation history — there may have been a manual adjustment or a RETURN from a cancellation.

”The margin on an item looks unusually high”

The most likely explanation is that an older batch with a lower purchase price is being consumed. This is expected FIFO behavior. Once the old batch is exhausted and the next batch (with a higher cost) kicks in, the margin will adjust. For a full breakdown, see the COGS and bar margin report.

”After stocktaking, ADJUSTMENT operations appeared”

This is correct behavior. Stocktaking in IZI creates ADJUSTMENT_IN or ADJUSTMENT_OUT operations for every item where the physical count differs from the system balance. These operations are independent of bar orders.

See also

• FIFO: how the deduction method works — how IZI selects batches and calculates cost
• Goods receipt — receiving stock, entering purchase prices, and managing receipts
• Inventory procedure — reconciling physical counts with system balances
• COGS and bar margin report — reading the financial result of the bar using FIFO data