Skip to content

[14.0][ADD] l10n_es_aeat_mod349_special_prorate - #954

Open
eantones wants to merge 1 commit into
14.0from
14.0-add-l10n_es_aeat_mod349_special_prorate
Open

[14.0][ADD] l10n_es_aeat_mod349_special_prorate#954
eantones wants to merge 1 commit into
14.0from
14.0-add-l10n_es_aeat_mod349_special_prorate

Conversation

@eantones

@eantones eantones commented Jul 23, 2026

Copy link
Copy Markdown
Member

New auto-install bridge module wiring the special prorate purchase taxes (l10n_es_special_prorate) into the AEAT 349 model tax map, keys A (intra-community acquisitions of goods) and I (intra-community acquisitions of services).

Why. l10n_es_special_prorate only depends on l10n_es, so it cannot declare 349 map membership itself. That wiring is generic (any database using both modules wants it), and until now it only existed inside a client localization module. This module is the missing 349 counterpart of the existing bridges l10n_es_aeat_mod303_special_prorate and l10n_es_aeat_sii_oca_special_prorate, built to their exact pattern: auto_install=True, depends on both sides, data-only.

Contents. A single data file extending the official l10n_es_aeat_mod349.aeat_349_map_line_A/_I records with the 9 prorate tax templates (p_priva{4,10,21}_ic_bc/_ic_bi on A, p_priva{4,10,21}_sp_in on I) via idempotent (4, ref(...)) additions.

No migration needed — but existing databases need an explicit install. Membership is stored on the template itself (tax_tmpl_ids is a one2many; the inverse many2one lives on account.tax.template), so on databases where the client module already wired these taxes the values persist and this module simply re-asserts them idempotently. On fresh databases auto_install wires everything whenever both dependencies are installed, in any order. On an EXISTING database, however, -u all never installs a new module — not even an auto_install one (that trigger only fires on install chains and fresh databases; proven in the migration rehearsal of 2026-07-23) — so the deployment pipeline must install it explicitly (-i l10n_es_aeat_mod349_special_prorate) once.

Companion change: oxigensalud/odoo-addons#217 removes the same 9 references (and the then-unused l10n_es_special_prorate dependency) from the client module.

Bridge module wiring the special prorate purchase taxes into the AEAT 349
model tax map (keys A and I). It is the missing 349 counterpart of
l10n_es_aeat_mod303_special_prorate and l10n_es_aeat_sii_oca_special_prorate:
l10n_es_special_prorate cannot declare the 349 membership itself without
depending on l10n_es_aeat_mod349, so the wiring belongs in this auto_install
glue module, installed whenever both sides are present.
eantones added a commit to oxigensalud/odoo-addons that referenced this pull request Jul 23, 2026
…_aeat_mod349_special_prorate

The 9 special prorate tax references on the official 349 map lines A/I were
client-side glue between two generic modules: l10n_es_special_prorate cannot
declare 349 membership itself (it does not depend on l10n_es_aeat_mod349).
They now live in the new generic bridge module
l10n_es_aeat_mod349_special_prorate (nuobit/odoo-addons#954), the missing 349
sibling of the existing 303/SII prorate bridges. The l10n_es_special_prorate
dependency falls with them: no other reference remains in this module.

No migration needed: on existing databases the m2m rows persist and the
bridge re-adds them idempotently ((4, ref) semantics); on fresh databases
auto_install wires them whenever both sides are installed, in any order.
@codecov

codecov Bot commented Jul 23, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.49%. Comparing base (915c841) to head (21bb17c).

Additional details and impacted files
@@            Coverage Diff             @@
##             14.0     #954      +/-   ##
==========================================
+ Coverage   51.47%   51.49%   +0.01%     
==========================================
  Files        1182     1182              
  Lines       20438    20438              
  Branches     4299     4299              
==========================================
+ Hits        10520    10524       +4     
+ Misses       9661     9658       -3     
+ Partials      257      256       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@eantones eantones added hold merge no merge before Oxigen 18 Do not merge until Oxigen is live in production on 18.0 (migration cutover). and removed hold merge labels Jul 23, 2026
@eantones
eantones marked this pull request as ready for review July 23, 2026 20:15
eantones added a commit to oxigensalud/odoo-addons that referenced this pull request Jul 26, 2026
…_aeat_mod349_special_prorate

The 9 special prorate tax references on the official 349 map lines A/I
(and the 9 tax-xmlid rows that only existed to feed them) were
client-side glue between two generic modules: l10n_es_special_prorate
cannot declare 349 membership itself (it does not depend on
l10n_es_aeat_mod349). They now live in the generic bridge module
l10n_es_aeat_mod349_special_prorate (nuobit/odoo-addons#954), which is
being migrated to 18.0 alongside this branch; on existing databases the
bridge re-creates the membership idempotently and on fresh databases
auto_install wires it whenever both sides are installed.

Unlike the 14.0 counterpart of this cleanup, the l10n_es_special_prorate
dependency stays for now: the 18.0 migration added prorate mappings on
the oxigen_fp_extra fiscal position that still reference its templates;
whether those mappings belong in this module is a separate pending
decision.
eantones added a commit to oxigensalud/odoo-addons that referenced this pull request Jul 27, 2026
…_aeat_mod349_special_prorate

The 9 special prorate tax references on the official 349 map lines A/I
(and the 9 tax-xmlid rows that only existed to feed them) were
client-side glue between two generic modules: l10n_es_special_prorate
cannot declare 349 membership itself (it does not depend on
l10n_es_aeat_mod349). They now live in the generic bridge module
l10n_es_aeat_mod349_special_prorate (nuobit/odoo-addons#954), which is
being migrated to 18.0 alongside this branch; on existing databases the
bridge re-creates the membership idempotently and on fresh databases
auto_install wires it whenever both sides are installed.

Unlike the 14.0 counterpart of this cleanup, the l10n_es_special_prorate
dependency stays for now: the 18.0 migration added prorate mappings on
the oxigen_fp_extra fiscal position that still reference its templates;
whether those mappings belong in this module is a separate pending
decision.
eantones added a commit to oxigensalud/odoo-addons that referenced this pull request Jul 29, 2026
…_aeat_mod349_special_prorate

The 9 special prorate tax references on the official 349 map lines A/I
(and the 9 tax-xmlid rows that only existed to feed them) were
client-side glue between two generic modules: l10n_es_special_prorate
cannot declare 349 membership itself (it does not depend on
l10n_es_aeat_mod349). They now live in the generic bridge module
l10n_es_aeat_mod349_special_prorate (nuobit/odoo-addons#954), which is
being migrated to 18.0 alongside this branch; on existing databases the
bridge re-creates the membership idempotently and on fresh databases
auto_install wires it whenever both sides are installed.

Unlike the 14.0 counterpart of this cleanup, the l10n_es_special_prorate
dependency stays for now: the 18.0 migration added prorate mappings on
the oxigen_fp_extra fiscal position that still reference its templates;
whether those mappings belong in this module is a separate pending
decision.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no merge before Oxigen 18 Do not merge until Oxigen is live in production on 18.0 (migration cutover).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant