…ank reco widget Steps to reproduce: - Create a bank journal with a foreign currency - Create a statement line on this journal using a rate - Change the rate on the foreign currency to something else - Open the bank reconciliation widget => The computed amount for the auto_balance line is wrong. Currently, to generate the auto-balance line, we call the method used when creating the journal entry for the statement line. This method is computing the company amounts using the rate encoded

…ank reco widget

Steps to reproduce:
- Create a bank journal with a foreign currency
- Create a statement line on this journal using a rate
- Change the rate on the foreign currency to something else
- Open the bank reconciliation widget => The computed amount for the auto_balance line is wrong.

Currently, to generate the auto-balance line, we call the method used when creating the journal entry for the statement line. This method is computing the company amounts using the rate encoded in odoo. However, the liquidity line is using the journal entry linked to the statement line to compute its amounts. To fix this inconsistency, we retrieve the transaction amount, journal amount and the company amount only from the accounting data without using any conversion rate.

Task : 3132054

Forward-Port-Of: odoo/enterprise#35817
Forward-Port-Of: odoo/enterprise#35723

forgotten fw-port of #15238 Forward-Port-Of: odoo/enterprise#35648 Forward-Port-Of: odoo/enterprise#34657

forgotten fw-port of #15238

Forward-Port-Of: odoo/enterprise#35648
Forward-Port-Of: odoo/enterprise#34657

This commit reorders the following commands: Outline, List, Index and Kanban. The old order was: List, Index, Kanban, Outline. The new order for these commands is: Index, Outline, List, Kanban. task-3128797 Forward-Port-Of: odoo/enterprise#35811 Forward-Port-Of: odoo/enterprise#35663

This commit reorders the following commands: Outline, List, Index and Kanban. 
The old order was: List, Index, Kanban, Outline.
The new order for these commands is: Index, Outline, List, Kanban.

task-3128797

Forward-Port-Of: odoo/enterprise#35811
Forward-Port-Of: odoo/enterprise#35663

Growth comparison was only applied on static lines. This commit adds growth comparison for dynamic lines as well. Forward-Port-Of: odoo/enterprise#35807 Forward-Port-Of: odoo/enterprise#34278

Growth comparison was only applied on static lines.

This commit adds growth comparison for dynamic lines as well.

Forward-Port-Of: odoo/enterprise#35807
Forward-Port-Of: odoo/enterprise#34278

After https://github.com/odoo/enterprise/pull/28071, a click_all test started failing with the error: `TypeError: this.state.selected_salespeople is not iterable`. This was being caused by `result.default_salesman || result.salesman_ids[0] || []` as the second fallback was not an array, therefore not iterable. This commit fixes this issue and also removes the unused context param passed to the `/sale_subscription_dashboard/fetch_data` route. task-3135664 Forward-Port-Of: odoo/ente

After https://github.com/odoo/enterprise/pull/28071, a click_all test started
failing with the error:

`TypeError: this.state.selected_salespeople is not iterable`.

This was being caused by
`result.default_salesman || result.salesman_ids[0] || []` as the second
fallback was not an array, therefore not iterable. This commit fixes this issue
and also removes the unused context param passed to the
`/sale_subscription_dashboard/fetch_data` route.

task-3135664

Forward-Port-Of: odoo/enterprise#35785

… bank reco widget Exclude payments having NULL batch_payment_id and already reconciled batch payments from the candidates batches. Forward-Port-Of: odoo/enterprise#35878

… bank reco widget

Exclude payments having NULL batch_payment_id and already reconciled batch payments from the candidates batches.

Forward-Port-Of: odoo/enterprise#35878

This commit solves an issue in the tax_tags engine. Before, when more than one column with tax_tags engine was specifed, the same values were displayed in all columns as the results where referencing the same object. Forward-Port-Of: odoo/enterprise#35734

This commit solves an issue in the tax_tags engine.

Before, when more than one column with tax_tags engine was specifed, the same values were displayed in all columns as the results where referencing the same object.

