France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

Forward-Port-Of: odoo/odoo#239576

Issue:
----------------------------------------
The default values aren't kept when using the previous/next arrows in planning calendar view.

Steps to reproduce:
----------------------------------------
- Go on a Project task
- Click the "To Schedule" button
- Switch to calendar view
- If we create now, the new slot will have the task as default value
- Click the arrow to switch to next week
- If we create there will be no default values

Cause:
----------------------------------------
Since 7b844902e5c3a7aeedda6cc2be61366caad2d144 the context is lost when using the arrows.

When switching to calendar view `load()` is called with the context in the params:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/model/model.js#L163-L164

But when using the arrows, it is called with only a date:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/views/calendar/calendar_controller.js#L426

So `...params.context,` is empty, and the context is only `hide_planned_dates: true,`.

Solution:
----------------------------------------
If no context is specified in params, we use the one in `this.meta` to allow changing the context by giving it in the params but keeping the previous context when it's not given.

opw-6211055

Forward-Port-Of: odoo/enterprise#118527

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137

**Steps to reproduce:**
- Create a flexible 32h/week calendar (8h/day, 4 days)
- Assign it to an employee with the Default Ruleset
- Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget)
- Select the list view and go to the month of the attendances
- Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat)

**Cause:**
`resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours.

The two overtime rule paths relies on these synthetic intervals:

1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304

**update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053

2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433

**Solution:**
For flexible calendars in the overtime rule consumer:
- Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period
- Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week)

opw-6067063

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

Forward-Port-Of: odoo/odoo#265976
Forward-Port-Of: odoo/odoo#263840

When we create a product variant and have a pricelist 
which is based on the cost price, and change the cost price, 
the on_sale_price doesn't update. You have the change the price 
list to other and back to the one you want for it to trigger 
change because the _onchange_compute_pricing only gets 
triggered if there's change on pricelist (pricer_sale_pricelist_id), 
and sales price (lst_price).

Steps to Reproduce:
1.Create a pricelist and add a line with "formula" price type, 
and based on "cost",
2.Create a product variant, and add the pricelist
just created.
3.Change the "Cost". The "On Sale Price" doesn't update. 
4.You have to change the price list to some other
and back to the one you want for the "On Sale Price" to update.

To fix the issue, we add the field Cost (standard_price) on 
api.onchange, so when we change the cost it'll
update the "On Sale Price" right away.

opw-5947995

Forward-Port-Of: odoo/enterprise#118584
Forward-Port-Of: odoo/enterprise#111892

### Issue:
When a Sale Order is delivered but later reimbursed (e.g., via a credit note without a return), it is still considered as to invoice
As a result, it continues to impact the partner’s credit limit

### Cause:
Sale Orders remain included in the `credit_to_invoice` computation even when invoicing is manually considered finished
There was no way to exclude such orders from the credit limit calculation

### Fix:
Use the `invoicing_closed` field to mark Sale Orders as fully processed
When set, the order is excluded from the credit limit computation

### Steps to reproduce:
- Install `sale_management`
- In Settings, enable Sales Credit Limit (default: 3000)
- Create, confirm, and deliver a Sale Order for a new customer (any product, price: 2000)
- Duplicate the Sale Order → a credit warning is displayed
- Go back to the original Sale Order and use Close Invoicing from the gear menu
- Return to the duplicated Sale Order
The warning disappears as the closed order is no longer included in the credit computation

### Note:
For a complete business scenario, refer to the steps described in the related ticket

opw-6013369

Forward-Port-Of: odoo/odoo#262720

Currently an error is generated when the user tries to cancel a
draft POS order as follows:

- Install the `pos_enterprise` module with demo data
- Open the register of `Furniture store` and select any product
- Click on the `Upload` icon to save the draft order and go to the backend.
- Navigate Orders > Orders > open Draft order
- Click the `cog` icon and click `Cancel Order` >>> Error occurs

This issue is caused by the recent refactor introduced in [1]. The
`action_pos_order_cancel` action now returns the `order`
(`pos.order` recordset) instead of default returning `None`.

As a result, the `action` variable contains a `pos.order` recordset, and
an error is raised at line [2] when `setdefault` is called on it, since
`setdefault` expects a dictionary-like object.

This commit fixes the above issue by removing the code that returns the
`pos.order` object from the action. As a result, the action now behaves
as expected and returns the default value (`None`).


[1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93
[2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24

Sentry-7354160052

Forward-Port-Of: odoo/enterprise#118035

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#117283

France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

Forward-Port-Of: odoo/odoo#239576

**Steps to reproduce:**
- Accounting > Configuration > Settings > Default Accounts > Product Accounts
- Change the default expense account (and income account)
- Create a new product category
- category still proposed the old accounts

Affected versions: from 18.2 till 19.2

**Cause:**
`ir.default` for `product.category` (`property_account_expense_categ_id` and `property_account_income_categ_id`) was not updated when `res.company.expense_account_id` / `income_account_id` changed, so new categories kept using stale defaults.

and in 19.0
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L490
and
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L753
calls
https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/account/models/company.py#L1136-L1139

However, when stock_account is installed

https://github.com/odoo/odoo/blob/894281f2a3e313fc239529572b5cc8c06a3511f7/addons/stock_account/models/res_company.py#L361-L366

this gets called, without calling super, that's why it didn't work although the fix is there, we will need to adapt another fix in 19.0+

**Solution:**
Call `_set_category_defaults()` in `res.company.write()` so `ir.default` stays aligned with the company's current product default accounts.

opw-6145491

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

Forward-Port-Of: odoo/odoo#265052
Forward-Port-Of: odoo/odoo#261594

Currently an error is generated when the user tries to cancel a
draft POS order as follows:

- Install the `pos_enterprise` module with demo data
- Open the register of `Furniture store` and select any product
- Click on the `Upload` icon to save the draft order and go to the backend.
- Navigate Orders > Orders > open Draft order
- Click the `cog` icon and click `Cancel Order` >>> Error occurs

This issue is caused by the recent refactor introduced in [1]. The
`action_pos_order_cancel` action now returns the `order`
(`pos.order` recordset) instead of default returning `None`.

As a result, the `action` variable contains a `pos.order` recordset, and
an error is raised at line [2] when `setdefault` is called on it, since
`setdefault` expects a dictionary-like object.

This commit fixes the above issue by removing the code that returns the
`pos.order` object from the action. As a result, the action now behaves
as expected and returns the default value (`None`).


[1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93
[2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24

Sentry-7354160052

Forward-Port-Of: odoo/enterprise#118035

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#117283

France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

Forward-Port-Of: odoo/odoo#239576

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#117283

### 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#117577
Forward-Port-Of: odoo/enterprise#113227

France’s electronic invoicing reform : The tax administration  needs structured fiscal data for the transactions , either via E-invoicing for the nationals B2B or E-reporting for the international B2B and the B2C.

This creates two complementary obligations:

- **E-invoicing** for domestic B2B transactions, where the invoice itself is exchanged through the PA/Peppol flow.
- **E-reporting** for transactions outside that domestic B2B scope, mainly B2C and international B2B, where transaction and payment data must be reported to the tax administration through Flux 10 (period-based).

## Scope

Domestic B2B remains handled by the existing e-invoicing flow, because the invoice exchange already carries the required structured information.

Flux 10 is introduced for transactions that must be reported separately:

- B2C transactions, where there is no buyer-side e-invoice exchange.
- International B2B transactions, where the counterparty is outside the French domestic B2B mandate.
- Payment reporting when VAT exigibility depends on collection.

The reporting is period-based and keeps transaction reports separated from payment reports, because they answer different legal obligations and follow different timelines.

## Corrections and Lifecycle

Flux 10 supports both:

- **Initial reports**, for the first declaration of a period.
- **Rectificative reports**, when already reported data must be corrected or completed.

This distinction is needed so corrections remain traceable instead of silently mutating a report that may already have been transmitted.

## Security and Eligibility

This PR also enforces stronger safeguards before using PDP/PA services.

- **2FA is required** because PDP/PA actions expose regulated fiscal flows and should not be available from a simple password-only login. Email-based 2FA is available as a fallback when users have not configured an authenticator app.
- **KYC is introduced** because a company must be identified and validated before Odoo can transmit documents or reports on its behalf through the PDP/PA infrastructure.

Together, these changes make the French PDP/PA flow usable not only for invoice exchange, but also for the wider e-reporting obligations required by the French reform.


Task-4603708

Forward-Port-Of: odoo/odoo#239576

### Description of the issue/feature this PR addresses: 
**Issue:** A recent update to support `certificateFingerprint` introduced a regression for existing users authenticating with standard certificates (AKA `certificateSubject`). Because the matching logic strictly checked for the company NIP within the certificate subject, it failed for users using personal PESEL certificates to act on a company's behalf. 

**Previous PR:** https://github.com/odoo/odoo/pull/264851 

**Solution:** Expanded the string-matching heuristic in the XML signer to strip formatting characters from the NIP and explicitly checks for standard Polish qualified certificate prefixes (VATPL and PNOPL) to accurately get the identifier type.

### Current behavior before PR: 
When a user logs in via a personal PESEL certificate for a company context, the NIP check fails and miscategorizes the payload as a `certificateFingerprint`. KSeF rejects this mismatch, causing a 400 error for previously working setups.

### Desired behavior after PR is merged: 
The authentication flow distinguishes between `certificateSubject` and `certificateFingerprint` by checking for valid Polish prefixes or exact cleaned NIP matches. Existing customers are restored to working order natively, and new customers using manual fingerprints are still supported without requiring any database or UI changes.

opw-6251153

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

Forward-Port-Of: odoo/odoo#267060

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#266969
Forward-Port-Of: odoo/odoo#265783

Thailand withholding tax report only displayed the total withholding tax amount instead of showing extensive information required on PND 3 and PND 53 forms. This commit improves the tax reports by grouping
  withholding tax values into partners and the withholding tax type.
This change improves the report to display more comprehensive data for the users.

Furthermore, previously the PND 3 & 53 report CSV export had hardcoded value on certain columns because the corresponding fields did not exist in Odoo. Now that we have fields required to properly build the CSV export, this commit updates the export logic to generate accurate values for the fields:

- Partner title/company types are no longer hardcoded to "บริษัท". The value refers to the new fields in res.partner.
- The withholding tax condition is no longer hardcoded to "1". The value is determined by the selection field value set on the related payment.
- The tax type no longer depends on the withholding tax's amount value. The value is based on the selection field of the tax.

Additionally, the CSV export delimeter is updated from "," to "|" to prevent data corruption caused by commas often found in the address values.

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

**Steps to reproduce:**
- Install the `l10n_fr_account_loans` module and switch to a `FR Company`.
- Navigate to Accounting > Accounting > Assets & Liabilities > Loans.
- Create a new loan record.
- Click `Add a line`, set a `Date`, and `save` the record.
- Click `Add a line` again.

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

**Root Cause:**
At [1], when adding a line after the record has already been saved with 
at least one existing line, the existing line has a valid `datetime.date` 
value for `l.date`, while the newly created unsaved line still has `line.date` 
set to `False`. This results in a comparison between a `datetime.date` object 
and a boolean value, causing an error.

**Fix:**
This commit prevents the errors when adding multiple lines after saving the 
record by applying a fix similar to [2].

[1]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/l10n_fr_account_loans/models/account_loan_line.py#L21

[2]:
https://github.com/odoo/enterprise/blob/54eef93f295eaebd98d24730d108b1203ca7b35a/account_loans/models/account_loan_line.py#L61-L63

opw-6244973

Forward-Port-Of: odoo/enterprise#118354

__

## Short functional explanation of the error
When we have a subscription product that has already been sold. If we try to import a product with the same ID but where we change the subscription type of the product, the import is executed without issue. However, this leads to undesired behavior:
when we go to the product page and try to manually change the subscription type (set it back to subscription), the change is not applied as a warning is raised.

## Reproduction Steps
Make sure you have debug mode enabled.
1. Create a product, and check the Subscription box.
2. Click on Orders and create a Quotation with this product, then confirm.
3. Go to Products > Products. Select the list view and search for the product you just created. Select it, and click Actions > Export.
4. Check the import compatible field. Select the fields to export: name, id and recurring_invoice. Upon exporting, a file is downloaded.
5. Access that file and change the recurring_invoice to FAUX or FALSE if your computer is in English. Save the changes.
6. Unselect the product and click on the cog, top right > Import. Click on Upload Data File and select the file that you have downloaded upon exporting, then import.

### Expected behavior
A user warning is raised: we shouldn't be able to change the subscription type of the product when it has already been sold.

### Unexpected behavior
The import is processed normally. Then, when we access the product page, and try to check the Subscriptions box again, a warning is raised.

## Origin of the issue
Nothing prevents the import from occurring in that case.

__
opw-6143789

Forward-Port-Of: odoo/enterprise#117318
Forward-Port-Of: odoo/enterprise#115046

The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name` field with an `LIKE` operator.

On databases that has a GIST index on the field `name`, the planner will prefer to filter the records based using the GIST index and add the extra filters as a filtering criteria after the index condition if the index-condition wasn't possible to be switched to a range-query. The condition is supposed to be a prefix-matching, which can be evaluated directly by a B-TREE if the field had an index and the planner can convert the condition to a range-query.

Apparently the `_` in `account_reco_models_fees_%%` was evaluated as a wild-card, making the condition a substring-matching rather than direct prefix-matching. In this PR, I have modified the condition to escape the '_' wildcards.

The benchmark done below was on a database that has around **10^7** `ir.model.data` records and 1K `account.reconciliation.model` records. I have split the benchmark into two cases, a case where the buffer-pool of
postgres warmed-up and a case where it is not.

After Worst case -> https://explain.dalibo.com/plan/975geg1f1h109d5c
Before Worst case -> https://explain.dalibo.com/plan/0ce9bf3g0ad8f98b

After Best Case -> https://explain.dalibo.com/plan/1a77459dadb0gfc4

Definition of ir_model_data_name_idx2  -> CREATE INDEX ir_model_data_name_idx2 ON public.ir_model_data USING gist (name gist_trgm_ops)

Definition of ir_model_data_module_name_uniq_index -> CREATE UNIQUE INDEX ir_model_data_module_name_uniq_index ON public.ir_model_data USING btree (module, name)


