# Hadoopt Technologies blog > Odoo 17 to 20 guides, Odoo comparisons, and web and mobile engineering notes from the Hadoopt team in Coimbatore, India. All 163 posts in full, newest first. Written by Janeindiran B. (https://hadoopt.com/blog/author/janeindiran-b). Source: https://hadoopt.com/blog --- ## Odoo 20 is out: what's new, from the official release notes - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/odoo-20-whats-new-release-notes - Published: 2026-09-26 - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo 20, Odoo Experience, Odoo release, AI agents, Upgrade planning Odoo 20 was unveiled at Odoo Experience on 24 September 2026. What the official release notes change for AI, everyday use, accounting, India and pricing. Odoo 20 was unveiled by Fabien Pinckaers in the opening keynote of Odoo Experience in Brussels on 24 September 2026, and Odoo has now published the official Odoo 20 release notes. The biggest changes are AI agents that can create and update records, an offline mode, a simpler access-rights model and a long list of accounting and localisation work. Odoo also added a cheaper Light User licence. The release notes also say that all AI features now need credits bought through IAP. Two days ago we wrote what we knew before the release and promised to come back once the release notes were out. This is that follow-up, written for businesses deciding what Odoo 20 means for them rather than for developers. ## AI agents in Odoo 20: from answering to acting In Odoo 19, AI was mostly something you asked. The Odoo 20 release notes describe agents that do the work. The items that matter most for a business user: - Agents create and update records. An agent can generate records, including from instructions in an uploaded PDF, and modify existing ones. A client's specification can become a project and its tasks. - Agents run on a schedule. Automated and scheduled actions can summon an agent, so a routine check can run without anyone asking for it. - Agents ask before going too far. Responses can include buttons for questions, permissions and suggestions. When an agent hits its limit of tool calls, it asks the user before continuing. - Files and voice. You can question a file while previewing it, send documents into an agent chat, and dictate requests. - MCP. The release notes say you can "connect Odoo to anything" through MCP (Model Context Protocol), the standard way AI tools talk to other systems. - Housekeeping. Odoo picks the AI model for each task automatically. Conversations are kept for 30 days after the last message, and "topics" are renamed "skills". ## Everyday changes every Odoo user will notice The general section of the release notes is long. These are the changes users will notice first: One change deserves its own line: simplified access rights . Odoo 20 removes record rules and moves the domain onto the access right itself. For a standard database that is simpler to manage. If you have custom modules with their own record rules, it is the change most likely to need developer time in your upgrade. It matches the "redesigned and unified security model" that Odoo's framework talk announced before the release. ## Accounting changes in Odoo 20 Accounting has one of the longest sections in the release notes. The changes most finance teams will notice: - Bank consistency. Everything that touches a bank account has to originate from a bank transaction, which keeps the books and the bank in step. - Parent accounts replace account groups in the chart of accounts. - Bill line prediction uses history and labels to fill vendor bills. - Customer invoice reminders , manual and automatic. - Reconciliation against several accounts at once, and analytic distribution on write-offs. - Simpler asset models built around depreciation logic, with depreciation by rate. - Paying bills from Odoo through a payment-initiation (PISP) interface, where your bank and country support it. - Multi-ledger consolidation improvements for groups reporting across companies. ## What Odoo 20 changes for Indian companies Most of our clients run the Indian localisation, so we read that section first. The release notes list five India changes: - Credit notes for price adjustments can be issued directly. - A bill of entry flow for imports simplifies recording customs duty on imported goods. - More flexible TDS: apply "TDS & Payment", "TDS Only" or "Payment Only". - Composition Taxpayers are now covered by GST compliance, with dedicated support for the Composition Scheme. - Schedule III, Division I financial statements with the prescribed presentation, classification and disclosures. For importers and small businesses on the Composition Scheme, these are reasons to look at Odoo 20 early. Check each one against your own filings on a test database before relying on it. ## Sales, website, inventory and HR highlights ### CRM and eCommerce CRM gets lead-distribution rules (always, limited rotation or out of rotation), a pipeline switcher per team, and upsells or renewals created straight from a lead's existing subscriptions. Lead generation now uses the Dun & Bradstreet database in place of Clearbit. eCommerce has one of the longest lists in the release: AI-assisted product editing, customer returns through the portal, preferred delivery dates, minimum order quantities, automatic unpublishing when stock runs out, WhatsApp abandoned-cart messages, and selling without installing the Inventory app. ### Inventory and barcode The Barcode app gets bulk lot and serial generation, manual lot entry, batch receipts from one vendor, product creation by scanning, and the option to count a total instead of scanning each unit. Light Users can be limited to the Barcode app, which pairs with the new licence below. ### HR, attendance and Discuss Attendance adds a photo at check-in, automatic check-out times, overtime rulesets with public-holiday rates, and an overtime analysis report. Appraisals get bulk actions and 360 feedback from external contacts. Discuss adds polls, channel categories and favourites. The Phone app shows who is on a call and can record calls with a transcript and summary. ### Point of Sale The POS section of the release notes is mostly country e-invoicing (Egypt, Malaysia, Pakistan, Vietnam and others). The restaurant and kiosk work Odoo trailed before the release, including a floor-plan editor, reservations, self-ordering and WhatsApp receipts, is what to test if you run a restaurant or store. ## Odoo 20 pricing and the new Light User The pricing change that affects most companies is a new user type. Odoo's pricing page describes a Light User as "an employee without application access or a user with limited access". It shows Rs 195 per month in India. For companies with many shop-floor, store or warehouse staff who only record their own time, leave or scans, the Light User can cut the licence bill noticeably. Several recaps say Light Users need Odoo 20 and also report changes to other plan prices. We couldn't confirm either on odoo.com, so ask Odoo or your partner for a quote on your own user mix. > The cheapest Odoo 20 upgrade is often not new features but moving the right people onto Light User licences. ## What we left out, and why Some Odoo 20 feature lists circulating this week mention an "OWL 3.0" web client, native GraphQL endpoints and Bluetooth thermal printing for offline POS. None of these appear in the release notes we read, and at least one such list was published weeks before the keynote. They may turn up in the code or the developer documentation later. Until then, we don't treat them as announced. ## Should you upgrade to Odoo 20 now? For most live databases, not in the first weeks. The pattern we recommend every year still holds: - Request a test upgrade of a copy of your database and check that your custom modules install on 20.0. - Go through the access-rights change with whoever maintains your custom code, since record rules are gone. - Test your localisation , including the India items above, against real transactions. - Price the AI credits and Light Users for your user mix before you count on either. - Pick a go-live date away from month-end and your GST filing dates. Our Odoo 20 readiness checklist covers the groundwork. If you are two or more versions behind, read planning a multi-version jump to Odoo 20 . If you are still deciding between 19 and 20, upgrade to Odoo 19 now or wait for Odoo 20 still applies. For help with your own database, talk to us . ## Questions we get asked **Q: When was Odoo 20 released?** Odoo 20 was unveiled on 24 September 2026 by founder and CEO Fabien Pinckaers in the opening keynote of Odoo Experience in Brussels, and Odoo has published the official Odoo 20 release notes on odoo.com. Availability can differ between Odoo Online, Odoo.sh, on-premise installations and the upgrade service, so check the hosting type you use before planning a date. **Q: What are the main new features in Odoo 20?** According to the official release notes, the headline changes are AI agents that can create and update records, run on a schedule and connect to other tools through MCP; an offline mode; activities assigned to roles; simplified access rights without record rules; a large accounting update; and many localisation changes. For Indian companies these include a bill of entry flow, flexible TDS, Composition Scheme support and Schedule III statements. **Q: Is AI free in Odoo 20?** Not entirely. The Odoo 20 release notes state that all AI features now need credits, which are bought through In-App Purchase (IAP). Odoo's pricing page lists Agentic AI under the Custom plan and says IAP credits are not included in any plan. Some recaps of the keynote describe AI as included in the subscription, so confirm the terms for your own contract before budgeting. **Q: What is an Odoo Light User?** A Light User is a lower-cost Odoo licence for employees who need little or no application access. Odoo's pricing page shows it at Rs 195 per month in India. A Light User can manage their own HR items such as leave, expenses and attendance, view their planning, log in to a POS session, read Knowledge and scan barcodes. They cannot use Sales, Purchase, Projects or Accounting. **Q: Will my custom modules work on Odoo 20?** Not without checking. Custom modules have to be migrated to every new major version, and Odoo 20 changes the access-rights model by removing record rules and putting domains on access rights. Modules that define their own record rules, or rely on the old mail tracking values, are the most likely to need rework. Run a test upgrade and install every custom module on 20.0 before setting a go-live date. --- ## Odoo 20 readiness checklist: the work you can do now - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/odoo-20-readiness-checklist - Published: 2026-09-22 - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo 20, Upgrade planning, Custom modules, Data migration Prepare for Odoo 20 before the feature list is out: custom module and Studio inventory, data clean-up, a test database, integrations, training and budget. You can prepare for Odoo 20 now without knowing a single new feature. The work that decides how an upgrade goes is the same every year: know your custom modules and Studio changes, clean your data, keep a test database, map your integrations, plan training and set a budget. Do these six things and the Odoo 20 decision becomes a question of timing, not a scramble. This checklist applies whether you move to Odoo 20 soon after release or a year later, and whether you are on Odoo 19 already or several versions behind. None of it depends on what Odoo announces at Odoo Experience. For what is actually known about Odoo 20 so far, see what we know before the release . ## Inventory your custom modules and Studio customisations This is the item that drives cost. Odoo's upgrade service converts standard apps and data. It does not port third-party or in-house modules unless they are covered by a maintenance-of-customisations subscription. Odoo's documentation is explicit: a database with custom modules cannot be upgraded until those modules exist for the target version. Start with a list of every installed module that Odoo didn't write. On a self-hosted or Odoo.sh database, a read-only query gives you a first draft: ``` SELECT name, author, latest_version FROM ir_module_module WHERE state = 'installed' AND author NOT IN ('Odoo S.A.', 'Odoo', 'Odoo SA') ORDER BY author, name; ``` First-pass list of non-Odoo modules. Check the result by hand, because author strings are free text. For each module, record four things: who maintains it, whether the source is in your own repository, what business process it supports, and whether anyone still uses it. Modules nobody can explain are candidates for removal before the upgrade, not after. Studio customisations are stored in a generated module called studio_customization . Under Odoo's upgrade SLA they are upgraded as long as Studio is still installed and the subscription is active. That is good news, but don't skip them. Automations, computed fields and report edits made in Studio still need testing. Our Studio guide covers where those changes live. ## Clean your data before it is converted Odoo's SLA says plainly that cleaning pre-existing data and configuration is not part of the upgrade service. Whatever mess is in the database today will be converted faithfully into Odoo 20. - Contacts: merge duplicates, and archive customers and vendors you no longer deal with. - Products: archive dead products and variants. For Indian companies, fill in the HSN/SAC code on every product you sell, because GST reporting depends on it. - Accounting: post or delete old draft entries, reconcile what can be reconciled, and close past periods properly. - Inventory: resolve negative stock and old unreserved moves, so the valuation you carry forward is one you trust. - Users: archive people who have left, and review who holds Administration / Settings rights. If you came from Tally or another system and imported opening balances in a hurry, this is the moment to check that those balances still tie to your books. ## Set up a test database you can rebuild on demand Every upgrade we run goes through several test upgrades before production. Odoo recommends the same: request an upgraded test database, test it, report issues, and request a fresh one again close to go-live, because both the standard upgrade scripts and your data keep changing. Odoo neutralises test databases: scheduled actions are disabled, outgoing mail servers are replaced with a fake one, payment providers and carriers go to test mode, and bank synchronisation is turned off. Make sure your team knows this, or someone will report missing emails as an upgrade bug. On Odoo.sh a staging branch already gives you this. On-premise, you need a server that can restore last night's backup in one command. If that takes a day of manual work today, fix it first. ## Map every integration Integrations break quietly. Write down every system that talks to Odoo: payment gateways, bank feeds, shipping carriers, e-commerce connectors, BI tools, and, in India, GST e-invoicing and e-way bill. For each, record the endpoint it uses, the user or API key it logs in with, and who owns it on the other side. Look at the protocol too. Odoo 19 introduced the external JSON-2 API at /json/2 . Odoo's documentation states that the XML-RPC and JSON-RPC endpoints ( /xmlrpc , /xmlrpc/2 , /jsonrpc ) are deprecated and scheduled for removal in Odoo 22 (fall 2028). Moving to Odoo 20 won't force the change, but any integration you rebuild now should use JSON-2. ## Plan user training around the changes Odoo's upgrade service does not include training on the new version. Users will notice changes in screens and workflows even when your processes stay the same. Plan three things: - A short list of key users per app, who test the upgraded database and then train their teams. - Test scripts written in your own terms ("raise a GST invoice for an interstate customer"), not Odoo's. - Time in the calendar. Avoid month-end, GST filing dates, payroll runs and your busy season. ## Budget for the upgrade The budget has four lines. Odoo Enterprise includes the upgrade of standard apps and Studio customisations. Custom and third-party modules are ported by whoever maintains them, or by a partner. Testing takes your own staff's time, which is usually the line people forget. Training comes on top. For licence changes, check Odoo's pricing page . We don't quote prices here because they change. The biggest variable is the custom module list from the first section, so do that first. Once you have it, upgrade effort can be estimated module by module instead of guessed. If your inventory shows you are more than one version behind, read planning a multi-version jump to Odoo 20 . For the Odoo 19 upgrade path specifically, see upgrading to Odoo 19 from 16, 17 or 18 . When you are ready for a test upgrade, start one with us . ## Questions we get asked **Q: How do I prepare for an Odoo upgrade?** Start by listing every custom and third-party module and naming who maintains each one. Then clean duplicate and obsolete data, set up a test database you can restore quickly, and document every integration. Plan key-user testing and training. Finally, budget for porting custom code and for your staff's testing time. None of this depends on the new version's feature list. **Q: Does Odoo upgrade my custom modules for free?** No, not by default. Under Odoo's upgrade SLA, Enterprise customers get the standard apps and Studio customisations upgraded, as long as Studio is installed and the subscription is active. Modules built in-house or by third parties, including Odoo partners, are only covered if you have a maintenance-of-customisations subscription. Otherwise their maintainer has to port them to the target version. **Q: Are Studio customisations kept when I upgrade Odoo?** Yes, according to Odoo's upgrade SLA, provided Studio is still installed and your subscription is active. Studio changes are stored in a generated module called studio_customization and converted by Odoo's upgrade service. You should still test Studio automations, computed fields and edited reports in the upgraded test database, because standard views and fields they build on can change between versions. **Q: Will my XML-RPC integrations stop working in Odoo 20?** Odoo's documentation says the XML-RPC and JSON-RPC endpoints are deprecated and scheduled for removal in Odoo 22, which it dates to fall 2028. So they should keep working in Odoo 20, but you should test every integration in an upgraded test database anyway. New integrations should use the JSON-2 API that Odoo 19 introduced at /json/2. --- ## Odoo 20: what we know before the release - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/odoo-20-what-we-know-before-release - Published: 2026-09-22 (updated 2026-09-26) - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo 20, Odoo Experience, Odoo release, Upgrade planning What Odoo has officially said about Odoo 20 ahead of the Odoo Experience 2026 keynote, what its release pattern suggests, and what is only rumour. As of 22 September 2026, Odoo 20 has not been released. Odoo has said it will unveil Odoo 20 in the opening keynote of Odoo Experience in Brussels on 24 September 2026 and release it during the event. Apart from a few session and webinar descriptions on odoo.com, any "Odoo 20 feature list" you read before that keynote is speculation. We implement and upgrade Odoo for a living, so we get the "should we wait for 20?" question every September. This post keeps two lists apart: what Odoo itself has published, and what we expect because Odoo has done the same thing every year. Where we are guessing, we say so. ## What Odoo has officially announced about Odoo 20 Everything in this section comes from pages on odoo.com. Nothing here is a confirmed feature list; it is what Odoo has chosen to say ahead of the launch. The framework abstract matters most if you run custom modules. "A redesigned and unified security model" means access rules written for Odoo 19 are likely to need rework. Until the code is out, we can't say how much. The POS webinar tells you what Odoo plans to demonstrate. It doesn't say which plan or edition each item needs. We will check that against the released code before anything goes into our guide. ## What to expect from Odoo's release pattern These points are expectations, not announcements. They follow from what Odoo has done in previous years and from its published policies. - One major version a year. Odoo's release notes page lists Odoo 14 (October 2020), 15 (October 2021), 16 (October 2022), 17 (November 2023), 18 (October 2024) and 19 (September 2025). Odoo 20 in September 2026 fits that rhythm. - The Online-only versions are the best preview. Between majors, Odoo ships intermediate versions on Odoo Online only: 19.1 (January 2026), 19.2 (March), 19.3 (May) and 19.4 (July). In the past, what shipped in those versions ended up in the next major. So the 19.x release notes are the most reliable guide to Odoo 20 you can read today. - Some 19.4 changes point the same way as the framework talk. The 19.4 release notes describe simplified access rights: record rules are removed and a domain is set directly on the access right. They also add a connection to your database over MCP (model context protocol) and automatic selection of the AI model for each task. We expect these to be part of Odoo 20, but that is our reading, not Odoo's statement. - More AI. Odoo 19 introduced the AI app (Enterprise, OEEL-1 licence), with AI agents, AI fields, AI in server actions and answers drawn from your own documents. The 19.0 source has 15 ai* modules. The Odoo 20 AI talks at Odoo Experience suggest the keynote will spend time on AI. What exactly ships is unknown. - The support window moves. Odoo supports each major version for three years. Its published table gives September 2026 as the planned end of standard support for Odoo 17. If the pattern holds, 18, 19 and 20 will be the three majors in standard support once Odoo 20 is out. Our support policy explainer has the details. ## Why third-party Odoo 20 feature lists are speculation Every year, articles titled "Odoo 20 new features" appear weeks before the keynote. Some are written from the rolling-release test instance, some from the Online release notes, and some are simply guesses. Even the ones based on a real test instance show a moving target. A rolling-release build before the launch is not the final 20.0 branch, and features get renamed, moved between editions or held back. > If a list of Odoo 20 features doesn't link to an odoo.com page, treat it as a rumour. We are deliberately not repeating any of those lists here. If you are making a budget or timing decision, base it on the official release notes and on a test upgrade of your own database, not on a blog post, ours included. ## How to read the Odoo 20 release notes for your business When the release notes go live, most people scroll the headline features. The lines that decide your upgrade effort are usually further down. We read them in this order: - Your apps only. Filter to the apps you actually run. A new Rental feature doesn't matter if you don't use Rental. - Your localisation. For Indian companies, look at the India section: GST returns, e-invoicing and e-way bill, and Indian payroll. Statutory changes can decide your timing more than any feature. - Changed or removed behaviour. Renamed menus, merged models and workflow changes are what break training material and customisations. - Edition and plan. Check whether a feature is Community or Enterprise, and whether your Odoo Online plan includes it. Odoo's pricing page is the reference. - Framework notes, if you have custom code. Pass these straight to whoever maintains your modules. ## What to do before Odoo 20 arrives You don't need the feature list to start preparing. Listing your custom modules, cleaning your data and setting up a proper test database all pay off whatever Odoo announces on Thursday. Our Odoo 20 readiness checklist walks through that work. If you are on 16, 17 or 18 and wondering whether to move to 19 now, read upgrade to Odoo 19 now or wait for Odoo 20 . For what the current version already does, the Odoo 19 guide is the best place to start. It is also the base Odoo 20 builds on. We will revisit this page after the keynote. If you want a second opinion on what the release means for your setup, get in touch . ## Questions we get asked **Q: When will Odoo 20 be released?** Odoo has said Odoo 20 will be unveiled in the opening keynote of Odoo Experience 2026 in Brussels on 24 September 2026 and released during the event. Odoo has released one major version a year, usually around its Brussels event. Availability on each hosting type and on the upgrade platform should be checked after the launch rather than assumed for day one. **Q: What are the new features in Odoo 20?** Before the keynote, Odoo has only published session and webinar descriptions. These mention framework changes, including a redesigned security model and new extension points, and Point of Sale work such as a new dashboard, a floor-plan editor, mobile ordering and kiosks. A full, confirmed feature list will only exist once Odoo publishes the official Odoo 20 release notes. **Q: Can I try Odoo 20 before it is released?** Yes. Odoo runs a "Test-drive Odoo 20" beta page with a rolling-release test instance. Odoo states it is meant for testing only and that databases created there are deleted every week. Never put real company data in it. Treat it as a moving preview, because behaviour can change before and after the official 20.0 release. **Q: Should I wait for Odoo 20 before implementing Odoo?** Usually not. A new implementation started on Odoo 19 today can be upgraded to Odoo 20 later through Odoo's upgrade service, and Enterprise subscriptions include upgrades of standard apps. Waiting delays the benefits and gives you a version with little field experience. The exception is a project that would go live several months from now anyway. Then starting on 20 after its release can make sense. --- ## Odoo's release cycle and support policy, explained - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/odoo-release-cycle-support-policy - Published: 2026-09-22 - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo support policy, Odoo release cycle, Odoo.sh, Odoo Online, Upgrade planning How long Odoo supports each version, how many are supported at once, what the Online-only saas versions are, and what end of support means per hosting type. Odoo supports each major version for three years, and with one major release a year, that means three major versions are in standard support at any time. Today those are Odoo 17, 18 and 19, with Odoo 17's standard support planned to end in September 2026. What "end of support" means for you depends on your hosting: Odoo Online upgrades you on a schedule, Odoo.sh gives you two more years, and on-premise lets you stay put at your own risk. We check these rules at the start of every upgrade conversation. The source is Odoo's own documentation page on standard and extended support, together with its upgrade documentation. The details below are as published on 22 September 2026, just before Odoo 20 is due at Odoo Experience. For what is known about that release, see what we know before the release . ## How many Odoo versions are supported at once Odoo's policy is short. Standard support lasts three years for every major version and includes helpdesk support, bug fixing and security updates. Beyond three years, extended support is available for a mandatory additional fee. It includes helpdesk support and bug fixes "depending on feasibility". Security updates are not in that list. Majors have come out once a year: Odoo's release notes list 14 in October 2020, 15 in October 2021, 16 in October 2022, 17 in November 2023, 18 in October 2024 and 19 in September 2025. Three years of support at one release a year gives three supported majors at any time. The oldest one drops off around the time the newest one arrives. ## The support table as of September 2026 This is Odoo's published table for major versions, simplified: Two upgrade rules sit alongside the table. First, you can only upgrade to a supported version. Second, the last version to go out of support can still be used as an upgrade target for up to six months after its end-of-life date. Note the word "planned" next to future dates. Odoo's page also carries a warning that it does not amend the Odoo Enterprise Subscription Agreement, and that the agreement governs if the two conflict. For contractual questions, the agreement is the reference, not the table. ## What the Odoo Online saas versions are Between majors, Odoo releases intermediate versions every two to three months. Odoo calls them online or SaaS versions. They exist only on Odoo Online, never on Odoo.sh or on-premise. In Odoo's public source repository they appear as branches named saas-19.1 , saas-19.2 and so on. The current cycle has 19.1 (January 2026), 19.2 (March), 19.3 (May) and 19.4 (July). Three things about them matter for planning: - They are short-lived. A database on an intermediate version must be upgraded a few weeks after the next version is released. Odoo's table already shows 19.1 as no longer supported. - They get no extended support. There is no paid option to stay on 19.2. - They preview the next major. Features that appear in 19.1 to 19.4 are the best public indication of what Odoo 20 will contain. Odoo's release notes for each one are worth reading if you plan to move to 20. If you are on Odoo Online and your version number has a decimal, you are on this track whether or not you chose it. ## What end of support means on Online, Odoo.sh and on-premise On-premise gives you the most freedom, and that is where we see databases drift three or four versions behind. The cost of drifting doesn't show on any invoice. It shows up later as a larger, riskier jump. Odoo's own advice is the same: the smaller the gap between versions, the easier the upgrade. If you run Odoo Community on-premise, Odoo's helpdesk support and upgrade service are not part of the picture at all. The upgrade platform asks for an Enterprise subscription code. Community users rely on the community-maintained OpenUpgrade project or on a partner. Our Odoo 19 hosting guide compares the three options in more depth. ## Planning your upgrades around the cycle - Write down your end date. Take your version's end of standard support from the table and put it in the calendar of whoever owns the budget. - Start a year before it. Test upgrades, custom module porting and user testing take months, not weeks, once customisation is involved. - Skip a version when it helps. Odoo's upgrade service can jump several versions in one request, so you don't have to install every major. See planning a multi-version jump . - Don't let the gap grow past two. Beyond that you are paying for extended support, carrying security risk, or both. If you are deciding between moving now and waiting for Odoo 20, this decision guide works through it by version. To see what your own database looks like on the target version, request a test upgrade . ## Questions we get asked **Q: How long is an Odoo version supported?** Odoo gives every major version three years of standard support, covering helpdesk support, bug fixes and security updates. After that, Odoo.sh and on-premise customers can buy extended support for a mandatory additional fee, which covers helpdesk support and bug fixes where feasible. Intermediate Odoo Online versions such as 19.2 are not eligible for extended support and must be upgraded within weeks of the next release. **Q: Which Odoo versions are supported in 2026?** As of September 2026, Odoo's published table shows Odoo 17, 18 and 19 in standard support, with 17 planned to end in September 2026, 18 in September 2027 and 19 in September 2028. Odoo 16, 15 and 14 are in extended support on Odoo.sh and on-premise only. On Odoo Online, the current intermediate versions 19.2 to 19.4 are also supported. **Q: What is an Odoo saas version?** A saas version, such as 19.1 or 19.4, is an intermediate release that Odoo ships on Odoo Online every two to three months between major versions. These versions are never released for Odoo.sh or on-premise and are not eligible for extended support. A database on one must be upgraded a few weeks after the next version comes out. Their features usually preview the next major version. **Q: Do I have to upgrade Odoo when support ends?** It depends on hosting. On Odoo Online, major version upgrades are mandatory every two years and are triggered automatically if you don't act. On Odoo.sh you get two extra years after the three years of support. On-premise you can stay on a version indefinitely, but without standard support you lose security updates, which Odoo does not recommend. --- ## Planning a multi-version jump from Odoo 14, 15 or 16 to Odoo 20 - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/planning-a-multi-version-jump-to-odoo-20 - Published: 2026-09-22 - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo 20, Odoo upgrade, Custom modules, Upgrade planning How Odoo's upgrade service handles a jump from Odoo 14, 15 or 16 to the latest version, what porting custom code involves, and how many test rounds to plan. You can upgrade from Odoo 14, 15 or 16 straight to the latest version without installing each version in between. Odoo's upgrade service takes your database and a target version and returns an upgraded database in one request. The effort in a multi-version jump is in your custom modules, which have to be rewritten for the target version, and in the several rounds of testing that follow. This post is for companies that have stayed on an older version and are now looking at Odoo 19 or the upcoming Odoo 20. As of 22 September 2026, Odoo 20 has not been released. It is due at Odoo Experience on 24 September, and nothing below depends on its features. If you are only one or two versions behind, our guide to upgrading to Odoo 19 from 16, 17 or 18 is shorter and more direct. ## How Odoo's upgrade service handles a multi-version jump You never choose the intermediate versions. You name the target, and the upgrade platform handles the rest. Odoo's own documentation describes an upgrade as moving a database "from an older version to a newer supported version" and gives 16.0 to 18.0 as its example. The target must be a supported version. Today the upgrade form offers 19.0, 18.0 and 17.0. How you submit depends on hosting: - On-premise: run Odoo's upgrade script on the database server, or upload a dump through the upgrade page. - Odoo.sh: use the Upgrade tab on a staging branch. The platform sends the latest daily production backup, restores the result and then updates your custom modules on every commit. - Odoo Online: request the upgrade from the database manager. Custom Python modules can't be installed on Online, so the question of porting them doesn't come up. ``` python <(curl -s https://upgrade.odoo.com/upgrade) test -d -t python <(curl -s https://upgrade.odoo.com/upgrade) production -d -t ``` Odoo's documented commands for a test upgrade and a production upgrade from an on-premise server. Two practical details catch people out. The upgraded dump comes back without your production filestore, so you have to merge the returned filestore folder with your existing one before testing. And the script needs outbound access on port 443 and on a range of high TCP ports. Strict corporate firewalls often block that range. The service is part of an Enterprise subscription. The upload form asks for your subscription code. Community databases need the community-maintained OpenUpgrade project or a partner-led migration instead. ## Why custom code decides the size of the job Odoo's documentation is blunt: a database with custom modules cannot be upgraded until a version of those modules exists for the target version. Odoo's SLA covers standard apps and Studio customisations. It does not cover in-house or third-party modules, unless they are under a maintenance-of-customisations subscription. In a multi-version jump, your code has to absorb every change between your version and the target, all at once. Odoo's upgrade guide lists the kinds of breakage you can expect: - invalid module dependencies; - syntax changes in asset declarations, OWL components and view attrs ; - references to standard fields, models or views that were renamed or removed; - XPaths into views that have moved; - renamed or removed methods. Data is the other half. When a model changes shape across versions, custom data has to be moved with upgrade scripts. Odoo's own example is custom fields on sale.subscription , which aren't migrated automatically when that model was merged into sale.order in Odoo 16. The upgrade-util helpers ( rename_field , rename_model , rename_xmlid ) exist for exactly this. > A multi-version jump doesn't cost the same as several single upgrades. The standard part is one request. The custom part is one rewrite against a much larger set of changes. That is why the first step in Odoo's guide is to stop development and challenge every customisation. Between 14 and 19, a lot of what companies once built themselves has become standard. Each module you drop is one you don't port. ## The six steps Odoo recommends for a customised database - Stop development and challenge it. Freeze the codebase except for bug fixes, and compare each module with what the target version does as standard. - Request an upgraded test database. The only aim here is to confirm the standard upgrade succeeds on your data. - Make your modules work on an empty database of the target version. Install them one by one, fix tracebacks, test, clean the code and get the standard tests passing. - Make them work on the upgraded database. Write upgrade scripts for renamed fields and moved data, re-enable views the upgrade disabled, and update records flagged noupdate . - Test extensively and rehearse. Request fresh test upgrades as you go, and do a full rehearsal the day before go-live. - Upgrade production. The database is unavailable while this runs, and on Odoo Online it can't be reverted once complete. ## How many testing rounds to plan We plan at least three rounds for a multi-version jump, and more if the module list is long. The first round is technical: the standard upgrade on its own, checking the upgrade report Odoo posts in Discuss for disabled views and other warnings. The second runs your ported modules on the upgraded database. The third is user acceptance: key users run real flows end to end, such as purchase to receipt to bill, or quotation to delivery to GST invoice, and compare results with production. Request a fresh upgraded database for each round. Odoo advises this because the upgrade scripts and your data keep changing. Remember that test databases are neutralised. Scheduled actions are off, mail goes to a fake server, and payment providers and bank sync are disabled. Test integrations deliberately, with sandbox credentials. ## Odoo 19 now or Odoo 20 as the target Odoo 20 can't be a target until Odoo releases it and the upgrade platform offers it. If you start now, the realistic target is Odoo 19. You can move from 19 to 20 later as an ordinary one-version upgrade. If you start in a few months, 20 may be available. The porting work you have done by then carries forward, because most of the gap between 14 and 20 is the gap between 14 and 19. Our now-or-wait guide weighs this by version. Either way, start with the inventory in our Odoo 20 readiness checklist . When you want to see your own database on the target version, request a test upgrade with us . It is the fastest way to turn a vague worry into a list of specific fixes. ## Questions we get asked **Q: Can I upgrade from Odoo 14 directly to Odoo 19?** Yes, for the standard part. Odoo's upgrade service takes a database and a supported target version and returns the upgraded database in one request, without you installing each version in between. Custom and third-party modules are a separate job. They must be rewritten for the target version before the production upgrade, and that work is usually where most of the time goes. **Q: How long does a multi-version Odoo upgrade take?** It depends almost entirely on your custom modules. A database with only standard apps and Studio changes can be test-upgraded quickly and mostly needs user testing. A database with many custom modules needs each one ported across several versions of framework change, plus upgrade scripts for data and at least three testing rounds. Estimate module by module, after a first test upgrade. **Q: Is the Odoo upgrade service free?** For Odoo Enterprise customers, Odoo's SLA includes upgrading standard applications, plus Studio customisations while Studio is installed and the subscription is active. It does not include cleaning existing data, upgrading in-house or third-party modules unless they are under a maintenance-of-customisations subscription, or training. The upgrade platform asks for an Enterprise subscription code, so Community databases are not covered. **Q: Can I upgrade Odoo Community across several versions?** Not with Odoo's own upgrade platform, which requires an Enterprise subscription code. Community users usually rely on OpenUpgrade, a community-maintained migration project, or on a partner. That route moves one version at a time and needs more technical effort per hop. For a long jump it is sometimes simpler to reimplement on the new version and import master data and open balances. --- ## Upgrade to Odoo 19 now or wait for Odoo 20? - URL: https://hadoopt.com/blog/odoo-20-complete-guide-for-businesses/upgrade-to-odoo-19-now-or-wait-for-odoo-20 - Published: 2026-09-22 - Category: Odoo 20: Complete Guide for Businesses - Tags: Odoo 19, Odoo 20, Odoo upgrade, Upgrade planning A decision guide for companies on Odoo 16, 17 or 18: when to move to Odoo 19 now, when waiting for Odoo 20 makes sense, and what changes the answer. If you are on Odoo 16 or 17, upgrade to Odoo 19 now rather than waiting for Odoo 20. Odoo 16 left standard support in September 2025, and Odoo 17 is due to leave it this month. If you are on Odoo 18, you have until September 2027, so waiting and moving straight to Odoo 20 once it has settled is a sound plan. That is the short version. The rest of this post explains the reasoning, and the situations that change the answer: heavy customisation, Odoo Online's upgrade rules, Community edition, and your own accounting calendar. We don't use any Odoo 20 features in this reasoning, because as of 22 September 2026 Odoo hasn't published them. For what is known so far, see what we know before the release . ## Where each version stands on support Odoo gives each major version three years of standard support, which covers helpdesk support, bug fixes and security updates. After that, extended support is available on Odoo.sh and on-premise for a mandatory additional fee. These are the dates Odoo publishes today: The support policy explainer covers what "end of support" means on each hosting type. ## If you are on Odoo 16 Don't wait. Your version has been out of standard support for a year. On Odoo.sh or on-premise that means paying for extended support or running without bug and security fixes. On Odoo Online, Odoo's table no longer shows 16 as supported at all. Waiting for Odoo 20 doesn't make the jump smaller. It adds one more version of change to absorb. Odoo's upgrade service lets you go straight from 16 to 19. Once you are on 19, the later move to 20 is a single step. In our experience that pair of upgrades is less risky than one long jump made in a hurry once 20 is out. ## If you are on Odoo 17 Standard support for 17 is planned to end this month. Moving to 19 now puts you on a version supported until September 2028. It has also had a year of bug fixes since its release in September 2025. The argument for waiting is "we only upgrade once". It sounds efficient, but in practice it means running on an unsupported version while you wait. You also wait for Odoo 20 to settle, and for any third-party modules you use to be published for 20. That wait is realistically several months beyond the release date. If your custom module list is short, go to 19 now. If it is long, start the inventory in our readiness checklist today, whichever target you choose. ## If you are on Odoo 18 You are the one group for whom waiting is a real option. Odoo 18 is in standard support until September 2027, so you can let Odoo 20 be released, watch its first bug-fix months, check that your third-party modules are available for it, and upgrade once, straight to 20. Two reasons to move to 19 anyway. First, you need something 19 already has, most often the AI app and AI fields. Second, you have a quiet window now and expect a busy 2027. Our Odoo 19 AI guide shows what that app does today, so you can judge whether it is worth an upgrade on its own. ## Situations that change the answer - Odoo Online. Odoo decides much of the timing for you. Major versions must be upgraded every two years, and intermediate versions a few weeks after the next one comes out. Odoo notifies you in the database before a mandatory upgrade and triggers it automatically if you don't act. Use that window to request a test upgrade. - Heavy customisation. The more custom modules you run, the more each version hop costs, because every module has to be ported and tested. That makes "one hop, not two" more tempting. It also makes running unsupported code for longer more dangerous. For large codebases, get the module-by-module estimate first, then decide. - Community edition. Odoo's upgrade platform asks for an Enterprise subscription code. Community users either migrate with the community-maintained OpenUpgrade project or reimplement. Both take more effort per hop, which pushes Community users towards fewer, better-planned upgrades. - Already on Odoo 19. There is nothing to decide this year. Standard support is planned to run until September 2028. Read the Odoo 20 release notes when they are out, run a test upgrade once your modules are available for 20, and move when that test is clean. - Your calendar. For Indian companies on an April–March financial year, don't go live on a new version during year-end closing or around GST return deadlines. A September or October decision usually means a go-live between November and January, or waiting until after the books are closed. ## How to make the decision in one meeting - Write down your version and hosting. These two facts decide most of the answer, using the table above. - Count custom and third-party modules. A rough count is enough to see whether you are facing weeks of work or months. - Name the features you need. Only features in the released Odoo 19 count. Odoo 20 features don't count until the release notes are out. - Check your calendar. Block out closing, filing and peak-season dates. - Request a test upgrade. Nothing settles the argument faster than your own database running on the target version. For the step-by-step of moving to 19, read upgrading to Odoo 19 from 16, 17 or 18 . If you are further behind than 16, planning a multi-version jump is the better starting point. When you want a test upgrade, upgrade.hadoopt.com is where we take requests. ## Questions we get asked **Q: Should I upgrade to Odoo 19 or wait for Odoo 20?** It depends on your current version. On Odoo 16 or 17, upgrade to 19 now, because 16 is already out of standard support and 17 is due to leave it in September 2026. On Odoo 18, which is supported until September 2027, waiting and moving directly to Odoo 20 once it has had a few months to settle is reasonable. **Q: Is Odoo 17 still supported?** Odoo's published table lists September 2026 as the planned end of standard support for Odoo 17. After that, Odoo.sh and on-premise customers can buy extended support for a mandatory extra fee. It includes helpdesk support and bug fixes where feasible. Odoo's upgrade documentation also lets the last unsupported version be used as an upgrade target for up to six months after its end of life. **Q: Can I upgrade directly from Odoo 16 to Odoo 19?** Yes. Odoo's upgrade service upgrades a database from an older version to a newer supported version in one request, and its own documentation uses 16.0 to 18.0 as an example. You choose the target version. Custom modules still have to be ported to the target version before the production upgrade, and every business flow should be tested on an upgraded test database first. **Q: Is it safe to upgrade to a new Odoo version right after release?** Test upgrades, yes. Production is a judgement call. A new major version gets bug fixes in its first months, and third-party modules often take time to be published for it. We run test upgrades early but usually schedule production go-live once the first round of fixes has landed and every module you depend on is available for the new version. --- ## Getting started with Odoo 19: what changed and where to begin - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/getting-started-with-odoo-19 - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, ERP implementation, Odoo Community, Odoo Enterprise What Odoo 19 is, the changes from Odoo 18 a business actually notices, which apps to roll out first, and who should move to 19 now. Odoo 19 is the current long-term release of Odoo, published in September 2025 and under standard support until September 2028. For a business, the visible changes from Odoo 18 are the new AI agents and AI fields (Enterprise only), employee contracts folded into the Employees app, product packagings folded into units of measure, and a long list of smaller workflow improvements. Any new implementation today should start on 19, and most businesses on 16 or 17 should plan to move within the next year. This is part 1 of our Odoo 19 guide. The series follows the order we would roll the apps out in a real project: setup first, then sales, operations, finance, HR and the extras. ## What Odoo 19 is, in practical terms Odoo is one database with many apps on top: CRM, Sales, Inventory, Invoicing, Employees and so on. You install only what you need, and every app you add reads and writes the same customers, products and accounts. That shared data is the whole point. A delivery validated in Inventory is what Invoicing bills, and the invoice is what Accounting reports on. It comes in two editions. Community is open source (LGPL-3) and free to run. Enterprise is Community plus Odoo's proprietary modules (licence OEEL-1) on a paid subscription. In the 19.0 source we work from, 671 modules are LGPL and 709 are Enterprise. The split matters for app choice: Sales, CRM, Inventory, Purchase, Manufacturing, Point of Sale, Website, eCommerce, Project, Employees and Invoicing are Community. The full Accounting app, Payroll (including Indian Payroll), Helpdesk, Documents, Knowledge, Sign, Studio and all the AI features are Enterprise. ## What changed from Odoo 18 that a business notices Odoo's release notes run to hundreds of items. These are the ones that change how people work or how an implementation is planned. - AI built in. A new AI app lets you create agents with their own instructions, sources (files, web pages, Knowledge articles) and tools. Any field can be made an AI field that fills itself from a prompt. Server actions gain an "Update with AI" option, Live Chat can hand visitors to an AI agent, and an Ask AI button turns plain questions into searches. All of this is Enterprise and needs an OpenAI or Google Gemini API key on a self-hosted server. Part 5 covers it properly. - Contracts are gone as a separate app. In Odoo 18, contracts lived in their own module. In 19, wage, contract dates and working terms sit on dated versions of the employee record inside the Employees app. HR and payroll teams need a short walkthrough before go-live, and any custom code built on contracts needs rework. - Packagings are units of measure now. The separate product packaging model has been removed. A "box of 12" is now a unit of measure on the product, listed in its Packagings field. Warehouses that sell by carton or case will see different screens, and imports from older templates need adjusting. - Payroll batches are "Pay Runs". The menu and the flow around them have been reworked in the Enterprise Payroll app. - Portal self-service. Portal users get an address book in the customer portal where they add, edit and archive their own billing and delivery addresses, instead of emailing your team to change them. - Integration APIs are changing. The XML-RPC and JSON-RPC endpoints ( /xmlrpc , /xmlrpc/2 , /jsonrpc ) are deprecated in 19. Odoo's documentation schedules their removal for Odoo 22 (fall 2028), and the replacement is the JSON-2 API at /json/2 . Integrations still work today, but new ones should be built on JSON-2. Under the hood, the minimums have moved too: Python 3.10 or later and PostgreSQL 13 or later, with PostgreSQL 15 or later plus the pgvector extension if you want the AI features. ## Which apps to start with The mistake we see most is switching on eight apps in the first week because the licence allows it. Every app brings its own settings and its own training. Start with the apps that hold your master data and your money, then add the rest. - Settings, company and users. Company details, GSTIN and fiscal localisation, currencies, users and access rights. Nothing else is safe until this is right. - Contacts, products and Invoicing or Accounting. Customers, vendors, the product catalogue, taxes and the chart of accounts. For Indian companies, the Indian accounting localisation loads GST taxes and the chart of accounts. - Sales or Point of Sale, and Purchase. Whichever side of the business earns the money first. - Inventory, then Manufacturing if you make things. Stock only after products and units are clean. - Employees, Time Off, Payroll, Project, Helpdesk, Website. Add these in waves once the core flows are stable. Two apps can wait almost indefinitely: Studio and the AI features. Both are more useful once you know how your team actually uses the standard screens. > Configure the standard flow first and customise second. Most customisation requests go away once people have used the standard screens for a month. ## Who should move to Odoo 19 now If you are still on Tally, spreadsheets or an older ERP, the question is not which Odoo version to use. It is how clean your opening balances, customer masters and item lists are. That work takes longer than installing Odoo, whichever version you pick. ## How this guide is organised Parts 2 and 3 cover installation and hosting: running Odoo 19 yourself from source, Docker or packages, and choosing between Odoo Online, Odoo.sh and your own servers. Part 4 sets up the company, users and access rights. Part 5 explains the AI modules. From part 6 onwards we go app by app, from CRM through to Studio, and part 36 covers upgrading from 16, 17 or 18. If you are deciding where Odoo 19 will run, read part 3 on hosting next, since that choice limits what you can customise later. If you would like an implementer to sanity-check your app list and rollout order, that is what we do . ## Questions we get asked **Q: When was Odoo 19 released and how long is it supported?** Odoo 19.0 was released in September 2025. Odoo gives each major version three years of standard support, covering helpdesk support, bug fixes and security updates, so Odoo 19 is planned to be supported until September 2028. After that, extended support is available on Odoo.sh and on-premise for an additional fee, while Odoo Online moves databases forward on its own schedule. **Q: Is Odoo 19 Community free?** Yes. Odoo 19 Community is licensed LGPL-3 and costs nothing to download and run on your own server. It includes CRM, Sales, Purchase, Inventory, Manufacturing, Point of Sale, Website, eCommerce, Project, Employees and Invoicing. Full Accounting, Payroll, Helpdesk, Studio, Documents, Knowledge, Sign and the AI features need an Enterprise subscription. For licence costs, check odoo.com/pricing. **Q: Are the AI features available in Odoo 19 Community?** No. The base AI module in Odoo 19 is licensed OEEL-1, which means Enterprise only, and every other AI module depends on it, including AI fields and AI server actions. On a self-hosted Enterprise server you also need your own OpenAI or Google Gemini API key, and PostgreSQL 15 or later with the pgvector extension for document search. **Q: Should I upgrade from Odoo 18 to Odoo 19 straight away?** Not necessarily. Odoo 18 has standard support until September 2027, so a stable Odoo 18 database can wait until a specific Odoo 19 feature, such as AI agents or the new employee versions, justifies the effort. Businesses on Odoo 16 or 17 have less time and should start planning, especially if they run custom modules that need rewriting. --- ## Installing Odoo 19 from source, Docker or packages - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/installing-odoo-19-source-docker-packages - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Installation, Docker, PostgreSQL, Deployment Installing Odoo 19 from source, the official Docker image or Debian/Ubuntu packages, plus production settings: workers, proxy mode, websocket, dbfilter. Odoo 19 needs Python 3.10 or later and PostgreSQL 13 or later (15 or later, with the pgvector extension, if you want the AI features), plus wkhtmltopdf 0.12.6 for PDF reports. You can run it from a git checkout of the source, from the official Docker image, or from Odoo's Debian/Ubuntu packages, which target Ubuntu 24.04. Whichever you choose, production means multi-worker mode behind a reverse proxy, with proxy mode on, websocket traffic routed to port 8072, and the database manager locked down. This is part 2 of our Odoo 19 guide. If you have not yet decided whether to host Odoo yourself at all, read part 3 on hosting first. Odoo Online needs none of this. ## Odoo 19 system requirements The minimums are written into the 19.0 source itself: MIN_PY_VERSION = (3, 10) and MIN_PG_VERSION = 13 in odoo/release.py . Odoo warns at startup if PostgreSQL is older. The requirements.txt file says the officially supported Python package versions are the ones shipped in Ubuntu 24.04 and Debian 12, so those are the safest operating systems to build on. - PostgreSQL: 13 or later. For AI agents and document search, the pgvector extension is required, and Odoo's documentation notes it is only available for PostgreSQL 15 and up. If AI is on your roadmap, start on 15 or 16 now rather than migrating the database later. - wkhtmltopdf: not installed by pip. Install version 0.12.6 by hand, or invoices and quotations print without headers and footers. - rtlcss: only if you use a right-to-left language such as Arabic or Hebrew. ## Installing Odoo 19 from source We use the source install on developer machines and on servers where we want exact control over the code, for example when custom modules are deployed through git. On Debian or Ubuntu the sequence is short. ``` $ git clone --branch 19.0 --single-branch https://github.com/odoo/odoo.git $ cd odoo $ sudo ./setup/debinstall.sh # system packages from debian/control $ sudo apt install postgresql postgresql-client $ sudo -u postgres createuser -d -R -S $USER $ python3 -m venv ~/venv-odoo19 && . ~/venv-odoo19/bin/activate $ pip install -r requirements.txt $ python3 odoo-bin --addons-path=addons -d mydb ``` Community from source. Enterprise customers also clone odoo/enterprise. For Enterprise, clone the enterprise repository with the same branch and put its path first in --addons-path , ahead of the Community addons. Access to that repository comes with an Enterprise subscription. Keep custom modules in a third directory of their own, never inside the Odoo checkout, so that pulling Odoo's bug fixes is a clean git pull . ## Running Odoo 19 with the official Docker image The odoo image on Docker Hub is built by Odoo from the Community nightly package, on Ubuntu 24.04, with wkhtmltopdf included. It exposes ports 8069, 8071 and 8072 and expects a separate PostgreSQL container. ``` $ docker run -d -v odoo-db:/var/lib/postgresql/data \ -e POSTGRES_USER=odoo -e POSTGRES_PASSWORD=odoo \ -e POSTGRES_DB=postgres --name db postgres:15 $ docker run -d -v odoo-data:/var/lib/odoo \ -v /srv/odoo/config:/etc/odoo -v /srv/odoo/addons:/mnt/extra-addons \ -p 8069:8069 --name odoo --link db:db -t odoo:19.0 ``` Named volumes keep the database and filestore when containers are replaced. Three paths matter. /var/lib/odoo holds the filestore, where every attachment lives; without a volume there, removing the container deletes your attachments. /etc/odoo holds odoo.conf . /mnt/extra-addons is where your custom modules go. In production we use Docker Compose with the same volumes and never the odoo / odoo password shown in the examples. Two cautions. The image is Community; for Enterprise you mount the Enterprise addons yourself and add them to the addons path. And the standard postgres image does not include pgvector, so for AI features you need a PostgreSQL image with that extension built in. ## Installing Odoo 19 from Debian/Ubuntu packages The package route installs Odoo as a system service, creates the PostgreSQL user and starts the server for you. Odoo publishes a nightly repository for Community: ``` $ sudo apt install postgresql -y $ wget -q -O - https://nightly.odoo.com/odoo.key | sudo gpg --dearmor \ -o /usr/share/keyrings/odoo-archive-keyring.gpg $ echo 'deb [signed-by=/usr/share/keyrings/odoo-archive-keyring.gpg] https://nightly.odoo.com/19.0/nightly/deb/ ./' \ | sudo tee /etc/apt/sources.list.d/odoo.list $ sudo apt-get update && sudo apt-get install odoo ``` Updates then arrive through the usual apt-get upgrade. There is no nightly repository for Enterprise. Enterprise customers download the .deb from Odoo's download page (you must be logged in as a paying customer or partner) and install it with apt install ./file.deb . The Odoo 19 deb supports Ubuntu 24.04 (Noble). The configuration file is /etc/odoo/odoo.conf . Packages suit a single-purpose server with few or no custom modules. Once you have a real custom codebase, we prefer source or Docker, because you control exactly which Odoo revision runs with which version of your code. ## Production settings: workers, proxy mode, websocket, dbfilter Out of the box Odoo runs with workers = 0 : a single threaded process that is fine on a laptop and wrong for a business. Setting workers to a positive number switches on the multi-processing server (Linux only), which also starts a separate gevent worker for real-time traffic (Discuss, Live Chat, notifications) on gevent_port , 8072 by default. ``` [options] workers = 9 ; (CPUs x 2) + 1 as a ceiling max_cron_threads = 1 limit_time_cpu = 600 limit_time_real = 1200 proxy_mode = True dbfilter = ^%d$ list_db = False admin_passwd = # nginx location /websocket { proxy_pass http://127.0.0.1:8072; ... } location / { proxy_pass http://127.0.0.1:8069; ... } ``` The shape of a production config. Size workers from your own load, not from this. - Workers. Odoo's own rule of thumb is (number of CPUs × 2) + 1 as the upper limit, and roughly one worker per six concurrent users. Cron jobs need CPU too. Memory is the other limit: Odoo's documentation estimates about 150 MB for a light worker and about 1 GB for a heavy one. - Proxy mode. Put nginx (or another proxy) in front for HTTPS, and set proxy_mode = True so Odoo trusts the forwarded host, scheme and client IP. Only enable it behind a proxy you control. - Websocket. Route /websocket to port 8072 with the Upgrade and Connection headers set. If you skip this, chat and live notifications quietly stop working. Older guides and some config templates still mention longpolling_port ; in 19 the option is gevent_port . - dbfilter. On a server with more than one database, especially with Website installed, dbfilter must be set so each hostname maps to one database. ^%d$ matches the database named after the first part of the domain. - Database manager. Once each hostname maps to a single database, set list_db = False , and change admin_passwd from its admin default. That password can create, copy and drop databases from the browser. Backups are the last piece. Back up both the PostgreSQL database and the filestore together, keep copies off the server, and restore one to a test machine every so often to prove it works. With Odoo running, the next decision is whether you should be running it at all. Part 3 compares Odoo Online, Odoo.sh and self-hosting . If you want a second pair of eyes on a production setup, get in touch . ## Questions we get asked **Q: What Python version does Odoo 19 need?** Odoo 19 requires Python 3.10 or later; the minimum is set in the source as MIN_PY_VERSION = (3, 10). Odoo's pinned dependencies follow the Python packages shipped with Ubuntu 24.04 and Debian 12, so the Python that comes with either distribution is the safest choice. Use a dedicated virtual environment per Odoo version so library versions do not clash. **Q: Which PostgreSQL version should I use for Odoo 19?** Odoo 19 supports PostgreSQL 13 and later, and warns at startup on anything older. If you plan to use the Enterprise AI features, you need the pgvector extension, which Odoo documents as available only for PostgreSQL 15 and up. For a new server we would install PostgreSQL 15 or 16 so AI stays an option without migrating the database later. **Q: Is the official Odoo Docker image Community or Enterprise?** The official odoo image on Docker Hub is Community. It is built from Odoo's Community nightly Debian package on Ubuntu 24.04 and includes wkhtmltopdf. To run Enterprise in Docker, mount the Enterprise addons from your subscription into the container and put that path first in the addons path, or build your own image that includes them. **Q: What port does Odoo 19 use for websockets?** In multi-worker mode, Odoo 19 serves websocket traffic from a separate gevent worker on gevent_port, which defaults to 8072, while normal HTTP requests use 8069. Configure your reverse proxy to send requests for /websocket to port 8072 with the Upgrade and Connection headers, and enable proxy_mode. Without this, Discuss, Live Chat and live notifications stop updating. **Q: How many workers should an Odoo 19 server have?** Odoo's guidance is to treat (CPUs × 2) + 1 as the maximum and to plan roughly one worker per six concurrent users, leaving CPU for scheduled jobs. Check memory too: Odoo estimates about 150 MB per light worker and around 1 GB per heavy one. Start from those figures, then adjust based on the CPU load and response times you actually see. --- ## Odoo 19 hosting: Odoo Online vs Odoo.sh vs on-premise - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-hosting-online-odoo-sh-on-premise - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Odoo hosting, Odoo.sh, Odoo Online, Self-hosting Choosing where Odoo 19 runs: Odoo Online, Odoo.sh or your own servers. Custom modules, upgrades, control, and which kind of business each suits. Odoo 19 can run in three places: Odoo Online (Odoo's shared SaaS), Odoo.sh (Odoo's managed platform for Enterprise with your own git code) and on-premise, meaning any server you control. The deciding question is custom modules. Odoo Online does not accept custom or App Store modules, so if you need code, the choice is between Odoo.sh, where Odoo runs the servers, and self-hosting, where you run everything, including upgrades. This is part 3 of our Odoo 19 guide. Part 2 covers the technical install if you self-host. ## The three Odoo 19 hosting options side by side ## Odoo Online: standard Odoo, no code Odoo Online gives you a private database on Odoo's servers, reached from a browser, with nothing to install. You configure it through Settings and can customise screens and fields with Studio. What you cannot do is install custom modules or modules from the Odoo Apps Store. Odoo's documentation is explicit about this. Online databases also run Odoo's intermediate SaaS releases. Since Odoo 19.0 in September 2025, Odoo has shipped 19.1, 19.2, 19.3 and 19.4 for Online only. You get new features sooner, but you also take upgrades on Odoo's timetable: a database on a major version must upgrade every two years, and one on an intermediate version must upgrade a few weeks after the next one is released. You are notified ahead of time and can test first, but you cannot decline indefinitely. Odoo Online suits businesses whose processes fit standard Odoo plus Studio: trading companies, service firms, small manufacturers and most retail setups we see. It is the lowest-effort option by some distance. ## Odoo.sh: Enterprise with your own code, managed by Odoo Odoo.sh is Odoo's hosting platform for Enterprise customers who need custom modules. Your project is linked to a GitHub repository, and every branch becomes a build. Branches sit in one of three stages: - Production: one per project. Pushing a commit updates and restarts the live server; if the update fails, Odoo.sh rolls the code and database back automatically. - Staging: a neutralised copy of production for testing. Scheduled actions are disabled, outgoing emails are caught by a mail catcher, and payment providers and shipping connectors are switched to test mode. - Development: fresh databases with demo data, where automated tests run. Production is backed up automatically, keeping seven daily, four weekly and three monthly backups, each with the database, filestore, logs and sessions. Upgrades are integrated: you request an upgraded copy on a staging branch, fix your modules against it, then upgrade production when ready. After a version's three years of standard support, Odoo.sh gives you another two years to complete the upgrade. Odoo.sh suits businesses with a meaningful custom codebase who do not want to run servers: a few integrations, some bespoke workflows, an in-house or partner development team that works in git. The trade-off is the subscription cost on top of the Enterprise licence, and less freedom over the server than your own machine gives you. ## On-premise and self-hosted Odoo On-premise, in Odoo's terms, means any server you run: a machine in your office, a VPS, or your own AWS or Azure account. It is the only option for Community edition, and it is also available for Enterprise. You get complete control. You choose the region and data centre, which matters for some Indian businesses with data residency requirements or contracts that name a location. You can install any module, connect to anything on your network and tune PostgreSQL as you like. And you can stay on a version indefinitely; Odoo does not force upgrades on self-hosted databases, though it recommends against staying behind. The cost of that control is responsibility. Security patches, backups that are actually tested, monitoring, HTTPS certificates, PostgreSQL upgrades, disk space and the Odoo upgrade itself are all yours. For Enterprise, upgrades still go through Odoo's upgrade service; for Community, there is no official upgrade service, and you rely on the open-source OpenUpgrade project or a partner. > Self-hosting is cheap to start and expensive to neglect. The cost is not the server. It is someone watching it. ## Which Odoo hosting option suits your business - List what you need that standard Odoo does not do. Be honest about integrations: a courier API, a bank feed, a machine on the shop floor, an e-commerce marketplace. - If Studio and Settings cover it, choose Odoo Online. Accept its upgrade rhythm as part of the deal. - If you need code and have no one to run servers, choose Odoo.sh. Keep the code in git from day one. - If you need Community, a specific region, deep network integration or full control, self-host. Budget for the operations work, not just the server. - Write the decision down with its reasons. Moving later is possible but not free. Moving between options is supported with limits. Odoo can bring an on-premise or Odoo.sh database into Odoo Online only after every non-standard module has been uninstalled. Going the other way, from Online to Odoo.sh or your own server, is a backup download and restore, provided you are on a major version. Changing hosting is not part of an upgrade; plan it as its own step. Once you know where Odoo will live, the next job is the same everywhere: set up the company, users and access rights properly. That is part 4 . If you would like help weighing the options against your customisation list, talk to us . ## Questions we get asked **Q: Can I install custom modules on Odoo Online?** No. Odoo Online does not support custom modules or modules from the Odoo Apps Store. You can customise it with Settings and the Studio app, which adds fields, changes views and builds simple automations without code. If you need custom Python modules or third-party apps, you need Odoo.sh or an on-premise server running Odoo Enterprise or Community. **Q: What is the difference between Odoo.sh and Odoo Online?** Both are hosted by Odoo and run Enterprise, but Odoo.sh lets you deploy your own code from a GitHub repository, with separate production, staging and development branches, automatic backups and shell access. Odoo Online runs only standard Odoo plus Studio and receives intermediate SaaS versions. Odoo.sh is for businesses with custom modules; Odoo Online is for those without. **Q: Can Odoo Community be hosted on Odoo.sh?** No. Odoo Online and Odoo.sh both run Odoo Enterprise. Odoo Community is only available self-hosted, on your own hardware, a VPS or a cloud account such as AWS or Azure. That gives you full control and no licence fee, but you handle security, backups and upgrades yourself, and there is no official Odoo upgrade service for Community. **Q: Do I have to upgrade Odoo if I self-host?** No. Odoo does not force upgrades on on-premise databases; you can keep a version running indefinitely. Odoo recommends against it, because after three years of standard support a version stops getting free bug fixes and security updates. Smaller version gaps are also easier to upgrade, so staying put usually makes the eventual upgrade harder and more expensive. --- ## Setting up companies, users and access rights in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-company-users-access-rights - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Multi-company, Access rights, User management Odoo 19 company setup, branches and multi-company, users and roles, per-app access rights, and the difference between internal and portal users. In Odoo 19, company setup, users and permissions all live under Settings › Users & Companies. Set up the company first (legal details, tax ID, logo, document layout), decide whether extra entities are separate companies or branches, then create users with a role and an access level per app. Anyone outside your organisation, such as a customer or vendor, should be a portal user, never an internal one. This is part 4 of our Odoo 19 guide. It assumes Odoo is installed and you have chosen where it runs ( part 3 ). ## Company setup in Odoo 19 Everything that prints comes from the company record: invoices, quotations, delivery slips, payslips. Get it right before anyone creates a document. ``` Settings › General Settings › Companies Update Info name, address, tax ID, currency, logo Manage Companies list of companies and branches Document Layout layout, fonts, colours, footer Settings › Users & Companies Users · Companies · Groups (developer mode) ``` Where company and user setup lives in Odoo 19. For an Indian company, the tax ID is your GSTIN, and the state on the address matters because it drives whether GST is split into CGST and SGST or charged as IGST. The company's currency and chart of accounts come from the fiscal localisation you pick when you set up Invoicing or Accounting. Install the right localisation (the Indian one for INR and GST) before you post a single entry, because changing it afterwards is painful. Then open Document Layout and set the layout, logo, colours and footer. Five minutes here saves weeks of "can we change the invoice" requests. ## Branches vs separate companies Odoo 19 gives you two ways to model more than one entity, and choosing the wrong one is hard to undo. In India we usually model each extra GST registration of the same legal entity (one GSTIN per state) as a branch of the parent company, and a genuinely separate private limited company as its own company. A group with a trading company in Chennai and a services company in Bengaluru is two companies. One company with warehouses registered in Tamil Nadu and Karnataka is one company with branches. Once you have more than one company, each user gets a Companies list (what they may access) and a Default Company on the Access Rights tab of their user record. A company switcher appears in the top bar, and record rules keep each user's data limited to the companies they have selected. For groups that trade with each other, the Inter-Company Transactions setting (Enterprise) creates the matching sales order, purchase order or bill in the other company automatically. ## Users, roles and per-app access rights Create users under Settings › Users & Companies › Users. In Odoo 19 the user form's Access Rights tab starts with a Role : User or Administrator . Administrator gives access to Settings; keep it to one or two people. Below the role, each installed app shows its own access level. Sales, for example, offers three: - User: Own Documents Only — sees their own quotations and orders. - User: All Documents — sees the whole team's. - Administrator — can also change the app's configuration. Most apps follow the same pattern of user, officer or manager levels. Leaving an app blank means the user cannot open it at all. In developer mode, the user form also shows buttons counting the groups, access rights and record rules that apply to that person, which is the fastest way to answer "why can't Priya see this?". - Write down roles, not people. "Sales executive", "Accounts assistant", "Store keeper", "Warehouse manager". Five to ten roles cover most businesses. - Map each role to an access level per app. A small table is enough: role down the side, apps across the top. - Set Default Access Rights. Settings › General Settings › Permissions defines what every new user starts with. Make it the least-privileged role. - Create users and adjust from the default. Only give extra access for a reason you can state. - Review every quarter. People change jobs; their access rarely follows unless someone checks. Two security settings belong in the same sitting. Enforce two-factor authentication can apply to employees only or to all users. And Minimum Password Length defaults to 8 characters; raise it if your policy asks for more. > The access rights problem we fix most often is not someone seeing too little. It is the finance module open to everyone because it was quicker at go-live. ## Internal users vs portal users Odoo has two kinds of login. Internal users work inside the back end with the apps and access levels above. Portal users are external: customers, vendors, sometimes contractors. They log in to the website portal at /my and see only their own records, such as quotations to accept and sign, invoices to download and pay, delivery status, support tickets and shared project tasks, depending on which apps you run. You do not create portal users from the Users menu. Open the contact, choose Grant portal access from the action menu, and Odoo sends an invitation email. The user record that results is flagged as an external user, with a ribbon on its form. Keep the line clean. Never make a customer or a freelance accountant an internal user to "just let them see one thing"; they will see far more than that. Internal users are what Enterprise subscriptions are counted on, so the portal is usually the cheaper answer as well as the safer one. See odoo.com/pricing for current terms. With the company, users and roles in place, you can safely install the business apps. Before that, part 5 looks at the new AI features , since some of them depend on the access you have just defined. If you are structuring several companies or GST registrations, we can help you plan it . ## Questions we get asked **Q: What is the difference between a branch and a company in Odoo 19?** A branch is a sub-company created from the Branches tab of a parent company. It takes the parent's chart of accounts template and respects the parent's lock dates, so it suits the same legal entity operating in another location or under another tax registration. A separate company has its own localisation and books, and suits a different legal entity. **Q: How do I give a customer access to their invoices in Odoo?** Open the customer's contact record, use the action menu and choose Grant portal access. Odoo emails them an invitation to set a password. Once logged in at /my on your website, they see only their own documents, such as quotations, sales orders, invoices and, if those apps are installed, helpdesk tickets and project tasks. Portal users cannot open the back-end apps. **Q: How do I restrict a salesperson to their own quotations in Odoo 19?** Open the user under Settings, Users and Companies, Users, go to the Access Rights tab and set the Sales access level to User: Own Documents Only. They will then see only the quotations and sales orders where they are the salesperson. User: All Documents shows the whole team's records, and Administrator adds access to the Sales configuration. **Q: Can I force two-factor authentication in Odoo 19?** Yes. In Settings, the Enforce two-factor authentication option lets you require 2FA for employees only or for all users, including portal users. Users who have not set up an authenticator app are asked to verify by email at login until they do. It is worth enabling from the start, especially for administrators and anyone with Accounting access. --- ## AI in Odoo 19: agents, AI fields and AI automation explained - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/ai-in-odoo-19-agents-ai-fields-automation - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, AI, Odoo Enterprise, Automation, AI agents What each Odoo 19 AI module actually does: agents, AI fields, AI server actions, Documents, CRM, Live Chat, Knowledge and Website. Limits included. Odoo 19 adds a family of AI modules: agents you configure with instructions, sources and tools; AI fields that fill themselves from a prompt; "Update with AI" in server actions; and AI hooks in Documents, CRM, Live Chat, Knowledge and Website. All of it is Enterprise-only, because every AI module depends on the base ai module, which is licensed OEEL-1. It calls OpenAI or Google Gemini, so a self-hosted server needs your own API key and PostgreSQL with pgvector. This is part 5 of our Odoo 19 guide. It describes what the modules do according to their code in the 19.0 source, not the marketing pages. ## The Odoo 19 AI modules and what each one does Most of these install automatically when their parent apps are present. A helper module, ai_auto_install , installs the base ai module only if the pgvector extension is available on the database server, so if AI is missing on a self-hosted instance, check PostgreSQL first. ## AI agents, topics and sources The AI app (AI › Agents) is where you build agents. Each agent has: - System Prompt : its instructions, tone and boundaries. - LLM Model : the default is GPT-4o. The list covers OpenAI models from GPT-3.5 Turbo to GPT-5 and Gemini 1.5 and 2.5 models. - Response Style : Analytical, Balanced (default) or Creative. - Sources : files or URLs, plus Knowledge articles and Documents files when those modules are installed. Sources are indexed into vector embeddings, which is why pgvector is required. Tick Restrict to Sources to stop the agent answering from general knowledge. - Topics : bundles of instructions plus tools. A tool is a server action marked Use in AI , so an agent can only do what you have explicitly given it an action for. Odoo ships several system agents. Ask AI turns plain questions ("pivot of products with less than 5 in stock", "top 5 sales reps by revenue") into searches and opens the matching view. Odoo Agent is the general-purpose default used by the AI drafting prompts and by AI server actions. Under Configuration › Default Prompts you can edit the prompts behind buttons such as "Summarize the chatter conversation" or "Write a followup answer". ## AI fields and "Update with AI" server actions ai_fields adds an AI tab to field definitions: tick AI field and write an AI Prompt that can reference other fields on the record. With Studio installed, you can create these fields there instead of in developer mode. Typical uses are a one-line summary of a long description, a product category guessed from the product name, or a sentiment tag on a ticket. Two behaviours are worth knowing. Empty text, char and HTML AI fields are filled by a scheduled action ("AI Fields: Compute AI fields") in batches, starting with the most recent 50 records when the field is created. That job currently only runs with an OpenAI key; if none is set, it skips silently. Other field types, such as dates, numbers and many2one or tag fields, are computed from the form view instead. ai_server_actions adds Update with AI as a way to compute the value in an Update Record server action. Combine it with an automation rule and you get, for example, "when a lead is created, set its industry from the company description". Only stored fields can be updated this way. Separately, the base module adds an AI action type that runs a prompt with a chosen set of tools. ## AI in Documents, CRM, Live Chat, Knowledge and Website - Documents ( ai_documents ). An administrator writes an AI Folder Sort Prompt on a folder. Files dropped there are sorted into the folders named in the prompt and tagged, using the tools "AI: Move To Folder" and "AI: Add Tags". The AI can only move files to folders the prompt mentions, and only ordinary files, not shortcuts. This is the most immediately useful AI feature for teams receiving scanned bills and HR paperwork. - CRM ( ai_crm ). Adds a "Create Leads" topic. Its instructions tell an agent to offer a human follow-up when it cannot answer confidently, collect name, email and phone one at a time, confirm them, and create one lead. - Live Chat ( ai_livechat ). Each Live Chat channel rule gains an AI Agent field next to the scripted chatbot. If both are set, the AI agent takes priority. With CRM installed, the default "Livechat AI Agent" also gets the lead creation topic. - Knowledge ( ai_knowledge ). Knowledge articles can be added as agent sources, and AI drafting works inside articles. - Website ( ai_website ). A system agent, "Website Page Generator", writes placeholder text for new pages in the language and tone you choose. It is archived by default, which keeps it out of the agent list, but Odoo calls it directly when generating a page. An AI Livechat snippet is also added to the website builder. > The useful question is not "where can we add AI?" It is "which repetitive judgement call does someone make fifty times a day?" ## Sensible first uses and real limits - Connect a provider. AI › Configuration › Settings: "Use your own ChatGPT account" or "Use your own Google Gemini account". Agree who pays the bill and set a spending limit with the provider. - Start with Ask AI and email drafting. Low risk, visible benefit, no configuration. - Add one AI field or one Documents sort prompt. Something a person would otherwise do by hand, where a wrong answer is cheap to fix. - Only then build a customer-facing agent. Live Chat with Restrict to Sources on, a small, curated set of sources, and lead creation as the fallback. The limits are real. Your data is sent to OpenAI or Google, so check this against your privacy policy and customer contracts; for Indian businesses, consider the Digital Personal Data Protection Act before sending personal data. Answers can be wrong, so keep a human in the loop anywhere money, stock or legal documents are involved. Costs scale with usage and are billed by the provider. And AI fields fill in batches on a schedule, not instantly. If the built-in agents do not cover what you need, such as an AI step inside a custom workflow or a model running on your own infrastructure, that is custom work on top of Odoo. Our AI development team builds exactly that. Next in the series, part 6 sets up CRM . ## Questions we get asked **Q: Is AI available in Odoo 19 Community?** No. The base ai module in Odoo 19 is licensed OEEL-1, which is Enterprise only. The ai_fields and ai_server_actions modules are LGPL, but they depend on the base ai module, so they cannot be installed on Community alone. To use AI agents, AI fields or AI sorting in Odoo 19, you need an Enterprise subscription. **Q: Which AI models does Odoo 19 support?** Odoo 19 supports OpenAI and Google Gemini. The agent model list includes GPT-3.5 Turbo, GPT-4, GPT-4o, GPT-4.1, GPT-4.1 Mini, GPT-5 and GPT-5 Mini, plus Gemini 1.5 Pro, Gemini 1.5 Flash, Gemini 2.5 Pro and Gemini 2.5 Flash. New agents default to GPT-4o. On a self-hosted server you enter your own API key in the AI settings. **Q: Why does Odoo 19 AI need pgvector?** Odoo 19 turns agent sources such as PDFs, web pages and Knowledge articles into vector embeddings stored in PostgreSQL, and searches them by similarity when answering. That needs the pgvector extension, which Odoo documents as available for PostgreSQL 15 and up. Without it, the ai_auto_install module does not install the AI features automatically. **Q: What is an AI field in Odoo 19?** An AI field is an ordinary field with a prompt attached. Odoo sends the prompt, including values from other fields on the record, to the AI model and stores the answer in the field. Text fields are filled in batches by a scheduled action that needs an OpenAI key, while other field types are computed from the form. You can create AI fields in Studio. **Q: Can an Odoo 19 AI agent answer customers on Live Chat?** Yes. With the ai_livechat module, each Live Chat channel rule has an AI Agent field. Set it and visitors matching that rule talk to the agent first; if a scripted chatbot is also set, the AI agent takes priority. With CRM installed, the agent can collect contact details and create a lead when it cannot answer confidently. --- ## Setting up Odoo 19 CRM: leads, pipeline stages and lead scoring - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-crm-leads-pipeline - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, CRM, Sales pipeline, Lead scoring Configuring Odoo 19 CRM: leads vs opportunities, pipeline stages, predictive lead scoring, lead assignment, activities, lost reasons and reports. Odoo 19 CRM is a Community (LGPL) app that tracks every enquiry as a lead or an opportunity and moves it through a kanban pipeline of stages you define. Get three things right before go-live: whether you need a separate lead qualification step, what your stages actually mean, and which lost reasons you will insist on. Scoring, auto-assignment and dashboards are only as useful as those three decisions. This is part 6 of our Odoo 19 guide. It assumes your company, users and access rights are already in place, as covered in part 4 . ## Leads vs opportunities in Odoo 19 Both are the same record underneath (the crm.lead model); a field called type is either Lead or Opportunity. Out of the box, Odoo skips leads entirely: every new enquiry lands straight in the pipeline as an opportunity. Switching on Leads in the settings adds a qualification step. A new top-level Leads menu appears, incoming enquiries wait there, and someone converts each one into an opportunity. The conversion wizard lets you convert or merge with a duplicate, and link to an existing customer, create a new one or leave the contact unlinked. ``` CRM › Configuration › Settings CRM Recurring Revenues Leads (qualification step) Multi Teams (one salesperson, several teams) Lead Generation Predictive Lead Scoring Rule-Based Assignment Lead Enrichment · Lead Mining · Visits to Leads ``` The settings that shape the CRM, in the order we decide them. Leads are also switched on or off per sales team (the Leads checkbox on the team), so a telesales team can qualify while a key-accounts team works straight from the pipeline. Each team can have its own email alias that creates leads from incoming mail. ## Designing pipeline stages A new database comes with four stages: New, Qualified, Proposition and Won. Only the Won stage has Is Won Stage? ticked, which sets the probability to 100%. There is deliberately no "Lost" stage. Losing an opportunity archives it and sets its probability to zero, so lost deals leave the board without cluttering a column. Stages live under CRM › Configuration › Pipeline › Stages. Each one can be limited to specific sales teams and has a Requirements field, shown as a tooltip on the column, where you write the exit criteria. Use it. "Proposition" means nothing unless everyone agrees it means "a priced quotation has been sent". The mistake we see most is stages that describe activities ("Call back", "Send brochure") instead of the buyer's commitment. Activities belong in the activity planner; stages should be milestones you could audit. Five to seven stages is usually plenty. ## Predictive lead scoring and rule-based assignment Predictive Lead Scoring computes an automated probability for each open lead from how similar leads were won or lost in the past. It always uses stage and sales team, plus the frequency fields you pick. The default set is phone quality, email quality, state, country, source, language and tags. You set a start date so that ancient, badly entered history does not skew it, and an Update Probabilities button recalculates on demand. A scheduled action also recomputes it regularly. If a salesperson types their own probability, the automated value is kept separately and the two stop syncing until someone resets it. This works well once you have a few hundred closed opportunities with clean lost reasons. On a brand-new database it has little to learn from, so do not promise the sales director accurate percentages in month one. Rule-Based Assignment distributes unassigned leads to team members. Each team and each member gets a domain (for example country = India, or a particular tag), and each member has an Average Leads Capacity (on 30 days) , 30 by default, which caps how many leads they receive. Assignment can run manually or on a schedule, repeating every so many minutes, hours, days or weeks. Members can pause assignment during leave. Lead Enrichment, Lead Mining and Visits to Leads also sit in this settings block. They rely on Odoo's paid IAP credits, so check the cost before you switch them on. ## Activities, activity plans and lost reasons Every opportunity carries scheduled activities (call, meeting, email, to-do) with due dates. Activity types and reusable Activity Plans are configured under CRM › Configuration › Activities. A plan schedules a whole sequence in one click, such as "demo booked": a prep task, the meeting and a follow-up call. My Activities under the Sales menu is the page salespeople should open every morning. When a deal is marked lost, a wizard asks for a Lost Reason and free-text feedback. The defaults are Too expensive, We don't have people/skills, and Not enough stock. Replace them with your own list under Pipeline › Lost Reasons before go-live. Keep it short and mutually exclusive, so the lost-reason report actually means something. "Other" should be rare enough that someone asks about it. - Agree stage definitions and write them into each stage's Requirements. - Replace the default lost reasons with six to eight of your own. - Set up sales teams, members and email aliases. - Import open opportunities (the Import & Synchronize menu), including history if you want scoring later. - Add activity plans for your two or three most common sequences. - Only then consider scoring, assignment rules and enrichment. ## CRM reporting: pipeline, forecast and activities The Reporting menu has Forecast, Pipeline, Leads and Activities. Forecast groups open opportunities by expected closing month, using expected revenue and probability, and it is the report sales managers end up living in. Pipeline gives the graph and pivot analysis by stage, salesperson, team or source. Activities shows who is doing the follow-up work and who is not. If you sell contracts, Recurring Revenues adds a recurring amount and plan (Monthly, Yearly and so on) to each opportunity, alongside the one-off expected revenue. Enterprise adds cohort and map views to the CRM analysis. Dates matter: Expected Closing drives the forecast, so make it a required habit rather than an optional field. For Indian businesses moving off spreadsheets or a Tally-plus-Excel setup, import only live opportunities first. Bring in historical won and lost deals later, once your lost reasons and sources are mapped consistently. ## Connecting CRM to quotations With the Sales app installed, the Opportunity to Quotation bridge ( sale_crm ) is installed automatically and a New Quotation button appears on every opportunity. Quotations stay linked, so the opportunity shows how many quotations and orders it has and their untaxed total. Marking the deal Won is still a deliberate click, so make it part of your order-confirmation routine. That is where the next post picks up: quotations and sales orders in Odoo 19 . If you would like a second pair of eyes on your stage design or assignment rules before the team starts using them, get in touch . ## Questions we get asked **Q: What is the difference between a lead and an opportunity in Odoo 19?** In Odoo 19 a lead and an opportunity are the same CRM record with a different type. A lead is an unqualified enquiry waiting in the Leads menu; an opportunity sits in the pipeline with a stage, expected revenue and probability. Leads only exist if you enable the Leads setting; otherwise every new record starts as an opportunity. **Q: Is Odoo CRM free in the Community edition?** Yes. The Odoo 19 CRM app is licensed LGPL-3 and ships with Community, including pipeline stages, leads, predictive lead scoring, rule-based assignment, activities, lost reasons and the forecast report. Enterprise adds extras such as cohort and map views. Lead enrichment and lead mining use Odoo's paid IAP credits in either edition. **Q: How does predictive lead scoring work in Odoo 19?** Predictive lead scoring compares each open lead with won and lost leads since a start date you choose. It looks at stage, sales team and the fields you select, by default phone and email quality, state, country, source, language and tags, and computes an automated probability. It needs a reasonable history of closed deals before its numbers are reliable. **Q: Why is there no Lost stage in the Odoo CRM pipeline?** Odoo treats lost as a status, not a stage. Marking an opportunity lost asks for a lost reason, sets its probability to zero and archives it, so it disappears from the kanban board. You can still find lost opportunities with the Lost filter and analyse them by reason in the pipeline reports. --- ## Quotations and sales orders in Odoo 19: templates, e-signature and invoicing policy - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-quotations-sales-orders - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Sales, Quotations, Invoicing Configuring Odoo 19 Sales: quotation templates, optional sections, online signature and payment, ordered vs delivered invoicing, and down payments. In Odoo 19 the Sales app (Community, LGPL) takes a quotation from draft to confirmed sales order and then to invoice. The decisions that matter most are the invoicing policy (invoice what is ordered or what is delivered), whether customers must sign or pay online to confirm, and how you use quotation templates . Settle those first; everything else is presentation. This is part 7 of our Odoo 19 guide, following CRM and the pipeline . Most settings below live under Sales › Configuration › Settings. ## How a quotation becomes a sales order in Odoo 19 A sales document in Odoo 19 has four states: Quotation, Quotation Sent, Sales Order and Cancelled. Quotation and order are the same record. Confirming a quotation (by a salesperson, or by the customer on the portal) turns it into a sales order with the same S-number. That triggers deliveries if Inventory is installed and makes it available for invoicing. Each quotation has an expiry date. The Default Quotation Validity is 30 days, set per company; 0 turns automatic expiry off. Customers see the quote on the portal, can accept it there, and can download the PDF. Salespeople can still edit a confirmed order unless you enable Lock Confirmed Sales , which we recommend once your team trusts the flow. ``` Sales › Configuration › Settings Quotations & Orders Quotation Templates (Default Template) Online Signature on by default Online Payment Prepayment percentage: 100% Default Quotation Validity 30 days Lock Confirmed Sales Pro-Forma Invoice Invoicing Invoicing Policy Invoice what is ordered | Invoice what is delivered ``` The settings behind the quote-to-invoice flow. ## Quotation templates and optional sections Enable Quotation Templates to get Sales › Configuration › Quotation Templates. The setting comes from the Sales Management module, which is Community. A template holds product lines, sections and notes, a quotation duration, terms and conditions, a confirmation email, an invoicing journal, and its own online signature and payment rules. You can pick one as the company's default template. Optional products work differently in Odoo 19. Earlier versions had a separate "Optional Products" tab on quotations. In 19, you mark a section as optional. The lines under it are shown to the customer on the portal as add-ons they can include or drop, and the quote total updates. This makes "base package plus optional extras" quotes much tidier: one section for the core scope, one optional section for the upgrades. Products also carry an Optional Products field. That is a cross-sell list suggested when a product is added, which is mostly relevant to eCommerce. If quotes must look like a brochure, PDF Quote builder (Community) adds header and footer pages and per-product documents to the quotation PDF. ## Online signature and online payment Online Signature is on by default for new companies. The customer signs on the portal and the signed quote is confirmed and stored with the signature. Online Payment asks the customer to pay before the order is confirmed, either in full (the default 100%) or as a partial prepayment such as 30%. Both defaults can be overridden per template and per quotation. Online payment needs an active payment provider. For Indian businesses that usually means the Razorpay provider (Community) for UPI and cards; Stripe, PayPal, Adyen and others are also available. With the policy set to Invoice what is ordered and online payment on, you can also enable Automatic Invoice , which generates the invoice as soon as the online payment is confirmed. Where teams go wrong is switching on both signature and full payment for every B2B deal. A procurement team that needs a purchase order raised internally will not pay a portal link on day one. Use signature for B2B, and payment for small-ticket or B2C deals. ## Invoicing policy: ordered vs delivered quantities The Invoicing Policy is set on each product. The company setting only chooses the default for new products. For services, installing Project adds a Service Invoicing Policy : prepaid/fixed price, milestones (when milestones are enabled), or delivered quantity entered manually. The timesheet-based option arrives with the timesheet integration, covered in part 31 . Each order shows an invoice status: Nothing to Invoice, To Invoice, Fully Invoiced, or Upselling Opportunity. The last one appears when a customer has been delivered more than they ordered on an ordered-quantity product. The Sales › To Invoice menu is the daily worklist for your billing team. ## Down payments and advance invoices The Create Invoice button on a sales order offers three options: Regular invoice, Down payment (percentage) and Down payment (fixed amount). A down payment invoice is posted against a down payment line on the order. When you later create the regular invoice, Deduct down payments (ticked by default) subtracts it automatically. A dedicated Downpayment Account can be set per company in the settings, and it is worth deciding before the first advance invoice is posted. Talk to your accountant before the first advance invoice. Advances received carry GST implications in India, and the chart of accounts and tax setup belong in the accounting posts ( part 22 covers GST). If you only need to show a customer the numbers before they pay, a Pro-Forma Invoice is a document, not an accounting entry. ## What to configure first and what can wait - Decide the default invoicing policy and correct it on existing products. - Choose online signature and/or payment defaults, and connect a payment provider if needed. - Set quotation validity and your standard terms and conditions. - Build two or three quotation templates for your most common offers. - Test a down payment, a partial delivery and a final invoice end to end with your accountant. - Later: discounts, margins, PDF Quote builder, commissions (Enterprise). Prices on these quotes come from your product catalogue and pricelists, the subject of the next post: products, variants and pricelists in Odoo 19 . If you want help mapping your current quote-to-invoice process onto Odoo, see our Odoo implementation service . ## Questions we get asked **Q: Where did optional products go in Odoo 19 quotations?** Odoo 19 replaced the separate optional products tab with optional sections. On a quotation or quotation template you mark a section as optional, and the product lines inside it are offered to the customer on the online quote as add-ons they can include or remove. The product form still has an Optional Products field for cross-selling suggestions. **Q: Can customers sign and pay a quotation online in Odoo 19?** Yes. Online Signature is enabled by default, so customers can sign a quotation on the customer portal to confirm it. Online Payment can require full or partial prepayment before confirmation and needs an active payment provider such as Razorpay or Stripe. Both defaults can be changed per quotation template and per individual quotation. **Q: What is the difference between invoicing ordered and delivered quantities in Odoo?** With ordered quantities, the whole order can be invoiced as soon as it is confirmed. With delivered quantities, only what has actually been delivered, validated in Inventory or entered manually on the order line, can be invoiced. The policy is set per product; the Sales setting only chooses the default applied to newly created products. **Q: How do down payments work in Odoo 19 Sales?** From a confirmed sales order, click Create Invoice and choose a percentage or fixed-amount down payment. Odoo creates an advance invoice and a down payment line on the order. When the regular invoice is created later, the Deduct down payments option, ticked by default, subtracts the advance automatically so the customer is not billed twice. --- ## Products, variants and pricelists in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-products-variants-pricelists - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Products, Pricelists, Product variants The Odoo 19 product catalogue: Goods, Service and Combo types, Track Inventory, variants and attributes, the new units of measure, and pricelist rules. In Odoo 19 every product has one of three types: Goods , Service or Combo . Stock tracking is a separate Track Inventory checkbox on goods. Variants come from attributes, units of measure no longer use categories, and pricelists hold rule-based prices per customer group, quantity or period. Get the product master right before you import thousands of SKUs; it is the hardest thing to fix later. This is part 8 of our Odoo 19 guide, after quotations and sales orders . Products and pricelists are a shared base module ( Products & Pricelists , Community) used by Sales, Purchase, Inventory, Point of Sale and eCommerce alike. ## Product types in Odoo 19: Goods, Service and Combo The Product Type field has three values. In the database they are consu , service and combo ; Goods is the default. If you are coming from Odoo 17 or earlier, the old "Storable Product" and "Consumable" types have gone. They are now one type, Goods, plus the Track Inventory checkbox. Once tracking is on you can also choose tracking by quantity, lots or unique serial numbers. Migration scripts map the old values, but check a sample after any upgrade. For Indian companies, the product also carries an HSN/SAC Code field from the Indian localisation. It flows to invoices and to POS receipts, so fill it at product-creation time, not at GST-return time. ## Variants and attributes Turn on Variants in the Sales (or Inventory) settings. Attributes such as Size or Colour, and their values, are defined once. Each product template then picks the attributes and values it uses. Each value can carry an extra price on top of the template's sales price. The key setting is on the attribute: Variant Creation . - Instantly creates a variant for every combination as soon as you save. Each variant can have its own barcode, internal reference, cost and stock. - Dynamically creates a variant only when that combination is first added to an order. This suits made-to-order configurations. - Never does not create variants at all. The value is recorded as a description on the order line, which suits engraving text, gift wrap or a "no onions" choice. Odoo caps instant generation at 1,000 new variants per template by default (the system parameter product.dynamic_variant_limit ). If you hit it, the model is wrong, not the limit. Three sizes by four colours is a variant problem; forty lengths by sixty finishes is usually a "Never" attribute plus a price rule. The Multi-checkbox display type only works with "Never", because a single variant cannot hold several values of the same attribute. Other display types (Radio, Pills, Select, Color, Image) only change how the choice looks on the configurator, the website and in POS. ## Units of measure and packagings in Odoo 19 Odoo 19 simplified units of measure. UoM categories are gone. Each unit now has a Reference Unit and a Contains factor: a Pack of 6 contains 6 Units, and a kg contains 1,000 g. Enable Units of Measure & Packagings in the settings and manage them under Sales › Configuration › Units & Packagings. Packagings are now additional units on the product itself (the Packagings field): a box of 24 or a pallet of 40 boxes becomes a unit you can sell in. The purchase unit is set per vendor line on the product's vendor pricelist. That is where "we buy in cartons, sell in pieces" belongs. ``` Unit Reference Contains Units — 1 Pack of 6 Units 6 g — 1 kg g 1000 Box/24 Units 24 ← your own packaging ``` How units relate in Odoo 19. All but the last row ship with Odoo; Box/24 is an example of your own. ## Pricelists and price rules Enable Pricelists in Sales settings, then open Sales › Products › Pricelists. A pricelist has a currency, optional country groups (and a website, if you use eCommerce), and a set of rules. Each rule has: - Apply On : All Products, Product Category, Product or Product Variant. - Price Type : Discount (a percentage off), Formula, or Fixed Price. - Based on (for formulas): Sales Price, Cost or Other Pricelist, with a discount, a surcharge, rounding, and minimum and maximum margins. - Minimum quantity and a start and end date , for quantity breaks and time-limited promotions. When several rules match, the most specific wins: variant, then product, then category, then all products, with higher minimum quantities checked first. Assign a pricelist to a customer on the contact form, in the Sales & Purchase tab, so dealers, distributors and retail customers each get their own prices automatically. How the price shows on the quote matters to customers. If you enable the Discounts setting, Discount -type rules appear on the order line as the list price with a visible discount percentage. Formula and Fixed Price rules simply change the unit price. Use Discount rules when your customer expects to see "MRP less 15%"; use Formula or Fixed when the net price is the price. > Price by rule, not by hand. Every manual discount a salesperson types is a margin decision nobody reviewed. ## A sensible order to set up the product catalogue - Agree product categories, since they drive accounting properties and pricelist rules. - Decide Goods vs Service vs Combo, and Track Inventory, for each product family. - Define units and packagings before importing products. - Create attributes and choose the Variant Creation mode for each. - Import products with HSN/SAC codes, taxes, barcodes and vendor lines. - Build pricelists last, as rules on categories rather than thousands of fixed prices. If you are moving from Tally, expect the stock item master to need restructuring. Tally's stock groups and units rarely map one-to-one to Odoo categories, variants and packagings, and it is cheaper to redesign them than to import them as they are. Next in the series: selling these products over the counter with Odoo 19 Point of Sale for retail and restaurants . For help restructuring a messy item master, see our Odoo implementation service . ## Questions we get asked **Q: What are the product types in Odoo 19?** Odoo 19 has three product types: Goods, Service and Combo, stored as consu, service and combo. Goods is the default. Whether goods are stock-managed is controlled by a separate Track Inventory checkbox, which replaced the old Storable Product type. Combo products bundle choices from groups of products, for example a meal deal or a gift hamper. **Q: What happened to storable products in Odoo 19?** The separate Storable Product type no longer exists. Since Odoo 18, physical items are all of type Goods, and ticking Track Inventory on the product makes Odoo manage stock quantities, with optional tracking by lots or serial numbers. When a database is upgraded, former storable products become Goods with Track Inventory enabled. **Q: When should I use variants instead of separate products in Odoo?** Use variants when products share a name, description and most settings but differ by attributes such as size or colour, and each combination needs its own stock, barcode or cost. Use separate products when items differ in category, taxes or vendors. For choices that do not need stock, such as engraving, set the attribute's Variant Creation to Never. **Q: How do pricelist rules decide which price applies in Odoo 19?** Odoo looks at the rules on the customer's pricelist that match the product, quantity and date. The most specific rule wins: product variant first, then product, then product category, then all products, and higher minimum quantities are checked before lower ones. A rule can give a discount, a formula based on price or cost, or a fixed price. --- ## Odoo 19 Point of Sale for retail and restaurants - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-point-of-sale-retail-restaurant - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Point of Sale, Restaurant, GST Odoo 19 Point of Sale setup: sessions, payment methods and terminals, restaurant floors and kitchen printing, offline mode, and GST on Indian receipts. Odoo 19 Point of Sale is a Community (LGPL) app that runs in a browser on any tablet, PC or phone, keeps selling when the internet drops, and posts each session to accounting as a single journal entry when it closes. Restaurants add floors, tables, courses and kitchen order printing on top, still in Community. The kitchen preparation display screen and several hardware and delivery integrations are Enterprise. This is part 9 of our Odoo 19 guide. POS sells the products and prices you set up in part 8 , so do that first. ## How Odoo 19 POS is structured: shops, sessions and orders Each till or outlet is a point of sale (one configuration record) with its own payment methods, product categories, pricelists, receipt header and footer, and printers. Settings live under Point of Sale › Configuration › Settings, with the shop picked at the top of the page. One shop can be flagged Is a Bar/Restaurant ; the rest behave as retail. Staff open a session on a shop, sell, and close it. If the shop has a cash payment method, cash control is on automatically: the opening float is counted, and at closing the expected and counted cash are compared, with the difference posted. Closing the session creates the accounting journal entry for all its orders. Orders where the customer asked for an invoice get a proper customer invoice as well. ``` Point of Sale › Configuration › Settings Point of Sale shop picker · Is a Bar/Restaurant Payment payment methods Payment Terminals Razorpay · Pine Labs · Adyen · Stripe … Pricing Default Pricelist · Available Pricelists Accounting Default Sale Tax · Fiscal Positions Bills & Receipts Receipt Header / Footer · Automatic Receipt Printing Preparation Order Printer Connected Devices ePos Printer · Customer Display · IoT Box ``` The areas to work through per shop, in the order the settings page lists them. ## Payment methods and card terminals A payment method is one of three types, decided by its journal: Cash , Bank , or Customer Account (no journal, so the amount goes onto the customer's receivable to settle later). Each bank method then has an integration: None required (the cashier records a card or UPI payment taken on a separate device), Terminal , or Bank App (QR Code) where a QR format is available for your bank account. Terminal integrations in 19 include Razorpay and Pine Labs, both Community modules and relevant in India, plus Adyen, Stripe, Viva.com, Mercado Pago, QFPay and Worldline. With an integrated terminal the amount is pushed to the device and the result comes back automatically, which removes a whole class of end-of-day mismatches. The mistake we see most is a single "Card" method for everything. Create one method per settlement account, for example Razorpay card, UPI and cash, so each reconciles against its own bank or clearing account. Your finance team will thank you at month end. ## Restaurant features: floors, tables and kitchen printing Ticking Is a Bar/Restaurant installs the Restaurant module (Community) and adds: - Floors and tables. You draw the plan directly in the POS: square or round tables, seats, colours and positions per floor. The default screen can be Tables or Register. - Bill Printing and Bill Splitting. Print a bill before payment, or split one table across several payments. - Courses. Group lines into courses and fire each one to the kitchen when the table is ready. - Presets such as dine-in, takeout and delivery. Each can carry its own pricelist and fiscal position and ask for a name or address. - Tips , including setting the tip after card payment. For the kitchen, an Order Printer is configured per shop and prints new and changed lines for the product categories you assign to it, for example drinks to the bar and mains to the kitchen. A printer is either an Epson ePOS printer on the network, reached directly, or a printer connected to an IoT Box (the IoT app is Enterprise). The preparation display , a kitchen screen with stages and preparation-time reporting, comes from the Point of Sale enterprise module (OEEL). So do the customer-facing order tracking display and the UrbanPiper connector. UrbanPiper's Indian localisation includes Swiggy and Zomato as delivery providers. QR-code menus, ordering from the table, and self-order kiosks come from POS Self Order, which installs with Restaurant in Community. ## Offline mode: what keeps working The POS is a web application that caches its data in the browser (using IndexedDB and a service worker). If the connection drops mid-shift, cashiers keep scanning, taking payments and printing receipts. Orders queue locally and sync once the connection returns. There are limits. The POS must have been loaded online first. Integrated terminals, QR bank payments and online payments need connectivity. Anything created in the backend while you are offline will not appear until you reconnect. Do not clear the browser's data on a till with unsynced orders, and do not close the session until everything has synced. ## GST on POS receipts in India With the Indian localisation, the Indian - Point of Sale module installs automatically. For a company registered under GST, the receipt shows the HSN/SAC code on each line and an HSN summary table with the rate and the CGST, SGST and, where applicable, IGST and cess amounts. The HSN code is copied from the product onto each order line, which is one more reason to fill it in on every product before go-live. Receipts also show the customer name and phone when a customer is set. For B2B walk-ins who need input credit, set the customer (with their GSTIN on the contact) and tick invoice, so a proper tax invoice is generated. Enterprise adds GSTR India eFiling with POS , which feeds POS orders into the GSTR-1 data set. GST setup in general is covered in part 22 . - Products, POS categories, taxes and HSN codes are complete. - One shop per till, with receipt header and footer. - Payment methods, one per settlement account, with terminals paired. - Restaurant: floors, tables, order printers per category. - A full dry-run day: open, sell, refund, go offline, reconnect, close, and check the journal entry with accounts. Next in the series: selling online with Odoo 19 eCommerce . If you are choosing POS hardware or terminals for a new outlet, talk to us before you buy. ## Questions we get asked **Q: Does Odoo 19 Point of Sale work offline?** Yes. Odoo 19 POS caches products, prices and customers in the browser, so cashiers can keep selling, taking cash and manual card payments, and printing receipts when the connection drops. Orders are stored locally and synchronised when the connection returns. Integrated card terminals, QR bank payments and anything created in the backend need connectivity, and the POS must be loaded online first. **Q: Is the Odoo restaurant POS available in Community?** Yes. The Odoo 19 Restaurant module is LGPL and adds floor plans, tables, bill splitting, bill printing, courses, presets such as dine-in and takeout, tips and kitchen order printers. QR menus and self-ordering are also Community. The kitchen preparation display, order tracking screen, IoT Box and UrbanPiper delivery connector need Enterprise. **Q: Does Odoo POS print GST details on receipts in India?** Yes. For a company registered under GST, the Indian Point of Sale module prints the HSN/SAC code on each receipt line and adds an HSN summary with the tax rate and CGST, SGST, IGST and cess amounts. The HSN code comes from the product, so it must be set on every product. B2B customers can request a full tax invoice at the till. **Q: Which card terminals integrate with Odoo 19 POS in India?** Odoo 19 includes Community integrations for Razorpay and Pine Labs terminals, both widely used in India, alongside Adyen, Stripe, Viva.com and others. With an integrated terminal the amount is sent to the device and the result returns to the POS automatically. Without one, create a payment method with no integration and record payments taken on a separate machine. --- ## Setting up an online shop with Odoo 19 eCommerce - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-ecommerce - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, eCommerce, Payment providers, B2B Odoo 19 eCommerce setup: publishing the catalogue, checkout steps, payment providers such as Razorpay, delivery methods, and B2B vs B2C tax display. Odoo 19 eCommerce (the website_sale module, Community) turns your product catalogue into a shop on the Odoo Website. Orders land in Sales as ordinary sales orders, so stock, invoicing and accounting work exactly as they do for quotes. Most of the setup work is in four places: which products are published, the checkout steps, payment providers, and delivery methods. For B2C, the one setting to change on day one is the tax display: Odoo shows prices tax-excluded by default. This is part 10 of our Odoo 19 guide. It builds on the products and pricelists in part 8 ; the website pages themselves are covered in part 32 . ## Publishing the product catalogue A product appears in the shop only when it is published and can be sold. Beyond that, the eCommerce-specific fields on the product are the eCommerce categories (separate from internal product categories, so the shop menu can follow how customers browse rather than how accounts are posted), extra images, a ribbon such as "New" or "Sale", and optional and accessory products for cross-selling in the cart. Variants appear as selectors on the product page, using the attribute display types you chose in the product setup. Combo products appear as configurable bundles. The eCommerce settings also offer Product Reference Price (a price per unit such as ₹/kg), Comparison Price (a struck-through reference price) and a Google Merchant Center feed. With Inventory installed, Product Availability lets you show stock levels and decide per product whether to Sell when Out-of-Stock . It is on by default. Turn it off for anything you cannot restock quickly, or you will be refunding orders. ``` Website › Configuration › Settings shop settings Website › eCommerce › Products › Products publish, categories, ribbons Website › eCommerce › Products › Pricelists Website › Configuration › eCommerce › Payment Providers Website › Configuration › eCommerce › Delivery Methods ``` Where the eCommerce setup lives in the Website app. ## The Odoo 19 checkout: steps and customer accounts Out of the box the checkout has three steps: Order (the cart), Address (with delivery method) and Payment . A fourth, Extra Info , exists but is off by default. Switch it on in the website editor if you need a PO number, a delivery note or a GSTIN confirmation from the buyer. Key settings on the shop's settings page: - Customer Accounts at checkout: Optional (the default), Disabled (buy as guest) or Mandatory (no guest checkout). - Add to Cart : stay on the product page, or go straight to the cart. - Abandoned carts : a recovery email sent after a delay you set (10 hours by default). - Prevent Sale of Zero Priced Product , which replaces the buy button with a contact button for price-on-request items. - Orders Assignment : the salesperson and sales team that own web orders. ## Payment providers for an Odoo shop Payment providers are shared by eCommerce, online quotations and invoices. Each is a Community module you activate and configure with your merchant credentials. In India the usual choice is Razorpay , which supports UPI alongside cards. Stripe, PayPal, Adyen, Mollie and others cover international sales. Some providers support express checkout, where the customer pays with a wallet straight from the cart. Two special providers are worth knowing about. Wire Transfer shows your bank details and leaves the order to be confirmed when the money arrives. Cash On Delivery is offered only on delivery methods where you have allowed it. Test every provider in its test mode with a real order, a failed payment and a refund before going live. Payment fees and settlement timing are set by the provider, not by Odoo. Record provider payouts through the provider's journal so bank reconciliation stays sane (see part 21 ). ## Delivery methods and shipping connectors A delivery method is either a Fixed Price or Based on Rules (weight, volume, quantity or price bands), optionally free above an order amount. Methods can be limited by country, state or ZIP prefix, so "Tamil Nadu next-day" and "rest of India" can be separate lines with separate prices. Carrier connectors calculate live rates and print labels. Shiprocket, relevant for Indian sellers, is an Enterprise module, as are most carrier connectors. Click & Collect (Community) lets customers pick up from a store or warehouse. If your shipping is complicated, start with a few rule-based methods by zone and weight, and add a connector once you know your volumes. A wrong live-rate integration is harder to debug than a simple table. ## B2B vs B2C: prices, taxes and access The same shop can serve consumers and trade customers, but you have to decide how prices appear. Display Product Prices is set per website and defaults to Tax Excluded. If you genuinely need both behaviours, the clean option is two websites on one database (for example a retail shop and a trade portal), each with its own tax display, access rule and pricelists. Pricelists can be tied to a website, restricted by country group, made selectable by the visitor, or applied with an E-commerce Promotional Code . A logged-in customer with their own pricelist sees their prices automatically. > Decide who the shop is for before you design it. The tax display, the login rule and the pricelists all follow from that one answer. ## What to configure first - Clean product data: names, images, eCommerce categories, HSN codes and taxes. - Set tax display, customer accounts and shop access for your audience. - Activate one payment provider in test mode, then live. - Create two or three delivery methods by zone. - Place test orders through to invoice and delivery, including a return. - Later: abandoned-cart emails, product comparison, wishlists, merchant feeds, carrier connectors. If your shop sells plans rather than one-off products, the next post covers subscriptions and recurring revenue in Odoo 19 . For an end-to-end shop launch, including payments and GST, see our Odoo implementation service . ## Questions we get asked **Q: Is Odoo eCommerce free in the Community edition?** Yes. The Odoo 19 eCommerce module, website_sale, is LGPL and included in Community with the Website app. It covers the product catalogue, cart, checkout, customer accounts, pricelists, payment providers such as Razorpay and Stripe, and rule-based delivery methods. Some extras, including most carrier connectors such as Shiprocket and the website sales dashboard, require Enterprise. **Q: How do I show prices including GST on an Odoo 19 website?** Open the Website settings and set Display Product Prices to Tax Included. The setting is per website and defaults to Tax Excluded. Your product taxes stay as they are; only the displayed price changes, so shoppers see the GST-inclusive amount they will pay. Check that every published product has the correct GST tax before switching. **Q: Which payment gateways work with Odoo 19 in India?** Odoo 19 includes a Razorpay payment provider, a Community module that supports UPI and cards, which is the usual choice for Indian shops. Stripe, PayPal and other international providers are also available. You can add Wire Transfer and Cash On Delivery, the latter enabled per delivery method. Each provider needs your own merchant account and credentials. **Q: Can one Odoo shop serve both B2B and B2C customers?** Partly. Pricelists assigned per customer give trade buyers their own prices on the same shop. However, tax display, shop access and sign-up rules are set per website, so B2B buyers wanting tax-excluded prices and consumers wanting tax-included prices cannot both be satisfied by one website. Running two websites on one Odoo database solves that. --- ## Odoo 19 Subscriptions: recurring plans, renewals and MRR - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-subscriptions-recurring-revenue - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Subscriptions, Recurring revenue, MRR How Odoo 19 Subscriptions works: recurring plans, automatic invoicing and payment, renewals and upsells, close reasons, and MRR and churn reporting. Odoo 19 Subscriptions is an Enterprise-only app ( sale_subscription , OEEL-1) that turns a sales order into a recurring contract. A daily scheduled action raises each period's invoice and, where the customer has saved a payment method, charges it. Renewals, upsells and cancellations are tracked as MRR events. Set up your recurring plans and subscription products first; the reporting only makes sense if those are clean. This is part 11 of our Odoo 19 guide. A subscription is a sales order underneath, so the quotation and product setup from part 7 and part 8 applies here too. ## How subscriptions work in Odoo 19 There is no separate contract object. A subscription is a sale.order with a Recurring Plan and at least one subscription product. It moves through its own subscription states: Quotation, In Progress, Paused, Renewal Quotation, Renewed, Upsell and Churned. Because it is still a sales order, templates, pricelists, taxes, online signature and online payment all work as they do in Sales. The app has its own menu: Subscriptions › Subscriptions (with Quotations, To Renew and Upsells views), Products, Reporting and Configuration. The customer portal shows each subscription with its invoices. Depending on the plan, customers can also renew, add products, pause or close from the portal. ``` Subscriptions › Configuration Settings Consolidate subscriptions billing Recurring Plans Monthly · Yearly (defaults) Quotation Templates template → Recurring Plan Close Reasons retention message + button ``` Configuration menu of the Subscriptions app. ## Recurring plans and subscription products A Recurring Plan defines the billing period: a number and a unit of Weeks, Months or Years. So "every 3 months" is one plan, not a workaround. Monthly and Yearly exist by default. Each plan also sets: - Align to Period Start : bill everyone on the first day of the period rather than on each start date. - Automatic Closing : how many days an overdue subscription is kept before it is closed. The default is 15. - Self-service options: Closable (at a date or at the end of the period), Renew , Add Products , Pausable , and Optional Plans the customer may switch to. - The invoice email template used for recurring invoices. On the product, tick Subscription Product and fill the Recurring Pricing table with one price per plan, for example a monthly price and a discounted yearly price. Accept One-Time lets the same product also be sold outright. Prorated Price controls whether partial periods (upsells mid-term, or calendar alignment) are charged pro rata. ## Recurring invoicing and automatic payment Each subscription has a next invoice date . A scheduled action ( generate recurring invoices and payments ) runs daily. It creates the invoice for every subscription due that day and, if a payment token is saved on the subscription, charges it through the payment provider. Without a token, the invoice goes out by email, and a separate reminder job nudges customers with no saved payment method. Invoicing follows the product's invoicing policy. Lines on ordered quantities are billed in advance for the coming period (prepaid). Lines on delivered quantities are billed for what was delivered during the period (postpaid), which suits metered usage. The Consolidate subscriptions billing setting puts all of a customer's subscriptions due on the same day onto one invoice. For Indian businesses, every recurring invoice is a normal GST invoice, with the usual HSN/SAC codes and place-of-supply logic. Recurring card and UPI debits are also subject to RBI's e-mandate rules. Confirm with your payment provider how tokenised auto-debit works for your customers before you promise "automatic payment" in the contract. ## Renewals, upsells and closing a subscription An upsell is a quotation linked to a running subscription, used to add products or quantities mid-term. It is priced pro rata to the next invoice date where prorating is on. Confirming it adds the lines to the parent subscription and the upsell itself is invoiced for the rest of the current period, so the customer keeps one contract and one billing date. A renewal is a new quotation for the next term, typically at new prices or on a new plan. Once it is confirmed, the original subscription is marked Renewed and the new order carries the contract forward, keeping the link to the first contract for reporting. Subscriptions due soon show up under To Renew . Closing asks for a close reason . Odoo ships reasons such as "Subscription is too expensive" and "I don't use it", plus protected system reasons for automatic closure and unpaid subscriptions. A close reason can carry a retention message and a button that the customer sees on the portal before confirming. Use it for "talk to us first" or "switch to the yearly plan" rather than letting self-service cancellation be one click. > Name the churn before you chase it. A close-reason list you actually maintain is worth more than any dashboard. ## MRR and churn reporting Every subscription carries its MRR , its recurring amount normalised to a month. Each change is logged as an event: New, Expansion, Contraction, Churn or Transfer. The Reporting menu has four views: These figures are only as good as the data behind them. If you migrate live contracts from spreadsheets, Tally or another billing tool, import them with their real start dates and next invoice dates. Otherwise every legacy customer shows as "New" MRR in the month you went live, which ruins the first year of growth charts. ## A sensible rollout order - Agree the plans you will actually sell (period, alignment, self-service rights). - Create or convert subscription products with recurring prices per plan. - Connect a payment provider that supports saved payment methods, and test a token charge. - Rewrite close reasons and retention messages. - Migrate live contracts with correct start and next invoice dates; reconcile the first MRR report against your old numbers. - Turn on customer self-service (renew, pause, close) only after the first billing cycle runs cleanly. That closes the sales section of the series. Next we move into operations, starting with inventory and warehouse management . If you are moving recurring billing into Odoo and want the migration planned properly, talk to us . ## Questions we get asked **Q: Is Odoo Subscriptions available in Community edition?** No. The Odoo 19 Subscriptions app, module sale_subscription, is licensed OEEL-1 and only available with Odoo Enterprise, including Odoo Online and Odoo.sh. Community users can record recurring revenue on CRM opportunities or create invoices manually, but automatic recurring invoicing, renewals, upsells and MRR reporting need the Enterprise Subscriptions app. **Q: How does Odoo 19 generate recurring invoices?** Each subscription has a next invoice date. A scheduled action runs daily, creates invoices for all subscriptions due that day, and charges the saved payment token if there is one. Without a token, the invoice is emailed for manual payment. Lines on ordered quantities are billed in advance; lines on delivered quantities are billed after the period for actual usage. **Q: How is MRR calculated in Odoo Subscriptions?** Odoo computes MRR on each subscription by converting its recurring amount to a monthly figure according to its plan, so a yearly plan contributes one twelfth each month. Changes are logged as New, Expansion, Contraction, Churn or Transfer events, which feed the MRR Breakdown and MRR Timeline reports under Subscriptions › Reporting. **Q: What happens when a subscription payment fails in Odoo 19?** The subscription stays open while it is overdue, and customers without a working payment method receive reminders. If it remains unpaid beyond the plan's Automatic Closing period, 15 days by default, Odoo closes it automatically with a system close reason and it is counted as churn. You can reopen a churned subscription if the customer pays. --- ## Inventory and warehouse management in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-inventory-warehouse-management - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Inventory, Warehouse management, Stock valuation Warehouses, locations, 1/2/3-step receipts and deliveries, routes, reordering rules, lots and serials, and how Odoo 19 values stock. Odoo 19 Inventory is a Community app that handles warehouses, locations, receipts, deliveries and replenishment; valuation comes from the WMS Accounting module that sits beside it. Start every warehouse at one-step receipts and deliveries, switch on Storage Locations and Lots & Serial Numbers only where you need them, and decide your cost method and valuation (periodic or perpetual) before the first receipt, because changing them later recomputes the cost of stock you already hold. ## Warehouses, locations and the settings that switch them on A new database has one warehouse with a five-character short name ( WH by default) and a stock location under it. That short name prefixes every transfer reference, so WH/IN/00012 is a receipt and WH/OUT/00012 a delivery. Pick short names you can read on a printed slip: CBE and BLR work better than WH2 . Most of the structure is hidden until you turn it on under Inventory > Configuration > Settings , in the Warehouse block: - Storage Locations lets you create bins, racks and zones under the stock location and track quantities in each. - Multi-Step Routes enables two- and three-step flows, custom routes and putaway rules. Turning it on also turns on Storage Locations. Locations are a tree, and only internal locations hold stock you own. Vendor, customer, inventory loss and production locations are virtual; stock moving into them leaves your books. Putaway rules ( Configuration > Warehouse Management > Putaway Rules ) send incoming products straight to a specific child location, and storage categories cap what a bin can hold. ## One, two or three steps for receipts and deliveries Each warehouse has an Incoming Shipments and an Outgoing Shipments setting. These are the exact options in 19.0: The default is one step both ways. We keep it there unless there is a physical reason not to: a separate dock and storage area, a packing bench, or goods that must wait for inspection. Every extra step is another document someone has to validate, and an unvalidated pick is a common reason a delivery shows "waiting" when the stock is sitting on the shelf. Three-step receipts do not create inspection records by themselves. The checks come from the Quality app, covered in part 15 . ## Routes, reordering rules and replenishment A route is a set of rules that says where stock comes from. The ones you will meet first are Buy (from Purchase), Manufacture (from Manufacturing), Replenish on Order (MTO) and Dropship . MTO and Dropship are switched on in the Logistics block of the settings. A product's routes, together with the warehouse steps above, decide what document Odoo creates when demand appears. Reordering rules are the everyday tool. Each rule has a location, a Min and Max quantity and a Trigger of Auto or Manual. With Auto, the scheduler creates RFQs or manufacturing orders when forecast stock falls below the minimum. With Manual, the need only appears in Operations > Procurement > Replenishment for someone to order. The Advanced Scheduling setting adds a horizon in days so rules fire earlier. We usually start new clients on Manual for the first few weeks. Buyers see what Odoo would have ordered, correct the min and max figures and vendor lead times, and only then flip the trustworthy products to Auto. > Reordering rules are only as good as the lead times behind them. Fix the vendor delay on the product first, then tune min and max. ## Lots, serial numbers and removal strategies Turn on Lots & Serial Numbers under Traceability, then set tracking per product: By Unique Serial Number , By Lots or By Quantity . Only products with Track Inventory ticked can be tracked. The Expiration Dates setting adds best-before, removal and alert dates to lots. Removal strategies decide which stock is picked first. Odoo 19 ships First In First Out (FIFO), Last In First Out (LIFO), Closest Location and Least Packages, plus First Expiry First Out (FEFO) with Expiration Dates. Set them on the product category or location. Note that the removal strategy governs which physical units leave; it is not the cost method, which is a separate choice below. For Indian businesses moving goods between GST registrations or to customers without an invoice, the Indian - E-waybill Stock module creates e-way bills directly from transfers. GST setup itself is part 22 . ## How Odoo 19 values inventory Valuation changed noticeably in 19.0. There are two separate settings, both set per company and overridable per product category: - Cost Method : Standard Price, First In First Out (FIFO) or Average Cost (AVCO). The company default is Standard Price. - Valuation : Periodic (at closing) or Perpetual (at invoicing) . The company default is Periodic. With periodic valuation, vendor bills post to expense and stock value is brought onto the balance sheet by a closing entry. The Inventory Valuation report (its menu is Enterprise) has a Generate Entry button for this, and the company's Inventory Period can be Manual, Daily or Monthly to post it automatically. With perpetual valuation, the vendor bill line posts to the stock valuation account and the customer invoice posts cost of goods sold against it; stock moves only create entries when they touch a location with its own valuation account, such as inventory loss or production. In Enterprise the company defaults live in Accounting > Configuration > Settings > Inventory Valuation , with the stock journal and valuation account. On the product category form, the Inventory Valuation group holds the category overrides. A product can also be valued per lot or serial with Valuation by Lot/Serial . ## What to configure first and what can wait - Warehouse names and short codes, one step in and out. - Product categories with cost method, valuation and accounts. - Products with Track Inventory, units of measure, vendor and lead time. - Opening stock through a physical inventory count, dated at go-live. - Reordering rules on Manual; review the Replenishment screen weekly. - Later: storage locations, multi-step routes, lots, barcode scanning. ``` Inventory > Configuration > Settings Inventory > Configuration > Warehouse Management > Warehouses Inventory > Operations > Procurement > Replenishment Inventory > Operations > Adjustments > Physical Inventory Accounting > Review > Inventory > Inventory Valuation ``` Where the pieces live in Odoo 19 (the last menu is Enterprise) Inventory, routes, lots and the valuation engine are all Community; the Barcode app, the valuation settings screen and the valuation report are Enterprise. Next in the series is purchase and vendor management , which is where most replenishment ends up. If you want a second pair of eyes on your location and valuation design, we can review it before you load stock. ## Questions we get asked **Q: Is Odoo 19 Inventory free in Community edition?** Yes. The Inventory app, WMS Accounting (valuation), routes, reordering rules, lots and serial numbers, putaway rules and the e-way bill stock module for India are all LGPL Community modules. The Barcode app, the Enterprise Inventory Valuation report and the accounting settings screen for valuation defaults are Enterprise-only. Community users set cost method and valuation on product categories instead. **Q: What is the difference between periodic and perpetual valuation in Odoo 19?** Periodic (at closing) posts vendor bills to expense and adjusts stock value with a closing entry, generated manually or daily or monthly. Perpetual (at invoicing) posts vendor bills directly to the stock valuation account and books cost of goods sold when the customer invoice is posted. Periodic is the company default in 19.0; both can be overridden per product category. **Q: Should I use 1-step, 2-step or 3-step receipts in Odoo?** Use one step unless your building forces otherwise. Two steps suit a separate receiving dock and storage area; three steps suit goods that must be inspected before storage. Each step adds a document to validate, so extra steps slow the team down if the physical process does not match. You can change the setting on the warehouse later without reinstalling anything. **Q: Can I change the costing method after go-live in Odoo 19?** Yes, on the product category, but Odoo then recomputes the unit cost of every product in that category from its stock history, so the value of stock already on hand changes. Your accountant will need to reconcile that. It is much cleaner to choose between Standard, AVCO and FIFO before the first receipt, and to test any mid-year change on a copy of the database first. --- ## Purchase and vendor management in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-purchase-vendor-management - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Purchase, Procurement, Vendor bills RFQs, vendor pricelists, blanket orders and purchase templates, approvals, bill control policy and 3-way matching in Odoo 19 Purchase. Odoo 19 Purchase is a Community app that takes you from request for quotation to purchase order, receipt and vendor bill, with vendor prices held in Vendor Pricelists and long-term deals in Purchase Agreements (blanket orders and purchase templates). The decision that matters most is the bill Control Policy : bill on received quantities for goods and on ordered quantities for services. Add the Enterprise 3-way matching module only when someone will actually act on its "should be paid" flag. ## From RFQ to purchase order in Odoo 19 Every purchase starts as a request for quotation. The order moves through RFQ , RFQ Sent , optionally To Approve , and Purchase Order ; there is also Cancelled. The main buttons on the form are Send RFQ , Confirm Order and, once confirmed, Send PO and Receive (when Inventory is installed). A confirmed order can be marked as acknowledged by the vendor, and the Receipt Reminder setting emails vendors ahead of the expected date. RFQs come from three places: a buyer creating one by hand, a reordering rule on the Buy route (see part 12 ), or a make-to-order sale. Odoo groups replenishment needs for the same vendor into one draft RFQ, so the buyer's job becomes reviewing and sending rather than typing. Two order settings under Purchase > Configuration > Settings deserve an early decision: - Purchase Order Approval : orders above a Minimum Amount stop at To Approve until a purchase manager approves them. - Lock Confirmed Orders : confirmed orders cannot be edited without unlocking, which keeps what the vendor saw and what you record in step. ## Vendor pricelists: where purchase prices live Purchase prices are not on the product's cost field; they are vendor price lines ( product.supplierinfo ), reachable from the product's Purchase tab or Configuration > Vendor Pricelists . Each line has the vendor, an optional vendor product name and code, a minimum Quantity , Unit Price , Discount (%) , currency, Start Date and End Date , and a Lead Time in days (default 1). When an RFQ line is created, Odoo picks the vendor line that matches the vendor, quantity and date. That lets you hold a quantity break (₹420 above 100 units, ₹450 below) or a dated price increase without anyone editing orders by hand. The Lead Time is also what the scheduler uses to decide when to order, so a wrong lead time produces late or early RFQs. For Indian businesses coming from Tally, vendor masters usually migrate cleanly; purchase price history usually does not exist in a usable form. Load current prices and lead times for your top vendors before go-live and let the rest build up from real orders. ## Purchase agreements: blanket orders and purchase templates Turn on Purchase Agreements in settings to install the purchase_requisition module (Community). Agreements appear under Orders > Purchase Agreements and come in two types: Because a confirmed blanket order writes vendor price lines, RFQs for that vendor pick up the agreed price automatically. Each agreement line shows the quantity already ordered against it, and New Quotation on the agreement starts the next call-off. The same setting offers Purchase Alternatives : link several RFQs for the same need, then use Compare Product Lines on the Alternatives tab to choose per line. When you confirm one, Odoo asks what to do with the others. This is the closest Odoo gets to a formal tender in standard, and for most SMEs it is enough. ## Bill control policy and 3-way matching Each product has a Control Policy : On ordered quantities or On received quantities . Services default to ordered; goods take the default policy, which is received quantities. The policy decides what quantity Odoo proposes when you bill from a purchase order, and so what the order counts as still to bill. > Bill what arrived, not what was promised. For stocked goods, On received quantities is the default for a reason. On a confirmed order, Upload Bill attaches the vendor's PDF and creates the draft bill, and the Bills smart button shows what is already booked. Vendor bill mechanics, GST input credit and payment runs are in part 20 . The setting 3-way matching: purchases, receptions and bills installs Vendor Bill: Release to Pay ( account_3way_match , Enterprise). It adds a Should Be Paid status to each bill: Yes, No or Exception. A bill line goes to Exception if its price differs from the order line, and the received and ordered quantities decide Yes or No according to the control policy. Payables can then filter to bills that are safe to pay. ## A sensible purchase setup order - Vendors with GSTIN, payment terms and currency. - Products with Control Policy set deliberately, not left to the default by accident. - Vendor price lines with lead times for the vendors you buy from weekly. - Approval threshold and order locking in settings. - Reordering rules on Manual, feeding RFQs the buyer reviews. - Later: blanket orders for contract vendors, alternatives for competitive buys, 3-way matching if AP is a separate team. ``` Purchase > Configuration > Settings Purchase > Configuration > Vendor Pricelists Purchase > Orders > Purchase Agreements Purchase > Orders > Requests for Quotation ``` Where the pieces live in Odoo 19 Purchase, Purchase Agreements, alternatives and approvals are all Community; 3-way matching and the Purchase Accounting bridge are Enterprise. Next in the series is manufacturing , where the other half of replenishment happens. If your vendor data is scattered across Tally and spreadsheets, we can help you clean it up before it goes in. ## Questions we get asked **Q: What is a blanket order in Odoo 19?** A blanket order is a Purchase Agreement of type Blanket Order: an agreed price and quantity with one vendor for a validity period. Confirming it requires a price and quantity on every line and creates vendor price lines, so later RFQs for that vendor use the agreed price automatically. It needs the Purchase Agreements setting, which installs the Community purchase_requisition module. **Q: Is 3-way matching available in Odoo Community?** No. The 3-way matching setting installs the Vendor Bill: Release to Pay module (account_3way_match), which is Enterprise-only. It gives each vendor bill a Should Be Paid status of Yes, No or Exception based on ordered, received and billed quantities and on price differences with the purchase order. In Community you can still bill on received quantities through the product's Control Policy. **Q: What does the Control Policy on a product do in Odoo Purchase?** Control Policy sets which quantity Odoo proposes when a vendor bill is created from a purchase order. On ordered quantities bills the full order at once, which suits services and advance payments. On received quantities bills only what has been received in Inventory, which suits stocked goods. Services default to ordered quantities; goods default to received quantities. **Q: Can Odoo 19 require approval for large purchase orders?** Yes. Enable Purchase Order Approval in Purchase settings and set a Minimum Amount in company currency. Orders above that amount move to the To Approve state when a buyer confirms them, and a user with purchase administrator rights must click Approve Order before the order is sent. It is a single threshold per company in standard Odoo. --- ## Manufacturing and MRP in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-manufacturing-mrp - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Manufacturing, MRP, Bill of materials Bills of materials, work centres, operations, manufacturing orders, subcontracting, by-products and MRP scheduling in Odoo 19, plus where PLM fits. Odoo 19 Manufacturing is a Community app built on three records: the bill of materials (what goes in), the work centre (where it is made) and the manufacturing order (one batch being made). Get BoMs and components' lead times right before anything else, add work centres and operations only when you need capacity planning or labour costing, and keep subcontracting, by-products and the Enterprise extras (Shop Floor, Master Production Schedule, PLM) for the second phase. ## Bills of materials: the record everything depends on A BoM lists components and quantities for a quantity of finished product. Its BoM Type is one of: - Manufacture this product : a normal BoM that manufacturing orders consume. - Kit : no manufacturing order; selling or delivering the kit moves its components instead. Useful for bundles and spare-part sets. - Subcontracting : added by the Subcontracting setting, with a list of subcontractors. Two BoM fields are worth setting deliberately. Flexible Consumption decides what happens when the operator consumes more or less than the BoM says: Allowed , Allowed with warning (the default) or Blocked , where only a manager can close the order. Manufacturing Readiness decides whether an MO is ready when all components are available or when those for the first operation are. BoMs can be multi-level: a component can have its own BoM, and Odoo creates child MOs for it when the route is Manufacture. Variants can share one BoM, with lines that apply only to certain attribute values. ## Work centres, operations and work orders Out of the box an MO is a single step: consume components, produce the product. Turning on Work Orders in Manufacturing > Configuration > Settings adds operations to BoMs and work orders to MOs. A work centre is a machine, line or team. The fields that matter: Each BoM operation names a work centre and a duration. Duration Computation is Fixed (you type the minutes) or Computed (Odoo averages the last work orders, ten by default). Start with Fixed times you trust; switch to Computed once operators reliably start and stop their work orders. The Work Order Dependencies setting lets you say which operations must wait for which, so independent ones can run in parallel. Work orders are processed from the MO in Community. The Shop Floor tablet interface and Gantt planning by production and by work centre come with the Enterprise MRP II module ( mrp_workorder ). ## Manufacturing orders and warehouse steps An MO goes through Draft , Confirmed , In Progress , To Close and Done (or Cancelled). Confirming reserves components and triggers replenishment for what is missing. With work orders enabled, Plan schedules them against work centre capacity. Each warehouse also has a Manufacture setting with three options: Manufacture (1 step) , Pick components then manufacture (2 steps) and Pick components, manufacture, then store products (3 steps) . As with receipts and deliveries in part 12 , add steps only when components physically move from a store to the production floor and someone will record that move. Use Unbuild Orders for disassembly or to reverse a wrong production, and scrap from the MO for waste during production, so the consumption is recorded against the right order. ## Subcontracting and by-products Subcontracting (Community) is for products a job worker makes for you, typically from components you supply. Give the product a Subcontracting BoM listing the subcontractor, and buy the finished product from them on a purchase order. When the receipt is validated, Odoo records a subcontracting MO that consumes the components held at the subcontractor's location. Components reach the subcontractor through the Resupply Subcontractor route or a dropship from your vendor. A subcontractor portal (under /my/productions ) lets the job worker open their receipts and record production details such as lots. In India this is the job-work pattern, and the GST paperwork for goods sent out (delivery challans and e-way bills) needs separate attention; part 22 covers the tax side. By-Products , enabled in settings, add secondary outputs to a BoM (A + B gives C + D). Each by-product carries a cost share percentage, so part of the production cost moves to it; the total share cannot exceed 100%. Use them for saleable offcuts and co-products, not for waste you will scrap anyway. ## How MRP scheduling works in Odoo 19 Odoo schedules backwards from the date something is needed. The inputs are: - Manufacturing Lead Time on the BoM: the average days to make the product. In multi-level BoMs the components' lead times add up. - Days to prepare Manufacturing Order on the BoM: create and confirm MOs this many days early to leave time for components. - Vendor lead times on the components' vendor price lines (see part 13 ). - Reordering rules or make-to-order routes that trigger the MO in the first place. Reordering rules plus the Replenishment screen are enough for many make-to-stock workshops. For forecast-driven planning across months, the Enterprise Master Production Schedule lets planners enter demand forecasts per product and period and see the suggested manufacturing and purchase quantities. > Scheduling is only as honest as your lead times. Measure them before you tune the planner. Product Lifecycle Management ( mrp_plm , Enterprise) adds engineering change orders: a proposed BoM or product change goes through stages (New, In Progress, Validated, Effective by default) with approvals, and the new BoM version applies when the change becomes effective. It is worth it when engineering and production are different teams and uncontrolled BoM edits have caused wrong builds. ## A sensible manufacturing rollout order - Components and finished products with units of measure, costs and vendor lead times. - BoMs for the products you make most, tested on real batches. - MOs without work orders; confirm that stock and cost come out right. - Work centres and operations, with Fixed durations and hourly costs. - Reordering rules and lead times for make-to-stock items. - Later: subcontracting, by-products, Shop Floor, MPS, PLM, quality checks. ``` Manufacturing > Configuration > Settings Manufacturing > Products > Bills of Materials Manufacturing > Configuration > Work Centers Manufacturing > Operations > Manufacturing Orders ``` Where the pieces live in Odoo 19 Manufacturing, work orders, subcontracting and by-products are Community; Shop Floor, MPS and PLM are Enterprise. Next is quality and maintenance , which hang off the same work centres. If you are moving BoMs out of spreadsheets or Tally stock journals, we can plan that with you . ## Questions we get asked **Q: Is Odoo 19 Manufacturing available in Community edition?** Yes. The Manufacturing app (mrp) is LGPL Community and includes bills of materials, kits, manufacturing orders, work centres, operations and work orders, unbuild orders, by-products and subcontracting. The Shop Floor tablet view and Gantt planning (MRP II), the Master Production Schedule, PLM engineering change orders and Quality checks on work orders are Enterprise-only modules. **Q: What is the difference between a kit and a manufactured BoM in Odoo?** A BoM of type Manufacture this product is consumed by manufacturing orders: components go in, the finished product comes out and is stocked. A Kit BoM never creates a manufacturing order; when you sell or deliver the kit, Odoo moves its components directly. Use kits for bundles assembled at dispatch and normal BoMs for anything you actually produce and store. **Q: How does subcontracting work in Odoo 19?** Give the product a BoM of type Subcontracting and name the subcontractor. Buy the finished product from that subcontractor with a purchase order. When the receipt is validated, Odoo records a subcontracting manufacturing order that consumes components from the subcontractor's location. You supply components with the Resupply Subcontractor route or by dropshipping from your vendor, and the subcontractor can record lots through the portal. **Q: Do I need work centres to use Odoo Manufacturing?** No. Without the Work Orders setting, a manufacturing order is a single step that consumes components and produces the product, which is enough for simple assembly. Add work centres and operations when you need capacity planning, labour and machine costing, or a record of time spent per step. Operations then appear on BoMs and work orders on each manufacturing order. --- ## Quality control and maintenance in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-quality-maintenance - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Quality, Maintenance, Manufacturing Quality control points, checks and alerts, plus preventive and corrective maintenance on equipment and work centres in Odoo 19. In Odoo 19, Quality is an Enterprise app that attaches control points to receipts, deliveries and manufacturing, creates checks that operators pass or fail, and raises alerts for problems that need a fix. Maintenance is a Community app for equipment records and corrective or preventive maintenance requests. Start with a handful of control points on the operations where defects actually cost you, and with recurring preventive requests on the machines whose breakdown stops production. ## How Odoo 19 Quality is structured The Quality app is the quality_control module (Enterprise), installed from the Quality setting in Inventory or Manufacturing. It has three records: The menus follow the same structure: Quality > Quality Control holds Control Points, Quality Checks and Quality Alerts, and Configuration holds Quality Teams, alert stages and tags. ## Control points and quality checks A control point names the products or product categories, the operation types it applies to (Receipts, Delivery Orders, Manufacturing and so on) and a test type. The standard test types are Instructions , Take a Picture , Pass - Fail , Measure and Spreadsheet ; Worksheet is added by the Quality Worksheet setting. Two fields decide how many checks you get: - Control per : Operation (one check per transfer), Product (one per product, the default) or Quantity (per quantity registered, allowing partial checks). - Control Frequency : All , Randomly (a percentage), Periodically (once per period) or On-demand . Measure tests carry a Norm and Min and Max Tolerance , so a reading outside the range fails automatically. A control point can also name Failure Locations : when a check fails, the operator can send the failed quantity to a quarantine location instead of into stock. On a transfer with pending checks, a Quality Checks button appears, and Odoo will not validate the transfer until the checks are done. That is the point: the check sits in the path of the work instead of on a separate form. With three-step receipts from part 12 , put the control points on the quality control step so goods cannot reach stock without passing. On the shop floor, checks on work orders need the Enterprise MRP II module and appear step by step in the operator's work order. ## Quality alerts and root causes An alert is the follow-up record: a problem tied to a product, lots, a vendor or a transfer, with a responsible person and a quality team. From a failed check the operator can raise one directly. Alerts move through a kanban with four stages by default: New , Confirmed , Action Proposed and Solved . Each alert has a Root Cause (defaults: Workcenter Failure, Parts Quality, Work Operation, Others), a priority, and separate Corrective Action and Preventive Action fields. That split is the useful part. Corrective is what you did about this batch; preventive is what stops the next one. If your team only ever fills in the first, the same alert will come back. > A failed check fixes a batch. An alert with a preventive action fixes the process. For suppliers, the alert list grouped by vendor and root cause is a simple, honest vendor quality review to bring to the next price negotiation from part 13 . ## Maintenance: equipment, teams and requests Maintenance ( maintenance ) is Community. Its records are equipment, equipment categories, maintenance teams and maintenance requests. Equipment carries a category, owner, technician, serial number, warranty expiration date and effective date. The HR bridge module lets you assign equipment to employees or departments, which also makes it a light asset register for laptops and phones. Requests move through New Request , In Progress , Repaired and Scrap by default, and each has a Maintenance Type : - Corrective (the default): something broke and needs fixing. - Preventive : planned work before it breaks. Only preventive requests can be Recurrent , repeating every so many days, weeks, months or years, forever or until an end date. Requests can carry instructions as text, a PDF or a Google Slide link, which is where the checklist from the machine manual belongs. The Maintenance Calendar shows scheduled work, and custom maintenance worksheets are an Enterprise add-on. From corrective requests Odoo computes MTBF (mean time between failures), MTTR (mean time to repair) and an estimated next failure date on each piece of equipment. Those numbers are only meaningful if every breakdown gets a request, including the ones fixed in ten minutes. ## Linking maintenance to manufacturing With Manufacturing, the Maintenance - MRP module (Enterprise, it depends on MRP II) lets a request be for a Work Center as well as a piece of equipment. Ticking Block Workcenter reserves the maintenance slot so work orders cannot be planned on that centre at the same time. ## What to configure first - Maintenance teams and equipment categories; load the equipment that matters to production. - Recurrent preventive requests for critical machines, with instructions attached. - Log every breakdown as a corrective request so MTBF and MTTR mean something. - Quality teams and three to five control points on receipts and final inspection. - Failure locations for quarantine; alerts with root cause and preventive action. - Later: work order checks, spreadsheets and worksheets, work centre blocking. ``` Quality > Quality Control > Control Points Quality > Quality Control > Quality Alerts Maintenance > Maintenance > Maintenance Requests Maintenance > Maintenance > Equipment ``` Where the pieces live in Odoo 19 Maintenance is Community; Quality, maintenance worksheets and the manufacturing link are Enterprise. Next is field service , which takes the same idea of planned work to customers' sites. If you want help deciding which checks are worth enforcing, talk to us . ## Questions we get asked **Q: Is the Odoo 19 Quality app included in Community?** No. Quality (quality_control) and its base module are Enterprise-only in Odoo 19, as are quality checks on work orders and quality worksheets. Community users have the three-step receipt route with a quality control location, but no control points, checks or alerts. The Maintenance app, by contrast, is a Community module and is free to use. **Q: What is the difference between a quality check and a quality alert in Odoo?** A quality check is one test instance, generated automatically from a control point on a transfer or work order, which the operator passes or fails. A quality alert is a problem record raised when something is wrong, often from a failed check. Alerts move through stages and hold the root cause, corrective action and preventive action, so they track the fix rather than the test. **Q: How do I set up preventive maintenance in Odoo 19?** Create a maintenance request for the equipment, set Maintenance Type to Preventive, tick Recurrent and choose how often it repeats in days, weeks, months or years, either forever or until an end date. Add instructions as text, PDF or a Google Slide. With the Enterprise manufacturing link you can raise it on a work center and block that time for production planning. **Q: Can Odoo stop a receipt being validated until quality checks are done?** Yes, with the Enterprise Quality app. When a control point applies to the receipt's operation type and products, Odoo creates checks on the transfer and shows a Quality Checks button. The transfer cannot be validated while checks are still to do. Failed quantities can be moved to a failure location, such as a quarantine bin, defined on the control point. --- ## Field service management in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-field-service - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Field Service, Scheduling, Invoicing How Odoo 19 Field Service handles on-site tasks, scheduling, worksheets, products used on site, timesheets and invoicing, and what to set up first. Odoo 19 Field Service ( industry_fsm , Enterprise) is a layer on Project and Timesheets: each visit is a task with a customer, a planned start and end, a technician and a timer. Worksheets record what was done and get signed on site, products used are added to the task, and Mark as done turns the time and materials into a confirmed sales order ready to invoice. Set up one Field Service project, one service product and one worksheet template before you touch anything else. ## What Odoo 19 Field Service is built on Field Service depends on Project (Enterprise views), Timesheets and geolocation. A Field Service project is an ordinary project with the Field Service box ticked. Installing the app creates one called Field Service, with timesheets enabled and five stages: New , Planned , In Progress , Done and Cancelled . The features you switch on live in two places. Under Field Service > Configuration > Settings there are Time and Material Invoicing and Worksheet Templates . On each Field Service project you then choose which of these it uses, plus options such as Products on Tasks and Extra Quotations . Because it is project-based, anything you already know from Projects applies: stages, tags, activities, customer ratings and the portal. ## Scheduling tasks and planning technicians A field task has a customer, address, planned dates and one or more assignees. The menus are organised around the technician's and the dispatcher's day: - My Tasks , with a list and a Map of the technician's visits. - All Tasks > To Schedule for tasks without planned dates, the dispatcher's inbox. - Planning by user, by project, by location and (with worksheets) by worksheet template, as Gantt views you can drag tasks across. Tasks can come from anywhere a task can: created by hand, from a sales order with a service product set to create a task, from a helpdesk ticket (see part 17 ) or from an incoming email. On site, the technician starts the timer on the task and stops it when done. Those timer entries become timesheet lines on the task, which is what later gets billed. ## Worksheets and the customer report With Worksheet Templates enabled ( industry_fsm_report , which needs Studio), each project or task gets a template: the checklist, readings and notes the technician fills in. Templates are designed in Studio, so they can have exactly the fields your job needs, such as meter readings, model and serial numbers, or a pass/fail checklist. When the work is done, Sign Report opens the report preview for the customer to sign on the technician's phone or tablet; the signature and signer's name are stored on the task. Send Report emails it. A project option can hide prices on the customer report and portal. > The worksheet is the evidence. If it is not filled in on site, the invoice becomes an argument. Keep templates short. A technician in a customer's plant room fills in eight fields; they do not fill in forty. ## Products used on site and stock With Products on Tasks , the task gets a Products button where the technician adds the spares and consumables used from a product catalogue. These lines go onto the task's sales order. When Inventory is installed, the Field Service Stock module (installed automatically) creates and validates the delivery for those products when the task is marked done, so stock is reduced from the right warehouse. If technicians carry van stock, model each van as a location or warehouse (see part 12 ) so the stock figure reflects reality. The Extra Quotations option adds New Quotation to the task, for the common case where the technician finds more work than was booked and needs the customer's approval before doing it. ## From time and material to invoice With Time and Material Invoicing ( industry_fsm_sale ), the project is billable and has a service product for time. Clicking Mark as done on the task: - Offers to stop any running timers and records the timesheets. - Creates a sales order for the task if there is none, with a line for the time spent and lines for the products used. - Confirms that sales order, and with Inventory validates the delivery of the products. - Leaves the task ready for Create Invoice ; the All Tasks > To Invoice menu lists what is waiting. The mistake we see most is technicians marking tasks done from the office at the end of the day. Timers left running overnight inflate the time line, products get remembered rather than recorded, and the customer never signed anything. Mark as done belongs on site, straight after the signature. Tick Under Warranty on a task and its time and materials are not billed to the customer. If you also run Subscriptions for annual maintenance contracts, the Field Service - Sale Subscription bridge installs automatically; subscriptions are covered in part 11 . ## A sensible field service rollout order - One Field Service project with timesheets and the stages you actually use. - A time product with price, SAC code and GST; enable Time and Material Invoicing. - Technicians as users with working schedules; test the Map and Planning views. - One worksheet template for your most common job, signed on site. - Products on tasks, van stock locations, and delivery validation. - Later: extra quotations, warranty handling, helpdesk-to-task, subscriptions. ``` Field Service > Configuration > Settings Field Service > Configuration > Projects Field Service > Configuration > Worksheet Templates Field Service > All Tasks > To Schedule ``` Where the pieces live in Odoo 19 Every Field Service module in this post is Enterprise, as are the Project Gantt and map views it relies on. Next is Helpdesk , which is often where field tasks start. If you want to test the flow end to end on your own jobs, we can set up a pilot with you. ## Questions we get asked **Q: Is Field Service available in Odoo Community?** No. Field Service (industry_fsm) and its worksheet, sale and stock extensions are Enterprise-only modules in Odoo 19. It depends on Enterprise Project views and Timesheets, and worksheet templates also need Studio. Community users can approximate it with ordinary project tasks and timesheets, but without the map, the field planning views, signed worksheets or automatic time-and-material sales orders. **Q: How does Odoo 19 invoice a field service visit?** With Time and Material Invoicing enabled, clicking Mark as done on the task stops running timers, creates or updates a sales order with a line for the time spent and lines for the products used, confirms it and, with Inventory, validates the delivery of those products. The task then shows Create Invoice, and the To Invoice menu lists every task waiting to be billed. **Q: Can customers sign a field service report in Odoo?** Yes. With Worksheet Templates enabled, the Sign Report button opens the report preview so the customer can sign on the technician's device. Odoo stores the signature and the signer's name on the task, and Send Report emails the signed report. The project can be set to hide prices on the customer report and portal if your technicians should not show them. **Q: Do field technicians need a paid Odoo user each?** Each technician who logs in to record timers, worksheets and products needs an internal user, and on Enterprise internal users count towards your subscription. Customers who only view or sign reports do not need an internal user. Check current plans and pricing on odoo.com/pricing before sizing a team, especially if you use subcontracted technicians. --- ## Setting up Helpdesk in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-helpdesk - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Helpdesk, Customer support, SLA Helpdesk teams, channels, SLA policies, automatic assignment, the customer portal, timesheets and billing, and ratings in Odoo 19. Odoo 19 Helpdesk is an Enterprise app organised around teams: each team has its own channels (email alias, website form, live chat), stages, members, SLA policies, assignment rule and portal visibility. Most options are switched on per team, not globally. Start with one team per support queue that has a different promise or a different set of agents, add SLA policies that match what your contracts actually say, and connect timesheets and billing only once agents log time reliably. ## Helpdesk teams and channels A team is the unit of configuration. Open it from Helpdesk > Configuration > Helpdesk Teams and you will find most of the app's features as checkboxes on that one form: channels, SLA policies, timesheets, time billing, ratings, after-sales actions and self-service. Tickets reach a team through: - Email alias , on by default. An incoming email creates a ticket; replies go back into its chatter. - Website Form , which publishes a ticket form on your Odoo website. It requires the team's visibility to include portal users. - Live Chat , where an operator or a chatbot step can turn a conversation into a ticket. - Self-service links to a Community Forum , eLearning courses or Knowledge articles, to deflect questions before they become tickets. Each team also has a Visibility setting: invited internal users only, all internal users, or invited portal users and all internal users. The last is the default and is what makes the customer portal work. ## Stages and SLA policies New teams use five stages: New , In Progress , On Hold , Solved and Cancelled . Stages can carry an email template that goes to the customer when a ticket reaches them; New sends the "Ticket Received" acknowledgement out of the box. With SLA Policies on (the default for new teams), you define policies under Configuration > SLA Policies . Each one applies to tickets of a team that match its conditions and sets a deadline: "Working hours" means the team's Working Hours calendar, so a 9-to-6, six-day Indian office and a 24x7 team get different deadlines from the same number. Tickets show an SLA Deadline and are flagged when a policy fails, and Reporting > SLA Status Analysis shows which tickets met or missed each policy, by team. > An SLA in Odoo should be the one written in your contract. If it is stricter, agents learn to ignore it; if it is looser, you find out from the customer. Use Excluding Stages honestly. Parking a ticket in On Hold to stop the clock while the customer is waiting on you makes the report look good and the customer relationship worse. ## How tickets are assigned With Automatic Assignment on, new tickets go to the team's members according to the Assignment Method : - Each user is assigned an equal number of tickets (the default). - Each user has an equal number of open tickets , which balances by current workload. - Dispatch tickets based on tags , so a tag such as GST or payroll reaches the agents who know it. Assignment takes members' working hours and time off into account, so tickets do not pile up on someone who is on leave. Without automatic assignment, agents pick tickets from the team's queue. For small teams that is often better: the person who knows the customer takes the ticket. ## The customer portal and ratings Customers with portal access see their tickets under /my/tickets , can reply, and follow progress. Turn on Closure by Customers if you want them to close a ticket themselves once they are satisfied. Automatic Closing closes tickets left inactive for a set number of days in chosen stages, which keeps "waiting for customer" tickets from living forever. With Customer Ratings on, Odoo activates the Helpdesk: Ticket Rating Request email template. Set it as the template on your Solved stage and customers are asked to rate the service when a ticket is solved. Results appear in Reporting > Customer Ratings and on the ticket. ## Timesheets, billing and after-sales With Timesheets on, the team is linked to a project and agents log time on each ticket. That is useful even if you never bill it: it tells you what each customer costs to support. Time Billing ( helpdesk_sale_timesheet ) connects tickets to sales order lines. Sell a block of support hours on a sales order, link the ticket to that line, and time logged on the ticket is deducted from the prepaid hours and invoiced according to the service product's policy. The ticket shows the linked sales order and its invoices. Timesheets and billable hours are covered in detail in part 31 . The after-sales options add buttons to the ticket for Refunds , Coupons , Gift Cards , Returns , Replacements , Repairs and Field Service . The last creates a field service task from the ticket, which is how on-site visits from part 16 usually start. ## A sensible helpdesk rollout order - One team, its email alias and members; stages left at the default five. - Working hours on the team; SLA policies copied from your contracts. - Portal visibility, the website form, and Closure by Customers if you want it. - Customer ratings on the Solved stage; review them monthly. - Timesheets on tickets, then Time Billing for prepaid support hours. - Later: automatic assignment, tag dispatch, after-sales actions, field service. ``` Helpdesk > Configuration > Helpdesk Teams Helpdesk > Configuration > SLA Policies Helpdesk > Reporting > SLA Status Analysis Helpdesk > Reporting > Customer Ratings ``` Where the pieces live in Odoo 19 Helpdesk and every extension in this post are Enterprise. This closes the operations part of the series; next we turn to finance, starting with accounting setup and the chart of accounts . If you are moving support off a separate ticketing tool, talk to us about bringing the history across. ## Questions we get asked **Q: Is Odoo Helpdesk available in Community edition?** No. Helpdesk is an Enterprise-only app in Odoo 19, and so are its extensions for timesheets, time billing, the website form and after-sales actions. Community users sometimes run support on Project tasks with an email alias and the portal, but that gives no SLA policies, no automatic assignment by workload or tags, and no SLA status reporting. **Q: How do SLA policies work in Odoo 19 Helpdesk?** An SLA policy belongs to a team and applies to tickets with a given priority, and optionally given tags or customers. It sets a target stage and a number of working hours, counted on the team's working-hours calendar from ticket creation. Time spent in excluded stages, such as On Hold, does not count. Tickets show an SLA deadline and are flagged when the policy fails. **Q: Can Odoo Helpdesk bill customers for support time?** Yes, with the Time Billing option. Sell support hours on a sales order using a timesheet-based service product, then link tickets to that sales order line. Time agents log on the ticket is counted against the hours sold and invoiced according to the product's invoicing policy. The ticket shows the linked sales order and its invoices, and remaining prepaid hours. **Q: How does automatic ticket assignment work in Odoo 19?** Turn on Automatic Assignment on the team and choose a method: an equal number of tickets per member, an equal number of open tickets per member, or dispatch based on tags. Odoo assigns new tickets only to members who are available according to their working hours and time off. Without it, tickets stay unassigned in the team queue for agents to pick. --- ## Setting up accounting in Odoo 19: localisation, chart of accounts and journals - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-accounting-setup-chart-of-accounts - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Accounting, Chart of accounts, India localisation How to set up Odoo 19 accounting in the right order: fiscal localisation, chart of accounts, journals, fiscal years, lock dates and opening balances. Set up Odoo 19 accounting in this order: confirm the company country so the right fiscal localisation loads, trim the chart of accounts it creates, add your bank journals, set the fiscal year and lock dates, and only then load opening balances. For an Indian company the l10n_in package gives you a 102-account chart, GST taxes and fiscal positions out of the box. Most of the rework we see comes from posting entries before these foundations were settled. ## Community Invoicing versus Enterprise Accounting The Community edition's accounting app is called Invoicing (module account ). It is a real double-entry ledger: chart of accounts, taxes, journals, invoices, bills, payments and journal entries. What it does not have is the working layer that finance teams live in day to day. Enterprise adds that layer in two steps. account_accountant (still labelled Invoicing) installs automatically in Enterprise and brings the bank reconciliation screen, lock dates, fiscal years and deferred revenue and expense entries. It pulls in account_reports (the P&L, balance sheet, aged reports and tax report) and account_followup . The Accounting app itself (module accountant ) sits on top and adds assets, budgets and the full accountant menus. If an external CA keeps your books in their own software and you only need to invoice and track payments, Community can work. If your team closes the month in Odoo, you need Enterprise. Pricing is on odoo.com/pricing . ## Choosing the fiscal localisation package Odoo picks the localisation from the company's country. For India, l10n_in (Indian - Accounting) installs automatically with the accounting app. The package it loads is shown under Settings, in the Fiscal Localization block, as the Package. For India it creates: - A single chart template with 102 accounts and six-digit codes. Receivables go to Debtors (10040) by default. - GST taxes as groups: "18% GST S" is SGST 9% plus CGST 9%, and "18% IGST S" is the inter-state version. Rates go up to 40%, and there are export, SEZ and LUT variants, reverse-charge taxes, and TDS and TCS taxes. - Fiscal positions: Within your state, Inter State, SEZ, Export and the two LUT positions. The first two apply automatically based on the customer's state. - A fiscal year ending 31 March, per-line tax rounding and the invoice total printed in words. ## Shaping the chart of accounts Start from the localisation chart and adapt it. Don't rebuild it from a blank sheet or copy it line for line from Tally. The template's accounts are already wired to the taxes, the default receivable and payable, the exchange-difference accounts and the tax reports. Replacing them means rewiring all of that by hand. What we usually do: - Map the old ledger list to Odoo accounts in a spreadsheet first. Many Tally ledgers are really partners (one ledger per customer) and should become contacts, not accounts. - Add accounts only where management reporting needs them, such as separate revenue accounts per business line. For finer cuts, use analytic accounts, not more GL accounts. - Check the account type on every new account. It decides where the account lands on the balance sheet or P&L, and whether it can be reconciled. - Archive what you won't use rather than deleting it. The chart lives at Configuration › Accounting › Chart of Accounts. Taxes and fiscal positions sit in the same menu. ## Journals: what Odoo creates and what to add The chart template creates Sales (INV), Purchases (BILL), Miscellaneous Operations (MISC), Exchange Difference (EXCH), Cash Basis Taxes (CABA) and a Bank journal. Add one bank journal per real bank account, each with its account number, so statements and reconciliation stay separate. Add another sales journal only when you need separate numbering, for example a different invoice series per GST registration or for exports. A journal per salesperson or per product line creates work without adding information; use analytic accounts or sales teams for that. If you run several sets of books on one company, the Multi-Ledger menu groups journals for reporting. ## Fiscal years and lock dates The fiscal year end is a company setting, and for India the default is 31 March. If you have a short first year or an irregular period, Enterprise has a Fiscal Years option in Settings to define periods longer or shorter than twelve months. Lock dates stop anyone posting into a closed period. In Enterprise, Accounting › Closing › Lock Dates… opens a wizard with separate dates: - Lock Sales and Lock Purchases close invoices or bills on their own. - Lock Tax Return protects periods whose GST return has been filed. - Lock Everything closes all journals up to that date. - Hard Lock is permanent and cannot be moved back. Use it only once the auditors have signed off. > Set the tax lock date the day the GST return is filed, not at year end. Most restated returns we see come from a late edit to an invoice in an already-filed month. ## Loading opening balances The accounting onboarding has a Review Chart of Accounts step. It opens the chart with Opening Debit and Opening Credit columns, and Odoo writes those figures into a single opening journal entry. If debits and credits don't match, Odoo adds an "Automatic Balancing Line" to the undistributed profits account. Treat a non-zero balancing line as a mistake to find, not a plug to accept. - Pick the cut-over date, ideally the first day of a fiscal year or a quarter, and take the trial balance from the old system on that date. - Load balance-sheet accounts (bank, fixed assets, GST input and output, loans, equity) through the opening balance columns. - Load customer and vendor balances as individual open invoices and bills, not as one lump on Debtors. Then payments can be matched and aged reports work from day one. - Check the Odoo trial balance against the old one, then post the opening entry and set a lock date on the day before cut-over. Next in the series: invoicing and customer payments in Odoo 19 . If you are planning a Tally-to-Odoo cut-over and want a second pair of eyes on the account mapping, get in touch . ## Questions we get asked **Q: Is Odoo 19 Community enough for accounting?** Odoo 19 Community includes the Invoicing app: chart of accounts, taxes, journals, invoices, bills and payments, plus the Indian GST localisation. It does not include the bank reconciliation screen, financial reports such as the P&L and balance sheet, payment follow-ups, lock-date management or assets. Those come with Enterprise. Community suits companies whose books are kept elsewhere by an accountant. **Q: Which chart of accounts does Odoo 19 use for India?** Odoo 19 uses the Indian - Accounting localisation ( l10n_in ), which installs automatically for companies in India. It loads a single chart template of 102 accounts with six-digit codes, plus GST taxes (CGST, SGST, IGST, cess), TDS and TCS taxes, and fiscal positions for intra-state, inter-state, SEZ and export supplies. The fiscal year is set to end on 31 March. **Q: Can I change the chart of accounts after I start posting in Odoo?** You can add, rename and archive accounts at any time. Switching to a different localisation package after entries exist is not realistic, and the Reload button on the settings page warns that reloading accounting data is irreversible. Settle the country, company state, GSTIN and package before posting the first entry, and adapt the chart from there. **Q: How do I import opening balances into Odoo 19?** Use the Review Chart of Accounts step of the accounting onboarding, which shows Opening Debit and Opening Credit columns for each account and creates one opening journal entry. Load customer and vendor balances as individual open invoices and bills so they can be matched to payments later. If the entry doesn't balance, Odoo adds an automatic balancing line, and that line should be investigated. --- ## Invoicing and customer payments in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-invoicing-customer-payments - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Invoicing, Accounts receivable, E-invoicing, GST Invoices, payment terms, online payment links, follow-ups, credit notes and Indian e-invoicing (IRN) in Odoo 19, and what is Community or Enterprise. In Odoo 19 a customer invoice moves from draft to posted when you click Confirm. It goes out through the Send dialog and is paid once a payment is registered and matched to the bank. Payment terms, online payment through providers such as Razorpay or Stripe, credit notes and Indian e-invoicing (IRN) are all in Community. Automated payment follow-ups are Enterprise. ## How an invoice moves through Odoo 19 Invoices come from a sales order, a subscription, a timesheet or directly from Customers › Invoices. Whatever the source, the lifecycle is the same: - Draft. Editable, no accounting impact, no invoice number yet. - Confirm. The invoice is posted, gets its number from the journal sequence, and the receivable and GST lines hit the ledger. - Send. One dialog emails the PDF, attaches any e-invoice file and, for Indian B2B invoices, submits to the Invoice Registration Portal. - Pay. Registering a payment moves the invoice to "In Payment". It becomes "Paid" only when that payment is matched to a bank statement line, or straight away if the payment method has no outstanding account. The difference between "In Payment" and "Paid" matters. "In Payment" means someone said the money arrived. "Paid" means the bank agrees. Collections staff should work from the second. ## Payment terms that match your contracts Odoo 19 installs ten payment terms, from Immediate Payment to "30% Now, Balance 60 Days" and "2/7 Net 30". You manage them under Configuration › Invoicing › Payment Terms. Each term is made of lines: a percentage or fixed amount, due a number of days after the invoice date, after the end of the month, or on a given day of the following month. Terms can also carry an early payment discount (the Early Discount option, with a percentage and a number of days). You choose whether the tax is reduced only on early payment, never, or always on the invoice. For GST-registered businesses, agree the treatment with your CA before switching it on. It changes what the tax lines say. Set a default term on each customer, not per invoice. Sales orders and invoices pick it up from there, and the aged receivables report reflects what you actually agreed. ## Getting paid online: providers, links and QR codes In Settings › Customer Payments, the option to let customers pay invoices online installs account_payment (Community). Customers can then pay from the invoice in their portal. Providers are set up under Configuration › Online Payments › Payment Providers. For India, the Razorpay provider enables card, netbanking and UPI payments by default. Stripe, PayPal, Adyen and others are also in the 19.0 source. A payment confirmed through a provider is registered against the invoice automatically, so it needs no manual entry. - Payment links. The "Generate a Payment Link" action on an invoice produces a URL you can send over WhatsApp or email when a customer won't log into a portal. - QR code. The same setting can add a QR code on the PDF that links to the online payment page. - Batch payments for grouping deposits (such as a day's cheques) are an Enterprise option. ## Payment follow-ups (Enterprise) Follow-ups come from account_followup , which is Enterprise-only. You define Follow-up Levels under Configuration › Invoicing: each level fires a number of days after the due date (it can be negative, to remind before the due date). Each level can send an email with the invoices attached, send an SMS, and schedule an activity for the follow-up responsible, the salesperson or the account manager. A level can run automatically or wait for someone to trigger it. Odoo creates two levels to start with, at 15 and 30 days. Each customer is set to automatic or manual reminders, and the customer list has "Overdue Invoices" and "Requires Follow-up" filters to work from. Our default: keep the first reminder automatic and polite, and make the second one an activity for a person to call. Put key accounts, where a relationship manager should decide the tone, on manual. ## Credit notes and debit notes On a posted invoice, the Credit Note button opens the reversal dialog. You give a reason, a journal and a date, then either Reverse (a credit note that offsets the invoice) or Reverse and Create Invoice (credit the original and open a corrected draft). The second option is the clean way to fix a wrong price or tax after posting. Debit notes, for charging more on an existing invoice, come from account_debit_note . The Indian localisation depends on it, so it is always there for Indian companies. Both documents keep a link to the original invoice. GST reporting needs that link, and it makes the customer's statement readable. ## E-invoicing in Odoo 19, including India's IRN Indian e-invoicing is in l10n_in_edi (Indian - E-invoicing, LGPL, so it works in Community too). Turn on E-Invoicing in the Indian Integration block of Settings, save, then enter the API username and password you created on the e-invoice portal and click "Verify Username and Password". Odoo connects through a GSP partner and uses IAP credits. From then on, the Send dialog offers an "E-invoicing" option on eligible invoices. It sends the JSON to the Invoice Registration Portal and stores the response, including the IRN, on the invoice. Eligibility follows the GST section of the lines: B2B, exports, SEZ, deemed exports and the matching credit and debit notes. B2C invoices are not sent. Cancellations take one of the portal's reasons (Duplicate, Data Entry Mistake, Order Cancelled, Others) plus remarks. If you also use e-way bills, l10n_in_ewaybill_irn generates the e-way bill from the IRN. Outside India, account_edi_ubl_cii exports and imports UBL and Factur-X invoices, and account_peppol sends them over Peppol where that network is used. Both are Community. ``` Settings › Invoicing › Indian Integration [x] E-Invoicing → save, then set credentials Username / Password → Verify Username and Password Invoice › Send [x] E-invoicing → IRN stored on the invoice ``` Where Indian e-invoicing is switched on and used in Odoo 19. Get payment terms and follow-up levels right before go-live. Everything else can be tuned once real invoices are flowing. Next: vendor bills and accounts payable , and for the GST side in depth, GST compliance in Odoo 19 . ## Questions we get asked **Q: Does Odoo 19 support e-invoicing (IRN) in India?** Yes. The Indian - E-invoicing module ( l10n_in_edi ) is LGPL, so it works in Community and Enterprise. After you enable E-Invoicing in Settings and verify your e-invoice portal API credentials, the invoice Send dialog submits eligible B2B, export, SEZ and deemed-export invoices to the Invoice Registration Portal and stores the IRN on the invoice. It uses Odoo IAP credits for each transaction. **Q: Can customers pay Odoo invoices by UPI?** Yes, through a payment provider. Enable online invoice payment in Settings, then configure a provider such as Razorpay under Configuration › Online Payments › Payment Providers. In the 19.0 source, Razorpay enables card, netbanking and UPI by default. Customers pay from the invoice portal or from a payment link, and the payment is registered against the invoice automatically. **Q: Are payment follow-ups available in Odoo Community?** No. Automated follow-ups come from the account_followup module, which is Enterprise-only. It adds Follow-up Levels that trigger a number of days after the due date and can send emails with invoices attached, send SMS and schedule activities. In Community you can still filter overdue invoices and send reminders by hand, but there is no scheduled follow-up engine. **Q: Why does an Odoo invoice show "In Payment" instead of "Paid"?** "In Payment" means a payment has been registered but not yet matched to a bank statement line. The payment sits on an outstanding receipts account until reconciliation confirms the money reached the bank. Once it is matched in bank reconciliation, the invoice changes to "Paid". Payment methods configured without an outstanding account mark invoices paid straight away. --- ## Vendor bills and accounts payable in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-vendor-bills-accounts-payable - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Vendor bills, Accounts payable, TDS, Purchase Capturing, checking and paying vendor bills in Odoo 19: digitisation, purchase bill control, 3-way matching, payment controls and Indian TDS. In Odoo 19, vendor bills reach the system by email, upload or from a purchase order. They are checked against what was ordered or received, then paid in grouped payments that are later matched to the bank. The core flow, purchase bill control and Indian TDS are all Community. AI bill digitisation, 3-way "release to pay" matching and batch payment files are Enterprise. ## Getting bills into Odoo 19 There are three ways in, and most companies use all three: - From the purchase order. The Create Bills button on a confirmed PO drafts the bill with the PO lines, prices and taxes already filled in. This is the cleanest route for anything that went through Purchase. - By email. Every purchase journal can have an email alias. Vendors or your own staff forward PDFs to it, and each email becomes a draft bill with the attachment. This is Community. - By upload and digitisation. Upload PDFs from the bills list. With Document Digitization switched on (Settings › Digitization, Enterprise, charged in IAP credits), Odoo reads the vendor, dates, amounts and lines. The account_invoice_extract_purchase module then tries to find the matching purchase order. Two helpers make this faster. "Predict vendor bill product" (Enterprise) guesses the product from the line label. The Auto-validate bills setting lets Odoo offer to post imported bills from a vendor automatically once they have been right three times in a row. Each vendor then has an Auto-post bills choice: Always, "Ask after 3 validations without edits", or Never. For Indian companies there is also "Fetch Vendor E-Invoiced Document" in the Indian Integration settings (Enterprise, l10n_in_reports ). It creates draft bills from the e-invoice data your vendors submitted on the GST portal. For e-invoiced vendors that is more reliable than reading their PDF. ## Bill control from purchase orders How much a PO lets you bill is set per product by its Control Policy in the Purchase tab: On ordered quantities or On received quantities . For stocked goods, bill on received quantities. Odoo then won't propose billing more than the warehouse has validated. For services and subscriptions, ordered quantities is usually right. Enterprise adds account_3way_match (Vendor Bill: Release to Pay), switched on with the 3-way matching setting in Purchase. Each bill gets a "Should Be Paid" status: The bills list gets matching filters: Bills to Validate, Bills to Pay and Bills in Exception. That makes a good weekly working list for whoever runs payables. ## Approving bills: what Odoo 19 has and what it doesn't Odoo 19 has no dedicated multi-level approval workflow for vendor bills, so don't promise one to your finance controller. What it does have covers most real needs: - Separation through access rights. Give buyers rights to create draft bills, and only accountants rights to post them. - Purchase Order Approval in Purchase settings, which requires a manager to approve orders above a minimum amount. If spending is approved at PO stage, a bill that matches the PO needs no second approval. - Reviewed flag on journal entries, which a senior accountant can use to mark bills as checked. - (Un)Block Payment , an action that puts a bill in the "Blocked" payment state so it can't be paid until someone releases it. - Duplicate warnings when a bill reuses a reference already recorded for the same vendor. If you genuinely need amount-based, multi-step bill approval, it is a small automation or Studio job. We would build it only after the basics above have been tried. ## Paying vendors safely Select bills in the list and click Pay. The payment dialog can group bills per vendor into one payment and creates one payment per vendor. As with customer payments, a vendor payment stays "In Process" until it is matched to the bank statement line. Each vendor bank account has a "Send Money" toggle that shows it as Untrusted or Trusted. It starts as Untrusted, only authorised users can change it, and changes are tracked in the chatter, because changed bank details in a fake invoice are a common fraud. Verify new account numbers by phone before you mark one as trusted. Payment output options depend on your country and edition: - Checks ( account_check_printing , Community) for printed cheques where a country layout exists. - Batch payments (Enterprise) to group payments into one bank transaction for easier reconciliation. - ENet Vendor Batch Payment for India (Enterprise, l10n_in_reports ), which generates a vendor payment file to upload to your bank. The 19.0 source ships an HDFC template. ## TDS on vendor bills in India TDS lives in the Community localisation. Enable TDS in Settings › Indian Integration and enter your TAN. The localisation preloads 34 TDS sections (192 to 195) and 13 TCS sections. You link a section to each expense account through the account's "TCS/TDS Section" field, for example contractor charges to 194C. - Record each vendor's PAN and its TDS Deduction type: Normal, Lower, Higher or No. - Set the TDS journal and account under India TDS Control in the default accounts settings. - When a bill line posts to an account with a section, Odoo checks that section's per-transaction and aggregate thresholds by PAN and warns that TDS is advisable. - On the posted bill (or on the payment, if you deduct at payment), click TDS Entry . The withholding wizard creates the TDS entry, and a TDS button on the bill shows the total withheld. The TDS and TCS report definitions come with the localisation. Viewing and exporting them needs Enterprise's reporting engine. The quarterly return is still filed outside Odoo. A payables process that works is mostly about who can post and who can pay. Settle that before configuring anything clever. Next: bank reconciliation in Odoo 19 . If you want help setting this up, see our Odoo implementation service . ## Questions we get asked **Q: Can Odoo 19 read vendor bills from PDF automatically?** Yes, in Enterprise. The Document Digitization setting installs Odoo's extraction service, which reads vendor, dates, totals and lines from uploaded or emailed PDFs and uses IAP credits. A related module links the bill to the matching purchase order. In Community, emailed PDFs still become draft bills through the purchase journal's alias, but you type the details in yourself. **Q: How do I deduct TDS on a vendor bill in Odoo 19?** Enable TDS and enter your TAN in the Indian Integration settings, then assign a TDS section such as 194C or 194J to the relevant expense accounts. Set the vendor's PAN and TDS Deduction type. After posting the bill, click TDS Entry to open the withholding wizard, which creates the TDS journal entry. All of this is in the Community localisation. **Q: What is 3-way matching in Odoo?** 3-way matching compares the purchase order, the goods received and the vendor bill before payment. In Odoo 19 it comes from the Enterprise module Vendor Bill: Release to Pay, enabled in Purchase settings. Each bill gets a Should Be Paid status of Yes, No or Exception, based on whether billed quantities have been received. Filters on the bills list show which bills are ready to pay. **Q: Does Odoo 19 have approval workflows for vendor bills?** Not as a dedicated feature. Odoo 19 offers purchase order approval above a set amount, access rights that separate drafting from posting, a Reviewed flag on entries, and an action to block a bill's payment until it is released. Amount-based multi-level bill approval can be added with automation rules or Studio if a company really needs it. --- ## Bank reconciliation in Odoo 19: feeds, matching and rules - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-bank-reconciliation - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Bank reconciliation, Accounting, Bank feeds How bank reconciliation works in Odoo 19: statement import and bank sync, automatic matching, reconciliation models and the rules Odoo learns. Bank reconciliation in Odoo 19 is an Enterprise feature. Statement lines arrive through online bank synchronisation or a file import. Odoo matches them to open invoices, bills and payments automatically, and reconciliation models deal with the recurring rest, such as bank charges. Odoo 19 also creates simple rules on its own when you code the same kind of transaction to the same account more than once. ## What Community and Enterprise give you The Community Invoicing app has bank journals, payments and the underlying reconciliation engine, but no bank reconciliation screen and no statement import. The reconciliation screen, the auto-matching scheduled action and the Reconcile menu (Accounting › Closing) all come from account_accountant . It installs automatically in every Enterprise database, even one that only uses Invoicing. If your team matches its bank in Odoo every week, you need Enterprise. There is no sensible Community workaround at any real volume. ## Getting bank transactions in: sync or import Each bank journal has a Bank Feeds field. In a standard Enterprise database it takes one of three values: Online synchronisation starts from Connect bank on the bank journal's dashboard card and then refreshes on a schedule. Coverage depends on the institution and the country, and the bank's consent expires and has to be renewed. Check your own bank in the connection dialog before you plan around it. Don't assume it works. For file imports, CSV is the universal fallback. Build one import mapping per bank format and save it, so the monthly import takes seconds. Enterprise can also digitise statements from PDF scans ( account_bank_statement_extract ), which helps with the odd bank that only sends PDFs. ## How Odoo 19 matches transactions automatically After every import or sync, and daily through a scheduled action, Odoo tries to reconcile the new statement lines on its own. The logic in the 19.0 source works roughly in this order: - Partner mapping. If a reconciliation model maps a label pattern to a partner, that partner is set on the line first. - Reference match. Odoo looks for open invoices, bills and payments whose reference appears in the transaction. This is why customers should pay with the invoice number as the payment reference. - Amount match. Without a reference, it looks for a single open item for that partner with the same amount. It also accepts the early-payment discounted amount within the discount period, or a small difference. - Tie-break. If several invoices qualify, it takes the latest one dated on or before the transaction. Everything else waits in the reconciliation screen, which you open from the bank journal's "to reconcile" button on the dashboard. Each line can be matched to journal items, given a partner (Set Partner) or posted to an account (Set Account). Any reconciliation model buttons that apply are one click away. Payments registered earlier sit on the outstanding receipts or payments account with the status "In Process". Matching the bank line clears that account and moves the invoice from "In Payment" to "Paid". ## Reconciliation models: the rules you write Reconciliation models are under the bank journal's dashboard menu (Reconciliation › Models). In Odoo 19 a model has: - Trigger : Manual (shown as a button or proposal) or Automated (applied without anyone clicking). - Conditions : which journals, an amount range (lower than, greater than, between), a label test (Contains, Not Contains, Match Regex) and specific partners. - Counterpart lines : the account, a fixed amount, a percentage of the balance or of the statement line, or an amount read from the label with a regex. Each line can carry taxes and analytic distribution. - An optional Next Activity , useful when a posted line still needs a document from someone. Every chart of accounts comes with two models: Internal Transfers, and Bank Fees (label contains "Bank Fees"). Rename the Bank Fees label test to whatever your bank actually prints. In India that is often an NEFT, IMPS or SMS charge description, and GST on bank charges belongs on the counterpart line as a tax. A model with a label condition and one line that has a partner but no account works as partner mapping . It only sets the partner, and invoice matching then does the rest. This is the tidy way to deal with payment gateways and UPI collections, which arrive with cryptic labels. ## Rules Odoo 19 creates by itself In the 19.0 code, when you use Set Account on a line and several recent lines in the same journal went to the same account, Odoo looks for the text their labels have in common. If it finds some, it creates a reconciliation model automatically, with a Match Regex condition and that account. It then offers the rule on other open lines that fit. It also cleans up after itself. If a rule Odoo created proposes an account and you choose a different one, that rule is deleted. Review the automatically created models monthly anyway. A pattern that is too broad (a common word such as "PAYMENT") can post the wrong things quietly if someone switches it to Automated. > Aim for the reconciliation screen to hold only real exceptions. If you code the same line by hand every month, it should be a model. ## A weekly routine that keeps the bank clean - Import or sync all bank journals on the same day each week, not just at month end. - Clear the automatic matches first, then the model proposals, then the exceptions. - Keep the Bank Suspense account at zero by month end. Anything left there is unexplained money. - Check that outstanding receipts and payments only hold items from the last few days. Next in the series: GST compliance in Odoo 19 . If you want your bank formats and rules set up properly the first time, talk to us . ## Questions we get asked **Q: Is bank reconciliation available in Odoo 19 Community?** No. Odoo 19 Community has bank journals and payments but no bank reconciliation screen, statement import or bank synchronisation. Those come from the Enterprise module account_accountant and its statement import and online synchronisation add-ons. That module installs automatically in Enterprise databases, including those that only use the Invoicing app. **Q: Can Odoo 19 connect directly to Indian bank accounts?** Odoo 19 Enterprise offers online bank synchronisation through Odoo's aggregator service, but coverage depends on the institution and country. Check your bank in the Connect bank dialog before relying on it. Where no connection exists, download statements in CSV, OFX or CAMT format and import them into the bank journal, which works with practically any bank. **Q: What is a reconciliation model in Odoo?** A reconciliation model is a rule that tells Odoo how to handle bank statement lines that match certain conditions: journal, amount range, label text or partner. It either proposes or automatically posts counterpart lines to set accounts, with taxes and analytics, or it simply sets the partner on the line. Typical uses are bank charges, internal transfers and payment gateway settlements. **Q: Does Odoo 19 learn reconciliation rules automatically?** Yes. When you post a statement line to an account and several recent lines in the same journal went to that account, Odoo 19 Enterprise finds text their labels share and creates a reconciliation model with a regex condition for it. If you later pick a different account on a line that rule proposed, Odoo deletes the rule. --- ## GST compliance in Odoo 19: taxes, HSN, e-invoice, e-way bill and GSTR - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-gst-india-compliance - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, GST, India localisation, E-way bill, GSTR What Odoo 19 does for Indian GST: taxes, place of supply, HSN/SAC, e-invoice, e-way bill, TDS/TCS and GSTR filing, and which parts need Enterprise. Odoo 19 handles Indian GST mostly in Community. The l10n_in , l10n_in_edi and l10n_in_ewaybill modules give you CGST, SGST and IGST taxes, automatic intra- or inter-state selection from the place of supply, HSN/SAC codes, IRN e-invoicing, e-way bills and TDS/TCS. The GSTR-1, GSTR-2B and GSTR-3B workflow, including pushing GSTR-1 to the GST portal and matching GSTR-2B against your bills, is Enterprise ( l10n_in_reports ). ## Community or Enterprise, feature by feature The online services (e-invoice, e-way bill, GSTIN status check and GST portal calls) go through Odoo's IAP service and use credits. Buy them from the same settings page. ## GST taxes and fiscal positions: how Odoo 19 picks CGST+SGST or IGST The Indian chart loads GST taxes as groups. "18% GST S" on a sale is SGST 9% plus CGST 9%, and "18% IGST S" is the inter-state equivalent. There are versions for each rate from 1% to 40%, plus export, SEZ and LUT variants, reverse-charge taxes (flagged Reverse charge) and cess. You put the intra-state tax on products, and fiscal positions switch it when needed. The chart creates these: - Within and Inter State , both applied automatically. - Special Economic Zone (SEZ) and Export for supplies with payment of IGST. - SEZ - LUT (WOP) and Export - LUT (WOP) for supplies under a Letter of Undertaking. - Reverse charge Intra State and Reverse charge Inter State , which add the reverse-charge note to the document. On a sales invoice Odoo sets the Place of supply from the delivery address's state (a foreign address becomes "Foreign Country") and compares it with your company's state to choose the fiscal position. The invoice also carries the GST Treatment , copied from the customer: Registered Business - Regular, Composition, Unregistered, Consumer, Overseas, Special Economic Zone, Deemed Export or UIN Holders. SEZ treatment picks the SEZ position. A fiscal position set by hand on the customer overrides all of this. Enter GSTINs on contacts. Odoo validates the format and can fill the state from the first two digits. With "Check GST Number Status" enabled, it can verify a GSTIN's status online and show it on the invoice. ## HSN and SAC codes Each product has an HSN/SAC Code field, copied to invoice lines and editable there. The HSN/SAC Validation setting sets how many digits you must give. Odoo offers 4 digits (turnover under ₹5 crore), 6 digits (over ₹5 crore) and 8 digits, and defaults to 4. Choose the level that matches your aggregate turnover, then clean the product master before go-live. A wrong HSN on an invoice flows straight into the e-invoice JSON and GSTR-1. ## E-invoice and e-way bill With E-Invoicing enabled and your portal API credentials verified, the invoice Send dialog submits eligible documents to the Invoice Registration Portal and stores the IRN. Eligible means B2B, exports, SEZ, deemed exports and their credit and debit notes. B2C invoices are not sent. E-way bills are in l10n_in_ewaybill . It is not installed automatically, because service companies don't need it. Switch it on under E-Way bill in the same settings block. An e-way bill records the document type, the transport mode (By Road, Rail, Air or Ship), the distance, the vehicle number or transport document, and the transporter. You can generate it from an invoice. l10n_in_ewaybill_stock adds it on deliveries without an invoice, for example stock transfers. When e-invoicing is also active, l10n_in_ewaybill_irn generates the e-way bill through the IRN. ``` Settings › Invoicing › Indian Integration Registered Under GST [x] GST Number: 33XXXXXXXXXXXZX E-Invoicing [x] → credentials → Verify E-Way bill [x] GST E-Filing & Matching Feature [x] (Enterprise) HSN/SAC Validation 4 Digits (turnover < 5 CR.) ``` The Indian Integration block in Odoo 19 settings, in the order we configure it. ## TDS and TCS TDS and TCS are separate switches in the same block. TDS needs your TAN. The localisation preloads 34 TDS sections (192 to 195) and 13 TCS sections under 206C. Each section has per-transaction and aggregate thresholds, and Odoo checks them against the partner's PAN and warns when deduction or collection is advisable. On a posted bill, invoice or payment, the TDS Entry button creates the withholding entry. When a customer's PAN is missing or invalid, an Apply Higher TCS button appears. The details are covered in vendor bills and accounts payable . ## GSTR-1, GSTR-2B and GSTR-3B (Enterprise) Enabling "GST E-Filing & Matching Feature" installs l10n_in_reports . Returns then appear under Accounting › Closing › Tax Returns as periodic records with a status. Anything that talks to the portal needs your GST username and an OTP first. - GSTR-1. Review the report and the document summary, then Push Data sends it to GSTN. Odoo checks the status and flags invoices the portal rejected. An XLSX export is also available. The final filing is done on the GST portal, and you then mark the return as filed in Odoo. - GSTR-2B. Each month Odoo fetches your GSTR-2B from the portal and matches it against posted vendor bills (Match, Partially Matched), so you can see input tax that vendors haven't reported, or bills you haven't booked. - GSTR-3B. A GSTR-3B version of the tax report, computed from your books to prepare the summary return. The 19.0 source has no push to the portal for 3B, so you file it on the portal. Before trusting any return, lock the period with the tax return lock date so nothing moves after you file. GST in Odoo 19 is mostly good master data: states, GST treatments, GSTINs and HSN codes. Get those right and the taxes follow. Next: financial reports, assets and closing . For a GST setup review, see our implementation service or contact us . ## Questions we get asked **Q: Is Odoo 19 GST compliant for Indian businesses?** Odoo 19 includes an Indian localisation covering GST taxes (CGST, SGST, IGST, cess), place of supply, HSN/SAC codes, e-invoicing with IRN, e-way bills and TDS/TCS, all in the Community modules. The GSTR-1, GSTR-2B and GSTR-3B return workflow is in the Enterprise module l10n_in_reports . Compliance still depends on correct contact, product and tax data, and on your CA reviewing returns. **Q: Can Odoo 19 file GSTR-1 directly?** Odoo 19 Enterprise can push GSTR-1 data to the GST portal from the Tax Returns menu after you log in with your GST username and an OTP. It then checks the status and flags invoices with errors. The final filing is completed on the GST portal, after which you mark the return as filed in Odoo. Odoo can also export GSTR-1 as XLSX. **Q: How does Odoo decide between IGST and CGST plus SGST?** Odoo compares the invoice's place of supply, taken from the delivery address's state, with the company's state. If they match, the automatic "Within your state" fiscal position keeps CGST plus SGST. If they differ, the Inter State position swaps in IGST. SEZ and overseas customers get their own positions, and a fiscal position set on the customer overrides the automatic choice. **Q: Does Odoo 19 generate e-way bills?** Yes. The Indian - E-waybill module ( l10n_in_ewaybill , Community) submits e-way bills to the government portal from invoices, recording transport mode, distance, vehicle and transporter. A stock add-on creates them from deliveries without an invoice, and when e-invoicing is enabled, another module generates the e-way bill through the IRN. It is not installed by default and uses IAP credits. --- ## Financial reports, assets and month-end closing in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-financial-reports-assets-closing - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Financial reports, Fixed assets, Month-end close, Accounting Odoo 19's P&L, balance sheet, aged and tax reports, fixed asset depreciation, deferred revenue and expenses, and a month-end closing sequence that works. Odoo 19's financial reports (P&L, balance sheet, cash flow, general ledger, trial balance, aged receivables and payables, and the tax report) come from the Enterprise module account_reports . Fixed assets need the Enterprise Accounting app. A reliable month-end in Odoo 19 follows a fixed order: bank, receivables and payables, deferrals and depreciation, currency revaluation, tax return, then lock dates. No year-end closing entry is needed, because the balance sheet works out current-year earnings itself. ## The reports Odoo 19 gives you All of these are live reports. You can unfold any line down to journal items, compare periods and export to PDF or XLSX. They sit under Reporting: For Indian companies, the Enterprise Indian reports module ( l10n_in_reports ) adds an India-specific Profit and Loss variant and GSTR-1, GSTR-2B and GSTR-3B. Community has Invoice Analysis but none of the statutory statements. That is usually the deciding point for a company whose auditors expect the books to come out of Odoo. ## Fixed assets and depreciation Assets come from account_asset , which depends on the Enterprise Accounting app, not on Invoicing alone. Assets live under Accounting › Assets & Liabilities, and Asset Models under Configuration › Accounting. Each asset or model sets: - Method : Straight Line, Declining (with a declining factor), or Declining then Straight Line. - Duration and period : a number of periods of one month or one year. - Prorata : No Prorata, Constant Periods, or Based on days per period, for assets bought mid-period. - Accounts : the fixed asset, accumulated depreciation and depreciation expense accounts, and the journal. The quickest setup is to link an asset model to each fixed asset account. On that account's Automation tab, Automate Asset can be set to Create in draft or Create and validate, so a vendor bill posted to that account creates the asset for you. Once an asset is confirmed, its depreciation entries are scheduled and post on their dates. Modify, Pause, Resume, Sell and Dispose handle the changes, and Sell and Dispose post the gain or loss. For India, l10n_in_asset installs automatically with assets. It changes the Declining method so the salvage value is respected, which is how written-down-value depreciation with a residual value is usually computed in India. Income-tax block-of-assets depreciation is a separate calculation. Keep that one in your tax working papers, not in the books. ## Deferred revenue and deferred expenses You don't need a separate module for deferrals. In Enterprise, an invoice or bill line gets Start Date and End Date fields. Fill them on a yearly AMC invoice or a prepaid insurance bill, and Odoo spreads the amount over the period. Settings has a Deferred expense entries block and a Deferred revenue entries block. Each sets the journal, the deferral account, when entries are generated (On bill validation, or Manually & Grouped) and how the amount is spread (Days, Months or Full Months). The Indian chart already has deferred revenue and deferred expense accounts. Our default: generate on validation for companies with few deferrals. Use Manually & Grouped when there are hundreds, so month-end posts one grouped entry per account, not one per invoice. Either way, the Deferred Revenues and Deferred Expenses reports under Review › Regularization Entries show what is still to be recognised. ## A month-end closing sequence for Odoo 19 The order matters more than speed. Each step relies on the one before: - Bank. Import or sync every bank journal to the last day and reconcile. Bank Suspense should be empty. - Receivables and payables. All sales invoices and vendor bills for the month posted, and outstanding receipts and payments cleared. - Inventory and payroll. Stock valuation and payroll entries posted, if those apps are in use. - Deferrals and depreciation. Generate grouped deferral entries and check that the month's depreciation entries have posted. - Accruals. Post accruals for goods received but not billed, and expenses incurred but not invoiced. - Currency revaluation. For foreign-currency balances, run the Currencies report under Review › Regularization Entries and post the adjustment. - Tax return. Under Accounting › Closing › Tax Returns, take the return through Review and Submit, then set the tax return lock date. - Review and lock. Check the trial balance, P&L and balance sheet, then set Lock Everything for the month in Lock Dates…. A return that still has failing checks can't be submitted. The same menu also holds an Audit return type for year-end work, with 33 ready-made audit checks such as empty suspense accounts, bank statements and clearing of internal transfer accounts. Go through them once with your auditor and drop the ones that don't apply. > A month is closed when it is locked, not when the report has been sent. ## Year-end in Odoo 19 At year end there is no closing entry to post. The balance sheet shows Current Year Unallocated Earnings and Previous Years Unallocated Earnings, computed from the P&L accounts, and the P&L starts from zero in the new fiscal year. What remains is judgement: provisions, the auditors' adjustments, allocating the result to reserves with a journal entry if your company does that, and finally a Hard Lock once the accounts are signed. Build the checklist once, give each step an owner, and run it the same way every month. Next in the series: employees and HR records in Odoo 19 . If your close takes longer than it should, we can look at it with you . ## Questions we get asked **Q: Does Odoo 19 Community have a balance sheet and P&L report?** No. The Balance Sheet, Profit and Loss, Cash Flow Statement, General Ledger, Trial Balance, aged reports and tax report all come from account_reports , an Enterprise module. Community includes Invoice Analysis and the underlying journal items, so you can export data to a spreadsheet, but it has no statutory financial statements that can be drilled into. **Q: How does Odoo 19 calculate depreciation?** Odoo 19 Enterprise's Assets app supports Straight Line, Declining and Declining then Straight Line methods over monthly or yearly periods. Prorata can be off, based on constant periods, or based on days. Confirmed assets schedule depreciation entries that post on their dates. For Indian companies, the l10n_in_asset module adjusts declining depreciation so the salvage value is respected. **Q: Do I need to post a year-end closing entry in Odoo?** No. Odoo computes the year's result on the balance sheet as Current Year Unallocated Earnings and carries earlier years as Previous Years Unallocated Earnings. Income and expense accounts start the new fiscal year at zero automatically. You only post entries for real decisions, such as moving the result into reserves, then lock the year with the lock dates wizard. **Q: How are deferred revenue and prepaid expenses handled in Odoo 19?** In Odoo 19 Enterprise you enter a Start Date and End Date on the invoice or bill line, and Odoo spreads the amount over that period using the deferral accounts in Settings. Entries can be generated when the document is validated, or manually in a grouped entry at month end. Deferred Revenues and Deferred Expenses reports show the balance still to be recognised. --- ## Employee records, departments and contracts in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-employees-hr-records - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Employees, HR, Org chart How Odoo 19 Employees stores people, departments and dated contract versions, who can see private data, and what to set up before payroll. In Odoo 19 the Employees app keeps each person as an hr.employee record whose job, department, schedule, private details and contract terms live in dated versions ( hr.version ). The separate Contracts app of earlier releases is gone: a salary change or promotion is now a new version with an effective date on the employee itself. Set up departments, working schedules and access groups first, then load employees with their current version, and only then switch on payroll. ## What changed in Odoo 19: versions replace contracts If you have used Odoo 16, 17 or 18, you will remember hr_contract , a module with its own contract records, stages and a Contracts menu. That module does not exist in 19.0. Its fields have moved into hr.version , which the employee inherits directly. Contract start and end date, end of trial period, wage, contract type, the salary structure type (labelled Pay Category on the form) and working hours all sit on the version. So does a lot more than the old contract ever held. Department, job position, job title, work address and work location, private address, marital status, dependent children and identification numbers are also versioned. The practical effect is a real history: when someone moves from Coimbatore to the Chennai office on 1 April, you create a new version dated 1 April instead of overwriting the old address and losing it. On the employee form the versions appear as a timeline in the header. The + button (tooltip "New Employee Record") asks for an effective date and copies the current values into a new version. The History smart button lists every version. A scheduled action updates each employee's current version as dates pass, so a version dated next month becomes current on its own. ## The employee form, tab by tab The form is organised into these tabs: - Work : department, job position, manager and coach, work address and work location, with an organisation chart panel on the right. - Resume : resume lines and skills, filled in once the Skills Management module is installed. We cover that in part 29. - Personal : private contact, emergency contact, visa and work permit, family and education. HR officers only. - Payroll : the contract overview (start and end date, wage, employee type, contract type, pay category) and working schedule. HR administrators only. - Settings : the linked user, time zone, HR responsible, and the PIN and badge barcode used by Attendance and Point of Sale. The Employee Type field has six values out of the box: Employee, Worker, Student, Trainee, Contractor and Freelancer. Decide early which of these you will use. Payroll structures and reports often filter on it, and contractors paid through vendor bills should not end up in a pay run. Under Payroll there is a Load a Template link. Contract templates, maintained under Configuration > Recruitment > Contract Templates , are versions without an employee. Building three or four of them (say, full-time staff, trainee, fixed-term) saves typing the same schedule, contract type and pay category for every new joiner. ## Departments, managers and the org chart Departments are a tree: each has a parent department, a manager and a colour. The employee's Manager field is what builds the reporting line, and it drives approvals in other apps (time off, expenses, appraisals). The Coach field follows the manager automatically unless you set it to someone else. Unlike department and job, Manager and Coach sit on the employee itself and are not versioned. The HR Org Chart module (Community) adds two things: the small chart on each employee's Work tab, and a hierarchy view on the Directory and on Departments where you can see the whole structure. Department hierarchy supports drag and drop; the employee chart is read-only and reflects the Manager field. Our advice is to model departments the way approvals actually flow, not the way the organisation chart on the office wall looks. If a plant head approves leave for three production departments, make sure every employee's Manager field says so. A tidy department tree with wrong managers produces wrong approval routing. ## Who can see private information Odoo 19 has two access levels on Employees beyond ordinary users: Ordinary users never read hr.employee directly; the Directory is built on a restricted public model. Record rules also stop non-officers from seeing employees' bank accounts. That is a sensible default, but check who you give the Officer group to. In many Indian SMEs the office manager who books travel ends up with it, and with it every employee's Aadhaar and PAN. Employees who have a user can maintain some of their own details, such as private address, private phone, emergency contact and bank account, from their user preferences. That is worth enabling in the onboarding message rather than having HR retype everything. ## Onboarding and offboarding plans Under Configuration > Employee > Onboarding / Offboarding Odoo ships two activity plans, Onboarding and Offboarding, each a list of activities with an assignee. For employee plans the assignee can be the employee, their manager or their coach, as well as a fixed user. The Launch Plan button on the employee form creates all the activities at once, with due dates. Plans can be tied to a department, so the factory can have a different onboarding list from the sales office. Keep the plans short. Ten activities that actually get done are better than thirty that sit overdue. When someone leaves, the departure wizard records a departure reason (Fired, Resigned and Retired are provided), the date, and optionally sets the contract end date and archives the linked user. Archive rather than delete: payroll, timesheets and accounting entries still point at the employee. ## A sensible setup order - Company details and the default working schedule in Settings > Employees . Add other schedules (six-day week, shifts) under Configuration > Employee > Working Schedules . - Work locations and the department tree with managers. - Job positions and two or three contract templates. - Access groups: decide who is Officer and who is Administrator before anyone imports data. - Import employees with one current version each: department, job, manager, schedule, contract start date. Add older versions only if you need the history for payroll or reports. - Create users only for employees who will log in. Odoo warns that new users may increase your subscription cost, and on Enterprise it does. - Set the expiry notice periods (defaults are 7 days for contracts and 60 days for work permits) and review the onboarding plans. ``` Employees > Configuration > Employee > Working Schedules Employees > Configuration > Recruitment > Contract Templates Employees > Configuration > Employee > Onboarding / Offboarding Settings > Employees > Contract Expiration Notice Period ``` Where the pieces live in Odoo 19 Employees is a Community app, and so is everything in this post. Payroll, appraisals and some reporting are Enterprise; we mark those as we go. Next in the series is recruitment and onboarding . If you are moving employee data out of Tally, spreadsheets or an older Odoo with hr_contract , we can plan the migration with you. ## Questions we get asked **Q: Does Odoo 19 still have a Contracts app?** No. The hr_contract module was removed in Odoo 19. Contract fields such as start and end date, wage, contract type and salary structure type now live on employee versions ( hr.version ). A new contract, raise or transfer is recorded by creating a new version with an effective date from the timeline on the employee form, and older versions stay in the History list. **Q: Is the Odoo 19 Employees app free in Community?** Yes. Employees ( hr ), HR Org Chart, departments, versions, contract templates and onboarding plans are all LGPL Community modules. Payroll and Appraisals are Enterprise-only. Community is free to use; if you run Enterprise, each user you create for an employee counts towards your subscription, so check odoo.com/pricing before creating users for everyone. **Q: Who can see employee salaries in Odoo 19?** Wage, contract dates, contract type and pay category are restricted to the Employees Administrator group. The Officer group sees private details such as address, identification numbers and bank accounts but not the Payroll tab. Ordinary internal users see only the Directory, which shows work contact details, department and reporting line from a restricted public model. **Q: How do I record a salary change or promotion in Odoo 19?** Open the employee, click the plus button on the version timeline in the header, and pick the date the change takes effect. Odoo copies the current version; change the wage, job or department on the new one. The old version stays in History, and the new one becomes current automatically on its effective date. --- ## Recruitment and onboarding in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-recruitment-onboarding - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Recruitment, Onboarding, HR Setting up Odoo 19 Recruitment: job positions, the applicant pipeline, interview forms, offers and handing a hire over to onboarding. Odoo 19 Recruitment is a Community app that runs hiring as a kanban pipeline of applicants per job position, from the first email or website application to a signed contract. Interview forms, SMS, and website job posting are optional add-ons; offer letters with e-signature and CV scanning need Enterprise. The step most teams skip is the hand-off: an applicant becomes an employee with one button, and that is where an onboarding plan should start. ## Job positions and how applications arrive Everything hangs off the job position ( Recruitment > Configuration > Job Positions ). Each position carries a department, a recruiter, a list of interviewers, a target number of new employees, a job summary, and an email alias. Any email sent to that alias creates an applicant for that position with the CV attached. Applications come in by four routes: - The job alias , for example careers-accountant@yourcompany.com , which is what most Indian SMEs start with because Naukri, LinkedIn and referral emails can simply be forwarded. - Your website , once Online Posting is ticked in settings. That installs the Online Jobs module ( website_hr_recruitment ), which publishes positions and an application form. - Job boards . Under Configuration > Job Boards > Emails , Odoo lists the sender addresses of LinkedIn, Jobsdb and Indeed so that notifications from them are not mistaken for the applicant's own email. You can add the addresses your own boards send from, with a pattern to pull the candidate's name from the subject. - Manual entry or import , which is fine for walk-ins and campus drives. Each position also has its own Applicant Properties , custom fields that exist only on applicants for that job. Use them for the two or three facts that decide a shortlist, such as notice period or a required licence, rather than adding fields to every applicant in the company. ## The applicant pipeline and stages A fresh database has six stages: New, Qualification, First Interview, Second Interview, Contract Proposal and Contract Signed. Contract Signed is flagged as the Hired Stage , which is what sets the hire date and counts the applicant as hired in reports. Stages can be shared by all jobs or limited to specific ones. Two stage settings do real work: - Email Template . When an applicant enters the stage, Odoo posts that template to them. The New stage ships with an acknowledgement email already attached; check its wording before you go live, because it will reach every applicant. - Hired Stage . Only tick it on the last stage. If a stage that already holds applicants loses the flag, Odoo warns you, because it changes their status. Every applicant has an evaluation (stars), a kanban state (In Progress, Ready for Next Stage, Waiting, Blocked), tags, expected and proposed salary, and an availability date. Interviews are calendar meetings created from the applicant, so interviewers see them in their own calendar with the applicant linked. ## Refusals, duplicates and talent pools Refuse opens a wizard with a reason and an optional email. Six reasons are provided, including "Does not fit the job requirements", "Job already fulfilled", "Duplicate" and two "Refused by applicant" reasons (job fit and salary), which is useful later when you ask why offers are being turned down. The wizard can also refuse duplicate applications from the same email or phone in one go. Good candidates you cannot hire now can be added to a talent pool ( Applications > By Talent Pools ) and pulled into a future job with Create Applications . That keeps their history instead of creating a stranger's record when they reapply. ## Interview forms, access and offers Recruitment has three access levels: Interviewer , Officer: Manage all applicants and Administrator . Interviewers only see applicants for jobs where they are listed as interviewers, or applicants they have been added to individually, which is usually what department heads need. Salary fields are hidden from interviewers. Tick Send Interview Survey in settings to install interview forms ( hr_recruitment_survey , Community, built on the Survey app). Each job position then gets an Interview Form , and the applicant gets Send Interview to email it to the candidate. We use it for structured pre-screening questions; interviewers' own notes are better kept in the applicant's chatter or notes. Offers are where the editions split: The Salary Configurator adds Generate Offer to the applicant. An offer is tied to a contract template and a Sign template, and is valid for 30 days by default. The only country pack for it in 19.0 is Belgian, so Indian companies will need to set up their own benefits and CTC breakdown before it is useful; for many, a signed PDF through Sign is enough. ## From hire to onboarding Once the applicant is in the hired stage, Create Employee (visible to users with the Employees Officer right) builds the employee record with name, contact details, job position and department carried over, and links the two so the application history stays reachable. Then the employee side takes over (see part 24 ): load a contract template for the first version and launch the onboarding plan. - Before hiring starts, edit the Onboarding plan under Employees > Configuration > Employee > Onboarding / Offboarding . Assign each activity to the manager, the coach, the employee, or a named person in IT or admin. - Create department-specific plans where the work genuinely differs, for example a plant induction with safety training. - On hire, click Create Employee , set the contract start date, and apply the contract template. - Click Launch Plan . The activities land in each assignee's to-do list with due dates. - Create a user only if the new joiner will log in, and collect PAN, bank and UAN details for payroll before the first pay run. Activity plans also work on applicants themselves ( Recruitment > Configuration > Activities > Activity Plans ), which is handy for pre-joining checks such as reference calls and background verification. ``` Recruitment > Configuration > Settings > Online Posting Recruitment > Configuration > Settings > Send Interview Survey Recruitment > Configuration > Stages Recruitment > Configuration > Activities > Activity Plans ``` The settings worth visiting first Start with one job position, the default stages and the email alias; add the website, interview forms and signatures once the team is actually using the pipeline. Next in the series: time off and attendance . If you want help shaping the process, get in touch . ## Questions we get asked **Q: Is Odoo 19 Recruitment free in Community edition?** Yes. The Recruitment app, website job posting (Online Jobs), interview forms and talent pools are all Community modules under LGPL. The Enterprise-only pieces are the Salary Configurator for online offers, Recruitment - Signature for e-signing documents, CV scanning (Résumé Digitization) and the employee referral programme. Community is free; Enterprise pricing is on odoo.com/pricing. **Q: Can Odoo import applicants from Naukri or LinkedIn?** Not through a built-in Naukri connector. The practical route is the job position's email alias: forward or route job board notifications to it and Odoo creates an applicant with the attachment. Job board sender addresses can be listed under Configuration, Job Boards, Emails so Odoo does not treat the board's own address as the candidate's email. **Q: How do I send an offer letter from Odoo 19 Recruitment?** In Community, record the proposed salary on the applicant and email the letter as an attachment from the chatter. With Enterprise, Recruitment - Signature sends documents for e-signature, and the Salary Configurator adds a Generate Offer button that emails the candidate a link to review and sign a contract based on a template. Offer links are valid for 30 days by default. **Q: What happens when an applicant is hired in Odoo 19?** Moving the applicant into the hired stage, Contract Signed by default, sets the hire date and marks them as hired. Clicking Create Employee then builds an employee record with contact details, job and department copied across and linked to the application. From the employee form you apply a contract template and launch the onboarding activity plan. --- ## Time off, accruals and attendance in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-time-off-attendance - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Time Off, Attendance, Overtime, HR How to set up Odoo 19 Time Off and Attendances: leave types, accrual plans, approvals, holidays, kiosk check-in and the new overtime rulesets. In Odoo 19, Time Off and Attendances are both Community apps. Time Off handles leave types, allocations, accrual plans, approvals and public holidays; Attendances records check-ins from a kiosk, the web or mobile, and calculates extra hours using the new overtime rulesets. Configure your working schedules and leave types first, write each leave policy as an accrual plan, and only then open the kiosk: attendance and overtime are measured against the schedule. ## Time off types and approvals A time off type ( Time Off > Configuration > Time Off Types ) holds most of the policy. The settings that matter: - Requires allocation . If ticked, employees can only take what has been allocated to them. Paid Time Off works this way out of the box; Sick Time Off and Unpaid do not. - Time Off Validation , with four choices: None needed, By Time Off Officer, By Employee's Approver, or By Employee's Approver and Time Off Officer. The default Paid Time Off type uses the two-step option. - Duration Type : Day, Half-Day or Hours. Choose hours for permission-style short leave. - Kind of Time Off : Absence or Worked Time. Worked time is for things like training or on-duty that should not count as absence. - Is Unpaid , Supporting Document (to ask for a medical certificate), and Allow Negative Cap with a maximum excess, for companies that let people go into a small minus. The approver comes from the employee's Time Off Approver field, which follows the manager's user automatically. Check it after importing employees; an empty approver means requests with manager validation have nobody to go to. Beyond ordinary employees, who request for themselves, Time Off has three access levels: Time Off Responsible, Officer: Manage all requests, and Administrator. Give the Officer level to HR, not to every line manager; managers approve through the approver field. ## India: sandwich leave and optional holidays For companies whose country is India, the India - Time Off module installs itself with Time Off (Community). It adds two options on the leave type: - Sandwich Leaves . When a request surrounds a weekend or holiday, those days are counted in the leave. Friday plus Monday becomes four days, not two, if that is your policy. - Limited to Optional Holidays . Employees can only pick dates from the list under Configuration > Optional Holidays . This is how you model restricted holidays, where staff choose two from a published list of festivals. Decide on sandwich leave per type, not globally. It usually applies to casual or earned leave and almost never to sick leave. ## Accrual plans An accrual plan ( Configuration > Accrual Plans ) earns leave over time instead of granting it all on 1 January or 1 April. A plan has one or more milestones. Each milestone says how much to add (in days or hours), how often (hourly, daily, weekly, twice a month, monthly, twice a year or yearly), from when it starts (at allocation creation or after a number of days, months or years), and an optional cap. Plan-level settings decide what happens at year end. Carry-Over Time can be the start of the year, the allocation date or a custom date, which is what Indian companies on an April to March leave year need. Unused time is either lost or carried over, with or without an upper limit. Accrual can also be based on worked time, so unpaid leave does not earn leave. - Write the policy in one sentence per rule: "1.5 days per month, max 45 carried forward, first credit after probation". - Build one milestone for each change in rate. A second milestone after five years handles long-service entitlement. - Set the carry-over date and limit, then attach the plan to the time off type. - Create accrual allocations for employees, with the start date set to their joining date, and check a few balances by hand before telling staff. ## Public holidays and mandatory days Configuration > Public Holidays holds company-wide closures. Each holiday can be limited to a working schedule, which is how a company with a Tamil Nadu factory and a Bengaluru office keeps different state holidays apart. Leave durations skip these days unless the time off type is configured to include public holidays in the duration. Mandatory Days are the opposite: days when time off cannot be requested, such as year-end closing or inventory count. They can be limited to departments or job positions. ## Attendances: kiosk, web and check-in modes Attendances ( hr_attendance , Community) needs little configuration, but the choices under Attendances > Configuration > Settings set how people will use it: The kiosk runs in a browser from a private URL shown in settings (with Generate new URL to revoke an old one). A cheap tablet at reception with the employee badge printed from the employee form is usually enough. Hardware biometric devices are not part of standard Odoo; those need a connector module. ## Overtime rulesets in Odoo 19 Overtime used to be little more than company tolerance thresholds, which are still in settings (Tolerance Time In Favor Of Company and Of Employee). In 19 the rules themselves are Overtime Rulesets ( Configuration > Overtime Rulesets ), each assigned on the employee's version. The Default Ruleset contains two rules: the Employee Schedule Rule, which counts hours beyond the working schedule, and the Non Working Days Rule, which counts any hours on a non-working day. Both are marked as paid. Rules are based on either quantity (hours above a daily or weekly amount) or timing (working days, non-working days, when the employee is off, or outside a specific schedule). Each has a rate, and employer and employee tolerances so a few minutes do not count. When several rules apply, the ruleset either takes the maximum rate or sums the extra percentages. Extra Hours Validation is either automatic or approved by the manager. With the HR Attendance Holidays bridge installed (it installs itself when both apps are present), approved extra hours can be converted into time off, and a time off type can deduct from extra hours. That covers compensatory off without spreadsheets. Paying overtime is a payroll matter; we cover that in Indian payroll in Odoo 19 . For help mapping your leave policy and shift rules, talk to us . ## Questions we get asked **Q: Does Odoo 19 support sandwich leave for India?** Yes. The India - Time Off module, which installs automatically with Time Off for Indian companies, adds a Sandwich Leaves option to each time off type. When enabled, weekends and holidays that fall inside a leave request are counted in its duration. It is a Community module, and you can switch it on for casual leave while leaving sick leave unaffected. **Q: How do accrual plans work in Odoo 19 Time Off?** An accrual plan adds leave to an allocation at a set frequency, from hourly to yearly, through one or more milestones that can change the rate after a period of service. Each milestone can have a cap. The plan decides the carry-over date, such as 1 April, and whether unused leave is lost, carried over in full, or carried over up to a limit. **Q: Can employees check in from their phone in Odoo 19?** Yes. With Attendances from Backend enabled, employees check in and out from the Odoo systray in the browser or the mobile app. Device and Location Tracking, on by default, stores GPS position, IP address and device details with each check-in. A shared kiosk on a tablet, using badges or PINs, is the alternative for sites where staff do not have Odoo users. **Q: How is overtime calculated in Odoo 19 Attendances?** Through overtime rulesets assigned on each employee's version. The default ruleset counts hours beyond the working schedule and any hours worked on non-working days. Custom rules can be based on quantity per day or week, or on timing, with rates and tolerances. Extra hours can be auto-approved or approved by a manager, then converted to time off or paid through payroll. --- ## Running Indian payroll in Odoo 19: PF, ESI, PT and TDS - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-payroll-india - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Payroll, India, PF, TDS What Odoo 19's Indian Payroll localisation covers: salary structures, PF, ESI, PT, LWF and TDS rules, pay runs, statutory reports and accounting. Odoo 19 Payroll is an Enterprise app, and its Indian Payroll localisation ( l10n_in_hr_payroll ) installs automatically for Indian companies. It ships four salary structures with rules for Basic, HRA, allowances, PF, ESI, Professional Tax, Labour Welfare Fund, gratuity and a monthly TDS deduction, plus EPF, ESI and salary register reports. It is a solid base for a standard CTC payroll, but tax slabs, PT states and TDS need checking before your first pay run: several values are shipped as fixed defaults and some statutory work still happens outside Odoo. ## How Odoo 19 payroll is put together Payroll sits on top of the employee records from part 24 . In Odoo 19 there is no separate contract model: wage, pay category (the salary structure type) and all Indian salary components live on the employee's version . The chain is: - Structure type on the employee's version (for example India: Employee Pay ), which sets the default structure and working schedule. - Work entries , generated from the schedule, approved time off and, if you use it, attendance. They decide paid and unpaid days. - Structure , a set of salary rules evaluated in sequence ( Payroll > Configuration > Salary > Structures ). - Rule parameters , dated values the rules read, such as the PF wage ceiling ( Configuration > Salary > Rule Parameters ). - Payslips , grouped into Pay Runs , which are confirmed and posted to accounting. One-off additions and recurring deductions, such as a loan recovery or salary advance, go in Salary Adjustments rather than being typed onto each payslip. ## What the Indian localisation ships The module creates four structure types, each with a default structure: Most companies should start from India: Regular Pay . Its 28 rules follow the usual CTC split, and the amounts come from fields on the employee's Payroll tab: basic salary as a percentage or amount, HRA, standard allowance, bonus, LTA and so on, with the fixed allowance absorbing the balance. Settings under Payroll > Configuration > Settings hold the company's EPF Employer ID, ESIC IP number, PT number and LWF number, and switch each scheme on or off. ## PF, ESI, PT and LWF: what the rules actually do - Provident Fund. Employee and employer PF are computed on basic at 12% (the l10n_in_pf_percent parameter). Per employee you choose either "Restrict contribution to ₹15,000 of PF Wage" or a percentage of actual PF wages. The EPS share (8.33%) is also a parameter. - ESI. Employee and employer ESIC percentages are set on each employee and applied to gross. The ₹21,000 gross ceiling exists as a parameter and is checked by the Non-Executive structure; in Regular Pay, eligibility is controlled by whether you fill the percentages, so clear them when someone crosses the ceiling. - Professional Tax. Each employee gets a Professional Tax slab . Slabs are shipped for Gujarat, Maharashtra (with separate male and female slabs), Karnataka, West Bengal and Andhra Pradesh. Other states, including Tamil Nadu, need their own rule parameter before PT will compute. - Labour Welfare Fund. Fixed employee and employer amounts on the employee, with a Labour Welfare Fund report. ## TDS on salary: what is and is not covered This is where expectations most need setting. The TDS rule deducts the fixed monthly amount entered in the employee's TDS Deduction field. The localisation includes a TDS computation that projects annual income and applies the slab chart, standard deduction, Section 87A rebate, surcharge and 4% health and education cess to propose a monthly figure, but it models the new regime only. What we did not find in the 19.0 source: an old-versus-new regime choice per employee, investment declarations and proof collection (80C, 80D, HRA exemption), automatic re-computation of TDS as the year progresses, Form 16 generation, or a Form 24Q return file. Plan for those to stay with your tax consultant or a specialised tool, and update the monthly TDS figure on each employee when their projection changes. ## Pay runs, payslips and reports A monthly cycle in Odoo 19 looks like this: - Resolve work entry conflicts for the month. Unpaid leave work entries are what reduce pay in the Regular Pay structure, so make sure approved leave is in before you generate payslips. - Create a pay run under Payroll > Payslips > Pay Runs and click Generate Payslips for the employees in scope. - Review payslips, add inputs where needed, and recompute. Compare totals with last month's register before going further. - With Payroll Accounting installed, Create Draft Entry produces the journal entry in draft for finance to check and post. - Use Payment Report to produce the bank payment file. For India the default format is a Payment Advice, exported as Excel, which you can adapt to your bank's bulk salary upload. - Mark as Paid once the bank has processed it. Under Payroll > Reporting > India you get the EPF Report, ESI Report, Salary Register, Salary Statement Report, Yearly Salary by Employee and the Labour Welfare Fund Report. The EPF and ESI reports are Excel exports of the month's contribution data, not the portal upload files themselves, so the ECR and ESIC returns still need a formatting step. ## Accounting: where payroll posts Payroll Accounting ( hr_payroll_account , Enterprise) adds a Salary Journal on each structure and debit and credit accounts on each salary rule. The India - Payroll with Accounting module installs automatically and maps the Regular Pay structure to accounts in the Indian chart of accounts: salary expense, HRA, allowance and bonus expenses, PF employee and employer payables, Professional Tax payable and salary payable. Check the mapping before your first pay run. In the source we read, ESI, TDS, gratuity, LWF and medical insurance rules are not given accounts by default, and the Worker and Non-Executive structures are not mapped either. Rules without accounts do not post, which leaves statutory liabilities missing from the balance sheet. Set Batch Account Move Lines in settings if you want one summarised entry per period instead of per-employee lines; it anonymises the entry but prevents individual payments. ``` Payroll > Configuration > Settings EPF, ESIC, PT, LWF numbers Payroll > Configuration > Salary > Rule Parameters PF ceiling, PT slabs, tax chart Payroll > Configuration > Salary > Structures account mapping per rule Payroll > Payslips > Pay Runs monthly cycle ``` The four screens to review before go-live Our rule for moving payroll from Tally, Excel or a payroll bureau: run at least two months in parallel and reconcile net pay, PF, ESI, PT and TDS to the rupee before switching. Expenses can also be reimbursed through payslips, which we cover next in expenses and reimbursements . If you want help setting up structures and parameters, talk to us . ## Questions we get asked **Q: Does Odoo 19 support Indian payroll?** Yes, in Enterprise. The Indian Payroll module installs automatically with Payroll for Indian companies and provides salary structures and rules for Basic, HRA, allowances, Provident Fund, ESI, Professional Tax, Labour Welfare Fund, gratuity and a monthly TDS deduction. It includes EPF, ESI, salary register and yearly salary reports, and an Excel payment advice for bank uploads. Payroll is not available in Community. **Q: Does Odoo 19 calculate TDS on salary automatically?** Partly. The payslip deducts a fixed monthly TDS amount stored on the employee. The localisation includes a new-regime computation with standard deduction, 87A rebate, surcharge and cess to propose that amount, but there is no old regime option, no investment declaration workflow, and no Form 16 or 24Q output. The shipped tax parameters should be updated for the current financial year. **Q: Which states' Professional Tax does Odoo 19 include?** The Indian localisation ships Professional Tax slabs for Gujarat, Maharashtra (separate male and female slabs), Karnataka, West Bengal and Andhra Pradesh, selected per employee. Other states, such as Tamil Nadu, Telangana or Kerala, are not shipped. You can add them as rule parameters in Payroll configuration, following the same slab format, before PT is computed for those employees. **Q: How is PF calculated in Odoo 19 Indian payroll?** Employee and employer Provident Fund are 12% of basic salary by default. For each employee you choose whether contributions are restricted to a PF wage of ₹15,000 or calculated on actual PF wages. The percentage, the ceiling and the 8.33% EPS share are rule parameters, so they can be updated with a new dated value if the statutory rates change. --- ## Employee expenses and reimbursements in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-expenses-reimbursements - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Expenses, Reimbursement, Accounting How Odoo 19 Expenses works without expense reports: categories, receipts, approvals, employee-paid versus company-paid, and re-invoicing customers. Odoo 19 Expenses is a Community app where each expense is approved, posted and paid on its own: the expense report (expense sheet) of earlier versions is gone. An employee records the expense with its receipt, chooses whether they or the company paid, and submits it; the approver approves, accounting posts it, and employee-paid expenses are reimbursed by bank payment or, with Enterprise Payroll, through the payslip. Get categories, approvers and the expense journal right first; everything else follows. ## What changed in Odoo 19: no more expense reports Up to Odoo 18, expenses were grouped into an expense report that moved through approval and posting as one unit. In 19.0 the hr.expense.sheet model is gone and only a "Former Report" reference remains on migrated expenses. Each expense now carries its own status: Draft, Submitted, Approved, Posted, In Payment, Paid, or Refused. In practice this is simpler for approvers, who see a list of items instead of opening reports, and for employees, who no longer have to remember to bundle claims. The trade-off is volume: a travelling sales team produces many small lines. Filters, grouping by employee, and approving in bulk from the list view become the working tools. If you are upgrading from 17 or 18, tell finance before go-live that the report they used to print and sign no longer exists in that form. ## Expense categories An expense category ( Expenses > Configuration > Expense Categories ) is a product that can be expensed. It carries the expense account, the default taxes and, optionally, a fixed cost. A fresh database has six: Meals, Travel & Accommodation, Mileage, Gifts, Communication and a general Expenses category. Two patterns are worth knowing: - Fixed-cost categories. Mileage ships with a unit of measure of kilometres and a cost of 1.0 per unit. Set that to your per-km rate and employees just enter the distance. The same works for a fixed daily allowance. - Open categories. Leave the cost at zero and the employee enters the amount from the receipt. Keep the list short and aligned with your chart of accounts. Ten categories that map cleanly to expense accounts are easier to report on than forty that finance has to reclassify. For Indian companies, decide per category whether you expect a GST invoice. Where you do, set the GST tax on the category and ask employees to record the vendor, so the input tax lands on the right account; where you usually do not (local travel, small meals), leave the tax off rather than claiming credit you cannot support. ## Recording expenses and receipts Employees record expenses from Expenses > My Expenses , the mobile app, or by email. The Incoming Emails setting gives an alias ( expense@ by default); an employee forwards a receipt from their work email address and Odoo creates a draft expense with the attachment. A few features stop common mistakes: - Duplicate warnings when the same receipt or a matching expense has already been submitted, which approvers then have to confirm. - Split Expense on a draft, for a hotel bill that covers room, meals and a client dinner in different categories. - Foreign currency amounts with the rate shown, so a USD hotel bill is converted to INR for reimbursement. Expense Digitalization (OCR) reads details such as the amount and date from a photo of the receipt. It is Enterprise-only and uses IAP credits. ## Approvals and who approves Expenses has three access levels: Team Approver , All Approver and Administrator . When an expense is submitted, Odoo looks for the approver in this order: the employee's Expense Approver field, then the manager of their department (if that person is a Team Approver), then their own manager. Approvers can approve or refuse with a reason. Refused expenses go back to the employee to correct and resubmit. After approval the expense waits for accounting: an accountant clicks Post Journal Entries , choosing the accounting date and, for employee-paid expenses, the journal. ## Employee-paid versus company-paid The Paid By field decides what the accounting looks like: For employee-paid expenses, the Reimburse in Payslip setting installs hr_payroll_expense (Enterprise, needs Payroll). Approved expenses then get Report in Next Payslip , and the Indian Regular Pay structure has an Expenses Reimbursement rule that picks them up. It saves a separate bank run each month, at the cost of employees waiting until payday. Company expense cards through Stripe Issuing exist as a setting, but Stripe Issuing in 19.0 supports only USD, EUR and GBP journals, so it is not an option for INR accounts. ## Re-invoicing expenses to customers With Sales installed, the Sales Expense bridge ( sale_expense , Community) installs itself. Each expense category gets a Re-Invoice Costs policy: No, At cost, or Sales price. On the expense, the employee or approver picks the Customer to Reinvoice , which is a sales order. When the expense is posted, a line is added to that sales order and invoiced with the next customer invoice. - Decide which categories are ever billable, usually travel, accommodation and mileage for service companies. - Set those to At cost (or Sales price if your contracts mark up expenses) and leave the rest at No. - Make sure consultants know which sales order to pick, or set analytic distribution to the project so finance can check. - Review the re-invoiced lines on the sales order before invoicing. If an expense is reset after posting, check that the sales order line has been corrected too. With Projects installed, expenses can also carry the project's analytic distribution, which feeds project profitability reports. That is covered in projects and tasks later in the series. ``` Expenses > Configuration > Settings > Incoming Emails Expenses > Configuration > Settings > Employee Expense Journal Expenses > Configuration > Settings > Payment methods Expenses > Configuration > Expense Categories ``` What to configure before the first claim Next in the series is appraisals and skills . If your current process lives in spreadsheets and emailed receipts, we can help you move it . ## Questions we get asked **Q: Where are expense reports in Odoo 19?** They no longer exist. Odoo 19 removed the expense report (expense sheet) model, so each expense is submitted, approved, posted and paid individually, with its own status from Draft to Paid. Expenses migrated from earlier versions keep a reference to their former report. Approvers work from filtered list views, and can approve many expenses at once. **Q: How are employee expenses reimbursed in Odoo 19?** When an employee-paid expense is posted, Odoo creates a purchase receipt payable to the employee's work contact in the Employee Expense Journal. Finance then registers a payment, typically a bank transfer, from the expense or from accounting. With Enterprise Payroll and the Reimburse in Payslip setting, approved expenses can instead be added to the employee's next payslip. **Q: Can I bill employee expenses to a customer in Odoo 19?** Yes, if Sales is installed. Set the expense category's Re-Invoice Costs policy to At cost or Sales price, then choose the customer's sales order in the Customer to Reinvoice field on the expense. When the expense is posted, Odoo adds a line to that sales order, and it is billed with the next invoice for the order. **Q: Is Odoo 19 Expenses free in Community?** Yes. Expenses, email submission, approvals, posting, payments and re-invoicing through Sales are all Community features. The Enterprise-only pieces are receipt scanning (Expense Digitalization, which uses IAP credits), product prediction from descriptions, and reimbursement through payslips, which needs Enterprise Payroll. Company expense cards through Stripe Issuing are limited to USD, EUR and GBP journals. --- ## Appraisals, goals and skills in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-appraisals-skills - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Appraisals, Skills, HR, Performance Setting up Odoo 19 Appraisals and Skills: review cycles, goals, 360 feedback, ratings, skill levels, certifications and employee resumes. Odoo 19 splits performance management across two apps. Appraisals (Enterprise) runs review cycles with self and manager feedback, goals, a final rating and optional 360 feedback through surveys. Skills Management (Community) keeps each employee's skills, certifications and resume, and job positions can list the skills they require. Set up skills first, because appraisals can then review and update them, and switch on automatic appraisal scheduling only after checking every employee's next appraisal date. ## Skills Management: types, levels and certifications Skills Management ( hr_skills ) is a Community module; tick Skills Management in the Employees settings to install it. It adds the Resume tab on the employee form and a skills section beside it. The structure is three levels deep, configured under Employees > Configuration > Employee > Skill Types : - Skill type , for example Languages or Soft Skills (both created by default), or ones you add such as Tally, GST filing, CNC machining or SAP. - Skills within the type: Tamil, Hindi, English; or Negotiation, Presentation. - Levels for the type, each with a progress percentage from 0% to 100% and one marked as the default. A skill type marked as Certification behaves differently: each entry has validity dates, and expired certifications drop out of the current view. That suits forklift licences, first-aid training, ISO auditor certificates or vendor certifications that must be renewed. Employees > Learning > Certifications lists them across the company. ## Resumes and required skills on job positions Resume lines sit in sections. Odoo creates three: Other Experience, Education and Training. Experience inside your own company is built from the employee's version history, one line per job title and period, so HR does not have to type it; this is another reason to record promotions as new versions. Three small Community bridges feed the resume automatically when the related apps are installed: completed eLearning courses ( hr_skills_slides ), passed certification surveys ( hr_skills_survey ) and attended training events ( hr_skills_event ). Training attendance is listed under Employees > Learning > Training Attendances . Job positions can also hold the skills and levels they require. With Recruitment installed, hr_recruitment_skills adds skills to applicants so you can compare them with the position. The Reporting > Skills menu in Employees gives an inventory of skills and levels across employees, which is what managers tend to ask for when planning training or succession. ## Appraisal plans and campaigns Appraisals ( hr_appraisal ) is Enterprise-only. It creates appraisals in two ways. Appraisal plans are set in Appraisals > Configuration > Settings . The default schedule is a first appraisal 6 months after recruitment, a second 6 months later, then every 12 months. With Appraisals Automation ticked (on by default), a daily job creates appraisals in the Ongoing state when an employee's next appraisal date arrives, with a deadline 8 days later. Campaigns create a batch of appraisals at once: Launch Campaign lets you pick employees by name, by company, by department or by employee tag, choose a template and a date, and assign either each employee's manager or other named reviewers. This suits companies with an annual cycle, which in India is often April, aligned with the financial year and increments. ## Running an appraisal: feedback, goals and ratings An appraisal moves through Draft, Ongoing and Done. Each one has two feedback areas, one for the employee and one for the manager, pre-filled from the Appraisal Template with the questions you want answered. Each area can be kept hidden from the other party until it is published, so neither side sees the other's answers early. Appraisals created by the automatic plan start with both unpublished. The manager sets a Final Rating from the Evaluation Scale. The default scale has four levels: Needs improvement, Meets expectations, Exceeds expectations, and Strongly Exceed Expectations. The rating and a private note are not visible to the employee. Schedule Meeting puts the review conversation in both calendars, and Mark as Done closes the appraisal. Goals are separate records with a deadline, a progression (0%, 25%, 50%, 75% or 100%), tags and a description. They can be assigned to one or several employees and reused from the goal Library . We usually keep goals to three to five per person per cycle, reviewed during the appraisal rather than typed into the feedback text, so progress can be reported on. ## 360 feedback and skills inside the appraisal Tick 360 Feedback in Appraisal settings to install Appraisal - Survey. Each appraisal template can then carry a 360 feedback survey, and Ask Feedback on the appraisal sends it to chosen colleagues. Keep the survey short: five or six questions get answered; twenty get skimmed. With Appraisal - Skills, the employee's skills appear on the appraisal. The manager records the new level with a justification, and the previous level is kept, so skill growth has a history. Setting a target job on the appraisal adds that job's required skills, which turns a promotion conversation into a concrete gap list. - Define skill types, levels and certifications, and load current skills for each employee. - Add required skills to the job positions that matter most. - Write one appraisal template with the questions you actually use, and adjust the evaluation scale if your policy uses a different one. - Decide between automatic plans and campaigns; set dates or switch automation off accordingly. - Run the first cycle for one department, then roll out. This closes the HR section of the series. Next we move to projects and tasks . If you would like help designing a review cycle that people will actually complete, get in touch . ## Questions we get asked **Q: Is the Odoo 19 Appraisals app available in Community?** No. Appraisals, including goals, appraisal templates, campaigns and 360 feedback, is an Enterprise app. Skills Management, which covers skill types, levels, certifications, employee resumes and required skills on job positions, is Community and free to use. A Community database can therefore track skills and certifications but needs another tool, or Enterprise, for formal review cycles. **Q: Does Odoo 19 support 360-degree feedback?** Yes, in Enterprise. Enable 360 Feedback in the Appraisals settings to install the Appraisal - Survey module. Each appraisal template can include a feedback survey, and the Ask Feedback button on an appraisal sends it to selected colleagues. Their answers are collected in the Survey app and can be opened from the appraisal by the manager conducting the review. **Q: How do I schedule annual appraisals for everyone in Odoo 19?** Use Launch Campaign from the Appraisals app. Choose employees by name, company, department or tag, pick an appraisal template and a date, and assign each employee's manager or specific reviewers. If you use campaigns for a fixed annual cycle, consider turning off Appraisals Automation in settings so the daily job does not also create appraisals from individual next appraisal dates. **Q: How do certifications with expiry dates work in Odoo 19?** Mark a skill type as Certification in Skills Management. Each certification added to an employee then has a validity start and stop date, and expired ones no longer count as current. The Certifications menu under Employees, Learning lists them across the company, which helps track renewals such as safety training or professional licences. --- ## Projects and tasks in Odoo 19: stages, dependencies, milestones and profitability - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-projects-tasks - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Project management, Tasks, Profitability How to set up Odoo 19 Project: task stages, dependencies, milestones, the customer portal, profitability from sales and timesheets, and Enterprise planning. Odoo 19 Project is a Community app that handles projects, task stages, dependencies, milestones, recurring tasks and customer portal sharing out of the box. Profitability comes from two free bridge modules, Project - Account and Sales - Project, that pull sales, invoices, vendor bills and timesheet costs into each project. Gantt planning and resource scheduling are Enterprise-only. Most project rollouts go wrong in the same place: teams design an elaborate stage board before deciding how the project will be billed. This post takes the opposite order. ## What Odoo 19 Project includes in Community and Enterprise The project module is LGPL (Community). It gives you projects, tasks and sub-tasks, per-project task stages, tags, an email alias per project so incoming mail becomes tasks, customer ratings, project updates with a status (On Track, At Risk, Off Track, On Hold, Complete), and Tasks Analysis and burndown chart reports. Odoo 19 also lets you convert a project into a template and create new projects from it. Around it sit a few bridges worth knowing by name: - Project - Account ( project_account , Community) computes profitability items such as vendor bills and other analytic costs and revenues. - Sales - Project ( sale_project , Community) generates projects and tasks from confirmed sales orders and adds sales revenue to profitability. - Task Logs ( hr_timesheet , Community) is the timesheet module; the app menu still reads Timesheets. Part 31 covers it. - Project Enterprise adds Gantt and map views; Planning and Project Planning ( project_forecast ) add shift-based resource planning. All three are Enterprise. ## Configuring task stages, task states and project stages Task stages belong to projects: each stage lists the projects that use it, so a software team and a site-installation team can have different boards in the same database. Configure them under Project > Configuration > Task Stages , or directly in a project's kanban. Stages describe where the work is. Odoo 19 keeps a separate state on every task for what is happening to it: In Progress, Changes Requested, Approved and Waiting, plus the closed states Done and Cancelled. Waiting is set automatically when a task is blocked by another task. Keep the two ideas apart: you do not need a "Blocked" or "Approved" stage when the state already says it. A stage can also carry: - an email template sent to the customer when a task reaches it; - a rating request, with Automatic Kanban Status turning good feedback into Approved and neutral or bad feedback into Changes Requested; - Days to rot , which marks tasks as stale after they sit in the stage for that many days (0 disables it). Stages for projects themselves (as opposed to tasks) are off by default. Switch on Project Stages in Project > Configuration > Settings if you manage a portfolio and want a kanban of projects by phase. ## Task dependencies, milestones and recurring tasks These three features are switched on per project, not globally. Open the project, go to the Settings tab and tick Recurring Tasks, Task Dependencies or Milestones as needed. - Task dependencies add a "blocked by" relation between tasks. A blocked task shows the Waiting state until its predecessors close, and in Enterprise the Gantt view draws the links. - Milestones have a deadline and a Reached flag, and tasks are attached to them. With Sales - Project installed, a milestone can point to a sales order line and a quantity percentage, which is how milestone billing works: reach the milestone and that share of the line counts as delivered. - Recurring tasks regenerate a task on a schedule. Good for monthly GST filings or maintenance visits; bad as a substitute for a proper subscription or maintenance plan. Turn on milestones before you create service products if you intend to bill on them. The Based on Milestones invoicing policy only appears on products once the milestone feature is active. ## Sharing projects with customers on the portal Each project has a Visibility setting on its Settings tab. The four options are Invited internal users, Invited internal and portal users, All internal users, and All internal users and invited portal users. The last is the default, so new projects are open to all employees and to any portal user you explicitly invite. To give a customer access, use Share Project and add them as a collaborator with one of three access modes: Read, Edit with limited access, or Edit. Read suits most clients. Edit with limited access lets them edit a restricted set of fields on the tasks they follow, which works well for customer-raised requests. Full Edit is rarely what you want on a client-facing project. ## Project profitability from sales, timesheets and vendor bills Profitability runs on the analytic account linked to the project; Odoo creates one when a feature such as timesheets needs it. The project's right-hand panel groups revenues and costs into lines such as Timesheets (Billed on Timesheets), Timesheets (Fixed Price), Timesheets (Billed on Milestones), Timesheets (Non-Billable), Materials, Customer Invoices, Down Payments, Vendor Bills, Other Revenues and Other Costs, depending on which modules are installed. Three things have to be true for those numbers to be meaningful: - Employees need an Hourly Cost on their employee record, otherwise timesheet cost is zero. - Service products need the right Create on Order value (Task, Project, or Project & Task) and invoicing policy, so the sales order line is linked to the project. - Vendor bills for subcontractors or materials need the project's analytic account on the line. For an Indian services business this is where a Tally migration shows its limits: Tally tracks cost centres, but it does not know which task or employee produced the cost. Moving to per-project analytic accounts is worth the effort. Profitability is a management view; statutory GST reporting still runs from the journal entries, as described in part 22 . ## A sensible setup order, with Enterprise planning last - Decide how each type of work is billed: fixed price, timesheets, milestones or not at all. - Create service products with the matching invoicing policy and Create on Order value. - Build one project, its stages and its Settings tab, then convert it to a template. - Set employee hourly costs and switch on timesheets for projects that need them. - Invite one friendly customer to the portal before rolling it out to everyone. - Only then add Planning (Enterprise) for shift and capacity scheduling. Planning works in shifts on a Gantt chart. With Project Planning installed, shifts can be linked to projects and tasks, and the Planning settings include options for employees to switch shifts or unassign themselves before a deadline. It pays off when people are shared across several projects; for a single team it is often more ceremony than value. Once projects are in shape, the next step is getting time recorded and billed properly. Continue with timesheets and billable hours in Odoo 19 , or talk to us if you want a second pair of eyes on your project structure. ## Questions we get asked **Q: Is Odoo 19 Project free in Community edition?** Yes. The Project app is licensed LGPL-3 and ships with Odoo Community. It includes tasks, sub-tasks, stages, task dependencies, milestones, recurring tasks, customer portal sharing and profitability through the Community bridge modules. Gantt and map views come from Project Enterprise, and resource scheduling comes from the Planning app, both of which need an Odoo Enterprise subscription. **Q: How do I enable task dependencies in Odoo 19?** Task dependencies are enabled per project. Open the project, go to its Settings tab and tick Task Dependencies. Tasks then get a "blocked by" field, and a task whose predecessors are still open shows the Waiting state automatically. Milestones and recurring tasks are switched on in the same place, so you can enable them only on the projects that need them. **Q: Can customers see their project tasks in the Odoo portal?** Yes. Set the project's visibility to an option that includes portal users, then use Share Project to add the customer as a collaborator. Choose Read, Edit with limited access, or Edit. Read-only suits most client projects. The customer then sees the project and its tasks from their portal account and can follow progress without emailing your team. **Q: How does Odoo 19 calculate project profitability?** Profitability runs on the analytic account linked to each project. Odoo groups revenue from sales orders and invoices, timesheet cost from employee hourly costs, and costs from vendor bills and other analytic lines into a profitability panel on the project. It is only accurate if employees have an hourly cost, service products are linked to projects, and bills carry the project's analytic account. --- ## Timesheets and billable hours in Odoo 19: billing models, validation and timers - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-timesheets-billable-hours - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Timesheets, Billable hours, Invoicing How Odoo 19 timesheets feed invoices: billing on timesheets vs fixed price vs milestones, employee rates, validation, and the Enterprise grid and timer. In Odoo 19, timesheets are logged against project tasks and become invoice lines through the service product on the sales order: bill on timesheets, at a fixed price, on milestones, or manually. The base timesheet module is Community; the weekly grid, the timer and timesheet validation are Enterprise. Decide the billing model per service product first, because every other setting follows from it. ## What Odoo 19 timesheets include in Community and Enterprise The Community module is Task Logs ( hr_timesheet ), though the app menu is still called Timesheets. It lets employees log time on tasks, rolls time up to projects, and gives you reports by employee, by project and by task. It also costs every entry using the employee's Hourly Cost , which is what makes project profitability work. Access comes in three levels: User: own timesheets only , User: all timesheets and Administrator . Most staff need the first. Team leads who approve time need the second. Enterprise adds the Timesheets module ( timesheet_grid ) with: - a weekly grid where people fill hours per task per day; - a start/stop timer on tasks and in the grid; - validation, with a To Validate menu split into Last Period and All Timesheets; - time rounding for the timer, with Minimal Duration and Round up both defaulting to 15 minutes. On top of that, Sales Timesheet: Invoicing (Enterprise) adds the choice to invoice all recorded timesheets or validated ones only, billing time targets per employee and a billing-rate leaderboard. ## Timesheet settings to configure first Open Timesheets > Configuration > Settings and settle these before anyone logs an hour: - Encoding Method : Hours / Minutes or Days / Half-Days. Consultancies billing day rates sometimes want days, but hours are easier to reconcile with attendance and payroll. - Employee Reminder and Approver Reminder : periodic emails to people with missing timesheets and to approvers with timesheets waiting. - Time Off : generates timesheets for validated time off and public holidays, so a week of leave does not look like a week of idle time in utilisation reports. Then set an Hourly Cost on every employee who logs time. Without it, timesheet cost is zero and every project looks more profitable than it is. For Indian teams, a practical approach is to derive hourly cost from CTC including employer PF and ESI contributions, divided by productive hours, and review it annually with the appraisal cycle. ## Billing on timesheets vs fixed price vs milestones The billing model lives on the service product as the Service Invoicing Policy , next to Create on Order , which decides whether a sales order creates a task, a project, or both. Based on Milestones appears only after milestones are enabled on at least one project (see part 30 ). With fixed price, timesheets are still recorded as cost, so profitability shows Timesheets (Fixed Price) against the fixed revenue. That is often the most useful report a services business gets from Odoo. Prepaid products also have an upsell Threshold : when the time delivered reaches that percentage of the prepaid amount, Odoo creates an upsell activity for the salesperson. Set it below 100% if you want warning before the hours run out. ## Task rate, project rate and employee rate For timesheet billing, the project's pricing is one of three types, and Odoo works it out from how you link the project to sales order lines: - Task rate : each task points to its own sales order item. Good when different tasks are different services at different prices. - Project rate : the whole project bills to one sales order item at one hourly rate, whoever does the work. - Employee rate : on the project's Invoicing tab, you map each employee to a sales order item, so a senior consultant and a junior consultant bill at different rates for the same service. Each timesheet line gets a Billable Type such as Billed on Timesheets, Billed at a Fixed price, Billed on Milestones or Non-Billable. Remove the sales order item from a timesheet and it becomes non-billable. That is how you write off time without deleting it, which keeps cost and utilisation honest. ## Timesheet validation and invoicing validated time In Enterprise, approvers validate timesheets from Timesheets > To Validate . Validation locks entries: only approvers (User: all timesheets) and Administrators can modify a validated line, and other users cannot edit or delete entries dated on or before the last validated date. With Sales Timesheet: Invoicing installed, Timesheets Invoicing in the settings offers All recorded timesheets (the default) or Validated timesheets only . The choice also controls which timesheets customers see on their portal. - Employees fill the week in the grid or with the timer, by Monday morning. - Reminders chase anyone missing; approvers validate Last Period. - Finance creates invoices from sales orders, using the timesheet start and end dates on the invoicing wizard to bill a clean period. - Each billed timesheet keeps a link to its invoice, so you can trace exactly which hours an invoice covered. GST on services works as for any invoice: the tax comes from the product and fiscal position, and place of supply follows the customer's state. Part 22 covers that set-up. Start with two or three service products, one billing model each, and a single project that uses them end to end before rolling out company-wide. The next post moves outward to your customers: the Odoo 19 website builder . If you are designing rates and billing for a services firm, our implementation team can help. ## Questions we get asked **Q: Are timesheets free in Odoo 19 Community?** Yes. The Community module, called Task Logs with a Timesheets menu, lets employees log time on tasks, costs it using the employee's hourly cost and supports billing through sales orders. The weekly grid view, the start/stop timer, timesheet validation and the option to invoice only validated timesheets are Enterprise features in the Timesheets and Sales Timesheet: Invoicing modules. **Q: How do I invoice customers based on timesheets in Odoo 19?** Create a service product with the Service Invoicing Policy set to Based on Timesheets and Create on Order set to Task, Project, or Project and Task. Sell it on a sales order and confirm. Hours logged on the linked tasks become the delivered quantity on the order line, and creating an invoice from the sales order bills them, optionally limited to a start and end date. **Q: Can different employees bill at different rates on the same project?** Yes. On a billable project with a customer, open the Invoicing tab and map each employee to a sales order item carrying their rate. Odoo then treats the project as Employee rate pricing, and each timesheet is billed on the sales order line mapped to the person who logged it. This suits consultancies where seniority determines the hourly rate. **Q: Can validated timesheets be edited in Odoo 19?** Only by approvers (User: all timesheets access) or Timesheets Administrators. Once time is validated, ordinary users cannot edit or delete entries dated on or before the last validated date. Validation is part of the Enterprise Timesheets module. If invoicing is set to validated timesheets only, unvalidated hours stay off invoices and out of the customer portal until an approver validates them. --- ## The Odoo 19 website builder: pages, blocks, SEO, forms and leads - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-website-builder - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Website, SEO, CRM Setting up an Odoo 19 website: pages and blocks, SEO settings, redirects, forms that create CRM leads, multi-language, the blog, and what to configure first. The Odoo 19 Website app is a Community module that builds pages from drag-and-drop blocks, manages SEO per page, and writes form submissions straight into the same database as your CRM, helpdesk and recruitment. Its real advantage over a separate CMS is not design but data: a contact form becomes a lead with its source and page views attached. Set up the domain, languages and tracking before building pages, and plan redirects before you migrate an existing site. ## What the Odoo 19 Website app covers The core website module is LGPL (Community). It gives you the page editor, themes, menus, multi-website, page visibility rules, redirects, visitor tracking and SEO tools. Separate Community modules add the parts most businesses need next: - Contact Form ( website_crm ) turns form submissions into CRM leads or opportunities. - Blog ( website_blog ) for posts, tags and tag categories. - Newsletter Subscribe Button ( website_mass_mailing ) to collect mailing list sign-ups. - eCommerce , Events , Online Jobs and eLearning for their own page types. Some neighbours are Enterprise-only, such as Website Appointments and publishing Knowledge articles. Odoo Online and Odoo.sh give you hosting and a domain mapping; on-premise, you run the web server and certificates yourself (see part 3 ). ## Website settings to configure before building pages Open Website > Configuration > Settings . The settings that are painful to change later are near the top: - Domain : the web address this website answers on. With multi-website, each website gets its own. - Languages : the languages the site offers and the Default one. Use Install new languages first if a language is not active in the database. - Website Identification : the site name and favicon. - Tracking & SEO : Plausible or Google Analytics, Google Search Console verification, a CDN, Robots.txt , a Default Social Share Image and the cookies bar, including an option to block third-party tracking services until consent. ## Building pages with blocks, menus and visibility Pages are built in the editor from blocks: drag a block from the Blocks panel, then adjust it in Style and set colours and fonts under Theme . Keep a small, consistent set of blocks. A site that uses every block type in the library looks like a demo. The Site menu in the editor holds the tools you use daily: Menu Editor , Content > Pages for the list of every page, and under This page , Properties , Optimize SEO and the HTML / CSS Editor . Each page's properties control its URL, whether it is indexed, publication, and visibility. There are four visibility options: Public, Signed In, Restricted Group and With Password. Restricted Group is useful for dealer price lists or partner resources without building a portal. ## SEO settings and redirects in Odoo 19 Optimize SEO works page by page. It lets you set the title and meta description, add keywords and see where each keyword is used (title, description, H1, H2, content), choose the social share image, check for broken links, and hide the page from search results. The dialog also has a Fill with AI option for the meta fields; treat its output as a draft and edit it. Odoo generates /sitemap.xml for published pages automatically. The work that actually matters is redirects. Under Website > Configuration > Redirects , each rule has an action: ``` 404 Not Found 301 Moved permanently 302 Moved temporarily (default) 308 Redirect / Rewrite ``` Redirect actions available in Odoo 19; new rules default to 302. For pages that have moved for good, including migrations from WordPress or an old Odoo site, change the action to 301. Leaving the 302 default in place is a mistake we see often on Odoo sites after a relaunch. ## Website forms that create CRM leads The form block submits into a model you pick. With the relevant apps installed, the actions include Send an E-mail , Create an Opportunity , Create a Task , Create a Ticket , Apply for a Job and Create a Customer . You can add fields from the target model, mark them required, and hide fields with preset values. For lead forms, set the Sales Team and Salesperson on the form itself so leads land with the right people. If you leave them empty, the website's default sales team and salesperson apply. Leads from the website get the UTM medium "Website" unless the form says otherwise, and are linked to the website visitor, so the salesperson can see the page views that led to the enquiry. Protect public forms against spam with Google reCAPTCHA or Cloudflare Turnstile, both available as Community modules. Lead scoring and assignment then follow the CRM set-up in part 6 . ## The blog, multi-language content and launch order The Blog app supports several blogs on one site, posts with their own SEO settings, and tags grouped into tag categories, all managed from Website > Content > Blog Posts and Configuration > Blog . Translating a post or page uses the editor's translate mode for each installed language, with the URL prefixed by the language code. - Settings: domain, languages, analytics, cookies bar, robots.txt. - Theme, header, footer and menus. - Core pages, with SEO titles and descriptions written as you go. - Forms wired to CRM, with sales team, salesperson and spam protection. - 301 redirects from every old URL that had traffic. - Blog and translations once the core site is live. Launch with fewer pages and working forms rather than more pages and a contact form that emails a shared inbox. The next part covers what to do with the contacts you collect: email marketing, automation and events . For a migration from another platform, talk to us about the redirect map first. ## Questions we get asked **Q: Is the Odoo 19 website builder free?** The Website app is licensed LGPL-3 and is part of Odoo Community, so the builder, themes, blog, contact forms, SEO tools and redirects cost nothing in licence terms. You still pay for hosting and a domain. Some related apps are Enterprise-only, such as Website Appointments and publishing Knowledge articles. On Odoo Online, check the current plans on odoo.com/pricing. **Q: How do I set up 301 redirects in Odoo 19?** Go to Website, then Configuration, then Redirects, and create a rule with the old URL, the new URL and the action. New rules default to 302 Moved temporarily, so change the action to 301 Moved permanently for pages that have moved for good. This matters most when migrating from WordPress or an older site, because search engines only transfer ranking reliably through permanent redirects. **Q: Can an Odoo website contact form create CRM leads automatically?** Yes. Install the Contact Form module, which comes with CRM, and set the form block's action to Create an Opportunity. You can choose the sales team and salesperson on the form. Each submission becomes a lead or opportunity in CRM, tagged with the Website medium and linked to the visitor record, so sales can see which pages the prospect viewed. **Q: Does Odoo 19 support a multilingual website?** Yes. Install the languages in the database, add them under Languages in the Website settings, and choose a default. Each page, menu and blog post can then be translated in the editor's translate mode, and translated pages are served under a language prefix in the URL. Meta titles and descriptions are translatable too, so each language gets its own SEO text. --- ## Email marketing, marketing automation and events in Odoo 19 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-email-marketing-automation-events - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Email marketing, Marketing automation, Events How to run Odoo 19 Email Marketing, Marketing Automation and Events: mailing lists, campaigns, A/B tests, automated workflows, registrations and tickets. Odoo 19 splits marketing into three apps that share one contact database: Email Marketing and Events are Community, and Marketing Automation is Enterprise. Email Marketing sends one-off mailings to lists or any filtered set of records, Marketing Automation runs multi-step workflows triggered by opens, clicks and time delays, and Events handles registrations, tickets and attendee emails. Start with clean mailing lists and a dedicated sending domain; automation only pays off once those basics work. ## Which Odoo 19 marketing apps are Community and which are Enterprise All of them record UTM campaign, medium and source on what they create, so a lead from a webinar or a sale from a newsletter link can be traced back in CRM and Sales reporting. ## Setting up Email Marketing: lists, contacts and sending The menu is short: Mailings , Mailing Lists (with Mailing List Contacts ), Campaigns once the setting is on, and Reporting . In Email Marketing > Configuration > Settings , the options worth deciding early are: - Mailing Campaigns , to group several mailings under one campaign. - Dedicated Server , to send bulk mail through a separate outgoing server from your transactional mail. - Blacklist Option when Unsubscribing , so recipients can block all mail, not just one list. - 24H Stat Mailing Reports , a summary a day after sending. A mailing can target a mailing list or any record type enabled for mailing, such as contacts, leads, sales orders or event attendees, with a filter. Lists are for people who opted in; filters on customers are for operational messages. Mixing the two is where consent problems start. Odoo 19 Email Marketing includes A/B testing in Community: send variants to a percentage of recipients and pick the winner manually or by Highest Open Rate, Highest Click Rate or Highest Reply Rate. Opt-outs, blacklisted addresses and opt-out reasons are all under Configuration and Reporting, and every link in a mailing goes through the Link Tracker. ## Building workflows in Marketing Automation (Enterprise) A Marketing Automation campaign has a target Model (Contact by default), a Filter that decides who enters, and a Unique Field , usually email, to stop the same person entering twice. Campaigns move through New, Running and Stopped. Inside, each activity is an Email or a Server Action , with SMS and WhatsApp available through bridge modules. Each activity has a trigger and a delay in hours, days, weeks or months: ``` beginning of workflow another activity Mail: opened · Mail: not opened Mail: replied · Mail: not replied Mail: clicked · Mail: not clicked Mail: bounced ``` Trigger types for Marketing Automation activities in Odoo 19. A practical first workflow is a three-step nurture: welcome email at the start, a follow-up two days later if the first was not opened, and a server action that creates a CRM activity for sales when someone clicks the pricing link. Server actions are where automation touches the rest of the database, so have someone who understands the data model review them. - Write down the audience filter and test it as a saved filter first. - Build the workflow with emails only, no server actions. - Run it with test participants and check timing and content. - Add server actions one at a time, then switch the campaign to Running. If you only have Community, Automation Rules ( base_automation ) can send an email when a record changes, but it is not a marketing workflow tool. Buy Enterprise for this if nurturing sequences genuinely drive revenue for you; otherwise well-timed mailings do most of the job. ## Running events: registrations, tickets and attendee emails The Events app works from event templates. A template carries the default tickets, registration questions and communication schedule, so set up one template per event format (webinar, workshop, conference) under Events > Configuration > Event Templates . A new event gets three scheduled communications by default: a confirmation sent on registration, and reminders three days and one hour before the event. Edit those mail templates first; the defaults are generic. Limit Attendees caps seats, and Multiple Slots lets one event run several time slots with seat limits per slot. Registrations move through Unconfirmed, Registered, Attended and Cancelled. The Registration Desk scans badge barcodes at the door when Use Event Barcode is enabled. Selling tickets and running larger events need extra modules, all switched on from Events > Configuration > Settings : - Tickets with Sale sells tickets on sales orders, with a product per ticket type, so GST and invoicing follow the product's taxes. - Online Ticketing sells tickets on the website through the eCommerce checkout and a payment provider. - Tickets with PoS sells at the door from Point of Sale. - Schedule & Tracks , Online Exhibitors and Booth Management for conferences. With CRM installed, Events > Configuration > Lead Generation holds rules that create leads from registrations, which is how an event feeds the pipeline rather than a spreadsheet of attendees. ## Connecting marketing to CRM and sales The reason to run marketing in Odoo rather than a separate tool is that results land on real records. A mailing's UTM campaign appears on the leads and orders it produced. Event lead rules put attendees into the pipeline. The Newsletter Subscribe Button on the website adds sign-ups to a list without an export. Start with one mailing list, one event template and the default reports. Add Marketing Automation when you can name the sequence you want to automate. The next part turns to internal paperwork: Documents, Sign and Knowledge . If you want help structuring lists and consent, get in touch . ## Questions we get asked **Q: Is Odoo Email Marketing free in Community edition?** Yes. The Email Marketing app is licensed LGPL-3 and ships with Odoo Community. It includes mailing lists, drag-and-drop email design, A/B testing, link tracking, opt-out management and reporting. Marketing Automation, which runs multi-step workflows with triggers and delays, is Enterprise-only. Sending volume and deliverability depend on your mail server or Odoo hosting plan rather than on the edition. **Q: What is the difference between Email Marketing and Marketing Automation in Odoo?** Email Marketing sends a single mailing to a list or filtered set of records at a chosen time. Marketing Automation, an Enterprise app, builds workflows where each step is triggered by the start of the campaign, another step, or recipient behaviour such as opening, clicking or not replying, after a delay. Use Email Marketing for newsletters and announcements, and automation for nurture sequences. **Q: Can I sell event tickets online with Odoo 19?** Yes. Enable Online Ticketing in the Events settings, which uses the Odoo eCommerce checkout, and configure a payment provider. Each ticket type is linked to a product, so taxes such as GST and invoicing follow the product. Tickets can also be sold on sales orders with Tickets with Sale, or at the venue through Point of Sale with Tickets with PoS. **Q: Does Odoo send event reminder emails automatically?** Yes. A new Odoo 19 event gets three scheduled communications by default: a confirmation on registration, and reminders three days and one hour before the event starts. You can change the timing, add more schedulers, or use SMS with the Event SMS module, and event templates let you save a standard schedule. Edit the mail templates before the first event, because the default wording is generic. --- ## Documents, Sign and Knowledge in Odoo 19: files, e-signatures and internal wikis - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-documents-sign-knowledge - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Documents, Sign, Knowledge How to set up Odoo 19 Documents, Sign and Knowledge: folders and access, document requests, OCR routing to accounting, e-signature templates and articles. Documents, Sign and Knowledge are three Enterprise apps in Odoo 19 that cover the paperwork around your transactions. Documents stores and routes files, including turning a scanned bill into a draft vendor bill; Sign sends PDFs for electronic signature; Knowledge is an internal wiki of written articles. Set up Documents folders and accounting routing first, because that is where the time saving is; Sign and Knowledge can follow in any order. ## What each app does and where they overlap All three are licensed OEEL-1, so none is available in Community. Bridge modules connect them to the rest of Odoo: Documents - Accounting, Documents - HR, Documents - Payroll, Documents - Expense, Documents - Projects and Documents - Signatures, among others. ## Organising Documents: folders, access and requests In Odoo 19, Documents is organised in folders; the separate "workspace" concept of older versions is gone, and a folder is simply a document of type Folder. A fresh install creates starter folders such as Inbox, Finance, Taxes, Annual Closing, Marketing, Legal and Insurances. Rename or remove them before users start uploading. Access is set per folder and per document with three controls: - Internal Users Rights : Viewer, Editor or None for all employees. - Link Access Rights : Viewer, Editor or None for anyone with the link. - Specific people added with their own access. New documents inherit these rights from the folder they are created in, and a document outside any shared folder defaults to None on both, so it stays private until you share it. For most businesses, a sensible pattern is one folder per department with internal rights on the folder, and link sharing only for individual files sent outside. Request creates a placeholder for a document you are waiting for, such as a signed offer letter or a supplier's GST certificate, with an owner, a contact, a due date and an activity. When the file arrives, it fills the placeholder. Folders can also have an email alias, so suppliers can mail invoices straight into Finance. ## Routing documents to accounting with OCR With Documents - Accounting installed, the Accounting setting in Documents centralises accounting files: you choose a Folder and map Journals to folders and tags, so bills and invoices created in Accounting also appear in Documents. The other direction is the useful one. On a file in the Finance area you can run actions such as: ``` Create Vendor Bill Create Vendor Credit Note Create Customer Invoice Create Customer Credit Note Create Vendor Receipt Create Misc Entry Import Bank Statement ``` Accounting actions provided by Documents - Accounting in Odoo 19. Actions can be pinned to a folder. The action creates a draft entry with the file attached. If Document Digitization is enabled in Accounting > Configuration > Settings , OCR reads the vendor, dates, amounts and tax lines. The defaults are Digitize automatically for vendor bills and Digitize on demand only for customer invoices. Digitisation uses paid IAP credits. For Indian vendor bills, check GSTIN, place of supply and the tax split between CGST/SGST and IGST on every digitised bill until you trust the results for each supplier. OCR saves typing; it does not replace review. The payables flow is covered in part 20 . ## Sending documents for e-signature with Sign Sign works from templates. Upload a PDF, place fields on it, assign each field to a role (Customer, Employee and so on), and save. The standard field types are Signature, Initials, Name, Email, Phone, Company, Text, Multiline, Checkbox, Radio, Selection, Date, Strikethrough and Stamp. When sending, you can set a Signing Order , a Valid Until date and reminders (every seven days by default once enabled). Requests move through To Sign, Signed, Cancelled and Expired. The finished PDF carries a certificate of completion, and settings let you configure a signing certificate for the company. Each role can require an Extra Authentication Step : - Unique Code via SMS , with the Authenticate by SMS setting (SMS credits apply); - Via Aadhar eSign , from the Sign with Aadhaar eSign setting, which installs the emSigner integration for Indian signatories; - itsme, for Belgium and the Netherlands. Which signature type a given Indian document needs is a legal question, not a software one; ask your adviser before you replace wet signatures on, say, property or loan documents. For offer letters, NDAs and sales agreements, a standard Sign template is usually enough. ## Writing internal documentation in Knowledge Knowledge articles sit in three sections: Workspace for articles visible to employees, Private for your own drafts, and Shared for articles shared with specific members. Internal permission on an article is Can edit, Can read or Members only, and external users, including portal users, can be added as members. Articles can contain items , child records shown as a list or kanban inside the article, which makes simple trackers possible without a custom app. Knowledge also supports article templates, and stages for items are managed under Knowledge > Configuration. With the Knowledge Website module (Enterprise), individual articles can be published on your website. ## A practical rollout order - Clean up the default Documents folders and set internal access per department. - Turn on Document Digitization and route the vendor-bill inbox into Finance. - Build two or three Sign templates for the documents you send most. - Move your SOPs into Knowledge, one workspace section per department. If you are unsure whether you need a custom field or a small app on top of all this, the next part covers exactly that line: Odoo 19 Studio and when to write a module instead . For a paperless-finance set-up, talk to us . ## Questions we get asked **Q: Is Odoo Documents available in Community edition?** No. Documents, Sign and Knowledge are all Enterprise apps in Odoo 19, licensed OEEL-1, so they need an Odoo Enterprise subscription on Odoo Online, Odoo.sh or on-premise. Community users can still attach files to any record through the chatter, but they do not get central folders, access controls, document requests, accounting routing, e-signature templates or the Knowledge wiki. **Q: How does Odoo 19 turn a scanned invoice into a vendor bill?** Upload or email the scan into a Documents folder, then run the Create Vendor Bill action on it. Odoo creates a draft vendor bill with the file attached. If Document Digitization is enabled in the Accounting settings, OCR reads the vendor, dates, amounts and taxes automatically, which uses paid IAP credits. An accountant then reviews the draft and posts it. **Q: Does Odoo Sign support Aadhaar eSign?** Yes. In Odoo 19 Sign settings, Sign with Aadhaar eSign installs an emSigner integration for Indian signatories. Each signer role can then require Via Aadhar eSign as its extra authentication step, alongside options such as a unique code by SMS. Whether a particular document legally needs Aadhaar eSign rather than a standard electronic signature is a question for your legal adviser. **Q: What is the difference between Odoo Knowledge and Documents?** Documents manages files such as PDFs, scans and spreadsheets, with folders, access rights, requests and actions that create accounting entries. Knowledge manages written articles such as procedures, guides and notes, edited directly in Odoo with permissions, templates and embedded lists. Use Documents for anything that arrives as a file, and Knowledge for anything your team writes and maintains. --- ## Customising Odoo 19 with Studio, and when to write a module instead - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-studio-customisation - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Studio, Customisation, Upgrades What Odoo 19 Studio does with fields, views, automations and reports, where it stops, when a custom module is the right call, and what that means for upgrades. Odoo 19 Studio is an Enterprise app for adding fields, changing views, building automations and editing reports without code, and Odoo's upgrade service covers Studio customisations while Studio stays installed and the subscription is active. Use Studio for fields, layouts, simple rules and report tweaks. Write a custom module when you need new business logic, integrations, performance-sensitive code or anything you want under version control and tests. ## What Odoo 19 Studio can change Studio ( web_studio ) is licensed OEEL-1. On Odoo's current plans it is included in the Custom plan, and it can also be picked as the single app on the free one-app plan; check odoo.com/pricing for your case. Open it from the toolbar icon on any screen, and it edits the screen you were on. Inside an app, the Studio bar gives you Views , Reports , Automations , Webhooks , Access Control and Filter Rules . From the Studio home screen you can also create a New App , and Export or Import customisations. - Fields : new fields on existing models are technical-named x_studio_… . Text, numbers, dates, selections, many2one links, related fields and more. - Views : form, list, kanban, calendar, pivot, graph, search, activity, and in Enterprise map, Gantt and cohort. Hide fields, make them required, move them, add tabs. - Reports : edit PDF layouts such as quotations and invoices, add fields or dynamic tables. - Approvals : rules on buttons so, for example, a sales order above a threshold needs a manager's approval before confirmation. - New apps : a custom model with its own menu, views and fields, for a simple register such as equipment loans or site visits. ## Automations, webhooks and the Community alternatives Automations in Studio are Automation Rules ( base_automation ), which is a Community module. Studio gives them a friendlier editor; in Community you reach the same rules in developer mode under Settings > Technical > Automation > Automation Rules . Rules are triggered by events such as Stage is set to, User is set, Tag is added, On create and edit, On deletion, On UI change, Based on date field, After creation, After last update, On incoming message, On outgoing message and On webhook. The actions they run are server actions: Update Record, Create Record, Duplicate Record, Execute Code, Send Webhook Notification and Multi Actions, plus sending emails, SMS or scheduling activities. Odoo 19 also has Properties fields in Community on several records, including contacts, CRM leads (defined per sales team) and project tasks (defined per project). Properties let users add simple fields without Studio or code. For a few extra fields on a lead or a task, try them first. ## Where Studio stops and a custom module is the right call Apps built with Studio's New App deserve the same scrutiny. The model gets a technical name starting with x_ , and it has fields, views and menus but no Python methods of its own; any behaviour comes from automation rules. That is fine for a register or a checklist. It becomes fragile once the app needs to post journal entries, reserve stock or talk to another system, because every rule is another piece of logic that lives only in the database. A custom module is also the right call when a change must behave identically across several databases, such as staging and production or a group of companies on separate instances. Studio's Export produces a zip containing a module ( studio_customization ) that can be imported elsewhere, but it is generated data, not code you maintain. For Indian businesses, the typical boundary cases are e-invoicing and e-way bill integrations, TDS or TCS logic beyond what the localisation provides, and data migrations from Tally. All of those belong in code. The GST localisation itself is covered in part 22 . ## How Studio and custom modules behave during upgrades This is the part that decides long-term cost. Odoo's upgrade documentation states that upgrade services cover all standard apps, all customisations created with Studio as long as Studio is still installed and the subscription is active, and developments covered by a maintenance of customisations subscription. Custom modules are different. Their source code must be updated to the target version before the database can be upgraded. That work is yours or your partner's, and it scales with how much the module overrides standard behaviour. > Studio is cheap to add and cheap to upgrade, but only while it stays within what Studio is meant for. One practical warning: Studio view changes are stored as inherited views that target elements of the standard view. If a later version restructures that view, the customisation may need adjusting after the upgrade, so test Studio-heavy screens on the upgraded copy like any other change. ## A sensible customisation policy - Run standard for a few weeks before customising anything; many requests disappear. - Try configuration and Properties fields first. - Use Studio for fields, views, reports and simple automations, and keep a list of every change. - Move anything with code, integrations or heavy logic into a module in Git. - Review the Studio list before each upgrade and remove what nobody uses. Whoever owns Studio in your organisation should also own that list. The next post in the series is about upgrading to Odoo 19 from 16, 17 or 18 . If you already have a mix of Studio and custom code to carry forward, our upgrade service or implementation team can review it. ## Questions we get asked **Q: Is Odoo Studio included in Odoo Community?** No. Studio is an Enterprise app, licensed OEEL-1. On Odoo's current plans it is part of the Custom plan and can also be chosen as the single app on the free one-app plan; odoo.com/pricing has the details. Community users can still use Automation Rules in developer mode and Properties fields on contacts, leads and tasks, but not Studio's visual editors. **Q: Do Studio customisations survive an Odoo upgrade?** Odoo's upgrade services cover customisations made with Studio as long as Studio is still installed and the subscription is active. Custom modules are not covered unless you have a maintenance of customisations subscription; their code must be ported to the new version first. Studio view changes can still need adjusting when a standard screen is restructured, so test them on the upgraded copy. **Q: When should I use a custom module instead of Studio?** Use a custom module when you need new business logic, calculations across many records, changes to accounting or stock behaviour, integrations with external APIs, scheduled batch jobs or code you want in version control with tests. Studio is best for fields, view layouts, report tweaks, approval rules and simple automations that set values, send emails or create activities. **Q: Can I move Studio customisations to another Odoo database?** Yes. The Studio home screen has an Export option that packages your customisations as a module named studio_customization, which can be imported into another database with the same apps and version. It is useful for moving work from staging to production. It is generated data rather than maintainable source code, so larger changes are better written as a proper module. --- ## Upgrading to Odoo 19 from Odoo 16, 17 or 18 - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/upgrading-to-odoo-19-from-16-17-18 - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, Odoo upgrade, Migration, Custom modules How an upgrade to Odoo 19 works: what Odoo's upgrade service converts, what your custom modules need, how to test an upgraded copy and which data to check. You can upgrade a database straight from Odoo 16, 17 or 18 to Odoo 19 in one jump; there is no need to stop at each version in between. Odoo's upgrade service converts the standard apps, their data and your Studio customisations. Your custom and third-party modules are not included: they must be ported to 19 by whoever maintains them before the upgrade can go live. The safe sequence is always the same: upgraded test copy, fixed modules, thorough testing, a full rehearsal, then production. This is part 36 of our Odoo 19 guide. If you are still deciding whether to move now or wait for Odoo 20, read our decision guide first. ## Why upgrade to Odoo 19 now Support dates set the pace. Odoo gives each major version three years of standard support. Odoo 16 left standard support in September 2025. Odoo 17 is scheduled to leave it in September 2026, which is now. Odoo 18 runs to September 2027 and Odoo 19 to September 2028. Beyond standard support, Odoo.sh and on-premise customers can buy extended support for an extra fee; Odoo Online does not offer it and upgrades databases on its own schedule. The smaller the version gap, the easier the upgrade. A jump from 16 to 19 is possible in one step, but it carries three years of changes to views, models and workflows, and your custom modules and your users both have to absorb all of them. ## What Odoo's upgrade service does and does not cover With an Enterprise subscription, upgrading to the latest version is included. Odoo's service-level agreement covers: - all standard applications and their data; - Studio customisations , as long as Studio is still installed and the subscription is active; - customisations covered by a maintenance of customisations subscription. It explicitly does not cover cleaning up existing data or configuration, upgrading in-house or third-party modules (including those written by Odoo partners) without a maintenance contract, or training your users. An upgrade also never changes edition or hosting: moving from Community to Enterprise, or from on-premise to Odoo Online, is a separate project. ## Getting an upgraded test copy You always start with a test upgrade. How you request it depends on hosting: - Odoo Online: the database manager at odoo.com/my/databases, Manage, then Upgrade, with Purpose set to Test. - Odoo.sh: request the upgrade on a staging branch. The latest daily production backup is upgraded and loaded, and every commit you push restores the upgraded copy and updates your custom modules, so you test against a clean copy each time. - On-premise: run Odoo's upgrade script on the database server, or upload a dump at upgrade.odoo.com. ``` $ python <(curl -s https://upgrade.odoo.com/upgrade) test -d mydb -t 19.0 # later, for the real thing $ python <(curl -s https://upgrade.odoo.com/upgrade) production -d mydb -t 19.0 ``` On-premise upgrade requests. The server must reach Odoo on port 443 and on a high port range. On-premise, the database goes to Odoo without its filestore. What comes back is a dump.sql and a filestore folder of new files, which you must merge with your production filestore before restoring. Skip that and attachments go missing in the test copy. When the upgrade finishes, Odoo also sends an upgrade report, which is posted in Discuss for administrators. Read it; it lists what changed. Test copies are neutralised: scheduled actions are disabled, outgoing mail servers are replaced with a fake one, payment providers and delivery carriers are switched to test mode, and bank synchronisation is off. That protects your customers, but it also means scheduled jobs and bank feeds must be tested deliberately. ## What custom modules need for Odoo 19 Odoo's documented process for customised databases has six steps: stop development and challenge each customisation, request an upgraded database, make your modules install on an empty 19 database, make them work on the upgraded database, test and rehearse, then upgrade production. The first step is the one teams skip. Odoo 19 may now do natively what you built in 16, and removing a module is cheaper than porting it. From reading the 19.0 source, these are the changes that break the most custom code coming from 16, 17 or 18: - Contracts moved into Employees. The separate hr_contract module is gone; wage and contract dates now live on the hr.version model in the Employees app. Anything that extended contracts, including payroll customisations, needs rework. - Product packagings removed. Packagings are now units of measure listed on the product's Packagings field. Code and imports that used product packagings need rewriting. - User and group fields renamed. A user's groups are now group_ids , and groups are organised under the new res.groups.privilege model. Security XML and code that assigns groups usually needs updating. - Controller and API changes. @route(type='json') is a deprecated alias for type='jsonrpc' . The external /xmlrpc , /xmlrpc/2 and /jsonrpc endpoints are deprecated; Odoo's documentation schedules their removal for Odoo 22 (fall 2028), with the JSON-2 API at /json/2 as the replacement. Integrations will keep working on 19, but plan the move. - Platform minimums. Python 3.10 and PostgreSQL 13 at least. Coming from 16, check your server before anything else. > Every custom module you retire before an upgrade is one you never have to port, test or pay for again. ## Testing the upgraded database and checking the data Test with the people who do the work, not only the implementer. Run full flows end to end: a purchase received into stock and billed, a sale delivered, invoiced and paid, a credit note, a payroll run, a website order. Check that reports and email templates render, that your saved filters still exist, and that integrations and automated actions behave. Odoo's own checklist also asks whether any views active in production are deactivated in the test copy, which is a quick way to find broken customisations. - Freeze a reference date. Take figures from production at the moment the test dump was made. - Compare the finance numbers. Trial balance, receivable and payable ageing, bank balances, and for Indian companies GSTR-1 and GSTR-3B figures for the last closed period. They should match to the rupee. - Compare stock. Quantity on hand and inventory valuation per warehouse, and a sample of products checked against production: category, cost, routes, vendors. - Count the open work. Open quotations, sales and purchase orders, pending deliveries and receipts, unpaid invoices, active subscriptions. - Rehearse the whole go-live. Request a fresh test upgrade shortly before the date, repeat it end to end, and time it so you know how long production will be down. On go-live day, production is unavailable while it upgrades, and on Odoo Online there is no reverting afterwards. Schedule it for a quiet period, never during month-end or a GST filing week, and tell users what will look different on Monday. If you would like the whole upgrade handled for you, including porting custom modules and the data checks above, see our Odoo upgrade service . The final part of this guide, part 37 , brings the whole series together. ## Questions we get asked **Q: Can I upgrade directly from Odoo 16 to Odoo 19?** Yes. Odoo's upgrade service can take a database from any supported version straight to Odoo 19 in one request, without stopping at 17 and 18. The standard apps, data and Studio customisations are converted for you. Custom and third-party modules still need their code ported to Odoo 19 before the upgraded database can go into production, and a bigger version gap means more to test. **Q: Is the Odoo upgrade free?** For Odoo Enterprise customers, upgrading to the latest version is included in the subscription, covering standard apps, data and Studio customisations. It does not include in-house or third-party custom modules unless they are under a maintenance of customisations subscription, nor data clean-up or training. Community databases are not covered by Odoo's upgrade service; they use OpenUpgrade or a partner. **Q: How long does an Odoo upgrade take?** It depends on database size and customisation. The technical upgrade of the database is often hours, but the full project, including porting custom modules, testing and a rehearsal, typically takes weeks. The only reliable way to know your production downtime is to time a full rehearsal with a fresh test upgrade shortly before go-live and plan around that figure. **Q: What happens to custom modules when upgrading to Odoo 19?** They are not upgraded automatically. Whoever maintains them must make them install on an empty Odoo 19 database, then work on the upgraded copy of your data. Common Odoo 19 breakages include the removal of the hr_contract module and product packagings, the rename of user groups to group_ids, and deprecated JSON routes. Retiring modules that Odoo 19 now covers is often cheaper. --- ## Running an integrated business on Odoo 19: how the apps connect and the order to roll them out - URL: https://hadoopt.com/blog/odoo-19-complete-guide-for-businesses/odoo-19-integrated-business-wrap-up - Published: 2026-09-22 - Category: Odoo 19: Complete Guide for Businesses - Tags: Odoo 19, ERP implementation, Rollout, Accounting How Odoo 19 apps connect in one database, from quote to payment, timesheet to invoice and payroll to ledger, and a phased rollout order that works. Odoo 19 works as one system because every app writes to the same database: a quotation becomes a sales order, the order creates a delivery, the delivery drives the invoice, the payment reconciles it, and the accounting reports read the resulting journal entries without any export. The same pattern links timesheets to invoices and payslips to the general ledger. Roll it out in phases, starting with accounting foundations and order-to-cash, and leave the website, marketing and Studio for last. This post closes the series. It traces the main flows across apps and links back to the part that covers each one in detail. ## Order to cash: quote, delivery, invoice, payment, reports For a business selling stocked products, the chain looks like this: ``` Quotation / Sales order S00042 → Delivery order WH/OUT/00017 → Customer invoice INV/2026/00031 → Payment matched on the bank statement → Reports aged receivables, P&L, GST returns ``` The standard order-to-cash chain in Odoo 19. Numbering follows each journal and warehouse sequence. The link that matters most is the product's Invoicing Policy : Ordered quantities lets you invoice as soon as the order is confirmed, Delivered quantities only invoices what has actually shipped. Choose deliberately; changing it later means explaining partial invoices to customers. On the invoice, the Pay button records a payment, and bank reconciliation matches it to the statement line. Inventory valuation feeds the ledger according to the product category's Inventory Valuation setting, which in Odoo 19 is Periodic (at closing) or Perpetual (at invoicing) . - Quotations and orders: part 7 , products and pricelists: part 8 - Inventory and delivery: part 12 - Invoicing and payments: part 19 , bank reconciliation: part 21 The purchase side mirrors it: purchase order, receipt, vendor bill, payment. The product's Control Policy , On ordered quantities or On received quantities , decides whether a bill can be validated before goods arrive. For most trading businesses, received quantities is the safer default. See part 13 and part 20 . Manufacturers add one more link. A sales order or a reordering rule creates a manufacturing order, which consumes components from stock and produces the finished product, and the component and finished-goods moves are valued through the same inventory accounting as any delivery. Quality checks and maintenance hang off the same records rather than a separate system. See part 14 and part 15 . ## Services: project, timesheet, invoice A services business runs a parallel chain. A service product on a sales order creates a project or task, according to its Create on Order setting. Employees log timesheets on those tasks. Depending on the Service Invoicing Policy , hours become the delivered quantity, milestones release a percentage, or the price is fixed. The invoice then goes through the same payment and reconciliation steps as any other. Every timesheet is also costed at the employee's hourly cost on the project's analytic account, so the project's profitability panel shows revenue against labour and bills without a spreadsheet. Details are in part 30 and part 31 . Expenses can be re-invoiced to customers through the same sales order, using the product's Re-Invoice Costs option (At cost or Sales price), as covered in part 28 . ## People: time off, payroll and the general ledger On the HR side, employee records (which in Odoo 19 hold contract details directly on the employee), time off and attendance feed payroll (Enterprise). With Payroll Accounting installed, confirming payslips posts an accounting entry in the Salary Journal of the salary structure. Indian Payroll ( l10n_in_hr_payroll , Enterprise) provides the Indian salary rules on top. The Batch Account Move Lines setting merges a period's payroll entries into single lines per account. It keeps individual salaries out of the general ledger view, at the cost of disabling per-employee payment generation. Decide this with finance before the first payroll run. See part 24 , part 26 and part 27 . ## Why one database changes month-end The practical benefit of integration shows at closing. Receivables, payables, stock value, payroll cost and GST all come from journal entries created by the operational apps, so month-end becomes reviewing and reconciling rather than importing and re-keying. That is the main difference from running Tally for accounts alongside separate sales, stock and HR tools. It only works if the operational teams use the system properly. A delivery validated late, or a vendor bill entered without its purchase order, shows up as a reconciliation problem in finance. Closing, assets and reports are covered in part 23 , and India-specific GST in part 22 . > Integration does not remove work; it moves it to the person who knows the facts, at the moment they happen. ## A phased rollout order for Odoo 19 Trying to go live with every app at once is the most reliable way to go live with none of them working well. The order we usually recommend: - Foundations : company, users and access rights, chart of accounts, taxes and GST, opening balances ( part 4 , part 18 ). - Order to cash and procure to pay : CRM, sales, purchase, inventory, invoicing and bank reconciliation. - Operations : manufacturing, quality, field service or helpdesk, depending on the business ( part 14 onwards). - People : employees, time off, attendance, expenses, then payroll after one parallel run against your current system. - Projects and services : projects, timesheets and service billing. - Customer-facing and extras : website, eCommerce, marketing, Documents, Sign, Knowledge, then Studio for the gaps that remain. Each phase should run for at least one full month-end before the next one starts. Services businesses can swap phases 2 and 5. If you are coming from an older Odoo version rather than starting fresh, read part 36 on upgrading first, and if you are new to the series, start at part 1 . When you are ready to plan your own rollout, our Odoo implementation team can help with phasing, data migration from Tally or spreadsheets, and cut-over. Or simply get in touch . ## Questions we get asked **Q: How do Odoo 19 apps share data with each other?** All Odoo apps in a database use the same records. A customer, product or employee exists once, and each app adds its own documents to it. Confirming a sales order creates the delivery; validating the delivery makes quantities invoiceable; posting the invoice creates journal entries that the accounting reports read directly. No exports or integrations are needed between Odoo's own apps. **Q: In what order should we implement Odoo modules?** Start with foundations: company, users, chart of accounts and taxes. Then implement order to cash and procure to pay, meaning sales, purchase, inventory, invoicing and bank reconciliation. Add operations apps such as manufacturing or helpdesk next, followed by HR and payroll, then projects and timesheets. Leave the website, marketing, Documents and Studio until the core flows have survived at least one month-end. **Q: Does Odoo payroll post to the general ledger automatically?** Yes, with the Payroll Accounting module, which is Enterprise like Payroll itself. Confirming payslips creates an accounting entry in the salary structure's Salary Journal, using the accounts set on the salary rules. The Batch Account Move Lines setting can merge a period's entries into single lines per account, which hides individual salaries in the ledger but disables per-employee payment generation. **Q: Can Odoo replace Tally for an Indian business?** For many small and mid-sized Indian businesses, yes. Odoo 19's Indian localisation provides the Indian chart of accounts and GST taxes, with e-invoicing, e-way bill and GST return features in additional Indian modules, some of them Enterprise. Odoo also connects accounting to sales, purchase, inventory and payroll in one database. The migration needs planning: opening balances, open invoices and stock valuation should be moved at a clean period end, ideally the start of a financial year or quarter. --- ## Comparing Odoo 18 and Odoo 19: Key Differences and Features - URL: https://hadoopt.com/blog/odoo-vs-odoo/comparing-odoo-18-and-odoo-19-key-differences-and-features - Published: 2026-09-22 - Category: Odoo vs Odoo - Tags: Odoo 18, Odoo 19, Odoo comparison, Odoo upgrade What changed from Odoo 18 to Odoo 19: the AI app, units of measure, inventory valuation, expenses, contracts, the JSON-2 API, and whether to upgrade now. Odoo 19, released in September 2025, is a bigger step from Odoo 18 than its interface suggests. The headline addition is a built-in AI app (Enterprise). The changes that matter most in an upgrade sit underneath: units of measure lose their categories, inventory valuation is simplified, expense reports are gone, employee contracts become versions on the employee record, and a new JSON-2 API replaces XML-RPC and JSON-RPC, which are now deprecated. Most Odoo 18 users should plan the move before Odoo 18 leaves standard support in September 2027. This post continues our version-by-version series after Odoo 17 vs Odoo 18 . We have kept to changes we could trace to Odoo's official 19 release notes and to the 19.0 source code. ## Odoo 18 vs Odoo 19 at a glance ## What changes in the interface and AI Interface work in Odoo 19 is about speed, not a redesign. Data fetched while browsing is cached, so returning to a view loads from the cache, and the search bar and view switcher are usable before the records arrive. Numeric dates give way to abbreviated ones. Blocking messages on products and contacts have been removed; only warnings remain, and they appear at the top of the screen instead of as pop-ups. Customers are no longer added as followers; Odoo suggests the recipients of earlier messages instead. The larger addition is the AI app, an Enterprise module with a family of integrations ( ai_fields , ai_server_actions , ai_documents , ai_crm , ai_livechat , ai_website and others). You can chat with agents that answer from your documents, Knowledge articles and web pages, fill fields with AI, use AI inside server actions, and type a search in plain language for Odoo to turn into a filter. The release notes list ChatGPT 5.0, and your own Gemini account, as providers. We cover setup, permissions and cost control in AI in Odoo 19 . ## How sales, products and inventory changed Quotations. Sections and sub-sections now work on quotations, sales orders and invoices. A section's prices can be hidden, or its lines collapsed so the customer sees only the total. The separate optional products tab is gone: a section can be marked optional instead, and portal customers choose quantities for those lines themselves. If your sales team used optional products for upsells, rebuild those templates as optional sections. See quotations and sales orders in Odoo 19 . Units of measure. UoM categories have been removed, and product packagings merged into units. A unit now points to a Reference Unit and says how many of it it Contains , so a "Box of 12" is simply a unit that contains 12 Units. Expect this to affect imports and custom code. Details are in products, variants and pricelists . Inventory. Valuation has been simplified. The options are now "Periodic (at closing)", where Odoo suggests the entries in the valuation report, and "Perpetual (at invoicing)", where an entry is posted when a product is billed or invoiced. The company sets a default, product categories can override it, and there is a new closing interface and support for backdated transfers. Several default virtual locations are gone. Reordering rules gain a horizon (365 days by default) and a deadline showing the latest date to reorder. Read inventory and warehouse management before you configure valuation on the upgraded copy. Purchase. The "Done" status is replaced by a lock/unlock flag. The purchase catalog suggests quantities from past sales and demand. See purchase and vendor management . ## What is new in Odoo 19 accounting Fiscal positions work differently. Tax mappings on the fiscal position have been removed. Each tax now declares which fiscal positions it applies to and which taxes it replaces, and Odoo picks fiscal positions by sequence. If you maintain custom fiscal positions, review them on the test copy. Other changes finance teams will meet in the first week: - Purchase and sales receipts are merged into bills and invoices; you switch between bill and receipt on the form. - Users with only invoicing rights can post invoices, but those moves are flagged "To review" for accountants. - Bank reconciliation has a simpler screen, keyboard shortcuts, and can reconcile draft entries. - A tax return feature tracks filing obligations and deadlines, and a follow-up report separates overdue invoices from due ones. For India, the release notes list improved GSTR-1 reporting (supply types are locked on posting and stored on journal items), a simplified GST return process, a one-click TDS report and an ESIC report in payroll. We go through them in GST and India compliance in Odoo 19 and accounting setup . ## What changes in HR, payroll and expenses HR sees the deepest structural change. Employees and contracts have been merged : there is no separate hr_contract module, and contract terms live as versions ( hr.version ) on the employee record; a salary or schedule change becomes a new version. Reports, Studio views and custom code built on contracts must be reworked. See employees and HR records . Expense reports have been removed. Each expense now moves through its own states (draft, submitted, approved, posted, paid). Managers can still approve or post many at once from the list, and posting several employee-paid expenses creates one bill per employee. Approval habits built around monthly reports need rethinking; our expenses post covers the new flow. Elsewhere in HR: - Attendances : overtime rulesets define what counts as extra hours and how it is compensated. See time off and attendance . - Payroll (Enterprise): batches are now Pay Runs and net salary can be split across several bank accounts. See payroll for India . ## What developers and integrators need to know The external API is the change with a deadline attached. Odoo 19 introduces JSON-2 : HTTP requests to /json/2// , authenticated with an API key sent as a bearer token. The old /xmlrpc , /xmlrpc/2 and /jsonrpc endpoints still work in 19 but are deprecated, and Odoo's 19.0 documentation schedules their removal for Odoo 22 (fall 2028). Move integrations to JSON-2 while you are touching them anyway. ``` POST https://your-db.odoo.com/json/2/res.partner/search_read Authorization: bearer Content-Type: application/json {"domain": [["is_company", "=", true]], "fields": ["name"]} ``` A JSON-2 call: the model and method are in the URL, the API key in the header. Custom modules usually break on the model changes above: hr.version in place of contracts, the missing hr.expense.sheet , UoM without categories, and the removed quotation option lines. On users, the groups field is now group_ids , organised through a new privileges model ( res.groups.privilege ). Odoo 19 runs on Python 3.10 to 3.13 and needs PostgreSQL 13 or later, so check your server before you install; see installing Odoo 19 . ## Should you upgrade from Odoo 18 to Odoo 19? Odoo gives each major version three years of standard support: Odoo 18 until September 2027, Odoo 19 until September 2028 (planned). The year between those dates is your planning window, not spare time. We usually take clients through these steps: - List what you depend on. Custom modules, third-party apps, Studio changes and every integration that calls Odoo. Mark those touching contracts, expenses, units of measure, quotation options or the RPC endpoints. - Request an upgraded test copy. Odoo's upgrade service converts standard apps and data; custom modules must be ported by whoever maintains them. Our upgrade guide explains the process. - Check the finance data first. Stock valuation, fiscal positions, open expenses and payroll are where a wrong number costs most. - Retrain on the changed flows. Quotation sections, single-expense approval, employee versions and Pay Runs all look different to users. - Rehearse, then go live. Run the full upgrade again on fresh data, time it, then schedule production. Switch on AI afterwards. If you are still on Odoo 16 or 17, you can go straight to 19 in one jump; the reasons are in upgrade to Odoo 19 now or wait for Odoo 20 . For a scoped estimate, upgrade.hadoopt.com covers how we run upgrades, or talk to us directly. ## Questions we get asked **Q: What is the biggest difference between Odoo 18 and Odoo 19?** For users, the new AI app in Odoo 19 Enterprise is the most visible change. For an upgrade, the structural changes matter more: units of measure without categories, simplified inventory valuation, expense reports removed, employee contracts merged into versioned employee records, and a new JSON-2 external API that replaces the now-deprecated XML-RPC and JSON-RPC endpoints. These drive retraining and custom-module work. **Q: Is AI available in Odoo 19 Community?** No. The core AI module in Odoo 19 is licensed as Enterprise (OEEL-1), and its integrations for fields, server actions, documents, CRM and live chat all depend on it. Community users do not get AI agents, AI fields or natural-language search out of the box. You can still connect Community to an external AI service through custom development, using the JSON-2 API or a custom module. **Q: Will my Odoo 18 integrations still work on Odoo 19?** Integrations that use XML-RPC or JSON-RPC still work on Odoo 19, because those endpoints are deprecated rather than removed. Odoo's 19.0 documentation schedules their removal for Odoo 22, planned for fall 2028. Integrations that read contracts, expense reports, UoM categories or quotation optional products will break regardless, because those models changed. Test every integration against an upgraded copy before going live. **Q: How long is Odoo 18 supported?** Odoo 18 is covered by standard support until September 2027, three years after its release. Odoo 19, released in September 2025, is planned to be supported until September 2028. After standard support ends, Odoo.sh and on-premise customers can buy extended support for an extra fee; Odoo Online databases are upgraded on Odoo's own schedule instead. **Q: Can I upgrade directly from Odoo 18 to Odoo 19?** Yes. With an Enterprise subscription, Odoo's upgrade service converts your standard apps, data and Studio customisations to Odoo 19. Custom and third-party modules are not included and must be ported to 19 by their maintainers. The safe order is an upgraded test copy, fixed modules, testing by the people who use each app, a full rehearsal, then the production upgrade. --- ## Choosing a mobile app framework: native, Flutter, React Native, KMP or web - URL: https://hadoopt.com/blog/mobile-app-development/choosing-a-mobile-app-framework - Published: 2026-09-22 - Category: Mobile app development - Tags: Mobile app development, Cross-platform, Flutter, React Native, Kotlin Multiplatform, Mobile architecture Native, Flutter, React Native, Kotlin Multiplatform or Ionic/Capacitor and PWAs: how they differ and which one to pick in which situation. There is no best mobile framework, only a best fit for your team and your constraints. For most business apps that need iOS and Android from one team, Flutter or React Native is the sensible default: Flutter when you want one consistent UI and strong offline behaviour, React Native when you already have React and TypeScript developers. Go native (Swift and Kotlin) when the device or platform is the product, pick Kotlin Multiplatform when you want native UI with shared logic, and use Ionic, Capacitor or a PWA when the app is mostly forms and content your web team can already build. The rest of this post is the reasoning behind that paragraph, a comparison table, and the order in which we ask the questions when a founder or product owner asks us what to build with. ## The five ways to build a mobile app today Native. Two apps: Swift with SwiftUI for iOS, Kotlin with Jetpack Compose for Android. Each uses the platform's own tools and gets new operating system features first. You pay for it with two codebases and, usually, two sets of skills. Flutter. One codebase in Dart. Flutter draws every pixel itself with its own rendering engine (Impeller on iOS and modern Android), so the app looks and behaves the same on both platforms. Details in Flutter: when to choose it . React Native. One codebase in TypeScript or JavaScript, written with React. Your components become real native views. Since version 0.82 it runs only on the New Architecture, and the React Native team recommends starting through a framework, which in practice means Expo. See React Native: when to choose it . Kotlin Multiplatform (KMP). Shared Kotlin code for business logic, networking and storage, with either native UI on each platform or shared UI through JetBrains' Compose Multiplatform, which has been stable on iOS since 1.8.0. See Kotlin Multiplatform: when to choose it . Web technology: Ionic, Capacitor or a PWA. HTML, CSS and JavaScript, either wrapped in a native shell with Capacitor (optionally with Ionic's UI components) or installed from the browser as a progressive web app. See Ionic, Capacitor and PWAs: when web tech is enough . ## How the options compare Two things the table does not show. First, every option here is used for serious production apps; the differences are in fit, not in whether it is "real". Second, the backend, the API and the data model usually take more effort than the choice of UI framework, and they do not change whichever you pick. ## What actually decides the choice We rarely decide on technical preference. These are the questions that settle it, roughly in order of weight. - Who will maintain it. An app lives for years. A framework your team, or the team you can hire in your city, can maintain beats a slightly better one nobody around you knows. - How much the device matters. Bluetooth peripherals, background location, camera pipelines, widgets, watch apps and payment hardware all push towards native, or at least towards writing native modules alongside a cross-platform app. - Offline requirements. A field technician in a basement or on a rural site needs a local database, a sync queue and conflict rules. Every framework can do it; the work is in the architecture, covered in offline-first mobile apps and sync architecture . - How native it must feel. A banking or consumer app judged against Apple's and Google's own apps benefits from native controls. An internal inspection app mostly needs to be fast and clear. - What exists already. An existing native app, a React web app or a Kotlin backend each tilts the decision towards the tool that reuses it. ## A decision sequence by situation This is the order we walk through with clients. Stop at the first step that clearly applies. - Is it mostly forms, lists and content, used by staff or known customers? If your web team can build it and the app does not need heavy background work, start with a PWA or a Capacitor-wrapped web app. It is the cheapest thing to maintain. - Is the device itself the product? Hardware integration, advanced camera or audio, platform features such as widgets or wearables at launch: build native, Swift and Kotlin. - Do you already have native apps? Keep them native. Add Kotlin Multiplatform for shared logic, or Flutter or React Native for new self-contained screens, rather than rewriting. - Is your team strong in React and TypeScript, or do you share code with a React web app? Choose React Native with Expo. - Is your team Android and Kotlin first? Choose Kotlin Multiplatform, with Compose Multiplatform if you are happy to share the UI too. - Starting fresh with one small team, a branded UI and offline needs? Choose Flutter. The sequence is deliberately blunt. Real projects mix answers, and a mixed answer usually points to a combination: a Flutter app with two native modules, or native apps sharing a KMP core. ## What we pick for field apps and customer apps Much of our mobile work is offline-first field apps for technicians, sales teams and warehouse staff, often talking to Odoo, plus customer-facing apps for ordering, bookings and account self-service. For field apps with one team building both platforms, our default is Flutter: one UI that behaves identically on the mixed Android devices field teams tend to carry, good local databases, and predictable rendering. Where the client's developers are React people, React Native with Expo is an equally good answer. Mobile apps for Odoo field teams covers what those apps need from the ERP side. For consumer apps where polish on iOS matters and the budget allows two teams, native is still the benchmark, described in native iOS and Android: when to go native . What moves the budget either way is explained in what drives mobile app cost and timeline , and the last mile is in releasing to the App Store and Google Play . If you are weighing options for a specific app, write down who will maintain it, what it must do offline and which device features it needs, then read the post for your top two candidates. Or bring that list to us through mobile app development or contact , and we will talk it through. ## Questions we get asked **Q: Is Flutter or React Native better for a business app?** Neither is better in general. Flutter suits teams starting fresh who want one consistent, branded UI and strong offline behaviour, because it draws its own interface. React Native suits teams that already write React and TypeScript, or want to share code and people with a React web app. Both produce production-quality iOS and Android apps from one codebase. **Q: When should I build separate native iOS and Android apps?** Build native when the device or platform is central to the product: deep hardware integration, advanced camera or audio, widgets and wearables, or new operating system features on release day. Native also makes sense for large consumer apps that can fund two specialised teams. For most internal and business apps, a cross-platform framework is enough. **Q: Can a PWA replace a mobile app?** For many internal tools, forms and content apps, yes. A progressive web app installs from the browser, works offline with a service worker and needs no store review. It is weaker for background tasks, deep device access and some iOS behaviour. If you need store distribution with web code, Capacitor wraps the same web app as a native app. **Q: What is Kotlin Multiplatform used for?** Kotlin Multiplatform shares Kotlin code, usually business logic, networking and local storage, between Android, iOS and other platforms, while each app can keep a native UI. With JetBrains' Compose Multiplatform, which is stable on iOS, you can share the UI as well. It suits Android-first teams and companies with existing native apps. **Q: Does the framework choice affect offline support?** Less than people expect. Native, Flutter, React Native and Kotlin Multiplatform all have mature local databases and background sync options. The hard part is the sync design: what is stored on the device, how changes queue while offline, and how conflicts are resolved. Web apps can work offline too, with more limits on storage and background work. --- ## Flutter: when to choose it for your mobile app - URL: https://hadoopt.com/blog/mobile-app-development/flutter-when-to-choose-it - Published: 2026-09-22 - Category: Mobile app development - Tags: Flutter, Dart, Cross-platform, Mobile architecture Where Flutter is the right choice for a business app, where it is not, and what to settle before the first sprint, as Flutter stands in 2026. Choose Flutter when one team needs to ship the same app to iOS and Android, the design is your own brand rather than stock iOS or Android controls, and the app has to behave predictably across many devices, including offline. Do not choose it when the product depends on the newest platform features on release day, when native look and feel is the selling point, or when your team is already strong in React or native development and would rather stay there. That is the short version. Below is how Flutter works, where it shines, where we would not use it, and the decisions that are worth settling before anyone writes a widget. ## How Flutter draws the screen Flutter apps are written in Dart. The important difference from most other options is how the interface gets onto the screen: Flutter does not ask iOS or Android to draw buttons and lists. It draws every pixel itself with its own rendering engine, Impeller. On iOS, Impeller is the only supported renderer; on Android it is the default on API level 29 and newer, with a fallback on older devices. ``` flutter create field_app cd field_app flutter run ``` A new Flutter project, run on a connected device or simulator. Two consequences follow, and they explain most of Flutter's strengths and weaknesses. - Consistency. The app looks and behaves the same on a three-year-old budget Android phone and a new iPhone, because Flutter, not the operating system, is doing the drawing. Testing one platform catches most UI problems on the other. - Imitation, not inheritance. When Apple or Google change their design language, native apps pick it up when rebuilt. Flutter's Material and Cupertino widgets are re-implementations, so they follow when Flutter's own libraries catch up. That second point is being addressed structurally. With Flutter 3.47 (August 2026), the standalone material_ui and cupertino_ui packages reached 1.0, so the design libraries can be updated on their own schedule rather than waiting for the quarterly SDK release. Existing projects have a migration tool, and the old in-framework widgets are scheduled for deprecation. ## Where Flutter is the right choice One small team, two platforms. A single codebase for UI and logic means one set of screens, one test suite and one release rhythm. For most business apps, this is where the savings come from. Branded apps. If the designer has produced a custom look rather than "an iPhone app and an Android app", Flutter builds that look once and it holds everywhere. Custom charts, animated flows and unusual layouts are comfortable territory. Field and offline apps. Technicians, delivery staff and sales reps carry a mix of Android devices. Flutter's consistent rendering and mature local database packages suit apps that capture data offline and sync later, which is most of our field work. Adding to an existing app. Flutter's add-to-app lets you build some screens in Flutter inside an existing native app. It is a reasonable way to trial Flutter or to share one new feature across two native apps, with limits: on mobile it runs as separate engines, and you cannot pack multiple Flutter libraries into one app. ## Where we would not pick Flutter The platform is the product. Widgets, watch apps, advanced camera or audio work, and features Apple or Google announce each June and ship each autumn all start life as native APIs. Flutter can reach them through plugins or your own platform channel code, but you are then writing Swift and Kotlin anyway, and waiting for plugins to catch up. Native feel is the selling point. A consumer app judged against Apple's own apps, where every scroll physics detail and system control matters, is easier to get right natively. Flutter can get close; native gets it by default. Your team is somewhere else. Dart is easy to learn for anyone who knows Java, Kotlin, Swift or TypeScript, but a team of strong React developers will be productive sooner in React Native. That usually outweighs any framework advantage. Mostly a website. Flutter can build for the web, and WebAssembly builds are available as an opt-in on the way to becoming the default. But if the product is mainly a content or SEO-driven website, a web framework is the better tool; see PWA vs native app vs responsive website . ## What to settle before the first sprint Flutter gives you a lot of freedom, and freedom is where projects drift. These are the decisions we make up front. - Audit the plugins you depend on. List every device feature the app needs (camera, maps, barcode scanning, background location, push, payments) and check that a maintained package covers it on both platforms. Anything uncovered becomes native module work; better to know on day one. - Pick one state management approach and one architecture. Flutter does not prescribe one. Choose, write down the pattern for a screen, and hold everyone to it. - Design the offline and sync model. Which records live on the device, how edits queue, what happens on conflict. This drives the local database choice, not the other way round. See offline-first mobile apps and sync architecture . - Decide how you track the design libraries. For new projects, start on the material_ui or cupertino_ui packages rather than the widgets being deprecated. - Set up CI and store builds early. Signing, flavours for test and production, and builds for both stores should work in week one, not the week before launch. > The framework rarely sinks a Flutter project. An unplanned plugin gap or an unplanned sync model does. If Flutter looks like your answer, compare it honestly with React Native before committing, and read the overview in choosing a mobile app framework . When you are ready to plan the build, our mobile app development team can help with the architecture or the whole app. ## Questions we get asked **Q: Is Flutter good for enterprise and business apps?** Yes, for most of them. Flutter suits business apps that need iOS and Android from one team, a branded design and consistent behaviour across many devices, including offline field apps. It is a weaker fit when the app depends on the newest platform features at launch or must feel exactly like Apple's own apps, where native development is easier. **Q: Does a Flutter app look native on iOS?** Flutter draws its own widgets rather than using iOS controls, so a Flutter app looks native only as far as its Cupertino widgets imitate iOS. Many teams instead use one branded design on both platforms, which Flutter handles well. The Material and Cupertino libraries now ship as separate packages, so they can follow platform design changes faster. **Q: What language does Flutter use?** Flutter uses Dart, a typed, object-oriented language developed by Google. Developers who know Java, Kotlin, Swift, C# or TypeScript usually pick it up quickly. Device features that Flutter's packages do not cover are written in Swift or Kotlin and called from Dart through platform channels, so some native knowledge helps on larger apps. **Q: Can Flutter apps work offline?** Yes. Flutter apps can store data in a local database on the device, queue changes while offline and sync them when the connection returns. Flutter itself does not decide how sync works; you design which records are stored locally, how edits are queued and how conflicts are resolved. That design matters more than the framework. **Q: Can I add Flutter to an existing native app?** Yes. Flutter's add-to-app feature lets you embed Flutter screens in an existing iOS or Android app while the rest stays native. It is a practical way to trial Flutter or share one new feature across two native apps. On mobile, each Flutter instance runs as a separate engine, and packing multiple Flutter libraries into one app is not supported. --- ## Ionic, Capacitor and PWAs: when web tech is enough for a mobile app - URL: https://hadoopt.com/blog/mobile-app-development/ionic-capacitor-and-pwas-when-web-tech-is-enough - Published: 2026-09-22 - Category: Mobile app development - Tags: Capacitor, Ionic, PWA, Cross-platform, iOS When a PWA or a Capacitor app is the right mobile choice, what iOS web apps can and cannot do in 2026, and where web tech stops being enough. Web technology is enough for a mobile app when the app is mostly forms, lists, dashboards and content, and does not depend on reliable background work or unusual hardware. Start with a progressive web app (PWA) if you do not need an App Store listing; wrap the same code with Capacitor when you need store distribution or native APIs such as the camera, secure storage or proper push notifications. Choose Flutter, React Native or native when the app lives in the background, talks to Bluetooth devices or needs demanding animation. ## What Ionic, Capacitor and a PWA each are - A PWA is a website with a web app manifest and a service worker. Users install it from the browser, it gets an icon, opens without browser chrome and can cache itself for offline use. No store is involved. - Capacitor is a native runtime from the Ionic team. It puts your built web app inside a native iOS and Android project, runs it in the platform web view and gives JavaScript access to native APIs through plugins. The result is a real app binary that goes through the App Store and Google Play. The current major version is Capacitor 8, which made Swift Package Manager the default for new iOS projects; 8.5, released in July 2026, moved iOS apps to Apple's UIScene lifecycle. - Ionic Framework is an optional UI component library that makes web screens look and behave like iOS and Android controls. Capacitor does not require it: React, Vue, Angular or Svelte with your own design system works just as well. So the real decision is two questions: do you need a store listing, and do you need native APIs the browser does not give you? If the answer to both is no, a PWA may be all you need. ## What PWAs can and cannot do on iOS in 2026 Android has supported installable web apps well for years. iOS is where the limits are, and it is where most "can we just do a PWA?" conversations are decided. The current position, checked against WebKit's own release notes: - Installation is manual. There is no automatic install prompt in Safari; users add the site through the Share menu and Add to Home Screen. Since iOS 16.4, Chrome, Edge and Firefox on iOS can add web apps to the Home Screen as well. - Any site opens as a web app. Since Safari 26 (iOS 26), a site added to the Home Screen opens as a web app by default, even without a manifest. - Web push works, with conditions. Since iOS 16.4, Home Screen web apps can receive push notifications and set badge counts. The user must install the app first and grant permission from a tap inside it. A site open in a Safari tab cannot ask. - Offline works through service workers , and Safari 27 (released 17 September 2026) added the Service Worker static routing API. Browser storage is still subject to quotas and eviction, so treat it as a cache that can be cleared, not as the only copy of a user's work. - Not available: the Background Sync API, Web Bluetooth, Web NFC and a store listing. Safari 27 did not change any of these. In the EU, Apple briefly removed Home Screen web apps in the iOS 17.4 betas in response to the Digital Markets Act and then reversed the decision, so they work there as elsewhere. ## When a PWA is the right choice We recommend a PWA first when: - The users are your own staff or existing customers who can be sent a link and shown how to install it once. - The app is a mobile face on an existing web product: a customer portal, an approval queue, order tracking, a simple field checklist. - You need to release changes the same day without store review. - Push notifications are useful but not critical, and you can live with users installing before they can receive them. Odoo itself takes this route. Its own documentation recommends the Odoo PWA over its store apps, and the PWA supports push notifications and SSO sign-in. ## When to wrap it with Capacitor Capacitor earns its place when a PWA is nearly right but one of these is a requirement: - Store presence. Consumers look for apps in stores, and some organisations only allow store or MDM-managed apps on company phones. - Reliable push through Apple Push Notification service and Firebase Cloud Messaging, without asking users to install from the browser first. - Native APIs through official or community plugins: camera and photo library, file system, biometrics, secure keychain storage, local notifications, geolocation, barcode scanning, in-app purchases. - A real on-device database such as SQLite through a plugin, instead of browser storage that may be evicted. For offline-first field apps this matters; our post on offline-first sync architecture goes into why. The advantage over rewriting is that the web codebase stays one codebase. The same screens can ship as a website, a PWA and two store apps. When a plugin does not exist, you write a small native plugin in Swift or Kotlin, so you are never completely stuck. Two cautions. First, Apple's App Review Guideline 4.2 asks for apps that are more than a repackaged website; a Capacitor shell around your marketing site will be rejected, while a real app built with web tech is fine. Second, if you relied on Ionic's commercial Appflow service for cloud builds or live updates, Ionic stopped new sales in February 2025 and says Appflow is sunset on 31 December 2027. Plan your builds in your own CI and choose another live-update provider before then. ## When web tech is not enough Web views have improved a great deal, and on a mid-range phone a well-built Capacitor app feels native for ordinary business screens. Where it shows is in gesture-heavy interfaces, very long lists, and anything that has to keep running when the screen is off. If your app's value is in those areas, start with a cross-platform native toolkit; our posts on Flutter and React Native cover when each fits. ## What we would pick, and in what order - Build the web app responsively first , with a service worker for caching and a manifest. That is your PWA and it costs little extra. - Put it in front of real users on their own phones , iPhones included, for a few weeks. Note every request that the browser cannot meet. - If store listing, reliable push or a native API appears on that list, add Capacitor to the same codebase rather than starting over. - If background work, hardware or performance appears on it, move the mobile client to Flutter, React Native or native , keeping the web app for desktop users and the same backend API for both. > Start with the web you already have, and let real iPhone users tell you where it stops. This sequence avoids paying for native work you may never need. If you are weighing these options against a real feature list, our mobile app development team can go through it with you, or read the wider comparison in choosing a mobile app framework . ## Questions we get asked **Q: Do PWAs support push notifications on iPhone?** Yes, since iOS 16.4, but only after the user has added the web app to the Home Screen and granted permission from a tap inside the app. A website open in a Safari tab cannot request push permission on iPhone. Badge counts on the icon are supported too. If you need push to work straight after a user first finds you, a store app built with Capacitor or a native toolkit is the dependable route. **Q: Is Capacitor the same as Ionic?** No. Capacitor is the native runtime that wraps a web app into iOS and Android binaries and exposes native APIs through plugins. Ionic Framework is an optional library of mobile-style UI components. Both come from the same team and are often used together, but Capacitor works with any web stack, including React, Vue, Angular or Svelte with your own components, and Ionic components can run without Capacitor. **Q: Will Apple accept a Capacitor app in the App Store?** Yes, provided it is a genuine app. Apple's guideline 4.2 rejects apps that are little more than a repackaged website, so a wrapper around a marketing site will struggle. An app with real features, offline behaviour, native integrations such as camera or push, and a proper account flow is reviewed like any other. The technology used to build the interface is not the test; usefulness is. **Q: Can a PWA work offline on iOS?** Yes. A service worker can cache the app's code and data so it opens and works without a connection. What iOS does not support is the Background Sync API, so changes made offline are only sent when the user opens the app again. Browser storage can also be cleared under storage pressure, so important unsent work should be synced promptly or kept in a Capacitor app's on-device database. --- ## Kotlin Multiplatform: when to choose it, and where Compose Multiplatform stands on iOS - URL: https://hadoopt.com/blog/mobile-app-development/kotlin-multiplatform-when-to-choose-it - Published: 2026-09-22 - Category: Mobile app development - Tags: Kotlin Multiplatform, Compose Multiplatform, Kotlin, Cross-platform, Mobile architecture When Kotlin Multiplatform and Compose Multiplatform fit a mobile app in 2026, their stability on iOS today, and how to adopt KMP one module at a time. Choose Kotlin Multiplatform (KMP) when your team is strong in Kotlin, when you already have native Android and iOS apps and want to stop writing the same logic twice, or when you want native UI on each platform with one shared core. Add Compose Multiplatform if you also want to share the UI; it has been stable on iOS since release 1.8.0 in May 2025. Look elsewhere when you have no iOS developers willing to work with Kotlin, or when a React or web team would be more productive in React Native or Flutter. KMP is the option with the most "it depends" in it, because it lets you choose how much to share. This post explains what it shares, where Compose Multiplatform stands on iOS today, and how we would introduce it. ## What Kotlin Multiplatform shares, and what it does not KMP compiles Kotlin code for several targets: for Android it is ordinary Kotlin on the JVM; for iOS it compiles to native code that Swift can call. The core technology is stable on Android, iOS and desktop JVM, and Google states that it officially supports KMP for sharing business logic between Android and iOS. A KMP project puts shared code in a common source set and platform-specific code alongside it. ``` shared/src/commonMain/kotlin # logic for every platform shared/src/androidMain/kotlin # Android-specific implementations shared/src/iosMain/kotlin # iOS-specific implementations ``` The usual source set layout of a shared KMP module. What typically goes into the shared module: - Data models, validation and business rules. - Networking and API clients. - Local storage and offline sync logic. Several Jetpack libraries now support KMP, including Room, DataStore, ViewModel, Lifecycle and Navigation. - Calculations that must match on both platforms: pricing, tax, scheduling rules. The UI is the choice you make on top. Either each platform keeps its own native UI (SwiftUI on iOS, Jetpack Compose on Android), or you share the UI too with Compose Multiplatform. ## Compose Multiplatform on iOS today Compose Multiplatform is JetBrains' port of Jetpack Compose to other platforms. Its status as it stands now: Stable does not mean identical to native. On iOS, Compose Multiplatform draws its own UI rather than using UIKit controls, much as Flutter does, so native feel depends on how well its components mimic iOS. JetBrains keeps closing the gaps: release 1.11 (May 2026) added an experimental native text input built on UIKit's UIView , for native caret movement, gestures and system menus. Treat text-heavy screens and platform-specific interactions as the places to test first. A second detail matters to your iOS developers. Kotlin code is exposed to Swift through Objective-C headers today. The newer Swift export , which exposes Kotlin to Swift directly and more idiomatically, is still Alpha, with breaking changes expected. It is fine to prototype with; we would not build a production release process on it yet. ## Where Kotlin Multiplatform is the right choice You have native apps already. KMP is the only option here that does not ask you to rewrite. You can move one piece of logic into a shared module, ship it inside both existing apps, and keep going. Your team is Android and Kotlin first. Kotlin developers stay in their language and tools. With Compose Multiplatform, Android developers can build iOS screens with the skills they have. Complex rules that must run on the device. Offline field apps that price, validate or schedule locally need identical results on both platforms. Sharing that code removes a whole class of "the iPhone calculates it differently" bugs. You want native UI but not double logic. For apps where the iOS experience must feel fully native, shared logic with SwiftUI on top keeps the look native and the rules single. ## Where it is not the best fit No iOS buy-in. If there is no one on the iOS side willing to work with a Kotlin module, the project will struggle regardless of the technology. A JavaScript or web-first team. React developers will be productive faster in React Native . One small team, starting fresh, sharing everything. Compose Multiplatform can do it, but Flutter has a longer track record for full UI sharing on iOS and a larger package ecosystem. We would compare the two on your team's skills and your plugin list. ## Adopting KMP one module at a time - Pick one self-contained piece of logic. An API client, a validation library or a pricing engine. Not the UI. - Agree the Swift-facing API with the iOS team. Design how iOS will call it before writing it, and review the generated interface together. - Ship it in both apps. Wire the module into the Android and iOS builds and your CI, and release it. - Move storage and sync next. With KMP-ready libraries such as Room and DataStore, offline data handling is a natural second step. See offline-first mobile apps and sync architecture . - Decide about shared UI last. Try Compose Multiplatform on one new screen on iOS, test it on real devices, and only then decide whether to go further. If KMP sounds right, compare it with fully native apps and read the overview in choosing a mobile app framework . Our mobile app development team can help plan where the shared code should start and stop. ## Questions we get asked **Q: Is Compose Multiplatform stable on iOS?** Yes. JetBrains declared Compose Multiplatform for iOS stable and production-ready with release 1.8.0 in May 2025, and later releases continue to improve it. It draws its own UI on iOS rather than using native controls, so test text input and platform-specific interactions carefully. Web support, based on Kotlin/Wasm, is still in Beta. **Q: What is the difference between Kotlin Multiplatform and Compose Multiplatform?** Kotlin Multiplatform is the technology for sharing Kotlin code, such as business logic, networking and storage, across Android, iOS, desktop and web. Compose Multiplatform is JetBrains' UI framework built on top of it, which lets you share the user interface as well. You can use Kotlin Multiplatform with fully native UIs and never adopt Compose Multiplatform. **Q: Kotlin Multiplatform or Flutter?** Choose Kotlin Multiplatform if your team knows Kotlin, you have existing native apps, or you want native UI with shared logic. Choose Flutter if one team is starting fresh and wants to share the whole UI with a large package ecosystem. Both can share the full interface; the deciding factors are usually your team's skills and your existing code. **Q: Can I add Kotlin Multiplatform to an existing app?** Yes, and that is one of its main strengths. You can move a single piece of logic, such as an API client or a validation module, into a shared Kotlin module and use it from both an existing Android app and an existing iOS app. Nothing else needs to change, and you can expand the shared code gradually. **Q: Does Google support Kotlin Multiplatform?** Yes. Google's Android documentation states that Kotlin Multiplatform is officially supported for sharing business logic between Android and iOS, and describes it as stable and production-ready. Several Jetpack libraries, including Room, DataStore, ViewModel, Lifecycle and Navigation, support Kotlin Multiplatform, so Android developers can reuse familiar libraries in shared code. --- ## Mobile apps for Odoo field teams: standard app or custom build? - URL: https://hadoopt.com/blog/mobile-app-development/mobile-apps-for-odoo-field-teams - Published: 2026-09-22 - Category: Mobile app development - Tags: Odoo 19, Field service, Mobile architecture, Odoo API, Offline-first When Odoo's own mobile app is enough for drivers and technicians, when to build a custom app on the JSON-2 API, and how to handle offline and API keys. For most Odoo field teams with decent mobile signal, Odoo's own progressive web app is enough: Field Service, Barcode, Timesheets, Expenses and Attendances all work on a phone, and Odoo 19 can reopen previously viewed records without a connection. Build a custom app when people must create or change data while offline, when the workflow needs to be much simpler than Odoo's screens, or when devices such as scanners and printers need tight integration. A custom app should call Odoo's JSON-2 API with a dedicated bot user, not the older XML-RPC and JSON-RPC endpoints, which are deprecated. ## What Odoo 19 gives field teams on a phone Odoo offers two mobile apps: a progressive web app installed from the browser, and store apps on Google Play and the App Store. Odoo's documentation recommends the PWA. It supports push notifications and SSO sign-in. The store apps support multiple accounts but, per the same documentation, are not compatible with SSO. The PWA is served by the core web module, so it works on Community as well as Enterprise. The field-relevant apps, and their editions: - Field Service ( industry_fsm , Enterprise): tasks for technicians, with worksheets through Field Service Reports, products used, timers and customer signature. - Barcode ( stock_barcode , Enterprise): receipts, picking, deliveries and counts with a phone camera or a scanning device. - Attendances and Expenses (Community): check-in and check-out, receipt capture and submission. - Point of Sale (Community): the one Odoo app built to keep taking orders when the connection drops, and send them when it returns. Odoo 19 also has an offline mode for the rest of the web client. Views and records that the user opened while online can be reopened without a connection, but, in Odoo's words, they "can be viewed but not modified while offline". Odoo caps this offline data at 2 GB and drops the oldest first, and a hard refresh clears it. ## When a custom app is worth building The standard app is a full ERP client on a small screen, which is both its strength and its weakness. We recommend a custom app when one or more of these is true: - Work happens without signal. Drivers confirming deliveries in basements, technicians in plant rooms, surveyors on farms. They need to complete jobs, capture photos and signatures, and sync later. - The job is three taps, not thirty. A driver needs "next stop, navigate, delivered, signature, photo". - Devices matter. Bluetooth printers for delivery slips, rugged scanners, NFC tags on assets, background location. - The users are not Odoo users. Subcontractors or customers who should see only their own jobs through a branded app. Here, compare with Odoo's portal first; our post on Odoo portal versus a custom build covers that choice. Keep Odoo as the system of record either way. The app is a focused client: jobs, stock moves, timesheets and attachments all land in standard Odoo models, so office staff, invoicing and reporting keep working unchanged. ## Which Odoo API to build on Odoo 19 introduced the JSON-2 API . You send a POST to /json/2// with a JSON body of named arguments, and authenticate with an API key as a bearer token. Any public model method can be called this way, and every call is checked against the user's access rights, record rules and field access. ``` POST /json/2/project.task/search_read Host: mycompany.example.com Authorization: bearer Content-Type: application/json; charset=utf-8 X-Odoo-Database: mycompany (only if the server hosts several databases) {"domain": [["user_ids", "in", [42]]], "fields": ["name", "partner_id", "date_deadline"]} ``` A JSON-2 request, following the pattern in Odoo 19's external API documentation. The older /xmlrpc , /xmlrpc/2 and /jsonrpc endpoints still work in Odoo 19, but they are deprecated. Odoo's current documentation says they are scheduled for removal in Odoo 22 (fall 2028). Anything new should use JSON-2, and existing integrations should be moved when they are next touched. Points that shape the app's design: - Each call is its own transaction. You cannot group several calls and roll them back together. If "complete job" must update the task, record materials and attach a signature atomically, write a small server-side method in a custom module and call that once. - Plan matters on Odoo Online. Odoo's documentation states that external API access is available only on Custom pricing plans, not on One App Free or Standard. On Odoo.sh or your own server this restriction does not apply. Check Odoo's pricing page before designing around the API. - Pull changes efficiently : use write_date as a change cursor and fetch only the fields you need. ## Authentication and API keys API keys are created under the user menu, My Preferences → Security → Add API Key . A key has a description and a duration, and it is shown only once. In Odoo 19, internal users are limited to keys of at most 90 days; Odoo's documentation recommends a short duration, typically one day, for interactive use, and rotation at least every three months for long-lived integration keys. That shapes how a field app should sign in. The two sound patterns: - A small middleware service between the app and Odoo. Users sign in to the middleware, which holds a key for a dedicated Odoo bot user with only the rights the app needs, and exposes a narrow API: my jobs, complete job, upload photo. This is our default for field apps. Keys never reach phones, rotation happens in one place, and the middleware is where the offline sync logic lives. - Per-user keys issued to the device , when each worker is an Odoo user and the app talks to Odoo directly. Store the key in the Keychain or Android Keystore, give it an expiry, and build the re-authentication flow before launch, not after the first key expires in the field. Odoo's documentation recommends dedicated bot users for automated integrations, with minimum permissions and password login disabled. Changes then show the bot as their author, so record which worker made each change in the data itself, for example on the task. ## Offline for drivers and technicians A custom field app earns its cost offline. The design is the one in our offline-first sync architecture post, applied to Odoo: - Download the working set each morning and on every app open: assigned tasks or deliveries, customer addresses and contacts, the products and lots the worker may use. - Record actions as events : arrived, used two units of this product, took this photo, customer signed. Events rarely conflict and map cleanly to timesheet lines, stock moves and attachments. - Let Odoo reject what breaks rules , such as consuming stock that is not there or completing a task reassigned to someone else, and show the reason in the app. - Upload photos and signatures separately as attachments on the record, so a slow upload does not block the job update. If you distribute an Android app to company devices outside Google Play, note that Google's Android developer verification applies to apps on certified devices in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, and globally in 2027. Register your apps before rolling out there. Start by piloting standard Odoo with a few field workers for a couple of weeks and listing exactly where it falls short. That list becomes the app's scope. Our mobile app development and Odoo implementation teams work together on these projects, and you can contact us to go through yours. ## Questions we get asked **Q: Does the Odoo mobile app work offline?** Partly. In Odoo 19, views and records a user opened while online can be reopened without a connection, but they are read-only until the connection returns. Odoo keeps up to 2 GB of this data and removes the oldest first. Point of Sale is the exception: it keeps taking orders offline and syncs them later. For creating or editing other records without signal, a custom offline-first app is needed. **Q: What is Odoo's JSON-2 API?** JSON-2 is the external API introduced in Odoo 19. Clients send a POST request to /json/2/model/method with named arguments in a JSON body, authenticated by an API key in a bearer Authorization header. It replaces the XML-RPC and JSON-RPC endpoints, which are deprecated and, according to Odoo's documentation, scheduled for removal in Odoo 22 in fall 2028. Every call runs in its own database transaction. **Q: Can I use the Odoo API on Odoo Online?** Only on the Custom pricing plan. Odoo's documentation states that external API access is not available on the One App Free or Standard plans. Databases hosted on Odoo.sh or on your own servers can use the API without that restriction. Confirm your plan before designing a mobile app or integration that depends on the external API, because moving plans later changes your licence costs. **Q: How long do Odoo API keys last?** In Odoo 19 every key has a duration chosen when it is created. Internal users can create keys lasting at most 90 days, and Odoo recommends about one day for interactive use. Long-running integrations therefore need to rotate keys at least every three months. Keys are shown only once at creation, so store them in a secrets manager or the device's secure keystore immediately. --- ## Native iOS and Android: when to go native with Swift and Kotlin - URL: https://hadoopt.com/blog/mobile-app-development/native-ios-and-android-when-to-go-native - Published: 2026-09-22 - Category: Mobile app development - Tags: Native apps, Swift, SwiftUI, Kotlin, Jetpack Compose, Mobile architecture When separate Swift/SwiftUI and Kotlin/Jetpack Compose apps are worth two codebases, when they are more than you need, and how to keep them in step. Go native, with Swift and SwiftUI on iOS and Kotlin and Jetpack Compose on Android, when the device or the platform is central to your product: hardware integration, demanding camera, audio or graphics work, widgets and wearables, or new operating system features on release day. It is also the right call for large consumer apps that can fund two specialised teams. For most internal and business apps, native is more than you need, and a cross-platform framework ships the same result with one team. Native development has never been the wrong answer technically. The question is whether its advantages are worth maintaining two apps for years. Here is how we judge that. ## What going native means in practice A native app uses each platform's own language, UI toolkit and tools. Both platforms have converged on the same idea: declarative UI, where you describe what the screen should show for a given state and the toolkit works out the updates. Google describes Jetpack Compose as Android's recommended modern toolkit for building native UI, and Apple continues to put its new UI work into SwiftUI; this year's WWDC26 releases, iOS 27 and Xcode 27, again brought SwiftUI additions such as new toolbar and document APIs. A developer who knows one of SwiftUI or Compose recognises most of the other, although they remain two languages and two ecosystems. ## When native is the right call The device is the product. Bluetooth peripherals, NFC, medical or industrial hardware, custom camera pipelines, AR, low-latency audio. Cross-platform frameworks reach these through native modules, which means you write Swift and Kotlin anyway, plus a layer in between. Platform features on day one. Home screen widgets, watch and car apps, Live Activities, App Intents and system assistant integration, new design language changes. They arrive as native APIs first; cross-platform support follows, sometimes months later. Native feel is how you compete. Banking, health and consumer apps are judged side by side with Apple's and Google's own apps. Native controls, gestures, accessibility and system behaviour come for free and stay current when you rebuild with a new SDK. You can staff two teams for the long run. Large apps often end up with separate iOS and Android teams whichever technology they start with. If you will have them anyway, native lets each team use the best tools for its platform. Heavy background work and tight performance budgets. Long-running sync, location tracking, large offline datasets and complex rendering are easier to tune when nothing sits between your code and the operating system. ## When native is more than you need Most business apps are screens of lists, forms, detail views, a camera for photos, a barcode scanner, push notifications and an offline cache. Every serious cross-platform framework does all of that well. Building it twice buys very little. - Internal and field apps for technicians, sales teams and warehouse staff, where consistency and reliability matter more than platform polish. - A first version whose job is to test whether customers want the product at all. - Small teams who would otherwise ship every feature twice and test it twice, and keep both apps in step on every release. For these, Flutter or React Native is the usual answer, and a web-based app can be enough for simpler tools. ## What drives the cost of two codebases We will not put a multiplier on it, because it depends on the app. What drives it is predictable: - Every feature is built, reviewed and tested twice. Shared design and a shared API reduce the thinking, not the typing. - Keeping parity. Two apps drift. Someone has to own the rule that a feature is not done until both platforms have it, or users on one platform wait. - Two sets of skills. Hiring, code review and holiday cover for Swift and for Kotlin, not one pool. - Two yearly upgrade cycles. Each new iOS and Android release brings SDK requirements, deprecations and store policy changes. The rest of the budget (backend, API, design, testing on devices, store releases) is the same whichever way you build the UI. What drives mobile app cost and timeline covers the full picture. ## Going native without doubling everything - Write the API contract first. One documented API, versioned, shared by both apps. Most parity bugs start as two teams reading an endpoint differently. - Keep business rules on the server where you can. Pricing, validation and permissions decided server-side are decided once. - Share logic with Kotlin Multiplatform if rules must run on the device. Offline apps often need the same calculations locally. KMP shares that code while both UIs stay native; see Kotlin Multiplatform: when to choose it . - Use one design system with platform variants. Shared tokens for colour, type and spacing; platform-appropriate controls. - Release together. One release checklist and one version number for both apps. Releasing to the App Store and Google Play covers the store side. If you are unsure whether your app needs native, list the device features and platform integrations it must have at launch and in the next year, and compare that list with the overview in choosing a mobile app framework . Our mobile app development team builds both ways and can help you decide. ## Questions we get asked **Q: Is native app development better than cross-platform?** Native is better when the app depends on device hardware, the newest platform features or a fully native feel, and when you can fund two specialised teams. For most business and internal apps, cross-platform frameworks such as Flutter and React Native deliver the same result with one codebase, so native adds cost without a matching benefit. **Q: Should I use SwiftUI or UIKit for a new iOS app?** Start with SwiftUI for new iOS apps. It is Apple's modern declarative UI framework and where Apple adds most new UI features each year. UIKit is still fully supported and sits underneath and alongside SwiftUI, so you can drop into it for specific screens or controls where SwiftUI does not yet do what you need. **Q: Should I use Jetpack Compose or XML views for Android?** Use Jetpack Compose for new Android apps. Google describes it as Android's recommended modern toolkit for building native UI, and most new Android libraries and samples assume it. The older View system with XML layouts is still supported and interoperates with Compose, which helps when modernising an existing app screen by screen. **Q: Can native iOS and Android apps share code?** Yes, with Kotlin Multiplatform. It shares Kotlin code such as business logic, networking and local storage between Android and iOS while both apps keep their native SwiftUI and Jetpack Compose interfaces. Google officially supports Kotlin Multiplatform for sharing business logic, and it can be introduced one module at a time into existing apps. --- ## Offline-first mobile apps: how the sync architecture works - URL: https://hadoopt.com/blog/mobile-app-development/offline-first-mobile-apps-sync-architecture - Published: 2026-09-22 - Category: Mobile app development - Tags: Offline-first, Mobile architecture, Data sync, iOS, Android Local database, sync queue, conflict resolution and the real limits of background sync on iOS and Android, for teams building field apps. An offline-first app treats the database on the phone as the source of truth for everything the user sees, and treats the server as something it synchronises with when it can. That takes four parts: a local database, a queue of pending changes (an outbox), a way to pull server changes since the last sync, and a written rule for every kind of conflict. Background sync helps, but on both iOS and Android the operating system decides when it runs, so the design must work even if sync only happens while the app is open. ## Offline-capable is not the same as offline-first Many apps are "offline-capable": they cache the last screen and show an error when you try to save. That is fine for a news app. It fails the delivery driver in a basement car park, the technician in a plant room or the sales rep on a rural highway, who need to finish the job and move on. Offline-first reverses the flow. Every screen reads from the local database. Every save writes to the local database and adds an entry to the outbox. The network is a background concern. The user never waits for a request to finish before carrying on, and the interface shows what is still waiting to sync. It costs more to build, so use it only where the user's work cannot wait for a signal. ## The local database Use a real embedded database, not a key-value cache. SQLite is the default choice on both platforms and is available in every major toolkit: Room on Android, Core Data or SwiftData on iOS, Drift in Flutter, and SQLite-backed libraries such as WatermelonDB or op-sqlite in React Native. Capacitor apps can use a SQLite plugin rather than browser storage, which the browser may clear under pressure. Decisions to take early: - What goes on the device. Sync the user's working set, not the whole database: today's and tomorrow's jobs, the customers on those jobs, the product catalogue they may need. A clear rule such as "my assigned jobs for the next seven days" keeps the device fast and limits exposure if a phone is lost. - Client-generated IDs. Records created offline need an identity before the server sees them. Give each one a UUID on the device and keep a mapping to the server ID once it is known. - Schema migrations. Phones will run old versions of your app with unsent data in them. Every release must migrate the local schema without losing the outbox. - Encryption at rest for anything sensitive, with the key held in the Keychain or Android Keystore. ## The sync queue: push and pull Push works from the outbox. Each entry records the operation, the record, the changed fields, the version of the record the user started from, and an idempotency key. The sync worker sends entries in order and removes each one only when the server confirms it. The idempotency key matters because mobile networks drop responses: the server receives the change, the phone never hears back and sends it again. With the key, the server recognises the repeat and does not create a duplicate delivery or a second payment. Pull asks the server for everything changed since a cursor, usually a timestamp or a revision number stored after the last successful pull. The server must also report deletions, either as tombstone records or through a separate "deleted since" call, or deleted records will live on in phones forever. When the backend is Odoo, the write_date field on each record gives you a change cursor to work from, though deletions still need their own handling. Photos, signatures and documents go in a separate upload queue. They are large, they fail differently, and a stalled photo upload should never hold up the small text change behind it. ``` outbox entry op_id 7f3c…e21 (idempotency key) entity task / local 5b9… → server 881 change stage: done, notes: "replaced valve" base_rev 17 status pending → sent → confirmed ``` What each queued change carries so it can be retried safely and checked for conflicts. ## Conflict resolution strategies A conflict happens when the server's version of a record has changed since the version the user started from. There is no single right answer; pick one per entity type and write it down before building. Do not rely on phone clocks to order changes. Devices drift and some people set their clocks by hand. Order by server revision, and keep the device timestamp only as information. ## Background sync limits on iOS and Android The most common wrong assumption is that the app will quietly sync every few minutes in the background. Neither platform promises that. ### iOS - BGAppRefreshTask and BGProcessingTask let you ask for background time. The system decides whether and when to grant it, based on battery, network and how often the user opens the app. - BGContinuedProcessingTask , new in iOS 26, lets a task the user started in the app, such as "sync now" or an export, carry on after they switch away, with system progress UI the user can cancel. It must begin from an explicit user action. - Background URLSession transfers let the system finish large uploads, such as job photos, after the app is suspended. ### Android - WorkManager is the recommended API. It persists scheduled work across restarts and reboots, supports constraints such as "only on a network", and respects Doze and battery saving. - Periodic work cannot run more often than every 15 minutes, and Doze can defer it further. Expedited work is for important jobs that finish within a few minutes. - Some manufacturers add their own battery optimisation that stops background work more aggressively. For company devices, exclude the app through device management. Web apps have it hardest: the Background Sync API is not available in Safari, so a PWA on iPhone syncs only while it is open. The practical answer on every platform is the same. Sync on app open, on return to the foreground, when connectivity comes back and on "sync now"; treat background runs as a bonus. ## Build or buy the sync layer Sync engines and backend-as-a-service products can save months of work, and for some apps they are the right call. Check two things before committing. First, can the product talk to your real system of record, such as Odoo, or will you end up running a second database and syncing that too? Second, what happens if the vendor changes course: MongoDB deprecated Atlas Device Sync, the sync service behind the Realm SDKs, in September 2024 and switched it off on 30 September 2025, leaving teams to rebuild their sync layer. A hand-built outbox and change feed on SQLite and your own API is more work at the start and fully under your control. For field apps against an ERP, that is usually what we build. Test sync the way users break it: airplane mode mid-save, killing the app during upload, two devices editing the same job, a phone left offline for a week, an app update installed with a full outbox. For the Odoo-specific side, including which API to call and how to authenticate, read mobile apps for Odoo field teams , or talk to us about your field process. ## Questions we get asked **Q: What is an offline-first mobile app?** An offline-first app reads and writes to a database on the phone for every action, and syncs with the server in the background whenever a connection is available. Users can finish their work without signal, and the app shows which changes are still waiting to upload. It differs from an app that merely caches screens, which shows errors when you try to save while offline. **Q: How do offline apps handle conflicting edits?** Each synced change carries the version of the record it started from. If the server's version has moved on, the app applies a rule chosen for that type of record: merge changes field by field, let the server reject changes that break business rules, keep the latest change for unimportant fields, or record actions as events that do not conflict. The rule should be decided per entity before development starts. **Q: Can an iPhone app sync data in the background?** Only when iOS allows it. Background refresh and processing tasks are scheduled at the system's discretion, depending on battery, network and how often the app is used. Since iOS 26, a sync the user starts can continue in the background with a progress indicator. Large uploads can finish through background transfer sessions. Design the app to sync reliably whenever it is opened, and treat background runs as a bonus. **Q: Which database should an offline mobile app use?** SQLite, in almost all cases. It is embedded, reliable and supported by every mobile toolkit: Room on Android, Core Data or SwiftData on iOS, Drift in Flutter, and SQLite libraries for React Native and Capacitor. Avoid relying on browser storage or simple key-value stores for unsent work, because they lack queries and migrations and, in a web view, can be cleared by the system. --- ## React Native: when to choose it, with Expo and the New Architecture - URL: https://hadoopt.com/blog/mobile-app-development/react-native-when-to-choose-it - Published: 2026-09-22 - Category: Mobile app development - Tags: React Native, Expo, Cross-platform, TypeScript, Mobile architecture Where React Native and Expo fit a business app in 2026, what the New Architecture changed, and where another framework is the better choice. Choose React Native when your team already writes React and TypeScript, when you want to share people and some code with a React web app, or when the app is content, commerce or account self-service that should use real native controls. Start it with Expo, which the React Native team itself recommends. Look elsewhere when the device is central to the product, or when your team has no JavaScript background and would be more productive in Flutter or native code. React Native has changed more in the last two years than in the five before. This post covers where it stands now, what Expo gives you, and when we would and would not pick it. ## How React Native works now You write components in React, usually with TypeScript, and React Native renders them as real iOS and Android views. A button is a platform button, a scroll view scrolls with the platform's physics. That is the core difference from Flutter, which draws its own widgets. What changed underneath is the New Architecture . The old design passed messages between JavaScript and native code over an asynchronous bridge, which caused the lag and dropped frames React Native used to be known for. The New Architecture replaces it with direct calls between JavaScript and native code (JSI), a new renderer (Fabric) and lazily loaded native modules (TurboModules). The milestones that matter: - React Native 0.80 (June 2025) froze the legacy architecture. - React Native 0.82 (October 2025) was the first release that runs entirely on the New Architecture; the legacy one can no longer be switched on. - React Native 0.84 (February 2026) made Hermes V1 the default JavaScript engine. - The current release at the time of writing is 0.87 (August 2026). In practical terms: the architectural debate is over. If a library or tutorial assumes the old bridge, it is out of date. When you assess an existing React Native app, the first question is whether it has made the move, because an app stuck on the legacy architecture cannot take current releases. ## Expo is the default way to start The React Native documentation now says plainly that new apps should be built with a framework, and names Expo as a production-grade one. Expo adds file-based routing (Expo Router), a standard library of native modules, and build and update services (EAS). ``` npx create-expo-app@latest ``` The create command recommended in the React Native getting-started guide. Expo ships SDK releases that each pin a React Native version. SDK 57 (June 2026) is built on React Native 0.86; SDK 58 is in beta on a release candidate of React Native 0.88. Recent SDKs have made Expo UI's SwiftUI and Jetpack Compose APIs stable, so you can use genuine platform UI components from React code, and let you write small Swift and Kotlin modules directly in your project. ## Where React Native is the right choice You already have React developers. This is the strongest reason. Your web team's knowledge of React, TypeScript, state management and testing carries over, and hiring for React is usually easier than for Dart or for two native stacks. You have a React web app. Business logic, API clients, validation and types can be shared between web and mobile in a monorepo. UI components mostly cannot be shared directly, but the thinking and the team can. Platform-native controls matter. Because components render as real native views, text inputs, pickers, navigation and accessibility follow each platform's conventions with little effort. For customer-facing apps that should feel at home on both systems, that is a real advantage. Frequent content and logic changes. Over-the-air updates (EAS Update) let you ship JavaScript changes without a full store release. They must stay within the store rules, and anything that touches native code still needs a store build. ## Where it is not the best fit The device is the product. Heavy Bluetooth work, camera pipelines, background processing and new platform features on release day mean much of the value sits in native modules. You can write them in React Native, but at that point native apps are worth pricing up. No JavaScript in the building. A team of Kotlin or Swift developers will not enjoy being moved to React. Kotlin Multiplatform, native, or Flutter is a kinder choice. Pixel-identical custom UI everywhere. If the design is heavily custom and must look exactly the same on both platforms, Flutter's own-renderer model does that with less effort. You cannot commit to upgrades. React Native apps pull in many third-party packages. Staying current with React Native, Expo SDKs and those packages is routine work, a few times a year. Apps that skip it for two years face a painful catch-up. ## Setting up a React Native project sensibly - Start on the current Expo SDK with TypeScript. Use development builds from the start rather than relying on Expo Go. - Check every native dependency supports the New Architecture. Prefer libraries Expo maintains or recommends. - Choose navigation and state patterns once. Expo Router for navigation keeps routes predictable; pick one data-fetching and state approach and document it. - Design offline behaviour before screens. Decide what lives on the device and how it syncs. See offline-first mobile apps and sync architecture . - Put SDK upgrades on the calendar. Plan an upgrade after each Expo SDK release rather than letting versions pile up. If React Native is on your shortlist, read Flutter: when to choose it for the strongest alternative, and the overview in choosing a mobile app framework . If you also run a React web product, React and Next.js: when to choose them covers the web side. Our mobile app development team works with both. ## Questions we get asked **Q: What is the React Native New Architecture?** It is the redesigned core of React Native, replacing the old asynchronous bridge between JavaScript and native code. It uses JSI for direct calls, the Fabric renderer and TurboModules for native modules. React Native 0.82, released in October 2025, was the first version that runs only on the New Architecture, so every current app and library must support it. **Q: Should I use Expo or plain React Native?** Use Expo for new apps. The React Native documentation recommends starting with a framework and names Expo as production-grade. Expo provides routing, a standard library of native modules, and build and update services, and development builds still let you add any custom native code. Plain React Native mainly makes sense when integrating into an existing native app. **Q: Is React Native slower than Flutter or native?** For typical business apps, users will not notice a difference when the app is built well. The New Architecture removed the old bridge that caused many performance complaints, and Hermes V1 is now the default engine. Very animation-heavy or computation-heavy screens may still need native code or careful optimisation, whichever cross-platform framework you choose. **Q: Can React Native share code with a React website?** Partly. Business logic, API clients, validation rules and TypeScript types can be shared between a React web app and a React Native app in one repository. Most UI components cannot be shared directly, because web and mobile render different primitives, but developers move between the two easily, which is often the bigger benefit. **Q: Can I update a React Native app without the app store?** You can ship JavaScript and asset changes over the air with services such as EAS Update, so fixes reach users without a full store review. Anything that changes native code, permissions or the app's core purpose still needs a new build submitted to the App Store and Google Play, and updates must respect both stores' policies. --- ## Releasing to the App Store and Google Play: a practical guide - URL: https://hadoopt.com/blog/mobile-app-development/releasing-to-the-app-store-and-google-play - Published: 2026-09-22 - Category: Mobile app development - Tags: App Store, Google Play, App release, TestFlight, iOS, Android Developer accounts, review guidelines, TestFlight and Play testing tracks, privacy labels, staged rollouts and what over-the-air updates may change. Releasing a mobile app means two separate processes: Apple's, through App Store Connect with TestFlight for beta testing and App Review for every build, and Google's, through Play Console with internal, closed and open testing tracks before production. Open organisation developer accounts early, because verification takes time. Fill in the privacy disclosures accurately, and release each update gradually so you can stop a bad build. Over-the-air updates can change your JavaScript or web code between releases, but not native code, permissions or the app's purpose. ## Developer accounts: organisation or personal Both stores offer personal and organisation accounts. For a business app, use an organisation account: the store listing shows your company as the seller, access can be shared with staff and agencies through roles, and the app does not depend on one employee's personal login. - Apple Developer Program : enrolment as an organisation requires a D-U-N-S Number for your legal entity, and the account is renewed yearly. Add developers as team members rather than sharing the Account Holder's Apple ID. - Google Play Console : organisation accounts also require a D-U-N-S Number and go through identity and organisation verification. Registration is a one-time fee rather than yearly. Get your D-U-N-S Number first; details that do not match your company registration stall verification. Distributing in the EU also requires declaring your trader status under the Digital Services Act in both consoles. ## Review guidelines that catch business apps Apple reviews every build, including updates. Google reviews new apps and updates too, usually with more automation. The rules that most often affect business and field apps: - Minimum functionality (Apple guideline 4.2): an app must be more than a repackaged website. - Sign-in for reviewers : if the app needs an account, give reviewers a working demo account or demo mode. An app that only lets approved employees sign in still needs a reviewer login. - Account deletion : if users can create an account in the app, both stores require a way to delete it, and Google also asks for a web link to request deletion. - Payments : unlocking digital features or content inside the app generally requires the store's in-app purchase system (Apple 3.1.1). Physical goods and services, such as a delivery or a field visit, use your normal payment gateway. - Permissions : every permission you ask for, especially location and camera, needs a clear purpose string, and background location is scrutinised on both platforms. Platform requirements also change every year. Since 28 April 2026, iOS apps uploaded to App Store Connect must be built with the iOS 26 SDK or later. On Google Play, new apps and app updates must target Android 16 (API level 36) from 31 August 2026, with extensions available to 1 November 2026. Plan an SDK upgrade into each year's maintenance. ## Beta testing: TestFlight and Play testing tracks TestFlight is Apple's beta channel. Up to 100 internal testers, who must have a role on your App Store Connect team, can install builds as soon as they are processed. Up to 10,000 external testers can be invited by email or public link, but a build must pass Beta App Review before external testers get it. Builds remain testable for 90 days. Google Play has three testing tracks: ### The testing requirement for new personal Play accounts If your Play Console account is a personal account created after 13 November 2023, Google requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. The application asks about your closed test, your app and your production readiness, and Google says review usually takes seven days or less. Organisation accounts are not subject to this requirement, which is one more reason to register as an organisation. ## Privacy labels and the Data safety form Both stores publish what your app collects, based on what you declare. - Apple : the App Privacy section in App Store Connect records the data types collected, whether each is linked to the user, and whether it is used for tracking. Third-party SDKs that Apple lists as commonly used must ship privacy manifests, so keep SDKs current. - Google : the Data safety form in Play Console covers data collected and shared, why, whether it is encrypted in transit, and whether users can request deletion. You also need a privacy policy URL. Declarations must cover the SDKs inside your app, not just your own code: analytics, crash reporting, maps and push libraries all collect something. Update the forms when you add an SDK, and keep them consistent with your privacy policy and laws such as India's Digital Personal Data Protection Act or the GDPR. ## Staged rollouts and phased releases Never release an update to everyone at once. Both stores let you widen gradually: - Apple phased release spreads automatic updates over seven days. You can pause it if something is wrong. Users can still update manually at any time, and new downloads get the new version straight away. - Google Play staged rollout lets you choose the percentage of users who receive the update and raise it over time. You can halt a rollout so no further users receive that version. Neither store has a true rollback. If a bad build reaches users, the fix is a new build with a higher version number, which goes through review again. So set up gradual rollout, crash reporting and server-side feature switches before the first release. - Internal testers on TestFlight and Play internal testing for every build. - A closed group of real users for significant releases. - Production at a small percentage , watching crash rates and support tickets. - Widen over several days, or halt and ship a fix. ## Over-the-air updates and their limits Tools such as Expo's EAS Update for React Native, live-update services for Capacitor and Shorebird for Flutter can push new JavaScript, web or Dart code to installed apps without a store release. They suit urgent fixes. The limits come from the stores' rules: - Apple : guideline 2.5.2 bars downloading code that introduces or changes features or functionality. The Apple Developer Program License Agreement allows downloaded interpreted code only as long as it does not change the app's primary purpose, does not create a store for other code, and does not bypass the operating system's security. Fixes and small changes are fine; a new feature set should go through review. - Google : the Device and Network Abuse policy bars downloading executable code such as dex, JAR or .so files from outside Google Play. Code running in an interpreter or virtual machine, such as JavaScript in a web view, is not covered by that restriction but must still comply with Play policies. - Technical limits : an OTA update cannot change native code, add native libraries or plugins, add permissions or change the app icon. Each OTA bundle must match the native version it runs on, or the app can fail to start. If you depend on Ionic's Appflow for Capacitor live updates or cloud builds, note that Ionic plans to sunset it on 31 December 2027. If you distribute Android apps outside Google Play, for example to company devices, Google's Android developer verification applies on certified devices in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, and globally in 2027. Set up the accounts, tracks, privacy forms and rollout routine once and later releases become routine. If you would like help getting a first release through both stores, our mobile app development team does this regularly, and you can contact us to plan it. For the budget side, read what drives mobile app cost and timeline . ## Questions we get asked **Q: What is Google Play's 12 testers requirement?** Developers with a personal Google Play Console account created after 13 November 2023 must run a closed test with at least 12 testers who have stayed opted in for at least 14 consecutive days before applying for production access. Google then reviews the application, which it says usually takes seven days or less. Organisation accounts are not subject to this requirement, so businesses should register as an organisation. **Q: How many testers can use TestFlight?** TestFlight allows up to 100 internal testers, who must be members of your App Store Connect team with a suitable role, and up to 10,000 external testers invited by email or public link. Internal testers get builds as soon as they are processed. External testers get a build only after it passes Beta App Review. Each build can be tested for 90 days after upload. **Q: Can I update a mobile app without going through app review?** Partly. Over-the-air tools can update JavaScript, web or Dart code in installed apps without a store release, which suits bug fixes and small changes. They cannot change native code, add permissions or native libraries, or change the app's primary purpose. Apple's rules bar downloaded code that changes features or functionality, so significant new features should still be submitted for review. **Q: Can I roll back a bad app release?** Not directly on either store. You can pause Apple's seven-day phased release or halt a Google Play staged rollout so no more users receive the version, but users who already updated keep it. The fix is a new build with a higher version number, reviewed again. Releasing gradually, monitoring crashes and keeping server-side feature switches limits the damage. --- ## What drives mobile app cost and timeline - URL: https://hadoopt.com/blog/mobile-app-development/what-drives-mobile-app-cost-and-timeline - Published: 2026-09-22 - Category: Mobile app development - Tags: Mobile app cost, Project planning, Mobile architecture, App maintenance The decisions that make a mobile app take longer and cost more: platforms, offline, integrations, design, compliance, release and maintenance. A mobile app's cost and timeline are driven far less by the number of screens than by a handful of decisions: how many platforms you ship natively, whether the app must work offline, how many systems it integrates with, how custom the design is, what compliance applies, and how releases and maintenance are handled after launch. Two apps with the same screens can differ widely in effort because of these choices. Fix them early and an estimate becomes something you can plan around. We deliberately do not quote figures here. Any number without your scope is a guess, and a guess repeated in a blog post turns into a budget. What we can do is show where the effort goes, so you can see which of your requirements are expensive and decide whether each one is worth it. ## Platforms and technology choice The first driver is how many codebases you maintain. - One cross-platform codebase (Flutter, React Native, or a web app wrapped with Capacitor) covers iOS and Android with one team. Platform-specific work still exists, such as permissions, push setup, store assets and device quirks, but it is a fraction of the whole. - Two native codebases (Swift and Kotlin) mean building and testing most features twice, in exchange for the best platform fit. That is right for some products; our post on when to go native covers which. - Tablets, watches, web and desktop each add layouts, testing and sometimes separate release tracks. Decide early whether "also on iPad" is a real requirement. The device range matters too. A company app on a known set of phones is simpler to test than a consumer app that must work on older and low-end Android devices, where performance and memory limits appear. ## Offline and background behaviour Offline-first is the single largest multiplier we see on business apps. An app that needs a connection sends requests and shows the result. An app that must work without one needs a local database, a queue of pending changes, a conflict rule for each type of record, schema migrations that protect unsent data, and a lot of testing in awkward conditions: airplane mode mid-save, the app killed during upload, two people editing the same job. Background work adds to this. iOS and Android both limit when apps can run in the background, so features such as "sync overnight", continuous location tracking or large uploads while the phone is locked need careful platform-specific work, and sometimes a change of expectations. Our offline-first sync architecture post explains the moving parts. ## Integrations and the backend A mobile app is usually the small visible part of a system. The effort behind it depends on: - Whether a usable API already exists. If your ERP, CRM or product database already exposes well-documented endpoints, the app consumes them. If not, someone builds and hosts that backend, and it is often the larger half of the project. - The number of systems. Each integration brings its own authentication, data model, error cases and test environment. Payments, maps, SMS, identity providers and ERPs each count. - Who owns the other side. Integrating with a system your team controls is quicker than waiting on another vendor for credentials, sandbox access and bug fixes. - Data quality. Duplicated customers or inconsistent product codes in the source system surface in the app and must be cleaned or handled. For apps against Odoo, the plan and hosting matter: external API access on Odoo Online depends on the pricing plan. Our post on mobile apps for Odoo field teams goes through the options. ## Design and user experience Design effort varies with how much the app departs from platform conventions. Standard navigation, lists, forms and system controls are quick to design and build, and users already know them. A distinctive brand-led interface with custom components, animation and illustration takes longer at every stage: design, build, and testing across screen sizes and accessibility settings. Other design drivers that are easy to underestimate: - Roles. A driver, a supervisor and a customer seeing different versions of the same app is three sets of flows to design and test. - Languages. Each language means translation, longer labels that break layouts, and right-to-left support if you need Arabic or Urdu. In India, supporting regional languages for field staff is often worth it, and worth budgeting for. - Accessibility. Dynamic text sizes, screen readers and contrast should be built in from the start; retrofitting them is slower. ## Security, privacy and compliance Some requirements are the same for every app: secure sign-in, encrypted storage of tokens, privacy disclosures for both stores, in-app account deletion if users can create accounts. Others depend on your sector and markets, and can add significant work: - Personal data rules , such as India's Digital Personal Data Protection Act or the GDPR for European users, affect consent flows, data retention, and where data is stored. - Payments. Selling digital goods inside an app generally means the stores' own in-app purchase systems; physical goods and services use a payment gateway. Each has its own integration and review requirements. - Regulated sectors such as health and finance may require security reviews, penetration testing, audit logs and documentation before launch. - Company device policies , such as distribution through mobile device management or single sign-on with your identity provider. ## Release, testing and maintenance Launch is not the end of the cost; for most apps it is the start of the longer part. - Store release work. Developer accounts, store listings, screenshots, privacy forms, review cycles and test tracks. A new personal Google Play account must also run a closed test with at least 12 testers for 14 days before production, which affects the calendar. Our post on releasing to the App Store and Google Play covers the process. - Testing on real devices , including older phones your users actually carry. - Yearly platform updates. Apple and Google raise their minimum SDK and target requirements every year. In 2026, App Store uploads must be built with the iOS 26 SDK, and Google Play updates must target Android 16 from 31 August. An app nobody touches will eventually be blocked from updating. - Dependency and backend upkeep : library upgrades, security patches, server hosting, monitoring and crash reporting. > Budget for the second year when you budget for the first. The stores will make you. ## How to get an estimate you can trust - Write down the drivers : platforms, offline tasks, integrations, roles, languages, compliance and who maintains the app after launch. - Separate the first release from the wish list. Ship the smallest version real users will adopt, then add features based on use. - Spend a short discovery phase on the risky parts , usually the integrations and offline sync, before committing to a full plan. - Ask for an estimate with its assumptions listed , so a change of scope shows clearly as a change of cost. If you have a feature list and want to see which items drive the effort, our mobile app development team can go through it with you, or you can get in touch directly. ## Questions we get asked **Q: What makes a mobile app expensive to build?** The main drivers are building separate native apps for iOS and Android, offline working with data sync, the number and quality of integrations with other systems, custom design and animation, multiple user roles and languages, compliance requirements such as data protection or payments, and ongoing maintenance. The number of screens matters much less than these decisions, which is why two apps that look similar can need very different effort. **Q: Is a cross-platform app cheaper than native?** Usually, because one codebase and one team cover both iOS and Android. Some platform-specific work remains, such as permissions, push notifications, store setup and device testing. Native apps cost more because features are built and tested twice, but they are the better choice when the app depends heavily on platform features, background processing or demanding performance. The right answer depends on what the app must do. **Q: Why do mobile apps need ongoing maintenance?** Apple and Google update their operating systems every year and raise the minimum SDK and target versions that new uploads must use. Libraries need security updates, backends need hosting and monitoring, and new phone models reveal layout issues. An app left untouched will eventually fail review for updates, lose compatibility with new OS versions, or carry known security vulnerabilities, so maintenance should be budgeted from the start. **Q: Why won't an agency give a price from a feature list?** A feature list rarely states the decisions that drive effort: whether the app works offline, which systems it integrates with and whether their APIs exist, how custom the design is, and what compliance applies. Without those, any figure is a guess. A short discovery phase that answers these questions and tests the riskiest integrations produces an estimate with stated assumptions, which is far more useful for planning. --- ## Angular vs Vue vs Svelte for business applications - URL: https://hadoopt.com/blog/web-application-development/angular-vs-vue-vs-svelte-for-business-apps - Published: 2026-09-22 - Category: Web application development - Tags: Angular, Vue, Svelte, Nuxt, Frontend Angular with signals, Vue with Nuxt, and Svelte 5 with SvelteKit compared for admin panels, portals and SaaS products, and which we would pick when. Angular, Vue and Svelte can all build a large business application well. Pick Angular for big, long-lived internal systems built by several teams that want one opinionated way of doing everything. Pick Vue (with Nuxt when you need server rendering) for a gentle learning curve and a clear official stack. Pick Svelte with SvelteKit for small teams that value very little code and fast pages, accepting a smaller hiring pool. React is the fourth option and has its own post: React and Next.js: when to choose them . ## Angular today: signals, zoneless and a full framework Angular, maintained by Google, has changed more in the last three years than in the decade before. The reactivity primitives (signals, computed values, effects, signal-based inputs and queries) became stable in Angular v20. Zoneless change detection, which drops the old Zone.js dependency, became stable in v20.2 and is the default for new applications from v21. Standalone components have replaced NgModules as the recommended way to structure an app, and the Angular roadmap lists OnPush as the default change-detection strategy now that zoneless is the norm. Angular v22 brought Signal Forms to stable, alongside the Resource and httpResource APIs for asynchronous data. Server-side rendering with incremental hydration is built in. What does not change is Angular's character: routing, forms, HTTP, dependency injection, testing and a CLI all ship in the box, with one documented way to use them. - Right for: large internal platforms, back-office systems with hundreds of forms, organisations with several teams or rotating vendors who need consistency, and teams coming from Java or .NET who like dependency injection and strong structure. - Not right for: a small marketing-led product that needs to move quickly, or teams who find the framework's size and conventions a burden. The older Angular knowledge in the market (NgModules, Zone.js, RxJS everywhere) also means some candidates need retraining on modern Angular. ## Vue and Nuxt: approachable, with an official path Vue's single-file components keep template, script and style together and read naturally to developers coming from HTML. The Composition API with