By Mexican labor law, employees are entitled to at least one paid rest day per week (commonly known as the Seventh Day). Depending on the contract, some schedules provide two rest days.

There are two ways to pay this concept:
* Fixed amount: The employee receives the full daily salary regardless of absences (already supported).
* Prorated amount: Applies strictly to weekly and 14-days schedule pays. The payment is proportional to the actual time worked during the period (new feature).

The prorated seventh day is calculated using the following formula: `accrued_days * work_rate * daily_salary`

Where:
* Accrued days: Actual days/hours worked in the period.
* Work rate: A proportional factor based on the rest days and working days per week: `rest_days / working_days_per_week`. Rest days are dynamically calculated using the `hours_per_day` and `hours_per_week` fields from the `resource_calendar_id`.
* Daily salary: Retrieved from the `l10n_mx_daily_salary` field.

EXAMPLE 1: WEEKLY SCHEDULE WITH 1 REST DAY
For a wage of 7,000 MXN weekly (daily wage = 1,000 MXN), the rate is `1/6 = 0.16666`.
The payment depends on the worked days:

| Worked Days | Seventh Day Amount Paid            |
| ----------- | ---------------------------------- |
| 1           | 1 * 0.16666 * 1,000 =   166.67 MXN |
| 2           | 2 * 0.16666 * 1,000 =   333.33 MXN |
| 3           | 3 * 0.16666 * 1,000 =   500.00 MXN |
| 4           | 4 * 0.16666 * 1,000 =   666.67 MXN |
| 5           | 5 * 0.16666 * 1,000 =   833.33 MXN |
| 6           | 6 * 0.16666 * 1,000 = 1,000.00 MXN |

EXAMPLE 2: WEEKLY SCHEDULE WITH 2 REST DAYS
For the same daily wage, but with a 5-day workweek, the rate is 2/5 = 0.4.

| Worked Days | Seventh Day Amount Paid          |
| ----------- | -------------------------------- |
| 1           | 1 * 0.40000 * 1,000 =   400.00 MXN |
| 5           | 5 * 0.40000 * 1,000 = 2,000.00 MXN |

* Add test_cfdi_nomina_con_septimo_dia test

target: master
task-5259458

Steps to reproduce:
- Set the user language to Dutch.
- Go to Accounting > Reporting > Annual Statements.
- Generate the XBRL export for a report other than the "company,
  abridged" (acon) balance sheet/P&L combination, e.g. an association
  (asso_a/asso_f) or "company, full"/"company, capital" report.
- Open the file: the `<met:bln1>` boolean facts are exported as
  "onwaar" instead of "false", which is not a valid XBRL boolean
  lexical value and gets rejected by the NBB validator.

Cause of the issue:
QWeb templates translate static text nodes by default. The base
module ships a generic `msgid "false" -> msgstr "onwaar"` translation,
used elsewhere in the UI, which silently hijacks the literal
"false"/"true" and unit tokens ("iso4217:EUR", "pure") in the XBRL
data templates whenever the file is generated in Dutch.

Solution:
Add `t-translation="off"` on the `<met:bln1>` boolean facts and the
`<measure>` unit tokens in the 5 remaining XBRL templates,
so these fixed-vocabulary XBRL values are never subject to translation

opw-6395785

Forward-Port-Of: odoo/enterprise#124945

To reproduce the issue:

1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
    ====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.

This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.

Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.

Forward-Port-Of: odoo/enterprise#124872
Forward-Port-Of: odoo/enterprise#124811

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#123983
Forward-Port-Of: odoo/enterprise#121693

Steps to reproduce
---
1. Enable Packages and turn on "Move Entire Packages" on the delivery operation type.
2. Create a storable product P and add 2 units in different package in stock: 1 in PACK001, 1 in PACK002 
3. In the Barcode app > Operations > Delivery > New
4. Scan a first package PACK001, then a second different package PACK002
5. Scan the first package PACK001 again.

Issue
---
Re-scanning an already scanned package is meant to be rejected with a "This package is already scanned." warning, but the rejection stops working as soon as a second package is present in the transfer, so the package content gets added a second time and, once validated, the source quant goes negative (the package ends up holding a negative and a positive quant of the same product).

