Enable global rounding Have a company currency with 0 decimal precision digits Have a foreign currency with 2 decimal precision digits Create a Pricelist for the foreign currency Create a Sale Order Set the foreign currency pricelist Add an order line with price 15.31 and 19% tax (not included) Issue: system will compute a price tax of 3.00, price total of the line will be 18.31 Order total is correct (18.22) This occurs because, when `_compute_taxes` aggregates results https://gi

Enable global rounding
Have a company currency with 0 decimal precision digits
Have a foreign currency with 2 decimal precision digits
Create a Pricelist for the foreign currency
Create a Sale Order
Set the foreign currency pricelist
Add an order line with price 15.31 and 19% tax (not included)

Issue: system will compute a price tax of 3.00, price total of the line
will be 18.31
Order total is correct (18.22)

This occurs because, when `_compute_taxes` aggregates results
https://github.com/odoo/odoo/blob/0e1e7bf9c96b8fe4a06dfe3f858a837a8fdf386d/addons/account/models/account_tax.py#L1159-L1162
it will consider a tax amount that, in global rounding,
is rounded according to company currency, that does not have the same
precision settings
https://github.com/odoo/odoo/blob/0e1e7bf9c96b8fe4a06dfe3f858a837a8fdf386d/addons/account/models/account_tax.py#L1011-L1014

A solution is to directly call `_compute_taxes_for_single_line` is order
to get the raw results for the single line

opw-4050736

Forward-Port-Of: odoo/odoo#178768
Forward-Port-Of: odoo/odoo#176187

### Issue: Previous fix: odoo/odoo@4c0f03c7a1d1ec1f99dbc8b2202454e4398e386b In CH tax report, tax amounts from Payments of Expenses paid by company are not shown when using taxes with Cash Basis. ### Explanation: The CH report uses tags to fetch taxes. With previous fix, those tags were still not passed through. ### Fix reasoning: We will use the same condition for the `include_caba_tags` parameter as for the `caba_no_transition_account` context key for consistency. opw-394636

### Issue:

Previous fix: odoo/odoo@4c0f03c7a1d1ec1f99dbc8b2202454e4398e386b
In CH tax report, tax amounts from Payments of Expenses paid by company are not shown when using taxes with Cash Basis.

### Explanation:

The CH report uses tags to fetch taxes. With previous fix, those tags were still not passed through.

### Fix reasoning:

We will use the same condition for the `include_caba_tags` parameter as for the `caba_no_transition_account` context key for consistency.

opw-3946362

Forward-Port-Of: odoo/odoo#179031
Forward-Port-Of: odoo/odoo#177246

