BigQuery changelog

This log covers the customer-scoped BigQuery views, not the REST API changelog. An entry describes an observed schema or a verified source-model change; a source migration date is not a promise that every customer view was refreshed on that date. Check your own environment's INFORMATION_SCHEMA.COLUMNS before depending on a new field. New nullable fields and view changes can appear at different times in development, staging, and production. The BigQuery guide explains how to export safely; the field reference records a dated example of the available views.

2026-10-26 — Ledger tabs: purchase lines say price, discount and net (source code, not deployed)

• Status: a source-model and code change under review, not applied in any environment.
• Changed, purchase_line_items on ledger tabs (tabs.ledger_account_id set):
  • total_amount_cents: the price of the units the payment covers before every discount (was: after discounts given before payment).
  • applied_total_discount_amount_cents: every discount on those units for the payment, given before payment (staff discounts, price changes, loyalty-integration discounts, vouchers on the order) or at it (was: the payment-time discount only).
  • pre_discount_vat_amount_cents: the VAT of total_amount_cents.
• Unchanged: total_amount_cents - applied_total_discount_amount_cents, final_amount_cents, the VAT columns, purchase_vats, purchase amounts, refunds, and every line outside the ledger.
• Action: on ledger tabs, read gross sales as SUM(total_amount_cents) and discounts as SUM(applied_total_discount_amount_cents). Ledger lines written before this release keep the earlier meaning. This replaces the purchase-line points of the 2026-10-22 entry.

2026-10-22 — Tab ledger: what the release changes in your data (source code, not deployed)

• Status: a source-model and code change under review. It is not applied in development, staging, or production, and no customer view of the new tables exists yet. This entry describes the release as it will ship and replaces the tab-ledger and voucher entries of October 19–21. A later entry will record each environment, and each customer view once it is checked.
• Which tabs: a location turns the tab ledger on through a location feature, location by location. Only tabs created after that get a ledger account. Tabs that already exist, open or closed, are not backfilled and finish as before. Everything below marked "ledger tabs" applies only to tabs with a ledger account.
• New nullable UUID columns on existing views:
  • tabs.ledger_account_id: the tab's ledger account.
  • purchases.discharge_id: set when a payment on a ledger tab is confirmed.
  • purchase_refunds.discharge_id: set when a refund on a ledger tab is confirmed.
  • Setting discharge_id also advances updated_at.
  • A payment's discharge_id changes again only if the purchase leaves confirmed, or its payer moves to another tab.
• A tab can leave the ledger. When the ledger cannot record a change, the change still goes through and the tab continues on the previous calculation.
  • tabs.ledger_account_id becomes NULL, and that account's ledger rows stop growing.
  • Later payments have a NULL discharge_id.
  • Treat a ledger account as complete only while a tab still points at it.
• Planned tables (not in any customer view yet; fields in the field reference):
  • The ledger: ledger_accounts, ledger_charges, item_charges, fee_charges, charge_tax_rates, ledger_reductions, ledger_discharges, ledger_allocations.
  • Applied discounts: account_discounts (name, kind, value) and discount_reductions.
  • The sources of those discounts: manual_discounts (given by staff) and voucher_discounts (one discount per redeemed Karma voucher).
  • tab_purchase_discounts: the payment attempt each discount came with, and its scope. payment means bound to that payment, in its lines' applied_total_discount_amount_cents. order means given on the items before payment.
  • Every table is append-only: a correction is a new row with reverses_id, never an edit.
  • Identifiers are time-ordered UUIDs (version 7).
  • The tables have no location_id; the planned views scope them through the owning tab.
  • account_discounts holds applied discounts and is unrelated to the discounts definitions view.
  • Integration-specific discount detail, partner redemption records, and the ledger's internal planning and failure tables are not planned as customer views.
• Purchase lines on ledger tabs. The meaning of every column is unchanged, and the paid line is still total_amount_cents - applied_total_discount_amount_cents. What is new:
  • No discount entries in applied_modifications. Vouchers and other discounts no longer appear there with a negative priceAdjustmentCents. A discount's name and source are in the ledger tables.
  • Amount payments (a guest paying part of a tab by amount) are type = 'product' lines carrying the share's quantity_cents, which can be fractional. They are not type = 'amount' lines.
  • Line VAT: total_vat_amount_cents is the VAT of the line's net total. It can differ from per-unit VAT times quantity by at most one minor unit per unit. pre_discount_vat_amount_cents is always written. purchase_vats is the sum of the lines' VAT per rate.
