While upgrade of a customer database, A P-type image
was being converted to JPEG image. It didn't allow to save
as direct conversion from P-type(palette) to JPEG. So, fix
covers conversion of such corner cases to first convert it
to RGB and then RGB can convert it to desired output format
opw-3043418

closes odoo/odoo#105549

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
  exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".

Related to opw-3056683

closes odoo/odoo#106794

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce:
- Setup product (
    cost 10$
    Storeable Product
    Standard Price Accounting
    automated valuation
    add account for price difference
)

- Purchase product in foreign currency (set a different price)
- Receive the product
- Create and validate Bill

Bug:
The reception JE is for the cost amount set on the product ($10)
debit and credit value are correct but the amount in currency
is wrong (purchase cost)

After creating the bill the Journal items are not correctly matched
since reconciliation is done on currency amount in the case fo foreign
currency transaction

Fix:
Set the correct amount (cost configured on product page)
in currency amount if costing method is standard

opw-2822366

closes odoo/odoo#101809

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Previously, it was only possible to upload a bill, so the partner_id was read
from the vendor in the imported file. Now, it is also possible to upload a
file to create an invoice, so we need to be able to decode the customer in
the imported file.

opw-3072989

closes odoo/odoo#106765

Signed-off-by: Laurent Smet <las@odoo.com>

This commit description is in three parts: a generic explanation, a real
use case and the solutions

**Explanations**
1. When getting an odoo `Environment`, we first generate a tuple used as
an environment identifier:
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L446
   Then, there are two possibilities:
   1. If such environment already exists in the environments list of the
transaction, we reuse it:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L448-L452
   2. Else, we create a new one and store it in the transaction:
      https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L454-L464
2. The `company` attribute of an `Environment` object is a lazy property
   https://github.com/odoo/odoo/blob/7475bcbef601b69e11c88a2ebb5fa39d7fcb52ab/odoo/api.py#L537-L538
   It means that its value won't be recomputed unless we delete it
   https://github.com/odoo/odoo/blob/083c70bbb63f27839b2c9a4b549e216947bc4dd1/odoo/tools/func.py#L12-L17
3. When running a `SavepointCase` test class, the `setUp` method ensures
that, after each test, we do cleaning:
   https://github.com/odoo/odoo/blob/a50a65be19b682201fc010d33c1b1f0b90cdf4d3/odoo/tests/common.py#L652-L662
   The functions are added in a stack. So, in the execution order, we
will
   1. Clear the current environment and the registry
   2. Reset the environments list with the ones that were existing
before the executed test
4. Suppose a test class TC that inherits `SavepointCase`. TC has a
special `setUpClass`:
   1. We create a new user U and replace the environment with a new one,
E1, based on U. This user has a company Comp_U. Because of [1], the new
environment E1 is added to the environments list of the transaction.
   2. For some reasons, we need to do some operations in `sudo` mode:
again, because of [1], a new environment E2 (same as E1 but with the
`su` flag to `True`) is created and added to the environments list of
the transaction
5. TC contains a first test T1. In that test, we create a company
Comp_tmp and set it as default one to U. Therefore, E1 and E2 are
updated (their `company` attribute is now Comp_tmp)
6. At the end of T1, because of [3]:
   1. E1 is reset (but its lazy properties are not deleted)
   2. The environments list of the transaction is reset and still
contains E1 and E2 as they have been created in the class setup (i.e.
before the test setup)
7. In a second test T2, there will be an inconsistency: both E1 and E2
have an incorrect value for their field `company`: Comp_tmp, which is
not the value defined on `self.env.user.company_id` (the value Comp_tmp
does not even exist anymore)

**Real use case**
- The class `AccountTestInvoicingCommon` is an inheritance of
`SavepointCase`. In its class setup, we create a user and set it on the
current environment. Later on, we create a company (the sudo mode will
be activated during the company creation process)
  https://github.com/odoo/odoo/blob/1e69c4fe5f8dd8a92d92f350b6d6a9539157f206/addons/account/tests/common.py#L38-L52
