# 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