When validating a payment for a subscription and the sale's setting `sale.automatic_invoice` is enabled, the invoice is send twice to the customer on subscription renewal; first with the normal template then a second time with the subscription specific template.

To reproduce:
- As Administrator:
  - Enable the "Automatic Invoice" option in the setting
  - Install/enable the `demo` payment provider and method

- Log-in as `portal` user
- Go the /shop and add the `Office Cleaning Service (SUB)` to you cart
- Pay your order using the `Demo` payment method => The invoice is send once

- Go to your subscription (/my/subscriptions)
- Click on your new subscription
- Scroll to the `Anticipate payment` section and pay for it (again choose the `Demo` payment method)

- You get back the the subscription page, click on the last invoice (2nd invoice you created)

=> Scroll to the history section and see that the invoice is sent twice

This commit ensure we're only sending invoice with the subscription specific template on renewal.

OPW-3900040

Forward-Port-Of: odoo/enterprise#61838

Steps to reproduce:
- Settings > Enable 'Consolidate subscriptions billing'
- Contact > Create a company
- Contacts & Addresses tab > Add
- Add an invoice address on the company
- Add an individual then duplicate it
- Create a subscription with the indiviual as customer
- Duplicate the subscription then set the duplicate contact as customer
- Debug mode > Scheduled actions
- Sale subscription: Generate recurring invoices and payments > Run manually

The subsciptions are invoiced separately instead of having one invoice
for both. The consolidated billing should produce only one invoice since
the invoicing address is the same.

This behavior works as intended if using the create invoices action on both
subscriptions at once. Here, the recurring invoice creation for subscriptions
uses its own grouping function using partner_id as a key instead of
partner_invoice_id which is 'parent invoice address id if any, else partner_id'.

Because this grouping is performed before creating the invoices, we end
up processing sale orders that should have belonged to the same group
separarately and thus create the invoices one by one. This means we
don't let _create_invoices do the grouping since we only pass it one SO
at a time, this fix will make it so _create_invoices is called on the
grouped SOs instead.

opw-4114035

Forward-Port-Of: odoo/enterprise#69277

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.

This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised.

Step to reproduce:
- create a db with hr_timesheet installed
- have a user with 'user' access rights on project and 'own timesheet' on timesheet
- create an internal project
- create a task inside that internal project and assigned the user on it
- connect with the other user
- open timesheet app
- select the task from the internal project to start a new timesheet timer
- an error access right on 'project' is triggered

Solution:
Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project.

task - 3922511
affected version 16.0 - master

Forward-Port-Of: odoo/enterprise#69226
Forward-Port-Of: odoo/enterprise#63159

### Steps to reproduce:
	- Install Sale and Field Service modules
	- Create a Quotation with a normal product and another Field service product
	- Confirm the quotation and invoice it
	- Change the delivered quantity of the field service product to meet the order quantity
	- Check the invoice status (will be 'Fully Invoiced')
	- Set the field service product in the SO to a unit price 0

### Current behavior before PR:
After creating an invoice for a SO that has field service product and then set the product's unit price to 0 the SO invoice_status will change from 'Fully invoiced' to 'Nothing to invoice'. This is happening because in FSM we don't invoice SOL that has price_unit equals 0 which will lead that the SO inovice status will change too to 'Nothing to invoice'. https://github.com/odoo/enterprise/blob/17.0/industry_fsm_sale/models/sale_order.py#L84:L91

### Desired behavior after PR is merged:
We are now checking before computing the invoice status of any FSM product if the SO is not yet invoiced because if it is we won't modify the invoice status of the SOL.

opw-4017282

Forward-Port-Of: odoo/enterprise#68893

Currently error is generated when try to edit 'Invoices' or 'Invoices without Payment' reports in studio mode when there is no record.

Steps to reproduce:

- Install an 'account' and 'web_studio' module (Without demo data).
- Navigate to invoicing / Customers / Invoices and open a web studio mode.
-  Open reports  and click on the 'Invoice' or 'Invoices without Payment' reports.
- Click on 'EDIT SOURCES'.

See Traceback:-

