This update adjusts several Point of Sale-related modules to follow a newly introduced code style rule. It is an internal cleanup that helps keep the codebase consistent and easier to maintain, with no expected change to user-facing behavior.

In the corresponding community commit we add the eslint rule `"arrow-body-style": ["error", "as-needed"]`.

In this commit we adapt the code to respect this new rule.

https://github.com/odoo/odoo/pull/188818

Add check if date string is not equal to "000000" before parsing it, in record types that were missing this check. Some banks provide CODA files with the date set to "000000" which caused the `_parse_bank_statement_file` method to raise an exception and fail to parse such files. Using the `statement['date']` as a fallback in such case, as it is already used for `balance_start_date` and `transactionDate` fields. task-4348031 Forward-Port-Of: odoo/enterprise#74640

Add check if date string is not equal to "000000" before parsing it, in record types that were missing this check.

Some banks provide CODA files with the date set to "000000" which caused the `_parse_bank_statement_file` method to raise an exception and fail to parse such files.

Using the `statement['date']` as a fallback in such case, as it is already used for `balance_start_date` and `transactionDate` fields.

task-4348031

Forward-Port-Of: odoo/enterprise#74640

To reproduce: ============= 1. Go to Documents app 2. Upload a PDF file (one of the attached on the opw) 3. Click on the file to open it 4. Click on the "Split" button the pages on the preview are not displayed correctly Problem: ======== these pdf files, the pages are rotated by 270 degrees so when splitting the pages, the rotation is not taken into account and set to 0 degrees Solution: ========= - set the rotation of the pages to the original rotation when splitting the pdf

To reproduce:
=============
1. Go to Documents app
2. Upload a PDF file (one of the attached on the opw)
3. Click on the file to open it
4. Click on the "Split" button

the pages on the preview are not displayed correctly

Problem:
========
these pdf files, the pages are rotated by 270 degrees so when splitting the pages, the rotation is not taken into account and set to 0 degrees

Solution:
=========
- set the rotation of the pages to the original rotation when splitting the pdf

opw-4216158

Forward-Port-Of: odoo/enterprise#75011

Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to

Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence.

To reproduce this issue:

1) Install planning
2) Open any existing Open Shift planning slot
3) Enable the `repeat` and update the start and end date 
4) Give the edit value as `All shifts` and make sure the resource be empty 
5) Save the record.

Error:- 
```
IndexError: tuple index out of range
```

Here the `resource` is not required in planning slot. So, when the user tries to update an open shift 
with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line.

https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871

This is because when there is no `recurrence_slots` in the slot, 
we get an empty recordset for the `recurrence_slots`, 
which leads to the above traceback when trying to extract a value from the recurrency_slots.

We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust.

sentry-6096445646

Forward-Port-Of: odoo/enterprise#75134
Forward-Port-Of: odoo/enterprise#74866

### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a set vendor - Create and confirm a sale order for 3 units of your product - Confirm the purchase order and the associated reciept - Go to the barcode app on you delivery - set the quantity to 1/3 and leave the barcode app - Go back to the the delivery ### > only one line 1/1 appears ###

### Steps to reproduce:

- In the settings: enable multi-steps route
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable prodcut with MTO, buy routes and a set vendor
- Create and confirm a sale order for 3 units of your product
- Confirm the purchase order and the associated reciept
- Go to the barcode app on you delivery
- set the quantity to 1/3 and leave the barcode app
- Go back to the the delivery
### > only one line 1/1 appears

### Cause of the issue:

The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line:
https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`:
https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422
As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on.

opw-4232106
---

Forward-Port-Of: odoo/enterprise#74874
Forward-Port-Of: odoo/enterprise#73773

### Steps to reproduce: - Create two storable product: Final Product (FP) and Component (COMP) - Create and confirm an MO for FP with a raw move: 1 x COMP > The move should be: "not available" since 0 unit of COMP are in Stock - Go to the barcode module > Operations > Manufacturing - Remove the MO Ready filter > Click on your MO and then exit barcode - Go back to the MO in the back end (mrp module) #### > The raw move has been reserved and is hence marked as available. ### Cause of the

### Steps to reproduce:
- Create two storable product: Final Product (FP) and Component (COMP)
- Create and confirm an MO for FP with a raw move: 1 x COMP
> The move should be: "not available" since 0 unit of COMP are in Stock
- Go to the barcode module > Operations > Manufacturing
- Remove the MO Ready filter > Click on your MO and then exit barcode
- Go back to the MO in the back end (mrp module)
#### > The raw move has been reserved and is hence marked as available.

### Cause of the issue:

Exiting the barcode will launch an rpc call of the `split_uncompleted_moves` in order to split uncomplete moves in 2 if necessary (for the records to be appropriately set the next time you enter the barcode):
https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/models/stock_move.py#L9-L11 Furthermore, since c29f61fdded2e80d0bb3c06199c6a196feac8076 in case of a production the component move are rather splitted on the move lines to avoid odd split of the component moves on the MO. However, in that case if a unassigned move is splitted, a move line will be generated and associated to that move, which makes it reserved and hence available.

opw-4338827
---

Forward-Port-Of: odoo/enterprise#74244

Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private. This commit makes sure the project visibility is `portal` to be able to set an access token as before. opw-4104804 task-4354145 Forward-Port-Of: odoo/enterprise#75115

Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private.

This commit makes sure the project visibility is `portal` to be able to set an access token as before.

opw-4104804
task-4354145

Forward-Port-Of: odoo/enterprise#75115

For attendance based contract do not split generated work entries around lunch Steps --- * Create a running contract for some employee that uses a schedule with * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated: * 10 - 12 * 13 - 20 * We want only one: 10 - 20 task-4252156 Forward-Port-Of: odoo/enterprise#71979

For attendance based contract do not split generated work entries around lunch

Steps
---
* Create a running contract for some employee that uses a schedule with 
  * `work_entry_source = 'attendance'`
* Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00)
* => 2 work entries are generated: 
  * 10 - 12 
  * 13 - 20 
* We want only one: 10 - 20

task-4252156

Forward-Port-Of: odoo/enterprise#71979

Now we have an helper ensuring the consistency between the computation of the tax totals in both python & javascript, let's use it. task-id: 4280495 Related: https://github.com/odoo/odoo/pull/183299 Forward-Port-Of: odoo/enterprise#72597

Now we have an helper ensuring the consistency between the computation of the tax totals in both python & javascript, let's use it.

task-id: 4280495

Related: https://github.com/odoo/odoo/pull/183299

Forward-Port-Of: odoo/enterprise#72597

server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients. possible steps to reproduce: 1) make a database 17.0 2) delete document tags 3) upgrade the database to 18.0 Document tags and server actions should be recreated in upgrade scripts when upgrading to 18.0 if they are missing. Setting the noupdate=1, makes sure that they are not recreated on subsequent updates or upgrades after reaching 18.0. o

server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients.
possible steps to reproduce:
1) make a database 17.0
2) delete document tags
3) upgrade the database to 18.0

Document tags and server actions should be recreated in upgrade scripts
when upgrading to 18.0 if they are missing. Setting the noupdate=1,
makes sure that they are not recreated on subsequent updates or upgrades
after reaching 18.0.
odoo/upgrade#6803

Forward-Port-Of: odoo/enterprise#73108

Versions: - 18.0 Steps to Reproduce: - Go to Recurring Plan. - Click on the "Subscription Items" button. - Create a new item and save it. Issue: - An error occurs when saving a new subscription item. Cause: - create method of the sale.order.line model when ensure_one was called on an empty recordset. Solution: - Fixed a ValueError occurring in the create method of the sale.order.line model when ensure_one was called on an empty recordset. Added validation to prevent

Versions:

- 18.0

Steps to Reproduce:

- Go to Recurring Plan.
- Click on the "Subscription Items" button.
- Create a new item and save it.

Issue:

- An error occurs when saving a new subscription item.

Cause:

- create method of the sale.order.line model when ensure_one was called on an empty recordset.

Solution:

- Fixed a ValueError occurring in the create method of the sale.order.line model when ensure_one was called on an empty recordset. Added validation to prevent attempts to unpack values from an empty recordset, ensuring smoother operation during sales order line creation and preventing RPC errors in the frontend.

Forward-Port-Of: odoo/enterprise#70525

## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution:

## Issue:
- The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit.

## Steps to reproduce:
- Create a manufactured product and two components with costs and on hand quantities.
- Confirm a manufacturing order for the product.
- Adjust the manufactured quantity of the manufactured product.
- Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit.

## Solution:
- Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`.

opw-4118237

Forward-Port-Of: odoo/enterprise#74892
Forward-Port-Of: odoo/enterprise#70727

### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |------

### Description

When opening a report with a lot of data to display, getting some values can be very costly.

In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`.

To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls.

### Benchmark (made in 17.0)

| N° of assets | Before  | After  |
|--------------|---------|--------|
|          500 |    2 s  | 1.55 s |
|           7k |   20 s  |   19 s |
|          17k |   50 s  |   41 s |

### Reference

opw-4287192

Forward-Port-Of: odoo/enterprise#75170
Forward-Port-Of: odoo/enterprise#74085

Improve kanban cards: - Avoid having empty spaces and optimize space - Prevent displaying too much info by only displaying some on hover. The favorite toggle, the activities widget, the "only accessible by link" icon. - Prevent displaying large urls by hiding them behind icons. Improve list view UI: - Reorder fields - Add favorite field - Give a name to the type field in the tree view fields configurator. - When it is a shortcut, display the target document icon instead of the sho

Improve kanban cards:
- Avoid having empty spaces and optimize space
- Prevent displaying too much info by only displaying some on hover.
  The favorite toggle, the activities widget, the "only accessible by link" icon.
- Prevent displaying large urls by hiding them behind icons.

Improve list view UI:

- Reorder fields
- Add favorite field
- Give a name to the type field in the tree view fields configurator.
- When it is a shortcut, display the target document icon instead of the shortcut icon.

Changing the keys:
- Open a folder / preview a file: single click (previously double click)
- Select a folder / file: ctrl+click (previously single click)
- Make a selection range: shift+click (same as previously)

=> It wasn't natural for users to open a folder / preview a file by double clicking.
It also required a lot of clicks to navigate.

Task-4294457

Forward-Port-Of: odoo/enterprise#73078

Two flows are fixed and tested in this PR: A/ 1. Create a document outside a project's folder 2. Link the document to a project/task without moving it 3. The document's access_internal value is not synced with the privacy visibility as it would have if we had moved it inside the project's folder instead B/ 1. Create a document in a project's folder with privacy visibility 'employees' 2. Move the document outside the project's folder 3. Update the privacy_visibility to 'followers' 4.

Two flows are fixed and tested in this PR:

A/
1. Create a document outside a project's folder
2. Link the document to a project/task without moving it
3. The document's access_internal value is not synced with the privacy visibility as it would have if we had moved it inside the project's folder instead

B/
1. Create a document in a project's folder with privacy visibility 'employees'
2. Move the document outside the project's folder
3. Update the privacy_visibility to 'followers'
4. The document is still accessible to all internal users while it shouldn't

Note: _add_missing_default_values was an unused remnant of a distant idea

Task-4242299

Forward-Port-Of: odoo/enterprise#71485

Fixed a series of issues related to flexible and fully flexible resource introduced in task 3762895. In this PR, the following issues are fixed in the planning app: - In dark mode, the progress bar of resources working fully flexible hours had white background instead of transparent. Step to reproduce: 1. Open the gantt view, create a resource with fully flexible hours and assign it to a task. 2. The progress bar should not have a white background on dark mode. - Fully flexible e

Fixed a series of issues related to flexible and fully flexible resource introduced in task 3762895. In this PR, the following issues are fixed in the planning app:

- In dark mode, the progress bar of resources working fully flexible hours had white background instead of transparent. Step to reproduce:
    1. Open the gantt view, create a resource with fully flexible hours and assign it to a task.
    2. The progress bar should not have a white background on dark mode.

- Fully flexible employee Suman Oza had no hourly cost set in demo data. Step to reproduce:
    1. Go to the employees view and search for Suman Oza.
    2. The hourly cost should be no longer be set to 0.

- Flexible employee should have the period outside of their contract grayed in the Gantt view Step to reproduce:
    1. Create a resource with flexible hours.
    2. Set a contract with a start and end date.
    3. Open the gantt view in planning, and search for the resource.
    4. The period outside of the contract should be grayed.

- In gantt view sparse mode view, the color of the progress bar (the thin line above each employee and each day) of resources working fully flexible hours should be always in purple color. Step to reproduce:
    1. Create a resource with fully flexible hours.
    2. Create some shifts for the resource.
    3. Open the gantt view in sparse mode.
    4. The progress bar should be in purple color.

- Recurring shifts for fully flexible employees are now assigned even if they generate conflicts with existing shifts. (test was added to ensure this behavior) Step to reproduce:
    1. Create an employee working fully flexible hours.
    2. Plan some shifts for the employee.
    3. Create a recurring shift for the employee which ovelaps with the existing shifts.
    4. The recurring shifts should be assigned to the employee even if they generate conflicts with existing shifts.

task-id: 4189386

Forward-Port-Of: odoo/enterprise#73477

Versions -------- - 17.0+ Community: https://github.com/odoo/odoo/pull/188440 >[!important] >All functional changes are made in `sale`, this PR simply adds a test. Steps ----- 1. Have a confirmed subscription; 2. go to subscription management in portal; 3. set or change payment method. Issue ----- The following email is sent: > A payment [...] amounting $ 0.00 for [...] has been confirmed. Cause ----- The `_reconcile_after_done` override in `sale` sends a payment succe

Versions
--------
- 17.0+

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

>[!important]
>All functional changes are made in `sale`, this PR simply adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144

Forward-Port-Of: odoo/enterprise#75046
Forward-Port-Of: odoo/enterprise#74626

Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will

Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen.

Steps to reproduce the issue:
1. configure a pos_restaurant
2. configure 2 kitchen displays (disp1 and disp2)
3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally)
4. on disp1, proceed to tick/mark as done 2 items
5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage.
6. back in the POS, create a new order (any table)
7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5

The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2.

What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders.

After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split.

opw-4367937

Forward-Port-Of: odoo/enterprise#74816

**Steps to reproduce:** - Install Accounting - Create a Branch company without COA - Switch to the Branch company - Go to "Accounting / Accounting / Management / Assets" - Create an asset - Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account" **Issue:** The list is empty. The accounts from the parent company should be proposed. opw-4368887 Forward-Port-Of: odoo/enterprise#75094 Forward-Port-Of: odoo/enterprise#75034

**Steps to reproduce:**
- Install Accounting
- Create a Branch company without COA
- Switch to the Branch company
- Go to "Accounting / Accounting / Management / Assets"
- Create an asset
- Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account"

**Issue:**
The list is empty.
The accounts from the parent company should be proposed.

opw-4368887

Forward-Port-Of: odoo/enterprise#75094
Forward-Port-Of: odoo/enterprise#75034

Forward-Port-Of: odoo/enterprise#74926 Forward-Port-Of: odoo/enterprise#74889

Forward-Port-Of: odoo/enterprise#74926
Forward-Port-Of: odoo/enterprise#74889

Steps to reproduce: - create a spreadsheet - Freeze and Share this spreadsheet - go to a pivot view and hit "Insert in spreadsheet" => the frozen spreadsheet is included in the dialog Task: 4353076 Forward-Port-Of: odoo/enterprise#74337

Steps to reproduce:

- create a spreadsheet
- Freeze and Share this spreadsheet
- go to a pivot view and hit "Insert in spreadsheet"

=> the frozen spreadsheet is included in the dialog

Task: 4353076

Forward-Port-Of: odoo/enterprise#74337

The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class. Runbot Error 108371 Forward-Port-Of: odoo/enterprise#74956

The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class.

Runbot Error 108371

Forward-Port-Of: odoo/enterprise#74956

Added the "identification_id" to all the "hr.employee" records to ba able to create the "DECSAL" report Task: 4334816 Forward-Port-Of: odoo/enterprise#74975

Added the "identification_id" to all the "hr.employee" records to ba able to create the "DECSAL" report

Task: 4334816

Forward-Port-Of: odoo/enterprise#74975

To avoid everyone creating his own template and making noise in the official list. If a user want to use his own template he can have a dedicated and private knowledge sheet for that. task-4366949 Forward-Port-Of: odoo/enterprise#74771

To avoid everyone creating his own template and making noise in the official list. If a user want to use his own template he can have a dedicated and private knowledge sheet for that.

task-4366949

Forward-Port-Of: odoo/enterprise#74771

Problem ---------- In th salary configurator, The display "group by category" for dropdown is broken in 18.0 due to framework task. Objective ---------- Make it works again like in 17.4. Group options by optgroup Solution ---------- add groups in the state and fill it with label of groups (attribute in optgroup) and all the choices (options inside optgroup) task-4350875 Forward-Port-Of: odoo/enterprise#74304

Problem
----------
In th salary configurator, The display "group by category" for dropdown is broken in 18.0 due to framework task.

Objective
----------
Make it works again like in 17.4.
Group options by optgroup

Solution
----------
add groups in the state and fill it with label of groups (attribute in optgroup) and all the choices (options inside optgroup)

task-4350875

Forward-Port-Of: odoo/enterprise#74304

To reproduce the issue: - Enable Avatax in Accounting settings - Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods' - Create a subscription order and set Deco Addict as the customer (is exempt) - Set the Avatax fiscal position - Confirm the order - Preview in portal view - Notice the tax is not equal The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, th

To reproduce the issue:

- Enable Avatax in Accounting settings
- Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods'
- Create a subscription order and set Deco Addict as the customer (is exempt)
- Set the Avatax fiscal position
- Confirm the order
- Preview in portal view
- Notice the tax is not equal

The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, the regular `tax_totals` field cannot be used in the portal anymore. Tax totals need to be recomputed for just those lines. This was done in a new method: `_next_billing_details()`.

This method recomputes tax totals using account.tax records, which won't be correct in many cases when using an external tax calculator. The percentage field that we set on the tax is only informational, and won't take exemptions into account.

Up to this point, the issue was only cosmetic. The customer was still charged the correct amount. This changed in #72120. Instead of charging `amount_to_invoice`, it now charges the amount calculated by `_next_billing_details()`. This, as stated above, won't always be correct.

To resolve the problem we first override `_next_billing_details()` so that it returns `tax_totals` based on line amounts. Those fields are the authoritative amounts that we set during external tax calculation [1]. This solves the cosmetic issue described above in most cases. However, the wrong totals are still displayed right after paying a subscription. This happens because the payment changes the state of the subscription, which invalidates the line amounts and recomputes them from `account.tax` again. We already overrode the `/my/subscriptions` controller to insert an external calculation and avoid this, but it happened after `super()` which is too late. At that point `_next_billing_details()` is already evaluated, with the incorrect values already in `qcontext`. To solve that we move the call before `super()`.

We also change `next_amount_invoice` to be the sum of invoicable lines, again basing this total on the authoritative amounts returned by the external tax calculator. We cannot use `amount_to_invoice` like before, because that breaks the "Anticipate payment" feature which was fixed in #72120. This solves the issue of charging the wrong amount.

opw-4315535
opw-4363065

[1] https://github.com/odoo/enterprise/blob/84aa5e2fb064bc0366e952cbd4eaf3628ea24b73/sale_external_tax/models/sale_order.py#L43-L55

PR note: built on top of #73921

Forward-Port-Of: odoo/enterprise#75028

Forward-Port-Of: odoo/enterprise#74947 Forward-Port-Of: odoo/enterprise#74033

Forward-Port-Of: odoo/enterprise#74947
Forward-Port-Of: odoo/enterprise#74033

Since applicants are aggregated into a candidate and the field company_id is not related between these two models. If the company is modified on a records, it won't match the one of the other model and so will create access right issues. To avoid this to hapend, we synchronize the company id between these tow models when we modify one and we use/create a candidate with the same company of the applicant on creation We also propagate the company from the applicant to the candidate, when the

Since applicants are aggregated into a candidate and the field company_id is not related between these two models. If the company is modified on a records, it won't match the one of the other model and so will create access right issues.

To avoid this to hapend, we synchronize the company id between these tow models when we modify one and we use/create a candidate with the same company of the applicant on creation

We also propagate the company from the applicant to the candidate, when the candidate is manually created from the backend.

task-4350838

Forward-Port-Of: odoo/enterprise#74674

Vestion: - 18.0 Steps to reproduce: - Create sale order and confirm it. - Invoice it. - Create renew order. Issue: - The "Cancel" button is not visible on the renewal quotation. Cause: - Condition to make button invisible is checking the invoice count should be greater than 1 but in renew order it is also considering invoice count of parent order and due to that it makes button invisible. Solution: - Remove the condition that checks the invoice count. The "Cancel" button will

Vestion:
- 18.0

Steps to reproduce:
- Create sale order and confirm it.
- Invoice it.
- Create renew order.

Issue:
- The "Cancel" button is not visible on the renewal quotation.

Cause:
- Condition to make button invisible is checking the invoice count should be greater than 1 but in renew order it is also considering invoice count of parent order and due to that it makes button invisible.

Solution:
- Remove the condition that checks the invoice count. The "Cancel" button will now be displayed even if an invoice exists. Since the system already prevents users from canceling subscriptions with invoices, this change will not lead to any functional issues.

Forward-Port-Of: odoo/enterprise#74234

Before this commit, when customer anticipated payment on portl, it would fail if there were already some draft invoices. This commit ensure the draft invoices are canceled before. In master, we should not create the invoice at all. taskid: 4368057 Forward-Port-Of: odoo/enterprise#74811

Before this commit, when customer anticipated payment on portl, it would fail if there were already some draft invoices. This commit ensure the draft invoices are canceled before.

In master, we should not create the invoice at all.

taskid: 4368057

Forward-Port-Of: odoo/enterprise#74811

When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected. Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong. This change makes the buttons clickable again, but instead displays a message saying that

When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected.

Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong.

This change makes the buttons clickable again, but instead displays a message saying that the user should select the main company and its branches in order to save a sensible report.

[task-4260501](https://www.odoo.com/odoo/all-tasks/4260501)

Forward-Port-Of: odoo/enterprise#73018

This update resolves an issue where the system incorrectly identified VAT numbers with dots (like BE1234.678.28) during SODA file imports. The fix adjusts the underlying regex to correctly validate Belgian VAT numbers, ensuring accurate company matching and import processes. This prevents import errors and improves data accuracy.

Steps to reproduce:
1. Have a VAT number (or company registry) with dots (e.g.: BE1234.678.28)
2. Import a valid SODA file with the same VAT number
3. Error: "The imported document doesn't seem to correspond to this company's VAT number nor company id"

Why it happens:
This happens because the regex was taking only the first matching group (1234 in the example above).

Solution:
Instead of searching the first group of the regex, we can subtract all chars and only keep digits to have a valid Belgian VAT number that can be used when checking correspondence between the company VAT and the imported SODA file VAT.

opw 4347926

Forward-Port-Of: odoo/enterprise#75111

This update streamlines the handling of Excel files (xlsx) within Odoo Enterprise. The previous process created unnecessary attachments and conflicts with computed fields, leading to inefficiencies. This fix simplifies the process by directly exploring the Excel file's structure, resulting in faster and more reliable document imports.

The multipage computation of xslx files was a bit overkill as it would convert the xlsx file to an o-spreadsheet json friendly form where it could simply explore the zip files. Furthermore, that convertion would create attachments for each media file present in the xlsx file. This is bad in 2 ways:
- the created attachment would never be used again
- we were creating attachment while calling a computed field (read/write mix is bad)

Task-4213183

This update resolves an issue where newly added form fields in Odoo's Web Studio were incorrectly placed at the end of the form instead of the beginning. The fix ensures that new fields are inserted at the start of the sheet, improving the user experience and preventing unexpected form layouts. This change ensures consistent and predictable form design.

Steps to reproduce
==================

- Open any form view
- Drag and drop a new html field at the start of the form view => It goes to the bottom

Cause of the issue
==================

The generated xpath was `<xpath expr="//form[1]/sheet[1]" position="inside"/>`
This puts the new element at the end of the sheet

Solution
========

If we want to insert something at the start of the sheet, we need to put it before it's first child. If the sheet is empty, we can use inside like previously

opw-4339407

This update fixes an issue where bank statement files with a date of '000000' caused parsing errors. The change allows the system to correctly process these files by using a standard fallback date, ensuring accurate import of bank transaction data. This improves the reliability of importing bank statements.

Add check if date string is not equal to "000000" before parsing it, in record types that were missing this check.

Some banks provide CODA files with the date set to "000000" which caused the `_parse_bank_statement_file` method to raise an exception and fail to parse such files.

Using the `statement['date']` as a fallback in such case, as it is already used for `balance_start_date` and `transactionDate` fields.

task-4348031

Forward-Port-Of: odoo/enterprise#74640

This update resolves an issue where the navigation menu and breadcrumbs disappeared after purchasing a reward on the Rewards page. The fix utilizes a 'soft reload' to prevent the page from resetting and maintaining consistent navigation for users. This improves the user experience and ensures seamless browsing.

Steps:
- Go to the Rewards page
- Buy a reward
- Breadcrumb and navigation menu were disappearing after the purchase

Cause of the issue:
- Page reload was resetting the breadcrumb and navigation

Fix:
- Used a soft reload instead of a full page reload to prevent the reset and preserve the 
  breadcrumb and navigation menu

task-4266538