RATIONALE

In order to prepare upcoming improvements for marketing automation
application, as well as performance improvements, some tests are added
to improve coverage and cover some synchronization use cases.

SPECIFICATIONS

Add some tests improve coverage of synchronization, as we recently
discovered limitations

  * "opposite" triggers when checking brother traces to skip in
    'action_update_participants' (which synchronizes traces): sub
    addons (sms, whatsapp) is not taken into account;
  * 'schedule_date' is not correct for user-based activities (e.g.
    mail_open, mail_click, ...) when new activities are added to
    a campaign. They should not have scheduled dates, as it depends
    on user action. Date is correct for activities when participants
    enter child activities but not when doing the synchronize;
  * add some checks on participant state;
  * globally try to improve some corner cases coverage;

Add some tests to improve coverage of bounce / fail behavior with
various activities, as we want to make it clearer how MA should
behave when dealing with issue. First step is to assert current
behavior and fix some odd bits.

Notably in some cases trace update is missing, notably with SMS
sending with does not call trace update method, which means some
triggers are not processed.

Various fixes are included in this branch, spotted by newly added tests.
See commits for more details.

Task-4224152: [marketing_automation] Performance / Scalability

Forward-Port-Of: odoo/enterprise#124248
Forward-Port-Of: odoo/enterprise#124126

Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.

### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.

### Current behavior:
A traceback is raised depending on the field added

#### For the Daily Salary field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
    payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
                                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```

#### For the Integration Factor field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
    payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
    versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
    self.ensure_one()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```

### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.

### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.

target: 19.0
task-6267003

Forward-Port-Of: odoo/enterprise#121718

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

Forward-Port-Of: odoo/enterprise#120184

…nding

When cash rounding is enabled with "Only for cash payment methods", an order partially paid in cash and completed with an online payment could neither request the correct online amount nor be marked as paid.

Steps to reproduce:
- Enable cash rounding (e.g. 0.05, HALF-UP) with "Only for cash payment methods"
- Create an order with a total of 15.28
- Add a cash payment of 10.00, then an online payment for the remainder

The frontend requests 5.28 for the online payment, but as soon as the order contained a cash payment the server rounded the whole order total: get_and_set_online_payments_data() returned an unpaid amount of 5.30 (15.30 - 10.00), so the validation failed with "Invalid online payments".

Even once the online payment of 5.28 was processed, the order remained stuck in draft with the money captured: _is_pos_order_paid() compared the paid amount (15.28) against the rounded total (15.30).

Only the part of the order actually settled in cash must be rounded: non-cash payments (card, online, ...) always pay their exact share.

- get_amount_unpaid() now returns the exact residual of the order when the rounding only applies to cash payment methods.
- _get_rounded_amount() now only rounds the amount not covered by non-cash payments, resolving its old TODO. Cash-only orders and orders where the cash payment settles the rounded remainder are unaffected.

opw-6314690

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

Forward-Port-Of: odoo/odoo#275305

Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.

### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.

### Current behavior:
A traceback is raised depending on the field added

#### For the Daily Salary field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
    payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
                                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```

#### For the Integration Factor field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
    payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
    versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
    self.ensure_one()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```

### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.

### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.

target: 19.0
task-6267003

Forward-Port-Of: odoo/enterprise#121718

When a regular employee accesses the Attendance Gantt view, they encounter an AccessError if there are other employees with flexible schedules who have taken time off.

### **Steps to reproduce:**
- Install hr_holidays, hr_attendance with demo.
- Create a time off and validate for an employee, and set the employee's contract to fully flexible
- As demo user, go to the attendance app.

### **Error:**
```
odoo.exceptions.AccessError: Sorry, Marc Demo doesn't have 'read' access to:
- Time Off (hr.leave)
```