| PostgreSQL Buffer Pool Status | Before | After |
| :--- | :--- | :--- |
| Not warmed up (Cold) | 11s | 130ms |
| Warmed up (Hot) | 0.022ms | 0.097ms |

Forward-Port-Of: odoo/enterprise#117746

Issue:
----------------------------------------
The default values aren't kept when using the previous/next arrows in planning calendar view.

Steps to reproduce:
----------------------------------------
- Go on a Project task
- Click the "To Schedule" button
- Switch to calendar view
- If we create now, the new slot will have the task as default value
- Click the arrow to switch to next week
- If we create there will be no default values

Cause:
----------------------------------------
Since 7b844902e5c3a7aeedda6cc2be61366caad2d144 the context is lost when using the arrows.

When switching to calendar view `load()` is called with the context in the params:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/model/model.js#L163-L164

But when using the arrows, it is called with only a date:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/views/calendar/calendar_controller.js#L426

So `...params.context,` is empty, and the context is only `hide_planned_dates: true,`.

Solution:
----------------------------------------
If no context is specified in params, we use the one in `this.meta` to allow changing the context by giving it in the params but keeping the previous context when it's not given.

opw-6211055

Forward-Port-Of: odoo/enterprise#118527

When we create a product variant and have a pricelist 
which is based on the cost price, and change the cost price, 
the on_sale_price doesn't update. You have the change the price 
list to other and back to the one you want for it to trigger 
change because the _onchange_compute_pricing only gets 
triggered if there's change on pricelist (pricer_sale_pricelist_id), 
and sales price (lst_price).