```
TypeError: 'bool' object is not subscriptable
  File "<744>", line 200, in template_744
  File "<744>", line 13, in template_744_content
QWebException: Error while render the template
TypeError: 'bool' object is not subscriptable
Template: ir.ui.view(744,)
Path: /t/t
Node: <t t-foreach="tax_totals[\'subtotals\']" t-as="subtotal"/>
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1827, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, 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 1825, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 739, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 652, in save_report
    report_html = self._render_report(report, record_id)
  File "home/odoo/src/enterprise/saas-17.2/web_studio/controllers/report.py", line 597, in _render_report
    return request.env['ir.actions.report'].with_context(studio=True)._render_qweb_html(report, [record_id] if record_id else [], {"studio": True})
  File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_actions_report.py", line 24, in _render_qweb_html
    return super(IrActionsReport, self)._render_qweb_html(report_ref, docids, data)
  File "odoo/addons/base/models/ir_actions_report.py", line 927, in _render_qweb_html
    return self._render_template(report.report_name, data), 'html'
  File "odoo/addons/base/models/ir_actions_report.py", line 654, in _render_template
    return view_obj._render_template(template, values).encode()
  File "home/odoo/src/enterprise/saas-17.2/web_studio/models/ir_ui_view.py", line 1302, in _render_template
    return super(View, self)._render_template(template, values)
  File "odoo/addons/base/models/ir_ui_view.py", line 2024, in _render_template
    return self.env['ir.qweb']._render(template, values)
  File "odoo/tools/profiler.py", line 302, in _tracked_method_render
    return method_render(self, template, values, **options)
  File "odoo/addons/base/models/ir_qweb.py", line 594, in _render
    result = ''.join(rendering)
  File "<748>", line 42, in template_748
  File "<748>", line 31, in template_748_content
  File "<747>", line 90, in template_747
  File "<747>", line 72, in template_747_content
  File "<747>", line 60, in template_747_t_call_0
  File "<742>", line 2412, in template_742
  File "<742>", line 2394, in template_742_content
  File "<742>", line 1650, in template_742_t_call_0
  File "<744>", line 208, in template_744
```

The issue occurs when the system tries to access a boolean value which is stored in 'Tax_totals' in the 'document_tax_totals' template [1] and this a boolean value is passed into 'tax_totals' from this line [2] because record is not available.

link [1]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/views/report_invoice.xml#L200-L201
link [2]: https://github.com/odoo/odoo/blob/a8daed02c58ab69cdea57a8f97065e229b07f0ab/addons/account/models/account_move.py#L1348

To resolve the issue, Add a condition that checks whether the 'Tax_totals' is available before call the 'document_tax_totals' template.

sentry-4499699758

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

Forward-Port-Of: odoo/odoo#161249

Before this commit, event listeners set on inputs by the datetime picker
service would be removed in the callback of the `useEffect` hook,
meaning that these listeners could be unregistered before the actual
elements would be removed.

