Waste Collection & Recycling Operations

Key Features

Container asset registry (`ecosire.waste.container`) with type, capacity, tare weight, asset tag/RFID reference, current site and a full dated movement history per asset

Service order model covering delivery, lift, exchange, final collection and wasted-trip outcomes, with a state machine and computed planned-vs-actual duration and weight fields

Route planning with driver, vehicle, depot and ordered stop lines, editable from list and calendar views, with resequencing and per-stop ETA rollup via `@api.depends`

Recurring collection generation from contract frequency rules through an `ir.cron` scheduled action, with a lookahead window and a guard against duplicate generation

Weighbridge ticket model capturing gross, tare and computed net weight, ticket reference, vehicle, timestamp and operator, linked to the originating service order and container

Weighbridge ingest over the XML-RPC/JSON-RPC API with an idempotency key on the external ticket reference, so a retried post from your indicator PC cannot create a duplicate charge

Touch-optimised OWL gate form for manual weighbridge entry, with tare recall from the vehicle record and immediate net-weight feedback

Waste stream / material catalogue with an EWC-style code field, per-stream rate configuration and inbound vs outbound tonnage tracking for recovery-rate reporting

Contamination capture as a percentage or flag per ticket line, with configurable threshold rules that drive an automatic surcharge line at invoicing

Contract model holding rental day/month rates, per-lift charges, per-tonne gate rates by material, minimum charges and escalation dates, with effective-dated rate versions

Periodic invoicing run that rates unbilled service orders and weighbridge tickets and produces reviewable draft `account.move` records, each line traceable back to its docket

QWeb reports for the weighbridge docket, the route manifest/run sheet and a waste transfer note layout adapted to your jurisdiction's wording

Role-based security via `ir.model.access.csv` plus record rules for driver (own route only), weighbridge operator, dispatcher and manager, with multi-company depot isolation

Automated actions and activity scheduling for containers overdue on site, tickets missing a tare weight, and service orders closed without a weight where the contract requires one

Reporting views over service orders, tonnage by stream and revenue by contract, built on standard read_group so they filter, group and pivot like the rest of Odoo

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Odoo.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Waste collection is a business of recurring service events attached to physical assets sitting on customer sites. A skip goes out on Tuesday, comes back Thursday at 3.42 tonnes of mixed C&D, gets tipped, and has to be rated against a contract that charges a rental day-rate plus a per-tonne gate fee with a contamination surcharge above a threshold. Odoo core has no vocabulary for any of that. stock.lot is not a skip, project.task is not a lift, and sale.order.line has no concept of a gross-minus-tare weight captured on a weighbridge at 06:10. Operators end up running routes on a whiteboard, containers in a spreadsheet nobody trusts, and billing in a monthly manual reconciliation between the weighbridge printout and the ERP — which is exactly where the revenue leakage lives.

We build a dedicated operations layer inside your database rather than bolting a second system onto the side of it. The core is a container asset model (ecosire.waste.container) carrying type, capacity, tare weight, current location as a res.partner site, and a full movement history, so at any moment you know which asset is on which customer site and how long it has been there. A service order model (ecosire.waste.service.order) represents one lift, exchange, delivery or collection, sequenced through states with @api.depends computed fields for planned versus actual, and grouped onto a route (ecosire.waste.route) with driver, vehicle and ordered stop lines. Routes are planned from calendar and list views, dispatched, and closed out against actuals; recurring contracted collections are generated ahead of time by an ir.cron scheduled action from a frequency rule on the contract, so Monday's commercial round appears without anyone re-keying it.

Weighbridge capture is a first-class model (ecosire.waste.weighbridge.ticket) holding gross, tare and a computed net weight, the material line-up by waste stream, the vehicle, the ticket reference and the timestamp. Tickets can be keyed at the gate on a stripped OWL form built for touch, or pushed in from an existing indicator or weighbridge PC over the XML-RPC/JSON-RPC API — we implement the ingest method and the idempotency key so a retried post never double-charges. Each ticket links back to its service order and container, and a QWeb report renders the customer-facing weighbridge docket plus, where you need it, the waste transfer note layout your regulator expects. Recycling material tracking sits alongside as waste-stream records with per-stream rates, contamination capture and inbound/outbound tonnage, which gives you a recovery-rate figure drawn from the same rows the invoice comes from rather than from a separate report nobody can tie out.

