ZATCA Phase 2 E-invoicing requires each invoice to carry an Invoice Counter Value (ICV) and a Previous Invoice Hash (PIH), forming a cryptographic chain of documents per device (journal).

When ZATCA fails to respond to a submission (timeout or other exception), the document is marked unknown since its actual outcome on ZATCA's side can't be confirmed. Retrying such a document previously regenerated the XML from scratch, producing a new UUID and signature. If ZATCA had in fact processed the original submission, this risked creating a second, divergent version of the same invoice within the chain.

This commit stores the signed XML at the moment a document goes unknown and reuses that exact file on every subsequent retry, rather than regenerating it:
- A document that returns unknown saves its submitted, signed XML as an attachment
- Retrying an unknown document resends that same attachment unchanged, so retries are idempotent and cannot fork the chain
- Documents previously stuck in unknown state without a stored attachment are backfilled via a migration, bringing existing data in line with the new behavior
- The now-unused chain-blocking mechanism and its supporting field are removed, since a document's own stored attachment is sufficient to guarantee a safe, consistent retry
- Only the latest log per document is now actionable (Retry/Process); previously every historical log could show these buttons, letting users retry outdated attempts instead of the current one.

Related PR: https://github.com/odoo/upgrade/pull/10887
taskID-5359557

As some shifts could be split and scheduled at different dates when using the side panel drag & drop feature (happens if there are some unavailabilities in the working schedule or other planned shifts at that time);
In some situations, it can be tedious for the user to undo the scheduling and return to the initial state.
To do that, the user would need to manually unschedule the shifts that were planned, set back the allocated hours, etc

To prevent this, we introduce an "Undo" notification button that appears after scheduling a shift (i.e., event) from the side panel, allowing you to easily return to the initial state (as we do in most planning actions, like rescheduling or splitting a shift in two).

We also moved the logic of the "Plan" dialog that shows up when clicking on an empty cell from sale_planning to the planning module.
Thus, we adapted the undo logic to work in batch to handle multiple shifts being scheduled at once.

Follow-up of this PR: https://github.com/odoo/enterprise/pull/112009

task-6303828

[IMP] web, html_editor, mail: move icon metadata in `web`
---
__Before commit__

All the icon logic is in `web` except for `ms_icons.py`, which
contains icon codepoints and search terms. It was originally put
in `html_editor` because it was mainly used by the Media Dialog.

However, `web_studio` also has an icon selector, `ai_website` uses
it inside a model and reimplements a search method, and the
codepoints are used by `mail`.

__After commit__

- `ms_icons.py` is moved to the root of `web` since it can be used by
  controllers and models across the entire codebase.
- A search method is added to it so `ai_website` doesn't have to
  write its own.

[IMP] web, html_editor, mail: use ligature for `odoo_ui_icons`
---
__Before this commit__

`odoo_ui_icons` was generated on fontello.com without ligatures. This
meant that a CSS file had to map every icon name to a custom Unicode
character.

__After this commit__

The Fontello config is stored in the repository. Based on this config,
`generate_icons.py` generates a WOFF2 font that contains icon
ligatures and a WOFF1 font, which is only used in the backend and
includes both ligatures and codepoints.

We can therefore remove the frontend CSS mapping, centralize all icon
metadata in `icons.py`, and simplify the code exclusive to Odoo UI
icons.

This PR is a first step into the cafeteria plan implementation.
It creates some properties on the version:
- net_contribution: which is an amount taken from the net to cover exceeding benefits costs.
- salary sacrifice: which represents the amount that the employee willingly sacrifices from his.her gross.

Both are used in the payroll process.
Salary sacrifice is used because ONSS is due on that.
Net contribution is a simple deduction from the net total.

Those values are just stored but not computed.
They're supposed to be filled after the salary config flow is complete.