- The class `TestPurchaseOrder` inherits `AccountTestInvoicingCommon`
- The test `:TestPurchaseOrder.test_06_on_time_rate` creates a company
and sets it as the one of the current user
  https://github.com/odoo/odoo/blob/87ffe5983be7f0f4a926b458c4bd1f13001048ec/addons/purchase_stock/tests/test_purchase_order.py#L313-L316


- Therefore, all next tests will have an issue with the environment
(unless we force the writing of the company on the current user to
bypass the issue)
```py
self.assertEqual(self.env.user.company_id, self.env.company) # will fail
self.assertTrue(self.env.company.exists()) # will fail
```

**Solution**
The above issue has been fixed from Odoo 15 on, thanks to commit C1.
Thanks to that diff, at step [3.1] in the above explanations, the lazy
properties of E1 are deleted (so, because of [2], the `company`
attribute of E1 will be correct again). However, once C1 is applied, we
can still add some lines in T2 to fail the test:
```py
sudo_env = self.env.user.sudo().env
self.assertEqual(self.env.user.company_id, sudo_env.company) # will fail
self.assertTrue(sudo_env.company.exists()) # will fail
```
The reason: at the end of the test T1, we reset the environments list of
the transaction ([6.2]). However, E2 has been created before the test
setup (it was in the class setup, see [4.2]). So, after the list reset,
E2 is still in that list and still has the value Comp_tmp for its
`company` attribute.

So... first we can conclude that C1 is not enough. Second, once the
environments list of the transaction is reset ([3.2]), we also have to
reset each environment to ensure that their lazy properties are correct.
We can then remove [3.1] since it will be included in that new step.

C1 a40511cd

closes odoo/odoo#106252

Signed-off-by: Raphael Collet <rco@odoo.com>

*: website_sale_wishlist

Commit [1] and [2] introduced test tours but did not mark them as test
tours properly, thus showing them to users (who are in debug=tests mode)
by mistake.

[1]: https://github.com/odoo/odoo/commit/7655bface7f9e9bae8579e14e9a87b4f4801cc33
[2]: https://github.com/odoo/odoo/commit/a0c33c5f896718d1c03a6a50c981d6d75ce0d169



closes odoo/odoo#106667

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

In large database with lot of user, the browser don't respond.

closes odoo/odoo#100106

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to reproduce:

- Open an invoice
- Enter a long link without spaces in the terms and conditions field
- Save

Issue:
The word doesn't break and spans outside its bounding box, possibly
overlapping with the subtotal footer on the right.

Solution:
Add class `text-break` to the narration field.

opw-3050054

closes odoo/odoo#106359

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

In this commit [1] (merged in 16.0) a bugfix has been made in the
`removeSlide` function but this one should have been applied on all
supported versions because the bug it fixes is present on all versions.
The bug it fixes is the following:
- Drop a carousel block on a page
- Remove the *first* slide

=> There is no active indicator.

Moreover, the bugfix made in 16.0 [1] introduces another error: when a
slide is removed from the carousel the indicators are not in a correct
state anymore.

Following the same steps with the changes of [1]:
- Drop a carousel block on a page
- Remove a slide

=> Indicators are no longer consistent with the slides so tracebacks
appear during the carousel slides. The list of indicators must have on
each element a `data-slide-to` attribute which must reflect the
position of the slide (starting with 0).

So this commit is to backport the fix from 16.0 [1] to 14.0 and to fix
the new bug that [1] introduces.

[1]: https://github.com/odoo/odoo/commit/f7055d3dbabfbe471f490bd65c2032f5251f3f37



task-3040931
opw-3051615

closes odoo/odoo#103963

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit:
1. Create PO with quantity 10, confirm (creates receipt-1)
2. Receive 2 quantities on first receipt (receipt-1), backorder (receipt-1 is 'done', creates receipt-2)
3. Receive 3 quantities on second receipt (receipt-2), backorder (receipt-2 is 'done', creates receipt-3)
4. Change quantity to 5 in PO
5. An exception is created on all receipts (1, 2 and 3)

In the scenario above, receipt-1 and receipt-2 are partial receipts that are set to 'done'.
It is not necessary to create an exception in these receipts when the quantity is changed to less than originally expected in the PO.
Since the system checks that the new quantity has to be equal or greater than the received quantities, the already received quantities cannot be impacted.

After this commit:
The exception is only propagated to the receipts that are not done.
e.g. in the example above, an exception appears only in receipt-3.

task-2648209

resolves #76297

closes odoo/odoo#76691

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this PR Odoo don't pre-search on location.

closes odoo/odoo#97014

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When creating draft deferred entries in a reconcilable account,
we should not attempt to reconcile them, because only posted entries
can be reconciled.

closes odoo/odoo#106524

Signed-off-by: William André (wan) <wan@odoo.com>

Current behavior:
When splitting the order in a pos_restaurant session, the order was not
correctly saved in the backend. It resulted in an order that still had
all the product of the original order and another order with the
correctly splitted products.

Steps to reproduce:
- Start a pos_restaurant session.
- Go to table A and add 3 products to the table.
- Go back to the floor screen
- Go back to the table A
- Split the order in 2
- Click on payment, and go back to the product screen without paying
- Click on the ticket button, and click on the order that was splitted,
  it still contains all the products from the original order.

opw-3061569

closes odoo/odoo#106358

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

PG12 introduced an optimization for CTEs that automatically inlines
CTEs if they are only refered once in the parent query. Prior to that
CTEs were always materialzed, meaning that PG created a sort of temp
table on the fly to store the result of the CTE's evaluation.

Whereas this leads to performance improvements in general, in the
particular case of _select_companies_rates this inlining becomes a
performance bottleneck. This is because while the currency_rate CTE
is only refered once in both purchase_report and product_margin,
the join condition (cr.date_end is null or cr.date_end > ...)
requires evaluating the CTE's date_end subquery twice. This, combined
with the fact that in PG12 the planner goes for a Nested Loop JOIN instead
of a HASH Join in PG10 makes the performances of the whole query
much worse in PG12 than in PG10.

Adding an ORDER BY (or an OFFSET 0, the resulting plan is the same)
creates a kind of optimization fence that forces PG to evaluate the
subquery first using its own plan. This removes the need to rescan the
subquery each time the Merge JOIN filter has to be applied, which
is a good strategy in this specific situation.

The same result could be achieved by adding the keyword "MATERIALIZED"
in the CTE definition. The issue is that this keyword did not exist
in PG 10 so using it would require to check the PG version at runtime
from python.

Examples of query timings change before and after PR:

Number of POs | Before PR | After PR
      2000    |     7s    |    345ms
      7000    |     23s   |    1.1s

opw-2930578

closes odoo/odoo#106078

X-original-commit: 8b7a3941
Signed-off-by: Raphael Collet <rco@odoo.com>

If a MO has some operations and if there are some reserved quantities
from sub-locations, when creating a backorder, the consuming lines in
the backorder will not use theses sub-locations.

To reproduce the issue:
1. In Settings, enable "Multi-Locations"
2. Create two storable products P_compo, P_finished
3. Update the on-hand quantity of P_compo:
    - 2 x P_compo at WH/Stock/Shelf 1
4. Create a bill of materials BM:
    - Product: P_finished
    - Compo: 1 x P_compo
    - Operations: add a new one
5. Create and confirm a MO:
    - Bill of materials: BM
    - Qty: 2
6. Check the availability
    - It reserves two P_compo from WH/Stock/Shelf 1
7. Set the producing qty to 1
8. Validate & Backorder
    - The producing qty of the backorder is already set to 1
9. Open the detailed operations related to P_compo

Error: There is a reservation line for 1 x P_compo from WH/Stock/Shelf
1, which is correct, but its done quantity is 0 instead of 1. Moreover,
there is another line from WH/Stock with the done quantity set to 1.
This line should not exist.

When creating the backorder, because there is at least one WO, we set
the remaining producing qty on the WO of the backorder:
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L1501-L1506
When writing on such a field, an inverse method is triggered:
https://github.com/odoo/odoo/blob/402dfd0a53af74e64278ff8746326c024128a2ee/addons/mrp/models/mrp_workorder.py#L221-L225
This method will update the producing quantity of the backorder and
generate the SML that consume the components
https://github.com/odoo/odoo/blob/ac11b7e00dea13a0d20bf0c39e544d12c0a1e9fe/addons/mrp/models/mrp_production.py#L993-L998