Commit 23613c63947 added a canPackSomeLines flag that is set to true for every package line that is not the scanned one, so any other package in the transfer makes the alreadyDonePackId && !canPackSomeLines guard false and silently skips the warning. The scanned package already exposes whether it had something left to pack through scannedPackages, so gating the warning on that flag instead keeps the check working regardless of how many other packages are in the transfer.

https://github.com/odoo/enterprise/blob/3cc1a162e61662814b0e52c0c720831952d208a8/stock_barcode/static/src/models/barcode_picking_model.js#L1976-L2006

opw-6279105

Forward-Port-Of: odoo/enterprise#125229
Forward-Port-Of: odoo/enterprise#121755

In the ReportEditorIframe component, the iframe may be removed at some point, to be replaced by another one. The problem is that the editor is destroyed only when the new iframe is loaded, so there is a period of time in which the previous editor is alive, but the iframe is destroyed. It can causes issues with plugins, which assumes that we have a valid editable zone. For example, here is a common traceback:

test_print_preview (odoo.addons.web_studio.tests.test_report_editor.TestReportEditorUIUnit.test_print_preview)

Error received after termination: TypeError: Cannot read properties of null (reading 'getComputedStyle')
    at http://127.0.0.1:8069/web/assets/e9a3359/web.assets_web.min.js:16264:290
    at Array.filter (<anonymous>)
    at ToolbarPlugin.getFilteredTargetedNodes (http://127.0.0.1:8069/web/assets/e9a3359/web.assets_web.min.js:16264:201)
    at ToolbarPlugin._updateToolbar (http://127.0.0.1:8069/web/assets/e9a3359/web.assets_web.min.js:16259:83)
    at http://127.0.0.1:8069/web/assets/e9a3359/web.assets_web.min.js:5325:117

The fix is to subscibe to the removal of the iframe, and destroy immediately the editor.

`pos_amount_unsettled` is a stored computed field defined as the invoice's residual minus the settle lines belonging to sessions that are not yet closed. Its compute method filters the lines on `order_id.session_id.state`, but that state is not in the compute dependencies.

When closing a session holding a settle order, `_validate_session()` first reconciles the settle payment with the invoice (which lowers `amount_residual_signed` and flags the field for recomputation) and only then writes `state = 'closed'` on the session. If the pending recomputation is executed in that window (any flush of `account.move` does it: recomputing the field for any other flagged record drags the whole queue along), the settle line is deducted from the already reconciled residual, i.e. counted twice, and the field is stored as `residual - settled` instead of `residual`. Since the session state is not a dependency, writing `state = 'closed'` does not flag the field again and the wrong value is never corrected.

The partner's `invoices_amount_due` then goes negative, which hides the "Settle invoices" option in the POS partner list and inflates the "Settle due amount" proposal
(`remainingDue = total_due - pos_orders_amount_due - invoices_amount_due`): a customer owing e.g. 500 is proposed, and charged, 700.

Steps to reproduce:
1. Post a customer invoice of 1000.
2. In the POS, select the customer > Settle invoices, pick the invoice, set the amount to 700 and pay in cash.
3. Close the session. The issue only occurs when the pending recomputation runs during the closing, which depends on the other operations performed by it (not deterministic in real usage; the regression test forces it with a flush after the reconciliation).
4. The invoice's "Amount To Pay In POS" shows -400 instead of 300 and the POS proposes to settle 700 instead of 300.

Add the session state to the compute dependencies so that the field is recomputed once the session is closed, yielding the correct amount regardless of any intermediate recomputation.

opw-6375095

Forward-Port-Of: odoo/enterprise#123783

Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled.

## Steps to replicate:
- Install stock with demo data
- Barcode Database > Setup barcode lookup credentials
- Users > Marc Demo > Give Marc Demo > Master Data > Products > Create
- Login as `Marc Demo`
- Products > Barcode: `850049670180` > Click anywhere else

## Observed Behaviour:
Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin).

## Root cause:
This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1].
[1]-
https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 
## Why this is an issue:
The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case.

In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6].

As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required.

## Solution:
Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent.
As a result, users no longer need unnecessary administrative privileges toperform barcode lookups.

[2]:
https://www.odoo.com/odoo/project/49/tasks/3911024 
[3]:
https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 
[4]:
https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 
[5]:
https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab 
[6]:
https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a

opw-6290999

Forward-Port-Of: odoo/enterprise#121915

When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.

Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.

e.g. l10n_es_edi_facturae:633:

```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```

Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.