Forward-Port-Of: odoo/enterprise#35734

A traceback would occur when changing the content of a note then leaving the view as the Component was being destroyed. Forward-Port-Of: odoo/enterprise#35816

A traceback would occur when changing the content of a note then leaving the view as the Component was being destroyed.

Forward-Port-Of: odoo/enterprise#35816

Post an image on instagram via Odoo, traceback in the logs while serving the callback. A `str` cannot be interpreted as a `Response`. The `@route` decorator should be the first decorator (the one at the top) used to decorate an endpoint. All other decorators should be placed in between `@route` and the endpoint. See also: odoo/odoo#109161 Forward-Port-Of: odoo/enterprise#35680

Post an image on instagram via Odoo, traceback in the logs while serving the callback. A `str` cannot be interpreted as a `Response`.

The `@route` decorator should be the first decorator (the one at the top) used to decorate an endpoint. All other decorators should be placed in between `@route` and the endpoint.

See also: odoo/odoo#109161

Forward-Port-Of: odoo/enterprise#35680

### Steps to reproduce * Create a reconciliation model that matches partners that have a category `C` * Create a bank statement and a partner that has *multiple* categories, including C. * Validate and reconcile The reconciliation model you created should be used, but it is not. opw-3063404 X-original-commit: odoo/odoo@a8c0c8175c1b2713b8de29e1dafce81b8d56e778 Forward-Port-Of: odoo/enterprise#35876

### Steps to reproduce
* Create a reconciliation model that matches partners that have a category `C`
* Create a bank statement and a partner that has *multiple* categories, including C.
* Validate and reconcile

The reconciliation model you created should be used, but it is not.

opw-3063404 

X-original-commit: odoo/odoo@a8c0c8175c1b2713b8de29e1dafce81b8d56e778

Forward-Port-Of: odoo/enterprise#35876

At this point of time in Odoo, if 2 different rates are set on a Purchase line (one via the Account and the DNA category, a second found via the Vehicle), the rate coming from the vehicle takes precedence. In the context of the regulation change, we would like to be more precise than that, and pick the smallest of the two rates. Additionally, several bugs in the disallowed expenses report are being fixed: 1. If a vehicle has several rates for the period covered by the report, the v

At this point of time in Odoo, if 2 different rates are set
on a Purchase line (one via the Account and the DNA category,
a second found via the Vehicle), the rate coming from
the vehicle takes precedence.

In the context of the regulation change, we would like to be
more precise than that, and pick the smallest of the two rates.

Additionally, several bugs in the disallowed expenses report are being fixed:

1. If a vehicle has several rates for the period covered by the report,
the values for the children lines are wrong.
That is because the values are grouped by rate,
which can lead to values being overwritten during post processing.

2. Due to the way line ids are generated,
trying to open the General Ledger from the caret options of account lines
would raise a UserError.
That is because the action expects the account to be the last element
of the line id, which is not always the case in this report.

3. The Journal Items caret options was removed in reportalypse,
but there was no obvious reason. It is reintroduced here.

4. The warning div that is displayed when there are multiple rates
in the report's period did not span across the report
because it was not located in the correct div.

5. The Unfold All options is activated as well.

6. Tests are added to cover most of theses cases.

task-3082174

Forward-Port-Of: odoo/enterprise#35824
Forward-Port-Of: odoo/enterprise#34995

To reproduce: - Go to runbot and login as 'admin' - Activate the developer mode (debug=1) - Go to "Referral" app, click on "Ongoing" UncaughtPromiseError > OwlError Uncaught Promise > Got duplicate key in t-foreach: [object Object] Forward-Port-Of: odoo/enterprise#35727

To reproduce:

- Go to runbot and login as 'admin'
- Activate the developer mode (debug=1)
- Go to "Referral" app, click on "Ongoing"

UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: [object Object]

Forward-Port-Of: odoo/enterprise#35727

