…or the general ledger In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date. We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger. task-4270453 Forward-Port-Of: odoo/enterprise#72673

…or the general ledger

In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date.

We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger.

task-4270453

Forward-Port-Of: odoo/enterprise#72673

Manual fw-port of translations since they're not on transifex for saas versions. Also, re-export pot files that were out of date. Notes: - pot files that had no term changes were not updated even if their version number is out of date. - a few new terms were added to the l10n_be_hr_payroll modules, the translations for these were added as well - Swiss payroll modules were missing most of their German/Italian translations at the time of this PR, so the fw-port reflects this - jun

Manual fw-port of translations since they're not on transifex for saas
versions. Also, re-export pot files that were out of date.

Notes:
- pot files that had no term changes were not updated even if
  their version number is out of date.
- a few new terms were added to the l10n_be_hr_payroll modules, the
  translations for these were added as well
- Swiss payroll modules were missing most of their German/Italian
  translations at the time of this PR, so the fw-port reflects this
- junk po files were deleted for cleaniness (i.e. languages that didn't
  make sense for those l10n's)

Also PR https://github.com/odoo/enterprise/pull/73568 is reverted by this PR

The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582

The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon.

task-4317822

Forward-Port-Of: odoo/enterprise#73582

**Version:** - 17.0 **Steps to reproduce:** 1. In the Sign app, send a request for a signature. 2. Complete the signature and submit the request. 3. Observe the completion certificate that is generated. **Issue:** The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies. **Solution:** replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone. task-4014378

**Version:**
- 17.0

**Steps to reproduce:**
1. In the Sign app, send a request for a signature.
2. Complete the signature and submit the request.
3. Observe the completion certificate that is generated.


**Issue:**
The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies.


**Solution:**
replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone.

task-4014378

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

Forward-Port-Of: odoo/enterprise#66565

We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#72083 Forward-Port-Of: odoo/enterprise#69561

We were misconfiguring some accounts in ec localization:

- EDI purchase journal default account

opw-4127252

Forward-Port-Of: odoo/enterprise#72083
Forward-Port-Of: odoo/enterprise#69561

Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile i

Context:
Every Behavior in Knowledge was a new App based on the config of the main Odoo
App.

Among shared resources are registries and services. In particular, the
`main_components` registry is used to mount components, and, for the purpose of
the following example that registry is used by the `popover_service`.

Another thing to note is that the template compilation involves a reference to
the App, and all ComponentNode have an app property which is the app that was
used to compile its template.

Issue:
Now all pieces together in a problematic example case:
Creating a new popover from a Behavior App involves the `main_components`
registry:
- Create a PopoverController (position logic (wrapper)).
  It is created within the main App through the registry, and its lifecycle is
  managed by the main App Scheduler.
- Fill it with a Custom Component (business logic).
  It is created within the Embedded Component App, and its lifecycle is managed
  by the Embedded Component App Scheduler.

Both schedulers lifecycle handling are not synchronized, and at some
indeterministic point one of the Apps will crash during the manipulation
of that popover.

Solution:
Use the new "subroots" OWL feature instead of using sub-apps, so that all
templates are created from the same App, and the scheduler is the same for all
components. This also has the advantage of not having to re-compile all
templates for every Behavior.

task-4300215

Forward-Port-Of: odoo/enterprise#73491
Forward-Port-Of: odoo/enterprise#73224

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. This commit adapts an error message to the new term. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/odoo/pull/186237 Forward-Port-Of: odoo/enterprise#73316 Forward-Port-Of: odoo/enterprise#73285

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up.

This commit adapts an error message to the new term.

[opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444)

Related to https://github.com/odoo/odoo/pull/186237

Forward-Port-Of: odoo/enterprise#73316
Forward-Port-Of: odoo/enterprise#73285

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one

Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system
Use case:
- In an MX Company with PAC Quadrum
- Enable currency USD
- Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148
- Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16%
- Confirm
- Make 2 partial payments of 100'000 MXN
- On the Invoice, click 'Update Payments'
- In the CFDI tab, on one of the payments, click 'Force CFDI'

Issue: Validation will fail with error
Note: This does not occur with other providers (Solucion Factibles)
```
Code : CRP20275
Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado,
convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto.
```

This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance

opw-4314798

Forward-Port-Of: odoo/enterprise#73696

To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the

To reproduce:
Go to Accounting/Invoicing, Customers and create a new Customer. Delete it.
You get an error talking about audit trail while you don't have it activated.

The issue is that we block based on customer/supplier rank 
when there is no company on the partner.

We now check if we should block the deletion of a message of a 
partner if this partner has at least one journal entry with a 
company that has audit trail activated.

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

Forward-Port-Of: odoo/odoo#181891

When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186808

When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread.

The fix is to call the func to remove the typing indicator when the thread changes.

task-4285488


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

Forward-Port-Of: odoo/odoo#186808

**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the butto

**Steps to reproduce:**
- Install l10n_mx_reports (not mandatory but easier to reproduce)
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to "Accounting / Reporting / Audit Reports / Trial Balance"
- Select "Last Month" as data filter
- Select "Previous Month: 9" as comparison filter
- Click on dropdown button next to PDF button
- Click on a button that is displayed in front of the header of the report (e.g. XLSX)

**Issue:**
The action is not triggered.
Once the button has been clicked, the dropdown menu disappears behind the header of the report.

**Cause:**
The buttons in the dropdown menu have z-index:1000 and the thead
of the report has the z-index:999, which displays the buttons in
front the header of the report.
However, when clicked, the button becomes active and its z-index
falls to 2, putting it behind the header.

opw-4265087




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

Forward-Port-Of: odoo/odoo#186277

Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579

Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed.

Forward-Port-Of: odoo/odoo#187053
Forward-Port-Of: odoo/odoo#186579

Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set

Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price.

Steps to reproduce:
-------------------
* Create a quotation in the **Sale** app
* In the **Point of Sale** app, open shop session
* Create a downpayment for the order
* Go back in the **Sale** app
* Open sale order
> Observation: The downpayment line has a price unit set
* If needed, deliver the items
* Create an invoice (regular invoice)
* Confirm the invoice
* Go back to the sale order
> Observation: The downpayment line has a price unit of 0.0

Why the fix:
------------
The difference between the two flows (pos/sale) mainly resides in those few lines:
https://github.com/odoo/odoo/blob/b3b1fe6a78f9e5b6f1d993b5aa2fed11e33c793e/addons/sale/models/account_move.py#L75-L85

`dpl.invoice_lines` will include 2 items when using the sale flow whereas only one when making the downpayment in pos.

Downpayments from pos are not automatically invoiced and even if they are, the model `pos.order.line` does not have the field `invoice_lines`.

However each downpayment **sale order line** that comes from the POS is linked to its downpayment **pos order line** with the field `pos_order_line_ids`.

The only element left in `dpl.invoice_lines` will not be counted as it is included in `real_invoice` (the current invoice).

The idea of the fix is to include the price unit of the downpayment made in pos in this sum.

opw-4160111

Forward-Port-Of: odoo/odoo#186753
Forward-Port-Of: odoo/odoo#185788

This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: re

This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen.

Steps to reproduce (on a small screen):
- Install CRM module
- Go to CRM > Configuration > Pipeline > Tags
- Try to modify one of the list's record

⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed

Note: reported during the mobile tests conversion to HOOT in master.



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

Forward-Port-Of: odoo/odoo#187110

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186279 Forward-Port-Of: odoo/odoo#186237

The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up.

Also the other UI strings were in all caps and have been changed to capitalized strings.

[opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444)

Related to https://github.com/odoo/enterprise/pull/73285

Forward-Port-Of: odoo/odoo#186279
Forward-Port-Of: odoo/odoo#186237

Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0 _(website_sale_product_configurator)_ - 17.2 _(website_sale_product_configurator)_ Steps ----- 1. Have 2 products with variants; 2. for both, add the other as optional product; 3. in eCommerce, add one to the cart; 4. select the other in the product configurator. Issue ----- The attributes get messed up due to first product being listed twice in the wizard, once in the cart, and once as an option for the second produc

Versions
--------
- 16.0 _(sale_product_configurator)_
- 17.0 _(website_sale_product_configurator)_
- 17.2 _(website_sale_product_configurator)_

Steps
-----
1. Have 2 products with variants;
2. for both, add the other as optional product;
3. in eCommerce, add one to the cart;
4. select the other in the product configurator.

Issue
-----
The attributes get messed up due to first product being listed twice in the wizard, once in the cart, and once as an option for the second product.

Solution
--------
### Front-end:
Get the IDs of the currently displayed product templates, and pass them to the controller when fetching additional variants.

### Back-end:
Before rendering the configurator template, update the cache to remove the currently displayed products from the added product's `optional_product_ids` field. Re-add them after rendering is done.

opw-4071002
opw-4189450

Forward-Port-Of: odoo/odoo#186789
Forward-Port-Of: odoo/odoo#185103

We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#183879 Forward-Port-Of: odoo/odoo#179361

We were misconfiguring some accounts in ec localization:

- Sale and purchase journals default accounts
- Missing default valuation accounts on Adjustement and Production locations

opw-4127252

Forward-Port-Of: odoo/odoo#183879
Forward-Port-Of: odoo/odoo#179361

Description of the issue/feature this PR addresses: Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process. Current behavior before PR: Currently, it only adds the warehouse information to the context variable. Desired behavior after PR is merged: The context object will include the warehouse information and the current context, ensuring that all necessary context

Description of the issue/feature this PR addresses:

Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process.

Current behavior before PR:

Currently, it only adds the warehouse information to the context variable.

Desired behavior after PR is merged:

The context object will include the warehouse information and the current context, ensuring that all necessary context data is properly included when making the call.



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

Forward-Port-Of: odoo/odoo#178546

Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 Forward-Port-Of: odoo/odoo#186804

Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client.

But this could be improved and fields should be loaded dynamically based on the needed fields.

opw-4262960

Forward-Port-Of: odoo/odoo#186804

use `assertSteps` to rather than `assert.verifySteps` to make sure the steps are executed in the correct order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187191

use `assertSteps` to rather than `assert.verifySteps` to make sure the steps are executed in the correct order.


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

Forward-Port-Of: odoo/odoo#187191

The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email,

The Send & Print dialog will not consider attachments that have the same name as removed ones, example:

- Create an invoice
- Confirm it
- From the action menu: `Print` > `Invoice`
- Download the file to disk - e.g. `INV_2024_00001.pdf`
- Open the `Send & Print` dialog
- Select `Email` only
- Remove the generated attachment `INV_2024_00001.pdf` (on the dialog)
- Add the `INV_2024_00001.pdf` attachment (the one on disk)
- Send the email

The invoice will not be attached to the email, you can check in the chatter.
This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4260237)
opw-4260237