When importing a UBL file, we get an error `SyntaxError: prefix 'cac' not found in prefix map` When importing a UBL file Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. We fix it by using the ubl namespace as nsmap (see https://github.com/o

When importing a UBL file, we get an error `SyntaxError: prefix 'cac'
not found in prefix map`
When importing a UBL file Odoo expects the UBL specific namespaces to be
in the root element of the file. This is not always the case as these
namespaces could exist in every element in the file. When a file is
formatted this way, Odoo cannot extract the necessary data from it
because it is missing the necessary namespaces.
We fix it by using the ubl namespace as nsmap (see
https://github.com/odoo-dev/odoo/commit/1e24b151c6ad0023769b5a561690cb62bcda1d8a)

opw-4142421

Forward-Port-Of: odoo/odoo#178547

Account moves are created for the whole session and are not specific to a pos order. So we shouldn't map the accounts used. This reverts commit 595561fd9b48b5a71bf709b018d25006deb9f12c. opw-4086609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179117 Forward-Port-Of: odoo/odoo#179084

Account moves are created for the whole session and are not specific to a pos order. So we shouldn't map the accounts used.

This reverts commit 595561fd9b48b5a71bf709b018d25006deb9f12c.

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

Forward-Port-Of: odoo/odoo#179117
Forward-Port-Of: odoo/odoo#179084

Steps to reproduce: ------------------- - Have xlrd >= 2.0 and openpyxl 3.1.2 - Using the `base_import` module, import an XLSX file with dates - Test -> ValueError unconverted data remains: 00:00:00 Cause: ----- Since xlrd 2.0.0 in (#169245), if we have a date in an XLSX file, we nonetheless always get a datetime with a time value of 00:00:00 instead of a date object. This datetime later fails to be converted to a date because of an "unconverted data remains: 00:00:00" error. Fix:

Steps to reproduce:
-------------------
- Have xlrd >= 2.0 and openpyxl 3.1.2
- Using the `base_import` module, import an XLSX file with dates
- Test -> ValueError unconverted data remains: 00:00:00

Cause:
-----
Since xlrd 2.0.0 in (#169245), if we have a date in an XLSX file, we nonetheless
always get a datetime with a time value of 00:00:00 instead of a
date object. This datetime later fails to be converted to a date
because of an "unconverted data remains: 00:00:00" error.

Fix:
---
Use is_datetime() from openpyxl.styles.numbers to check cell.number_format instead of depending on object type.

Forward-Port-Of: odoo/odoo#177782

### Steps to reproduce: - Enable workorders in the settings - Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes - Create and confirm an MO for 5 units of P - Set a producing quantity of 2 - Validate the MO and create a back order ### Issues: On each of the operations of the MO: 1) The quantity displayed is 0 2) The expected duration is the expected duration corresponding to the full initial demand e.g. 50 minutes Note: Issues 1 is pre

### Steps to reproduce:

- Enable workorders in the settings
- Create a BOM for a product P with an operation: - OP1: Assembly line 1, duration 10 minutes
- Create and confirm an MO for 5 units of P
- Set a producing quantity of 2
- Validate the MO and create a back order

### Issues:

On each of the operations of the MO:

1) The quantity displayed is 0
2) The expected duration is the expected duration corresponding to the full initial demand e.g. 50 minutes

Note: Issues 1 is present even if the produced qty match the full demand of the MO.

### Cause of the issues:

1) The quantity displayed on the operations is the 'qty_remaining' independantly of the state of the MO. However, once the MO is done, this qty is set to 0 because the product have been produced.

2) The expected duration is a computed field that is not updated once the opeartion is done:
https://github.com/odoo/odoo/blob/45154cfdb044aea85ad72bb36348af7b77afd844/addons/mrp/models/mrp_workorder.py#L329-L333 However, finishing the operation will change the state to 'done' before the MO is backordered and the `qty_production` updated. In addition, the `_get_duration_expected` relied solely on the qty_production rather than also relying on the actual 'qty_produced':
https://github.com/odoo/odoo/blob/45154cfdb044aea85ad72bb36348af7b77afd844/addons/mrp/models/mrp_workorder.py#L786

### Fix:

1) Since we can not show different columns for each operation depending on their state, we rely on the state of the MO to determine which qty is the most relevant: the qty_remaining or the qty_produced

2) We update the expected duration depending on the qty_produced in case it was not manually set (which can be determined by comparing its current value with the expected value before the workorder is set as done)

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

Forward-Port-Of: odoo/odoo#178094
Forward-Port-Of: odoo/odoo#171771

**Current behavior before PR:** - Pressing Enter after selecting all columns in a row would break the table format. **Desired behavior after PR is merged:** - Now, when the Enter key is pressed, all the contents of the anchor `<td>` will be removed first, and then the Enter process within that `<td>` will be executed. task-3557503 Forward-Port-Of: odoo/odoo#177775 Forward-Port-Of: odoo/odoo#139312

**Current behavior before PR:**

- Pressing Enter after selecting all columns in a row would break the table
  format.

**Desired behavior after PR is merged:**
- Now, when the Enter key is pressed, all the contents of the anchor `<td>`
  will be removed first, and then the Enter process within that `<td>` will
  be executed.

task-3557503

Forward-Port-Of: odoo/odoo#177775
Forward-Port-Of: odoo/odoo#139312

It is necessary to wrap the tab names in _lt to make them translatable into the various languages offered by Odoo. Before these changes, the tab names are always in English. After these changes, when translations are added to the terms, they will appear translated into the selected language. cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177889 Forward-Port-Of: odoo/odoo#177724

It is necessary to wrap the tab names in _lt to make them translatable into the various languages offered by Odoo.

Before these changes, the tab names are always in English.

After these changes, when translations are added to the terms, they will appear translated into the selected language.

cc @Tecnativa

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

Forward-Port-Of: odoo/odoo#177889
Forward-Port-Of: odoo/odoo#177724

- saas-17.1 ### Steps to reproduce: - Install sales timesheet, accounting, and purchase. - Select Analytic Accounting from the accounting setting. - Create a billable project. - Create a purchase order, select a service product, add a project in analytic distribution, and add quantity 10. - While confirming PO, add received quantity 5. - Open project updates, on the right side under the profitability heading. Observe the expected value of cost. - Click on a new button, in the descripti

- saas-17.1

