A customer-facing now-serving / preparing / ready display that calls out order numbers with a chime for takeaway and QSR pickup. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $199.00 USD; request a quote for a scoped proposal.

A customer-facing now-serving / preparing / ready display that calls out order numbers with a chime for takeaway and QSR pickup. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19.
现在无需付款。此操作会向我们的团队发送报价请求——我们会通过邮件跟进价格和后续步骤。
Takeaway and QSR pickup flow breaks down at the counter, not in the kitchen. Customers crowd the till asking "is my order ready?", staff shout numbers over noise, and the same order gets handed out twice or missed entirely. Odoo Point of Sale ships a kitchen/preparation display (pos_preparation_display / KDS in Enterprise) that tells the kitchen what to cook, but there is no native customer-facing screen that shows a guest their order number moving from preparing to ready. The KDS is staff-side; the receipt printer is one-shot; and the standard POS customer display mirrors the cart, not the pickup queue. There is simply no out-of-the-box now serving board in either Community or Enterprise, so venues resort to buzzers, whiteboards, or a spare tablet with a spreadsheet.
Two-column customer display (Preparing vs Ready) rendered as a full-screen OWL component on a dedicated public POS route
Order-number call-out with a configurable browser chime and optional Web Speech text-to-speech announcement on the ready transition
Auto-advance from KDS bump: an automated action / bus.bus push moves an order from preparing to ready when its preparation ticket is marked done
Live estimated wait-time figure computed via @api.depends from rolling recent order throughput, refreshed without a full page reload
Fully branded layout (logo, colors, fonts, optional promo/menu strip) delivered as editable QWeb/OWL templates you own
New display-state model projecting each pos.order into preparing / ready / called / collected without mutating the core POS order flow
We build a dedicated pickup-display module that reads directly from your existing POS order lifecycle so no one has to re-enter anything. Technically it is a standard Odoo addon: a __manifest__.py declaring dependency on point_of_sale (and the preparation display where present), a models.Model that projects each pos.order into a lightweight display state (preparing, ready, called, collected) with @api.depends computes for estimated wait time, and an OWL front-end component served as a full-screen public route. When a kitchen ticket is bumped on the KDS, an automated action (or bus.bus push) auto-advances that order number from the Preparing column to the Ready column in real time — no polling refresh, no manual toggling. The Ready transition fires a browser chime and optionally speaks the order number, so guests look up when their number is called instead of hovering at the counter.
The screen itself is fully brandable: your logo, colors, fonts, and an optional promo/menu strip, laid out as QWeb/OWL templates you own and can restyle. Two columns (Preparing vs Ready) with large high-contrast order numbers readable across a food court, an audible chime plus configurable call-out, and a live estimated-wait-time figure computed from your recent throughput. Because it rides on Odoo's ORM and the JSON-RPC/XML-RPC layer, the same order states are queryable by other systems — a second screen, a mobile "your order is ready" SMS trigger, or a self-order kiosk — without duplicating data. Access is locked down with ir.model.access.csv and record rules so the public display route exposes only order numbers and status, never customer or payment data.
Because this is build-to-order, ECOSIRE builds it against your Odoo version and your POS configuration — we do not ship a generic zip and wish you luck. After a short scoping call we confirm the exact columns, chime behavior, wait-time logic, branding, and which screens run where, then develop and test on a staging copy of your database. Typical delivery is 2 to 4 weeks from confirmed scope. You receive the full installable source, deployment on your Odoo 17.0, 18.0, or 19.0 (Community or Enterprise), user training, and a post-go-live support window. The git repository is handed to you at the end, so you are never locked to us.
Runs high-volume takeaway counters and needs guests to self-monitor their order instead of crowding the till. Wants order numbers auto-called from the kitchen bump with a clear ready column and a chime staff don't have to trigger.
Serves a steady stream of pickup orders and wants a clean, branded now-serving screen on a wall-mounted display that matches the shop's look and reduces 'is mine ready?' interruptions during rushes.
Manages several stalls under one roof and needs a per-vendor display filtered by pos.config, plus consistent wait-time signals, without giving each stall a separate ad-hoc tablet-and-spreadsheet setup.
Owns the Odoo instance and wants a clean, upgrade-safe addon that reuses the existing POS order and preparation-display data, respects access rules, and hands over as a git repo they can maintain in-house.
在 ecosire.com 上购买许可证并从您的帐户仪表板下载 POS Queue & Order-Status Display (Pickup Screen) 模块 ZIP。
将 ZIP 解压到服务器上的 Odoo 自定义插件文件夹中(或通过“应用程序”>“从 Odoo.sh / runbot 上的文件安装”上传)。
激活开发者模式,打开应用程序,单击更新应用程序列表,搜索 POS Queue & Order-Status Display (Pickup Screen),然后按安装。
打开新菜单,粘贴您的 ECOSIRE 许可证密钥,连接任何外部凭据(Shopify、Amazon、Stripe 等),然后保存。
运行内置连接测试,同步前 10 条记录,并安排定期 cron。如果出现任何问题,请联系支持人员。
| 标准 | 伊科西尔 | 定制建造 | 竞争对手 | 奥杜本机 |
|---|---|---|---|---|
| Customer-facing pickup screen | Purpose-built Preparing/Ready board with call-out | Possible but you design it from scratch | Some offer a basic board, often fixed layout | |
| Auto-advance from KDS bump | Wired to preparation display / bus in real time | You build and debug the trigger yourself | Varies; often manual toggle or polling | |
| Order-number chime & call-out | Configurable chime plus optional voice announce | DIY audio handling and browser autoplay quirks | Sometimes a fixed sound, rarely voice | |
| Estimated wait-time display | Computed from live throughput via @api.depends | You define and maintain the calculation | Uncommon or static placeholder | |
| Version & edition fit | Built for your 17/18/19, Community or Enterprise | Whatever you scope and test yourself | Per-version listings; edition support varies | |
| Branding & layout | Your logo, colors, fonts in editable QWeb/OWL | Full control, full build effort | Limited theme options, often locked | |
| Privacy / access control | Record rules expose only number + status | Your responsibility to lock down | Depends on vendor implementation | |
| Ownership & support | Git handover + post-go-live support window | In-house team owns all maintenance | Vendor-controlled updates, ticket support |
No. This is a build-to-order module. ECOSIRE develops it against your specific Odoo version and POS configuration, tests it on a staging copy of your database, then installs and supports it. You are not downloading a generic zip from apps.odoo.com.
Typically 2 to 4 weeks from confirmed scope. After a short scoping call we lock down columns, chime and call-out behavior, wait-time logic, branding, and which screens run where; that agreed scope sets the timeline. Complex multi-outlet or custom-integration work sits at the upper end.
It works on both. The display reads from the standard point_of_sale order flow, so it runs on Community. Where Enterprise's native preparation display (KDS) exists, we wire the auto-advance directly to the kitchen bump; on Community we implement an equivalent trigger so orders still move from preparing to ready automatically.
When a kitchen ticket is bumped on your preparation/kitchen display, an automated action (or a real-time bus push) advances that order number into the Ready column and fires the chime. Staff can still manually recall or mark an order collected from an optional console for edge cases like remakes or walk-offs.
The display route is locked down with ir.model.access.csv and record rules to expose only the order number and its status. Customer names, order lines, prices, and payment data are never sent to the public screen.
We build for Odoo 17.0, 18.0, or 19.0. Every engagement includes a post-go-live support window for defect fixes and configuration tuning. Because you receive the full git repository, you can maintain it in-house, and we can quote a version migration when you later upgrade your Odoo.
Yes. Displays are filtered per pos.config, so a food court can run one board per vendor. Because the order states live in the ORM, they are queryable over JSON-RPC/XML-RPC, letting you add a second screen, a self-order kiosk, or an SMS 'order ready' trigger against the same live data.
A customer-facing now-serving / preparing / ready display that calls out order numbers with a chime for takeaway and QSR pickup. ECOSIRE builds, installs, and supports it on your Odoo 17, 18, or 19.