[14.0][FIX] account_invoice_same_accounting_date: recompute line balances on multicurrency invoice date change

[eantones]

Summary

• Override _get_accounting_date to return invoice_date for purchase documents (same as core does for sales), using a scoped context flag to reuse super's tax lock date logic without code duplication
• Override _onchange_invoice_date in the prorate module via super() (guaranteed execution order) and add guard to only recompute taxes when prorate taxes exist

Root cause

When a user set invoice_date on a multi-currency vendor bill:

1. Core _onchange_invoice_date called _get_accounting_date(invoice_date) which returned max(invoice_date, today) for purchase documents — same as current date — so _onchange_currency() was NOT called (else branch taken)
2. NuoBiT base module (_onchange_invoice_date_accounting) set date = invoice_date but didn't recompute line amounts
3. NuoBiT prorate module unconditionally called _recompute_dynamic_lines(recompute_all_taxes=True) which recomputed ONLY tax lines at the new date (invoice_date rate)

Result: base lines stayed at the creation rate, tax lines moved to the invoice_date rate. This rate mismatch caused SII error 1242 on intra-community USD invoices (reported on invoice 2026/00934).

Fix approach

Base module: override _get_accounting_date so it returns invoice_date (after tax lock date check) for purchase documents — the same behavior core already has for sale documents. This makes the core's _onchange_invoice_date detect the date change and call _onchange_currency(), which recomputes ALL line debit/credit at the correct exchange rate. To avoid duplicating the tax lock date logic from super, we use a scoped context flag that makes is_sale_document() return True during this specific super call only, routing through the sale branch.

Prorate module: override _onchange_invoice_date via super() instead of having a separate onchange handler (which had no guaranteed execution order). Add guard to only call _recompute_dynamic_lines(recompute_all_taxes=True) when the invoice has taxes with prorate=True — this was the direct cause of the rate mismatch on non-prorate invoices.

Test plan

• Create a USD vendor bill with invoice_date = today
• Change invoice_date to a past date with a different exchange rate
• Verify all line debit/credit amounts are recomputed at the new date's rate (check Apuntes contables tab)
• Verify base and tax lines use the same exchange rate
• Verify EUR invoices are not affected
• Verify sale invoices are not affected (use original _get_accounting_date logic)
• Verify tax lock date: set invoice_date before tax_lock_date on an invoice with taxes → accounting date should be tax_lock_date + 1
• Verify prorate invoices: change invoice_date → prorate percentage should recalculate for the new date
• Verify non-prorate invoices: change invoice_date → no unnecessary full tax recomputation

[codecov]

Codecov Report

❌ Patch coverage is 76.92308% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.53%. Comparing base (a9120c5) to head (93f60bf).
⚠️ Report is 2 commits behind head on 14.0.

Files with missing lines	Patch %	Lines
...ame_accounting_date_prorate/models/account_move.py	25.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             14.0     #863      +/-   ##
==========================================
- Coverage   50.56%   50.53%   -0.03%     
==========================================
  Files         979      979              
  Lines       16678    16685       +7     
  Branches     3555     3558       +3     
==========================================
- Hits         8433     8432       -1     
- Misses       8029     8034       +5     
- Partials      216      219       +3     

☔ View full report in Codecov by Sentry.
📢 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.