Skip to content

Service Bundles: Physical Goods + Asset-Bound Services

Purpose: Define how to represent bundles combining physical goods with service contracts that bind to specific assets in Odoo, while maintaining integration with the ABS (Asset-Based Services) platform.

Audience: Developers, system architects, operations teams implementing asset-service binding.

1. Product Domain Separation

The architecture maintains strict semantic and accounting separation between two product domains:

Physical Goods

  • Tangible products (electric motorcycles, home energy systems)
  • Managed under the Goods branch of the product category tree
  • Participate in standard Odoo workflows:
  • Inventory moves
  • BoM management
  • Cost of Goods Sold (COGS) roll-up
  • Pricing rules
  • Sales → Invoice → Payment lifecycle
  • Tracked at individual item level (VIN, Product Item ID, serial/lot)

Service Products

  • Intangible, long-lived offerings (subscriptions, warranties, privileges, entitlements)
  • Managed under the Services branch of the product category tree
  • Characterized by:
  • Duration or lifecycle
  • Ongoing contractual meaning rather than inventory movement
  • Examples: warranties, swap privileges, service subscriptions

2. Bundle Requirements

Bundles serve commercial requirements beyond simple product grouping:

  • Combine at least one physical good with one or more service products
  • The combination carries business meaning, not merely pricing convenience
  • Example: Motorcycle sale with warranty + swap privilege + service entitlement

3. Core Challenge: Service-to-Asset Binding

The critical requirement is what happens after the sale:

Physical Goods Resolution

  • Physical goods naturally resolve to specific assets:
  • Motorcycle with VIN
  • System with ProductItemID / serial number

Service Products Challenge

  • Service products are generic by default
  • Lack intrinsic awareness of which physical item they apply to

Required Binding

When a "goods + services" bundle is sold:

  • The service contract must bind to the specific physical item sold
  • Binding is to the serial number, not just to the customer
  • This binding must be:
  • Deterministic
  • Traceable
  • Compatible with Odoo's native data model

4. System Responsibilities

Odoo Responsibilities

  • Commercial intent
  • Product definition
  • Pricing
  • Selling
  • Invoicing

ABS (Asset-Based Services) Responsibilities

  • Asset-level service execution
  • Enforcement
  • Runtime service state
  • IoT-based asset tracking
  • ServicePlan management linking:
  • Customer
  • Specific asset
  • Service logic (LEV services, battery swap, enforcement rules)

The systems connect via clear artifacts and messages, without collapsing responsibilities.

5. Architectural Constraints

The following constraints guide implementation:

  1. Avoid creating new Odoo models
  2. Avoid extending existing core models
  3. Use intrinsic/native Odoo constructs
  4. Do not interfere with or destabilize existing Odoo operations
  5. Preserve standard Odoo workflows and accounting logic
  6. Treat Odoo as the System of Record for sales
  7. Allow ABS to remain the System of Execution for services

6. Design Objective

Represent "Physical Goods + Asset-Bound Services" bundles in Odoo such that:

  • They can be sold cleanly using native constructs
  • They preserve all native Odoo behaviors
  • They generate structured information at sale/confirmation time
  • ABS can deterministically bind service entitlements to specific physical assets
  • Long-term architectural boundaries are respected
  • Odoo's core data model remains unmodified
  • Existing operations remain undisrupted