Odoo POS + pos_restaurant

Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.

order-capture-floor-plan-editor

Multi-floor editor in backend and POS frontend: table number, seats, square/round shape, size, color, background image, clone. No server-section assignment. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.

order-capture-seat-level

Split flow selects products, not seats. Presets capture a guest count only. No seat tagging on order lines documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.

order-capture-coursing-hold-fire

Course button splits the order; Order fires course 1; retrieve from floor plan and click Fire Course 2. Transfer course between courses. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.

order-capture-split-merge

Split by product into a sub-order, transfer products to another table, merge by transferring onto an occupied table. No even N-way or arbitrary-amount split. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator

order-capture-bar-tab-preauth

Set Tab records only an open order name. No card pre-authorization, incremental re-auth, or stale-tab auto-close documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.

order-capture-transfer-audit

Transfer/Merge documented; session report attributes each order to an Employee. No transfer-specific audit entry naming both employees. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.

order-capture-native-handheld

POS is a browser app running on any tablet or phone, plus iMin Android devices. Odoo ships no first-party purpose-built handheld. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.

order-capture-offline-order-entry

Docs claim it is 'built to maintain functionality even during temporary network outages'. No published list of what works offline. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator

order-capture-qr-same-check

Per-table QR codes; guest orders assign a table and land in POS orders and the prep display. Merging onto an open server check is not stated. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator

order-capture-kiosk-first-party

First-party kiosk on the same product records. No ADA/WCAG conformance documented; kiosk payment limited to Adyen and Stripe terminals. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.

order-capture-drive-thru

UPHELD on re-run instruments. The POS index enumerates every documented POS area and the restaurant entry reads 'Features specific to restaurants: manage floors, tables, tips, and online delivery.' - no drive-thru area. Re-run over the FULL 696-document corpus with the fixed nav-stripping grep: drive.?thr(u|ough) 0, curbside 0. Doc-tree three-state probe (addendum 3b): .../point_of_sale/restaurant/drive_thru.html returns the 146-byte NEVER-EXISTED 404, identical to the fabricated control .../extra/zzq_fabricated.html and NOT the 132-byte retired stub, so no such page was ever built; and no drive-thru docname appears in the 1,159-page Sphinx build census. MODULE/EDITION: no lane, window-separation or pull-forward module exists in the 638 Community modules (.cache/q210/odoo-addons.txt) and none is documented for Enterprise either, so this is absent from BOTH editions - a proper 'no' under the addendum section 4 rule, not an edition gate. Falsified by any 19.0 module or page implementing lane assignment or order/pay/pickup window separation. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-09-05 adversarially verified

Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.

order-capture-drive-thru-timers

RE-HOMED off reporting.html and upgraded to grade A, because the proposal's instrument was overclaimed: reporting.html says its statistics are 'available in a graph or pivot view that you can filter or group depending on your needs', and an open-ended pivot means that page enumerates one list view but NOT the reportable field set. The model does enumerate it. In Community point_of_sale, pos.order carries exactly one clock field, "date_order = fields.Datetime(string='Date', readonly=True, index=True, default=fields.Datetime.now)", plus "preset_time = fields.Datetime(string='Hour'" and "shipping_date = fields.Date('Shipping Date')". There is no elapsed-time field, no per-segment (order/total/window) duration and nothing to group a speed-of-service report by; 'speed of service' returns 0 over 696 docs. MODULE/EDITION: point_of_sale, Community, grade A source tree. The only elapsed-time instrument in the product is the 'Alert timer (min)' and the order card's waiting-time indicator of pos_preparation_display, which is Enterprise (absent from the 638 Community modules) and is a kitchen-stage timer, not a drive-thru window timer. Falsified by an Enterprise field storing per-order stage timestamps exposed to reporting. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/point_of_sale/models/pos_order.py · retrieved 2026-09-05 adversarially verified

Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator

order-capture-voice-ai

UPHELD on limb one and the note CORRECTED, because the proposal never addressed the rubric's SECOND limb, 'or publishes a documented API partner program for third-party voice AI'. Limb one: this page is Odoo's whole voice surface and it is dictation - 'Odoo AI can transcribe spoken audio into text and generate summaries from that transcript.' - with no caller-facing agent and no order injection. Limb two, tested here for the first time: 'certified partner' 0 and 'conversational ai' 0 over 696 docs; legal/terms/partnership.html is the RESELLER partner programme, not an integration certification, and developer/reference/external_api.html is a generic ORM XML-RPC/JSON-RPC surface, not a voice-AI partner program - a third party could write pos.order over it, but Odoo publishes no programme for doing so. Vocabulary control run with the addendum's word-boundary trap avoided: voice ?(order|assistant|bot|agent) = 1 and it is 'invoice orders' on invoicing_policy.html; 'phone order' 0, 'answer.{0,20}call' 0, 'speech recognition' 0. MODULE/EDITION: no module named ai or *_ai is among the 638 Community modules, so the AI application is Enterprise - moot, because in NEITHER edition is this order capture, which is why this is a 'no' and not an edition-gated 'partial'. Falsified by a documented voice agent that writes pos.order, or by a named voice-AI partner programme. https://www.odoo.com/documentation/19.0/applications/productivity/ai/voice.html · retrieved 2026-09-05 adversarially verified

Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator

order-capture-throttling

Presets support time slots plus a Preparation capacity limit per time frame. No automatic quote-time extension on kitchen load. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.

order-capture-scheduled-orders

Manage orders by time lets staff or guests pick a future slot. Auto-injection into the make queue at a computed fire time is not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.

order-capture-catering

UPHELD after reading the page end to end and confirming all four mechanical limbs verbatim: quotes - the register opens 'the list of quotations and sales orders created from the sales application'; deposits - 'Apply a down payment (percentage) or Apply a down payment (fixed amount)'; balance due - 'Once a sales order is partially settled, the applied down payment is automatically deducted' from the order total; schedule - 'The Ship Later feature allows you to sell products and schedule delivery at a later date', with a shipping date, Warehouse and Specific route. The Sales-order queue is genuinely separate from the POS order queue, which answers the rubric's 'separate from the standard order queue'. What is missing is the catering flow as a distinct object: 'catering' returns 0 over 696 docs, no catering docname is in the 1,159-page census, and the doc-tree probe returns the 146-byte never-existed 404 for both .../point_of_sale/catering.html and .../restaurant/catering.html. MODULE/EDITION: point_of_sale plus pos_sale, both in the 638 Community modules, and the Sales app must be installed. Falsified to yes by a catering-specific order type or event-schedule view; falsified to no if down payments prove unavailable from the register. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/shop.html · retrieved 2026-09-05 adversarially verified

Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator

order-capture-order-ready-signal

UPHELD, and the onward-transmission doubt the analyst self-reported is now resolved AGAINST the doubt by evidence they did not cite. The page keeps two distinct fields on one order: 'Order Status' (Placed to Acknowledged to Food Ready) and Odoo's own 'Status' (New/Ongoing/Done, switching to Paid). Only a platform-side lifecycle explains the first, and the Order rejection section proves those actions round-trip to the marketplace: 'Swiggy orders cannot be directly rejected. Attempting to reject one prompts Swiggy customer support to contact the restaurant. Similarly, Deliveroo, JustEat, and HungerStation do not allow order rejection.' Per-platform acceptance rules only bind if the action is sent to the platform. The signal is raised from POS state by an operator - 'Click the Mark as ready button.' - not by a marketplace tablet, which is exactly what the rubric asks. MODULE/EDITION: pos_urban_piper, ENTERPRISE ONLY - 'An active Odoo Enterprise subscription is required. Odoo Community does not support this integration.' - and the module is absent from the 638 Community modules. Partial, not yes, PURELY on the addendum section 4 edition rule (first-party plus documented plus Enterprise-only equals partial, matching the standing hardware-kds precedent); on merits alone for an Enterprise tenant it would be yes. Falsified if Food Ready is shown to be an Odoo-internal state only. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-09-05 adversarially verified

Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.

order-capture-void-comp-controls

Three fixed rights tiers gate discounts, price changes, refunds and cancels. No reason codes and no dedicated exception report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

Docs enumerate the alternative: product attributes/variants plus one-level Combo Choices with Maximum items. No nested groups with per-level min/max. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

Extra price is set per attribute value or per product inside a combo choice. No parent-item x size price matrix. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports fractional/sectioned modifier placement (at minimum halves, ideally quarters) with independent pricing per section. differentiator

menu-pricing-fractional-placement

Held to the highest bar as instructed. The products page documents only attributes/variants and combo choices as the composition model — the alternative is affirmatively enumerated, so 'no' is defensible rather than mere silence. The dependent cells (half-and-half rule, kitchen-pizza-fractional-display, modifier-price-by-parent-size, nested modifiers) fall the same way. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01 adversarially verified

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

No half-and-half pricing rule of any kind documented, since fractional placement does not exist. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

The numpad Qty modifier multiplies line quantity. No light/regular/extra tiers with price multipliers documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

Two attributes (e.g. size x crust) generate a variant grid; extra price is per attribute value, with variant prices adjustable via pricelists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

Combo Choice has Includes items and Maximum items, with a Combo Price charged for each extra selection. Combo-scoped only, not item-modifier scoped. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

Combo product type with swappable choices and Extra Price deltas. No automatic detection or conversion of a-la-carte cart items into the combo. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

POS Optional Products suggests add-ons per product in the register. No per-channel configuration and no attach-rate reporting. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

Availability is driven by stock tracking and static per-channel flags (Available in Self Order, Available on Food Delivery). No 86 action, no latency stated. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

POS shows Free To Use units for tracked products and depletes on sale. Automatic 86 at zero with scheduled restore is not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

Presets carry a Schedule tab and working hours; POS categories carry Service Hours for delivery platforms; pricelists have date validity. Not per-item timezone scheduling. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

Pricelists attach per POS, per preset (Dine In/Takeout/Delivery) and per customer, with percentage and formula rules over a base price. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

Pricing docs cover discounts, pricelists, cash rounding and fiscal positions. No dual-pricing or cash-discount mode. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

Products carry tags, descriptions and images for self-order. No structured allergen flags or nutrition fields documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

Odoo Manufacturing BoMs plus POS stock moves can deplete components; POS shows margins and costs. No documented POS-to-recipe theoretical costing path. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

Sync Menu pushes to UrbanPiper Atlas with a Last Sync timestamp — middleware, not direct. Combos unsupported; no per-item rejection surface. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

Pricelist rules key off date, quantity, customer and channel. No demand-driven pricing with floor/ceiling guardrails. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

All thirteen names verified on the terminals page exactly as listed. Processor neutrality is real and is the dossier's most defensible differentiator. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01 adversarially verified

Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator

payments-published-rates

Odoo takes no payment margin and publishes no card rates; pricing comes from the merchant's chosen terminal provider. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator

payments-dual-pricing

No dual-pricing or cash-discount mode in the payment or pricing documentation. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

No surcharging engine, no BIN/debit exclusion, no network cap enforcement documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods.html · retrieved 2026-08-01

All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.

payments-emv-nfc

EMV and NFC come from the third-party terminal (Adyen, Stripe, Worldline etc.). Odoo ships no first-party terminal, so acceptance depends on provider. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator

payments-softpos-tap-to-pay

UPHELD. Verified verbatim on the page: 'The viva.com Terminal app turns a smartphone with an NFC chip into a payment terminal', 'Viva.com payment terminals do not require an IoT Box to operate', and the Odoo side is a real first-party integration - a Payment Method where you 'Set the Integration field to Terminal' and 'Set the Integrate with field to Viva.com', with Merchant ID, API Key, Client ID, Client secret and Terminal ID, plus a generated 'Viva Com Webhook Endpoint'. MODULE/EDITION: pos_viva_com is PRESENT in the 638 Community modules, so this cell is not edition-gated and partial here is not the addendum section 4 rule. Partial for three independent reasons: the acquirer rule - the NFC acceptance happens inside Viva's own Terminal app over Viva's Cloud Terminal API, and a terminal provider's capability may never score an Odoo cell yes; the page's own hard limit, 'Odoo only supports the Euro currency with viva.com.'; and it is one provider among the supported terminals, with Odoo never naming Tap to Pay on iPhone or Android ('tap to pay' 0 and 'softpos' 0 over 696 docs). Falsified to yes by a second documented tap-on-phone provider or an in-POS softpos flow; falsified to no if the Viva app proves to be a wholly separate register. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals/viva_com.html · retrieved 2026-09-05 adversarially verified

Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.

payments-pay-at-table

Odoo ships no handheld. The POS runs in a browser on any device, but no documented tableside handheld-plus-reader product exists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator

payments-qr-guest-pay

QR menu + Ordering lets guests order and pay from their phone; a separate QR code payments method exists. Not documented as scan-to-pay on a printed check. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

On-device tip via Adyen terminal; Add tip after payment is US-only with Stripe or Adyen, offering 15/20/25%, No Tip or custom. No unadjusted-tips manager screen. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator

payments-tip-pooling

Tips post as a single [TIPS] product line. No pooling or distribution rules documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator

payments-offline-store-and-forward

Terminal docs state a connection issue between Odoo and the terminal automatically cancels the transaction. The marketing 'offline payments' claim conflicts with this. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator

payments-offline-decline-liability

No offline card capture, therefore no published decline-liability position or post-reconnect failure report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

Promotions, Coupons, Gift Card & Loyalty Program setting; codes entered or scanned at the register and shared with eCommerce in the same database. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.

payments-house-accounts

Customer account payment method lets guests pay on account. Per-account credit limits and periodic statements are not documented in POS. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/customer_credit.html · retrieved 2026-08-01

A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.

payments-split-tender

Multiple tenders per order are documented (order and tip on different methods) and splits create sub-orders. No even-N or arbitrary-amount split. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.

payments-refund-void-controls

Refunds, discounts and cancels gated by the basic/advanced rights tiers; orders carry the Employee. No immutable approver audit log documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator

payments-chargeback-tooling

Odoo is not the acquirer; no dispute dashboard or evidence-submission tooling documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods.html · retrieved 2026-08-01

Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator

payments-card-on-file