### Steps to reproduce:
- Install sales timesheet, accounting, and purchase.
- Select Analytic Accounting from the accounting setting.
- Create a billable project.
- Create a purchase order, select a service product, add a project in analytic distribution, and add quantity 10.
- While confirming PO, add received quantity 5.
- Open project updates, on the right side under the profitability heading. Observe the expected value of cost.
- Click on a new button, in the description tab, and check the expected value.
- There is a wrong value in the form view.

### Issue:
Wrong value of costs expected in project update form view.

### Solution:
Calculate the value in the same way in the project update right side.


task-3996848


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

Forward-Port-Of: odoo/odoo#170266

- Before this commit The ir.asset target field is only displayed when the directive is 'replace', but this field is required for 'after' and 'before' directives too. - After this commit The form view is adapted to fix this issue. Forward-Port-Of: odoo/odoo#178799 Forward-Port-Of: odoo/odoo#178765

- Before this commit The ir.asset target field is only displayed when the directive is 'replace', but this field is required for 'after' and 'before' directives too.

- After this commit The form view is adapted to fix this issue.

Forward-Port-Of: odoo/odoo#178799
Forward-Port-Of: odoo/odoo#178765

Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#174750

Fixed some missing / incorrect translations of account names in the chart template.

Forward-Port-Of: odoo/odoo#174750

**Steps:** - Create a few products and e-commerce categories - Go to the shop page - Hover on the eCommerce categories created - A bit displacement is seen in the margin **Issue:** - The margin is given to adjust the height of the scrollbar on hover but it's applied even when scrollbar is not present (when handful of categories are there) resulting in a displacement. **Fix:** - Disabling the margin on hover when there are less categories that is when scrollbar is not present **Aff

**Steps:**
- Create a few products and e-commerce categories
- Go to the shop page
- Hover on the eCommerce categories created
- A bit displacement is seen in the margin

**Issue:**
- The margin is given to adjust the height of the scrollbar on hover but it's applied even when scrollbar is not present (when handful of categories are there) resulting in a displacement.

**Fix:**
- Disabling the margin on hover when there are less categories that is when scrollbar is not present

**Affected version:** 17.0~master
opw-4088697

Forward-Port-Of: odoo/odoo#178545

Current behavior before PR: 1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element. 2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`. 3. Copy/pasting multiple paragraphs into a list does not convert it to list. 4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss

Current behavior before PR:

1. When we attempt to paste an H1 element into a P element, the H1 element gets converted to a P element.
2. When pasting from GDocs, nested UL or OL is a direct child of its parent UL or OL, rather than being child of LI with class `oe-nested`.
3. Copy/pasting multiple paragraphs into a list does not convert it to list.
4. When pasting content that begins with a list and includes other tags below it into a new list, only the list is pasted, resulting in a loss of the other content.
5. Copy/pasting one list over another bullets does not get transformed.
6. When copying a checklist from Google Docs, the check options are pasted as images.

Desired behavior after PR is merged:

1. When we attempt to paste an H1 element onto a P element, the H1 element will remain as an H1 element.
2. When pasting from GDocs, nested UL or OL are contained within an LI element with class `oe-nested`.
3. Copy/pasting multiple paragraphs into a list gets converted to list.
4. Pasting content with a list and other tags should no longer result in the loss of content.
5. Copy/pasting one list over another bullets get transformed.
6. Check options copied as image from Google Docs will no longer be pasted as images; instead the images should be removed and class `o_checklist` should be add to the closest list.

task-2956048

Co-authored-by: Deependra Solanki <deso@odoo.com>

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

Forward-Port-Of: odoo/odoo#178031
Forward-Port-Of: odoo/odoo#115019

This is no longer necessary with the introduction of: https://github.com/odoo/odoo/pull/144652 Forward-Port-Of: odoo/odoo#179149 Forward-Port-Of: odoo/odoo#145284

This is no longer necessary with the introduction of: https://github.com/odoo/odoo/pull/144652

Forward-Port-Of: odoo/odoo#179149
Forward-Port-Of: odoo/odoo#145284

Currently an exception was generated when the user processed an instance refund from Razorpay, and we get notes as a list in notification data (see response here [Ref](https://github.com/razorpay/razorpay-python/blob/master/documents/refund.md#create-an-instant-refund)). error: ``` AttributeError: 'list' object has no attribute 'get' File "odoo/http.py", line 2383, in __call__ response = request._serve_db() File "odoo/http.py", line 1913, in _serve_db return self._transac