Billing is where the module earns its keep. A contract model holds the commercial terms — rental per container per day or per month, per-lift charges, per-tonne gate rates by material, minimum charges, surcharge rules and escalation dates — and an invoicing run walks unbilled service orders and weighbridge tickets for the period, rates each one, and produces account.move drafts with lines that link straight back to the docket. Nothing posts automatically without your say-so; a review step is deliberately built in. Security is real, not decorative: ir.model.access.csv grants for driver, weighbridge operator, dispatcher and manager groups, plus record rules so a driver sees only their assigned route and a multi-company operator sees only their own depot's containers. Everything is standard Odoo — models, views, security, reports — so it upgrades and backs up with the rest of your database.

Delivery is build-to-order, and we are explicit about what that means. This is not a listing you download from apps.odoo.com today. It starts with a short scoping call where we go through your container types, route structure, weighbridge hardware and above all your rate card, because the billing rules are the part that is genuinely different in every yard. We come back with a written scope and a fixed quotation. Once you confirm scope, typical delivery is 2-4 weeks to a working build installed on a staging copy of your database for UAT, followed by go-live with a rollback plan, a training session for dispatch and gate staff, and a post-go-live support window. You receive the full installable source for your Odoo version — 17.0, 18.0 or 19.0, Community or Enterprise — along with the git repository, so nothing about this leaves you dependent on us to keep operating.

What you get

Complete installable source code for the module, targeted at your exact Odoo version (17.0, 18.0 or 19.0) and Community or Enterprise edition, with a documented `__manifest__.py` and declared dependencies

Installation and configuration on your staging database, including security group assignment, container types, waste streams and an initial rate card loaded from your existing data

Technical documentation covering the data model, field-level notes, the XML-RPC/JSON-RPC weighbridge ingest contract, scheduled actions and the upgrade path between Odoo versions

End-user guide plus a live training session for dispatch, weighbridge and finance staff, recorded so you can reuse it for new hires

UAT on a staging copy of your production database with a written test script covering route close-out, ticket capture and a full billing cycle, signed off before go-live

Production go-live with a documented rollback plan and a pre-deployment database backup taken and verified before anything is installed

Post-go-live support window for defect fixes within the delivered scope, with an agreed response time and a named engineer

Handover of the private git repository with full commit history, so your team or any other partner can maintain the module without us

Who this is for

Operations / Dispatch Manager

Plans tomorrow's rounds and fields the calls when a skip isn't where the customer says it should be. Needs one screen showing every container on site with its age, resequencable route planning, and a run sheet the driver can actually work from — plus an audit trail when a customer disputes a wasted trip.

Weighbridge Operator / Gate Clerk

Turns vehicles around at the gate under time pressure. Needs a form that opens in one click, recalls the tare from the vehicle, computes net weight immediately, prints a docket, and never asks for a field that isn't on the scale ticket. Manual entry and automated ingest from the indicator both have to work.

Finance Manager / Credit Controller

Owns the month-end billing run and the revenue leakage hiding inside it. Needs every invoice line to trace back to a specific weighbridge ticket or lift, surcharges applied by rule rather than by memory, drafts reviewable before posting, and rate changes that are effective-dated instead of retro-applied.

Compliance & Environmental Officer

Answers to the regulator on waste streams, transfer documentation and recovery rates. Needs stream-coded tonnage that reconciles to the same rows finance bills from, transfer-note output in the required layout, and a defensible record of what left which site on what date.

How Waste Collection & Recycling Operations Compares

Criterion	ECOSIRE	Custom Build	Competitor	Odoo Native
Container as a tracked asset	Dedicated container model with tare weight, capacity, current customer site and full dated movement history	Achievable, but the asset/movement model is the part teams usually under-design and rebuild later	Generic asset or equipment tracking with no tare weight and no site-days concept	No equivalent; `stock.lot` and product records do not represent a skip on a customer site
Weighbridge capture	Gross/tare/net ticket model, touch gate form, plus RPC ingest with an idempotency key	Depends entirely on whether the duplicate-post problem is anticipated up front	Rarely present; weights end up typed into a note or an order line	Not modelled at all — Odoo core has no weighbridge concept
Weight-based contract billing	Rated invoicing run producing reviewable drafts, each line traceable to its docket or lift	Possible, though rate-card edge cases are where custom builds overrun	Usually flat per-order pricing; tonnage rating is out of scope	Manual invoice lines keyed from the weighbridge printout each month
Route planning and dispatch	Routes with driver, vehicle, ordered stops, resequencing and a QWeb run sheet	Buildable, but the dispatcher UX takes several iterations to get right	Often a simple stop list with no container context or actuals capture	Field Service scheduling exists in Enterprise but carries no container or tonnage context
Recycling stream and recovery reporting	Stream catalogue with codes, contamination capture and tonnage reconciling to the billed rows	Frequently deferred to phase two and then never funded	Not typically covered by generic logistics modules	No waste stream concept; would require a parallel spreadsheet
Fit to your rate card and processes	Scoped against your actual contracts before a line is written; bespoke rules priced in the quotation	Fully yours, at the cost of specifying every rule from a blank page	You adapt your process to whatever the vendor assumed	You adapt entirely, or run the process outside Odoo
Access control and depot isolation	`ir.model.access.csv` groups plus record rules — driver sees own route, depot sees own containers	Often added late, after a driver has already seen the full customer list	Coarse group-level access with little or no record-rule work	Standard Odoo groups only, with no domain logic for routes or depots
Ownership, source and support	Full source, git repository handover, documented support window and a quoted upgrade path	You own it, and you own the maintenance and the bus factor	Vendor-controlled release cycle; fixes arrive when they arrive	Supported by Odoo, but only for what core actually does

