Odoo Community and OCA overview

This document explains the pieces Avunu builds Odoo systems from (Odoo Community, OCB and the Odoo Community Association), how that differs from Odoo Enterprise, and how we decide which modules go into a build. Read it first if you are new to the Odoo section of this knowledge base.

The pieces

Four names come up constantly, and they are easy to mix up.

An Avunu Odoo project is OCB plus a chosen set of OCA modules plus, where your business is genuinely different, a few small custom modules of our own.

How Community differs from Enterprise

Enterprise is a polished product with a subscription attached. Some of its features are not in Community. That is a fair business model, but it is not the only way to run Odoo.

Two practical consequences are worth knowing before you choose:

• Some Enterprise features have no Community equivalent. One we have run into: Community has no Gantt view, so a shop schedule board is the calendar view colored by technician instead.

• Odoo's own hosting is built around Enterprise. Because of that, you host Community yourself or with a provider. Avunu runs it on our managed platform, on your hardware, or with another host you trust.

If a specific Enterprise feature matters to your business, we say so plainly and help you weigh the options. Checking whether an OCA module covers a gap is where most of our selection work happens.

Why we build on Community plus OCA

We build on Community and OCA for four reasons:

• No license fees. Adding a technician, a counter clerk or a seasonal hire does not add a subscription line.

• No lock-in. The code is open, your data sits in a standard PostgreSQL database, and any qualified Odoo developer can support the system. You can bring it in-house whenever you like.

• Proven building blocks. OCA modules are reviewed and used by businesses around the world, so most requirements start from existing code instead of a blank page. We write custom code only where we have to.

• A path forward. The OCA ports its modules to each new Odoo release, so the system has an upgrade route.

OCA modules are published under open licenses. In the module catalog bundled with odoo-nix, nearly all of the 18.0 modules are AGPL-3 or LGPL-3. Our own open-source Odoo modules are released under AGPL-3, with one LGPL-3 exception (shopfloor_mobile_camera_scan). Check a module's manifest for its license before you adopt it.

Which Odoo version we use

New projects start on Odoo 18.0. It is the default series in odoo-nix, and the series where the OCA catalog is richest. Odoo 19.0 is supported by the tooling, but the OCA's port to it is still in progress, so fewer modules exist there.

At the time of writing, the odoo-nix catalog lists 2,923 module records across 149 OCA repositories for 18.0, and 1,259 across 121 repositories for 19.0. These numbers come from a catalog snapshot and change whenever the catalog is refreshed.

How we choose modules

We work down a short ladder and stop at the first rung that meets the need.

1. Core Odoo. Configure what Community already does.

2. An OCA module. Look for a maintained module that covers the requirement, and read its manifest and source before adopting it.

3. A small custom module. Write focused glue that connects existing pieces. We prefer several small modules over one large one, and we ship automated tests with them. See Testing Custom Odoo Modules.

When we evaluate an OCA module, we check these things:

• It is ported and installable for your series. The version in the manifest starts with the series (for example 18.0.), and the module is marked installable.

• Its dependencies are acceptable. A module's depends can pull in further OCA repositories. Every extra repository is something to keep updated, so we look at the whole set, not just the module.

• Its maturity matches the risk. OCA modules carry a development status. In our repair-shop build, repair_type is Alpha, and a few repair modules are young Betas. They are small and readable, but we pin exact versions and smoke-test after every update.

• It does not fight the workflow. One timesheet module we first installed forced a task on every timesheet line, which broke technician time on repair orders, so we removed it. Reading how a module behaves before you commit saves a rework later.

Sometimes two modules collide, or an upstream module has a bug we need to work around. We override it in our own module, and the fix is worth offering upstream to the OCA so the override can be dropped once it is merged.

Bundles

Common starting points are collected in curated bundles. odoo-nix ships these (defined in its data/oca-bundles.json):

OCA software is entirely opt-in. A new project can start as plain Odoo core, with no bundles and no modules, and you add what you need later.

Adding modules to a project

In an odoo-nix project, run these from the project root inside the dev shell:

odoo module add
odoo module add-bundle base sales
direnv reload

odoo module add opens a picker over every installable OCA module for the series. Choosing a module resolves the OCA repositories it needs, adds only the new ones as git submodules, records the module in modules.txt and re-locks the Python dependencies. odoo module add-bundle does the same for a named bundle. Run direnv reload afterwards so the environment picks up the new paths.

You can also add a repository from outside the OCA by passing a git URL or owner/repo shorthand to odoo module add.

Two conventions keep a project readable:

• modules.txt is the install set, and odoo db provision installs everything in it on a new database.

• Your own modules live in custom/, and OCA repositories live in modules/. Many projects keep modules.txt to OCA modules only and install their own modules explicitly, for example from the Apps menu. Nothing in odoo-nix forces that, so follow what your project already does.

The full workflow is in Odoo Development Environment.

Why every project is pinned

Every OCA repository is a git submodule, and every Python dependency is locked. What we test is exactly what runs in production, and an update is a deliberate step, never a surprise. After pulling new module versions, we run the project's tests and smoke-test the workflows that matter before anything reaches a live system.

What is in this section

The Odoo section covers the system from the workstation to the finished workflow:

• Odoo Development Environment: set up a reproducible local Odoo with OCB, OCA modules, a database and a mail catcher.

• Testing Custom Odoo Modules: run automated tests against custom modules.

• Repair Shop Workflow on Odoo: how an auto and heavy-truck repair shop runs from repair order to paid invoice on Community and OCA.

• Migrating from QuickBooks to Odoo: move a business off QuickBooks with a clean cutover.

• Importing Documents from Email into Odoo: turn emailed documents into Odoo records.

• Two-Way SMS in Odoo with Twilio: send and receive text messages inside Odoo.