Technology and AI
Real-time interfaces with Odoo.
It is less good at showing it the way a managing director, a Senegalese accountant or a shop manager needs it. Rather than developing inside Odoo — which costs at every upgrade — we built a technology that works alongside Odoo, live, without copying your data.
Our OHADA balances, your dashboard, the stock location view, the Excel exports appear in Odoo's menus, with your access rights, without a second login.
No data warehouse refreshed overnight: the balance you open at 10:04 contains the entry posted at 10:03. The 3D planogram fills at receipt and empties at sale.
A validated invoice, a closed till session, a confirmed order: Odoo notifies our server, which updates the dashboard, flags the forgotten session, or triggers a supplier order.
Tremol fiscal devices in Kenya, receipt printers, M-Pesa terminals: our gateways run next to the till and keep a queue, so an internet outage never blocks a sale.
Five stations, five Odoo databases, one dashboard; one configuration compared with another; a central purchasing company that splits its orders across its stations' databases.
every write is logged and can be undone, access to your databases is encrypted and specific to each client, and you receive the rebuild sheet of your configuration.
AI drives your databases
An MCP server connects Claude or ChatGPT to your Odoo databases: reading, logged and reversible writing, under your access rights.
AI and the MCP server →Clusters of SaaS databases
One database per cluster of about twenty sites, master data propagated, a federated view: an incident stays local, you grow by adding clusters.
SaaS clusters →The Senedoo ToolBox
Client portal, add-ons installable in Odoo, orchestrator: our technology alongside Odoo, live, without copying your data.
The ToolBox →
Your Odoo databases, operated by AI — under control.
Model Context Protocol, the open standard created in late 2024 and adopted by Claude, ChatGPT, Gemini and Copilot, which lets an AI use tools. Ours has three hundred and thirty-seven, all connected to your Odoo databases: diagnostics, Sage import, payroll, reports, tills, backups, dashboards, configuration. No dependency on a single AI vendor.
"Check the balance after the import", "install the Commerce agreement on this database and compute a test payroll", "which till is stuck at Westlands?" — and the answer comes back, with the numbers.
Every write is simulated first, executed only on confirmation, and logged so it can be undone. The AI proposes; the consultant decides.
The SaaS cluster technology
For a shop network or a group of companies, we don't put everything in one database. We spread sites across clusters of about twenty Odoo SaaS databases, linked by our orchestrator: each cluster stays light, an outage never stops the whole network, and you grow by adding a cluster, not by rebuilding.
Resilience
A maintenance window or an incident affects only one cluster of twenty shops: the rest of the network and the hub keep selling and ordering.
Controlled volumes
One till ticket creates twelve records. Over five years a twenty-shop cluster weighs 131 million rows — Odoo's comfort zone. A single 150-shop database would weigh a billion.
Parallelism
POS load is distributed; the orchestrator processes each cluster's flows in parallel. Latency stays stable at peak hours.
Roll-out in waves
One cluster = one wave. Our tooling provisions a complete database — companies, warehouses, tills, catalogue — in an automated, repeatable way.
Master data propagated
A product added at the hub propagates to every cluster and to e-commerce; a permanent consistency check flags any discrepancy — price, code, unit, tax.
One federated view
The dashboard and the MCP tools read clusters one by one or in a cached federated view: to the user, the network reads like a single database.
SaaS, Odoo.sh or on-premise? Why do we prefer Odoo SaaS?
Odoo deploys three ways: Odoo SaaS (odoo.com, hosted and operated by the publisher), Odoo.sh (the publisher's cloud platform with your own Python modules), or on-premise (your servers). We recommend SaaS to almost all our clients, and we prefer to say so with its limits.
| Criterion | ✔ Odoo SaaS (our recommendation) | Odoo.sh | On-premise |
|---|---|---|---|
| Hosting and operations | Included Included in the Enterprise subscription: ISO 27001 infrastructure, replicated backups, monitoring, Odoo S.A.'s availability guarantee. Zero servers to buy or administer. | To plan Hosting billed on top (workers, storage, staging environments). Operations shared between publisher and integrator. | On you Servers, redundancy, backups, security and an operations team at your expense. In Senegal or Kenya, power and connectivity add to the risk. |
| Version upgrades | Included Automatic and continuous, year after year: your databases stay on the latest version with no migration project. | To plan A migration to plan every two or three years, adapting your modules: a project each time. | On you Migration at your expense, often postponed: on-premise databases age, technical debt piles up. |
| Customisation | Included Studio (fields, views, reports, automations) and our technology alongside Odoo (ToolBox, orchestrator, installable add-ons). Honest limit: no way to touch Odoo's source code. Our answer: customisations run on a VPS kept in sync with your database through webhooks and crons, without touching the SaaS database — it stays standard, hence always up to date. | To plan Custom Python modules possible — that is its point, and its trap. A module touches Odoo's source code: at every version it must be reviewed, adapted and retested; until then the upgrade is blocked. A bug in the module stops the whole database, not just the feature. And the code ties you to its author: without them, nobody maintains it. | On you Everything is possible, everything is yours to maintain. Same drawbacks as Odoo.sh Python modules — modified source code, postponed migrations, dependence on the developer — without the platform's automated staging and deployment. This is how databases end up stuck on version 12 or 14. |
| Resilience and scale | Included One database per cluster of about twenty sites; an incident stays local; you grow by adding clusters. | To plan A single database: single point of failure, volumes growing without limit. | On you Same, plus the fragility of your own infrastructure. |
| Total cost | Included The lowest: licences only, no server, no migration, no operations team. | To plan Licences + hosting + periodic migrations. | On you Licences + hardware + team + migrations. The visible cost is low, the real cost is the highest. |
| Data location | Included Odoo data centres (Europe by default). To be examined if a regulation imposes national localisation. | To plan Same (publisher's cloud). | On you At your premises — the one decisive argument for on-premise, when the law requires it. |
| When to choose it | Included SMEs, multi-company groups, shop or station networks, any client who wants an up-to-date system without a technical team. | To plan When a custom business module is genuinely indispensable and you accept paying for its maintenance. | On you Legal data-localisation obligation, or a site without reliable internet with an on-site IT team. |
Our position. What a client asks for "bespoke" is almost always solved by Studio, by an installable Senedoo add-on, or by our technology working alongside Odoo in real time — without ever leaving SaaS. When it isn't, we say so, and we support you on Odoo.sh. We have never yet had to recommend on-premise.
The Senedoo ToolBox
Your client portal
senedoo-toolbox.com: single sign-on to all your databases, financial reports, Excel exports, dashboards, project tracking, video tutorials.
Add-ons inside Odoo
Twenty-nine installable tools — OHADA reports, returns, payroll, shelf tags, mobile money — updated centrally, with no intervention on your side.
The MCP server
Connector for Claude and ChatGPT, reserved for our consultants and, on request, your trained teams. Dry-run by default, undo log.
Odoo tells us, our servers act.
Odoo does it both ways, without a line of code, from its automation rules.
The "Send Webhook Notification" action sends a POST request, carrying the fields you choose, to the address you choose. A validated invoice, a closed till session, a confirmed order, a new hire: our orchestrator receives the event and does the work that follows — refresh the dashboard, flag a till session left open before opening time, chase a purchase order.
The "External" trigger does the opposite: Odoo generates an address, an outside system calls it, and an automation fires on the target record. That is how a payment terminal, a fiscal gateway or a form hosted elsewhere write into Odoo at the moment the event happens, with no overnight synchronisation.
A webhook carries the event, not the file: Odoo announces that "till session 1842 is closed", it does not send its three hundred sales lines. That is deliberate — the payload stays small, and nothing confidential crosses the network unless it was asked for. So our orchestrator takes the second step: it checks the signature, then calls Odoo back through the API to pull exactly what it needs. The webhook says what; the API says how much.
Evening exports, files dropped on a server, scripts polling Odoo every five minutes to find out whether anything changed. A webhook costs one call, exactly when the event occurs.
Odoo says it in its own documentation: a badly configured webhook can disrupt a database, and reverting takes time. With us a webhook never comes alone: signed address, a log of every call received, a queue when the other side does not answer, and replay. A lost event is a wrong figure the next morning.
Thirty lines, and no code inside the Odoo database. The same shape serves a validated invoice, a confirmed order or a new hire: only the query in step 2 changes.
Odoo's API: your data, readable and writable from outside.
Anything a user can do in Odoo, a program can do through the API — with the same rights, no more and no less. That is how our reports, dashboards and gateways work.
JSON-2, the current road
Since version 19: post a JSON object to /json/2/model/method, authenticated by a dedicated API key. Every database publishes the list of its models, fields and methods on its own documentation page.
XML-RPC, the legacy
The old interface still works, but Odoo has deprecated it: the database-management service disappeared in version 20, and the rest is scheduled for removal. Our connectors still run on it and will move before the deadline.
The MCP server
The same idea, for artificial intelligence: declared tools rather than direct access. Odoo 20 ships one; ours holds more than three hundred. Read the comparison
Our OHADA trial balances, your SYSCOHADA income statement, your dashboards, the shelf labels, the Sage import reconciled to the franc, the monitoring of your tills: all of it reads and writes in your database through the API, at the moment you look, with no copy of your data on our side.
On Odoo Online, access to the external API is not open to every subscription: it is reserved for Custom plans, and excluded from One App Free and Standard plans. It is not a matter of edition but of plan — we check it with you before integrating anything, and we tell you whether your need justifies it.
An API key is worth a password: it carries its owner's rights. We create a dedicated user with strictly necessary rights, one key per use, and we log every write so it can be undone.