However, we write the producing quantity of the WO before the quantity
reservation on the backorder. Therefore, when generating the consuming
SML, because there isn't any reserved quantity, we consume the
components from the default location (this is the reason why there is a
SML with a done qty from WH/Stock). Later on, we will unassign the
initial MO and reserve the backorder (and here is the reason why there
is a second SML from WH/Stock/Shelf 1)

The solution is an adapted backport of [1]

[1] 1180b6f7

OPW-3020189

closes odoo/odoo#106147

Related: odoo/enterprise#34179
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

update to this PR[1]

BUG:
some discounts are still displayed on the middle of the order

FIX:
move all discounts to the end

[1]:https://github.com/odoo/odoo/pull/102700


opw-2985632

closes odoo/odoo#106322

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

closes odoo/odoo#105518

Signed-off-by: Olivier Dony (odo) <odo@odoo.com>

closes odoo/odoo#106424

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

In Factur-X, there is no way to represent a tax "price_include" because
every amounts should be tax excluded.

Currently in Factur-X, a line with a tax price_include = True will be
incorrectly exported. Indeed, the Factur-X.xml is generated by setting the
GrossPriceProduct as the price_unit. In Factur-X, this amount (and the others
in the line details) should be tax excluded. Thus, it's wrong to set the
GrossPriceProduct as the price_unit.

To fix this, the GrossPriceProduct should be the price_unit if no tax
price_include = True is set, otherwise, the gross price = price_unit/(1+tax/100).

This way, the Factur-X file will be consistent with the norm.

Note that the import of a Factur-X xml will thus try to pick taxes with price_include = False,
and the price_unit will be tax excluded. If no matching tax with price_include = False is
retrieved, a tax with price_include = True is searched, if found, the price_unit is
recomputed accordingly. In both cases, the lines subtotals are the same.

opw-3032382

closes odoo/odoo#105276

Signed-off-by: William André (wan) <wan@odoo.com>

Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:

(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)

- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button

=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.

opw-2967706

closes odoo/odoo#105334

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit:
 If we remove a payment line using an Adyen payment method,
 `pending_adyen_line()` return `undefined`.
 With the `_poll_for_response` still being executed,
 it will pop some JS traceback each call with:
 ```js
 TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
 ```

After this commit:
 No JS traceback loop

OPW-3032391

closes odoo/odoo#105716

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Commit 7fbb337e introduced performance slowdown when reconciling a
bank statement line with multiple invoices. This is due to the
compute function being called a lot of times and each time need to
trigger a search for CABA moves (even if the company do not use
cash basis).

This commit aims to not trigger the search if the company do not use
cash basis and add some domain conditions on indexed fields to speed up
the search when it's a cash basis company.

opw-3013391

closes odoo/odoo#105925

Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: Arnaud-Sibille <arsi@odoo.com>

If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.

Do not call this method if no module need to be installed.

closes odoo/odoo#106310

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit: if one product in one of the previous orders is
archived, it won't load the order properly for order management.

opw-3035231

closes odoo/odoo#105952

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

On large database this can take 700 ms per moves. After a few ms.

closes odoo/odoo#97000

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@openerp.com>

On the ticket https://github.com/odoo/odoo/pull/101547

 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.

closes odoo/odoo#106313

X-original-commit: e8bb4a50
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104779

Signed-off-by: Josse Colpaert <jco@odoo.com>

The dimensions UoM of the carrier packaging is useless: it is not the
one used in the requests and there is not any conversion

To reproduce the issue
(Need delivery_fedex. Use demo data. Enable debug mode)
1. In Shipping Methods, edit 'Fedex US':
    - Package Weight Unit: KG
    - Debug Requests: True
2. Edit its Fedex Package Type:
    - Height: 1m
    - Width: 1m
    - Length: 1m
    - Package Code: YOUR_PACKAGING
3. Create a SO with a US partner and one product
4. On the SO
    - Add Shipping
    - Select 'Fedex US'
    - Click on 'Get Rate'
5. In Logging, open the request sent

