Telecom operators and ISPs almost never fail at accounting — they fail at the gap between the network and the ledger. A customer signs up on a 50 Mbps plan with a 500 GB fair-usage cap, a static IP add-on and a two-month promotional discount; the RADIUS/OLT side knows the session, the mediation export knows the bytes, and the finance team knows nothing until somebody pastes a spreadsheet into an invoice run. Odoo native gets you close and then stops: sale.subscription (Enterprise) or a recurring sale order handles a flat monthly fee well, but it has no concept of a rated usage record, no tariff with tiers and free allowances, no proration rule for a mid-cycle plan change, no service instance to suspend when a bill ages past 30 days, and no link from a trouble ticket back to the specific circuit whose SLA credit should appear on next month's invoice. Community has no subscription engine at all. So operators end up with three disconnected systems — a NAS/AAA stack, a spreadsheet rating sheet, and Odoo as a dumb invoice printer — and the reconciliation between them is a person.

What ECOSIRE builds is the missing middle, entirely inside Odoo so that one database holds the customer, the service, the rating, the invoice, the payment and the ticket. The core is a small set of new models declared in a proper __manifest__.py that depends on sale, account, product, contacts and (where the operator runs it) helpdesk or project: a telecom.plan with tariff lines, a telecom.service instance that carries the subscriber identifier (username, CPE MAC, ONU serial, MSISDN — whatever your access layer keys on) and a state machine of draft → provisioning → active → suspended → terminated, a telecom.usage.record for rated events, and a telecom.rating.rule that turns raw counters into billable lines. Rating runs as a batch: an ir.cron pulls or accepts mediation data, groups it by service and period, applies tiered/committed-rate/overage logic, and writes rated lines that a compute field on the service rolls up with @api.depends so the current-cycle exposure is visible before the invoice exists. Invoicing then reuses Odoo's real account.move machinery — no shadow ledger — so tax, fiscal positions, multi-currency and analytic distribution behave exactly as your accountants already expect, and the customer-facing bill is a QWeb report we design to show plan, allowance, overage and credits line by line.

Operations sit on the same records rather than beside them. Provisioning is a workflow: an order confirmation creates the service in provisioning, raises the field/NOC tasks, and only moves to active when the activation step is signed off — with an optional outbound call to your AAA, OLT controller or NMS over HTTP, or (more commonly, and more safely) an export queue your existing scripts consume. Suspension and reconnection are the same path in reverse, driven either by an operator button or by an automated action on ageing receivables, so a dunning decision and a network action stop being two separate human jobs. Trouble tickets extend the helpdesk/ticket model with the service, the outage window and a fault category; time inside the window feeds an SLA calculation that can raise a credit note against the next invoice under approval. Dealer and collection channels get their own layer: a telecom.dealer with assigned territories or customer sets, cash-collection batches that post to a dealer-specific journal or account, and commission accrual computed from collected (not merely invoiced) amounts. Access is enforced properly — ir.model.access.csv for the new groups (Billing Officer, NOC/Provisioning, Dealer, Manager) plus record rules so a dealer sees only their own subscribers and a NOC user cannot post an invoice. Everything is reachable over XML-RPC/JSON-RPC, so an existing captive portal, self-care app or mediation script can create usage records and read balances without a second integration layer.

This is a build-to-order product, not a download. After you request a quotation we run a scoping call, then write the specification against your actual tariffs, your access technology and your Odoo edition and version — 17.0, 18.0 or 19.0, Community or Enterprise (where Enterprise is present we integrate with sale_subscription rather than duplicating it; on Community we build the recurring engine ourselves). You get the module built against that spec, installed on a staging database restored from your data for UAT, then a scheduled go-live with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope; a heavily integrated build with live provisioning calls into third-party equipment can be longer, and we say so in the quotation rather than after the fact.