To reproduce the issue:

1) Initialize a company in Belgium, create the tax returns 2) Submit the VAT return from January
3) Open the lock date wizard. The tax lock date is January 31st. 4) Add a lock date exception removing the tax lock date just for you, for 5 min. 5) Reset January's return
6) Reopen the lock date wizard.
    ====> Your exception is still there, but the tax lock date for everyone has been reset to December 31st.

This is plain wrong. Resetting a return should not automatically reopen the period for everyone. Lock dates exceptions/modifications are anyway required to reset the return ; they should pilot the whole flow. Nothing being magically hidden from the user means there can't be someone else mistakenly encoding something into the reopened period.

Another fix was required to make this one work: setting the tax lock date before submitting the return should work. In bigger environments, users might want to do that as a first step to reduce the number of people encoding data before actually doing the submission of the return. Therefore, the case where the tax lock date is already set at the date_to of the return when submitting it was supposed to be already supported, and allow the creation of the closing entry for that return, despite it being on the tax lock date. The test ensuring this was however badly written, and the feature didn't work: the closing was created at a later date than the lock date automatically, due to the Bills' Algorithm.

Forward-Port-Of: odoo/enterprise#124872
Forward-Port-Of: odoo/enterprise#124811

Steps to reproduce
---
1. Enable Packages and turn on "Move Entire Packages" on the delivery operation type.
2. Create a storable product P and add 2 units in different package in stock: 1 in PACK001, 1 in PACK002 
3. In the Barcode app > Operations > Delivery > New
4. Scan a first package PACK001, then a second different package PACK002
5. Scan the first package PACK001 again.

Issue
---
Re-scanning an already scanned package is meant to be rejected with a "This package is already scanned." warning, but the rejection stops working as soon as a second package is present in the transfer, so the package content gets added a second time and, once validated, the source quant goes negative (the package ends up holding a negative and a positive quant of the same product).

Commit 23613c63947 added a canPackSomeLines flag that is set to true for every package line that is not the scanned one, so any other package in the transfer makes the alreadyDonePackId && !canPackSomeLines guard false and silently skips the warning. The scanned package already exposes whether it had something left to pack through scannedPackages, so gating the warning on that flag instead keeps the check working regardless of how many other packages are in the transfer.

https://github.com/odoo/enterprise/blob/3cc1a162e61662814b0e52c0c720831952d208a8/stock_barcode/static/src/models/barcode_picking_model.js#L1976-L2006

opw-6279105

Forward-Port-Of: odoo/enterprise#121755

To reproduce the issue:

1) Create a company in Belgium
2) Instantiate its returns and review, submit and pay one of the VAT returns 3) Change the states_worklfow of the VAT return so that it only accepts "review" and "submit" stages, not "paid" anymore 4) Go to the list of returns, remove the TODO filter => traceback

The problem is here that the existing returns don't recompute their state when the workflow of the type is modified. In some cases, this is fine, but it others, it's annoying. In our example, the terminal state changed, so all the returns in that terminal stage should change their state to the new terminal one. "paid" is not an accepted value anymore, it should become "submitted".

Moreover, when the workflow is changed, the selection field actually containing the state must also change. As it is, it seems to work because "state" of account.return is stored, but the value it's based on (the workflow field) won't be consistent with it. It's not annoying now, but those inconsistencies could become a big source of trouble in the future (we know that from experience ... I'm looking at you, version 8 ! è-é).

This issue typically happens at upgrade. We had cases in FR and AE already. We solve that by a generic override of the write to sort things out when such change needs to happen. An upgrade PR will also be done to adapt the script so that we eventually solve the inconsistencies on dbs that have already migrated to 19.0.

Forward-Port-Of: odoo/enterprise#124144