### **Root cause:**
since [this commit](https://github.com/odoo/enterprise/pull/112482/changes/b326263d67dc0654a7d4b6d77dc4ad8de53bc1c1), `handle_flexible_leave_interval` accesses fields on `leave.holiday_id` at [1] to determine the bounds of flexible leave intervals. when the  unavailability computation is performed by a regular employee, they may not have access to the corresponding `leave` record leading to access error.

[1]- https://github.com/odoo/enterprise/blob/7a34c9a6a58df22fbef143d820a29106249e3af5/hr_holidays_gantt/models/resource_calendar.py#L17-L24

### **Fix:**
This commit allows regular employees to compute unavailability intervals for flexible employees.

**opw-6243778**

Forward-Port-Of: odoo/enterprise#119229

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

Forward-Port-Of: odoo/enterprise#120184

Cached functions with `@ormcache` should not return immutable values, yet `_get_parameter_from_code()` could return dicts/sets/lists/etc.

It could lead to very obscure bugs such as:

```python
def some_innocent_code():
    category_dict = self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')
    incapacity_codes = category_dict['partial_incapacity']
    incapacity_codes |= category_dict['total_incapacity']
    # ... then use incapacity_codes

def print_rule_param():
    print(self.env["hr.rule.parameter"]._get_parameter_from_code('l10n_be_work_entry_categories')['partial_incapacity'])

print_rule_param()  # OrderedSet(['LEAVE281'])
some_innocent_code()
print_rule_param()  # OrderedSet(['LEAVE281', 'LEAVE264', 'LEAVE266', 'LEAVE217', 'LEAVE218', 'LEAVE219', 'MEDIC01'])
```

The solution was to either deepcopy the returned value each time, or to change all the rule parameters to their frozen equivalent. Since we don't have access to frozen objects in rule parameters's xml definitions, we opted for the deepcopy approach.

task-6329380

Forward-Port-Of: odoo/enterprise#124141
Forward-Port-Of: odoo/enterprise#123057

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

Forward-Port-Of: odoo/enterprise#120184

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

task-6215466

Forward-Port-Of: odoo/enterprise#122313

### Steps to reproduce:
1. Open any Project > open its Tasks view
2. Open Studio
3. Press the browser Back button

### Current behavior:
Crash "active_id is not defined". The Tasks view needs active_id
(the ID of the open project, e.g. 5) to pre-filter tasks by project,
but it is missing when Studio restores the view from the URL.

### Expected behavior:
Back exits Studio and returns to the Tasks view with no error.

### Issue:
The browser URL tracks navigation as a stack of visited actions. When
Studio is open, the stack has two entries: the view being edited
(position -2) and Studio itself (position -1). Studio loads the action
from position -2 but was reading active_id from position -1 Studio's
own slot, which carries no record ID. Reading context from the wrong
slot left active_id undefined, crashing the view render.

A second problem: Studio was writing active_id into the shared URL
state. The router automatically copies this into the Studio URL path,
changing ".../tasks/studio" to ".../tasks/5/studio". Every Back press
produced a different URL, so the router treated it as a new visit
instead of a Back navigation creating an infinite history loop.

### Fix:
active_id now comes from the same URL slot as the action identity
(position -2), which is where the project ID actually lives. The
shared URL write that caused the history loop is removed.

task-6097949

In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started.

Case 1:
- Have website A and website B
- Create an appointment page website A
- Log in via website B
- As public user, make an appointment in Website A
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url.
This parameter is then used as fallback when we need to retrieve the base url without an active record

Case 2:
- Have website A and website B
- Create an event and assign it to website B
- As public user, access the event and register to it
- Check the generated email

Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event.
This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A)

Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf

opw-4146760
opw-4336369

Forward-Port-Of: odoo/enterprise#123851
Forward-Port-Of: odoo/enterprise#122669

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

task-6215466

Forward-Port-Of: odoo/enterprise#122313

The pay run header card was assembled by kanban XML inheritance and its
responsive behaviour keyed off `ui.size` (the browser-window breakpoint).
Regions shifted from one step to the next, and the free space and the
buttons collapsed based on the window rather than the card's own width -
folding while there was still room and overflowing when there wasn't.

Rework it into a single OWL shell (PayrunCard) that owns four regions -
name | KPIs | steps | buttons. Per-step views only fill the `payrun_kpis`
slot and declare their `current_step`; the name block and step bubbles are
declared once and reused.

The kanban record owns one ResizeObserver that measures the card's actual
width and each region's content width, then resolves the layout in
priority order: the name truncates to its floor, the buttons collapse into
the overflow menu, and finally the steps stack onto their own full-width
row. The decision is recomputed only when the width changes, so toggling
the layout - which only changes the height - cannot feed back and flicker
at the boundary.

task-6259171

## Previous behavior:
Recurrent tasks could still be scheduled on weekends, vacation days, or other non-working days.

## New expected behavior:
Recurrent tasks are always scheduled based on the workable days and working hours of the users assigned to them. Workable days and hours are determined using the assigned users’ shared calendars. If the assigned users do not share the same calendar, the company calendar is used to resolve scheduling conflicts. If a user is on leave, the recurrent tasks they are assigned to are still scheduled, but the user is temporarily removed from the list of assigned users for the duration of their leave.This allows other individuals to take over the task when the user is on leave. Users are also removed from recurrent tasks when their contract start or end dates fall outside the task schedule since users shouldn't work with outdated contracts.

## Exception:
This behavior can be overridden if the original recurrent task was initially scheduled on a weekend day (Saturday or Sunday). In this case, recurrent tasks behave exactly as before and may be scheduled on non-working days. This was made to ensure the end-users could have the final say on this behavior in the case it is unwanted.

## Reference:

[task-4796700](https://www.odoo.com/odoo/project/4105/tasks/4796700)

**Problem:**
On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist).

**Steps to reproduce:**
1. Create a subscription product with a recurring plan.
2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price).
3. Open the product page on the website.

**Current behavior:**
The page fails with a 500: Internal Server Error during price computation.

**Expected behavior:**
The page loads and shows the discounted recurring price.

**Cause of the issue:**
For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion.

**Fix:**
Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record.

opw-6306105

Forward-Port-Of: odoo/enterprise#121466

### Description

Installing or upgrading `l10n_pe_edi` aborts with a `psycopg2.errors.SyntaxError` whenever `account_move` already contains rows:

```
psycopg2.errors.SyntaxError: syntax error at or near "AND"
LINE 9:                    AND l10n_pe_edi_operation_type IS NULL
```

### Root cause

The `init_storage` SQL that backfills `l10n_pe_edi_operation_type` (added in e182608f13c6 `[REF] *: use init_storage`) closes the `WHERE` clause with a stray semicolon right after the country condition:

```sql
WHERE res_company.id = account_move.company_id
   AND move_type IN ('out_invoice', 'out_refund')
   AND res_country.code = 'PE';               -- stray ';' ends the UPDATE
   AND l10n_pe_edi_operation_type IS NULL     -- parsed as a new statement -> syntax error
```

The semicolon terminates the `UPDATE` early, so `AND l10n_pe_edi_operation_type IS NULL` is parsed as a separate statement starting with `AND`.

`init_storage` only runs when the table already has rows (`_init_column_data` in `odoo/orm/fields.py` skips empty tables), which is why the crash surfaces on databases that already contain journal entries — e.g. runbot `*-all` builds, or `button_immediate_install` over a populated database.

### Fix

Remove the stray semicolon so the NULL guard stays part of the `WHERE` clause.

### Validation

Reproduced and verified on `master` (community + enterprise), with a row present in `account_move`:

- **Before:** `-u l10n_pe_edi` fails with `syntax error at or near "AND"` at `LINE 9`.
- **After:** the module installs/updates cleanly and the column is backfilled without error.

Issue:
The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence 