• Discounts given before payment are already in the kitchen line's price and in the purchase line's total_amount_cents, as before. On ledger tabs this covers staff discounts, price changes and loyalty-integration discounts. The ledger writes kitchen_dispatch_items.price, discount and allocated_*. Nothing is written to kitchen_dispatch_items.discount_details.
• Tab columns on ledger tabs:
  • paid_amount_cents and paid_amount are payments net of refunds, plus the discounts bound to those payments.
  • A purchase that leaves confirmed lowers paid at once.
  • remaining_balance_cents is total_amount_cents - paid_amount_cents, never below zero.
  • Report sales from purchases and refunds, not from tab columns.
• Marketplace orders, on every tab:
  • The intake writes the prepaid purchase's lines before confirming it, so the tab shows the purchase amount as paid from intake: goods plus booked marketplace fee lines, minus the merchant-funded discount. Previously it stayed 0 until a later update.
  • Fee lines are not part of the tab total, so paid can exceed total_amount_cents.
  • A repeated delivery of the same external order creates nothing.
  • On ledger tabs, the merchant-funded discount is applied_total_discount_amount_cents on the food lines, with no negative marketplace_discount line. Tabs outside the ledger keep the negative line.
  • Some marketplace purchases stay pending for a moment between intake and confirmation.
• Value vouchers of a POS integration are a payment of their own, on every tab:
  • A voucher that pays a whole order is one purchase with a new provider value in purchases.psp.
  • A voucher that pays part makes two purchases on the tab: the voucher's, then the rest paid by the guest's method.
  • Neither purchase's lines carry the voucher as a discount.
  • Promotion codes of that integration are applied discounts, as Karma vouchers are.
• discounts view:
  • Stored value is a gift card, never a voucher. A source migration sets enabled = false on every enabled GIFT_CARD voucher that is not a template.
  • New vouchers hold no balance (balance_mode = 'NONE'), and remaining_balance_cents is no longer deducted on redemption. Existing balances stay as recorded.
  • Gift-card templates are unchanged.
• Voucher rules at payment, on every payment path:
  • Loyalty enrollment and tier are checked against the paying guest.
  • Per-person limits count each guest on a shared tab separately.
  • Two vouchers that cannot be combined are not both accepted.
  • A refused code refuses the payment's other codes.
  • User, e-mail, phone and segment restrictions are not checked at payment, as before.
  • On ledger tabs, each voucher is its own applied discount, named by the voucher's public title or Voucher: <code>, and is sized on what the paying guest pays.
• Breaking: kitchen_dispatch_items.discount_details is dropped. A source migration that runs after the deploy removes it. A replicated column can linger with its old values, and the customer view loses it at its next refresh. Stop selecting it before then. An integration's internal tab-lock and receipt tables, which no customer view exposes, are dropped too.
• Unchanged: every tab outside the ledger keeps today's lines, VAT and tab columns, apart from the marketplace, value-voucher and voucher-rule changes above.
• Validation:
  • Replaying 189,985 production tabs through the ledger: 189,959 reproduced their recorded money. 24 (0.013 %) would leave the ledger, for documented reasons: 17 items paid above their current price, and 7 overpayments. 2 differ because of concurrent payments the stored rows cannot reproduce.
  • The ledger's line builder against 4,854 recorded purchases: 0 differences in total, discount, quantity, rate or line count.
  • 41 end-to-end payment flows: no tab left the ledger.
• Consumer action:
  • Stop selecting discount_details.
  • Do not expect discount entries in applied_modifications or type = 'amount' lines for tabs with a ledger_account_id.
  • Treat an unknown purchases.psp value as a payment, not as card revenue.
  • To report discounts by name and source, plan to read account_discounts with tab_purchase_discounts once a later entry announces the views in your environment.

2026-10-20 — Development source changes; customer-view availability remains separate

The October 19–20 development-source review adds per-item voucher rates, receipt-specific item/variant names and loyalty identifiers to the release preview. This review performs no customer-view refresh, replication check or warehouse backfill and announces no new production BigQuery columns or views.

