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)

__

## 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:**
The account_online_payment module overrides `action_draft` to raise a UserError for sepa_ct payments belonging to a batch with a `payment_online_status` = 'pending' or 'accepted'.
This blocks the bank statement unreconciliation process. When `delete_reconciled_line` is called, it tries to set payments to draft and re-post them, despite it being an internal process not a manual user modification.

**Steps to reproduce:**
- Setup a 'sepa_ct' payment method on a bank journal.
- Create a bill with a vendor with a trusted bank account.
- Create a payment for that bill with a 'sepa_ct' payment method.
- Add the payment to a batch.
- Manually set the `payment_online_status` = 'pending'.
- Create a bank transaction and reconcile it with the batch.
- Try to unreconcile the lines on the transaction
- Result: UserError 'You cannot modify a payment that has already been sent to the bank.'

**Fix:**
Pass a context flag to `action_draft` during the unreconciliation flow so that the validation is skipped when the call originates from the internal unreconcile flow.

OPW-6080464

Forward-Port-Of: odoo/enterprise#118649
Forward-Port-Of: odoo/enterprise#117921

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

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406