UPHELD after reading the controller directly rather than trusting the note. Both quotes are verbatim in THIS file: it loads saved cards with "request.env['payment.token'].sudo()._get_available_tokens(" for the order's partner, accepts a payment whose "kwargs.get('flow') == 'token'", and raises "Tokenization is not available for logged out customers." under the comment '# Avoid tokenization for the public user.' MODULE/EDITION: pos_online_payment, Community (present in the 638-module list) - grade A source tree, the strongest instrument available for a Community question. Partial, not yes, because the rubric asks for reuse across online ordering, phone orders AND in-store: this is the guest-facing /pos/pay/<order_id> portal route only, tokenization is refused to the public user so the guest must be a logged-in portal user, there is no cashier-initiated charge of a stored token from the register (the in-store card path is a third-party terminal), and there is no phone-order flow in the product at all ('phone order' 0 over 696 docs). No PAN sits with the merchant: Odoo 'outsources tokenization and payment to external payment providers'. Falsified to yes if Odoo documents a cashier charging a stored token from the register. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/pos_online_payment/controllers/payment_portal.py · retrieved 2026-09-05 adversarially verified

Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator

payments-payout-timing

Odoo holds no merchant funds and publishes no deposit schedule; funding timing belongs to the chosen processor. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.

payments-p2pe-pci4

UPHELD - this is the strongest form a 'no' can take, an explicit vendor denial, and I confirmed it verbatim on the cited page under the heading 'PCI DSS and Attestation of Compliance': 'Odoo is not PCI DSS-certified because it does not store cardholder data or process payments. Instead, it outsources tokenization and payment to external payment providers, which means that as an Odoo customer, you only need to complete the minimal Self-Assessment Questionnaire (SAQ) with the provider to obtain the Attestation of Compliance (AoC) and achieve PCI compliance. Odoo should not be mentioned as a payment processor or a third-party service provider in the SAQ.' So Odoo publishes no AoC of its own and disclaims the role that would require one. P2PE half: 'point-to-point encryption' returns 0 over 696 docs and Odoo holds no PCI P2PE listing. MODULE/EDITION: the disclaimer is about Odoo S.A. as publisher and binds Community and Enterprise alike, so n/a rather than a gate. A merchant may still hold P2PE from Adyen, Stripe, Six, Worldline or Viva, but that is the terminal provider's listing and the rules bar it from scoring an Odoo cell. Falsified only if Odoo publishes its own AoC or a PCI P2PE listing. https://www.odoo.com/documentation/19.0/applications/finance/payment_providers.html · retrieved 2026-09-05 adversarially verified

Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.

kitchen-station-routing

DOWNGRADED from a standing 'yes' to reconcile it with the hardware-kds precedent, as addendum section 4 requires: the two rows cite the SAME Enterprise-only module and cannot both be right, and the standing note itself said 'Carry the same Enterprise-edition caveat as hardware-kds' while still scoring a full yes. On the merits the routing is real and operator-configurable per location: 'Select the Point of Sale that sends orders to this display. Leave the field empty to link it to all points of sale.' and 'Specify the POS product categories to be sent to this display. Leave the field empty to allow all categories.', with per-display stages, colors and an 'Alert timer (min)' - routing by category and by revenue centre, configured in the UI with no vendor involvement. MODULE/EDITION: pos_preparation_display, ENTERPRISE-only (absent from all 638 Community modules), so the Community self-host this record is framed on cannot route to KDS stations at all. What Community ships instead is PRINTER routing: point_of_sale/models/pos_printer.py defines "product_categories_ids = fields.Many2many('pos.category', 'printer_category_rel', 'printer_id', 'category_id', string='Printed Product Categories')" alongside pos_config_ids, i.e. per-POS, per-category kitchen and bar printers - station routing to paper, not to a KDS, which is why this is partial and not no. Falsified to yes if pos_preparation_display appears in a Community release. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-09-05 adversarially verified

An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.

kitchen-expo-consolidation

Multiple displays plus a top bar tracking all orders across stages. No documented expo screen that completes only when every station has bumped. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator

kitchen-course-firing

Courses fire on demand from the register or by retrieving the order from the floor plan or Orders overview (Fire Course 2). https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator

kitchen-prep-time-pacing

Stages carry an alert timer only. No per-item cook times and no staggered start so items finish together. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator

kitchen-order-throttling

Throttling is at order intake via preset Preparation capacity per time slot, not driven by live kitchen ticket times. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator

kitchen-channel-pause-propagation

Store Timings control platform availability windows through UrbanPiper. No documented ad-hoc pause or item-level 86 push to marketplaces. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator

kitchen-order-ready-callback

UPHELD on the merits but the EDITION GROUND STRIPPED - the proposal's 'doubly moot for Community' reasoning is exactly the edition-as-ground-for-no that the addendum section 4 rule forbids, and it is not needed. The Order flow section is a complete documented procedure and it routes the ready step AWAY from the KDS: an accepted order 'is automatically displayed on the preparation display', but then 'When the order is ready, Open the orders' list view. Select the order. Click the Mark as ready button.' A separate manual step, in a different view, documented after the order is already on the display, is affirmative evidence that a stage move on the display does not emit the event. preparation.html independently enumerates every control on the display - clicking items to cross them off, the automatic move to the next stage, Recall ('Undo the most recent order stage move'), Done, Clear All Orders and Reset - and none is described as emitting anything outward. MODULE/EDITION: pos_urban_piper and pos_preparation_display, both Enterprise-only (absent from the 638 Community modules); the capability is absent even in Enterprise, where BOTH modules are present, and that is what licenses the 'no'. Falsified by documentation or code showing a prep-display stage move emits Food Ready. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-09-05 adversarially verified

KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.

kitchen-bump-bar-hardware

Prep display runs in a browser on a mobile device or a USB/HDMI touchscreen, and 'IoT boxes are not supported'. No bump-bar models documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.

kitchen-all-day-counts

The top bar shows order counts per stage, not aggregated outstanding quantities per item or modifier. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.

kitchen-sla-alerts

Per-stage 'Alert timer (min)' highlights orders exceeding the target, with color-coded stage status and visible waiting times. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator

kitchen-printer-fallback

Printer setup binds categories to a printer with no documented backup printer or screen failover. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator

kitchen-offline-operation

NEW SURFACE, held unknown. The live 19.0 use.html now carries an "Offline POS" section that was NOT in the q210 696-doc corpus (0 hits in the cached copy); also odoo/documentation master 05a1e9c6 (1,164 .rst, tree truncated:false) fetched in full via raw.githubusercontent.com, plus new general/offline_mode.rst. EVIDENCE: "Orders created offline are stored in the browser cache and synced to the backend when the connection is restored." "Many POS features rely on backend information and, therefore, are not available offline. These features include: Generating invoices ... Registering customers ... Accessing detailed product information ... Synchronizing stock in real time ... Using payment terminals ... Loading data on demand" and "Devices connected to the local network, such as printers and scales, continue to work offline". WHY STILL UNKNOWN: the list is OPEN ("include") and never names the preparation display; preparation.rst (master and 19.0 identical on this point) still never takes up connectivity. The architecture implies orders reach the display only after the backend sync (preparation.rst: orders placed in the register "are sent to the preparation display"; the POS queues offline orders locally), but no sentence states the display stops receiving, so a no would rest on inference. general/offline_mode.rst covers "apps and modules built using standard Odoo framework components" (cached views/records) and does not name the preparation display either. Kitchen PRINTERS on the LAN are documented to keep working offline (that is reliability-offline-kds-printing, not this KDS cell). SOURCE: pos_preparation_display is absent from odoo/odoo 19.0 (630ed4e8, 638 addons) and master (c3776940, 642 addons); api.github.com/repos/odoo/enterprise is 404; translate.odoo.com 403. Retrieved 2026-09-17. || 329th: 329th: the preparation-display doc has MOVED and the source route is now closed for good, but neither changes the verdict. (1) The 19.0 page the record's chain relies on is no longer at restaurant/preparation.html (404, 170 b); it is now extra/preparation.html, reached from the 19.0 Point of Sale index. Its full text (6,260 stripped chars) was re-read and tokenised controls over it are ZERO for offline, connectiv*, internet, network, sync, cache and unreach* -- the page takes up connectivity nowhere, so the open-list inference recorded on 2026-09-17 stands unchanged. (2) The source census is closed, not merely truncated: pos_preparation_display and pos_restaurant_preparation_display return 404 for __manifest__.py on raw.githubusercontent.com at 17.0, 18.0, 19.0 AND saas-18.4, and the RECURSIVE trees (api.github.com, truncated:false) of odoo/odoo 19.0 bcd36a80b0b1f3b56810440e2d180d40f0ff1a82 (48,224 blobs, 936 of them under addons/point_of_sale/) and 18.0 7950c5b47b8b8315a0eff73a1d242fdc72dddcdf (51,345 entries) contain ZERO files matching /prepar/i except addons/point_of_sale/static/tests/pos/tours/utils/preparation_receipt_util.js. So the display is Enterprise-implemented on every supported version and no community source can ever bound it (odoo/enterprise is 404 to anonymous API calls). (3) apps.odoo.com is not a route either: /apps/modules/19.0/<name> works (amazon_ept 200) but point_of_sale, pos_preparation_display and pos_urban_piper all 404, i.e. Odoo SA's own modules are not published there. The 19.0 release-notes page (101 KB) has 0 hits for 'kitchen' and 1 for 'offline' (Discuss chat status). Retrieved 2026-09-18. adversarially verified

Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator

kitchen-item-build-screens

Order cards show order detail including variant/attribute selections and notes. No recipe steps or portioning build screens. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator

kitchen-pizza-fractional-display

No fractional placement exists in the menu model, so nothing sectioned can be rendered on the make line. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.

kitchen-recall-refire

A Recall button undoes the most recent stage move, and the POS reprints a duplicate of the last kitchen order. No per-item refire documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator

kitchen-order-modification-alerts

pos_restaurant ships an order-change receipt template and prints a cancellation ticket, implying change tracking. On-screen flagging is not documented. https://github.com/odoo/odoo/blob/master/addons/pos_restaurant/__manifest__.py · retrieved 2026-08-01

Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator

kitchen-guest-ready-notification

Presets support an Email Confirmation template and kiosk tracker numbers. No SMS-on-ready, app push, or status board documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.

kitchen-waste-logging

Waste is handled by Inventory scrap in the back office, not logged with reason codes at the kitchen screen. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01

Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.

kitchen-speed-of-service-reporting

Prep display shows live waiting times, but POS reporting covers orders and sessions only — no per-station time percentiles by daypart. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.

kitchen-prep-forecasting

UPHELD, with the vocabulary control widened beyond the proposal's single term. preparation.html enumerates the display's ENTIRE configuration (Name, Point of Sale, POS product categories, Auto clear, Stages with colors and 'Alert timer (min)') and its entire interface (top bar, side panel filtering by Time, Preset and POS categories, and order cards); every element is reactive to orders already placed. Re-run over 696 docs with the fixed grep: 'prep list' 0, 'prep(aration)? (sheet|task|quantit)' 0, 'par level' 0, 'production plan' 0. 'forecast' returns 7 and every one is the Inventory forecasted on-hand quantity or the CRM sales forecast (inventory configure/type.html, crm/performance/forecast_report.html, point_of_sale/products.html, point_of_sale/models/product_template.py) - stock replenishment, never a kitchen prep sheet and never surfaced to kitchen staff. MODULE/EDITION: the KDS this would live on is pos_preparation_display, Enterprise-only (absent from the 638 Community modules); the Inventory forecast is Community (stock) but is a different capability. Absent in BOTH editions, which licenses the 'no' rather than an edition gate. Falsified by a documented prep-list view fed by historical sales. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-09-05 adversarially verified

Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).

delivery-driver-roster

Restaurant docs cover floors, orders, printing, bills and tips. No in-house driver entity, clock state or run history exists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).

delivery-dispatch-board

No dispatch or expo screen for delivery orders, driver availability, or multi-order run batching. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator

delivery-route-map

No dispatch map or route sequencing; no delivery dispatch module exists to host one. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator

delivery-driver-tracking

No driver-facing mobile app and no GPS surfacing documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator

delivery-zones-polygon

No delivery-zone geometry of any kind — polygon, isochrone, radius or ZIP list — documented for POS. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.

delivery-zone-pricing

Delivery is a preset (pricelist plus fiscal position), not a zone with its own fee, minimum and promise time. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.

delivery-address-validation

Preset Identification can require a customer address, but no geocoding, validation or out-of-zone rejection is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator

delivery-driver-comp

No mileage, per-delivery reimbursement, or driver-tip tracking exists because there is no driver module. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.

delivery-cash-reconcile

POS cash control reconciles the register session, not a per-driver bank with orders assigned and tips owed. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.

delivery-daas-dispatch

No native handoff to DoorDash Drive, Uber Direct, Nash or Relay from the POS is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator

delivery-daas-fallback

No hybrid dispatch rules, since neither in-house drivers nor DaaS dispatch exist. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator

delivery-3p-direct-integration

THE ADDENDUM'S PREMISE FOR THIS ROW IS WRONG and I am correcting it: s4 says this no's whole stated ground is the UrbanPiper Enterprise gate, but the standing note's operative ground is that marketplace access is exclusively via UrbanPiper middleware, and that is exactly the disqualifier the rubric writes into the claim, which requires vendor-owned certified integrations not solely resold through Otter, Deliverect, Chowly or ItsaCheckmate middleware (the rubric's own words in data/taxonomy/restaurant.yaml). UrbanPiper is such middleware and the page says so in Odoo's own words: "UrbanPiper is an order management system that integrates with multiple food delivery platforms.", with "A valid UrbanPiper subscription is mandatory." and "A registered reseller account is required with each delivery platform to be integrated" (e.g. Uber Eats, DoorDash, Careem, Deliveroo, Zomato). Three counterparties, and no direct Odoo-to-DoorDash certification anywhere. The verdict therefore stands on the merits and does NOT depend on the edition, so addendum s4's rule that edition-gating alone is not a ground for no does not reach this row. MODULE/EDITION: pos_urban_piper is Enterprise-only - absent from the 638 Community modules, the page stating "An active Odoo Enterprise subscription is required. Odoo Community does not support this integration." - so Community has no marketplace path at all and Enterprise has only a resold one. No first-party DoorDash, Uber Eats or Grubhub module exists among the 638, and no such page exists among the 1,158 census docnames. FALSIFIER: an Odoo-owned marketplace connector module, or a direct-certification announcement. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-09-05 adversarially verified

Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.

delivery-3p-injection

This is the exact shape of cell the brief says to hold to the highest bar, and it is not native. Verified from the Odoo doc: 'an active Odoo Enterprise subscription is required. Odoo Community does not support' it; Enterprise 18.0+; a valid UrbanPiper subscription; plus registered reseller accounts with each platform. Three separate paid relationships and a middleware hop is a partner integration, not a yes. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01 adversarially verified

Menu, pricing, modifiers, and photos publish from the POS master menu out to connected third-party marketplaces, including channel-specific price markups, without maintaining a separate menu in each portal.

delivery-menu-push

Sync Menu publishes products; pricelist and fiscal position auto-attach per store. Combos are unsupported (workaround: attributes and variants). https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).

delivery-86-sync

OVERTURNED from 'no' on two defects. First, the proposal's decisive clause, 'Community has no channel to 86 to at all', is edition-as-ground-for-no, which the addendum section 4 rule forbids: pos_urban_piper is first-party and documented, so the floor is partial. Second, its own evidence describes item-level availability reaching the platform. The page enumerates the product form's Urban Piper section as 'Available on Food Delivery', 'Meal Type', 'Is Recommended' and 'Is Alcoholic'; 'Available on Food Delivery' is settable per product and in bulk from the list view, then published to every connected platform by 'Click the Sync Menu button.' Clearing and restoring that field is item-level availability control that reaches the channel, so the rubric is part-satisfied. It is not a yes: the push is operator-initiated and whole-menu rather than event-driven, the page warns 'The synchronization process may take 2-3 minutes to reflect changes on the UrbanPiper Atlas platform', so it is not near-real-time; there is no stock-driven or automatic trigger; and there is no item-option 86ing, since 'Currently, UrbanPiper does not support combo products.' The only runtime control is Store Timings ('Week Day, Starting Hour, Ending Hour'), which closes the whole store. MODULE/EDITION: pos_urban_piper, Enterprise-only - 'An active Odoo Enterprise subscription is required. Odoo Community does not support this integration.' Falsified to yes by a documented on-demand or stock-driven item availability push covering item options. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-09-05 adversarially verified

Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.

delivery-store-pause

Store Timings set weekly availability windows per POS. No ad-hoc pause with timed auto-reactivation from inside the POS. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator

delivery-3p-reconciliation

RE-HOMED off reporting.html; value upheld. The proposal called reporting.html 'the complete POS reporting surface', which it is not - it says its statistics are 'available in a graph or pivot view that you can filter or group depending on your needs', and an open-ended pivot cannot be an enumeration. The right instrument is the only third-party food-delivery connector Odoo documents, described here end to end: prerequisites, credentials, store creation, Store Timings, products, menu synchronization, go-live, order flow and order rejection. That complete integration enumeration contains no payout, deposit, commission, marketing-fee, adjustment or missing-order surface of any kind. Vocabulary re-run over 696 docs: 'settlement report' 0, 'marketing fee' 0; 'commission' returns 22 and every commercial hit is HR payroll commissions, sales-rep commission plans, the reseller partnership terms, or the Amazon, Lazada and Shopee e-commerce connectors - Odoo HAS built marketplace fee handling for e-commerce channels and has NOT built it for food delivery, which is the sharper form of this absence. MODULE/EDITION: pos_urban_piper, Enterprise-only (absent from the 638 Community modules); the capability is absent in Enterprise too, where the connector exists, and that is what licenses the 'no'. Falsified by a documented food-delivery payout or commission report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-09-05 adversarially verified

Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator

delivery-injection-error-visibility

Successful sync triggers a notification and a Last Sync on timestamp updates. No per-channel connection status or failure alerting documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.

delivery-tracking-page

RE-HOMED and DOWNGRADED from grade A. A single module's __manifest__.py (pos_sms) cannot carry a corpus-wide absence claim, and the proposal's premise that pos_sms is the guest-messaging channel is WRONG: preparation.html documents a different, richer one - 'Install the POS Enterprise SMS Whatsapp module', then 'Activate SMS Enabled and/or WhatsApp Enabled in the Communication tab. Select templates for Order received and Order is ready.' Guests DO receive order-state-driven SMS and WhatsApp notifications, which the proposal denied. It is still a 'no', on this page's own enumeration of that Communication tab: the templates are notifications, not a link or a page, and the two status surfaces Odoo documents are in-store screens - the 'Order Status Screen' showing orders 'Ready for pickup' and 'Almost there', used 'via a web browser on a mobile device or a screen connected via USB or HDMI'. Nothing is served on the restaurant's own domain, and no driver state exists to drive one (this record already scores delivery-driver-roster and delivery-driver-tracking 'no' because the POS model has no driver entity). Doc-tree probe: .../point_of_sale/extra/order_tracking.html returns the 146-byte never-existed 404. MODULE/EDITION: the notification templates need the Enterprise SMS/WhatsApp module (whatsapp is absent from the 638 Community modules); Community pos_sms sends only a receipt. Falsified by a documented per-order guest tracking URL. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-09-05 adversarially verified

Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator

delivery-promise-time

Preset time slots and capacity are static configuration; no dynamic promise time from kitchen load or drive time. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.

delivery-offline-behavior

No delivery offline behaviour is documented because no delivery dispatch module exists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

QR menu + Ordering is first-party and commission-free, writing straight into POS; Odoo Website/eCommerce covers a branded domain in the same database. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

Self-order renders the same product records; a per-product 'Available in Self Order' flag controls exposure. No separate digital menu build. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator

digital-native-app

Self-ordering is a mobile web interface reached by QR code or a kiosk. No branded native iOS/Android ordering app documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.

digital-account-saved-payment

Odoo portal/eCommerce accounts hold addresses and tokenized methods, but self-order and kiosk flows only collect name, phone or email per order. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator

digital-upsell-engine

POS Optional Products provides rules-based add-on suggestions. No personalization from order history and no attach-rate reporting. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Preset 'Manage orders by time' defines slots from a working schedule plus a Preparation capacity limit per time frame; guests pick a slot. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.

digital-fulfillment-modes

Presets cover Dine In, Takeout and Delivery with per-mode pricelist and fiscal position; service at Table or Pickup zone. No curbside arrival check-in. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.

digital-qr-table

Verified verbatim on the restaurant page: 'To order free physical QR codes adapted to the floor plan, activate the QR menu setting, then click Get QR Codes in the Floor plan view. This offer is available worldwide and for all subscription types.' Rare case of a marketing-sounding claim that is actually in the product docs. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01 adversarially verified

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

First-party kiosk on the same menu, optionally on an IoT Box touchscreen. Unattended payment limited to Adyen/Stripe; no accessibility conformance published. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

No shareable multi-participant group order link with per-person caps documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator

digital-catering-portal

No catering-specific ordering flow with minimums, lead-time rules, proposals, deposits or invoice terms documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator

digital-voice-ai-phone

MODULE/EDITION: the whole 'ai' application is Enterprise-only (no ai, ai_* or *_ai module among the 638 Community modules in .cache/q210/odoo-addons.txt); Odoo Phone (ex-VoIP) is a separate app. Odoo AI's only voice surface is dictation, not telephony: "Odoo AI can transcribe spoken audio into text and generate summaries from that transcript." and "This feature supports both meeting recordings and real-time dictation". CORRECTION TO THE STANDING NOTE, which is wrong: this is NOT the only voice page in the census and call vocabulary is NOT corpus-absent - the 1,158-name docnames census carries a full 16-page Phone/VoIP book (applications/productivity/phone.html plus phone/axivox/*, didww, onsip, phone_widget, devices_integrations, sales_calls, support_calls) that is MISSING FROM THE 696-DOCUMENT CORPUS, so every corpus-wide zero-hit on 'inbound call' was an artefact of a corpus hole, not an absence. I fetched that book live (200, 419,487 b): Odoo Phone is a human softphone over SIP/WebRTC with three verified providers (Axivox, DIDWW, OnSIP), call queues and dial plans, and its own overview enumerates its feature set as linking calls to CRM and Helpdesk records, logging communication history, automating call routing, call recording and analytics - no AI answering agent, and Point of Sale is not among the apps it integrates with. Doc-tree three-state probe: applications/productivity/ai/phone.html returns the 146-byte never-existed 404. FALSIFIER: an Odoo page documenting an AI agent answering an inbound call and writing a pos.order. https://www.odoo.com/documentation/19.0/applications/productivity/ai/voice.html · retrieved 2026-09-05 adversarially verified

Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.

digital-drivethru-ai

No drive-thru support at all, so no drive-thru voice AI. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.

digital-sms-ordering

Odoo ships SMS Marketing, but no conversational text-to-order path into the POS is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

MODULE/EDITION: pos_self_order IS among the 638 Community modules, so this is a product gap, not an edition split. Re-run against the corrected 696-document corpus: 'order with google' 0, 'google business profile' 0. Census control, which is the stronger instrument: the 1,158-name Sphinx docnames manifest contains exactly seven Google pages - google_oauth, google_translate, users/google, appointments/google_reserve, calendar/google, ecommerce/google_merchant_center and website/configuration/google_search_console - and no Google Business Profile page of any kind. Doc-tree three-state probe: .../point_of_sale/extra/google_order.html and .../general/integrations/google_business.html both return the 146-byte never-existed 404, not the 132-byte retired stub. The cited page is Odoo's own first-party ordering surface and enumerates how the ordering link reaches guests - printed or downloaded QR codes and a kiosk - with the operator told "To customize QR codes, scan the relevant QR code to acquire its URL, then use a QR code" generator, which is the opposite of provisioning that link into a listing. I also re-ran Odoo's OWN guest-surface nouns after the mid-run correction to the drive-thru control list (order status screen 1, ready for pickup 2, almost there 1, all on extra/preparation.html and extra.html): Odoo's guest-facing order surface is a merchant-operated in-store Order Status Screen, which is the opposite of a provisioned listing and does not touch this cell. FALSIFIER: an Odoo page pushing the self-order URL into a Google Business Profile ordering slot. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-09-05 adversarially verified

Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.

digital-apple-business-connect

MODULE/EDITION: pos_self_order is in the 638-module Community list; a product gap, not an edition split. Re-run over the corrected 696-document corpus: 'apple business connect' 0, 'apple maps' 0. Census control: no docname among the 1,158 in .cache/q210/odoo-docnames.txt mentions Apple or Maps at all. Doc-tree three-state probe: .../point_of_sale/extra/apple_business_connect.html returns the 146-byte never-existed 404, matching the fabricated control .../extra/zzq_fabricated.html and unlike the 132-byte retired meta-refresh stub that .../productivity/voip.html returns, so the instrument does discriminate here. On the cited page the distribution channels for the first-party ordering link are enumerated as QR codes and a kiosk, the operator being told "To customize QR codes, scan the relevant QR code to acquire its URL, then use a QR code" generator; there is no place-card or custom-action provisioning of any kind. Following the mid-run correction to the drive-thru control list I re-ran Odoo's own guest-surface vocabulary rather than only the Apple proper nouns: the nouns order status screen, ready for pickup and almost there all resolve to a merchant-operated in-store Order Status Screen on extra/preparation.html, so the one guest surface Odoo does ship is not a map or listing placement. FALSIFIER: an Odoo page documenting an Apple Maps Order Food action pointing at the self-order URL. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-09-05 adversarially verified

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

Loyalty programs are configured under Point of Sale and share res.partner with eCommerce; explicit loyalty accrual inside the self-order flow is not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.

digital-subscriptions

Verified verbatim on the cited page: the app "is designed to manage recurring revenue through subscription-based" products or services, and its own integration sentence - "The app integrates with other Odoo modules such as" Invoicing, CRM, Sales and Helpdesk - is the completeness sentence, and Point of Sale is not in it. So a real recurring-billing engine exists but nothing it issues is redeemable at the register: 'recurring', 'membership' and 'subscription' return zero across the 45 point_of_sale pages and the loyalty, gift-card and eWallet pages, and I confirmed those books are FULLY present in the corpus (669 of the 1,158 census pages are missing from it, but none of the missing are POS, loyalty, marketing or SMS pages), so this zero is bounded by complete books rather than by the corpus hole that damaged other rows in this slice. MODULE/EDITION: ENTERPRISE-ONLY - no module matching 'subscription' appears among the 638 Community modules, so a self-hosted Community merchant has no subscription engine at all. Partial not no under this record's own edition precedent (hardware-kds, a standing verified partial for the Enterprise-only pos_preparation_display): an Enterprise-only, first-party, documented capability is partial, never no on edition grounds alone. FALSIFIER: a documented subscription entitlement redeemable in POS would make this yes. https://www.odoo.com/documentation/19.0/applications/sales/subscriptions.html · retrieved 2026-09-05 adversarially verified

Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.

digital-promo-parity

Discount and loyalty programs are defined once and shared across POS and eCommerce in one database. Per-channel eligibility controls not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator

digital-guest-data-ownership

'With Odoo, the values can be exported from any field in any record' - select records in list view, Action > Export, CSV or XLS, no fee or ticket. Odoo's GDPR page puts ownership beyond doubt: on Odoo Cloud 'you are the controller for that database and Odoo SA is only a data processor'. The Cloud SLA adds 'Users can download manual backups of their live data at any time'. Self-hosting removes all gates. https://www.odoo.com/documentation/19.0/applications/essentials/export_import_data.html · retrieved 2026-08-08

Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.

digital-checkout-pci-sca

Both quoted strings verify verbatim on the cited page and nowhere else in the 696-document corpus. Hosted-field half met: "Odoo apps delegate the handling of sensitive information to the certified payment provider so" the merchant need not worry about PCI compliance, and no sensitive information such as credit card numbers is stored on Odoo servers, a unique reference number being used instead. Compliance half not met, and by explicit vendor denial rather than by silence - on the same page Odoo states it is "not PCI DSS-certified" because it does not store cardholder data or process payments, so there is no PCI DSS 4.0 attestation and nothing on the March 2025 client-side script-integrity requirements. 3DS/SCA: '3DS', '3D Secure' and 'strong customer authentication' return zero over 696 documents, and ALL 25 payment_providers census pages are present in that corpus, so this zero is bounded by a complete book. MODULE/EDITION: the payment framework and pos_online_payment are both Community, so edition is not the constraint here. Several supported providers offer 3DS themselves, but under the brief's rule a terminal or acquirer capability cannot score this Odoo cell yes. FALSIFIER: an Odoo PCI DSS 4.0 statement or a documented 3DS flow. https://www.odoo.com/documentation/19.0/applications/finance/payment_providers.html · retrieved 2026-09-05 adversarially verified

Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator

digital-surcharge-transparency

No surcharge, service-fee or dual-pricing engine exists in POS, so nothing to mirror into digital channels. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.

guest-loyalty-unified-profile

One res.partner record serves POS, self-order and eCommerce in the same database. Dedup is a separate Data Cleaning app; no documented merge behaviour for POS. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator

guest-loyalty-thirdparty-identity-attach

OVERTURNED FROM no. Addendum s5 asks whether the capability is absent or merely Enterprise-gated; the answer is that it is gated AND undocumented, which licenses no verdict either way. MODULE/EDITION: marketplace orders reach Odoo POS only through pos_urban_piper, absent from the 638 Community modules, and this page states "An active Odoo Enterprise subscription is required. Odoo Community does not support this integration." - and api.github.com/repos/odoo/enterprise is 404 private, so the implementing source cannot be read at any grade. I read this page end to end. It enumerates supported providers by region, prerequisites, UrbanPiper credentials, the POS setting, store timings, product exposure, menu synchronisation, go-live and the order lifecycle ("its Order Status switches from Placed to Acknowledged"), and it never takes up customer data in any form - no res.partner, no contact, no guest identity field, and no completeness sentence about what attributes the connector carries onto an order. Under the mandatory no-audit that is absence from a document that never took up the topic, which is unknown, not no. It cannot be rescued as partial either: the record's edition precedent (hardware-kds) makes an Enterprise-only capability partial only when it is DOCUMENTED, and this one is not documented on either edition. FALSIFIER: pos_urban_piper source, or an Enterprise page, showing the connector creating or matching a res.partner from platform customer data. || 321st: Re-checked on a new surface, held unknown. odoo/documentation master 05a1e9c6 (1,164 .rst, truncated:false, full fetch): restaurant/urban_piper.rst has zero word-boundary hits for customer/partner/contact/phone/email/guest in any customer-data sense (the only "customer" is "Swiggy customer support"; "name" only as the store/POS name), unchanged from 19.0. pos_urban_piper remains absent from odoo/odoo 19.0 (630ed4e8, 638 addons) and master (c3776940, 642 addons, incl. new pos_partner_autocomplete, which is a partner-lookup helper, not a marketplace connector); odoo/enterprise 404. No source or doc sentence says the connector creates or matches a res.partner. crt.sh not run: *.odoo.com certificates enumerate customer databases, not vendor surfaces. Retrieved 2026-09-17. || 329th: 329th: re-read the LIVE 19.0 urban_piper page (not the .rst) and probed the two surfaces that could still hold the connector's data model; nothing moves. The live page's article text is 8,391 stripped chars and the tokenised counts are: partner 0, phone 0, email 0, guest 0, address 0, loyalty 0, anonym* 0, customer 1 -- and that one hit is still "Attempting to reject one prompts Swiggy customer support to contact the restaurant" (the same sentence as the 321st), in a paragraph that now also names Deliveroo, JustEat and HungerStation as providers whose orders cannot be rejected. So the marketplace connector's page has still never taken up customer data. NEW NEGATIVE RESULTS on the two remaining routes: apps.odoo.com serves module pages at /apps/modules/19.0/<name> (control amazon_ept = 200) but pos_urban_piper 404s there, so the Enterprise connector has no public listing page or description to read; and the odoo-19-release-notes page (101,309 chars) has 0 hits for urban, piper, deliveroo and 2 for marketplace, neither about POS. The falsifier named in the record (pos_urban_piper source, or an Enterprise page showing the connector creating or matching a res.partner from platform customer data) remains unreachable: the module is absent from odoo/odoo 19.0 bcd36a80 (48,224 blobs, recursive, truncated:false) and odoo/enterprise 404s to anonymous api.github.com. Retrieved 2026-09-18. adversarially verified

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

Loyalty cards with real-time points, plus promotions, coupons, next-order coupons, discount codes and Buy X get Y — all configuration, no bolt-on vendor. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator

guest-loyalty-tiers

Loyalty documentation covers points, promotions and coupons. No status tiers with automatic promotion or demotion. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

Loyalty requires selecting a customer and shows points updated in real time; no offline behaviour is documented anywhere. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator

guest-loyalty-offer-stacking-rules

RE-HOMED to the source tree as addendum s5 directs, because the doc-page absence control was not vocabulary-complete ('combinable|stackable|stacking' 0 over 696 documents proves only that Odoo does not use those words). Settled at grade A by reading the three Community loyalty models field by field. The cited file declares the complete program-level field set - name, active, sequence, company_id, currency_id, pricelist_ids, rule_ids, reward_ids, communication_plan_ids, program_type, date_from, date_to, limit_usage, max_usage, applies_on, trigger, portal_visible, portal_point_name, is_nominative, is_payment_program, available_on - and NOT ONE of them expresses exclusivity, combinability or order of application against another program; the only volume control is 'limit_usage = fields.Boolean(string="Limit Usage")' with max_usage, a count. loyalty_rule.py and loyalty_reward.py add no such field either: their booleans and selections are reward_point_split, reward_point_mode, minimum_amount_tax_mode, mode, reward_type, discount_mode, discount_applicability, clear_wallet, and a COMPUTED is_global_discount that scopes one reward's own target rather than inter-program precedence. The nearest thing to precedence is this model's plain record ordering, "_order = 'sequence'" over an unlabelled sequence Integer - generic Odoo list ordering, not a configurable stacking or precedence rule, and I record it as the honest near-miss rather than suppress it. MODULE/EDITION: Community - loyalty, sale_loyalty, pos_loyalty and pos_restaurant_loyalty are all in the 638. FALSIFIER: an exclusivity or combinability field in the loyalty models, or documented precedence semantics for the sequence field. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/loyalty/models/loyalty_program.py · retrieved 2026-09-05 adversarially verified

Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator

guest-loyalty-targeted-offers

Odoo Marketing Automation and Email Marketing can target audiences via domain filters over customer and order data; not a POS-native offer audience builder. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator

guest-loyalty-rfm-segmentation

No automatic recency/frequency/monetary lifecycle segments; the operator must build pivot filters. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.

guest-loyalty-lifecycle-automation

Studio automation rules support date-field, after-creation and after-last-update triggers with email actions — generic, not shipped restaurant lifecycle campaigns. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator

guest-loyalty-native-email-sms

First-party apps for both channels in the same database, documented in Odoo's manual. Email Marketing: create a mailing with New, set Recipients from in-database models (Mailing List, Contact, Event Registration, Lead/Opportunity, Mailing Contact, Sales Order) with customisable filter equations, then Send, Schedule or Test. SMS Marketing: same Recipients mechanism, message body with live character and SMS-segment count, and Send / Schedule / Test; sending is metered - "Credits must be purchased from Odoo in order to take advantage of the SMS Marketing app; SMS messages will not be sent without credits." Contacts captured in POS are res.partner records in the same database, so no export to a third-party ESP is involved; the per-app cost above the One App Free tier and the SMS IAP credits are commercial, not architectural, limits. https://www.odoo.com/documentation/18.0/applications/marketing/sms_marketing/create_sms.html · retrieved 2026-08-06

Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.

guest-loyalty-consent-management

Odoo mailing uses blacklist/opt-out per email and phone. Per-channel consent timestamp and source of consent are not documented for POS-captured guests. https://www.odoo.com/pricing · retrieved 2026-08-01

Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.

guest-loyalty-10dlc-registration

Both quotes verify verbatim on the cited page and nowhere else in the corpus: on the built-in IAP path, "Currently, Odoo registers itself when possible to avoid extra setup for its customers, however in some countries that is not enough and the client itself must do it.", and on the Twilio path the operator is explicitly on their own - "This can only be done by you, and not by Odoo." So the obligation is disclosed but the regime is never named and never handled in product: '10DLC' and 'A2P' return zero over the corrected 696-document corpus, and I confirmed the SMS Marketing book is FULLY present in that corpus (no sms page is among the 669 census pages missing from it), so this zero is bounded by a complete book rather than by a corpus hole. There is no brand object, no campaign object, no registration-status field and no submission flow. Disclosure without handling is partial, not yes and not no. WIDER SMS FOOTPRINT, checked after the mid-run correction and it does not change the value but does raise the stakes: POS itself has a second outbound A2P surface, since extra/preparation.html tells the operator to install the POS Enterprise SMS Whatsapp module and then select templates for Order received and Order is ready (strings verbatim on THAT page, not on the page cited here) - transactional order-state messaging to guests, with the same unhandled registration obligation and no 10DLC surface of its own. MODULE/EDITION: sms, sms_twilio, mass_mailing_sms and pos_sms are all Community, but that preparation-display messaging path rides pos_preparation_display and whatsapp, both Enterprise-only (absent from the 638). FALSIFIER: an Odoo IAP or SMS page naming 10DLC brand and campaign registration with a submission workflow. https://www.odoo.com/documentation/19.0/applications/marketing/sms_marketing/twilio.html · retrieved 2026-09-05 adversarially verified

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Coupon and loyalty redemptions are order lines and can be pivoted against check totals; no packaged campaign-attribution report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator

guest-loyalty-data-export-portability

Select records in any list view, Action > Export, choose fields, export CSV or XLS - 'the values can be exported from any field in any record', with reusable export presets. Applies to contacts, POS orders and order lines alike. The Cloud SLA adds a full live-database backup 'at any time'. No fee and no support ticket; the docs' only caveat is to batch very large exports to avoid a timeout. https://www.odoo.com/documentation/19.0/applications/essentials/export_import_data.html · retrieved 2026-08-08

Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator

guest-loyalty-review-capture-routing

Value upheld, but one sentence of the standing note is FALSE and is corrected here. On the cited page Helpdesk does trigger the request automatically - "To automatically request ratings from customers once their tickets have closed, an email template needs to be added to the appropriate stage" - and scores three ways, but every response lands in the ticket chatter plus a Customer Ratings report. The standing note's claim that there is no low-score branch anywhere is wrong: applications/websites/livechat/ratings.html, a census page that is MISSING from the 696-document corpus and which I fetched live (200), documents a genuine score-conditional branch - a smile shows a thank-you and a close link, while a neutral or frown opens a comment box that is sent to the operator - and it even publishes a channel's aggregate ratings to the operator's own website. That still fails this cell on two independent grounds: the destination is never a public review site (Google review, review site, NPS, Net Promoter, Trustpilot and Yelp are zero over 696 documents and no such page exists among the 1,158 census docnames), and neither surface is post-transaction - one is ticket-scoped, one is chat-scoped. A SECOND standing-note sentence also falls to the mid-run correction: the outbound POS message set is NOT just the pos_sms receipt - extra/preparation.html documents installing the POS Enterprise SMS Whatsapp module and selecting templates for Order received and Order is ready, plus an in-store Order Status Screen showing Ready for pickup and Almost there (all strings verbatim on THAT page, not on the page cited here). Odoo therefore does message the guest post-order; what it never does is ask for a rating afterwards or route one anywhere. MODULE/EDITION: helpdesk is Enterprise (absent from the 638), but im_livechat and survey ARE Community, so the edition split is not what decides this - the missing routing destination is. FALSIFIER: a documented action branching on rating score to different destinations, one of them a public review site. https://www.odoo.com/documentation/19.0/applications/services/helpdesk/overview/ratings.html · retrieved 2026-09-05 adversarially verified

Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.

guest-loyalty-referral-program

Loyalty offers next-order coupons but no two-sided guest referral mechanic with per-guest codes and first-order attribution. (Odoo Referrals is a recruiting app.) https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator

guest-loyalty-wallet-pass

No Apple Wallet or Google Wallet loyalty pass documented; loyalty is looked up by selecting a customer at the register. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Odoo's GDPR page walks each right by hand: access/portability via the customer portal or Action > Export, rectification via the portal, opt-out by ticking a field, erasure by attempting to delete the contact - which the system blocks where business documents still reference it, leaving anonymisation as the fallback. No packaged DSAR workflow and no deletion propagation into loyalty or mailing-list records. https://www.odoo.com/gdpr · retrieved 2026-08-08

Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.

guest-loyalty-redemption-fraud-controls

No redemption velocity limits, manual-adjustment approval, or employee self-redemption flagging documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator

guest-loyalty-ai-offer-recommendation

Shipped, not roadmap: an AI prompt embedded in an email template is evaluated per recipient at send time, the generated content being inserted into the message automatically, and the shipped prompts adapt the message content to the current record using that record's data. That is genuine AI-generated message content in an outbound marketing surface, which is the offer-content half of the cell. The recommendation half is absent: the page's own example use cases are sales follow-ups, HR communication and project updates, nothing recommends a discount, a target audience or a send time, 'optimal send|best time to send' returns zero over 696 documents, and the loyalty program form has no AI-suggested field. I verified all 12 AI pages are present in the corpus (ai.html, agents, apikeys, default_prompts, document_sort, email-templates, fields, improve_text, live-chat, server-actions, support_operations, voice), so this shortfall is a bounded enumeration and not a corpus hole. MODULE/EDITION: ENTERPRISE-ONLY - no ai, ai_*, *_ai or llm/gpt/gemini/openai module exists among the 638 Community modules, and the AI book never labels itself Enterprise (the same unlabelled-Enterprise trap as pos_preparation_display), so a Community install gets none of it. Partial not no under this record's hardware-kds edition precedent. FALSIFIER: an AI page recommending offer targets or send timing. https://www.odoo.com/documentation/19.0/applications/productivity/ai/email-templates.html · retrieved 2026-09-05 adversarially verified

Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.

guest-loyalty-stored-value-gift

Native gift cards under the Promotions, Coupons, Gift Card & Loyalty Program feature, tied to customer records and shared across POS configs in one database. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.

labor-clock-in-at-pos

Employees log in to the register by badge scan, name selection or PIN, with no extra hardware. True clock-in/out lives in the separate Attendances app. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator

labor-photo-punch-verification

RE-HOMED from the doc page to Community source, which closes this far harder than prose can. The kiosk identification method is a CLOSED Selection of exactly three values - ('barcode', 'Barcode / RFID'), ('barcode_manual', 'Barcode / RFID and Manual Selection') and ('manual', 'Manual Selection') - optionally gated by attendance_kiosk_use_pin, labelled 'Employee PIN Identification'. The camera is bound to barcode reading and nothing else: attendance_barcode_source is a Selection of ('scanner', 'Scanner'), ('front', 'Front Camera') and ('back', 'Back Camera'), string='Barcode Source'. I also read hr_attendance/models/hr_attendance.py: the punch record's complete stored field set is employee_id, department_id, manager_id, attendance_manager_id, check_in, check_out, date, worked_hours, the overtime fields, in/out latitude, longitude, location, ip_address, browser and mode - there is NO image or binary field of any kind, so no photo can be attached to a timecard entry and the non-biometric-mode half of the claim never arises. 'facial|face recognition|buddy punch' returns zero over 696 documents. MODULE/EDITION: hr_attendance is Community and it is the punch device, NOT the POS - pos_hr scopes itself to employee login at the till by barcode or PIN with no punch record. FALSIFIER: an image field on hr.attendance, or a fourth kiosk mode. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/hr_attendance/models/res_company.py · retrieved 2026-09-05 adversarially verified

Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator

labor-offline-time-punch

RE-HOMED AND STRENGTHENED after bounding against the census rather than the corpus, which is what the coordinator's warning was for and it landed: applications/general/offline_mode IS in the 1,159-page Sphinx census and was ABSENT from the 696-document corpus, so my earlier 'offline mode = 0' was a corpus artefact and not a documentation zero. I fetched the page live (200, 408,600 bytes, 1,168 characters of article text) and it decides the cell against the vendor more firmly than absence ever could. Odoo does ship a platform-wide offline mode - it “makes certain data available offline for logged-in users”, and “views or records that were previously opened while online can be re-opened, regardless of whether they were active in the browser at the moment connectivity was lost” - but it is READ-ONLY, and the page says so in terms: “Previously opened records can be viewed but not modified while offline.” A time punch is a write (hr_employee.py's _attendance_action_change CREATES an hr.attendance record, stamped server-side with fields.Datetime.now()), so under Odoo's own documented offline behaviour a punch cannot be taken at all while disconnected, let alone queued and reconciled. The page also caps local data at 2 GB with oldest-first eviction and warns that a hard refresh removes all locally stored data - retention rules, not reconciliation rules; there is no queue, no replay and no duplicate suppression anywhere in it. MODULE/EDITION: hr_attendance and pos_hr are both among the 638 COMMUNITY modules, and the offline framework is web-client-wide, so this holds identically in Enterprise. BOOK COMPLETENESS: applications/hr/attendances is 10 of 10 census pages present in the corpus and applications/hr/payroll 27 of 27, so the 54 missing hr pages the coordinator flagged do not touch this cell. RECORDED AGAINST MYSELF: point_of_sale/controllers/main.py serves /pos/service-worker.js, so the POS REGISTER is a genuinely offline-capable PWA - but pos_hr is register login only and no POS module references hr_attendance, so the punch does not ride that buffer. FALSIFIER: an Attendances or offline-mode page describing writeable offline records or a punch queue. https://www.odoo.com/documentation/19.0/applications/general/offline_mode.html · retrieved 2026-09-05 adversarially verified

Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.

labor-granular-rbac

POS rights are three fixed tiers — Minimal, Basic, Advanced — with a fixed action list per tier, not per-action grants per role and location. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.

labor-manager-override-audit

Session reports show who opened the register and the Employee on each order. No immutable, queryable override-approval trail documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator

labor-native-scheduling

True that Planning is first-party, but it is a separate app: unavailable on the $0 One App Free tier the dossier leans on, and it reaches the operator only via the all-apps Standard/Custom per-user subscription. It is also not a restaurant labor scheduler — no demand forecast from POS sales, no break/minor/fair-workweek rules (the dossier correctly scores all three 'no'), which makes an unqualified yes here inconsistent with its own neighbors. https://www.odoo.com/pricing · retrieved 2026-08-01 adversarially verified

Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator

labor-demand-labor-forecast

Payroll consumes Planning, Attendances and Timesheets; no staffing recommendation generated from POS sales history is documented. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator

labor-realtime-labor-percent

POS reporting covers orders and sessions only; no live labor-cost-to-sales view on a manager screen. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator

labor-overtime-prevention

RE-HOMED off the doc page onto the model that enumerates the rule, because the cell asks about a capability rather than about documentation and the source is the stronger enumeration. hr.attendance.overtime.rule (module hr_attendance, one of the 638 COMMUNITY modules; identical in Enterprise) carries its complete field set here and the only outcome fields are paid = fields.Boolean("Pay Extra Hours"), amount_rate, employee_tolerance and employer_tolerance - there is no warn, block, notify or approval-gate field, and every condition field (base_off 'Quantity'/'Timing', timing_type, expected_hours, quantity_period) evaluates time ALREADY worked. The check-in path confirms there is no gate: hr_employee.py's _attendance_action_change creates the hr.attendance record unconditionally and its only raise is on a check-OUT with no matching check-in. The operator doc agrees and is itself enumerative: overtime.html (a different document, so its wording is reported rather than quoted to this url) says the Action section determines how approved extra time is handled and then offers exactly two checkboxes, Pay extra hours and Give back as time off. The two clock.?in hits at 696 documents are work_entries.html, where the phrase covers an employee who forgot to clock in and out for a shift - a retrospective correction and the Australian payroll page, neither a threshold gate. EDITION: Community and Enterprise alike; APP: Attendances, not point_of_sale. FALSIFIER: a rule field or kiosk prompt that warns on or refuses a check-in against a configured threshold. CENSUS BOUND: applications/hr/attendances is 10 of 10 census pages present in the corpus and applications/hr/payroll 27 of 27, so none of the 54 missing applications/hr census pages is an attendance or payroll page and this verdict is not standing on a hole; the primary instrument is in any case the source model, not a corpus count. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/hr_attendance/models/hr_attendance_overtime_rule.py · retrieved 2026-09-05 adversarially verified

Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator

labor-break-compliance-by-state

Working schedules and country localizations drive payroll rules; no US state-level meal/rest break prompts or missed-break premium flags documented. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.

labor-minor-labor-rules

No age-based hour caps, prohibited windows or school-day limits enforced at scheduling or clock-in. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.

labor-tip-pooling-rules

Tips post as a single [TIPS] product line per order. No pooling or tip-out computation documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.

labor-tip-distribution-audit-trail

Tip lines are attached to orders, and orders carry the Employee, so tips received are traceable. No pool contribution or distribution record exists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator

labor-qualified-tips-w2-reporting

UPHELD, and the standing note's declared HONEST LIMIT is now closed against the vendor rather than left open. POS side: pos.order carries exactly two tip fields - "is_tipped = fields.Boolean('Is this already tipped?', readonly=True)" and "tip_amount = fields.Monetary(string='Tip Amount', readonly=True)" - one undifferentiated total with no cash-versus-charged split and no occupation code; module point_of_sale, one of the 638 COMMUNITY modules and identical in Enterprise. Community side: no module matching 'payroll' exists in the 638, so the open-source edition has nothing to export to. ENTERPRISE side, which the standing note could not reach: applications/hr/payroll/payroll_localizations/united_states.html is now a live 470,825-byte page (probed 2026-09-05) and I read its 23,881 characters of article text. Reported rather than quoted, because it is a different document from this row's url: it documents a W2 Report that produces a CSV for employees to e-file with third-party software, and a W-2 form section whose options it says correspond to checkboxes in box 13 of the W-2 form - box 13 only. Across that whole page 'Box 12' = 0, 'Box 14' = 0, 'occupation' = 0, 'qualified' = 0, and every 'tip' hit is a UI Tip callout, not a gratuity. So the Enterprise US payroll localisation is an ENUMERATING document for W-2 boxes and it enumerates box 13, never box 12 code TP, box 14b or a Treasury tipped-occupation code. The no therefore holds in BOTH editions, not just Community. FALSIFIER: a tipped-occupation field on hr.version or a box-12/14 mapping in l10n_us_hr_payroll. CENSUS BOUND: applications/hr/payroll is 27 of 27 census pages present, and the decisive page was in any case read LIVE off the census rather than off the corpus, so the applications/hr hole does not reach this cell. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/point_of_sale/models/pos_order.py · retrieved 2026-09-05 adversarially verified

Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator

labor-native-payroll

Odoo Payroll computes payslips from contracts and work entries and pays by wire, SEPA or check. No evidence Odoo files payroll taxes as a service. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).

labor-payroll-export-formats

Odoo positions Payroll as the system of record rather than an exporter; no named Gusto, ADP, Paychex or QuickBooks payroll connector documented. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator

labor-shift-swap-workflow

Odoo Planning supports open shifts employees can take, but a manager-approved swap workflow enforcing overtime and role eligibility is not documented. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator

labor-server-performance-metrics

Orders carry the Employee and are analysable in graph/pivot views, so average check is derivable. No packaged void, comp or attachment-rate scorecard. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.

inventory-recipe-bom-costing

Odoo Manufacturing provides multi-level BoMs with sub-assemblies and cost rollup natively, but POS docs never connect recipes to plate cost. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.

inventory-unit-conversion-yields

Units of Measure & Packagings with conversion factors are native and surfaced in POS. No raw-to-usable yield or waste percentage documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator

inventory-theoretical-vs-actual

Physical inventory adjustments produce counted-versus-system variance, but no theoretical usage from sales times recipe versus actual report is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator

inventory-realtime-depletion

POS shows Free To Use units and sales move stock for tracked Goods and Combo products. Modifier-driven ingredient depletion needs BoM/kit setup not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator

inventory-86-auto-sync

No automatic 86 of menu items to POS, online ordering or delivery channels when a component hits zero or a threshold. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.

inventory-count-modes

Odoo Inventory supports full physical inventory, partial adjustments and scheduled cycle counting with dated history — documented in Inventory, not POS. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.

inventory-mobile-count-offline

Odoo Barcode provides mobile scanning for counts; offline tolerance and reconnect sync are not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator

inventory-vendor-catalogs-edi

Odoo supports vendor pricelist import and RFQ/PO email, but no pre-built Sysco, US Foods or PFG EDI catalog integration is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator

inventory-invoice-ocr

Odoo Accounting/Documents offers AI invoice digitization via IAP credits; line-item extraction directly into the inventory ledger was not verified. https://www.odoo.com/pricing · retrieved 2026-08-01

Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator

inventory-price-change-alerts

Vendor pricelists store prices, but no received-price-versus-prior alerting with a configurable threshold is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator

inventory-par-auto-suggest

Odoo reordering rules (min/max) generate suggested purchase orders; a forecast-driven par mode from sales history is not documented for restaurants. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.

inventory-waste-logging

Odoo Inventory Scrap records losses against a scrap location and debits stock; reason codes and a waste-cost report separate from usage variance are not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.

inventory-shelf-life-expiry

I could not re-verify that sentence on the cited POS products page; the rendered page's stock section is a stub linking out to Inventory. Expiry tracking is a real Odoo Inventory feature, but its POS surfacing — the thing the cell is scoring — is not confirmed on the cited source. Same caution applies to inventory-lot-traceability's stronger sub-claim that lots are 'imported automatically onto POS cart lines,' which I also could not verify. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01 adversarially verified

Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.

inventory-bar-partial-bottle

POS supports To Weigh With Scale for by-weight sales, but no partial-bottle liquid counting by weight or bottle fraction is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.

inventory-cogs-gl-export

Odoo Accounting is the GL, so COGS and AP post natively rather than exporting; no QuickBooks/Intacct/NetSuite import-format connector is shipped. https://www.odoo.com/pricing · retrieved 2026-08-01

Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator

inventory-native-not-partner

Inventory installs automatically with POS and Manufacturing/Purchase/Accounting are all Odoo-built — no MarginEdge or MarketMan contract needed. Beyond one app, plan cost applies. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

'Show margins & costs' surfaces price, cost and margin per product in POS, and order pivots give sales mix. No automatic below-threshold margin flagging. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.

reporting-realtime-dashboard

POS dashboard plus Reporting > Orders in graph or pivot view, filterable and groupable; available in a browser and the Odoo mobile app. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

Closing the register produces a comprehensive session report covering all session activity, who opened it, and every order placed during it. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Order statistics pivot by product and variant. Modifiers are attribute values or combo lines, so true modifier-level PMIX is not a first-class report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.

reporting-comps-voids-audit

Orders list shows status, employee and totals, and discounts are order lines. No dedicated comps/voids audit report with reason codes and approver. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.

reporting-cash-over-short

POS cash control with cash-in/cash-out and register close computes a session difference; per-employee over/short reporting is not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

POS reporting is limited to order and session statistics; sales per labor hour and labor percent by hour are not produced. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

Orders are groupable by Employee in pivot/graph, giving average check and volume. No packaged attachment-rate or tips-percent scorecard. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator

reporting-channel-profitability

Orders can be grouped by preset (Dine In/Takeout/Delivery) and by point of sale. No revenue net of marketplace commission by channel. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/presets.html · retrieved 2026-08-01

Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.

reporting-scheduled-delivery

Studio automation rules with timing triggers can email records on a cadence; no built-in 'schedule this report to recipients' control in POS reporting. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator

reporting-public-api

External JSON-2 API at /json/2/<model>/<method> with bearer API-key auth and a per-database /doc page listing available models, fields and methods. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator

reporting-webhooks

'Send Webhook Notification' POSTs selected fields to a URL from any automation rule. No documented retry behaviour and no payload signature. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

'Access to data via the external API is only available on Custom Odoo pricing plans... not available on One App Free or Standard plans.' Self-hosting is exempt. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

POS reporting, pivot analysis and session reports ship with the app itself, including on the $0 One App Free plan. The paywall is on the API, not reporting. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator

reporting-history-retention

Closed sessions and their orders stay in the reporting views ('access the comprehensive report to review all session activities'), filterable and groupable in graph or pivot; data sits in the operator's own database, which is downloadable as a ZIP at any time. No archiving, purge or archive-retrieval fee appears anywhere in the POS or database-management docs, but Odoo publishes no retention-window commitment at all, so a 24-month floor is not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-08

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

Automation rules can fire emails when records match a domain condition. No statistical deviation-from-pattern alerting. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.

reporting-nl-query

UPHELD and quote-checked verbatim at 696 documents. The capability is real and first-party: agents.html's preconfigured 'Natural Language Search' topic 'supports the interpretation of a user query to open the appropriate Odoo view with a set of tools necessary to perform the search', beside 'Information retrieval : a collection of tools to retrieve information about the models', and it runs read-only unless given tools - 'it is only able to provide information, not complete tasks or make changes to the database'. The sibling ai.html (a different document, so reported not quoted here) says the standard Ask AI agent can open views and display reports but cannot create leads or alter data, which is the figure-or-chart half of the rubric answered against the operator's OWN records rather than a help article. All five strings re-verified as single-document hits. EDITION: the AI application is ENTERPRISE - no module matching ai, ai_*, *_ai, llm, openai or gemini exists among the 638 Community modules (the standing note says 637; the oracle is 638), and the book itself only says 'creating and customizing agents requires that the AI application is installed'. Under the record's own precedent (hardware-kds, a standing verified row scoring the Enterprise-only pos_preparation_display as partial) an Enterprise-only, first-party, documented capability is partial - never yes, because Community lacks it, and never no, because it demonstrably exists. Second discount: ai.html's own enumerated list of common requests is translation, summarise, generate, improve and suggest, none of them a sales-or-labor figure. FALSIFIER: an ai module appearing in a Community module listing. CENSUS BOUND: applications/productivity/ai is 12 of 12 census pages present in the corpus, so the AI book is complete and this verdict does not rest on a corpus hole. https://www.odoo.com/documentation/19.0/applications/productivity/ai/agents.html · retrieved 2026-09-05 adversarially verified

Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator

reporting-guest-cohorts

Orders carry the Customer and are pivotable, so frequency and lifetime spend are derivable. No packaged new-versus-returning or cohort report. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator

reporting-sales-forecast

POS reporting is historical only; no forward hourly or daypart sales forecast is exposed. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.

reporting-tip-tax-compliance

Charged tips are captured as order lines attributable to an employee. No declared-versus-charged split, pool detail, or jurisdiction tax liability summary. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.

multi-location-org-hierarchy

Multi-company (parent/child) plus many POS configs per company gives a hierarchy that reporting and record rules scope to, but multi-company requires the Custom plan. https://www.odoo.com/pricing · retrieved 2026-08-01

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

Product records are shared across POS configs and can be shared across companies, so one edit reaches all. No publish action, target-set selection or version history. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/products.html · retrieved 2026-08-01

Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.

multi-location-price-zones

Pricelists give one product different prices per POS, per preset/channel, per customer and per date window without duplicating the product record. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

Order statistics aggregate across POS configs via pivot grouping. No store-versus-store ranking or variance flagging, and labor is not in POS reporting. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/reporting.html · retrieved 2026-08-01

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

Gift cards are database records usable at any POS in the company. No outstanding-liability report or inter-store redemption settlement documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.

multi-location-cross-location-loyalty

One res.partner and one loyalty card serve every POS in the database; cross-company sharing depends on multi-company record-rule configuration. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

Multiple POS configs with distinct product categories, pricelists and receipts can run on one device, but only one session at a time per register. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

Fiscal positions map taxes and accounts per POS, per customer and per preset, with country localization packages preconfigured and inclusive/exclusive handling. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01

Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.

multi-location-central-labor-policy

POS rights tiers are per point of sale but labor rules (overtime, breaks, predictive scheduling) are not enforced at the terminal. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator

hardware-commodity-devices

Browser-based POS running on any device; peripherals are commodity Epson/ESC-POS printers and third-party iMin Android units bought from iMin partners. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.

hardware-os-platforms

Docs name Chromium 142+ browsers (Chrome, Brave, Edge, Vivaldi, Opera) for LNA and iMin Android devices, but publish no full OS/device minimum-spec matrix. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/pos_lna.html · retrieved 2026-08-01

Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.

hardware-handheld-purpose-built

Odoo sells no handheld. Hardware guidance is commodity browser devices, Epson printers and iMin Android POS units from third-party partners. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator

hardware-handheld-battery-swap

No first-party handheld exists, so no battery rating or hot-swap claim is published. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.

hardware-handheld-lte

This page is Odoo's own enumeration of POS hardware AND network topics, which is the right instrument for this proposition: "Odoo Point of Sale supports integration with a variety of hardware, including" payment terminals, cash drawers, customer displays, scales, barcode scanners, receipt printers and in-store electronic shelf labels, and its only network entries are Local Network Access and the IoT system connection. No connectivity product and no failover appears. Re-run over the corrected 696-document corpus with the Sphinx nav stripped, the regex '\bLTE\b|\b4G\b|\b5G\b|cellular' returns ZERO - the standing note's claim of exactly one hit in an HR employee-record page does not reproduce at 696 and I have dropped it. MODULE/EDITION: point_of_sale is core Community, and Odoo ships no first-party handheld at all (the POS is a browser application on merchant-supplied devices), so there is no vendor-supplied failover that could exist to document. FALSIFIER: an Odoo page documenting cellular failover or a cellular-equipped POS device; a commodity phone running the browser POS has its own radio, but Odoo documents no failover behaviour for it. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network.html · retrieved 2026-09-05 adversarially verified

Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).

hardware-offline-mode

Marketing and docs claim reliable online-and-offline operation, but no explicit list of which functions degrade is published. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.

hardware-kds

It is genuinely first-party and the routing/stages/alert-timer/Recall features are all verbatim in the docs — but it is Enterprise-edition-only (module absent from the public odoo/odoo tree; docs treat it as an Enterprise app), so it is not available to the Community self-host the dossier's whole 'best at' thesis rests on. Also verified: 'IoT boxes are not supported.' https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/preparation.html · retrieved 2026-08-01 adversarially verified

Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator

hardware-kiosk

First-party kiosk software on the same menu, optionally on an IoT Box touchscreen. No countertop/freestanding SKUs and no ADA documentation. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-08-01

Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.

hardware-drive-thru

Hardware docs cover printers, scales, customer displays, electronic labels and IoT. No menu boards, confirmation displays or headset integration. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.

hardware-printer-compatibility

'Epson printers are strongly recommended.' Network ePOS direct (Epson), any ESC/POS via an IoT system, LAN/Ethernet supported; Bluetooth explicitly not compatible. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.

hardware-peripherals

Documented pages for scales, customer displays, electronic shelf labels, barcode scanning and cash machines (Cashdro, Cashmatic, Glory). Multi-drawer per terminal not documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.

hardware-p2pe-terminal

Card entry happens on the third-party provider's PTS terminal, keeping Odoo out of the card path, but Odoo does not state the merchant's SAQ type. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator

hardware-tap-to-phone

Verified verbatim by re-reading the cited source file, line 35: module_pos_viva_com is declared with help="The transactions are processed by Viva.com on terminal or tap on phone." - Odoo's own words for tap-to-phone, in core Community source. MODULE/EDITION: the field lives in point_of_sale itself and pos_viva_com IS among the 638 Community modules, so the open-source edition gets it. Partial not yes: of the terminal-provider fields in this one file only Viva.com carries the tap-on-phone clause - the sibling help strings for Adyen, Stripe, Razorpay and Mercado Pago read only "The transactions are processed by" that provider - the acceptance runs in Viva's own application rather than in Odoo's browser POS, and Odoo never names Tap to Pay on iPhone or Tap to Pay on Android anywhere ('tap to pay' 0 and 'softpos' 0 over 696 documents; 'tap on phone' returns exactly 1, this file). It also could not be yes under the brief's rule that a terminal provider's capability never scores an Odoo cell yes. FALSIFIER: a second provider module gaining the same help text. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/point_of_sale/models/res_config_settings.py · retrieved 2026-09-05 adversarially verified

Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator

hardware-pricing-transparency

Odoo publishes no POS hardware SKU prices; devices are sourced from third parties such as iMin business partners. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator

hardware-ownership-vs-lease

CLAIM: hardware can be bought outright as an alternative to a mandatory lease/subscription-bundled rental, and the vendor states which. VERDICT: unknown -> partial/C. NEW SURFACE: www.odoo.com/app/iot-faq (HTTP 200; a fabricated sibling /app/zzq-fabricated-control returns 404, so not a catch-all), the page the IoT docs themselves link as "IoT system FAQ" (odoo/documentation master 05a1e9c6 content/applications/general/iot.rst). This is exactly the falsifier the standing row asked for: an Odoo page stating IoT box purchase terms. EVIDENCE (vendor FAQ, verbatim after tag-strip): "The IoT Box Subscription costs US$ 30.00 /month/box. For each IoT Box Subscription, you get an IoT Box for free (shipping fees included) (special temporary offer)." and "You can buy an IoT Box from our eCommerce for US$ 179.68 *." and "If the IoT Box is connected to a production database, the US$ 30.00 /month/box subscription will be added to the enterprise contract automatically." Docs (grade B, iot.rst / applications/general/iot.html): "An IoT box subscription is required for production use of IoT systems and generating the HTTPS certificate." SHORTFALL (why partial, not yes): (1) buying the box outright is NOT an alternative to the subscription - the US$30/month/box subscription is mandatory for production use whether the box was bought or came free with the subscription, so ownership does not escape the recurring fee; (2) the FAQ does not say whether the "free" subscription box is owned or remains Odoo's; (3) the FAQ's "eCommerce" link, /shop/iot-box-8937, now returns 404 and the live /shop listing holds only goodies and the Scale-Up game, so the outright-purchase offer may be retired (Wayback CDX was offline 2026-09-17, so not dated); (4) grade C, a marketing FAQ. CONTEXT: the POS itself runs in a browser on merchant-supplied devices, and the Windows virtual IoT (iot/windows_iot.rst) needs no Odoo hardware, but iot.rst requires the same subscription for "IoT systems" generally. Retrieved 2026-09-17. https://www.odoo.com/app/iot-faq · retrieved 2026-09-17 adversarially verified

Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator

hardware-usable-after-churn

Hardware is commodity third-party equipment Odoo never sold or provisioned, so it cannot be software-locked — but Odoo publishes no statement to that effect. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator

hardware-rma-sla

Odoo sells no restaurant hardware and publishes no warranty term or advance-exchange SLA. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.

hardware-byod

The POS runs in a browser on any phone, with employee badge, name or PIN login gating access. No documented BYOD security or device-management model. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator

hardware-remote-device-management

The IoT app lists connected devices and the POS exposes an LNA Permission status popup. No fleet console with remote reboot or staged rollout. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/pos_lna.html · retrieved 2026-08-01

Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.

hardware-selfpour-scales

Weighing scales are supported for by-weight products, but no self-pour tap wall, flow meter or pour-spout integration is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/scale.html · retrieved 2026-08-01

Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.

hardware-callerid-integration

Odoo ships a VoIP app that surfaces the contact record on calls, but no documented POS caller-ID popup with order history. https://www.odoo.com/pricing · retrieved 2026-08-01

Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.

extensibility-public-api-docs

External JSON-2 API reference is fully public with no NDA or sales call, plus a per-database /doc page enumerating models, fields and methods. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator

extensibility-api-access-cost

Verified verbatim, and it appears consistently across the 15.0 through 19.0 and master docs — this is longstanding policy, not a 19.0 quirk. Note two refinements the dossier missed: /json/2 is flagged 'New in version 19.0', so anyone on 18.0 or earlier has only XML-RPC/JSON-RPC; and a forum thread claims read access works in practice on lower plans, which is not authoritative and should not be scored. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01 adversarially verified

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

Odoo offers a free trial, a public demo database and runbot builds, and Community Edition self-hosts free — but no purpose-built seeded developer sandbox is documented. https://www.odoo.com/pricing · retrieved 2026-08-01

Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).

extensibility-oauth-partner-apps

External API auth is 'bearer followed by an API key' — a static per-user key, not OAuth 2.0 with scoped, individually revocable operator consent. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.

extensibility-webhooks-push

Automation rules push a 'Send Webhook Notification' POST on model triggers, usable for pos.order lifecycle, but there is no packaged order-event webhook product. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-08-01

Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator

extensibility-webhook-reliability

OVERTURNED from unknown/F. The standing row said the deciding document was missing from disk; both Studio webhook pages are now in the 696-document corpus and I read them in full. DIRECTION first, because the harm the rubric names - an unsigned, un-retried webhook silently dropping orders during a partner outage - is about Odoo PUSHING to a partner: the outbound feature is the 'Send Webhook Notification' server action, and THIS page is its reference. It enumerates the action's entire configuration and it is three items: "This action is used to send a POST API request with the values of the selected Fields to the webhook URL specified in the URL field. The Sample Payload provides a preview of the data included in the request". No signing secret, no HMAC, no retry policy, no backoff, no delivery log, no replay - the rubric needs all three and the enumerating document offers none. Vocabulary-complete absence control over Odoo's own nouns at 696 documents: backoff|back-off = 0, redeliver|re-deliver|replay = 1 and it is AI voice transcription, retr(y|ies|ied) = 5 and none is a webhook (deploy.html, email FAQ, email_marketing, amazon_connector, and a Python stack trace on external_api.html), and webhook = 0 on external_api.html itself. The contrast is the tell: the INBOUND page, webhooks.html, is a different document and I report rather than quote it - it does describe a Rotate Secret URL-secret and an optional Log Calls history reachable from a Logs smart button, so Odoo knows how to write these controls and writes them only for the direction that is not scored here. That is a URL-bearer secret and an inbound request log, not an outbound HMAC signature, a retry policy or a replay facility. DOC-TREE THREE-STATE PROBE, run this session at the coordinator's direction, four plausible paths, all returning the 146-byte / 33-char nginx NEVER-EXISTED control rather than the 132-byte retired meta-refresh stub: studio/automated_actions/webhooks/security.html, studio/automated_actions/webhooks/retries.html, studio/automated_actions/send_webhook.html and developer/reference/external_api/webhooks.html. So the webhook book is exactly the two pages on disk and no reliability page was ever published and retired. EDITION: base_automation IS in the 638 Community modules, so the automation-rule engine and this action ship in Community; only the Studio UI for creating them is Enterprise (web_studio is absent from the 638). Either way the answer is identical, so no edition split rescues the cell. FALSIFIER: a signing-header or retry-policy passage anywhere in the Studio or developer books. CENSUS BOUND, and I closed the developer-book hole the coordinator flagged rather than assuming it away. applications/studio is 8 of 8 census pages present, so the webhook book itself is complete. Of the 33 missing developer/reference docnames only two could bear on this cell - external_rpc_api and extract_api - and I fetched both live: external_rpc_api (200, 33,672 characters) mentions webhook, HMAC, signature, retry, backoff, replay and idempotency ZERO times; extract_api (200, 11,912 characters) exposes a THIRD outbound webhook surface and it has none of the controls either, describing only an empty POST request sent to the caller-supplied webhook_url plus the document token when the result is ready (reported, not quoted to this url, since extract_api is a different document), with hmac, signature, retry, backoff and replay all zero on that page. The remaining 31 missing developer/reference pages are the CLI, the upgrade scripts and view-architecture attribute stubs. So all three of Odoo's outbound webhook surfaces are now enumerated and none is signed, retried or replayable. https://www.odoo.com/documentation/19.0/applications/studio/automated_actions.html · retrieved 2026-09-05 adversarially verified

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

pos.order is writable through the ORM API, but Odoo does not document externally created orders firing to KDS and printers as first-class tickets. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

Menu items, modifiers, and prices can be written and updated via API, not just read. differentiator

extensibility-menu-write-api

product.template, attributes, combo choices and pricelists are ordinary models fully writable over /json/2, subject to access rights. https://www.odoo.com/documentation/19.0/developer/reference/external_api.html · retrieved 2026-08-01

The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator

extensibility-doordash-preferred

DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

'A valid UrbanPiper subscription is mandatory' and Odoo Community does not support the integration — marketplace access is middleware-mediated and paid. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).

extensibility-middleware-compatibility

UrbanPiper is a documented first-class connector covering 25+ marketplaces. Support by Deliverect, Chowly, Otter or Checkmate was not verified. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant/urban_piper.html · retrieved 2026-08-01

Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.

extensibility-accounting-connectors

Odoo Accounting is the native GL with mapped journal entries from POS sessions, so no connector is needed — but no QuickBooks Online or Xero connector ships. https://www.odoo.com/pricing · retrieved 2026-08-01

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

Odoo Payroll is positioned as the system of record; no native export or direct integration with two named third-party payroll providers is documented. https://www.odoo.com/documentation/19.0/applications/hr/payroll.html · retrieved 2026-08-01

The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.

extensibility-app-marketplace

apps.odoo.com is a public, browsable third-party module marketplace with self-install, referenced directly from Odoo's own support forum and docs. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.

extensibility-headless-embedded

UPHELD with one method name corrected. pos_self_order is one of the 638 COMMUNITY modules, so this is not an Enterprise-gated cell. The controller genuinely lets a non-Odoo client drive the transaction engine: the process-order route at line 10 is declared "auth=\"public\", type=\"jsonrpc\", website=True" and creates the order via sync_from_ui, while the kiosk payment route at line 155 calls _payment_request_from_kiosk to drive the terminal. CORRECTION to the standing note: process_order authorises through _verify_authorization(access_token, table_identifier, order); it is the sibling routes (get-order, remove-order, kiosk payment, get-user-data) that call _verify_pos_config. Either way the credential is a pos.config access_token, not a user login, so nothing binds the caller to Odoo's own PWA, and LGPL-3 lets a self-hoster replace the frontend outright. PARTIAL, not yes, because Odoo publishes no headless contract: 'headless' now returns 2 of 696 documents (up from 0) and BOTH are the test framework - backend/testing.html and the HOOT unit-testing page describing headless browsers - so the real doc count for a headless PRODUCT mode is still zero, and no docname in the 1,159-page Sphinx census carries it. These are unversioned private endpoints for Odoo's own kiosk, free to change. FALSIFIER: a published contract for these routes (yes), or a token check binding the caller to Odoo's client (no). CENSUS BOUND: all 44 point_of_sale census pages are present in the corpus, so the headless shortfall is measured against a complete book; the primary instrument is in any case the source controller. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/pos_self_order/controllers/orders.py · retrieved 2026-09-05 adversarially verified

A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator

extensibility-data-portability-exit

'Download a ZIP file containing a database backup by clicking Download Backup', self-service from the database manager, and the docs advise downloading one before deleting a database. The dump restores into the same LGPL-3 code the operator may self-host, and per-model CSV/XLS export covers subsets. Caveat: 'If the Download Backup option is disabled, it means the database is too large to be downloaded using the database manager. Contact Odoo Support to request an alternative download solution.' https://www.odoo.com/documentation/19.0/administration/odoo_online.html · retrieved 2026-08-08

Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.

reliability-offline-order-entry

Vendor claims the POS is 'built to maintain functionality even during temporary network outages'. No documented guarantee for ticket routing or check printing. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator

reliability-offline-card-auth

Verified verbatim on the terminals page, along with the Force done / Cancel manual overrides. No store-and-forward. payments-offline-store-and-forward and payments-offline-decline-liability are upheld on the same evidence. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01 adversarially verified

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

No store-and-forward exists, so no decline-liability position or offline cap is published. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

Local Network Access is documented purely as browser-to-printer/IoT device access. No LAN-only shared check state across terminals is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/pos_lna.html · retrieved 2026-08-01

The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator

reliability-local-transaction-engine

Odoo Online is pure cloud with no edge server, but On-Premise deployment (Custom plan or free Community) puts the whole transaction engine on the operator's LAN. https://www.odoo.com/pricing · retrieved 2026-08-01

Kitchen display and/or kitchen printer routing continues to function while offline.

reliability-offline-kds-printing

LNA lets the browser talk directly to an ePOS printer on the LAN, so kitchen printing may survive an internet outage. The preparation display is server-served. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/pos_lna.html · retrieved 2026-08-01

The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.

reliability-printer-fallback

Printer configuration binds categories to a single printer with no backup printer or KDS failover and no staff alert on unreachable printers. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/restaurant.html · retrieved 2026-08-01

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

UPHELD against the brief's invitation to cut it to no. Every quoted string verified at the line: sync_from_ui's docstring at line 1269 reads "If an order already exists with a status different from 'draft' it will be discarded, otherwise it will be saved to the database. If saved with 'draft' status the order can be overwritten later by this function" - last-write-wins on drafts, first-write-wins once paid; identity is a client uuid guarded at line 388 by _unique_uuid with the message "An order with this uuid already exists"; and _ensure_to_keep_last_preparation_change (line 396) keeps the newer serverDate and logs "Preparation changes were outdated, probably linked to a synching issue." (line 412). Module point_of_sale, one of the 638 COMMUNITY modules, identical in Enterprise. I decline to read the rubric's 'documents' as operator-facing-only: for an LGPL-3 product the published source IS the vendor's publication, and the peer group already scores this shape at partial on published-source evidence - thanx (partial, grade A, an API-doc delivery rule) and urbanpiper (partial, grade A, a webhook circuit-breaker rule) - while the peers scored no are those with NO rule at all (opensourcepos, sambapos, ury). PARTIAL not yes stands on the real shortfall: no 19.0 documentation page describes partition behaviour, and the code never addresses two devices editing one split check during a partition. FALSIFIER: a 19.0 page describing partition/merge behaviour. CENSUS BOUND: all 44 point_of_sale census pages are present in the corpus, so the finding that no operator-facing page documents partition behaviour is bounded by a complete book rather than by the 42% corpus. https://raw.githubusercontent.com/odoo/odoo/19.0/addons/point_of_sale/models/pos_order.py · retrieved 2026-09-05 adversarially verified

The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).

reliability-offline-feature-matrix

No published list of features unavailable offline. A long-standing community question about how offline mode works remains the operator's only reference. https://www.odoo.com/forum/help-1/how-is-the-point-of-sale-offline-mode-working-218314 · retrieved 2026-08-01

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

status.odoo.com exists with per-component sections and a 90-day uptime figure, but the fetched page contained unrendered template tags and Lorem Ipsum incidents. https://status.odoo.com/ · retrieved 2026-08-01

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Verified verbatim: 'unlimited access to our support by email ... 24/5, in English, French, Spanish or Dutch.' Monday to Friday only. https://www.odoo.com/pricing · retrieved 2026-08-01 adversarially verified

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

Implementation runs through Success Packs or Odoo Partners; the ESA contemplates working with an Odoo Partner. First-party on-site go-live is not offered as a product. https://www.odoo.com/pricing · retrieved 2026-08-01

The vendor performs the initial menu build as part of onboarding rather than leaving it entirely to the operator. differentiator

reliability-menu-build-service

Implementation is a separately purchased Success Pack or partner engagement; no standard included menu build is documented. https://www.odoo.com/pricing · retrieved 2026-08-01

A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.

reliability-hardware-replacement-sla

Odoo supplies no restaurant hardware, so there is no replacement or advance-exchange program. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.

reliability-pci-dss-4-attestation

UPHELD, and the audit brief's own accusation against this row is WRONG - the addendum is right that it is stale. The row never quotes the CSA STAR string to this url; it names www.odoo.com/security as a different document and deliberately leaves the string unquoted, which is correct practice, and the quote checker returns 0 MISATTRIBUTED. Verified verbatim on THIS page: 'PCI DSS and Attestation of Compliance Odoo is not PCI DSS-certified because it does not store cardholder data or process payments. Instead, it outsources tokenization and payment to external payment providers'. That is an explicit vendor denial, the strongest form a no can take, and it is exactly the proposition the cell scores - Odoo SA's OWN attestation, not the merchant's Adyen/Stripe/Worldline terminal. I read www.odoo.com/security in full myself (200, 16,413 chars): it offers only CSA STAR Level 1 participation in the CSA Security Trust Assurance and Risk Program plus the CAIQv3.1 questionnaire - a self-assessment, not a third-party attestation - and on that page SOC = 0, ISO 27 = 0, and its only PCI reference is to Odoo's PCI-compliant payment acquirers, i.e. someone else's compliance. I leave all of those unquoted deliberately, because they live in a document other than this row's url. At 696 documents 'P2PE' = 0 and 'PCI DSS' matches 1 document, this one. Doc-tree probe: /documentation/19.0/administration/security.html returns the 146-byte never-existed control, so no compliance page was ever retired either. EDITION-INDEPENDENT: Community is LGPL-3 software the operator hosts, so Odoo SA operates no cardholder data environment to attest; Enterprise/Cloud customers get the security page and nothing more. FALSIFIER: an Odoo-published AoC or a PCI SSC validated-P2PE listing naming Odoo SA. CENSUS BOUND: applications/finance/payment_providers is 25 of 25 census pages present, and no PCI, compliance or security page exists anywhere among the 1,159 census docnames, so the absence of a published attestation is census-bounded and not an artefact of the corpus holding only 42% of the documentation. https://www.odoo.com/documentation/19.0/applications/finance/payment_providers.html · retrieved 2026-09-05 adversarially verified

Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.

reliability-mfa-role-based-access

Backend uses Odoo user accounts with granular access groups and available two-factor auth; POS itself is limited to PIN/badge across three fixed rights tiers. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/employee_login.html · retrieved 2026-08-01

A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.

reliability-self-serve-training

Free public documentation and video tutorials (including POS-specific ones referenced throughout the docs). No POS terminal training/practice mode documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale.html · retrieved 2026-08-01

Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator

reliability-failover-terminal-role

Terminals are browser clients of a central server; no master/primary terminal role exists to fail over. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/pos_lna.html · retrieved 2026-08-01

Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.

reliability-cellular-backup

Network guidance covers Wi-Fi and Ethernet for printers and devices; no cellular/LTE failover is documented. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator

commercial-month-to-month-contract

Score stays partial, but the note is factually wrong and must be corrected before it is quoted anywhere. $31.10 and $61.00 are the REGULAR ANNUAL rates. The published monthly rates are $48.90 (Standard) and $95.25 (Custom) regular, $38.90 and $76.20 promotional. The ESA term-and-30-day-notice reading is verified. https://www.odoo.com/pricing · retrieved 2026-08-01 adversarially verified

Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator

commercial-no-early-termination-fee

UPHELD after checking the precedent the brief pointed at. That precedent - the standing verified row on commercial-rate-increase-clause, which endorses leaving the ETF cell unknown - was written when the ETF cell was grade F and before anyone had read the ESA and the General Terms of Sale to the end; this row is a genuine F->B evidence upgrade and reverting it would replace better evidence with worse. My own absence control over the legal set at 696 documents, searching the terms early termination, termination fee, liquidated damages and cancellation fee: the pattern matches ONE document in the entire corpus and it is a Belgian payroll page - zero in the ESA, the General Terms of Sale and the Partnership Agreement. EDITION SPLIT is the whole answer. COMMUNITY self-host is LGPL-3 (pos_restaurant/__manifest__.py, 'license': 'LGPL-3'), no subscription and no counterparty, so no exit fee is possible - the same construction on which the open-source peers opensourcepos, tastyigniter and ury score yes. ENTERPRISE fails the rubric's affirmative test: the ESA (Version 12) nowhere STATES a no-ETF position and grants no mid-term cancellation right, the only exit being 'a written notice of termination minimum 30 days before the end of the Term', so the remaining Term's fees are the real exit cost. Every monetary penalty in the ESA is triggered by something other than cancelling - '300% of the applicable list price for the actual number of Users' for using Enterprise Edition after termination (verified verbatim), a EUR 30 000 non-solicitation sum, and 25% for running a non-Covered Version. FALSIFIER: an order form or Cloud-specific term naming a cancellation charge. CENSUS BOUND, run this session after the coordinator flagged 27 unread legal/terms pages: of the 28 legal docnames absent from the corpus, exactly THREE are English non-LaTeX documents (legal/coc, the legal/terms index, and legal/terms/odoo_sh_terms) and I fetched and read all three live; the other 25 are 22 i18n translations and 4 _tex renderings of the same three agreements already in the corpus. The legal/terms index is itself the publisher's enumeration of its terms and names exactly four: the Odoo.sh Beta Program, the Enterprise Subscription Agreement, the Partnership Agreement and the General Terms of Sale. All four have now been read. odoo_sh_terms is a 2017 Version 1 AS-IS beta disclaimer under which the customer assumes all risk of loss of information or data; it adds no fee, window or ownership clause. So the legal set is closed and this cell's zeros are census-bounded, not corpus-bounded. https://www.odoo.com/documentation/19.0/legal/terms/enterprise.html · retrieved 2026-09-05 adversarially verified

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

ESA §1: auto-renews for an equal Term unless either party gives written notice of termination at least 30 days before the end of the Term. Publicly readable. https://www.odoo.com/documentation/19.0/legal/terms/enterprise.html · retrieved 2026-08-01

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Odoo is not an acquirer and documents 13 independent terminal providers; the merchant contracts payments entirely outside Odoo. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator

commercial-interchange-plus-published

Odoo publishes no processing rates of any structure because it does not provide processing. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/payment_methods/terminals.html · retrieved 2026-08-01

The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator

commercial-rate-increase-clause

Verified, as are the 30-day auto-renewal notice (commercial-autorenew-terms-published, yes) and the 300%-of-list-price post-termination breach fee. The dossier is right that 300% is a breach penalty and not an ETF, and right to leave the ETF cell unknown. https://www.odoo.com/documentation/19.0/legal/terms/enterprise.html · retrieved 2026-08-01 adversarially verified

Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).

commercial-pricing-published

Exact dollars are published, but the unit is per user per month, not per location or per terminal — terminal count is not a pricing dimension in Odoo. https://www.odoo.com/pricing · retrieved 2026-08-01

Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator

commercial-module-unbundling

One App Free is a single app at $0; Standard and Custom are all-apps flat per user. No à la carte purchase or cancellation of individual modules. https://www.odoo.com/pricing · retrieved 2026-08-01

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

