…lit for same-product lines

When doing an intercompany Sale->Purchase with multiple lines having the same products, the receipt picking would be incorrectly assigned:
- Enable Inter-Company Transactions on both companies (Create and validate)
- Create SO in company A to company B with 2 lines having the same product P, Confirm. => Delivery in company A, Purchase and Receipts in company will be created => The SO/PO/Delivery/Receipt will all have 2 lines
- Validate delivery => On the receipt, the 2 units of P are reserved on the 1st move, and the 2nd move is not reserved.


https://github.com/user-attachments/assets/b4816051-120e-4226-9228-fd552649d5ef


---

### Test result without fix:
```
2026-04-23 13:16:44,577 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: Starting TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product ... 
2026-04-23 13:16:44,949 48027 INFO oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: ====================================================================== 
2026-04-23 13:16:44,949 48027 ERROR oes_test_18.0 odoo.addons.sale_purchase_stock_inter_company_rules.tests.test_inter_company_so_to_po: FAIL: TestInterCompanySaleToPurchaseWithStock.test_02_inter_company_multiple_lines_with_same_product
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/sale_purchase_stock_inter_company_rules/tests/test_inter_company_so_to_po.py", line 109, in test_02_inter_company_multiple_lines_with_same_product
    self.assertRecordValues(purchase_from_a.picking_ids.move_ids, [
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/tests/common.py", line 709, in assertRecordValues
    self.assertSequenceEqual(expected_reformatted, record_reformatted, seq_type=list)
AssertionError: Lists differ: [{'pr[18 chars]0, 'quantity': 1.0}, {'product_uom_qty': 1.0, 'quantity': 1.0}] != [{'pr[18 chars]0, 'quantity': 2.0}, {'product_uom_qty': 1.0, 'quantity': 0.0}]

First differing element 0:
{'product_uom_qty': 1.0, 'quantity': 1.0}
{'product_uom_qty': 1.0, 'quantity': 2.0}

- [{'product_uom_qty': 1.0, 'quantity': 1.0},
?                                       ^

+ [{'product_uom_qty': 1.0, 'quantity': 2.0},
?                                       ^

-  {'product_uom_qty': 1.0, 'quantity': 1.0}]
?                                       ^

+  {'product_uom_qty': 1.0, 'quantity': 0.0}]
?                                       ^

```

OPW-6145683

Forward-Port-Of: odoo/enterprise#118805
Forward-Port-Of: odoo/enterprise#114873

When a sale order containing a product with a custom (free text) attribute was settled in POS, the order line displayed the placeholder attribute value name (e.g. "Custom") instead of the actual text entered by the customer.

Steps to reproduce:
-------------------
* Create a product with a free text attribute (create_variant='no_variant', is_custom=True)
* Go to the website's shop (works best in a new private tab)
* Fill the free text attribute and add the product to the cart
* Click on checkout
* In POS, open Quotation/Order and settle the order

> Observation:
the order line shows "Custom" instead of the text

Why the fix:
------------
`SaleOrderLine._load_pos_data_fields` was not exposing `product_no_variant_attribute_value_ids` nor `product_custom_attribute_value_ids`, so the JS `settleSO` function received no attribute data on the `line` object. As a result, the new POS order line was created with empty `attribute_value_ids` and `custom_attribute_value_ids`, leaving `constructFullProductName` unable to find the custom text.

The fix adds both fields to `_load_pos_data_fields` and updates `settleSO` to use them when building the new POS order line. The dynamic fetch path (`_getSaleOrder`) is also updated to explicitly read the `product.attribute.custom.value` records so the data is available for orders loaded at runtime.

opw-5958678

Forward-Port-Of: odoo/odoo#266875
Forward-Port-Of: odoo/odoo#251993

Several error are logged in the chatter when signing a payslip that includes an IMSS disability time off.

Steps to reproduce:
* Install l10n_mx_hr_payroll_account modules
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company
* Go to Employees and open Cesar Osbaldo Cruz Solorzano
* Click on "Time Off" smart button and create a new time off with "Disability due to illness (IMSS)" type for "02/01/2026"(Any date).
* Go to Payroll > Payslips > Payslips and create a new pay run
* Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and the Period '01/01/2026 -> 01/31/2026'
* Click on Continue, select Cesar and click on Select
* Open the payslip, click on "Validate" and "Ok"
* Mark as paid, open the "Journal Entry" from the smart button and click on "Post".
* Back to the payslip, and click on "Generate CFDI" button.
* An error is added to the chatter.

### Missing node to declare disabilities
Original message
```py
An error occurred while signing the CFDI document with the government:
Code : NOM111 Message : Error no clasificado. Extra Info : El nodo
"Incapacidades" se debera informar si se incluye en percepciones la
clave 014 "Subsidios por Incapacidad" o bien en deducciones la clave 006
"Descuento por incapacidad".
```

Translated message
```py
An error occurred while signing the CFDI document with the government:
Code: NOM111 Message: Unclassified error. Extra Info: The "Incapacidades"
(Disabilities) node must be reported if the perception key 014
"Subsidios por Incapacidad" (Disability Subsidies) is included, or if
the deduction key 006 "Descuento por incapacidad" (Disability Deduction)
is included.
```

Legal Context:
According to Mexican law, IMSS disabilities must be declared in a specific XML node.

There are two primary scenarios for reporting these amounts:
* Deduction (Type 006): The employer does not pay for these days, as the IMSS is responsible for the payment to the employee.
  This is the most common scenario.

* Perception (Type 014): The employer pays for these days as a superior benefit. For example, by law, the IMSS does not pay for the first 3 days of a disability due to illness, and employers are not obligated to cover them either. However, companies offering superior benefits may choose to pay these days as a "Disability Subsidy."

Solution:
The chosen approach is to configure the Deduction node.
For the `l10n_mx_regular_pay_imss_disabilities` rule, the `l10n_mx_concept` has been set to `l10n_mx_concept_d6` (D06 - Disability Deduction). This ensures the required node is added.

### Missing "ImporteMonetario" attribute
Original message
```
An error occurred while signing the CFDI document with the government:
Code : NOM95 Message : El atributo Deduccion:Importe no es igual a la
suma de los nodos Incapacidad:ImporteMonetario, ya que la clave
expresada en Nomina.Deducciones.Deduccion.TipoDeduccion es "006".
```

Translated message
```
An error occurred while signing the CFDI document with the government:
Code: NOM95 Message: The attribute "Deduccion:Importe" does not match
the sum of the "Incapacidad:ImporteMonetario" nodes, as the key
expressed in "Nomina.Deducciones.Deduccion.TipoDeduccion" is "006".
```

Problem:
The "Incapacidades" node requires the "ImporteMonetario" attribute, which should represent the sum of the monetary value associated with the disabilities.

Solution:
Add the "ImporteMonetario" attribute and calculate its value using `l10n_mx_daily_salary`.

### Invalid "DiasIncapacidad" format
```py
An error occurred while signing the CFDI document with the government:
Code : 301 Message : XML mal formado Extra Info : Element
'{[http://www.sat.gob.mx/nomina12}Incapacidad](http://www.sat.gob.mx/nomina12%7DIncapacidad)', attribute
'DiasIncapacidad': '4.0' is not a valid value of the local atomic type.
```

Problem:
Altough the defaultdict where the values are sum up, `number_of_days` is
a float field, and when we get back the value, it is a float, adding for
example 4.0 instead of 4, which is not a valid value.

Solution:
Cast the value to int.

### Duplicate deduction on disabilities
```py
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Salary Slip - Cesar Osbaldo Cruz Solorzano - 05/01/2026 - 05/15/2026
- Salary rule: ISR (Income Tax) (ISR)
- Error: TypeError('cannot unpack non-iterable NoneType object') while
evaluating
"
def find_rates(x, rates):
    for low, high, fix, rate in rates:
        if low <= x <= high:
            return low, high, fix, rate

gross = categories['GROSS']
result = 0
if gross:
    isr_table = payslip._rule_parameter('l10n_mx_isr_tables')[version.schedule_pay]
    low, high, fix, rate = find_rates(gross, isr_table)
    result = -((gross - low) * rate + fix)

period_factor = payslip._rule_parameter('l10n_mx_schedule_table')[version.schedule_pay]
if period_factor >= 15:
    period_factor = (period_factor / 30) * (365 / 12)
min_wage = payslip._rule_parameter('l10n_mx_daily_min_wage') * period_factor

if gross <= min_wage:
    result_qty = 0.0
"
```

Problem:
The IMSS disability amount is being deducted twice:
1. During "Worked Days" calculation, the IMSS disability is already not considered because the work entries belong to the "Unpaid Work Entry Types" of "Mexico: Regular Pay" structure.
2. During "Salary Computation", the `IMSS_DISABLE` salary rule deducts another time because it is in the `TAXABLE_ALW` category, and this one is deducted in the `NET` rule.

When the disability covers more than half of the period (e.g., 20 days in a monthly schedule), the double deduction causes the NET to become negative. This prevents the ISR rule from finding a correct stage in the tax tables, leading to a traceback.

Example: For a monthly wage of 30,000.0 and 5 disability days:
- The total amount in "Worked Days" is 25,000.0 (disabilities already deducted).
- The IMSS_DISABLE rule calculates -5,000.0, and when the NET rule is calculated, the disabilities are deducted again. Total NET becomes 16,843.84 instead of the expected 20,834.85.

Solution:
Change the rule category to `INTERMEDIARY_COMPUTATION` and avoid the double deduction when the `NET` is calculated, as it is already considered in the "Worked Days".

### Incorrect values in the XML
The signing process completes without errors, but some amounts in the generated XML are incorrect.

Problem:
The introduction of the Deduction 006 (Disability) directly impacts the calculation of the SubTotal and Total attributes in the Comprobante node.
For a monthly payslip with a wage of 30,000.00 (daily salary of 1,000.00) and 5 disability days (work risk), the values are calculated incorrectly as follows:
Attribute            | Calculation                      | Actual Value | Correct Value
---------------------|----------------------------------|--------------|--------------
Comprobante:SubTotal | Sum of Perceptions (P01)         | 25000.00     | 30000.00 (1)
Comprobante:Total    | SubTotal - Total Deductions (2)  | 15803.74     | 20803.74

(1) Must include the 5,000.00 from disabilities to balance the deduction.
(2) Total Deductions = D06 (5,000.00) + ISR (3,451.65) + IMSS (744.61) = 9,196.26.

The Total is currently undercalculated because the 5,000.00 is being
deducted from the SubTotal that already had those 5,000.00 excluded.

Solution:
Since the `SubTotal` is derived from Perceptions, and the "(P01)
Salaries, Wages, Stripes, and Day Labor" amount is driven by the
`GROSS_WITHOUT_HOLIDAY` rule, the disability amount must be added. This
balances the Deduction 006, ensuring `SubTotal` is correct.

### Absenteeism and Disabilities
By law, the calculation of IMSS contributions depends on these two types of unpaid days:
* Disabilities: Refers to medical leave issued by the Institute (IMSS).
* Absenteeism: Refers to unjustified leave; apply for periods of fewer than 8 days.