According to CPA-005 standards on the Item Trace Number:
"The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36).
https://www.payments.ca/sites/default/files/standard005eng.pdf

Steps to reproduce:
1. Install the module l10n_ca_payment_cpa005
2. Go into "CA Company"
3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC"
4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal
5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence
6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error)
7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT"
8. Create a batch payment for both payments created
9. Validate the batch payment and the export file should show up in the chatter
10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence

Solution:
Set the Item Trace Number to be the payment's id

opw-6323432

Forward-Port-Of: odoo/enterprise#124016
Forward-Port-Of: odoo/enterprise#123633

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#123817
Forward-Port-Of: odoo/enterprise#114876

## [FIX] sale_renting_planning: check global leaves working schedule

Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.

After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.

if the leave has no `calendar_id` then the leave applies to all `resource.calendars`

if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well

## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones

This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.

It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.

task-6179505

Forward-Port-Of: odoo/enterprise#120983
Forward-Port-Of: odoo/enterprise#116430

Steps to reproduce:
------------------------------------------------
1. Install Event module
2. Create a multi day event
3. Create one attendee for the event
4. Change the event dates
5. Go to attendee and Click on Send by Email

Observation:
------------------------------------------------
The event start date displayed in the email body is not updated after the event dates are modified.

Issue:
------------------------------------------------
In `saas-18.2`, `event_begin_date` and `event_end_date` were simple related fields that automatically updated when their source fields changed. https://github.com/odoo/odoo/blob/saas-18.2/addons/event/models/event_registration.py#L57-L58

However, in `saas-18.3`, slots were introduced and these fields were converted to computed fields
https://github.com/odoo/odoo/pull/205945/changes/e2bf8a89d6a50bd40f4673bef38176465f83ba0f

* `event_begin_date` is made stored for cohort view grouping
* However, the base compute method only depends on `event_id` and `event_slot_id`
https://github.com/odoo/odoo/blob/ac37b479321dbe9dbf864e833900e043b1cc70df/addons/event/models/event_registration.py#L177-L180
* When you change `event.date_begin` or `event.date_end`, the registration records don't recompute because the dependency is on the `event_id`, not on the related date fields (`event_id.date_begin`, `event_id.date_end`)
* Non-stored computed fields recalculate on-the-fly when accessed, so `event_end_date` appeared to work
* Stored computed fields only recalculate when their explicit dependencies change

Solution:
------------------------------------------------
* Corrected the dependencies of `_compute_event_begin_date` to recompute
value on changing the date of the event

opw-6284576

Forward-Port-Of: odoo/enterprise#120184

Users frequently use Odoo Studio to display the Daily Salary (`l10n_mx_daily_salary`) and Integration Factor (`l10n_mx_integration_factor`) fields on the payslip form to verify salary rule computations. However, doing so raises a traceback immediately upon closing the Studio editor, as well as when attempting to create a new Off-Cycle payslip.

### Steps to reproduce:
* Install `l10n_mx_hr_payroll` and `web_studio`.
* Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company.
* Go to Payroll > Payslips > Payslips and create a "New Off-Cycle"
* Use the Studio editor to add `l10n_mx_daily_salary` or `l10n_mx_integration_factor` fields.
* Close the Studio editor.

### Current behavior:
A traceback is raised depending on the field added

#### For the Daily Salary field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 21, in _compute_daily_salary
    payslip.l10n_mx_daily_salary = payslip.version_id.wage / payslip._rule_parameter('l10n_mx_schedule_table')[payslip.version_id.schedule_pay]
                                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: False
```

#### For the Integration Factor field:
```py
  File "/Users/ivgm/odev/worktrees/19.0/enterprise/l10n_mx_hr_payroll/models/hr_payslip.py", line 33, in _compute_integration_factor
    payslip.employee_id.with_context(before_date=payslip.date_from)._get_first_contract_date()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 493, in _get_first_contract_date
    versions = self._get_first_versions_filtered(no_gap=no_gap).filtered(lambda x: x.contract_date_start)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ivgm/odev/worktrees/19.0/odoo/addons/hr/models/hr_employee.py", line 461, in _get_first_versions_filtered
    self.ensure_one()
  File "/Users/ivgm/odev/worktrees/19.0/odoo/odoo/orm/models.py", line 5942, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee()
```

### Expected behavior:
No error is raised, and the fields are correctly displayed on the form view.

### Solution:
* Add Guard Clause: When creating a "New Off-Cycle" payslip, `payslip.version_id` is not initially set because no employee has been selected yet. Added a condition to check if `version_id` exists before computing the values to prevent the traceback.
* View Update: Since displaying these fields is a highly requested feature for traceability, they have now been added to the form view.

target: 19.0
task-6267003

# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

### Steps to reproduce:
- Create a subcontracted product P1
- Create a storable product P2
- Buy 5 units of both products from your subcontractor
- On the receipt set both moves quantity to 2 Units
- Validate the receipt and create a backorder
#### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2.

### Cause of the issue:

Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83 https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123 https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91
However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164 This is problematic since picking a move line will also pick the move: https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267 And only picked moves are considered to be processed at picking validation.

### Note:

The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549
However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b

The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding a picked move line on a subcontracted move will still pick that move).

Community: https://github.com/odoo/odoo/pull/275304

opw-6330584

## Issue
When exporting the General Ledger in xlsx format with only one journal selected, the tax declaration lines appear multiple times and are disrupt the overall format of the report.

## Steps to reproduce
1. Install *Accounting* (`account_accountant`) with demo data
2. In Accounting > Reporting > General Ledger, select a single journal (e.g. Customer Invoices) and click the *XLSX* export button.
3. **The resulting XLSX file is incorreclty formated. The tax declaration lines appear multiple times and disrupt the structure of the report.**

<img width="1012" height="603" alt="image" src="https://github.com/user-attachments/assets/1d22e9a1-3fc2-4538-b1bd-4ca1d1bbe092" />


## Cause
Since https://github.com/odoo/enterprise/commit/6a3804c5fe6b4f1d48a4ab311a0f1fbb24d75187, the xlsx report is generated by iterating over the relevant accounts and injecting the lines into the report account by account.

https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_general_ledger.py#L773-L775

The [`_get_accounts_with_move_lines` method](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_general_ledger.py#L814) does not take into account the journals that are requested when exporting .xlxs, which leads to too many accounts being iterated over.

Before that commit, the `_get_lines` method was only called once when generating the xlsx report. This explains the behaviors below, that were not properly adapted to call the method multiple times to generate a single report.

The first issue is that the `_get_lines` method calls the `_dynamic_lines_generator` method, which adds the tax declaration lines after each account when only one journal is selected:

https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_general_ledger.py#L88-L91

To avoid that, we can add a context key to prevent the injection of the tax declaration lines for all iterations, then add the lines afterwards.

Another issue is that the accounts chosen to iterate over do not take the selected journal into account. Without doing so, we iterate over too many accounts, which is inefficient, but which also adds the tax declaration lines (and only those lines) for those irrelevant accounts. That is why the tax declaration lines appear multiple times in the incorrect reports: they were added for accounts that were not supposed to belong in the report.

Lastly, because the total line is added individually, it would not be bold because of the following condition from `inject_lines_into_xlsx_sheeŧ`:

https://github.com/odoo/enterprise/blob/b6d27f428e2b966e38b65e820e1454b711483996/account_reports/models/account_report.py#L5262-L5266

## Performance Impact
Because the commit introducing the issue (https://github.com/odoo/enterprise/commit/6a3804c5fe6b4f1d48a4ab311a0f1fbb24d75187) is a [PERF] commit, the performance impact of this fix was evaluated. The table below shows the time taken to export the XLSX report of the General Ledger for a various amounts of `account.move.line`. Each value represents the average execution time over 10 runs (in milliseconds), with the standard deviation shown in parentheses.

|        | Before (ms)      | After (ms)       |
|--------|------------------|------------------|
| 100    | 321.25 (± 49.56) | 363.43 (± 59.93) |
| 5,000  | 1759 (± 71.87)   | 1773 (± 60.19)   |
| 10,000 | 2723 (± 70.72)   | 2765 (± 106.8)   |
| 50,000 | 11501 (± 170.32) | 11567 (± 165.87) |


opw-5783588

Forward-Port-Of: odoo/enterprise#111826

Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal.

Solution: Extract the basis_qty logic into a helper method so
other localizations can override when needed.

Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill.

Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied.

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

Steps to reproduce:
----------------------------------------------
1. Install Subscription module
2. Create two recurring products with the following configuration:
    * Type: Service
    * Invoicing Policy: Delivered Quantities
    * Set the Sales Price of one product to 0.0
3. Create and Confirm the Subscription having both products
4. Set a delivered quantity on both subscription lines
5. Create and confirm an invoice for the subscription
6. Check the Invoice status in the Other Info tab (Enable Debug mode)

Observation:
----------------------------------------------
1. Invoiced Quantity remains 0 for both products
2. Invoice status remains 'To Invoice' instead of 'Fully Invoiced'

Issue:
------------------------------------------------
`_compute_qty_invoiced` internally reads `order_id.next_invoice_date` (via `_get_subscription_qty_invoiced`) to determine the billing period window used to match invoice lines.
https://github.com/odoo/enterprise/blob/21c93f40f3367d3be77d2e78fdee1b7cb6449978/sale_subscription/models/sale_order_line.py#L176-L179 The problem is a timing issue during `_post()`.

1. `sale_subscription._post()` calls `super()._post()` which goes to `_generate_deferred_entries()`
2. For zero-price lines, all deferral moves have `amount_total = 0`, so they get unlinked
https://github.com/odoo/enterprise/blob/21c93f40f3367d3be77d2e78fdee1b7cb6449978/account_accountant/models/account_move.py#L304-L305
3. This unlink triggers an ORM flush which forces `_compute_qty_invoiced` to run NOW, but `next_invoice_date` hasn't been updated yet (it's still the start date)
4. With the stale `next_invoice_date`, the period window is wrong, so no invoice lines match → `qty_invoiced = 0`
5. Control returns to `sale_subscription._post()` which then updates `next_invoice_date` to the correct value, But `_compute_qty_invoiced` is never re-triggered because `next_invoice_date` is not in its `@api.depends`

Additionally, `_compute_invoice_status` unconditionally forces `invoice_status = 'no'` for any line with `price_subtotal == 0`, even after that line has been fully invoiced and delivered.
https://github.com/odoo/enterprise/blob/21c93f40f3367d3be77d2e78fdee1b7cb6449978/sale_subscription/models/sale_order_line.py#L63-L64

Solution:
------------------------------------------------
1. In `_post()`, after updating `next_invoice_date`, explicitly mark `qty_invoiced` for recomputation on recurring lines. This ensures it is recomputed with the correct `next_invoice_date` value
2. In `_compute_invoice_status`, add `and line.invoice_status != 'invoiced'` to the zero-price check so that once a zero-price line is fully invoiced (as determined by `super()`), it retains the 'invoiced' status instead of being overridden to 'no'.

Note:
----------------------------------------------
We cannot add `order_id.next_invoice_date` to the `@api.depends` of `_compute_qty_invoiced` because that would cause manual changes to `next_invoice_date` by users to incorrectly reset `qty_invoiced` to 0 (shifting the period window so existing invoice lines no longer match). This was the exact issue fixed by a prior commit that intentionally removed it from the dependencies.
https://github.com/odoo/enterprise/pull/65203/changes/e126a4008ef164b056b75031f2ec08aeb2bedd14

opw-5941955