• Mixed voucher rates: checkout carries the matched rate of each participating line through discount and VAT allocation, including amount-mode partial payments. For sales reporting, use the recorded line and purchase amounts; a single blanket percentage cannot reproduce every mixed-rate bill. Existing restrictions, excluded nested amounts and maximum discounts remain relevant.
• Receipt names: the source adds optional API receiptTitle values and saved purchase-line receipt text. A guest-facing receipt label is distinct from the internal/reporting item title. Do not assume receipt_title is selectable from a customer view until that view's metadata confirms it.
• Loyalty and usage details: unique guest fields, program identifiers and AI request-cost estimates do not by themselves establish advertised warehouse fields. Historical AI estimates and gross request costs are not final invoice amounts or a sales-ledger backfill.
• Reporting fixes: configured organisation numbers appear in application PDF headers; Caspeco staff attribution and payment recovery fixes do not announce a new customer-view schema or a historical data rewrite.

The previously checked price-cluster view availability and its development/test scope remain unchanged. See the API changelog for the source contracts and the BigQuery guide for the verified warehouse contract.

2026-10-19 — Upcoming dev changes with reporting implications

Source review compares dev with the production branch, main, on October 19. These changes are pending on main. This source review itself performs no customer-view refresh, production replication check or historical backfill. The separately recorded October 19 price-cluster sync below is the latest development/staging customer-view update on dev; the older field reference remains a dated snapshot. Check your dataset before changing an export.

• Historical refunds and Save service fees: the dev refund flow supports eligible historical purchases and returns the refundable Save service-fee portion. The REST purchase response exposes fee/refund details, including serviceFeeRefundAmountCents; that camel-case response property is not a verified customer-view column. Reconcile confirmed refunds, their product allocations and any service-fee return separately; do not assume a product-line sum includes the entire provider refund. Existing nullable purchase_refund_line_items.quantity_cents semantics remain unchanged: explicit units use hundredths, while amount-only and historical rows need not have a quantity. No quantity backfill is announced.
• Remakes and supplements: the dev order model introduces ambulance_kind with charged and supplement values. Charged remakes retain their price; supplements and their children are forced to zero and handled separately on kitchen tickets/KDS. The application requires central database migrations, but this review does not establish a corresponding customer-view column, its BigQuery type or its null behavior. Do not substitute zero_ticket for a remake classification or infer one from a zero amount. The follow-up also exposes nullable ambulanceKind on REST purchase lines and labels remakes in merchant history; this property comes from the linked kitchen dispatch item and does not establish a new purchase-line column in BigQuery.
• Inventory, recipes and history: the optional ingredient/recipe model, reviewed stocktakes and inventory_item_versions configuration journal are source/application additions. No ingredient, recipe, stocktake or version-history customer views were verified for this entry. Recipe-derived purchase cost, nutrition and current shared/cluster prices are configuration or estimates; they do not rewrite recorded purchase-line prices, VAT or historical cost. Inventory configuration history excludes stock-only changes and starts with the first captured baseline.
• Current prices and table grouping: Foodora, Wolt and Uber Eats publication uses the shared pricing implementation with location/channel overrides; this changes current menu publication, not the historical sale ledger. The reporting API's hasTable distinction separates OTC sales from tables without a group; it is not an announced BigQuery column. For warehouse reporting, use only table relationships actually present in your authorized views.
• Receipt presentation and storefront settings: dev receipt rendering replaces voucher-code labels with public discount names or a generic label and masks codes in voucher payment summaries. This does not establish changes to stored discount/voucher data, customer-view columns or historical rows. The storefront ratings toggle and confirmation-content editor are presentation changes, not warehouse schema additions.
• Caspeco corrections: the dev exporter sends confirmed refunds for already-exported sales as deduplicated correction tickets, booked on the refund's day and linked to the original receipt. This is an integration export behavior, not a new BigQuery refund schema or an independent refund payout-method field. It does not change the original purchase's sale date or state. Refund corrections default on and can be date-restricted or disabled in the integration settings.

2026-10-12–18 — Production-branch reporting fixes

These direct commits and cherry-picks were recorded on main during October 12–18 in Europe/Stockholm. They describe application behavior in that branch; deployment, Datastream replication and customer-view availability are separate.