Steps to Reproduce:
1.Create a pricelist and add a line with "formula" price type, 
and based on "cost",
2.Create a product variant, and add the pricelist
just created.
3.Change the "Cost". The "On Sale Price" doesn't update. 
4.You have to change the price list to some other
and back to the one you want for the "On Sale Price" to update.

To fix the issue, we add the field Cost (standard_price) on 
api.onchange, so when we change the cost it'll
update the "On Sale Price" right away.

opw-5947995

Forward-Port-Of: odoo/enterprise#118584
Forward-Port-Of: odoo/enterprise#111892

__

## Short functional explanation of the error
When rescheduling the deadline only of a task that has dependencies, other dependencies won't be moved in time, even if we select `Auto-Reschedule (Keep Buffer)`.

## Reproduction Steps
1. Go to Project. On a given project, click on the 3 dots on the top right of the project card. Then, click settings and under Task Management, check Task Dependencies.
2. Create 2 tasks for this project. On task 1, click on the Deadline field, then click on the top right of the calendar card to set a planned date.
3. On task 2, click on the Blocked By tab. Then, add a line with task 1. Select a planned date like you did with task 1.
4. Go back to the project and on the top right, click on the Gantt view. Make sure that above the calendar, the Auto-Reschedule (Keep Buffer) option is selected. Then, move forward (or backward) the deadline of task 1 by only clicking on the right edge of the pill and dragging/dropping it to the left/right.

