RollCall docs ↗ Dashboard

Coverage & readiness

Why a venue has no comparable night

For a venue with a sales feed but no completed night yet, which of four honest reasons applies — so a feed that keeps dropping mid-night is never shown as a venue that simply hasn’t traded.

Group · Sales
Every source on this page was found and then independently re-verified by a separate check that fetched it. 1 verified reference below — each links straight to the original so you can confirm it yourself.

What it is

Why a venue has no comparable night is not a number — it is an honest label. When the sales comparison above has no eligible completed night to stand on, this says which of a few plain reasons is the cause, so a feed that keeps dropping mid-night is never quietly shown as a venue that simply hasn't traded.

It reads only for venues whose eligible-night search came back empty, and it reports one of a small set of states: no night recorded yet, tonight still in progress, a finished night still finalising, a finished night confirmed incomplete (with the reason named), an older night from before this check existed, or — if the check itself cannot be read — status unavailable. It is a reason, never a reading of sales.

How to use it at your venue

Operators tend to read each state as a diagnostic, not a verdict. No night recorded or status unavailable points at a capture gap to look into — a feed not yet connected, an integration that lapsed — rather than a claim the room did no business; the discipline of classifying why a data point is absent before letting its absence mean anything is the foundational rule of missing-data statistics.[1] In progress and finalising are usually read as "wait" — a partly-settled night is not yet the equal of a fully closed one.

A grounded use of incomplete is to treat that night as weighted-down or set-aside evidence when you look at a trend, rather than lining it up one-to-one against confirmed nights — the named reason tells you how much of the night the feed actually covered. None of this dictates a dashboard action; how cautious to be with partial evidence stays the operator's call. The one thing the state is not for is inferring the missing number: it tells you why there is no comparison, not what the comparison would have said.

How to read it

Read the state as the cause, then decide what it warrants. Status unavailable is deliberately distinct from no night recorded — the first means the check could not run, the second means the check ran and found nothing. They are never collapsed, because "no night exists" is a claim only a successful check can support. When an incomplete state names a reason, that reason is the recorded completeness verdict for the night, not a guess about the feed.

What it doesn't mean

⚠ What it can't tell you

It says why no comparison exists — it does not say what that venue earned. Nothing here is a measurement of sales. It cannot diagnose why a feed dropped, only that it did and when. It is never compared to another venue, and it never falls back to "no night exists" when the check cannot be read: a row that cannot be verified says exactly that — "completed-night status unavailable" — rather than guessing a reason. No reading is a state, not a zero.

How it's calculated

Entirely client-side, over night documents already loaded for the venue — no scans, no server call, no arithmetic. When the sales card finds no eligible completed night for a venue, it inspects that venue's two most recent night records and reads their status fields to decide which reason applies. Nothing is summed and nothing is estimated; the output is one of the fixed states. If those records cannot be read at all, the state is reported as unavailable rather than inferred.

The exact method
state = rcSalesEvidence(≤2 most-recent night docs) no night doc present................................ none latest night not complete.......................... in_progress complete but not yet settled/confirmed............. finalising complete + completenessFinal says incomplete....... incomplete (+ incompleteReason) older night predating this check................... legacy docs unreadable.................................... unknown → "status unavailable"

Computed by rcSalesEvidence(docs) — a pure function over the ≤2 most-recent night documents, run only for venues whose eligible-night search returned empty. Inputs are the venue's own night-document fields: settled, complete, completenessFinal, incompleteReason, businessDate. Owner-facing state strings render (e.g. "Tonight in progress — no completed night yet", "Completed-night status unavailable — open Sales to check"). No door scans, no POS arithmetic. Schema version evidence.v1. The five/six state names are RollCall's own engineering design, not a literature taxonomy.

The research behind it

"No data" and "zero" are not the same thing. If RollCall doesn't yet have enough evidence about a night — because it hasn't happened, hasn't finished, hasn't been confirmed, or the data pipeline hasn't caught up — it says so honestly instead of quietly counting that night as dead. That's the same discipline statisticians use before drawing conclusions from missing data, and the same discipline revenue managers use before reading true demand off of booking counts that were capped by capacity or cut off mid-night: figure out why the data is absent before you let its absence say anything.

  1. Inference and Missing Data ✓ verified
    Rubin, Donald B. · Biometrika, Vol. 63, No. 3 · 1976
    Read the source ↗

Confidence & caveats

The state is a direct read of the recorded status fields, so it is exact about what those fields say — but "exact" here means faithful, not diagnostic. It reports the completeness verdict; it cannot explain the underlying cause of a dropped feed. The unknown / status-unavailable case is a deliberate honesty floor: when the check cannot run, the row states that plainly rather than defaulting to "no night," because absence of a reading is a state, never a zero. Nothing on this row is a sales figure, and nothing is ever compared across venues.