Once you run more than one courier in Odoo, the cracks show. Odoo's native delivery app models a delivery.carrier and stock.picking handoff, but each carrier connector you bolt on tends to re-invent its own rate-request plumbing, its own label field, its own tracking-reference storage and its own error handling. The result is duplicated code, inconsistent field names across connectors, label PDFs stored three different ways, and a support burden that grows with every new integration. There is no shared contract that says "this is how a shipping carrier talks to Odoo here" — so the tenth connector is as expensive to build and debug as the first.

The Delivery Base Module is the foundation layer that fixes that. It is not a courier connector itself; it is the shared substrate that every ECOSIRE (and your own) shipping integration installs on top of. Technically, it extends delivery.carrier with a common set of fields and abstract methods — a normalized rate-request/rate-response structure, standardized label storage (ir.attachment-backed, one convention for PDF/ZPL/PNG), tracking-number and tracking-URL fields, package-level dimension and weight normalization, and a service-level selector. Carrier-specific modules then subclass a well-defined Python interface (_get_rate(), _send_shipping(), _cancel_shipment(), _get_tracking_link()) instead of each connector improvising its own. Under the hood it uses models.Model inheritance, @api.depends computed fields for landed-cost and volumetric weight, and a thin service layer that carrier modules call — so a new integration is a few hundred lines, not a few thousand.

The module ships with the cross-cutting concerns a fleet of connectors needs but no single connector should own: unit-of-measure conversion between your warehouse UoM and each carrier's expected weight/dimension units, a request/response audit log for debugging carrier API calls, configurable retry and timeout handling, credential storage on the carrier record (with ir.model.access.csv and record rules so only shipping managers read API keys), and a QWeb-driven packing-slip/label report template that carrier modules reuse. Because it exposes its rate and label methods cleanly, they are also reachable over the XML-RPC/JSON-RPC API for headless or e-commerce-driven flows. It is built to your target — Odoo 17.0, 18.0, or 19.0 — and works on both Community and Enterprise (the base itself needs no Enterprise-only dependency; if your carrier flow relies on Enterprise studio or EDI features we call that out during scoping).

Because this is a dependency other modules require, we treat it as an architectural decision, not a plugin drop. During scoping we map which carriers you run now and plan to add, your warehouse UoM conventions, your multi-company and multi-warehouse layout, and any existing home-grown connectors we need to migrate onto the base. We then build against a clean staging clone of your database, run UAT there, and hand over versioned source plus the git repository.

This is build-to-order: nothing is downloaded and switched on instantly. After a short scoping call we confirm scope in writing and typical delivery is one working week from confirmed scope. Pricing starts from $999 (indicative, single-company base scope); the number of carrier interfaces you need supported, multi-company/multi-warehouse layout, UoM and localization depth, and migration of existing custom connectors onto the base all increase the quoted scope. You get a firm fixed quote after the scoping call — never a surprise on the invoice.