### Expected behavior
As task 2 depends on task 1, and we need to keep the buffer. The start date of task 2 should be moved left when we drop the deadline of task 1 further left, or right when we move the deadline of task 1 further right.

### Unexpected behavior
Nothing happens.

## Origin of the issue
### JS side
When we click on the whole task 1 and drag it to the right (thus changing the start date *and* the deadline), the dependent tasks are also moved right. When performing this action, this calls the method `dragPillDrop`. In it, we can see this piece of code: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L1484-L1489 where `this.isAutoPlan` indicates whether we checked the Auto-Reschedule (Keep Buffer) option. In that case, we call `rescheduleAccordingToDependency`, which performs this ORM call: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L500

However, when only moving the deadline of the task, we call the method `resizePillDrop`. In this method, we don't check if `this.isAutoPlan` is True, as we perform in all case the call to: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L2822 Which will trigger the orm call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L479 which will call the `web_gantt_write` method in Python, only writing on the task we changed the deadline of.

### PY side
Inside `web_gantt_reschedule`, to reschedule dependent tasks, we have to reach the method call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L247 However, there's a condition preventing us from reaching that code when only changing the deadline:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L230-L235 Yet, we need to trigger the code and reschedule dependencies even if there's no planned date as soon as we change the deadline.

Once we're in `_web_gantt_action_reschedule_candidates`, we check if we're in the case of preponing or postponing the task (i.e the direction of the rescheduling):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L410 This call is performed with `start_date_field_name`, which is present in the `vals` in the case of moving a whole task. Yet, in our case, we only move the deadline, so `start_date_field_name` isn't in our `vals`. So, to get the direction of our rescheduling, we have to use `stop_date_field_name` instead.

Then, we perform this call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L412 However, in our case, the dependent tasks are still found under the `dependency_inverted_field_name` field.

This leads us to the return of the function, where we call `_web_gantt_move_candidates`. In it, we retrieve the previous values of the pill we're modifying with:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1366 using `vals`. Later we use `start_date_field_name` to update the dates of dependent tasks:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1413-L1415 Still, in our case, we don't have `start_date_field_name` in vals. Thus, we have to define `old_vals_per_pill_id[self.id][start_date_field_name]`.

Next, we define the start date and end date of the intervals in which we reschedule the dependent tasks (so, the left and right bounds of intervals):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1392-L1401 In case of a `search_forward`, this is natural. Nevertheless, in the case of a backwards search, we can't consider the start date of the first task to be the right bound for our dependent tasks, as they occur after the first task! This would mean that our right bound is set before the dependent tasks even start. So, in our case of changing only a deadline, we have to set the right bound to the latest deadline of the dependent tasks. They won't be set to later, as we are moving the deadline backward.

Finally, in the case of setting a deadline backwards, we have to keep the time gap between task 1 and the dependent tasks, based on the working hours. This feature wasn't implemented.

__
opw-6080405

Forward-Port-Of: odoo/enterprise#117815
Forward-Port-Of: odoo/enterprise#113787

Issue:
Unreconciling a payment in a batch payment from a recurring invoice will cause an invoice for the next recurring period to be generated

Steps to reproduce:
1. Create and confirm a monthly recurring invoice
2. Create a payment for the invoice
3. Create a batch payment and add the payment created in step 2 then validate it
4. Create a bank statement line and reconcile it with the batch payment created in step 3
5. Unreconcile the payment from the invoice from the invoice form view
6. Notice that a draft invoice for the next month’s recurring invoice is created

