Skip to content

Fleet — Concept

One sentence

A fleet is a group of serialized items that belongs together for operational or governance purposes — independent of where the items are physically right now.

The key rule

One serialized item can belong to only one fleet at a time.

This is a governance constraint, not a physical one. An item can be in a warehouse, in a van, or in a customer's hands — and still belong to the same fleet.

Why not just use stock.location?

Odoo already tracks physical location (stock.location). That answers: where is this item now?

Fleet answers a different question: which operational grouping does this item belong to?

stock.location ov.fleet
Answers Where is it physically? Which fleet/group owns it?
Changes when… The item moves The business reassigns it
Examples Warehouse A, Van 3, Customer site Customer rental fleet, battery swap pool, maintenance reserve

In normal operations these can diverge: - A battery belongs to fleet A but is currently at a repair warehouse - A motorcycle belongs to rental fleet B but is temporarily with a technician

If fleet were modelled as location, moving an item for repair would accidentally remove it from its fleet. That is the wrong semantic effect.

When to introduce ov.fleet

Only create a fleet layer when the operational grouping must stay stable across physical movements.

Typical cases: - Customer rental fleets - Battery swap/circulation pools - Maintenance reserve fleets - Delivery fleets

If the physical location is the business boundary (e.g. a simple warehouse section), a governed stock.location is simpler and sufficient. Do not add ov.fleet merely because assets exist.

How it connects to the rest

SA  →  ov.sa_fleet  →  ov.fleet  →  ov.fleet_item  →  stock.production.lot
  • SA governance attaches to the fleet (ov.sa_fleet)
  • The item belongs to the fleet (ov.fleet_item)
  • Native Odoo remains the source of truth for physical location and inventory operations

This follows the V3 association-model pattern (ADR 0003): native objects stay native; governance stays externalised; the relationship itself is the source of truth.

What this is NOT

  • Not subscription state → that stays in ABS
  • Not billing lifecycle → that stays in ABS
  • Not a generic ov.asset wrapper → not needed as the default

See also