Introduction to Fulfillment and Receipts
How BackOps records what actually showed up on an event, as opposed to what was planned or ordered, and how that record becomes the real cost of the show.
Fulfillment is the record of what actually showed up for an event. Procurement says what the show needs and orders say what you asked for; fulfillment says what arrived, who worked, for how long, and what that really cost.
Why Fulfillment Matters
The plan and the day rarely match. Eight of the ten radios arrive. The A1 the union sent is not the one you were told about, shows up late, and stays two hours past the call. A second console comes from a different rental house. Without a place to write this down, it lives on a clipboard or in someone's head, and the estimate you built in procurement never turns into an actual cost.
That gap matters most when the invoice lands. If nobody recorded what arrived, there is nothing to check the bill against, so "you charged me for gear that never came" and "you sent more than we asked for" both go unnoticed. Fulfillment gives you that record, and it keeps the number honest after the fact: when the invoice shows your on-site notes were wrong, you correct the notes rather than arguing with a correct bill.
How Fulfillment Works
The unit of fulfillment is a receipt: a dated record that something arrived. A receipt is created in one of two ways.
From an order. On an order's Fulfillment tab, Receive from order creates a receipt with one item for every line on the order, already carrying the quantity you ordered. You then adjust each item to match what actually came.
Standalone. On the event's Fulfillment page, Receive fulfillment records stock that arrived with no order behind it. Extra gear that nobody ordered is a normal case, not a gap, and its items do not need to point at a need.
Each item on a receipt is one resource type and a quantity. What else an item carries depends on how the type is tracked:
- Serialized types (people and individually identified units, such as truck GC-014) are filled slot by slot. Each slot holds a reservation: the specific person or unit filling it, with its own status and its own actual schedule.
- Pooled and expendable types (fifty radios, a pallet of gaffer tape) carry only a quantity, optionally drawn from an inventory resource.
flowchart LR
O["Order"] -->|"Receive from order"| R["Receipt"]
S["Receive fulfillment"] --> R
R --> I["Items"]
I -->|"Serialized"| V["Slots and reservations"]
I -->|"Pooled or expendable"| Q["Quantity"]
V --> A["Actual schedule"]
A --> F["Fulfilled cost"]
Q --> F
Receipts have no status of their own. One need can be satisfied across several receipts (thirty radios on one delivery, twenty on the next), and the event's Fulfillment page lists every receipt as a ledger with its order, received date, item count and quantity.
Two money questions sit on top of the record. Settlement says who pays for an item: "We absorb the cost" or "Vendor invoices us". True-up is an optional step for pooled and expendable items that records how much was actually used and whether the unused part is sunk or goes back to inventory. For serialized slots, the actual schedule is what drives cost: the same rules that priced the plan reprice the real hours, so overtime is computed rather than chosen.
All of this rolls up into the Fulfilled figure: what the show really cost, compared against what the vendor invoiced.
Recording Receipts
Receive from an order or standalone, fill serialized slots, and swap in a replacement for a no-show.
Settlement and True-Up
Say who pays for an item and record what was actually used.
Plan Versus Actual
Log the real on-site schedule for a slot and read the variance against the plan.
Reconciling Against Invoices
Compare the Fulfilled total with what the vendor invoiced, and decide which side to correct.