Cause:
When unreconciling the payment from the invoice via the invoice form view, the method “delete_reconciled_line” is called. In the “account_accountant_batch_payment” override of that method, it will reset the invoice back to draft and repost it. However, when posting a recurring invoice, the default behavior is to create the invoice for the next recurrence period

Solution:
Adding a new context flag called “skip_recurring_copy” will prevent the next period’s recurring invoice from being generated when invoices are posted through “delete_reconciled_line”

opw-6158881

Forward-Port-Of: odoo/enterprise#117011

Currently, an error will occur when user puts Date of Salary Increase in the past on the salary increase wizard.

Steps to replicate:
- Install `hr_payroll` and create a new employee.
- From the cog menu click `Salary Increase`.
- Put any date from the past in the `Date of Salary Increase` field.

Error:
```py
File '/home/odoo/src/enterprise/saas-19.3/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py', line 43, in _get_affected_version_ids
    increase_base_version = employee.version_ids.filtered_domain([('date_version', '<=', self.increase_date)])[-1]
File '/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py', line 6135, in __getitem__
    ids = (self._ids[key],)
IndexError: tuple index out of range
```

Cause:
- When the user changes the salary increase date, it triggers the [compute], which calls `_get_affected_version_ids()`. In this method, employee versions [1] are filtered to keep only those whose `date_version` is less than or equal to the selected increase date.

- For newly created employees, version_ids typically contain only an initial version with date_version set to today's date. Therefore, when the selected salary increase date is earlier than today, the filter returns an empty recordset, which later causes the crash when accessing the last record of that recordset.

Solution:
- Early returned empty recordsets when no matching employee versions are found for the selected increase date.

[compute]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L34-L39

[1]: https://github.com/odoo/enterprise/blob/2a86967c1754f9c703a87c5d9ceb1d5f5d0ec26f/hr_payroll/wizard/hr_payroll_salary_increase_wizard.py#L43

sentry-7498213478

Forward-Port-Of: odoo/enterprise#118309

### Sales Contribution Margin Reporting (CM1–CM5)
This PR introduces a contribution margin reporting layer on top of Accounting and Stock valuation data.

The report provides post-period margin analysis for CFO/controller use after month-end closing.

It is a read-only reporting extension and does not modify any accounting or stock entries.

**Scope**
Adds Sales Contribution Margin report under Accounting reporting:
- Sales Contribution Margin (By Partner)
- By Product
- By Invoice

**Margin model**
CM1

Direct margin based on accounting and stock valuation:
- FIFO / AVCO: stock valuation layers
- Standard cost fallback: standard_price * qty
- Services / dropship: zero direct cost

CM2–CM5
Optional cost layers based on account tags:
- cm2_cost
- cm3_cost
- cm4_cost
- cm5_cost

**Overhead allocation**

- Pro-rata allocation based on revenue share
- Period-based (accounting date)

**Configuration**

Account tags defined in:
Accounting > Configuration > Account Tags

Tag names:
- cm2_cost
- cm3_cost
- cm4_cost
- cm5_cost

**Design constraints**
- Read-only reporting layer
- No changes to accounting entries
- No impact on posting or valuation logic
- No demo data dependency

The current implementation of l10n_se_sie4_export does not follow 
the SIE4 specification (version 4C, 2025-08-06) in several critical 
areas, causing exported files to be rejected by Swedish audit software, 
accounting systems and Skatteverket's own tools.

This PR corrects all known spec deviations and completes the 
implementation of optional but commonly required identification posts.

Note: The character encoding was set to ISO-8859-1. 
The SIE4 specification §5.8 explicitly requires IBM PC 
Codepage 437 (CP437). Files generated by the current 
implementation cannot be correctly read by any SIE4-compliant 
receiving system.

Some identification posts are optional per the SIE4 specification, 
but required in real world use by Swedish audit software, accounting 
systems and government filing tools.

The exported file has been validated against the official SIE4 
validator at https://sietest.sie.se and passes all checks.

**Specification reference:** 
https://sie.se/wp-content/uploads/2026/02/SIE_filformat_ver_4C_2025-08-06.pdf

**Fixes:**
- CP437 encoding per spec §5.8
- Amount format max 2 decimals per spec §5.9  
- Identification posts in correct order per spec §5.12
- #VER sequence number per serie per spec §11
- #VER with all 6 fields per spec §11
- partner_id.company_registry as canonical source
- stdnum.luhn for org number validation (v1.17/v1.19 compatible)
- _escape_sie on all string values
- Correct implementation order