Source: [Artículo 31](https://www.imss.gob.mx/sites/all/statics/pdf/leyes/LSS.pdf)
Translated text:
Article 31. When wages are not paid due to the employee's absence from work, but the employment relationship persists, the monthly contribution shall be adjusted according to the following rules:

I. If the employee's absences are for periods of fewer than eight consecutive or non-consecutive days, contributions shall be calculated and paid for such periods only for the sickness and maternity insurance...
If the employee's absences are for periods of eight consecutive days or more, the employer shall be released from the payment of employer-employee contributions...

IV. In the case of absences covered by medical disabilities issued by the Institute, it shall not be mandatory to cover the employer-employee contributions, except regarding the retirement branch.

The following table summarizes the contribution requirements based on the type of absence:
Insurance Branch (RAMA)         | Section I (Absenteeism) | Section IV (Disability)
--------------------------------|-------------------------|------------------------
Sickness and Maternity          | Paid                    | Not Paid
Disability and Life             | Not Paid                | Not Paid
Severance and Old Age           | Not Paid                | Not Paid
Work Risk                       | Not Paid                | Not Paid
Daycare and Social Benefits     | Not Paid                | Not Paid
INFONAVIT                       | Not Paid                | Paid
Retirement                      | Not Paid                | Paid

The type of unpaid day to be considered depends on the specific insurance branch being calculated within the employer-employee contributions.

### Add test for cfdi with disabilities.

target: 19.0
task-6066160

Forward-Port-Of: odoo/enterprise#116819

## Steps to Reproduce:
1. Install the Accounting module.
2. Go to Accounting > Reporting > Executive Summary.
3. Activate debug mode.
4. Click on the gear icon at the top.
5. In the "Options" tab, disable the "Date Range".
6. Open the report again.

## Error:
`TypeError - unsupported operand type(s) for -: 'datetime.date' and 'NoneType'`

## Cause:
At [1], when the "Date range" option is disabled in the summary report, `date_from` becomes None. The NDays expression still computes `date_to - date_from` at [2], which raises a TypeError because subtraction between a datetime and NoneType is not supported.

## Fix:
This commit takes the fiscal-year's start date, when the date-range feature is disabled.

[1] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/account_report.py#L564-L570
[2] - https://github.com/odoo/enterprise/blob/a9cadd93b849375edfcc7fd04612d9eb8787043b/account_reports/models/executive_summary_report.py#L15-L16

sentry-7455506965

Forward-Port-Of: odoo/enterprise#116888

When a user installs only the Invoicing app and creates a new purchase journal, no default_account_id is set on the journal. The Invoicing app does not expose account configuration, so the user cannot fix this manually. As a result, importing a Peppol XML invoice through that journal fails with a database constraint error because the generated account.move.line has a null account_id.

https://github.com/odoo/odoo/blob/16245530f0e3e9be21c8b96baaecd3a679420cac/addons/account/models/account_journal.py#L776-L805 This already auto-creates accounts for bank/cash journals, but does nothing for sale/purchase journals.

Steps to reproduce:
- Install the Invoicing app (no full Accounting)
- Create a new purchase journal with type 'purchase'
- Go to Vendors -> Bills and Upload a Peppol XML file
- Error importing attachment as invoice (decoder=_import_invoice_ubl_cii)

Ticket [link](https://www.odoo.com/odoo/action-4043/6014363)
opw-6014363

Forward-Port-Of: odoo/odoo#267552
Forward-Port-Of: odoo/odoo#252859

**Steps to Reproduce:**

1. Configure the website default language different from the user’s current language.
2. Go to Website → Site → Pages.
3. Duplicate an existing page.
4. Edit the duplicated page and save the changes.
5. Duplicate the edited page again.
6. Observe that the newly duplicated page is generated from the original page content instead of the updated duplicated page.

**Issue:**

When duplicating a website page, the website default language was not passed in the context. As a result, the duplication was performed using the active user language.

The root cause is that `copy()` does not simply duplicate the existing `arch_db` translation dictionary. Instead, it copies the field value in the current language and then rebuilds all translations through `copy_translations()`.

This behavior becomes problematic when `delayed translations` are involved. After a page is modified in a non-default language, the latest changes may be stored in a delayed translation entry (`_{lang}`) while the regular translation value remains unchanged. During the copy process, these delayed translation entries are intentionally discarded because they are considered temporary data and are not treated as valid language translations.

As a result, when the page is duplicated from a non-default language, `copy()` rebuilds the translations using an outdated translation value instead of the most recent content stored in the delayed translation. The newly
duplicated page therefore does not accurately reflect the current state of the source page.

**Solution:**

The fix enables `check_translation=True` during page duplication so that the copy operation uses the latest translation state, including delayed translations when available. This ensures duplicated pages are generated
from the most recent version of the source page and keeps translated content consistent across languages.

**opw-5914281**

Forward-Port-Of: odoo/odoo#264656

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

Forward-Port-Of: odoo/odoo#257294

Issue
-----
Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high.

Steps to reproduce
-----
- Setup Sendcloud delivery method
	- make it available in e-commerce
- Create a 150kg product and publish it
- Go to e-commerce
	- Add the product to cart
	- Checkout the cart

> Traceback

Cause
-----
We retrieve the order's weight through the context.

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108

If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into

https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128

If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow).

https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69

-----
Ticket:
opw-6210398

Forward-Port-Of: odoo/enterprise#119048
Forward-Port-Of: odoo/enterprise#117028

When the stock valuation closing report computes FIFO valuation at a
historical date, it recomputes each move's value via
`move._get_value(at_date)`. For moves without a purchase link (inventory
adjustments, initial inventory), the value falls through to
`_get_value_from_std_price()` which uses the current `standard_price`.

For FIFO products, `standard_price` is recalculated on every stock
operation (`total_value / qty_available`), so the historical valuation
drifts as new operations are processed.

This is the same root cause as https://github.com/odoo/odoo/commit/d2934b59e49ef943d957a80e53cca835a59fabef which fixed it for AVCO's
`_run_average_batch` by passing `forced_std_price`. This commit fixes
the FIFO path by using `move.value / move._get_valued_qty()` (the unit
price stored at validation time) as the fallback in
`_get_value_from_std_price` when `at_date` is set and no std_price was
explicitly forced.

Steps to reproduce (in `odoo-bin shell`, using freezegun's `freeze_time`
to backdate two operations to different dates, e.g. date1 = two days ago
and date2 = yesterday):

1. Create a FIFO periodic product with `standard_price = 10`
2. With `freeze_time(date1)`: apply an inventory adjustment of 10 units
3. With `freeze_time(date2)`: receive 10 units at unit cost 20
   > standard_price shifts to 15
4. Check `product.with_context(to_date=date1).total_value`
   > Before fix: 150 (drifted with current standard_price)
   > After fix:  100 (stable, uses stored move value)

closes opw-6081736

Forward-Port-Of: odoo/odoo#267409
Forward-Port-Of: odoo/odoo#262127

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`.

`classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds.

Steps to reproduce:
1. Open Email Marketing and create a new mailing using the Welcome Message template
2. Select a content block, open Customize, set the background to the 5th theme color
3. Save the mailing
4. Open the Website editor and change the 5th primary color to a different value
5. Reopen the saved mailing in the backend

=> the block's rendered background follows the new website color instead of the one picked at design time

Ticket [link](https://www.odoo.com/odoo/project.task/5892350)
opw-5892350

Forward-Port-Of: odoo/odoo#267570
Forward-Port-Of: odoo/odoo#253934

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.

Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212



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

Forward-Port-Of: odoo/odoo#267234
Forward-Port-Of: odoo/odoo#256636

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

Forward-Port-Of: odoo/enterprise#118832
Forward-Port-Of: odoo/enterprise#112482

Problem:
When the selection is inside a `contenteditable="true"` element that is not the root editable, focusing away does not trigger a save.

Cause:
When the DOM contains a nested contenteditable structure like:

```html
<div class="odoo-editor-editable" contenteditable="true">
  abc
  <div contenteditable="false">
    ac
    <div contenteditable="true">a</div>
  </div>
</div>
```

With the selection inside the inner `contenteditable="true"`, the `blur` event is not triggered on `.odoo-editor-editable` when focusing away, because the active element is the inner div and `blur` does not bubble.

Solution:
Replace the `blur` listener with `focusout`, which bubbles from the inner `contenteditable="true"` up to `.odoo-editor-editable`, allowing `onBlur` to be called correctly.

Steps to reproduce:
- Open Project > Task.
- Add a `/column` block in the description.
- Focus inside any column and write some text.
- Click away to change tab.
- Reopen the description tab.
- The latest changes inside the columns were not saved.

opw-6227922

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

Forward-Port-Of: odoo/odoo#266367

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#119215
Forward-Port-Of: odoo/enterprise#118711

### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

Forward-Port-Of: odoo/odoo#266224

Issue:
----------------------------------------
When searching for a field from `hr.version` without any rights on Employees, we get an access error.

Steps to reproduce:
----------------------------------------
- Timesheet > To Validate > All timesheet
- Filter on Employee > Department (is set for example)
- An error pops up

Cause:
----------------------------------------
The field `department_id` of `hr.employee` belongs to `hr.version` and is accessible through the `_inherits` and the field `version_id`. When doing the search above, during the optimization of the domain, we end up trying to read `department_id` on `hr.employee.version_id`. But the field `hr.employee.version_id` is not accessible to users without Employee access rights. They only have rights on the field  `hr.employee.current_version_id`.

This occurs from version saas-19.1 because the access check was added in this version. ([commit](https://github.com/odoo/odoo/commit/aa58663a271e24a1fcb3f59e6bddfac50054703c))

Solution:
----------------------------------------
We remove the group restriction on `version_id`. The group restrictions are done with the fields of `hr.version`. As `version_id` is only a computed field from `current_version_id` which has `bypass_search_access=True`, this should not expose any field that wasn't already. `bypass_search_access=True` was added on `current_version_id` for the same reason. ([src](https://github.com/odoo/odoo/commit/94bb4a29189400d6bd0c2ca97eba271601262e1b))

opw-6149198 
opw-6251866

Forward-Port-Of: odoo/odoo#264953

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

Forward-Port-Of: odoo/odoo#257294

Problem
------------------
When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce:
1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day)
2. From the allocations view -> New Group Allocation
3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off
4. Go to the newly created allocation The allocation amount is 0.

Reason
----------------------
When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed.

Solution
------------------
Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations.

task-4938695

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#267305
Forward-Port-Of: odoo/odoo#265783

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`.

`classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds.

Steps to reproduce:
1. Open Email Marketing and create a new mailing using the Welcome Message template
2. Select a content block, open Customize, set the background to the 5th theme color
3. Save the mailing
4. Open the Website editor and change the 5th primary color to a different value
5. Reopen the saved mailing in the backend

=> the block's rendered background follows the new website color instead of the one picked at design time

Ticket [link](https://www.odoo.com/odoo/project.task/5892350)
opw-5892350

Forward-Port-Of: odoo/odoo#267570
Forward-Port-Of: odoo/odoo#253934

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Navigate to Invoicing > Vendors > Bills.
- Create a new vendor bill.
- Observe that `GT Document Type` includes `NABN - Nota de Pago Electrónica` option.
- `Confirm` the bill.
- Click `Credit Note`, add a reason, and click `Reverse`.
- Observe the available options in the `GT Document Type` field.

**Observation:**
The `NABN - Nota de Pago Electrónica` option is not available for 
vendor credit notes (`in_refund`), even though `NABN` is a GT-specific 
credit note document type.

**Root Cause:**
At [1], `NABN` is added for vendor bills (`in_invoice`, `in_receipt`) 
instead of vendor credit notes (`in_refund`).

**Fix:**
This commit ensures users can correctly select `NABN - Nota de Pago Electrónica` 
on GT vendor credit notes.

[1]:
https://github.com/odoo/enterprise/blob/c7fa8c9c6f6830f5702fab4f6efaf3ac33f7fe72/l10n_gt_edi/models/account_move.py#L159-L160

opw-6252256

Forward-Port-Of: odoo/enterprise#119215
Forward-Port-Of: odoo/enterprise#118711

### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

Forward-Port-Of: odoo/odoo#266224

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`.

`classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds.

Steps to reproduce:
1. Open Email Marketing and create a new mailing using the Welcome Message template
2. Select a content block, open Customize, set the background to the 5th theme color
3. Save the mailing
4. Open the Website editor and change the 5th primary color to a different value
5. Reopen the saved mailing in the backend

=> the block's rendered background follows the new website color instead of the one picked at design time

Ticket [link](https://www.odoo.com/odoo/project.task/5892350)
opw-5892350

Forward-Port-Of: odoo/odoo#267570
Forward-Port-Of: odoo/odoo#253934

### Description of the issue/feature this PR addresses:
Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets.

### Current behavior before PR:
When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash.

### Desired behavior after PR is merged:
The method now utilizes a hybrid data extraction approach:
- The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids.
- A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query.
- itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries.
The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure.

### Benchmark:

For Memory:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 407MB|
| ~200,000 moves | 1.8GB | 174.8 MB|

For Speed:
| # Input Data | Before PR | After PR |
| -------- | -------- | -------- |
| ~190,000 moves | MemoryError | 5.10s |
| ~200,000 moves | 1m29s| 5.3s|

### Reference:
opw-6067999

Forward-Port-Of: odoo/enterprise#118449
Forward-Port-Of: odoo/enterprise#113227

Before this commit:
---

- Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name.
- If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44).
- However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`.
- As a result, nothing was shown when `summary` was empty, even though `display_name` was set.



Steps to reproduce:
---

- Create an activity in chatter
- Remove the default summary if set.
- Observer the title.

https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045


After this commit:
---

- Added `display_name` to `_to_store` along with `summary`.
- Chatter activity now correctly falls back to `display_name`.
- Users can now see the correct activity label in chatter.




OPW: 6212976



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

Forward-Port-Of: odoo/odoo#266706

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#266383
Forward-Port-Of: odoo/odoo#264272

### Description of the issue/feature this PR addresses:
**Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor.

**Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records.

### Current behavior before PR: 
When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback.

### Desired behavior after PR is merged: 
The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected.

opw-6174628

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

Forward-Port-Of: odoo/odoo#266224

[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
-  Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
  (e.g. `8426904171073`).
- Select the product and trigger the server action:
  `Action -> Get Pictures from Barcode Lookup`

Issue:

**During image fetching:**

-  Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
-  `_get_image_from_url()` assumes the response is always a `requests.Response`
   object and directly accesses:  `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`

**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
     - `requests.Response` for successful requests
     - `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
   response attributes.

**Solution:**
- Make barcode_lookup_request() always return a One Response
  object.
- Move the response validation to the callers instead of returning custom
  dict objects.

**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.

**OPW-6200749**

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#118131
Forward-Port-Of: odoo/enterprise#115760

**Step to reproduce**
Reproducible in single app

The "name" field make this assertion fails: 
```
self.assertRecordValues(sale_order.order_line[0], [{
            "product_id": no_variant_product_tmpl.product_variant_id.id,
            "name": 'No Variant\nAttribute: Value 1',
```
**Observation**
The name will not be the same depending which app are installed, purchase_product_matrix, changes the name of the product if there is a attribute value of a never variant:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase_product_matrix/models/purchase.py#L168-L174
Which will be passed to the purchase_order_line:
https://github.com/odoo/odoo/blob/f399f99d4e0e562d25e1de32336e8d6a55199b9b/addons/purchase/models/purchase_order_line.py#L630-L634
that will pass the information to the sale order:
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L114
https://github.com/odoo/enterprise/blob/bce04ce24b66fb1a2481274eb3aebdc30a62766e/sale_purchase_inter_company_rules/models/purchase_order.py#L125-L126

breaking commit : https://github.com/odoo/enterprise/commit/bf286a0005b8e22ffa717419cd2dfacff861a265
runbot-242362

**Steps to reproduce:**
* install `l10n_lu_reports`.
* Create a company in Luxembourg with a `company_registry` number set.
* Link this company to an accounting firm that is a natural person (independent accountant) with no business registration number — i.e. `l10n_lu_agent_rcs_number` is left empty on the agent partner.
* Go to the tax report and generate the XML declaration.

**Observed behavior:**
* The `<Agent><RCSNbr>` field in the generated XML contains the company's own `company_registry` value instead of `NE`.
* The file is rejected by the Luxembourg tax administration.

**Cause:**
* In `l10n_lu_generate_xml.py`, the `agent_rcs_number` template value was built with a plain `or` chain: `agent.l10n_lu_agent_rcs_number or company.company_registry or "NE"`
* When an agent is set but has no RCS number (natural person), the fallback incorrectly continued to `company.company_registry` instead of stopping at `"NE"`.

**Fix:**
* Use a conditional expression so that `company.company_registry` is only used as a fallback when **no agent is linked** to the company: `(agent.l10n_lu_agent_rcs_number if agent else company.company_registry) or "NE"`

opw-6044689

Steps to reproduce:
-------------------
1. Install Time Off
2. Create an employee with a 38-hour working schedule (7.6h/day)
3. Create a time off type with request unit set to "Hours"
4. Create an allocation for this employee with a duration of 8 hours
5. Observe the allocation title displaying a long decimal value. (e.g., 7.999999999999999)

Issue:
------
The `number_of_days` is calculated in `_compute_number_of_days` using: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L261-L262

For an 8-hour request on a 7.6h/day schedule, this results in ~1.052631579 days.
In `_get_title`, this value is multiplied back to show hours: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L151

This multiplication leads to the long decimal values being displayed in the title.

Solution:
---------
Round the computed duration to two decimal places using `float_round`.

**NOTE:**
This issue is already fixed in saas-19.1 (commit 01d86a7).

However, **no change** is required in the multi-allocation wizard, as the duration
there directly uses user input and is not computed from working hours.

opw-6091424





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

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692

Forward-Port-Of: odoo/odoo#265352

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692