• October 12 — Per-location reporting days: combined SIE/CSV/PDF exports, Fortnox vouchers and purchase summaries apply each included location's calendar/business-day setting. The exporting location honors the requested setting; children use their own saved setting, defaulting to calendar day. A warehouse reconciliation must reproduce those per-location windows rather than apply the parent's window to every child. This changes export selection, not the meaning or type of purchases.purchased_at, and announces no data backfill.
• October 12–13 — State and configuration fixes: nearest-parent pricing and inherited course names resolve correctly, stock reports honor their filters, and verified late-authorization cancellations are reconciled. Continue filtering finalized sales/refunds by their recorded confirmed state; an authorization or cancellation is not itself a finalized sale or refund. No new customer-view column or historical rewrite is established by these commits.
• October 12–15 — Operational and commercial reporting: Adyen report-cost processing is batched and bounded. Team Pulse/progression uses verified daily activity and transaction revenue, including Swish totals checked against the canonical intent, with corrected contributor attribution, deduplication and Stockholm daily limits. These internal reporting fixes do not add customer-scoped BigQuery views or alter the warehouse payment/refund contract.
• Other production-only fixes: saved-card CVC capability, scheduled article visibility, refund receipt labels, voucher reset, the HOLD banner and the October 17 POS touch-quantity cherry-pick are included in the release notes. They announce no customer-view schema change.

2026-10-19 — Price-cluster sync enabled in development and staging

• Added price_clusters, price_cluster_entries, price_cluster_locations, and price_cluster_applications to the existing PostgreSQL publications and Datastream streams in development and staging/beta. All four backfills completed in each environment, and both streams reported running without stream errors.
• Created and authorized the four customer-scoped views in development customer_location_5182 and staging customer_location_1500000000. Each dataset now advertises 449 columns across 30 views, with matching table/column/type inventories. Cluster ownership is restricted through the existing location_members; location/application rows also require an in-scope target location.
• All four views are queryable. The checked EH scopes currently return zero rows, matching the scoped source data; this is not missing replication. Existing dataset permissions were preserved. Connectors should refresh their view inventory and metadata.
• These views describe current pricing configuration, not historical charged prices. Use recorded purchase lines for past sales. This operation did not change or verify production customer views.

2026-10-12 — Reporting clarification and dev/test parity recheck

• Rechecked the existing development customer_location_5182 and staging customer_location_1500000000 view inventories: 429 advertised columns across 26 views, with identical table/column/type tuples. zero_ticket is BOOL, refund-line quantity_cents is INT64, and printer_jobs.rendered_content is absent. No top-level BYTES column is advertised in either checked inventory. This is a recheck, not a new deployment or a production/customer-wide availability claim; the customer's connector run must be verified separately.
• Clarified that sales-line item_type is extensible text. The guide lists current goods/non-goods classifications and adds an unknown-value preflight before irreversible uploads. Inventory catalogue itemType and legacy item-type references are separate contracts.
• Added the checked multi-purchase tab example, fractional product allocations, flat split-bill modifier limitations and the kitchen-link article fallback. These explain recorded data; no corrected marketplace price split, modifier parent-link repair or historical backfill is announced.
• Documented historical pre-discount line VAT and purchase/line rounding differences. Current discount writers calculate post-discount line VAT, but the example observations do not establish an exact rollout timestamp or repair older rows. Use recorded purchase-level VAT for purchase reporting.
• Documented partner-specific tab member lookup and its mutable tab scope. Confirm the integration's actual JSON key with Karma. An immutable per-payment member export, independent refund payout method and returns without an original Karma sale are not supplied by the checked customer-view contract. These are explicit limitations, not new fields.

2026-10-08 — Development/staging customer-view schema convergence

