The website editor now shows and hides button tooltips correctly after the Bootstrap update. This prevents tooltips in the editing side panel from getting stuck or failing to appear again, making website editing smoother for users.

This commit fixes the behavior of the tooltips of any buttons with a
title attribute because since the bootstrap update to 5.3, they were not
working well anymore.

When using selector within a tooltip in bootstrap < 5.3, you had hover
behavior (which was wanted) by default on every 'children tooltip', now
you haven't. So we instantiate tooltips 1 by 1 to explicitly have the
hover behavior. Explicitly setting the behavior on 'hover' with a
selector isn't working either because of [1].

Steps to reproduce :
 - Enter edit mode
 - Hover 'Discard' button
 - Unhover it
 - Hover 'Mobile preview' button
 - Unhover it
 - Try hovering again the 'Discard' button

=> Tooltips doesn't disappear unless you click them, you can't display
tooltips a second time.

Commit introducing the bug : [2]

[1]: https://github.com/odoo/odoo/blob/058212e12b5079eba870bde9775fe98f27928935/addons/web/static/lib/bootstrap/js/dist/tooltip.js#L504
[2]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935

task-3998800

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

Calendar-related automated tests were adjusted to run more efficiently by avoiding slower timing operations. This helps reduce test execution time for developers and maintainers without changing how users experience the calendar.

This commit adds small improvements to the calendar tests and test utility functions in an effort to speed up the execution of tests.

The main bottleneck was a bunch of calls to `runAllTimers()`, which interacts very badly with FullCalendar as it uses a lot of timers and this creates a large overhead.

This overhead is minimized through the use of more precise calls to `advanceTime()` and with less calls to `animationFrame()`.

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

This update keeps the appointment customization form working after a related platform change. It adjusts how the form dialog references its custom behavior, preventing potential loading or display issues for users managing appointment forms.

With https://github.com/odoo/odoo/commit/2b46bfdf63b316ffb5fd57b57b3c6aa16c7d0ba6, the prop type of the View component can no longer be a js_class.
Here we fix the component CustomAppointmentFormViewDialog by using the
new View prop jsClass introduced in https://github.com/odoo/odoo/pull/173491.

The Dutch reporting test setup was corrected so the required test user remains available throughout XML validation. This prevents false test failures and helps keep Dutch report exports stable before release.

Currently, the external `l10n_nl_reports` test checking the validity of the generated XML file is failing due to some missing user.

By adding the `enter_test_mode` method, we make sure that the user will be maintained all throughout the testing process like this is done for the non-external test.

Fixes an internal appointment form dialog setup so it works with recent view handling changes. This helps prevent appointment form sharing dialogs from failing due to an outdated configuration reference.

To reproduce the bug: 1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5. 2. Go to the website and add a product to the cart. 3. Go to the cart and click on the "+" button. Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend. opw-3990565 Forward-Port-Of: odoo/odoo#171104

To reproduce the bug:
1. On Runbot, set the decimal accuracy of "Product Unit of Measure" to 5.
2. Go to the website and add a product to the cart.
3. Go to the cart and click on the "+" button.

Some decimals may appear due to issues related to floating-point numbers. This issue is being addressed and will be fixed in the future (see: https://github.com/odoo/odoo/pull/152709). In the meantime, we can apply a fix on the frontend.

opw-3990565

Forward-Port-Of: odoo/odoo#171104

Specification: The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog. Expected behavior: The automation rule ID and name are visible, and both buttons work as expected. Task-3959044 Forward-Port-Of: odoo/odoo#171486

Specification:
The automation name and ID are not visible. Additionally, the 'Disable Automation Rule' and 'Edit Automation Rule' buttons are not working in the error dialog.

Expected behavior:
The automation rule ID and name are visible, and both buttons work as expected.

Task-3959044

Forward-Port-Of: odoo/odoo#171486

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`. This commit simply performs a quick raw SQL check to ensure no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

You can't run the `populate` odoo-bin command more than once if `product.product` is part of the models to be populated. This is because it will always generate a kind of fixed barcode pattern in the form of `BARCODE-PP-{counter}`.

This commit simply performs a quick raw SQL check to ensure  no previous populate run was done, and if it was it simply retrieves the barcode of the last product created through a previous populate command. If that barcode exists, is then used as prefix itself.

Running the populate command 4 times in a row will produce the following results:
```
select id,default_code, barcode from product_product order by id desc;

 id  | default_code |          barcode
-----+--------------+----------------------------
 639 | PP-150       | BARCODE-PP-150-150-150-150
 638 | PP-149       | BARCODE-PP-150-150-150-149
              ...
```

Another option would have been to use a fully randomized string, but avoiding randomness is preferable, especially when considering the case of running the populate command only once.

Note that the `product.product` model is the only problematic one when
running back to back `populate` on all models used by accounting:
- account.move
- account.journal
- account.bank.statement
- account.bank.statement.line
- account.payment
- account.reconcile.model
- account.reconcile.model.line
- res.company
- res.partner
- res.partner.industry
- product.product
- product.category
- ...probably more through `_populate_dependencies`...

task-3821088

Forward-Port-Of: odoo/odoo#166365

Before this commit, the test `test_change_reward_value_with_language` was using a partner only available in demo data. This commit removes the use of demo data in the test by using a partner created in the test itself. Runbot error: 70611, 70477, 70419, 70480 Forward-Port-Of: odoo/odoo#173301 Forward-Port-Of: odoo/odoo#173170

Before this commit, the test `test_change_reward_value_with_language` was using a partner only available in demo data.

This commit removes the use of demo data in the test by using a partner created in the test itself.

Runbot error: 70611, 70477, 70419, 70480

Forward-Port-Of: odoo/odoo#173301
Forward-Port-Of: odoo/odoo#173170

This commit should fix the following error which is thrown from time to time on runbot. ``` [HOOT] HootDomError: Could not find elements matching ".o_content" within 200 milliseconds at http://127.0.0.1:8069/web/assets/6bdc9d0/web.assets_unit_tests_setup.min.js:3227:8 ``` Forward-Port-Of: odoo/odoo#172622

This commit should fix the following error which is thrown from time to time on runbot.
```
[HOOT] HootDomError: Could not find elements matching ".o_content" within 200 milliseconds
at http://127.0.0.1:8069/web/assets/6bdc9d0/web.assets_unit_tests_setup.min.js:3227:8
```

Forward-Port-Of: odoo/odoo#172622

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173112 Forward-Port-Of: odoo/odoo#172413

This commit normalize the breakpoint used to set the justification of the dialog footer's buttons. The issue is that the breakpoint used in the utility classes didn't match the css used for nested footer's children, resulting into discrepancy in in-between viewport sizes.


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

Forward-Port-Of: odoo/odoo#173112
Forward-Port-Of: odoo/odoo#172413

NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs. In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that. (cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024) 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 t

NOTE: to speed up the merge process of https://github.com/odoo/odoo/pull/170785, I've cherry-picked the changes that were not yet merged in other PRs.

In mrp bom kanban view, it is written "clatt" instead of "class". This commit changes that.

(cherry picked from commit 758d3b80d6b1ce035a48fab42b7cab68e4ed7024)

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#173224
Forward-Port-Of: odoo/odoo#173151

### Steps to reproduce #### Use case 1: 1. Create a PO with 2 lines having different "expected arrival". 2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified. 3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines. #### > the date is changed on all the lines #### Use case 2: 1. Create a PO with 1 line and change its date planned to tomorrow 2. Save the PO 3. Add a new li

### Steps to reproduce

#### Use case 1:

1. Create a PO with 2 lines having different "expected arrival".
2. Change the "expected arrival" of one of the lines so that the earliest date of all the lines is modified.
3. This will change the "expected arrival" of the PO (intended) but also the "expected arrival" of all PO lines.
#### > the date is changed on all the lines

#### Use case 2:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line on the SO and set a product
#### > the date is changed on all the lines

#### Use case 3:
1. Create a PO with 1 line and change its date planned to tomorrow
2. Save the PO
3. Add a new line for a product with at least 2 product variant and complete his grid for quantities
#### > the date is changed on all the lines

### Cause of the issue:

The `date_planned` fields of the `purchase.order` and `purchase.order.line` are both computed and stored.  When the `date_planned` of a line (new or already existing) is changed, it triggers the compute method of the `date_planned` of the purchase order and changes it: https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L184-L190 
This will in turn trigger the `onchange_date_planned` of the purchase order since we are in the Form view of that model and will update the "planned_date" of every other existing line accordingly:
https://github.com/odoo/odoo/blob/5d8c8f3d01c3c633bcacbdb9e42419e11eb802d9/addons/purchase/models/purchase_order.py#L229-L232

### Fix

We add back the override of the onchange that was present in previous versions and removed in the onchange refactoring made in commit https://github.com/odoo/odoo/commit/109935dbc10256bebb1f5ee0d76a23df7ea91e9f. The purpose of this override being to remove any update of the 'date_planned' of the POL's from the onchange call if this one was triggered by a change of an POL.

#### Note: 
The third use case was fixed by commit 387e9a4 by adding the `_must_delete_date_planned` method but this fix becomes ineffective without the onchange override.

opw-4000019
opw-4012390
opw-4028100
---

Forward-Port-Of: odoo/odoo#171769

Enterprise: https://github.com/odoo/enterprise/pull/66743 Design Themes: https://github.com/odoo/design-themes/pull/831

Enterprise: https://github.com/odoo/enterprise/pull/66743
Design Themes: https://github.com/odoo/design-themes/pull/831

# :whale: Enterprise PR: https://github.com/odoo/enterprise/pull/61967 taskid: 3603762 Forward-Port-Of: odoo/odoo#162196

# :whale:  

Enterprise PR: https://github.com/odoo/enterprise/pull/61967
taskid: 3603762

Forward-Port-Of: odoo/odoo#162196

…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#172683 Forward-Port-Of: odoo/odoo#154760

…ecordset

Steps to reproduce:
install hr_expense with demo data
try to make a jsonrpc or any search on product.product with no domain ->key error

Before PR:
When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys

opw-3741337

Forward-Port-Of: odoo/odoo#172683
Forward-Port-Of: odoo/odoo#154760

A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query. Description of the issue/feature this PR addresses: Creating an analytic account is slow on a db with 1.5M account.analytic.line. Current behavior before PR: Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39 Desired behavior after PR is merged: Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9 --- I confirm I have signe

A search_count is enough in this use case, especially because a classic search adds a (useless here) order by to the query.

Description of the issue/feature this PR addresses:
Creating an analytic account is slow on a db with 1.5M account.analytic.line.

Current behavior before PR:
Slow query (2.0 s) https://explain.dalibo.com/plan/dgf46e2gd03gcf39

Desired behavior after PR is merged:
Fast query (0.2 ms) https://explain.dalibo.com/plan/464363de3f09eff9


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

Forward-Port-Of: odoo/odoo#173437

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made. opw-3987849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173282

Before this commit, opening a record from the list view triggered field validity checks, resulting in unnecessary notifications. This commit optimizes the process by bypassing the _checkValidity function when no changes to the record have been made.

opw-3987849

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

Forward-Port-Of: odoo/odoo#173282

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones Expected deferred accounts: - Expense: 486000 - Revenue: 487000 task-383985 Forward-Port-Of: odoo/odoo#171416

Accounts 471000 to 475000 can be used as suspense accounts. 471000, 472000 & 473000 have been chosen since they're the 1st ones

Expected deferred accounts:
- Expense: 486000
- Revenue: 487000

task-383985

Forward-Port-Of: odoo/odoo#171416

before this commit, a traceback was showing on creating product variant steps to reproduce: * click create button in product, traceback will be showing after this commit, without any traceback product is created traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7 traceback details:  super()._compute_display_name() File "/da

before this commit, a traceback was showing on creating product variant

steps to reproduce:
* click create button in product, traceback will be showing

after this commit, without any traceback product is created

traceback is introduced in: https://github.com/odoo/odoo/commit/758ced91f8cb220a003a49b01e047b507f8509d7

traceback details:

![2024-07-08_14-02](https://github.com/odoo/odoo/assets/99093808/fc3c5132-3e22-478f-8b93-2daf60877bc0)

super()._compute_display_name()
File "/data/build/enterprise/sale_renting/models/product_product.py", line 14, in _compute_display_name
super()._compute_display_name()
File "/data/build/odoo/addons/l10n_gcc_invoice/models/product.py", line 23, in _compute_display_name
product.display_name = re.sub(r'(\d)(\s)([\u0600-\u06FF])', repl, product.display_name)
File "/usr/lib/python3.10/re.py", line 209, in sub
return _compile(pattern, flags).sub(repl, string, count)
TypeError: expected string or bytes-like object

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

Forward-Port-Of: odoo/odoo#172240

Before this commit, the self order was created with the user of the current session. This is not the expected behavior, as the self order is always accessed by a public user. This commit fixes this by always using the self user for the self order. Forward-Port-Of: odoo/odoo#173292

Before this commit, the self order was created with the user of the
current session. This is not the expected behavior, as the self order
is always accessed by a public user.

This commit fixes this by always using the self user for the self order.

Forward-Port-Of: odoo/odoo#173292

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models. By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

The index definition that supports the implementation of `_search_phone_mobile_search` defined in the `PhoneMixin` is created in an `_auto_init` in `crm_lead` of the `crm` module. This means that other models that use the mixin (for ex: `res_partner`) will not get the indexes for it's table, leading to Seq.Scans when searching for a phone number on those models.

By hoisting the index definition to an `init` in the mixin, all models that inherit from the mixin will have the supporting index.

Also add the same custom `trigram` index to support `like/ilike` operators in domains.

task-3942852

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

Forward-Port-Of: odoo/odoo#166698

This PR reverts the changes from commit [170126](https://github.com/odoo/odoo/pull/170126/commits/5ee56608c0c397d03a82a8472dfdab46213f6a27) Because the flex-shrink: 0 is making the iframe overflow and introduces a horizontal scrollbar Task-4050207 Forward-Port-Of: odoo/odoo#173109

This PR reverts the changes from commit [170126](https://github.com/odoo/odoo/pull/170126/commits/5ee56608c0c397d03a82a8472dfdab46213f6a27)

Because the flex-shrink: 0 is making the iframe overflow and
introduces a horizontal scrollbar

Task-4050207

Forward-Port-Of: odoo/odoo#173109

[IMP] account_online_synchronization: disable auto sync on interactive connection 1- Some providers have bank institutions that are "interactive". In a general way, interactive institution means that users have to refresh their connection with the provider to ensure that they can still have an access to the bank. 2- It's a nightmare for users and for support as the connections keep failing in error. - Disable the automatic synchronization flow on bank sync connections with an interact

[IMP] account_online_synchronization: disable auto sync on interactive connection

1- Some providers have bank institutions that are "interactive".
In a general way, interactive institution means that users have to refresh their connection with the provider
to ensure that they can still have an access to the bank.

2- It's a nightmare for users and for support as the connections keep failing in error.

- Disable the automatic synchronization flow on bank sync connections with an interactive providers and a message should be displayed explaining the situation to users.

task-id#3887751

odoofin-pr#https://github.com/odoo/odoofin/pull/297

Forward-Port-Of: odoo/enterprise#63926

The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is that the list of IDs can be gigantic, leading to performance issues. Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report. That PR then simply bypassed the issue by passing t

The model 347 report is adding a partner exclusion domain in the search call.
It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf.
The issue is that the list of IDs can be gigantic, leading to performance issues.

Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report.
That PR then simply bypassed the issue by passing the domain as `forced_domain` so it would not go through the `literal_eval()` call (which is the one crashing when the list is too long).

But even after that fix, we still provide the list of IDs into the domain and so ultimately in the SQL request, which can still be an issue if there are too many.

This commit improves that by passing the SQL subquery (the one fetching the partners to exclude) directly into the domain, so the SQL query won't contain any list of IDs but just a sub-select. It does have better performance within PostgreSQL for big lists.

Note that the `SQL()` query is surrounded by parentheses on purpose, as it doesn't work otherwise. This might be improved at the ORM level in the future with odoo/odoo#163560.

Task [link](https://www.odoo.com/web#model=project.task&id=3895983)
task-3895983

Forward-Port-Of: odoo/enterprise#62866

Steps to reproduce: - Install "Field Service" - Open "Project" - Open the settings of a random project - Then click on the "Settings" tab - Disable "Field Service" and enable "Worksheets" - Create a new task with a worksheet - Click on start then stop and save - Click on "Sign Report" Issues: The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled. https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f388448

Steps to reproduce:
- Install "Field Service"
- Open "Project"
- Open the settings of a random project
- Then click on the "Settings" tab
- Disable "Field Service" and enable "Worksheets"
- Create a new task with a worksheet
- Click on start then stop and save
- Click on "Sign Report"

Issues:
The sign button is not displayed due to the condition in the template which required previously to have `is_fsm` enabled.

https://github.com/odoo/enterprise/blob/4d0a467220fba5253fb4a6f38844861d9ed4e442/industry_fsm/views/project_portal_templates.xml?plain=1#L42

opw-4032692

Forward-Port-Of: odoo/enterprise#66599
Forward-Port-Of: odoo/enterprise#66057

When the document is filled in with the OCR values, we need to use the document's company context, otherwise it can lead to inconsistent values being selected. For example, the payment terms of a supplier are company dependent, so we need the right company context to select the one from the company of the invoice. Related task: [#3902741](https://www.odoo.com/odoo/project.task/3902741?cids=1) Forward-Port-Of: odoo/enterprise#66168

When the document is filled in with the OCR values, we need to use the document's company context, otherwise it can lead to inconsistent values being selected.
For example, the payment terms of a supplier are company dependent, so we need the right company context to select the one from the company of the invoice.

Related task: [#3902741](https://www.odoo.com/odoo/project.task/3902741?cids=1)

Forward-Port-Of: odoo/enterprise#66168

Community: https://github.com/odoo/odoo/pull/173324 Design Themes: https://github.com/odoo/design-themes/pull/831

Community: https://github.com/odoo/odoo/pull/173324
Design Themes: https://github.com/odoo/design-themes/pull/831

Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#65609

Issue:
--------------------
When you open a sign template you can see there are double scroll bars on the iframe

Cause:
----------------------
The sign item toolbar placed on the left side is given 100% height and  1px border which is causing the iframe body to overflow

Solution:
-----------------------------
The 100% height given to the toolbar is changed with -webkit-fill-available

task-4014519

Forward-Port-Of: odoo/enterprise#65609

The current code is taking the residual amount instead of the statement line amount. When doing a reco model 'percentage_st_line' on 1000: Line 1 - 74% Line 2 - 24% Line 3 - 2% We get: 1000 * 0.74 = 740 (1000 - 740) * 0.24 = 62.4 (1000 - 740 - 62.4) * 0.02 = 3.95 Instead of: 1000 * 0.74 = 740 1000 * 0.24 = 240 1000 * 0.02 = 20 task_id: 3940370 Forward-Port-Of: odoo/enterprise#66366 Forward-Port-Of: odoo/enterprise#62884

The current code is taking the residual amount instead of the statement line amount. When doing a reco model 'percentage_st_line' on 1000: Line 1 - 74%
Line 2 - 24%
Line 3 - 2%

We get:
1000 * 0.74 = 740
(1000 - 740) * 0.24 = 62.4
(1000 - 740 - 62.4) * 0.02 = 3.95

Instead of:
1000 * 0.74 = 740
1000 * 0.24 = 240
1000 * 0.02 = 20

task_id: 3940370

Forward-Port-Of: odoo/enterprise#66366
Forward-Port-Of: odoo/enterprise#62884

Introduces e-invoicing and stock reporting via the new eTIMS service. Community PR: https://github.com/odoo/odoo/pull/162196 taskid: 3603762 Forward-Port-Of: odoo/enterprise#66428 Forward-Port-Of: odoo/enterprise#61967

Introduces e-invoicing and stock reporting via the new eTIMS service.

Community PR: https://github.com/odoo/odoo/pull/162196
taskid: 3603762

Forward-Port-Of: odoo/enterprise#66428
Forward-Port-Of: odoo/enterprise#61967

…dated on template change" This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon. This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c. Task-3996935 Forward-Port-Of: odoo/enterprise#66727

…dated on template change"

This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon.

This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c.

Task-3996935

Forward-Port-Of: odoo/enterprise#66727

…d warning Steps to reproduce: - Go to Accounting/Reporting/Tax Report; - Make sure there is a negative amount in the tax report; - Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report"; - Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s); Issue: On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals Sol

…d warning

Steps to reproduce:
- Go to Accounting/Reporting/Tax Report;
- Make sure there is a negative amount in the tax report;
- Click on PDF/EDI VAT/Test Interchange (available in debug) not to send the tax report to the government for real, and "Send VAT Report";
- Go to Reporting/EDI exports > it should have the "Rejected" status because of the negative amount(s);

Issue:
On the Accounting Dashboard: the error "Export(s) de taxes rejeté(s)" is appearing on several journals

Solution:
We get the journal defined for the Tax Return Periodicity. If no journal defined;
We keep only the first Misc journal that is found

This way, we let the user have custom misc journals (fec import or custom coa)

opw-4004375

Forward-Port-Of: odoo/enterprise#66437
Forward-Port-Of: odoo/enterprise#66346

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report. opw-4037481 Forward-Port-Of: odoo/enterprise#66666 Forward-Port-Of: odoo/enterprise#66343

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report.

opw-4037481

Forward-Port-Of: odoo/enterprise#66666
Forward-Port-Of: odoo/enterprise#66343

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail. runbot-71136 Forward-Port-Of: odoo/enterprise#66739

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail.

runbot-71136

Forward-Port-Of: odoo/enterprise#66739

Steps to reproduce: 1. Open document. 2. Select a doc. > Preview the doc. 3. Replace it with another file. 4. Preview the replaced doc , Now restore the doc from the bottom of the inspector. The preview is not opened and updated with the restore file. After this Commit: The preview must be closed and updated as per the restored file. Forward-Port-Of: odoo/enterprise#66657 Forward-Port-Of: odoo/enterprise#65801

Steps to reproduce:
1. Open document.
2. Select a doc. > Preview the doc.
3. Replace it with another file.
4. Preview the replaced doc , Now restore the doc from the bottom of the inspector.

The preview is not opened and updated with the restore file.

After this Commit:
The preview must be closed and updated as per the restored file.

Forward-Port-Of: odoo/enterprise#66657
Forward-Port-Of: odoo/enterprise#65801

Currently, an error occurs when the payment status is failed, expired, or failed. Steps to produce an error: - Install `sale_subscription` and `payment_mollie` - setup `mollie` payment provider in testing - Create an invoice for the subscription and confirm it - Click preview of the invoice and click Pay Now. - fill card details, and on the on the next page, select failed or expired in payment status - Confirm error:  `PaymentTransaction._set_canceled() takes 1 positional argument b

Currently, an error occurs when the payment status is failed, expired, or failed.

Steps to produce an error:
- Install `sale_subscription` and `payment_mollie`
- setup `mollie` payment provider in testing
- Create an invoice for the subscription and confirm it
- Click preview of the invoice and click Pay Now.
- fill card details, and on the on the next page, select failed or expired in payment status
- Confirm

error: 
`PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given`

This is because at code [1], we have passed `**kwargs` as arguments in super call, and as a result, it sets all arguments of kwargs in agruments, e.g., 2 of super call, but method call requires one positional argument.

This commit will fix the above issue by passing a positional argument with kwargs in the super call.

[1]-https://github.com/odoo/enterprise/blob/43621084d0cf95970eb6e45cf67bcb20ec14b8b3/sale_subscription/models/payment_transaction.py#L186

sentry-5606090812

Forward-Port-Of: odoo/enterprise#66664