Error: the dimensions of the packaging are expressed with "CM" but they
are not converted:
```xml
<ns0:Dimensions>
	<ns0:Length>1</ns0:Length>
	<ns0:Width>1</ns0:Width>
	<ns0:Height>1</ns0:Height>
	<ns0:Units>CM</ns0:Units>
</ns0:Dimensions>
```

When encoding the packaging in the request, the UoM defined on the
packaging (meter) is ignored. Instead, we define a length UoM depending
on the UoM of the weight and we don't convert any dimension:
https://github.com/odoo/enterprise/blob/e4fd13a0e073b9855864b7fabc26bc05b9a5fd19/delivery_fedex/models/fedex_request.py#L172-L178
There is even a `TODO` about the issue.

It will be the same with the other carriers. For instance, with UPS:
https://github.com/odoo/enterprise/blob/c9899f7860cd19c86f215d6dcea89f73b51433f3/delivery_ups/models/ups_request.py#L98-L102


We use the UoM of `ups_package_dimension_unit` and do not convert the
dimensions.

We can't implement the dimensions conversion on stable versions, since
it will break all existing packagings. So, as temporary solution, we can
simply hide the useless UoM defined on the packagings.

OPW-3053048

closes odoo/odoo#105308

Related: odoo/enterprise#33754
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

closes odoo/odoo#106246

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).

Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
   wouldn't have to do that if it was in the regular testing base as it
   could not be broken. This is a waste of time for no reason, as we
   need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
   because the test need to be adapted to a theme change or something,
   but one day someone will be able to break the website core mechanisms
   (COW, theme install etc) and this will be problematic.
   Note that if this was to happen, the runbot team will be handling the
   issue and the fix with the people that broke it, as it was promised
   when we discussed about moving those tests in the regular testing
   suite. It was the conscensus for us to accept to leave those tests in
   the nightly only (we didn't really had a choice tho).

[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c



closes odoo/odoo#106026

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Setup multicurrency, with:
* rateA for dateA
* rateB for dateB (dateB > dateA)

Have an invoice in dateA with foreign currency and duplicate it.
Checking the journal entries, you should see that Debit/Credit is the
same as the source invoice. Posting the invoice would assign today date,
keeping the wrong rate.

opw-3007740

Backport of 0ac6bb4662b537ed10eaab89a6484476c421342f

closes odoo/odoo#106146

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909

Fixes 2687380
Fixes 2856101

closes odoo/odoo#103292

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Issue :
- Liechtenstein adapted the same QR-Invoice as Switzerland.
However, Odoo only allows the issuance of QR-Invoices to
swiss customers

https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills

.

Fix:
- Allow LI users to be issued QR-Invoices

OPW-2977644

closes odoo/odoo#100470

Related: odoo/enterprise#34168
Signed-off-by: Josse Colpaert <jco@odoo.com>

- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...

closes odoo/odoo#95291

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

closes odoo/odoo#105740

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

The existing code was generating misleading errors for imported Odoo
modules that could not be loaded.  Although there was a specific hack
for module 'studio_customization', imported modules were not handled
properly.  This patch adds the right condition in the SQL query in the
module that introduces imported modules.

closes odoo/odoo#105955

Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce:
    - install a localization which uses the account_edi module;
    - define Lock date for the fiscal period;
    - choose an invoice which was sent before this date;
    - click on the "REQUEST EDI CANCELLATION" button.

Issue:
    We try to cancel the EDI document despite exceeding the fiscal period.

Cause:
	The verification of the fiscal period is done when clicking on the "RESET TO DRAFT" button which, in the flow, is after the request for cancellation of the EDI document.

Solution:
    Make a verification of the fiscal period when clicking on the "REQUEST EDI CANCELLATION" button.

opw-2990873

closes odoo/odoo#106014

Signed-off-by: Josse Colpaert <jco@odoo.com>

Computing account.move.payment_state relies on this field. When
perfoming payment operations in bulk (like during an upgrade) the field
computation may become too slow.

On recent upgrade cases the abscense of this index caused delays ranging
from 5 hours to whole days in the upgrade of big DBs.

closes odoo/odoo#105794

Signed-off-by: Christophe Simonis <chs@odoo.com>