• Refreshed the existing customer views in the checked development (customer_location_5182) and staging (customer_location_1500000000) datasets. Afterward, each advertises 429 top-level columns across 26 views, with identical table/column/type tuples. The existing location filters and authorized-view grants were preserved; this is not a claim about production datasets or every customer's separate dataset.
• kitchen_dispatch_items.zero_ticket is now advertised as BOOL in both views (KAR-150). printer_jobs.rendered_content (BYTES) is removed from both customer views (KAR-149); the upstream operational table still contains it. rendered_at and rendered_media_type are advertised in both customer views. Connectors should re-probe view metadata, not the raw source table.
• purchase_refund_line_items.quantity_cents is now advertised as INT64 in both checked customer views. Historical and amount-only allocations remain nullable; no quantity backfill is asserted. Previously hidden source columns in items, kitchen_dispatch_items, kitchen_dispatches, and purchase_line_items were refreshed into both views; consult the field reference for the newly observed fields.
• Dev-only purchase_line_items.pre_discount_value_cents and purchases.processed_by_retailer_user_id were removed from the dev customer views: neither exists in the checked development PostgreSQL source, although both linger in its replicated BigQuery source tables. The dev-only kitchen_dispatch_items.is_surplus customer-view column was also removed to match staging: it exists in dev PostgreSQL but not staging PostgreSQL, and is not interchangeable with item_type = 'surplus' (seven mismatches in a checked recent dev sample). For a sold-line surplus flag, use purchase_line_items.is_surplus. None of these three changes deletes source data.
• The parity check compared stored INFORMATION_SCHEMA.COLUMNS, not just a SELECT * sample. After the view refresh, no table/column/type difference remained between the two checked customer datasets. Raw Datastream tables can still differ from live PostgreSQL when dropped columns linger; do not treat this view parity as upstream CDC cleanup.

2026-10-06 — Production source release; customer-view availability is separate

• The October 6 production release applied the refund-control and price-cluster source migrations, including linked cluster pricing, hidden refund reasons and descendant prepaid-account export settings. This supersedes the earlier source-branch availability check below; it does not verify production Datastream replication or customer-view provisioning.
• Product refund allocations can record nullable purchase_refund_line_items.quantity_cents in hundredths of a unit: 100 means one unit. Amount-only and historical refunds can remain NULL; no quantity backfill is announced. Check your customer view's metadata before selecting it. The October 8 observation above verifies the column in the checked development and staging views only.
• Price clusters describe current menu-price configuration, not the historical price charged. For historical sales use the recorded purchase lines. No production customer-view availability is asserted for the four price-cluster tables or the refund-settings tables.

Earlier October 6 preparation check

• A source migration defines price_clusters, price_cluster_entries, price_cluster_locations, and price_cluster_applications for current grouped-price configuration. The migration was not in the checked remote database dev branch on October 6; this is not an announcement of replicated tables or customer views.
• Customer-scoped, authorized views for all four tables have been prepared. They require the owner location to be in the customer's location_members; location/application rows additionally require their target location to be in scope. Do not query them until replication, customer-view provisioning, and dataset metadata are verified for your environment. These tables are not a historical sale-price ledger.

2026-10-05 — Discounts in development/staging; refund quantity in development

• The discounts PostgreSQL source was already included in the running main Datastream streams in development, staging, and production, with completed backfill objects and replicated analytics_eupublic.discounts tables in all three. No stream inclusion change was needed. The separate legacy production stream does not own this dataset and was left untouched.
• Customer-scoped discounts views were created and authorized in the existing development and staging customer datasets on October 5. Each filters discounts.location_id through that dataset's location_members; the checked staging view returned 13 rows and zero out-of-scope rows. There was no production customer dataset in the checked production project, so this entry does not claim a production customer view or customer access. The view reports current discount/voucher definitions, including gift-card configuration, not an applied-discount or redemption ledger. The field reference records 34 view columns observed in staging.
• purchase_refund_line_items.quantity_cents is now present in the development upstream BigQuery table and advertised as INT64 by the refreshed development customer view. It remains absent from the checked staging upstream table and customer view; production upstream metadata also does not advertise it, and no production customer dataset was available to check. It is not included in the staging inventory. Amount-only and historical refunds still lack a recorded quantity; no backfill is announced. Before selecting the column, confirm its presence in your customer view.

2026-10-04 — Refund quantities in remote dev source model (not yet in customer views)