**Feature completion:**
- #ORGNR with Luhn validation and report header warning
- #ADRESS, #FNR, #GEN with username
- #KPTYP hardcoded EUBAS97 (Odoo Swedish chart)
- #VALUTA always written
- #PROSA support
- #KSUMMA per spec §10
- #OMFATTN for partial period export
- Import key in #VER sign field (move.name)
- 7 tests including encoding, round-trip and KSUMMA

The current implementation of l10n_se_sie4_export does not follow 
the SIE4 specification (version 4C, 2025-08-06) in several critical 
areas, causing exported files to be rejected by Swedish audit software, 
accounting systems and Skatteverket's own tools.

This PR corrects all known spec deviations and completes the 
implementation of optional but commonly required identification posts.

Note: The character encoding was set to ISO-8859-1. 
The SIE4 specification §5.8 explicitly requires IBM PC 
Codepage 437 (CP437). Files generated by the current 
implementation cannot be correctly read by any SIE4-compliant 
receiving system.

Some identification posts are optional per the SIE4 specification, 
but required in real world use by Swedish audit software, accounting 
systems and government filing tools.

The exported file has been validated against the official SIE4 
validator at https://sietest.sie.se and passes all checks.

**Specification reference:** 
https://sie.se/wp-content/uploads/2026/02/SIE_filformat_ver_4C_2025-08-06.pdf

**Fixes:**
- CP437 encoding per spec §5.8
- Amount format max 2 decimals per spec §5.9  
- Identification posts in correct order per spec §5.12
- #VER sequence number per serie per spec §11
- #VER with all 6 fields per spec §11
- partner_id.company_registry as canonical source
- stdnum.luhn for org number validation (v1.17/v1.19 compatible)
- _escape_sie on all string values
- Correct implementation order

**Feature completion:**
- #ORGNR with Luhn validation and report header warning
- #ADRESS, #FNR, #GEN with username
- #KPTYP hardcoded EUBAS97 (Odoo Swedish chart)
- #VALUTA always written
- #PROSA support
- #KSUMMA per spec §10
- #OMFATTN for partial period export
- Import key in #VER sign field (move.name)
- 7 tests including encoding, round-trip and KSUMMA

On September 1 electronic invoicing will become mandatory in France.
For this we need to send our invoices to an approved platform.
Before the Septemer 1 the users can participate in the pilot phase to test if they wish.
This module adds support to connect to do the e-invoicing via the Odoo approved platform.

The electronic invoicing is a 5-corner peppol model.
So it is basically Peppol and the access points send regulatory information
to the government.
The Regulatory information are tax information (XML extracted from the invoice XML)
and some lifecycle messages.

The French e-invoicing uses a dedicated peppol identifier format.
- The `0225` peppol scheme is reserved for French tax payers and managed by the French authorities and the approved platform network.
- The peppol identifier for this scheme has one of the following formats:
  SIREN, SIREN_SIRET, SIREN_SIRET_CodeRoutage or SIREN_SuffixeAdressage.
  There the CodeRoutage and SuffixeAdressage are new and free identifiers respectively.

The annuaire is a place that lists all peppol identifiers for French tax payers.
It's role is to track the platform each tax payer is using to send / receive their electronic invoices.
So i.e. it is used to associate a platform to each peppol identifier with scheme `0225`.

This module depends on / extends the standard Peppol module `account_peppol` to work.
So it basically works the same except that
- we are connected to the Odoo approved platform instead of the Odoo peppol acces point
- we look up the partners in the annuaire when they are french taxpayers (instead of via peppol directly)
- (some) lifecycle messages are mandatory to support
- it uses special XML formats for invoices and lifecycle messages

In terms of XML formats this commit adds
- the special French UBL invoicing format in model "account.edi.xml.ubl_21_fr"
- support for parsing for lifecycle messages in the format CDAR (CrossDomainAcknowledgementAndResponse)

The code for the Odoo approved platform is added in the IAP PR https://github.com/odoo/iap-apps/pull/1435

task-4603737
task-5060323
task-5183084
task-6193378