A build-to-order foundation module that gives every Odoo shipping-carrier integration a shared, consistent base layer — rate abstraction, label storage, tracking hooks, and a common `delivery.carrier` extension pattern. ECOSIRE scopes, builds, installs, and supports it. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $249.00 USD; request a quote for a scoped proposal.
ایپ مینی فیسٹ
آپ کے ورک فلو کے مطابق تیار کردہ
A build-to-order foundation module that gives every Odoo shipping-carrier integration a shared, consistent base layer — rate abstraction, label storage, tracking hooks, and a common `delivery.carrier` extension pattern. ECOSIRE scopes, builds, installs, and supports it.
خود سیٹ اپ کی ضرورت نہیں — ایک کام کرنے والی ایپ جو ECOSIRE بناتا، انسٹال اور سپورٹ کرتا ہے۔
ایک بار کی تعمیر کی قیمت سے آغاز کریں۔ آغاز پر ہم آپ کے ساتھ مل کر دائرہ کار طے کرتے ہیں۔
ECOSIRE اسے آپ کے Odoo پر بناتا، ترتیب دیتا اور انسٹال کرتا ہے۔
آپ تقریباً 2–4 ہفتوں میں لائیو ہو جاتے ہیں، لانچ کے بعد معاونت کی مدت کے ساتھ۔
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 2-4 weeks from confirmed scope. Pricing starts from $249 (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.
Operations or IT teams that already ship with two or more carriers and are tired of each connector storing labels, tracking, and rates differently. They need one shared base so the next integration is cheap and consistent.
Developers who plan to build their own carrier connectors and want a clean, well-documented interface (`_get_rate()`, `_send_shipping()`, etc.) to subclass rather than reinventing rate and label plumbing per carrier.
Businesses with high shipment volume across warehouses and companies that need consistent volumetric-weight calculation, UoM normalization, and an audit trail of every carrier API call for dispute resolution.
Teams driving shipment creation from a storefront or middleware over XML-RPC/JSON-RPC that need the rate and label logic exposed through a stable, documented API surface.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| What you get | Purpose-built shared carrier base, scoped to your carriers and warehouses | Whatever your team has time to build and maintain | Generic base bundled with one vendor's connectors | |
| Carrier interface | Documented abstract methods every connector subclasses consistently | Interface quality depends entirely on internal discipline | Interface tied to that vendor's connector conventions | |
| Label & tracking storage | One `ir.attachment` convention for PDF/ZPL/PNG plus tracking fields | Often inconsistent between connectors | Standardized within the vendor's own connector set only | |
| Volumetric weight & UoM | Computed volumetric weight and warehouse-to-carrier UoM conversion | Built per connector, easy to get wrong | Varies by vendor; sometimes fixed to their locale | |
| API audit & retries | Request/response audit log with configurable timeout and retry | Rarely built until an outage forces it | Usually not exposed as a reusable base concern | |
| Fit & ownership | Made to order; full git repo and source handover to you | You own it, but you also own every bug and upgrade | Licensed as-is; limited to the vendor's roadmap | |
| Support & delivery | Scoped build, staging UAT, rollback plan, post-go-live support window | Your team is the only line of support | Vendor support tiers, generic to all buyers | |
| Timeline & cost | 2-4 weeks from confirmed scope; from $249 indicative, fixed quote after scoping | Open-ended internal effort and salary cost | Instant download but generic fit and hidden integration work |
No. It is a build-to-order foundation module — the shared base layer that individual carrier connectors install on top of. It is not on apps.odoo.com as an instant download; ECOSIRE scopes, builds, installs, and supports it for your specific Odoo environment. On its own it standardizes the carrier contract; you pair it with one or more carrier integrations (ours or your own) to actually ship.
Because every build is made to order, we do not ship a pre-packaged binary. After a short scoping call and written scope confirmation, typical delivery is 2-4 weeks from confirmed scope. The exact timeline depends on how many carrier interfaces you need supported and whether we are migrating existing custom connectors onto the base.
Pricing starts from $249 as an indicative figure for a single-company base scope. The final number depends on the number of carrier interfaces supported, multi-company/multi-warehouse layout, UoM and localization depth, and any migration of existing custom connectors. We give you a firm fixed quote after the scoping call — the from-price is a starting point, not the invoice.
Every build includes a post-go-live support window for defect fixes and configuration questions, plus the full git repository so your team owns the code. Because we build against a specific Odoo version (17.0, 18.0, or 19.0), version upgrades or ports to a newer Odoo release are handled as a separate scoped engagement — we will quote that when you plan the upgrade.
The base module itself has no Enterprise-only dependency and runs on Community or Enterprise. If a particular carrier flow you want relies on Enterprise-only features (for example certain EDI or Studio capabilities), we flag that during scoping so there are no surprises.
It extends `delivery.carrier` and the standard `stock.picking` flow rather than replacing them, so native delivery behavior stays intact. If you already have home-grown connectors, we assess them during scoping and, where it makes sense, refactor them to subclass the base interface — that migration is part of the quoted scope.
Yes — that is the point. The module exposes a documented Python interface and a reusable QWeb report, so your developers subclass `_get_rate()`, `_send_shipping()`, `_cancel_shipment()`, and `_get_tracking_link()` for each new carrier. We include a reference connector stub and technical docs to make that straightforward.
A build-to-order foundation module that gives every Odoo shipping-carrier integration a shared, consistent base layer — rate abstraction, label storage, tracking hooks, and a common `delivery.carrier` extension pattern. ECOSIRE scopes, builds, installs, and supports it.