This is an issue in the specific case where the deletion of the element
occurs before the "change" event has been dispatched and after the
removal of the listeners. The thing is: the removal of the element also
triggers the "change" event (if it hasn't been triggered before), and
with the listener gone this means that the value is lost.

This commit deletes the removal of event listeners attached on inputs
by the hook. This has been done since using the datetime picker service
implies that the inputs affected by the feature will never be in an
interactive state without the datetime picker actively listening on
them.

Although a test case setup is easy to reproduce, this behavior is
unfortunately impossible to reproduce programmatically as the "change"
event dispatched by removing an element only works when a trusted
"input" event was triggered to change its value (setting the internal
browser "changed" value of the input).

Task [4104407](https://www.odoo.com/odoo/all-tasks/4104407)

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

Forward-Port-Of: odoo/odoo#178533

Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases
- Multiple payment term lines
- Discount on payment term lines

This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly).

After this commit the cash rounding is applied to the payment terms:
- The amount of each payment term line is cash rounded
- The discounted amount of each payment term line is cash rounded

Reproduce:
  1. Install module `account` (or `account_accountant`)
  2. Create a payment term with 1 line with 10% discount when paid within 30 days. Ensure "Display terms on invoice" is on. (Invoicing / Accounting -> Configuration (menu) -> Payment Terms)
  3. Enable "Cash Rounding" in the settings
  4. Create a cash rounding with precision 0.05 and rounding method HALF-UP (Invoicing / Accounting -> Configuration (menu) -> Cash Roundings)
  5. Create an invoice
     - Payment term from step 2
     - Cash rounding from step 3 (set in "Other Info" tab) - A line s.t. the total is 868.35 (This value does not need cash rounding)
  6. Confirm the invoice
  7. Print the invoice: On the PDF the value 781.52 is shown for the payment terms. But the value should be 781.50 due to the cash rounding.
  8. Register payment: The amount 781.52 is suggested. But the value should be 781.50 due to the cash rounding. Changing the amount to 781.50 loses the automatic reconciliation.

task-4095505
opw-3985470

Forward-Port-Of: odoo/odoo#178344
Forward-Port-Of: odoo/odoo#176289

When the user tries to unarchive the multiple views,
a traceback will appear.

Steps to reproduce the error:
- Install 'website'
- Go to Settings > Technical > Views
- Open archived views > unarchive multiple views

Traceback:
```
ValueError: Expected singleton: ir.ui.view(534, 535, 537)
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, 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 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "odoo/models.py", line 5771, in action_unarchive
    return self.filtered(lambda record: not record[self._active_name]).toggle_active()
  File "odoo/models.py", line 5759, in toggle_active
    (self - active_recs)[self._active_name] = True
  File "odoo/models.py", line 6619, in __setitem__
    return self._fields[key].__set__(self, value)
  File "odoo/fields.py", line 1376, in __set__
    records.write({self.name: write_value})
  File "addons/website/models/theme_models.py", line 366, in write
    return super().write(vals)
  File "addons/website/models/ir_ui_view.py", line 95, in write
    return super(View, self).write(vals)
  File "odoo/addons/base/models/ir_ui_view.py", line 529, in write
    self._validate_fields(['arch_db'])
  File "odoo/models.py", line 1484, in _validate_fields
    check(self)
  File "odoo/addons/base/models/ir_ui_view.py", line 371, in _check_xml
    view=self.key or self.id,
  File "odoo/fields.py", line 1202, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5856, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

https://github.com/odoo/odoo/blob/9be0c5348bfeb338bcba95b2a9c01e0d7dd14306/odoo/addons/base/models/ir_ui_view.py#L379 Here, self is used in place of view.
So it will lead to the above traceback.

sentry-5604174783

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

Forward-Port-Of: odoo/odoo#173117

### Steps to reproduce:

- Enable Multi-Step Routes in the settings
- Go to Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable product:
  - Routes: MTO, manufacture
  - With a bom
  - On hand qty: 10
- Create an SO for 15 units and validate
- Go back to your product form > forecasted Report
#### > Even thought 15 units are made to order 10 units are reported to be taken from stock to fulfill the SO

### Cause of the issue:

The lines appearing on the reported are computed by the `_get_report_lines` method. During this call, the quantity taken from stock is computed by comparing the demand of the out moves with the quantity currently in stock:
https://github.com/odoo/odoo/blob/1fdccad664cad37a69dc960444aa0c318d1bf464/addons/stock/report/report_stock_forecasted.py#L218-L223 This is incorrect because the quantity taken from stock is null if the procure_method of the out move is make_to_stock.

### Note:

The issue is not reproducible since 17.0 since the _get_report_lines has been refactored during the stockpocalypse.

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

Forward-Port-Of: odoo/odoo#177867
Forward-Port-Of: odoo/odoo#176273

Currently, a log error is generated when the user tries to import a module that is not the same as the current Odoo version.


Stack Trace:
```
ValueError: Invalid version '17.0.1.0.0'. Modules should have a version in format `x.y`, `x.y.z`, `saas~17.2.x.y` or `saas~17.2.x.y.z`.
  File "addons/base_import_module/models/ir_module.py", line 253, in _import_zipfile
    self.sudo()._import_module(mod_name, path, force=force, with_demo=with_demo)
  File "addons/base_import_module/models/ir_module.py", line 81, in _import_module
    values['latest_version'] = adapt_version(terp['version'])
  File "odoo/modules/module.py", line 423, in adapt_version
    raise ValueError(f"Invalid version {base_version!r}. Modules should have a version in format `x.y`, `x.y.z`,"
```

The error was caught on log because at [1] `_logger.exception()` was used, and this log error was not
useful because after the printing, the log `UserError` was raised, which shows the user what's wrong with its custom module.

This commit removes the logger exception because the `UserError` shows
what is wrong with the custom modules.

[1]-https://github.com/odoo/odoo/blob/b95edd874ce904ef231c295790a003992db002e3/addons/base_import_module/models/ir_module.py#L255-L258

sentry-4931285432

Forward-Port-Of: odoo/odoo#160274

Version: 16

Description of the issue/feature this PR addresses:

A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is not on hand in menu "Accounting / Customers / Third Party Checks" if journal doesn't has "Existing Third Party Checks" incoming payment method.

Steps to reproduce:

1) Log in with admin on runbot odoo enterprise 16 instance and install l10n_latam_check (Third Party and Deferred/Electronic Checks Management) module.

2) Go to "Accounting / Configuration /Accounting / Journals" and create a new journal of type "Cash" and add incoming payment method "New Third Party Checks".
![image](https://github.com/user-attachments/assets/a600542a-8e35-473a-b5a6-66b6d6cbc15b)

3) Create a new customer payment with journal created on step 2 and "New Third Party Checks" payment method and confirm.
![image](https://github.com/user-attachments/assets/4036ef78-03d1-4993-aa66-a49ae7174069)

4) Go to menu Third Party Checks and the check received on step 3 is not on hand.
![image](https://github.com/user-attachments/assets/84fe2ffb-3ce4-42df-9cd6-c31dd81c84dd)


Current behavior before PR:

A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is not on hand on tree view in "Accounting / Customers / Third Party Checks" if the journal doesn't has "Existing Third Party Checks" incoming payment method.

Desired behavior after PR is merged:

A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is on hand on tree view in "Accounting / Customers / Third Party Checks" if the journal doesn't has "Existing Third Party Checks" incoming payment method.

Ticket Adhoc side: 77887
Task Latam side: 1234


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

Forward-Port-Of: odoo/odoo#174283

[FIX] website_sale: Avoid collect sale orders confirmed in backend

This happens when, during a payment process, when the order is confirmed from the backend and in Website the cart icon is clicked.  What causes the error is that the request is still pinned in the session, so it identifies that certain values ​​should not be loaded and deletes them.

The cart() method identifies if it's not a draft order, and in that case it clears the session order to continue with a new one.  That causes undesired modifications in modules that inherit cart() and execute before calling super(), such as website_sale_delivery, that removes carrier from order. With this motification the method sale_get_order() will now discriminate the orders that are completed and clear ir from the session, avoiding losses of information.

Description of the issue/feature this PR addresses:

This error was detected because the carrier_id was eliminated when following the aforementioned flow. The problem is that clicking on the cart retrieves the order that is in the session, but if it has been confirmed from the backend it should not collect it since at that moment it is not a "cart".

A way to see this clearly is with the 'delivery_auto_refresh' module. This module shows the carrier_id field in sale order view (that exists but is not visible), which is collected at website. The flow that exists nowadays remove this value when we follow this steps:

[Grabación de pantalla desde 16-08-24 10:41:50.webm](https://github.com/user-attachments/assets/9ec82b67-3e73-4083-b65b-be8d59db6a5a)


In this video:
1. Customer starts an order
2. An user confirms the order at backend
3. Customer acceses to /shop/cart
4. Some fields of the sale order can be deleted, such as the delivery carrier

If we confirm the order at backend and then follow the flow shown, the value of this field will dissapear. This happens because, as I said before, clicking the cart icon recovers the confirmed sale order (which is no longer a 'cart') and deletes many values of it.

Current behavior before PR:

If you confirm an order in process from website at backend and then click on the cart icon, certain fields are eliminated.

Desired behavior after PR is merged:

The cart button identifies whether the order is in confirmed status (or quote sent), and if so removes it from the session before the fields are cleared, thus starting a new order.

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

Forward-Port-Of: odoo/odoo#178953
Forward-Port-Of: odoo/odoo#176718

When the product has the "continue selling" box when "out-of-stock" checked, and you add the product to the wishlist from ecommerce, "Temporarily out of stock" message/warning will appear in the wishlist.

To Reproduce on Runbot:
1. Make sure ecommerce module is installed
2. Go to storable product (for example: Cable Management Box)
3. In the sales tab, make sure the option "Continue Selling" for Out-of-Stock field is checked
4. Go to ecommerce, search for the product (here, let's search for Cable Management Box), click on it
5. Click on add to wishlist
6. Go to wishlist.
7. We'll see "Temporarily out of stock" message.

But, we don't want this because we want to continue selling even if it's out of stock, and don't want to customer to get confused with the message. So, since the message/warning doesn't align with the concept of continue selling when out of stock, we want to get rid of the message/warning if the product has "continue selling" box checked.

opw-4121929

Forward-Port-Of: odoo/odoo#177993

Currently, an error occurs when creating foreign taxes for 'Austria'.

Steps to produce:

- Installing the 'account' module.
- Go to Invoicing / Configuration / Accounting / Fiscal Positions.
- Create a Fiscal Position, Set the Country as 'Austria', and enter an 'FR23334175221'(For example) as 'Foreign Tax ID'.
- And Create the taxes for this country.

Stack Trace:

```
KeyError: 'children_tax_ids'
  File "odoo/http.py", line 2374, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1904, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1967, 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 1934, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2178, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 755, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 40, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 459, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/account/models/partner.py", line 289, in action_create_foreign_taxes
    self.env["account.chart.template"]._instantiate_foreign_taxes(self.country_id, self.company_id)
  File "addons/account/models/chart_template.py", line 929, in _instantiate_foreign_taxes
    children_taxes = tax_data['children_tax_ids'].split(',')
```

An error occurs when the system tries to get a 'children_tax_ids' key from tax data at [1] while foreign tax creation, But it is not available.

link [1]: https://github.com/odoo/odoo/blob/4c79aceb3a6c08453f9ec66131e1bc525eae140c/addons/account/models/chart_template.py#L936

To resolve the issue, make small changes into tax data where 'amount_type' = 'percent' instead of 'amount_type' ='group'.

Sentry-5730875398

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

Forward-Port-Of: odoo/odoo#178939
Forward-Port-Of: odoo/odoo#178058