Introduced in: https://github.com/odoo/enterprise/pull/75327.

opw-6378954

Forward-Port-Of: odoo/enterprise#124691

**Description**
Opening the Budget Report from any budget record times out on databases
with significant data volume. The request to
`budget.report/formatted_read_grouping_sets` consistently times out,
making the Budget Report completely unusable.

**Root cause:**
`budget.report` is an SQL view that consists of 5 UNION ALL branches.
When the list view loads, the ORM translates the `budget_analytic_id`
domain into a WHERE clause on the outer query wrapping the full UNION
ALL subquery. PostgreSQL cannot push this filter through a UNION ALL as
it's a hard optimization barrier. It must fully materialize the subquery
regardless of which budget is being viewed.

**Fix:**
Override _search on budget.report to extract budget_analytic_id and
budget_line_id conditions from the incoming domain using the Domain API.
budget_line_id is rewritten as Domain('id', op, value) so _to_sql()
correctly emits bl.id in the raw SQL. The resulting domain is injected
in context under budget_line_domain and read in _get_bl_query,
_get_aal_query (base module), and _get_pol_query (purchase module) to
filter budget_line rows inside each branch's LEFT JOIN ON clause.
This also removes the budget_report_budget_line_ids context key from
budget_line._compute_all, unifying both filters under one mechanism.

---

On customer DB (568k `account_analytic_line`, 27k `budget_line`,
116k confirmed `purchase_order_line`, 114k posted vendor bill lines
with purchase link):

| Budget | Before | After |
|---|---|---|
| 8 lines, 730d span | timeout | 2.27s |
| 14 lines | timeout | 2.39s |
| 14 lines, 1095d span | timeout | 1.63s |

- Before: https://explain.dalibo.com/plan/ehed5eb8de251426
- After: https://explain.dalibo.com/plan/db8aef35cag9hg6f

opw-6098047

Forward-Port-Of: odoo/enterprise#120707
Forward-Port-Of: odoo/enterprise#114692

Issue
-----
Delivery does not always work from/to some cities in Colombia, like Antioquia.

Cause
-----
There was an oversight in fix 7654c55 where only 5 digit postal codes taken from the colombian localisation were padded in

https://github.com/odoo/enterprise/blob/390acf532e8932fd9b9a708382a5e36cdbb35754/delivery_envia/models/envia_request.py#L726-L727

However, some of the colombian cities listed in `l10n_co_edi/data/res.city.csv` have 4 digit codes (like `SANTA FÉ DE ANTIOQUIA`, code `5042`).

https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/l10n_co_edi/data/res.city.csv#L12


These 4 digit codes have to be right-padded to 5 characters before the left-padding to match the official colombian zip codes. See colombian gov official document (PDF download) where the code is actually `05042`.

https://www.dane.gov.co/files/censo2005/provincias/subregiones.pdf

-----
Ticket:
opw-6248252

Forward-Port-Of: odoo/enterprise#123344
Forward-Port-Of: odoo/enterprise#120164

[FIX] documents_{hr|sign}: employee docs button for signed contracts
Bug reproduction:

1 - In saas-19.4, install documents_hr and hr_contract_salary with demo data
2 - As Mitchell Admin, go to Employees, open one, click on "Offers - New"
3 - Select employee_contract.pdf as PDF Template
4 - Use the button "Salary configurator" to fill in the configurator, review it and sign it.
5 - Go back to the backend, find the contract in Sign and sign it.
6 - Go back to the Employee form view, the Documents stat button shows 0 document when it should be 1.
7 - Click the stat button and you see 0 documents in Documents when there should be one.

Bug cause:

1 - The document is created for the employee in documents app
    but smart button cannot open those
2 - The res_model of the documents.document is hr.version for signed doc
    -> it is not hr.employee
3 - In current implementation:
    3.1 -> only hr.employee's documents appear after that smart button

Bug solution:

1 - _compute_document_count is reimplemented:
    -> to count also documents with res_model as hr.version
2 - override _get_documents_domain:
    -> to add version domain as an alternative with OR
        -> to get documents with res_model='hr.version'

Test:

1 - Unit test is added
2 - Create documents with the archived versions of the employee
    -> and observe the document count of the employee

Note:

-> Also, we changed the final document name in documents of the employee

task-6373620

Forward-Port-Of: odoo/enterprise#123763