Frequently Asked Questions about Waste Collection & Recycling Operations

How long does delivery take, and what happens first?

This is a build-to-order module, not an instant download. We start with a short scoping call (about 30 minutes) covering your container types, route structure, weighbridge hardware and rate card, then send a written scope and a fixed quotation. Once you confirm that scope, typical delivery is 2-4 weeks to a working build installed on a staging copy of your database for UAT, then go-live. Very unusual rate structures or a bespoke weighbridge integration can extend that, and if so we say so in the quotation rather than after.

What support and updates do I get after go-live?

Every build includes a post-go-live support window for defect fixes within the delivered scope, with an agreed response time and a named engineer. Beyond that we offer an optional annual maintenance arrangement covering compatibility with Odoo point releases and your minor change requests. Migrating the module to a future major Odoo version (for example 18.0 to 19.0) is quoted separately, because it is real engineering work. You also receive the git repository and full source, so you are never blocked from maintaining it yourself or handing it to another partner.

Which Odoo versions and editions does this work on?

We build for Odoo 17.0, 18.0 and 19.0, on Community or Enterprise, and on odoo.sh, on-premise or a self-managed cloud instance. The module is written against standard framework APIs — `models.Model`, computed fields, `ir.model.access.csv`, record rules, XML/OWL views, QWeb reports and `ir.cron` — so it does not require Enterprise. Where an Enterprise feature genuinely improves the result, such as Gantt or map views for route planning, we implement a Community-compatible list/calendar equivalent and use the Enterprise widget only when your licence supports it. Tell us your version at scoping and the build targets it.

Can it connect to our existing weighbridge indicator or gate software?

Yes, and this is a normal part of scope. The ticket model exposes an ingest method over Odoo's XML-RPC/JSON-RPC API with an idempotency key on your external ticket reference, so your weighbridge PC or middleware can post gross/tare/net readings without any risk of double-billing on a retry. If your indicator writes to a CSV drop or a local database instead, we build a scheduled import against that. If you have no automation at all today, the touch-optimised gate form covers manual entry and the integration can be added later without a rebuild.

Our billing rules are unusual — minimum tonnages, rebates on clean loads, different rates per site. Will that fit?

The rate card is the part we expect to differ in every yard, which is why it is configuration on the contract model rather than logic hard-coded into the invoicing run. Rental day/month rates, per-lift charges, per-tonne gate rates by material, minimum charges, contamination surcharges and effective-dated escalations are all supported out of the build. Genuinely bespoke rules — a rebate formula tied to a market index, for instance — are captured at scoping and priced into the quotation, so you know before you commit whether your rules fit the standard configuration or need a specific extension.

How is this different from just using Odoo Field Service or Rental?

Both are useful neighbours and we integrate with them where it makes sense rather than replacing them. What they do not model is a container as a tracked asset with a tare weight sitting on a customer site for an unknown number of days, a weighbridge ticket with gross/tare/net and a waste stream, or an invoicing run that rates a lift by tonnage against a contracted gate fee. Without those you get scheduling but still reconcile the weighbridge printout to the ERP by hand every month — which is the actual cost you are trying to remove.

What happens to our existing container and contract data?

Data migration is part of delivery. At scoping we take a sample of your current container spreadsheet, customer site list and rate card, and agree a mapping. We then load it into the staging database as part of the UAT build so you are testing against your own containers and customers, not demo records. Anything that will not map cleanly — duplicate asset tags, containers with no known location, historic rates with no start date — comes back to you as a data-quality list before go-live rather than being silently imported.