In sign_itsme we currently just receive the error that itsme returns us and we show it in a dialog. However, these errors are not translated to the user's language. This commit allows us to receive the error code from the IAP server and map it to a more meaningful and translated error for the user. task-2969605 Forward-Port-Of: odoo/enterprise#32033

In sign_itsme we currently just receive the error that itsme returns us and we show it in a dialog. However, these errors are not translated to the user's language. This commit allows us to receive the error code from the IAP server and map it to a more meaningful and translated error for the user.

task-2969605

Forward-Port-Of: odoo/enterprise#32033

Currently, when using the "/article" command, you cannot type into the "select2" custom element to filter on a specific article. This is caused by a conflict with Bootstrap's "focustrap" that moves the focus outside of the input, and does not allow to move it back in it. This commit hacks the modal to disable this focustrap when the modal is shown. This will be refactored in master to avoid using a legacy modal. Task-3079001 Forward-Port-Of: odoo/enterprise#35733

Currently, when using the "/article" command, you cannot type into the "select2" custom element to filter on a specific article.

This is caused by a conflict with Bootstrap's "focustrap" that moves the focus outside of the input, and does not allow to move it back in it.

This commit hacks the modal to disable this focustrap when the modal is shown.

This will be refactored in master to avoid using a legacy modal.

Task-3079001

Forward-Port-Of: odoo/enterprise#35733

The introduction of the new constraint on the UoM category required that the UoM be explicitely specified in the test setUpClass. Related PR: https://github.com/odoo/odoo/pull/109347 Forward-Port-Of: odoo/enterprise#35670 Forward-Port-Of: odoo/enterprise#35622

The introduction of the new constraint on the UoM category required that the UoM be explicitely specified in the test setUpClass.

Related PR: https://github.com/odoo/odoo/pull/109347

Forward-Port-Of: odoo/enterprise#35670
Forward-Port-Of: odoo/enterprise#35622

Since refactoring made in odoo/enterprise/pull/30774, when we try to send the followup reports from the list view it tries to send all of them with snailmail. This is due to the use of send_email instead of send_letter in the options.get in the override of send_followup in snailmail Forward-Port-Of: odoo/enterprise#35768

Since refactoring made in odoo/enterprise/pull/30774, when we try to send the followup reports from the list view it tries to send all of them with snailmail.

This is due to the use  of send_email instead of send_letter in the options.get in the override of send_followup in snailmail

Forward-Port-Of: odoo/enterprise#35768

Steps to reproduce: - Install website_sale_subscription module - Create a subscription product and a normal product - Go to the website - Add both product to the cart - In the backend, the recurrence should be set on related SO - Go back to the website and remove the subscription product from the cart - Go back to the SO in the backend Issue: The recurrence should be removed, but it's still set. It triggers an issue on the Website where payment methods became

Steps to reproduce:

  - Install website_sale_subscription module
  - Create a subscription product and a normal product
  - Go to the website
  - Add both product to the cart
  - In the backend, the recurrence should be set on related SO
  - Go back to the website and remove the subscription product from the cart
  - Go back to the SO in the backend

Issue:

  The recurrence should be removed, but it's still set.
  It triggers an issue on the Website where payment methods became
  unavailable, even if no subscription product is in the cart anymore.

Cause:

  The recurrence is updated only when added to a subscription product,
  not when removing one.

Solution:

  Override _cart_update_order_line to update recurrence in case a
  subscription product is added or removed to cart.
  PS: If removed, and another subscription product is in the cart, it
  will set the matching recurrence of the first product available
  (it should not be possible to add 2 subscription product from website
  only, but just in case a backend SO became a Website SO).

opw-3099515

Forward-Port-Of: odoo/enterprise#35689

## Current behaviour When selling a recurrent service with fixed/prepaid invoicing, it appears two times in the project profitability report, once as "Fixed/Prepaid" Service, another time as a "Subscription". ## Expected behaviour Such service should only be present in the "Subscription" section. ## Steps to reproduce - Install Sales, Project, Subscription - Create a Service that is invoiced "Fixed/Prepaid", creates a new project on creation - Create a new SO with that product, confir

