Impacted versions

• Odoo 19.0 Enterprise
• Odoo.sh
• Modules: excise_management, deposit_management (from odoo/industry @ 19.0, pulled in by beverage_distributor)

Related issues

• [19.0] Can’t install 3pl_logistic_company : module_delivery* fields trigger _button_immediate_install during data load*_ #1378 - same class of bug (Studio-generated fields failing during headless install) in 3pl_logistic_company
• [booking_engine] -u all fails: view validation can't see manual related field x_resource_id on rental.order.wizard.line #2320 - same class (manual related field not resolvable during -u all) in booking_engine

Summary

excise_management and deposit_management both fail to install on a clean Odoo.sh 19.0 Enterprise build. Both fail with the same root cause: a manually-defined (Studio-generated) computed field is recomputed during module load and reads a cross-model field that is not yet resolvable, raising AttributeError and aborting registry load.

Installing via the UI with demo data gets past excise_management but then fails on deposit_management, so the Beverage Distributor bundle cannot be installed cleanly on Odoo.sh 19.0.

Steps to reproduce

1. Create a fresh Odoo.sh 19.0 Enterprise project.
2. Either:
   • Add excise_management to the repo (Odoo.sh runs module tests on repo addons) → build fails.
   • Or: Apps → Install → Beverage Distributor → build fails.
3. Equivalent headless:

   odoo-bin -d test -i excise_management --stop-after-init --without-demo=all
   

   → same traceback.

Root cause: excise_management

File: excise_management/data/ir_model_fields.xml

• ~Line 138: field x_excise_packaging_tax is defined on product.template as a related, non-stored field (related="x_excise_category.x_packaging_tax").
• ~Line 224: field x_packaging_amount on stock.move has compute:

  record['x_packaging_amount'] = record.x_packaging_units * record.product_id.x_excise_packaging_tax

  It reaches through product_id (product.product) to the product.template field.
• Its declared depends is only "x_packaging_units" — it does not declare product_id.x_excise_packaging_tax although the compute reads it.

At install time, adding these fields triggers a recompute (_reflect_relation → flush_all → _recompute_field). The stock.move compute runs and reads product.product.x_excise_packaging_tax before product.product's _inherits delegation to that product.template field is established, raising:

AttributeError: 'product.product' object has no attribute 'x_excise_packaging_tax'

Also affects x_total_excises (~line 264) and x_total_excises_account_move (~line 298), which read the same field.

Full traceback tail:

...odoo/tools/safe_eval.py line 414 in safe_eval
ValueError: AttributeError("'product.product' object has no attribute 'x_excise_packaging_tax'")
  while evaluating
  "for record in self:
    record['x_packaging_amount'] = record.x_packaging_units * record.product_id.x_excise_packaging_tax"

odoo.tools.convert.ParseError:
  while parsing excise_management/data/ir_model_fields.xml:223,
  <record id="stock_move_excise_packaging_amount" model="ir.model.fields">

Root cause: deposit_management

File: deposit_management/data/ir_model_fields.xml

• x_total_deposits on sale.order.line: non-stored computed from tax_ids.
• x_has_deposit_line on sale.order: declares depends="order_line.x_total_deposits" and computes any(line.x_total_deposits for line in record.order_line).

Resolving/recomputing the sibling manual field across the One2many during setup fails on a clean install. Build reports: "At least one test failed when loading the modules (deposit_management)".

Suggested fix

The auto-generated cross-model computed/related fields are not install-order-safe. Options:

(a) Declare complete/correct depends including the cross-model path (e.g., product_id.x_excise_packaging_tax).

(b) Guard install-time recompute so related fields via _inherits delegation are resolved before dependent computes run.

(c) Load the base product/tax fields in an earlier data file than the stock.move / sale.order computed fields (split the XML).

The interactive/demo install path masks the issue via different recompute timing.

Impact

• Beverage Distributor (and any database adding these industry modules through the repo/CI path) cannot complete a clean automated build on Odoo.sh 19.0.
• This is the same class of bug as [19.0] Can’t install 3pl_logistic_company : module_delivery* fields trigger _button_immediate_install during data load*_ #1378 (open since Nov 2025) and [booking_engine] -u all fails: view validation can't see manual related field x_resource_id on rental.order.wizard.line #2320, suggesting a systemic issue with how industry packages use Studio-generated x_ fields in ir_model_fields.xml data records.

Environment

• Odoo.sh 19.0 Enterprise
• Clean project, no custom modules
• Reproducible on headless and CI builds
• Demo-data install partially masks the issue (different recompute timing)