All hardware is third-party and bought outright with no Odoo lease, but Odoo publishes no prices for terminals, KDS screens or printers. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator

commercial-hardware-not-locked

Documented non-proprietary options: any Chromium browser device, Epson ePOS network printers, any ESC/POS printer via IoT, and third-party iMin Android units. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/hardware_network/receipt_printers.html · retrieved 2026-08-01

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

Any list view - POS orders, order lines, payments, employees, attendances - exports via Action > Export to CSV or XLS, with field selection and saved presets; 'the values can be exported from any field in any record'. No ticket, no fee. The Cloud SLA adds a full database backup 'at any time', and the JSON-2 external API is documented for programmatic pulls. https://www.odoo.com/documentation/19.0/applications/essentials/export_import_data.html · retrieved 2026-08-08

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

'Generated gift cards can be accessed through the Gift Cards smart button' (and eWallets likewise), each issued card a record with Expiration Date, Partner and Balance. Loyalty cards appear the same way from the program form and via a Loyalty Cards smart button on the contact. Being ordinary models, they fall under Action > Export to CSV/XLS - 'the values can be exported from any field in any record' - and under the full database backup. https://www.odoo.com/documentation/19.0/applications/sales/sales/products_prices/ewallets_giftcards.html · retrieved 2026-08-08

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

OVERTURNED AND RE-HOMED, and the brief's challenge to this row is answered by a clause nobody had quoted. The brief asked whether the Privacy Policy's three-week deactivation period earns partial when it is framed as retention for reactivation rather than retrieval. It does not have to: ESA 6.5 Data Protection (h) binds Odoo SA to "permanently delete all copies of the Customer’s database in possession of Odoo SA, or return such data, at the Customer’s choice, upon termination of this Agreement, subject to the delays specified in Odoo SA’s Privacy Policy". That is a contractual RETRIEVAL right at the customer's election, and it incorporates by reference the very window the standing row cited: www.odoo.com/privacy states, in a different document that I therefore report rather than quote to this url, that a cancelled Odoo Cloud database is kept deactivated for three weeks as a grace period during which the customer can change their mind, and is then destroyed. Retrieval right plus a defined number of days, both published, is the rubric satisfied. Corroborating but weaker, and again a different document: www.odoo.com/security says manual backups of live data can be downloaded at any time from the control panel. EDITION: the ESA and the Privacy Policy bind ENTERPRISE / Odoo Cloud customers only; a COMMUNITY self-hoster is under LGPL-3 with no counterparty and already holds the database and its filesystem, so the cell is vacuous in their favour - the same construction on which opensourcepos scores yes. FALSIFIER: an ESA amendment or Cloud term stating that a deactivated database cannot be exported or returned. CENSUS BOUND, run this session after the coordinator flagged 27 unread legal/terms pages: of the 28 legal docnames absent from the corpus, exactly THREE are English non-LaTeX documents (legal/coc, the legal/terms index, and legal/terms/odoo_sh_terms) and I fetched and read all three live; the other 25 are 22 i18n translations and 4 _tex renderings of the same three agreements already in the corpus. The legal/terms index is itself the publisher's enumeration of its terms and names exactly four: the Odoo.sh Beta Program, the Enterprise Subscription Agreement, the Partnership Agreement and the General Terms of Sale. All four have now been read. odoo_sh_terms is a 2017 Version 1 AS-IS beta disclaimer under which the customer assumes all risk of loss of information or data; it adds no fee, window or ownership clause. So the legal set is closed and this cell's zeros are census-bounded, not corpus-bounded. The Odoo.sh beta terms cut mildly against the operator on that platform, since the customer there assumes the risk of data loss, but they neither create nor remove a retrieval window and the ESA governs the Enterprise subscription this cell is scored on. https://www.odoo.com/documentation/19.0/legal/terms/enterprise.html · retrieved 2026-09-05 adversarially verified

Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator

commercial-data-ownership-clause

UPHELD, and the brief's worry that the ownership sentences sit only in a Privacy Policy rather than an agreement is met by the ESA. All three quotes re-verified as single-document hits at 696 documents: on ownership, 'any information or content you submit or upload into your database is your own, and you control it fully' and 'you always retain ownership and full control on this data'; on vendor use, the Third Party Disclosure section's 'We do not sell or trade your data.' The agreement side is stronger than the standing note said: ESA 6.5, in legal/terms/enterprise.html and therefore reported rather than quoted to this url, makes the Customer the Controller of the Personal Data in its database, binds Odoo SA at (a) to process that data only when and as instructed by the Customer and only to perform a Service under the Agreement, and at (h) requires delete-or-return on termination. The only vendor use the ESA reserves is instance telemetry, expressly limited there to the running of an instance, the number of Users, the installed Apps and the number of lines of code of Covered Extra Modules - not transaction or customer data. EDITION: the Privacy Policy and ESA govern ENTERPRISE / Odoo Cloud; for a COMMUNITY LGPL-3 self-host Odoo SA never receives the data, so the constraint is moot in the operator's favour - the same construction on which opensourcepos scores yes. The residual weakness stays on the record: the no-sell sentence is a policy statement, not a warranty of title, and it is unqualified rather than carved out for aggregated use. FALSIFIER: an ESA or order-form clause licensing Odoo to use customer database content for its own products. CENSUS BOUND, run this session after the coordinator flagged 27 unread legal/terms pages: of the 28 legal docnames absent from the corpus, exactly THREE are English non-LaTeX documents (legal/coc, the legal/terms index, and legal/terms/odoo_sh_terms) and I fetched and read all three live; the other 25 are 22 i18n translations and 4 _tex renderings of the same three agreements already in the corpus. The legal/terms index is itself the publisher's enumeration of its terms and names exactly four: the Odoo.sh Beta Program, the Enterprise Subscription Agreement, the Partnership Agreement and the General Terms of Sale. All four have now been read. odoo_sh_terms is a 2017 Version 1 AS-IS beta disclaimer under which the customer assumes all risk of loss of information or data; it adds no fee, window or ownership clause. So the legal set is closed and this cell's zeros are census-bounded, not corpus-bounded. odoo_sh_terms contains no licence for Odoo to use customer content, so reading it does not disturb the constraint half of this cell. https://www.odoo.com/privacy · retrieved 2026-09-05 adversarially verified

Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.

commercial-pci-p2pe-tokenization

UPHELD. Quotes verified verbatim on this page, given as contiguous fragments rather than joined with an ellipsis: "you only need to complete the minimal Self-Assessment Questionnaire (SAQ) with the provider to obtain the Attestation of Compliance (AoC) and achieve PCI compliance", and "Odoo should not be mentioned as a payment processor or a third-party service provider in the SAQ". The premise is stated on the same page as "it outsources tokenization and payment to external payment providers". Two of the rubric's three elements fail and one is met, which is what partial means: tokenization IS documented and enumerated (the Supported payment providers table carries a Tokenization column, and the page states "a payment token is created in Odoo to be used as a payment method for subsequent payments", the underlying card data being held by the provider), a scope reduction IS asserted, but 'minimal' is not a named SAQ type - no SAQ A, SAQ A-EP or SAQ P2PE-HW designation appears anywhere in the 696 documents, and a search for P2PE and point-to-point encryption returns 0, so no validated P2PE solution is claimed. Caveat kept from the standing note and re-confirmed: this page is scoped to ONLINE payment providers for the portal and eCommerce, not to card-present POS entry, which happens on the third-party terminal. EDITION-INDEPENDENT: the position turns on the acquirer, not on Community versus Enterprise, and point_of_sale plus the pos_* terminal modules are all in the 638 Community list. FALSIFIER: a page naming the applicable SAQ type, or a PCI SSC P2PE listing covering a terminal deployment Odoo documents. Peer distribution agrees this shape is partial (0 yes, 29 partial of 46). CENSUS BOUND: applications/finance/payment_providers is 25 of 25 census pages present in the corpus, so this zero is bounded by a complete book and not by the 153 missing applications/finance pages, none of which matches pci, secur, complian or card except an expense-cards page. CENSUS BOUND, run this session after the coordinator flagged 27 unread legal/terms pages: of the 28 legal docnames absent from the corpus, exactly THREE are English non-LaTeX documents (legal/coc, the legal/terms index, and legal/terms/odoo_sh_terms) and I fetched and read all three live; the other 25 are 22 i18n translations and 4 _tex renderings of the same three agreements already in the corpus. The legal/terms index is itself the publisher's enumeration of its terms and names exactly four: the Odoo.sh Beta Program, the Enterprise Subscription Agreement, the Partnership Agreement and the General Terms of Sale. All four have now been read. odoo_sh_terms is a 2017 Version 1 AS-IS beta disclaimer under which the customer assumes all risk of loss of information or data; it adds no fee, window or ownership clause. So the legal set is closed and this cell's zeros are census-bounded, not corpus-bounded. https://www.odoo.com/documentation/19.0/applications/finance/payment_providers.html · retrieved 2026-09-05 adversarially verified

Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.

commercial-pci-dss-4-controls

UPHELD with the counts re-run at 696 documents and one of them corrected downward. The vendor disclaims the premise in terms: 'Odoo is not PCI DSS-certified because it does not store cardholder data or process payments' - verified verbatim here - so there is no cardholder data environment for Odoo to state 4.0.1 controls over, and this is a denial rather than a silence. Absence controls at 696: a search for PCI DSS matches ONE document, this page (the standing note said two, which was wrong); SAQ likewise one; requirement 6.4.3, 11.6.1 and payment-page script integrity return nothing; and the multi-factor/2FA hits are the generic users, 2fa and access-rights pages describing optional backend two-factor authentication with no CDE scoping and no coverage of POS logins, which authenticate by PIN or badge in pos_hr. Doc-tree three-state probe adds a control the standing note lacked: /documentation/19.0/administration/security.html returns the 146-byte / 33-char NEVER-EXISTED nginx body, so no compliance or security page was published and later retired; and www.odoo.com/security, which is live, carries CSA STAR and CAIQv3.1 only, with SOC and ISO 27 both returning zero on that page. EDITION-INDEPENDENT: a COMMUNITY LGPL-3 self-hoster owns the whole environment and receives no control statement, and an ENTERPRISE/Cloud customer gets the same security page. FALSIFIER: an Odoo compliance page enumerating the future-dated 4.0.1 controls. CENSUS BOUND: applications/finance/payment_providers is 25 of 25 census pages present, so the zero is bounded by a complete book; of the 153 missing applications/finance census pages none matches pci, secur, complian, card or fraud except applications/finance/expenses/expense_cards, which is an employee expense-card page. No PCI or compliance page exists anywhere among the 1,159 docnames. https://www.odoo.com/documentation/19.0/applications/finance/payment_providers.html · retrieved 2026-09-05 adversarially verified

Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.

commercial-privacy-dsar-tooling

A guest record can be located, exported (portal or Action > Export) and deleted by hand, and the subscription agreement includes 'Data Protection Clauses (often referred to as a Data Processing Agreement), as required by the GDPR' with no signature step - customers 'automatically benefit'. But there is no in-app DSAR queue or one-click subject package, and erasure is refused where business documents reference the contact, leaving anonymisation and no deletion propagation. https://www.odoo.com/gdpr · retrieved 2026-08-08

Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator

commercial-wcag-kiosk-accessibility

UPHELD, with the standing note's control figure withdrawn: it cited the 9,748-character ruler from BRIEF-ODOO.md, the addendum gives 3,363, and the two disagree only because of the stripper, so neither number is citable on its own. What the control establishes is INVARIANCE, and I measured my own in the same run with my own stripper (script and style bodies removed before tags): www.odoo.com/accessibility = 404 at 66,947 bytes, www.odoo.com/vpat = 404 at 66,362 bytes, and the fabricated control www.odoo.com/zzq-fabricated-control-beta = 404 at 67,857 bytes - three different byte lengths because the page echoes the requested path, and all three identical at 3,363 characters of text on my stripper, against 5,866 for a live page (www.odoo.com/cloud-sla). So no accessibility or VPAT page exists. Doc-tree three-state probe agrees: .../point_of_sale/extra/accessibility.html returns the 146-byte / 33-char NEVER-EXISTED control, not the 132-byte retired-stub, so no such page was ever published. VOCABULARY CONTROL IN ODOO'S OWN NOUNS, widened at the coordinator's direction because a zero on WCAG/VPAT alone would only prove the word absent. At 696 documents with nav stripped: WCAG, VPAT and accessibility conformance = 0; a11y = 0; screen reader = 0; aria- and role="button" = 0; high contrast and colour contrast = 0; Section 508, EN 301 and ADA compliance = 0; assistive, braille, tactile, audio jack and headphone = 0. The only near-misses are a single keyboard-navigation hit on developer/reference/frontend/owl_components.html, which is framework guidance and not a kiosk mode, and six text-size/font-size/zoom hits (HTML editor, email templates, the KDS preparation display's font size, the PDF quote builder, an ecommerce product page and a backend performance page), none of them a non-visual access affordance. No docname in the 1,159-page Sphinx census carries wcag, vpat or accessib. The zero is now vocabulary-complete rather than a wording artefact. The cited page is the enumerating one: it says 'Select Kiosk to let customers browse the menu or product catalog, place orders, and pay directly at a self-ordering kiosk' and then lists the kiosk's complete configuration set - Home buttons, Service location and payment options, Launch on IoT Box, Language, Splash screens, Background - with no non-visual access mode, no audio output, no tactile input and no screen-reader affordance. EDITION: pos_self_order is one of the 638 COMMUNITY modules, so Community and Enterprise ship the same unaudited kiosk and there is no edition split. Kept from the standing note because it is right: the absence of a published report is not proof the UI fails WCAG - but the cell scores publication, and publication is a measured zero. Peer distribution: 0 of 44 records score this yes. CENSUS BOUND, which is the answer to the corpus-hole objection: all 44 point_of_sale census pages are present in the corpus, so the kiosk enumeration is complete, and searching the whole 1,159-name census for access, a11y, wcag, vpat or disab returns only three pages and all three are access RIGHTS - general/users/access_rights, general/users/user_portals/portal_access and developer/tutorials/restrict_data_access - i.e. permissions, not accessibility. There is no accessibility book in Odoo's own build manifest to be missing from the corpus. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/self_order.html · retrieved 2026-09-05 adversarially verified

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

Pricing features cover discounts, pricelists, cash rounding and fiscal positions only. No cash-discount, surcharge, or debit-exclusion engine exists. https://www.odoo.com/documentation/19.0/applications/sales/point_of_sale/extra/pricing.html · retrieved 2026-08-01