Car rental is a per-asset business, and Odoo core is built around per-product quantities. sale.order will happily sell three units of "Compact Sedan" for the same week because stock has no notion of a specific chassis being physically on the road until Thursday. Odoo's fleet app tracks vehicles, odometers, contracts and service costs, but it is an internal-cost application: no customer-facing availability, no rate card, no deposit, and no concept of handing keys over and getting them back. Enterprise's sale_renting adds durations and pickup/return, but it is still quantity-based on a rentable product, and it has nothing to say about fuel level at handover, a dent in the nearside rear door, a speeding fine that arrives six weeks after the customer flew home, or the fact that unit 47 must go off-hire at 60,000 km. Operators bridge that gap with spreadsheets and a WhatsApp folder of handover photos — which is exactly where deposits get argued over and lost.

We build a rental layer that treats each vehicle as the bookable resource. A fleet.rental.agreement model carries the customer, the specific fleet.vehicle, the period, the rate line and the deposit, with overlap prevented at the database level rather than in a UI warning: a SQL/exclusion constraint plus an @api.constrains check on the date range means two confirmed agreements can never claim the same chassis, whatever concurrent path created them. Availability is exposed as a Gantt-style board (Enterprise web_gantt; a colour-coded calendar and list view on Community, since Gantt is not in Community) grouped by vehicle category, so the counter agent sees the real board, including units blocked by a scheduled service. Rates live on a fleet.rental.rate model with tiered daily, weekly and monthly bands, mileage allowance and excess-kilometre pricing, seasonal date ranges and customer-pricelist overrides; the charge is a compute field with @api.depends on the period, the rate and the returned odometer, so a re-read of the meter recalculates the settlement rather than requiring a manual invoice edit.

Check-out and check-in are the heart of the build. Both are OWL-based screens designed for a tablet at the counter or the kerb: fuel level, odometer, accessories checklist, and a vehicle diagram where the agent taps a panel to log damage. Each damage record is its own model row with a panel code, severity, a photo attached through ir.attachment, and a flag for whether it was pre-existing at check-out or newly found at check-in — which is what turns a deposit dispute into a two-column QWeb comparison report you can email the customer. Check-in computes the settlement: excess kilometres, fuel differential, late-return hours, damage charges, and deposit release or partial capture, posting to the customer invoice through standard account.move lines so your accountant sees ordinary Odoo entries. Traffic fines and tolls get their own model with an incident date, matched back to whoever held the vehicle on that date and recharged with an administration fee — the single largest source of unbilled revenue we see in this vertical. Maintenance closes the loop: rules on kilometres or elapsed months raise service requests against fleet.vehicle.log.services through ir.cron and Odoo automated actions, and a vehicle due for service is automatically withheld from the availability board so nobody books a car that is about to go into the workshop.

Everything ships as a proper Odoo addon with a complete __manifest__.py, not a customisation poked into your production database. Access is defined in ir.model.access.csv with record rules separating counter agents (their own branch's agreements), fleet supervisors and finance, and multi-company rules are honoured so a group with branches keeps its books apart. Documents — the rental agreement, the condition report, the settlement statement — are QWeb PDF templates using your letterhead and your terms, in the languages you operate in. Integration points are ordinary Odoo ones: the models are exposed over XML-RPC and JSON-RPC so a booking website, an aggregator feed or a telematics provider can create reservations and push odometer readings without us inventing a private protocol.

Because this is build-to-order, nothing is downloaded and installed blind. We start with a scoping call, agree the exact rate structure, damage taxonomy, deposit policy and document layouts in a written scope, and build against your Odoo version — 17.0, 18.0 or 19.0 — and your Community or Enterprise edition, since the availability board and sign-on-glass options differ between them. Typical delivery is one working week from confirmed scope, depending on how much of the fine-recharge and telematics surface you want in v1. You get the full source, a staging UAT round before anything touches production, a rollback plan, training for your counter staff, and a support window after go-live. If requirements change mid-build, we re-scope in writing rather than quietly shipping something different.