Delivery Orders in your POS — PedidosYa and Rappi Land in the Till, Not in a Sale Order Nobody Opens
A restaurant runs on the Point of Sale: the session, the kitchen printer, the Z report at closing. This add-on drops each delivery order into the open POS session — paid, taxed like any other line, printed in the kitchen. And when the till is closed, nothing is ever lost.
Where every delivery order landed — and what the kitchen actually saw.
- The cook never opens Sales — somebody has to shout the order across the shop
- The Z report closes without it, so the till says 800 and the bank says 1,100
- Delivery revenue lives in one place and shop revenue in another
- The order becomes a paid POS order in the session that is running right now
- The kitchen ticket prints on the POS's own printers
- It closes with the day — the Z report is the day's real total
Works with jjro_pedidosya and jjro_rappi (sold separately). Install it and they start feeding the POS — nothing to configure in the connectors themselves.
From the app to the kitchen
This platform, this shop, goes to this Point of Sale, paid with this method. One shop or all of them.
A paid POS order in the open session, with the platform as its payment method — so the closing shows what each one owes you.
Straight to the POS's order printers. The cook does not need to look at a screen, or at Sales.
The till records what the customer paid — to the cent
A delivery platform charges a final price: what the app shows is what the customer paid, tax and all. So the tax is taken out of that price, never added on top. An order the customer paid 95.70 for is 95.70 in your till — not 110.06. Copy the price and add VAT on top, as a naive integration does, and you declare a tax you never charged. Product taxes and the shop's fiscal position are applied exactly as they are on a line typed at the counter.
A PedidosYa order, paid, in the session — it closes with the day like any other ticket.
A closed till never becomes a lost order
Orders arrive at 01:00, and sometimes the session is already closed. This add-on does not invent a session that does not exist, and it does not drop the order: it falls back to a sale order, exactly as before, and the cockpit tells you which orders did and why. The same is true if a kitchen printer is off — the order still lands in the POS. Printing is a bonus, never a blocker.
Set up in one screen
A route is one line: the platform, the shop, the Point of Sale and the payment method. Leave the shop empty and every shop of that platform goes to the same till — which is what a single restaurant wants. A chain routes each branch to its own POS and its own warehouse.
AI analysis — optional, your own key
Add your own Anthropic Claude or OpenAI key and get a read of the service — what landed in the till tonight, what fell back to Sales and why, which kitchen ticket never printed — and the single thing to fix before the next service, in your language. The module calls the provider directly from your Odoo: no data goes through a third party, and you control the model and the cost. It never posts or changes anything, and the app works perfectly with it switched off.
Features
- The delivery order becomes a paid POS order in the session that is open right now — with the platform as its payment method, so the closing shows what each one owes you.
- In the Z report — delivery closes with the day. The session total is the day's real total.
- Kitchen ticket printed on the POS's own order printers (ePOS), with the platform, the order code and the items.
- Taxes computed like any other POS line — the platform's price is a final price, so the tax comes out of it, never on top of it.
- A closed session never loses an order — it falls back to a sale order, exactly as before, and the cockpit says which and why.
- Never cooked twice — the same order pushed twice (a status update, a catch-up pull, a webhook that fires again) is the same POS order. One ticket, one amount.
- One route per shop — many shops, many tills, one integration. Or one route for everything.
- Live cockpit — what came in today from each platform, what is in the till, what fell back to Sales, and whether each session is actually open right now.
- Full log — every routed order, every fallback, every print, with its reason. When the kitchen swears a ticket never arrived, this is the answer instead of an opinion.
- Delivery orders are findable in the POS — the platform and its order code are on the POS order itself, and searchable.
- AI analysis (optional) — Anthropic Claude or OpenAI, your own key: what landed in the till, what fell back to Sales and why, and the one thing to fix before the next service, in your language.
- Multi-company — every route, order and log line belongs to its company; nothing leaks between them.
- Works on Odoo Community — and Enterprise. No Preparation Display needed: the printer is enough.
- Multilingual — English, Spanish and Portuguese (BR).
In the POS orders, the delivery ones are marked — the cashier can tell them apart at a glance.
Perfect for restaurants, dark kitchens and food chains in Latin America that take orders on PedidosYa or Rappi and run their shop on the Odoo Point of Sale — and for anyone tired of a delivery order sitting in Sales while the kitchen waits.
Keywords: delivery orders in POS, PedidosYa POS, Rappi POS, restaurant point of sale, kitchen printer, kitchen ticket, ePOS printer, POS session, Z report, delivery revenue in the till, food delivery integration, dark kitchen, Odoo Community POS, LATAM delivery, Peru, Colombia, Mexico, Chile, Argentina.
Palabras clave: pedidos de delivery en el punto de venta, PedidosYa en el POS, Rappi en el POS, impresora de cocina, comanda, ticket de cocina, sesión de caja, reporte Z, cierre de caja, restaurante, cocina oculta, integración de delivery, Odoo Community, Perú, Colombia, México, Chile, Argentina.
Permissions & data security
This app writes money into your till. It is built accordingly.
- 💰 It never invents money. One delivery order becomes one POS order, once — and only in a session that is genuinely open. A re-sent webhook cannot double a ticket or a total.
- 🔒 It never writes to a closed session. When the till is closed the order stays in Sales, where it always was. Your closing is never touched after the fact.
- 👤 Role-based access. POS users see the cockpit; only a POS manager creates a route or changes where the money lands.
- 🏢 Multi-company isolation. Every route, POS order and log line is tagged to its company; a user only ever sees the companies they are allowed into.
- 📝 Everything is on the record. Every order routed, every fallback and every print attempt is logged with its reason — no silent failures.
Requires the Point of Sale app, and the PedidosYa or Rappi connector (sold separately) to have something to route. Works with Odoo Community and Enterprise.
More from the author: Aski — ask your Odoo in natural language by chat or voice, and get real figures from your phone. https://aski.dev
Questions, or want a quick personalized demo? Email me at jhonrojas.dev@gmail.com — I am happy to answer questions or set up a short demo.
Support: jhonrojas.dev@gmail.com · License: OPL-1
About the author
Jhon Jairo Rojas Ortiz
Odoo developer · custom modules, integrations & business intelligence
5+ years of hands-on Odoo experience — building and shipping real modules, integrations and analytics for companies across LATAM and Europe. Every app I publish is maintained and supported personally.
Custom Odoo modulesIntegrations & APIsBI & analyticsOdoo 16–19
inConnect on LinkedIn →| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Point of Sale (point_of_sale)
• Discuss (mail) • Inventory (stock) • Invoicing (account) |
| Lines of code | 1188 |
| Technical Name |
jjro_delivery_pos |
| License | OPL-1 |
| Website | https://aski.dev |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module