Odoo-Modules/fusion_accounting_reports/UPGRADE_NOTES.md

fusion_accounting_reports — Upgrade Notes

Odoo Version Anchor

This module targets Odoo 19.0 (community-base).

Reference snapshot of Enterprise code mirrored from:

• account_reports (Odoo 19.0.x)
• Source: /Users/gurpreet/Github/RePackaged-Odoo/accounting/account_reports/

Cross-Version Diff Strategy

When a new Odoo version ships:

1. Run check_odoo_diff.sh (in repo root) against the new Enterprise version
2. Note any breaking changes in account.move.line / account.account API surfaces relied on by services/totaling.py and services/drill_down_resolver.py
3. For mirrored OWL components, diff Enterprise's new versions against ours and port material changes (signature renames, new behaviour we want to inherit)
4. Re-run the full test suite + tour tests + benchmarks against the new Odoo version
5. Update this file with the new version anchor + any deviations

V19 Migration Notes (already applied — Phase 1 lessons)

These were the bite-points from Phase 1 (fusion_accounting_bank_rec); we preempted them in Phase 2 from day one:

• _sql_constraints → models.Constraint (used in fusion.report, fusion.report.commentary, fusion.report.anomaly)
• @api.depends('id') → removed everywhere; computed fields depend on real field names instead
• @route(type='json') → type='jsonrpc' (all 8 endpoints)
• numbercall field on ir.cron → omitted (removed in V19)
• res.groups.users → user_ids
• ir.ui.menu.groups_id → group_ids (used in views/menu_views.xml and the two wizard view files for the coexistence-group filter)

Engine API Stability

The 5 public engine methods (compute_pnl, compute_balance_sheet, compute_trial_balance, compute_gl, drill_down) are the public contract. Their signatures are keyword-only after the first positional argument and will be treated as semver-stable across patch releases. Breaking changes will bump the minor version (e.g. 19.0.2.x.y).

Phase 2 → Phase 2.5 Migration

If we ship Phase 2.5 (line_spec polish, deferred features, header_only flag, prefix overlap fix), changes will go in incremental commits. No DB migration needed — Phase 2 schema is forward-compatible:

• fusion.report.line_specs is a JSON column; the migration path is to rewrite specs in place
• fusion.account.balance.mv can be dropped/re-created freely
• fusion.report.commentary is a cache; safe to truncate on upgrade
• fusion.report.anomaly records carry Period as date_from/date_to fields; no schema-level changes anticipated