## Current behaviour
When selling a recurrent service with fixed/prepaid invoicing, it appears two times in the project profitability report, once as "Fixed/Prepaid" Service, another time as a "Subscription".

## Expected behaviour
Such service should only be present in the "Subscription" section.

## Steps to reproduce
- Install Sales, Project, Subscription
- Create a Service that is invoiced "Fixed/Prepaid", creates a new project on creation
- Create a new SO with that product, confirm it.
- Go to the Project's Update of the newly created project
- Observe that the services was accounted 2 times, onces in the "Fixed/Prepaid" section, another time in the "Subscription".

## Reason for the problem
When calculating the profitability from "Fixed/Prepaid" services, we ignore the fact if they are a subscription or not.

## Fix
Extend the domain to not take subscription into account when generating the profitability items that are prepaid services.

## Affected versions
- 16.0
- master
---
opw-3113320

Forward-Port-Of: odoo/enterprise#35765

install account_consolidation module and try creating record in Consolidation -> Configuration -> Company periods, in the form currently the Period will not have required attribute and in the model level the field is required. So if the user tries to create a record without inputting the value to the period field, the exception will be shown.  t

install account_consolidation module and try creating record in Consolidation -> Configuration -> Company periods, in the form currently the Period will not have required attribute and in the model level the field is required.

So if the user tries to create a record without inputting  the value to the period field, the exception will be shown.

