BigQuery field reference

This reference inventories 414 advertised fields in 26 customer views, observed in a staging customer dataset on 2026-10-05. It is a dated example, not a guarantee that your environment exposes the same columns at the same time. Always inspect your own dataset with INFORMATION_SCHEMA.COLUMNS (query in the BigQuery guide). Column descriptions are based on the documented reporting contract or source model where known; “operational/source-specific” explicitly means the field has no promised customer reporting semantics, not that its name should be interpreted as a contract.

October 8, 2026 update: The checked development and staging customer datasets now each advertise 429 fields in 26 views, with matching names and types. Relative to the staging inventory below, the following fields are newly advertised in both datasets:

printer_jobs.rendered_content (BYTES) was removed from both checked customer views, while remaining in the upstream operational table; the October 5 printer_jobs table below is a historical snapshot and should not be used as a current SELECT * schema. Dev-only purchases.processed_by_retailer_user_id, purchase_line_items.pre_discount_value_cents, and kitchen_dispatch_items.is_surplus were also removed from dev customer views for parity; use purchase_line_items.is_surplus for the sale-line flag. These changes are detailed in the changelog. Other customer datasets, especially production, must be verified separately.

BigQuery view metadata reports nullable columns even when a source column has a database default or NOT NULL constraint. Do not derive source constraints from this inventory. Types and names are those advertised by the customer views, not the upstream PostgreSQL schema. All tables below are read-only views scoped to the customer; joins and money rules are in the guide.

Planned, not part of the 414-field inventory: Price clusters are defined in the source model but are not verified as customer views. These source fields explain the intended customer-scoped tables and relationships; they are not advertised BigQuery column types or availability promises:

In the planned customer views, the cluster owner must be in location_members; assignment/application locations must additionally be in location_members. Check actual BigQuery types and row availability after replication and view provisioning. See the changelog.

• cost_centers
• discounts
• item_accounts
• item_accounts_map
• items
• kitchen_dispatch_events
• kitchen_dispatch_item_modifications
• kitchen_dispatch_items
• kitchen_dispatches
• location_members
• locations
• prepaid_types
• printer_jobs
• purchase_applied_fees
• purchase_line_items
• purchase_payment_method
• purchase_refund_line_items
• purchase_refund_vats
• purchase_refunds
• purchase_vats
• purchases
• retailer_user_actions
• tab_events
• tab_members
• tabs
• variants

cost_centers

Cost-center definitions assigned to locations and used for reporting or accounting.

discounts

Current location-owned discount/voucher definitions, including gift-card configurations; not a per-purchase redemption ledger.

item_accounts

Accounting account definitions used for catalogue mapping.

item_accounts_map

Links catalogue items to accounting accounts.

items

Current catalogue items; not historical purchase-line snapshots.

kitchen_dispatch_events

Events recorded against kitchen dispatches.

kitchen_dispatch_item_modifications

Variant/modification links recorded against kitchen lines.

kitchen_dispatch_items

Kitchen preparation/order lines; not equivalent to completed sales.

Historical metadata exception (staging, 2026-09-28): zero_ticket was queryable as BOOL, but an older customer view's stored schema did not advertise it. It is now advertised as BOOL in the checked development and staging customer views as of October 8, 2026. Check other datasets independently.

kitchen_dispatches

Kitchen orders/dispatches, which can be separate from payments.

location_members

Location IDs included in this customer dataset's access scope.

locations

Limited, customer-scoped location details.

prepaid_types

Configured prepaid payment types, labels, and reporting codes.

printer_jobs

Operational print jobs; rendered content can be binary.

purchase_applied_fees

Commercial/payment fees associated with a purchase, not sold articles.

purchase_line_items

Sale/payment lines belonging to purchases.

purchase_payment_method

Purchase-level payment method details and later provider enrichment.

purchase_refund_line_items

Refund allocations to original purchase lines; monetary amounts do not establish returned quantities.

Historical rollout note: quantity_cents became advertised as INT64 in a checked development customer view on October 5, 2026. As of October 8 it is also advertised in the checked staging customer view; no production customer-view availability is claimed. See the changelog.

purchase_refund_vats

Refunded VAT amounts grouped by VAT rate.

purchase_refunds

Refund attempts/results referring to original purchases.

purchase_vats

VAT totals grouped by rate for each purchase.

purchases

One purchase/payment record; the primary sales reporting grain.

retailer_user_actions

Operational audit actions by retailer users; not sales or payments.

tab_events

State/events recorded against a tab.

tab_members

Participation/payment identity within a tab.

tabs

Ordering/payment container; a tab can have multiple purchases.

variants

Current variant/add-on catalogue definitions; not historical sale snapshots.

Planned: tab ledger (not in this view inventory)

The tab ledger records what a tab owes, every discount by name and source, and how each payment and refund is spread over the tab's lines. It is defined in the source model but not verified as customer views. The fields below are PostgreSQL source fields, not advertised BigQuery types or availability promises. Every ledger identifier is a time-ordered UUID (version 7). Every ledger table is append-only: a correction is a new row with reverses_id pointing at the row it cancels, never an edit. A payment's discharge is recorded once, from the purchase's lines when it turns confirmed; it is reversed only if the purchase leaves confirmed or its payer moves to another tab.

Existing views gain tabs.ledger_account_id, purchases.discharge_id, and purchase_refunds.discharge_id (UUID); all three are NULL outside the ledger. Only tabs created after the ledger is enabled get an account. When the ledger cannot record a change, the change still goes through, the tab leaves the ledger (ledger_account_id becomes NULL) and its account stops growing. A discount given before payment lowers the kitchen line's price (the ledger writes it). Every discount, given before or at payment, is in applied_total_discount_amount_cents of the purchase lines that pay for its items, whose total_amount_cents is the price before every discount. Every discount is its own applied discount with its own name, and a purchase's lines are derived from what the ledger planned for that payment. Integration-specific discount detail and the ledger's internal pricing and payment-coverage tables are not planned as customer views. Ledger rows carry no location_id: planned views scope them through the owning tab's location_id in location_members. Existing purchase, kitchen and tab columns keep their meaning; purchase lines say price, discount and net, as a voucher's line does. Check the changelog for rollout status; these tables are not included in the counts above.