Forward-Port-Of: odoo/odoo#186489

Current Behavior: When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again. To reproduce: 1. Optional: add the field is_move_sent to the view, to see its value 2. Create and confirm an invoice (is_move_sent = False) 3. Send it via the Send & Print button (is_move_sent = True) 4. Reset move to draft (is_move_sent = False

Current Behavior:
When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again.

To reproduce:
1. Optional: add the field is_move_sent to the view, to see its value
2. Create and confirm an invoice (is_move_sent = False)
3. Send it via the Send & Print button (is_move_sent = True)
4. Reset move to draft (is_move_sent = False)
5. Confirm and send it again (is_move_sent = False)

Desired behavior:
is_move_sent should be set to True after being sent via Send & Print, even if it is not the first time the invoice is being sent.

Fix:
We don't reset the is_move_sent to False when we set the invoice to draft.

opw-4245126

Backport of #170713

Forward-Port-Of: odoo/odoo#185830

## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is cal

## Issue:
- When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English.

## Steps To Reproduce:
- Create a storable product.
- Define a vendor for this product and add a delivery lead time.
- Navigate to the product template and click on the "Replenish" button.
- Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time.
- Change the language of the database to a different language.
- Repeat the replenish process.
- Observe that the schedule date is not calculated correctly.

## Solution:
- Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons..

opw-4199660

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

Forward-Port-Of: odoo/odoo#183552

To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239

To reproduce the issue:

1) Create a company A, with a branch B
2) Define a currency rate for A, for currency C
3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown

Forward-Port-Of: odoo/odoo#187239