• The database dev branch adds nullable, positive-integer purchase_refund_line_items.quantity_cents. The purchase service's dev branch writes it when an explicit product quantity is selected for a refund: 100 means one unit, and 150 means 1.5 units. This is the quantity on a refund allocation to the original purchase line, not a currency amount and not the original sale's purchase_line_items.quantity_cents.
• An amount-only refund leaves the new field NULL; older refunds also have no recorded refunded quantity. Do not infer returned units from monetary allocations or treat NULL as zero returned units. Continue using total_amount_cents for the refunded monetary magnitude and restrict financial reporting to confirmed refunds.
• Availability check (October 4): Neither the development nor staging customer view advertises this column in INFORMATION_SCHEMA.COLUMNS; it was also absent from the checked development upstream BigQuery table. No customer-view column addition or backfill is announced. Before selecting it, check your own view metadata and confirm it is queryable. The field reference retains its September 28 inventory and notes this pending field separately.
• The same source migration adds location refund settings and reason definitions; no corresponding customer views were observed. Other recent source additions (including gift-card details and location seasonality) were not observed as newly advertised columns in the checked customer views. They are not part of this customer-view schema announcement.

2026-09-28 — Staging schema inventory

• A staging customer dataset exposed 25 views and 380 advertised top-level columns when the field reference was prepared. This is a snapshot, not a versioned promise about other customer datasets or production.
• Confirmed reporting interpretation: purchases.id identifies the purchase within an environment; purchases.purchased_at is the UTC sale time represented as a BigQuery TIMESTAMP; purchase_refunds.purchase_id ties refunds back to the original purchase. purchases.cr_receipt_id is a separate, nullable fiscal reference and not a universal export key.
• A confirmed sale remains confirmed after a refund; a technical zero-refund may instead reference a failed purchase. Only confirmed purchases count as finalized sales, and only confirmed refunds count as finalized refund records. For an article export, purchase_line_items.type = 'product' is the starting filter, with non-goods item_type exclusions and separate treatment of tips and amount payments.
• Known schema mismatch: kitchen_dispatch_items.zero_ticket exists and resolves as BOOL when queried in the staging customer view, but that view's stored schema and INFORMATION_SCHEMA.COLUMNS do not yet list it. Inferring the type from one nullable row can produce a false string/boolean mismatch. A view-schema refresh and connector recheck are needed; this log does not claim the fix has been deployed.
• Known connector limitation: printer_jobs.rendered_content is BYTES in the staging view. Connectors that cannot ingest binary data from SELECT * must omit it or use a deliberate Base64 STRING projection. No customer-view type change is announced here; confirm whether you need the payload before changing an established column.

2026-09-22 — Variants in development and staging

The customer-scoped variants view and its read authorization were verified in development and staging. It restricts variants through the owning variant group's location and the customer's location_members. A variant's optional item_id is not the ownership filter. This does not assert that every production customer dataset already has the view; check your dataset's view list before integrating.

2026-09-18 — Prepaid reporting code in the source model

The purchase payment-method model gained nullable prepaid_type_code: the configured prepaid reporting code snapshotted at payment time. The same purchase-method record also carries a Karma payment_method_id and a human-readable brand. The code is the stable choice for an agreed customer reporting mapping; the label is not. The column was observed in the staging customer view in the September 28 inventory. Previously replicated rows may lack detail; do not treat NULL as a failed payment. Card-provider enrichment fields also remain nullable.

2026-09-15 — Zero-ticket flag in the source model

kitchen_dispatch_items.zero_ticket was added as a source-side boolean for an item recorded on the tab but already prepared elsewhere. Its staging customer-view metadata remains stale as of September 28 (see the known mismatch above). Source schema additions and customer-view schema visibility are separate steps.

2026-08-13 — Rendered printer payload in the source model

printer_jobs.rendered_content was added as a binary payload. In the September 28 staging inventory, the customer view exposes it as BigQuery BYTES. A generic SELECT * export can fail in connectors without binary support; select the columns you use or agree a transformed customer view before ingesting it.

2026-06-26 — Fiscal refund registration fields in the source model

Refund records gained nullable cr_receipt_id and cr_registered_at for the refund's later fiscal cash-register booking. Both fields were observed in the staging customer view in the September 28 inventory. They do not replace purchase_refunds.purchase_id, purchase_refunds.id, or the original sale's purchased_at.

Maintaining this log

When a customer-visible BigQuery field or view changes, record the environment, date observed, view/column, old and new types/meaning, null/backfill behavior, and any required consumer action. Do not call a source migration “available to customers” until the customer view and its metadata have been checked. Customer dataset access and production rollout are verified separately from the source schema.