Currently an exception was generated when the user processed an instance refund from
Razorpay, and we get notes as a list in notification data (see  response here [Ref](https://github.com/razorpay/razorpay-python/blob/master/documents/refund.md#create-an-instant-refund)).

error: 
```
AttributeError: 'list' object has no attribute 'get'
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2100, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/payment_razorpay/controllers/main.py", line 41, in razorpay_webhook
    tx_sudo = request.env['payment.transaction'].sudo()._get_tx_from_notification_data(
  File "addons/payment_razorpay/models/payment_transaction.py", line 328, in _get_tx_from_notification_data
    reference = notification_data.get('notes', {}).get('reference')
```

This commit will fix the above issue by preventing getting the dict data if `notes` in notification data is list type.



sentry-5793000218

Forward-Port-Of: odoo/odoo#179135

You shouldn't be able to archive a journal that is used in a payment method. Steps to reproduce: ------------------- * Open a payment method and archive the journal used in it * Open PoS and make an order using this payment method > Observation: Close the PoS session, you will have an error saying you cannot close the session. Why the fix: ------------ We override the `action_archive` function to make sure no payment method is using the journal being archived. opw-4070620 --- I

You shouldn't be able to archive a journal that is used in a payment method.

Steps to reproduce:
-------------------
* Open a payment method and archive the journal used in it
* Open PoS and make an order using this payment method
> Observation: Close the PoS session, you will have an error saying you
cannot close the session.

Why the fix:
------------
We override the `action_archive` function to make sure no payment method is using the journal being archived.

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

Forward-Port-Of: odoo/odoo#177751

model.default_get should use a list of field names as input but not a field name 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#179162 Forward-Port-Of: odoo/odoo#179092

model.default_get should use a list of field names as input but not a field name

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#179162
Forward-Port-Of: odoo/odoo#179092

When trying to print the receipt on the Odoo app on a mobile device, the background color of the receipt would be different than the background color of the text Steps to reproduce: ------------------- * Open PoS on the Odoo app * Print receipt > Observation: On the preview the receipt looks like this  Why the fix: ------------ By making the background color transparent we

When trying to print the receipt on the Odoo app on a mobile device, the background color of the receipt would be different than the background color of the text

Steps to reproduce:
-------------------
* Open PoS on the Odoo app
* Print receipt
> Observation: On the preview the receipt looks like this

![Screenshot_20240902-141836](https://github.com/user-attachments/assets/f7426653-7e68-4565-9bf4-a90d3f2fae1b)

Why the fix:
------------
By making the background color transparent we ensure that it will always be the same for the text and the general background color

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

Forward-Port-Of: odoo/odoo#178803

On the invoice tree view we have a possible search on multiple field at once. While this is a good feature for the user as it makes a very practical search, for large databases this is not performant at all, as we're searching on multiple fields at once, some of them not being indexed. To allow for more efficient searches, we added some specific search. task: 4154313 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#

On the invoice tree view we have a possible search on multiple field at once. While this is a good feature for the user as it makes a very practical search, for large databases this is not performant at all, as we're searching on multiple fields at once, some of them not being indexed. To allow for more efficient searches, we added some specific search.

task: 4154313




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

Forward-Port-Of: odoo/odoo#179125

Issue: When trying to resend a mail authored by any other user as an administrator, we are going to receive a "Delivery Failed" error even though the mail has been sent. Steps to reproduce: - Send any email as Demo, so they stay in queue for seding under mails. - Go to mails as admin now and try to send the mail manually. (You can use a meeting for example to send the mail, create a meeting and send the mail to notify this meeting.) Solution: Since the issue is triggered when we try

Issue: When trying to resend a mail authored by any other user as an administrator, we are going to receive a "Delivery Failed" error even though the mail has been sent.

Steps to reproduce:

- Send any email as Demo, so they stay in queue for seding under mails.
- Go to mails as admin now and try to send the mail manually. (You can use a meeting for example to send the mail, create a meeting and send the mail to notify this meeting.)

Solution:

Since the issue is triggered when we try to write on the message_id, which is a related field we might want to specify it in 'mail.mail' so we ensure that message_id is available directly on the 'mail.mail' model. This, will also apply properly the related_sudo=True that we need in order to work with it as administrator.

opw-3963124

Forward-Port-Of: odoo/odoo#177813
Forward-Port-Of: odoo/odoo#173406

…osting a batch of moves When we tried to confirm a batch of moves during the tax closing in a multi company setup with branches, an error was raised because the dependant closing moves should be posted before the parent move. This error was only catched in the `action_post` method but not on the modal that validates the batch. Original Commit: https://github.com/odoo/enterprise/pull/65645 opw-4148070 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi

…osting a batch of moves

When we tried to confirm a batch of moves during the tax closing in a multi company setup with branches, an error was raised because the dependant closing moves should be posted before the parent move.

This error was only catched in the `action_post` method but not on the modal that validates the batch.

Original Commit: https://github.com/odoo/enterprise/pull/65645

opw-4148070

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

Forward-Port-Of: odoo/odoo#179160
Forward-Port-Of: odoo/odoo#178601

### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to t

### Steps to reproduce:

- Enable multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Operations types
- Click on Manufacturing and put "Always" on create a backorder
- Create a product P (no need for a bom)
- Create and confirm a manufacturing order for 2 units of the product
- Go to the barcode module > operations > manufacturing > the MO
- Register only one unit of P and produce
#### > A backorder is automatically created but you are redirected to the backend.

#### Note:

If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module.

### Cause of the issue:

The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" backorder.

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

Forward-Port-Of: odoo/odoo#178674
Forward-Port-Of: odoo/odoo#178492

We add an alias to reset the IoT Box on a dev branch. Forward-Port-Of: odoo/odoo#179175

We add an alias to reset the IoT Box on a dev branch.

Forward-Port-Of: odoo/odoo#179175

Allow to send UBL Bis 3 invoices using Peppol to Chorus Pro (B2G plaftorm in France). This requires to send the information contained in the already existing fields `buyer_reference`, `contract_reference`, `purchase_order_reference` in the Bis 3 xmls. task-4147787 opw-4139689 Forward-Port-Of: odoo/odoo#178389

Allow to send UBL Bis 3 invoices using Peppol to Chorus Pro (B2G plaftorm in France).

This requires to send the information contained in the already existing fields `buyer_reference`, `contract_reference`,
`purchase_order_reference` in the Bis 3 xmls.

task-4147787
opw-4139689

Forward-Port-Of: odoo/odoo#178389

Previously, settling a sale.order from the POS of a Belgian company would require the creation of an invoice. This was actually only necessary when the sale contains intra-community (EU) taxes. Those are the taxes that are mapped to (dest_tax_id) by the Intra-Community fiscal position. See https://github.com/odoo-dev/odoo/commit/70f3b748f7098b60e02e8235f2007e4b94f666c3 This commit narrows down the enforcement of the invoice creation to only target sales made with such taxes. opw-[3

Previously, settling a sale.order from the POS of a Belgian company
would require the creation of an invoice.

This was actually only necessary when the sale contains intra-community
(EU) taxes. Those are the taxes that are mapped to (dest_tax_id) by the
Intra-Community fiscal position.
See https://github.com/odoo-dev/odoo/commit/70f3b748f7098b60e02e8235f2007e4b94f666c3

This commit narrows down the enforcement of the invoice creation to only
target sales made with such taxes.

opw-[3986443](https://www.odoo.com/odoo/project.task/3986443?cids=1)

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

Forward-Port-Of: odoo/odoo#172280
Forward-Port-Of: odoo/odoo#170186

This commit aims to enhance the validation of VAT numbers for Ireland to avoid conflicts with similar numbers like CRNs (Company Registration Numbers). Steps to reproduce: - Create a new contact with Ireland as the country and use "IE393763" for the VAT number. - A traceback occurs. opw-4125865 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177375

This commit aims to enhance the validation of VAT numbers for Ireland to avoid conflicts with similar numbers like CRNs (Company Registration Numbers).

Steps to reproduce:

- Create a new contact with Ireland as the country and use "IE393763" for the VAT number.
- A traceback occurs.

opw-4125865

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

Forward-Port-Of: odoo/odoo#177375

Steps to reproduce: - Open the 'Outstanding Receipts' account on any DB - Change its code - Notice how `reconcile` changes to False. Analysis: - Since #94171 (merged in 15.5), there is a dependency chain `code` -> `account_type` -> `reconcile`. - As such, changing the code will cause `reconcile` to be recomputed even if the account type was not changed. - Because the Outstanding Receipts has account type `asset_current`, it's changed back to `reconcile=False` any time `code` is changed.

Steps to reproduce:
- Open the 'Outstanding Receipts' account on any DB
- Change its code
- Notice how `reconcile` changes to False.

Analysis:
- Since #94171 (merged in 15.5), there is a dependency chain `code` -> `account_type` -> `reconcile`.
- As such, changing the code will cause `reconcile` to be recomputed even if the account type was not changed.
- Because the Outstanding Receipts has account type `asset_current`, it's changed back to `reconcile=False` any time `code` is changed.

Solution:
- We don't change `reconcile` if the account_type is an asset or liability type different from `asset_receivable` or `liability_payable`.

taskid: 4137941

Forward-Port-Of: odoo/odoo#177880

The issue was that when extracting field names from an address, the current implementation only considered fields and spaces. Adding any additional characters would break the field names, resulting in invalid field names. For example, given the address line "%(zip)s, %(city)s", the current code would return the fields ["zip,", "city"], where the first field name is invalid. We should only consider what is between "%(<field_name>)s". Steps to reproduce: - Go to Contact > Configuration > Cou

The issue was that when extracting field names from an address, the current implementation only considered fields and spaces. Adding any additional characters would break the field names, resulting in invalid field names. For example, given the address line "%(zip)s, %(city)s", the current code would return the fields ["zip,", "city"], where the first field name is invalid. We should only consider what is between "%(<field_name>)s".

Steps to reproduce:

- Go to Contact > Configuration > Countries (Developer mode must be enabled).
- Search for "United States" and then edit.
- In "Layout in Reports", add any characters to the 3rd line where there is the "city" field, and save.
- Open any contact (you may need to refresh).
- The order of fields is now incorrect and does not match the "Layout in Reports".

This fix ensures that only valid field names are extracted from the address line, maintaining the correct order as specified in the "Layout in Reports".

opw-3920886

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

Forward-Port-Of: odoo/odoo#176017

We should only see the accounts matching the code prefix, just like done in `_name_search`. It was the expected result before this fix[^1] but the solution was to remove the feature instead of fix the traceback without explanation. [^1]: 8852ff2767eef111807a3f6efc7cc5376656f45f Forward-Port-Of: odoo/odoo#178947

We should only see the accounts matching the code prefix, just like done in `_name_search`.
It was the expected result before this fix[^1] but the solution was to remove the feature instead of fix the traceback without explanation.

[^1]: 8852ff2767eef111807a3f6efc7cc5376656f45f

Forward-Port-Of: odoo/odoo#178947

Description of the issue this commit addresses: With the change of the taxes in Finland, the default tax was modified but the way it is decided isn't the same as from 17.0. Because of that, in 17.0 and later versions, the default tax remained 24.0%. --- Desired behavior after this commit is merged: The default tax in the company template is 25.5% --- no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#

Description of the issue this commit addresses:

With the change of the taxes in Finland, the default tax was modified but the way it is decided isn't the same as from 17.0. Because of that, in 17.0 and later versions, the default tax remained 24.0%.

---

Desired behavior after this commit is merged:

The default tax in the company template is 25.5%

---

no-task

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

Forward-Port-Of: odoo/odoo#179516

On the first of september 2024, the official default rate in finland goes from 24.0% to 25.5%. This means that the OSS taxes that were pointing at the old rate need to be updated. --- task-4027773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179506 Forward-Port-Of: odoo/odoo#177857

On the first of september 2024, the official default rate in finland goes from 24.0% to 25.5%. This means that the OSS taxes that were pointing at the old rate need to be updated.

---

task-4027773

---

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

Forward-Port-Of: odoo/odoo#179506
Forward-Port-Of: odoo/odoo#177857

Odoo Enterprise modules were updated so test-only code is no longer loaded during normal operation. This keeps runtime startup cleaner while leaving test execution to the testing framework, with no expected change for everyday users.

There is no need to import the module `tests`, it will be done by the testing framework and we do not need it during runtime.

odoo/odoo#177671

The favorite button in marketing automation mailings has been moved from the subject field to the form header. This makes the control easier to find and keeps the subject area focused on message content.

Purpose
=======
Move the favorite button from the subject field to the header.

Task-3877116

This update prevents temporary record identifiers from being used in filtering logic, reducing the risk of errors while editing or creating records. It helps make HR contracts, payroll payslips, employee signing flows, and field service reports behave more reliably before records are fully saved.

odoo/odoo#177331

This update aligns several Odoo Enterprise apps with a newer shared way of searching records by display name. It should keep search behavior consistent across accounting, documents, knowledge, sign, WhatsApp, and localization features while reducing future maintenance work.

odoo/odoo#174967

This update corrects an incorrect documentation link displayed on the helpdesk team form view. Users will now see the correct knowledge base reference when accessing team settings, ensuring they have access to the right support resources.

This PR fixes a wrong documentation link in the helpdesk team form view.

Task-4102472