Updating the salary sacrifice does not trigger any recomputation.
The net contribution though has an impact on the yearly_cost : if more of the benefit cost is covered by the employee, it means that the employer cost is lowered. Updating the net contribution has an impact on the yearly_cost, just as updating benefits on the employee's form has an impact on the yearly_cost (in that case, an increase).

task-6313710

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/2b1e397c1c [REL] 19.5.0-alpha.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/b85fb02778 [FIX] search and replace: manage invalid range [Task: 6483222](https://www.odoo.com/odoo/2328/tasks/6483222)
https://github.com/odoo/o-spreadsheet/commit/b786cb49ed [MOV] clipboard: move clipboard store to correct folder [Task: 6389205](https://www.odoo.com/odoo/2328/tasks/6389205)
https://github.com/odoo/o-spreadsheet/commit/873b9b4a20 [REF] clipboard: transform the clipboard into a store [Task: 6389205](https://www.odoo.com/odoo/2328/tasks/6389205)
https://github.com/odoo/o-spreadsheet/commit/e4f76b9720 [FIX] carousel: cannot add non-existing chart to carousel [Task: 6455790](https://www.odoo.com/odoo/2328/tasks/6455790)
https://github.com/odoo/o-spreadsheet/commit/1fbd77fa5d [FIX] calendar chart: wrong groupBy choice filtering [Task: 5358625](https://www.odoo.com/odoo/2328/tasks/5358625)
https://github.com/odoo/o-spreadsheet/commit/56dd9da741 [REF] print: use an iframe to print the spreadsheet [Task: 6466136](https://www.odoo.com/odoo/2328/tasks/6466136)
https://github.com/odoo/o-spreadsheet/commit/fe65c382c5 [IMP] draw_grid: explicitly reset transform [Task: 6466136](https://www.odoo.com/odoo/2328/tasks/6466136)
https://github.com/odoo/o-spreadsheet/commit/f6cc865beb [FIX] grid: hide AddRowFooter when the mainViewport is too small [Task: 6103620](https://www.odoo.com/odoo/2328/tasks/6103620)
https://github.com/odoo/o-spreadsheet/commit/3418890d8e [FIX] print: always print in light mode [Task: 6432165](https://www.odoo.com/odoo/2328/tasks/6432165)
https://github.com/odoo/o-spreadsheet/commit/e3f0d8100c [FIX] charts: some charts cannot be aggregated [Task: 6501177](https://www.odoo.com/odoo/2328/tasks/6501177)
https://github.com/odoo/o-spreadsheet/commit/d0227ba203 [FIX] print: handle hidden headers [Task: 6332587](https://www.odoo.com/odoo/2328/tasks/6332587)
https://github.com/odoo/o-spreadsheet/commit/59860bf2de [FIX] xlsx: fix geo chart xlsx export [Task: 4632983](https://www.odoo.com/odoo/2328/tasks/4632983)
https://github.com/odoo/o-spreadsheet/commit/929d44602d [FIX] composer speech_bubble: move after rendering [Task: 6484405](https://www.odoo.com/odoo/2328/tasks/6484405)
https://github.com/odoo/o-spreadsheet/commit/fb3300f036 [IMP] package: update owl to alpha 49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/2c7276afad [IMP] *: set button border radius to 4px [Task: 5086089](https://www.odoo.com/odoo/2328/tasks/5086089)
https://github.com/odoo/o-spreadsheet/commit/1de94c295d [IMP] formatLargeNumber: throw Error instead of EvaluationError [Task: 6306250](https://www.odoo.com/odoo/2328/tasks/6306250)
https://github.com/odoo/o-spreadsheet/commit/1bcd848606 [FIX] hover_overlay: avoid useless render [Task: 6526551](https://www.odoo.com/odoo/2328/tasks/6526551)
https://github.com/odoo/o-spreadsheet/commit/a177d96fd5 [FIX] carousel: increase bottom padding [Task: 6481993](https://www.odoo.com/odoo/2328/tasks/6481993)
https://github.com/odoo/o-spreadsheet/commit/4b77d5f79f [FIX] ComposerHighlight: Highlight the correct sheet with `#` [Task: 6527596](https://www.odoo.com/odoo/2328/tasks/6527596)
https://github.com/odoo/o-spreadsheet/commit/88fdc912e8 [FIX] clipboard: typo on copy/paste on a merge [Task: 6515850](https://www.odoo.com/odoo/2328/tasks/6515850)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**PURPOSE**
- The Italian invoice PDF should contain the relevant information available in 
  the FatturaPA XML, such as the payment method, fiscal code, 
  and reference document.
- The SdI payment method should also be derived from the customer's configured 
  payment method instead of being manually selected or overridden during payment
  registration.

**SPECIFICATION**
- Map Odoo payment methods to their corresponding SdI payment codes.
- Automatically set the SdI payment method on new customer invoices based on the
  customer's configured payment method.
- Remove the payment-registration logic that overrides the SdI payment 
  method based on matched or linked payments.
- Use the payment method already set on the vendor bill when opening the 
  payment registration wizard.
- Improve the Italian invoice PDF to display the missing information, 
  including payment method, fiscal code, and reference document.

Task [link](https://www.odoo.com/odoo/project.task/6107170)
task-6107170

## [FIX] web_map: allow to define field/popover in any order in map view

Before this commit, it was not possible to add field below the popover
element in the map view definition. It was also not possible to define a
field without string attribute. However, if the string attribute is not
given, the string is found thanks to the fields_get, so the string
attribute can be optional.

This commit improves the rng file for the map view to accept to add
field after the popover to be able to add a field with such xpath:

```xml
<xpath expr="//map" position="inside">
    <field name="x_coucou"/>
</xpath>
```
this commit also makes string attrbitue optional for field inside the
map view definition.

## [FIX] planning: wrong order for planning manager

## [IMP] planning{_field_service}: harmonize card popover in calendar/gantt/map

This commit adds the card view in calendar/gantt/map to be able to have
the same card view in popover of those views but also in the kanban
view. This commit also refactors a bit the code to avoid having to
duplicate the code in all those views.

## [IMP] planning_field_service: rename view itinerary and sign in buttons

This commit renames `View Itinerary` into `Navigate` to reduce the size
of the button and also renames `Sign In` button into `Start` to facilitate
the understanding of the purpose of that button.

## [FIX] planning_field_service: correctly restore the menu items in planning

Before this commit, when the field service feature is uninstalled, the
menuitems in planning are not reset as they should be in planning module
and so those menuitems are no longer linked to the planning app.

This commit adds an uninstall_hook to reset the menuitems to their
expected state when only planning is installed.

## [IMP] planning_field_service: improve sign in on open shift

Before this commit, when the user signs in on an open shift, the shift
state is changed to in progress but the shift remains unassigned.

This commit assigns the current user who signs in the open shift to make
sure a resource is assigned to continue the process.

task-5999286

[IMP] ai_website: use aiClientToolsRegistry

PR [1] introduced a more convenient way to call client tools, which does
not rely anymore on the bus and allow the AI agent to receive a response
from the tool executing in the user browser.

This commit implements this new method for the tools defined in
`aiWebsiteBuilderPlugin`.

[1]: https://github.com/odoo/enterprise/pull/122477

task-6487866

---

[IMP] ai_website: make agent aware of failed edits

Before this commit, the AI agent was not aware of failures generated in
`aiWebsiteBuilder.applyActions()`. This meant that the agent was giving
a positive feedback to the user edit requests, even if they failed.

After this commit, `applyActions()` reports per action what the editor
dropped.

task-6487866

---

[IMP] ai_website, *: lock the builder UI for the whole AI turn

*: ai_html_builder
Before this commit, `Thread.post` in `ai_website` ran the post promise
inside the builder mutex. The lock was therefore held by `post` for the
whole AI turn.

After this commit, the loading screen shows the loading effect and
blocks the page for the whole turn, this way there won't be any
flickering.

task-6487866

Circular 99/2025/TT-BTC (effective FY2026) replaces Circular 200/2014/TT-BTC. It renames the Balance Sheet to "Báo cáo tình hình tài chính" (Statement of Financial Position); the report's account mapping is otherwise unchanged, so only the Vietnamese title needs updating.

The Profit & Loss statement (Mẫu B02-DN) gains a new mandatory line, "Lãi/lỗ của hoạt động bán, thanh lý bất động sản đầu tư" (mã số 21), computed from the new 5117/6327 sub-accounts (see the paired l10n_vn commit). Financial income, financial expenses and the interest memo line shift to mã số 22/23/24 accordingly, the "Net profit from operating activities" formula is updated to include the new line, and all following line numbers/labels are renumbered to match the printed form.

Also, per revised guidance:
- Revenue and cost of goods sold now exclude the new investment property sub-accounts (5117/6327), so those amounts aren't double-counted between the main lines and the new gain/loss line.
- Other income is now computed from the "income_other" account type instead of a hardcoded account code, matching how the chart of accounts already classifies it.
- The "Percentage of" comparison option is hidden on both reports: it silently no-ops as soon as a report declares more than one column (both reports have a Code column alongside Balance), and there's no per-report way to make it work without a core account_reports change.

Task-6518304

See: https://github.com/odoo/odoo/pull/287549

Previous this changes, the CFDI import had some limitations:
    - Missing description when importing Conceptos with a product that didn't exist in database
    and also the lookup didn't consider when a product reference is from the vendor
    - Not a strong validation when importing CFDI (a different RFC, wrong journal, etc.)
    - Missing information to be imported due to recent changes
    - Wrong criteria to search for a partner when is a foreign Invoice or to public
    - No support for local taxes
    - Failed to match amounts when taxes are hidden or doesn't match database tax configuration.
    - Repetitive error messages or not a complete description on what failed mainly on tax import
    and when a document is not valid
    
After this commit, now:
    - The lookup of products considers the vendor information and if no product is found,
    the description of the Concepto is used instead
    - Improved the validation when a CFDI is not valid and a message explaining why
    - Added missing information
    - Improved partner search to not search by a generic RFC but for the Registration number
    - Added support for local taxes. This will be created as new invoice lines with a generic tax.
    - Tax amounts are fixed by forcing the tax lines to have the values of the CFDI. For the untaxed
    amounts, a rounding line will be created

Also the structure of the import workflow is changed to use the new helpers for edi import

task-4399021

Steps to reproduce:
- Create an attribute "Size" with values M and L, variants creation mode "Dynamically", and an extra price of 10 on L
- Create a product at 30 using that attribute, and give the L variant a barcode
- In the PoS, type that barcode in the search bar and click the card

Issue:
The line is added at 50 instead of 40. Scanning the barcode with a barcode reader was fixed by c1ae3261e895, but resolving the variant from the search bar still charges the extra price twice.

Cause:
The lst_price of a variant already contains the extra price of every attribute value that creates a variant ('always' and 'dynamic'); only 'no_variant' extras are missing from it and have to be carried by the order line as price_extra. This is what ProductConfiguratorPopup does, hence the correct price when the configurator opens.

Both openConfigurator(), when the resolved variant leaves a single value per attribute line and no popup is needed, and handleConfigurableProduct(), when configure is false, filter those values with create_variant !== 'always', so a 'dynamic' extra is added on top of a lst_price that already includes it. The same fix was made in 18.0 by d4fabfa08d1c but was lost when pos_store.js was refactored in saas-18.1.

Fix:
Filter on create_variant === 'no_variant' in both places, like the configurator popup. This supersedes the !opts.code condition of c1ae3261e895: product_template_variant_value_ids never holds 'no_variant' values, so the extra is now ignored however the line was added - scan, barcode search, sale order import or optional product.

opw-6531114

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#286460

[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) 

The Time Off gantt only greyed a employee ordinary calendar days off,
never the days a window shows that no version covers at all: before
the employee was hired, after they left, or in a gap between two
contracts. Those days rendered as plain available cells, letting time
off be requested outside any contract.

[[MOV] sale_timesheet_enterprise: move employee chat widget from hr](https://github.com/odoo/enterprise/commit/c56a47aa3e2693d58f2e37356da547332caf012f) 

The hr_employee_chat widget is now only used here
(edit_billable_time_target_views.xml), so bring it into this module
instead of leaving dead code behind in hr.

[[IMP] hr_payroll, l10n_in_hr_payroll: don't block payslip printing on warnings](https://github.com/odoo/enterprise/commit/0ddce9b40c204d2f31539eff17681ee12e2c02f2) 

Steps to reproduce:
- Go to an employee
- Put it as anomaly
- Go to the payslip
- Unable to print it

action_print_payslip refused to print any payslip carrying a
danger-level warning (error_count)

The check was added to work around a report crash for employees
without a running contract (comparing a date to a False contract
start raised a TypeError). That crash is already fixed directly in
the payslip template's own guard, so blocking print entirely is no
longer needed to avoid it.

task-6563733

In odoo/enterprise#98816 the MX invoice pdf was modified to be an exact representation of the generated CFDI document (MX EDI doc). Some info was not considered during the implementation: local taxes and export type value. This causes the pdf total amounts to not match when generating the PDF when using local taxes.

How to reproduce (using demo data for easy testing):
- Install l10n_mx_edi with demo data and select `INNOVACION Y DESARROLLO...` demo company
- Go to Accounting > Configuration > Taxes
- Copy tax 16% (VAT(16%)) and under `Advanced Options` tab change SAT tax type (l10n_mx_tax_type) to Local
- Go to Accounting > Customer > Invoices and use one of the draft invoices to INMOBILIARIA CVA.
- Add the new tax under the existing line.
- Post invoice and send to show Send wizard. Disable the email option and enable CFDI one if not set and generate CFDI.
- Generated PDF will not have the local taxes on their totals and also exportacion value is not there

This commit adds the local taxes at the tax totals table and export type value.

task-6477478

Forward-Port-Of: odoo/enterprise#128145

**Description of the issue/feature this PR addresses:**
If a field is `computed`, `precomputed`, and has `groups` defined, an `AccessError` is raised when a user who does not have the required group creates a record because the field is precomputed.

After this commit https://github.com/odoo/odoo/pull/201565/changes/48521a311a6dc857c3808db70ed359c7866aa125, Odoo checks field access in `__get__`, so an `AccessError` is now raised. If the field is not precomputed, everything works fine. Therefore, this commit prevents the error by using `sudo()` to recompute the value.

I have attached a module to demonstrate the issue.

**Steps to reproduce the issue:**

1. Install the attached module. [sale_margin_security_test.zip](https://github.com/user-attachments/files/31967357/sale_margin_security_test.zip)
2. Create a sales order and add a product.
3. Try to save the sales order. The AccessError is raised.

https://github.com/user-attachments/assets/54c7e4e2-005f-4ced-bb62-22d0e00049d9

For more context, this module is a simple example extracted from the OCA `sale_margin_security` module, which inherits from a mixin and adds groups to the fields: https://github.com/OCA/margin-analysis/pull/285

You can see the error in this PR: https://github.com/OCA/margin-analysis/actions/runs/34254749207/job/102157600233?pr=285#step:8:126

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#287257

[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) 

The Time Off gantt only greyed a employee ordinary calendar days off,
never the days a window shows that no version covers at all: before
the employee was hired, after they left, or in a gap between two
contracts. Those days rendered as plain available cells, letting time
off be requested outside any contract.

[[MOV] sale_timesheet_enterprise: move employee chat widget from hr](https://github.com/odoo/enterprise/commit/c56a47aa3e2693d58f2e37356da547332caf012f) 

The hr_employee_chat widget is now only used here
(edit_billable_time_target_views.xml), so bring it into this module
instead of leaving dead code behind in hr.

[[IMP] hr_payroll, l10n_in_hr_payroll: don't block payslip printing on warnings](https://github.com/odoo/enterprise/commit/0ddce9b40c204d2f31539eff17681ee12e2c02f2) 

Steps to reproduce:
- Go to an employee
- Put it as anomaly
- Go to the payslip
- Unable to print it

action_print_payslip refused to print any payslip carrying a
danger-level warning (error_count)

The check was added to work around a report crash for employees
without a running contract (comparing a date to a False contract
start raised a TypeError). That crash is already fixed directly in
the payslip template's own guard, so blocking print entirely is no
longer needed to avoid it.

l10n_in_hr_payroll's payslip templates had the same unguarded comparison
this commit fix it

task-6563733

Ensures that preparation tickets are printed from the correct channel.

- Mobile Self Order => via OBOX
- Kiosk Self Order => via local IP
- Point of Sale => via local IP

Behavor of the self-ordering preparation process depending on the payment
status and the configuration of the PoS.

Self Order mobile (always printed via OBOX):
- EACH PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (via OBOX or preparation display)
- EACH UNPAID: If an order is created and unpaid, it should also create
  a prep order directly from the Self Order if there is NO available
  payment method (via OBOX or preparation display)
- MEAL PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (via OBOX or preparation display)
- MEAL UNPAID: If an order is created and unpaid, it should also create
  a prep order directly from the Self Order (via OBOX or pdis)

Self Order kiosk:
- EACH PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (local IP or preparation display)
- EACH UNPAID: If an order is created and unpaid, it should create a
  prep order directly only if there is NO available payment method
  (via local IP or preparation display)

Ensures that preparation tickets are printed from the correct channel.

- Mobile Self Order => via OBOX
- Kiosk Self Order => via local IP
- Point of Sale => via local IP

Behavor of the self-ordering preparation process depending on the payment
status and the configuration of the PoS.

Self Order mobile (always printed via OBOX):
- EACH PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (via OBOX or preparation display)
- EACH UNPAID: If an order is created and unpaid, it should also create
  a prep order directly from the Self Order if there is NO available
  payment method (via OBOX or preparation display)
- MEAL PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (via OBOX or preparation display)
- MEAL UNPAID: If an order is created and unpaid, it should also create
  a prep order directly from the Self Order (via OBOX or pdis)

Self Order kiosk:
- EACH PAID: If an order is created and paid, it should create a prep
  order directly from the Self Order (local IP or preparation display)
- EACH UNPAID: If an order is created and unpaid, it should create a
  prep order directly only if there is NO available payment method
  (via local IP or preparation display)

Currently, an error occurs when the scheduled action
`Payment: Post-process transactions` attempts to post-process a
payment after performing the following steps:

- Install `website_sale` with demo data
- Enable payment provider `Demo` for testing
- Go to Settings and search for `Order Confirmation`
- Under Email, enter a template name that does not exist (e.g., `Test`)
- Click `Create "Test"` and save the settings
- Go to the website shop, place an order, and complete the payment

Error: `KeyError: False`

Error when user selects `model_id(Applies_to)` as `journal_entry` in the
above `Test` template:
```
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: account.move(1,), User: 1)
```

The issue occurs because clicks `Create "Test"` creates a `mail.template` record
without setting the required `model_id` field. As a result, `render_model`
remains empty, causing an error when `self.env[self.render_model]` is
accessed (see code [1] and [2]).

This commit fixes the above issue by setting `default_model` to `sale.order`
in the context, ensuring the correct model is set when a user creates an
`Order Confirmation` email template. The same change is also applied to
the invoice and rating email templates to ensure the appropriate model is
provided when creating each template.


[1]: https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/addons/mail/models/mail_render_mixin.py#L739
[2]: https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/addons/mail/models/mail_template.py#L125-L128

Sentry-7634490774,7635560002

l10n_es dropped the l10n_es_is_simplified boolean in favour of storing
l10n_es_invoice_type (F1/F2/R1-R5, encoding "simplified" through its own
selection values) and l10n_es_regime_code directly on account.move,
both editable by the user and frozen once the move is posted. These
three enterprise modules still read the removed field, or duplicated
logic that the move itself now already computes and stores.

l10n_es_reports: `_l10n_es_libros_get_operation_code` and
`_l10n_es_libros_get_invoice_type` used to re-derive the AEAT operation
code and invoice type from the move's taxes/is_simplified flag on every
report run, ignoring any manual override a user made after posting.
Read `l10n_es_regime_code`/`l10n_es_invoice_type` straight off the move
instead. This changes two report tests: the OSS/DUA fixtures now carry
their own l10n_es_regime_code (as real OSS taxes do via
l10n_eu_oss.EU_FIELD_MAP), and the purchase-refund libros export now
reports 'R4' instead of the previously hardcoded 'R1', matching what
the move's own compute freezes. Add a regression test asserting a
manually-picked regime code survives action_post().

l10n_es_sale_amazon: port the amazon-order override from
`_compute_l10n_es_is_simplified` (removed) to `_compute_l10n_es_invoice_type`,
forcing 'F2'/'R5' the same way it used to force the boolean to True.

l10n_es_real_estates: rename `cadastral_reference` (the '1'-'4' BOE
location selection) to `real_estate_location`, freeing the old field
name for a genuine Char cadastral reference. Mod. 347 generation is
updated to read the location from its new field name.

task-6175455

## Steps to Reproduce:
- Install the Time Off module.
- Create an Accrual Plan without any milestones.
- Create an Accrual Allocation using the newly created accrual plan.
- Approve the allocation.
- Add a milestone to the accrual plan.
- Create a new Time Off request after the allocation start date.
- Save the record.

## Error:
`TypeError - '>' not supported between instances of 'datetime.date' and 'bool'`

## Cause:
`lastcall` is initialized by method `_add_lastcalls()`, which is only called at create and write. When an accrual allocation is created with an accrual plan that has no milestones, `_add_lastcalls()` returns early because `level_ids` is empty, leaving `lastcall` set to `False`. - [1]

If a milestone is added later, `lastcall` is compared with `first_level_start_date`, resulting in a comparison between boolean and datetime, which raises an error.

## Fix:
When `lastcall` is not set, default it to `first_level_start_date`.

[1] - https://github.com/odoo/odoo/blob/27036bea232572ba692fbb95387911eb453266bf/addons/hr_holidays/models/hr_leave_allocation.py#L703-L706

sentry-7615375197

Forward-Port-Of: odoo/odoo#287331
Forward-Port-Of: odoo/odoo#280674

### Issue:
In Germany, the intrastat report requires region code `99` for dispatch moves where the product origin country is not DE

Per the official specification (section 5.8 — Region of origin): "As for goods with foreign origin, code '99' should be entered"
https://erhebungsportal.estatistik.de/Erhebungsportal/api/assets/files?downloadId=0c5422f111104705b021b41616ad1ecc

But `99` was not being used in those cases

### Cause:
`99` was already the default fallback when no `region_code` is set but `_fill_missing_values` had no condition to override the region code for dispatch moves with a non-DE origin country

### Notes:
While fixing this, two additional issues were found when exporting with the German locale (`de_DE`):
- `weight` and `supplementary_units` are formatted with a comma as decimal separator by the German locale, causing `float()` to raise a `ValueError` — fixed by normalizing to dot before conversion, as done in other localizations
- The dispatch/arrival check was comparing against the translated label (e.g. `'Versand'`) instead of a stable identifier A new `intrastat_type_code` field with static values `arrival` and `dispatch` is added based on the existing `id` values from `default_type`, avoiding locale-dependent comparisons This improvement could be extended to other localizations
- Net mass is now rounded to full kilograms per item (see §5.14 of the specification linked above)
 A weight rounding down to 0 kg is reported as `0` instead of being silently dropped (QWeb `t-out` omits the element when the value is `None`)
Totals are computed as the sum of already-rounded per-item values to stay internally consistent

### Steps to reproduce:
- Install `sale_management`, `l10n_de_account` and `accountant`
- Switch to the DE company
- In Settings, configure the Intrastat values:
-- Default invoice transaction code: 11
-- Default refund transaction code: 21
-- Intrastat region: 07
- Create 3 products with a commodity code set and country of origin: one DE, one empty, one other country
- Create and confirm a Sale Order for all products with a European partner, deliver all, create and send the invoice
- Open the Intrastat report (Accounting > Reporting > Taxes & Fiscal > Intrastat)
- Set the month to the current month

Before the fix, all regions show 07
Expected: non-DE origin products should show 99

opw-6455585

Forward-Port-Of: odoo/enterprise#128747

Before this, SII, TicketBAI and Veri*Factu each re-derived a move's
"TipoFactura" (F1/F2/R1-R5) and "ClaveRegimenEspecialOTrascendencia" at
send time, from `l10n_es_is_simplified` (a boolean guessed from
partner/amount) and ad hoc, slightly different tax-based rules per EDI.
Credit notes needed a manual reason anyway, so each EDI kept its own
private field for it (`l10n_es_sii_refund_reason`,
`l10n_es_tbai_refund_reason`, `l10n_es_edi_verifactu_refund_reason` +
`l10n_es_edi_verifactu_clave_regimen`). None of this was visible or
correctable from the invoice before sending, and an already-declared
move's values could silently drift if its tax configuration changed
afterwards, since they were never actually stored.

Both values now live directly on `account.move` as real fields:
`l10n_es_invoice_type` (replacing `l10n_es_is_simplified`, since a
boolean can't express F2 vs R5 vs a refund reason) and
`l10n_es_regime_code`/`l10n_es_regime_code_additional`. They're
computed once from the move's taxes and the company's special V
regime, editable before posting to correct the odd case the com
gets wrong, and frozen once posted so a declared invoice keeps
what was sent regardless of later changes elsewhere.

`account.tax` gets a matching `l10n_es_regime_code`, filled fro
tax's own chart-template data instead of re-derived from its ty
amount at report time. `l10n_es_applicability` (the tax's AEAT
Impuesto: VAT/IPSI/IGIC) moves from `l10n_es_edi_verifactu` to
alongside it, since it's a property of the tax itself, not of one EDI's
document format, and `l10n_es`'s own regime-code catalog already keyed
off it. This also fixes a silent gap: `l10n_eu_oss`'s EU_FIELD_
already stamped this field on the OSS taxes it generates, but t
only existed when Veri*Factu happened to be installed, so OSS t
a plain Spanish company silently lost their applicability.

SII/TicketBAI/Veri*Factu no longer maintain their own refund-re
field or re-derivation logic: they read `l10n_es_invoice_type`/
`l10n_es_regime_code` straight off the move, and only extend th
catalog (`_l10n_es_regime_code_labels`/`_l10n_es_regime_available_codes`
on `account.tax`/`res.company`) with the codes their own format
each gated behind its own boolean so the EDI's can be installed
together in any order without one silently exposing another's c
The same `l10n_es_invoice_type` field is reused on `pos.order`
TicketBAI/Veri*Factu POS integrations, replacing their own sepa
refund-reason fields there too.

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr