Foodics as the till, Odoo as the record
Foodics already closes the ticket
Foodics is a restaurant POS. Branches, menus, modifiers, staff, customers and tenders live there. The till is not waiting for Odoo in order to sell.
Odoo is the system that has to hold what that till already decided: what was sold, with which modifier, at which tax, on which payment, at which branch. The integration is that handoff, not a second Foodics.
You hold the Foodics account. We authenticate Odoo against it and hand the credentials back at go-live.
- Platform
- Foodics (restaurant POS)
- Odoo side
- Point of Sale, products, partners, taxes, payments, sessions
- Direction
- Foodics → Odoo for master data and closed orders. Orders can be written back when Odoo is the source.
- Availability
- Built to order. Not a module on the Apps Store.
Live tickets do not belong in ERP twice
A Foodics floor is noisy. Draft tickets, splits, voids, combos, kitchen notes. If every tap writes to Odoo, POS sessions never close and stock moves on orders that the guest has not paid.
Master data drifts. A modifier created on the till never appears in Odoo. A tax group exists in both places under different names. The ticket then posts with a product Odoo cannot price.
The closed ticket is the one that matters. Open tickets change. Closed and refunded tickets are the ones finance will ask about. Syncing too early is how you get two versions of the same sale.
Payments are not a total. Multiple tenders, discounts, combo lines, kitchen notes. A single “paid” flag without line-level mapping is how cash-up disagrees with Foodics.
Sessions outlive the shift. A POS session left open because a draft ticket will not close is an operations problem that looks like an integration bug.
Taken in the same order:
Closed tickets, mapped masters, sessions that can end
Masters first. Branches become POS configs. Users, customers, products, modifiers, payment methods, tax groups, taxes, charges and tags sync into Odoo on a schedule you set. A ticket is not imported against a product that does not exist yet.
Closed orders, not the live floor. When Foodics closes (or voids) a ticket, a webhook creates or updates the POS order in Odoo: lines, combos, modifiers, kitchen notes, discounts, payments. Refunds reverse the Odoo lines rather than leaving a positive sale behind.
Tenders on the order. Foodics payments become Odoo POS payments against the mapped method. The order is paid in Odoo because the till was paid, not because someone typed the total again.
A history you can inspect. Each call is stored. When a ticket is missing, the question is which payload failed, not whether anyone remembers yesterday’s shift.
Sessions that close. Open POS sessions can close on a timer you configure, so an overnight session is a setting, not a ritual. Draft tickets that would block close need a separate operations rule; the timer is not a licence to delete unpaid work.
Ordable is a different storefront. Do not treat this page as that estate. Ordable →
Named as a till, not as a client
Foodics is on the Integration Engineering roster as POS and commerce capability. It was delivered to operators who run Foodics on the floor and Odoo in the back office. The end clients stay unnamed.
It is not the three-branch Ordable estate. Mixing the two on this page would imply a client we have not cleared and a stack they do not run.
- Delivered
- Branches, users, customers, products, modifiers, taxes, payments, closed POS orders, sync history, session auto-close
- Client
- Unnamed
- Sibling storefront
- Ordable (separate engagements)
A sandbox till, and a rule for when a ticket exists
A Foodics account with API access, and a branch you will close real test tickets on. Sandbox means closed orders, not only a token.
Written ownership: Foodics owns the floor; Odoo owns stock and books. If both may edit the menu, say so before go-live. Dual writes on the same product are how names fork.
Tax and tender maps, including the methods used for comps and delivery aggregators.
An Odoo POS config per Foodics branch, and a policy for how long a session may stay open.
Someone on the floor who will void and refund in sandbox the way they do on a Saturday. Those are the payloads that break a sync built only on happy sales.
We will not treat a nightly CSV of Foodics sales as this integration. If that is the actual need, say so; it is a different, smaller job.
Is Foodics the till, or is it also the books?
If the floor is already on Foodics and Odoo is supposed to hold stock and tenders, send the branch count and whether refunds have to post the same day. That is enough to tell you if this is in scope.