![Screenshot from 2022-12-13 20-36-44](https://user-images.githubusercontent.com/27989791/207404996-a8ed6dd3-2644-4f5d-aa0b-8e93c019b21d.png)


this pr will change the given wrong condition and will make the field required in the view level also.

Impacted Versions: 14 and above

Forward-Port-Of: odoo/enterprise#34946

How to replicate the issue ? 1. Setup a company A and a company B 2. Enable invoice & bill synchronisation between the two 3. Create an invoice from company A with company B as the custommer 4. Fill the form and set a due date to somewhere in the future If we go to Accounting > Vendors > Bills on the company B side. We can see that the due date is always set to the invoice date. This is because of this [line](https://github.com/odoo/odoo/blob/ace565ee49d126b53d23cc97ae4cdea2626a9ea9/

How to replicate the issue ?

1. Setup a company A and a company B
2. Enable invoice & bill synchronisation between the two
3. Create an invoice from company A with company B as the custommer
4. Fill the form and set a due date to somewhere in the future

If we go to Accounting > Vendors > Bills on the company B side. We can see that the due date is always set to the invoice date.

This is because of this [line](https://github.com/odoo/odoo/blob/ace565ee49d126b53d23cc97ae4cdea2626a9ea9/addons/account/models/account_move.py#L970)

Because `self.invoice_date_due` is always set to `False`, the method will always return `self.invoice_date`

opw-3111669

Forward-Port-Of: odoo/enterprise#35667

- Have an admin user create a product - Define its default account of type fixed assets - On this account, click on "create and validate" - Create an asset model - Define accounting role of another user to account.group_account_invoice - Log in on this user - Create a bill with the product created before => Posting of the bill is prevented Problem: validating an asset will also modify it So we sudo the auto-creation of the asset/deferred expense/revenue. t-3076379 Forward-Port-Of:

- Have an admin user create a product
- Define its default account of type fixed assets
- On this account, click on "create and validate"
- Create an asset model
- Define accounting role of another user to account.group_account_invoice
- Log in on this user
- Create a bill with the product created before
=> Posting of the bill is prevented

Problem: validating an asset will also modify it
So we sudo the auto-creation of the asset/deferred expense/revenue.

t-3076379

Forward-Port-Of: odoo/enterprise#34350

Forward-Port of https://github.com/odoo/enterprise/pull/35796 Forward-Port-Of: odoo/enterprise#35797

Forward-Port of https://github.com/odoo/enterprise/pull/35796

Forward-Port-Of: odoo/enterprise#35797

In the aged reports (aged receivable/payables), the column amount currency was present which might lead to misunderstanding for users. Indeed, the user expects to see the residual amount instead of the original amount when a partial payment has been done and reconciled. The column has therefore been modified from "amount currency" to "amount residual currency" task-3105257 related PR (fix for Odoo 16) : Forward-Port-Of: odoo/enterprise#35726 Forward-Port-Of: odoo/enterprise#35147

In the aged reports (aged receivable/payables), the column amount currency was present which might lead to misunderstanding for users. Indeed, the user expects to see the residual amount instead of the original amount when a partial payment has been done and reconciled. The column has therefore been modified from "amount currency" to "amount residual currency"

task-3105257
related PR (fix for Odoo 16) :

Forward-Port-Of: odoo/enterprise#35726
Forward-Port-Of: odoo/enterprise#35147

Migration to very old versions of Odoo (6.1 -> 7.0) introduced negative ids for some models (e.g. res.partner). This clashed with the generic ids generated for report lines, as they used the '-' character to join their terms. We fix that by changing '-' by '~' in the generic report ids. Forward-Port-Of: odoo/enterprise#35784

Migration to very old versions of Odoo (6.1 -> 7.0) introduced negative ids for some models (e.g. res.partner). This clashed with the generic ids generated for report lines, as they used the '-' character to join their terms. We fix that by changing '-' by '~' in the generic report ids.

Forward-Port-Of: odoo/enterprise#35784

add missing neutralisation for the the l10n_in_reports_gstr module introduced in https://github.com/odoo/enterprise/pull/34481 Forward-Port-Of: odoo/enterprise#35829 Forward-Port-Of: odoo/enterprise#35783

add missing neutralisation for the the l10n_in_reports_gstr module introduced in https://github.com/odoo/enterprise/pull/34481

Forward-Port-Of: odoo/enterprise#35829
Forward-Port-Of: odoo/enterprise#35783

In some cases, for a purchase journal in the accounting dashboard, the number of "Bills to Pay" will be different than the number of moves in the list view generated by clicking on it. There are two changes to make. 1) Change the `bills_to_pay` filter. In the query that compute the bills to pay for the dashboard view, the `payment_state` field is filtered as: `payment_state in ('not_paid', 'partial')` but in the filter `bills_to_pay`, we find: `('payment_state', 'not in', ('paid', 'in

In some cases, for a purchase journal in the accounting dashboard, the
number of "Bills to Pay" will be different than the number of moves in
the list view generated by clicking on it.
There are two changes to make.

1) Change the `bills_to_pay` filter.
In the query that compute the bills to pay for the dashboard view, the
`payment_state` field is filtered as:
`payment_state in ('not_paid', 'partial')`
but in the filter `bills_to_pay`, we find:
`('payment_state', 'not in', ('paid', 'in_payment'))`
so an `account.move` with a `payment_state == 'reversed'` would be taken
into account by the filter but not by the query.
I've change the filter to match the query.

The query is defined in the function
`_get_open_bills_to_pay_query(self)` in
enterprise/account_3way_match/models/account_journal_dashboard.py

2) Change the context for the "Bills to Pay" link.
When clicking the `Bills to Pay` link, it opens an `account.move` list
view with 3 filters: `Vendor Bills` & `Not Paid` & `Bills to Pay`.
This module is responsible for the last 2 filters.  The `Not Paid` one
should be remove, as the `payment_state` is taken into account in the
`Bills to Pay` filter.
Originally (at the creation of the module), that was not the case and
that's why this filter was added.  Because the`payment_state` domain
is now different than `('payment_state', '=', 'not paid')`, this filter
clashes with the `Bills to Pay` filter and so partially paid moves will
not be shown.

opw-3103219

Forward-Port-Of: odoo/enterprise#35659
Forward-Port-Of: odoo/enterprise#35575

Forward-Port-Of: odoo/enterprise#35814 Forward-Port-Of: odoo/enterprise#35707

Forward-Port-Of: odoo/enterprise#35814
Forward-Port-Of: odoo/enterprise#35707