The accrual plan is not working for the last level, it seems like the last level computation is always using the previous level instead. If those levels have a different number of days granted, this will be wrong. Else, if they grant the same amount of days, the error won't be noticed. Steps to reproduce: - Create an accrual plan with: - Accrued Gain Time -> At the start of the accrual period - Carry-Over Time -> At the start of the year - Add 4 rules to the plan: - For all: don't

The accrual plan is not working for the last level, it seems like the last level computation is always using the previous level instead. If those levels have a different number of days granted, this will be wrong. Else, if they grant the same amount of days, the error won't be noticed.

Steps to reproduce:
- Create an accrual plan with:
  - Accrued Gain Time -> At the start of the accrual period
  - Carry-Over Time -> At the start of the year
- Add 4 rules to the plan:
  - For all: don't set a cap, set carry-over to all, set the frequency to yearly
  - For the first, grant 1 day immediately (milestone reached 0 days after allocation start
  - For the second, grant 5 days after 1 year
  - Third, 20 days after 2 years
  - Fourth, 100 days after 3 years
- Go to Management > Allocations, and create a new allocation for someone, like Mitchell Admin, with:
  - Time off Type set to "Parental Leaves" (so you should not have any by default for testing)
  - Allocation type set to "Accrual"
  - Select the accrual plan we just created
  - Set start date at the first of january for the current year
- This should grant you immediately your first Parental Leave
- Go to the dashboard and see the 1 parental leave
- Change the date to see how many Parental Leaves you will have at other dates (years). It will always be wrong, see explanation below.

If you set 1 year after (eg 2025-01-01), you will have 2 Parental leaves instead of 6 because it does 1 + 1 instead of 1 + 5. If you set 2 year after (eg 2026-01-01), you will have 11 leaves instead of 26, because it does 1 + 5 + 5 instead of 1 + 5 + 20 For year 3, you will have 46 instead of 126, because it does 1 + 5 + 20 + 20 instead of 1 + 5 + 20 + 100.

Notice the last added number, it will also be a duplicate of the one before because it considered the wrong accrual level for the last level.

Commit [1] in Odoo 18 did fix it, on top of other bugs. This commit is thus part of a cherry-pick, on top of which a test is added to cover this specific flow.
Also, note that [1] was actually itself a forward port with different code than its version in Odoo 17.0, see [2]. That commit fixed other issues but not this one.

[1]: https://github.com/odoo/odoo/commit/1897ff0d224416fc2df19b8f9783a94709704457
[2]: https://github.com/odoo/odoo/commit/8b339fdde161e81e1a00cecd3b1fd280de51fd08

Forward-Port-Of: odoo/odoo#194559

To reproduce: - Install delivery_fedex (for example) and sale_management. - Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example). - New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO. Current behaviour: Estimated cost on SO line description is not rounded according to the currency conventions. Expected behaviour: Estimated cost on SO line description is rounded, according to the curre

To reproduce:
- Install delivery_fedex (for example) and sale_management.
- Open Fedex US shipping method and set invoicing to real cost, margin on rate to 93.47 (for example).
- New SO to Azure Interior, 1x product 5555, Add shipping Fedex US and get the rate before adding to the SO.

Current behaviour:
Estimated cost on SO line description is not rounded according to the currency conventions.

Expected behaviour:
Estimated cost on SO line description is rounded, according to the currency conventions.

opw-4543605

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

Forward-Port-Of: odoo/odoo#201572
Forward-Port-Of: odoo/odoo#201510

Crash with traceback when openning Time Off in Serbian (latin) Steps to reproduce: ------------------- *Change user language to Serbian (Latin) *Open Time Off app > Observation: Traceback Why the fix: ------------ Intl.NumberFormat only accept dash-case format. @ in sr@latin is not supported. opw-4583287 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 re

Crash with traceback when openning Time Off in Serbian (latin)

Steps to reproduce:
-------------------
*Change user language to Serbian (Latin)
*Open Time Off app
> Observation:
Traceback

Why the fix:
------------
Intl.NumberFormat only accept dash-case format. @ in sr@latin is not supported.

opw-4583287

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#200320

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Description of the issue/feature t

In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount.

To improve clarity:
- Negative values are now displayed instead of being forced to 0.
- The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed.

Task-4589150

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#198606

- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510

- Fetch photo from `hr.employee.public` to be avail for users without no hr rights

Task: 4626795



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

Forward-Port-Of: odoo/odoo#200510

As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law. source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/ opw-4531928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201214

As per the XRechnung invoice standard, the Buyer Reference (BT-10) is now a mandatory field to comply with German law.

source: https://en.e-rechnung-bund.de/e-invoicing-faq/xrechnung/

opw-4531928


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

Forward-Port-Of: odoo/odoo#201214

…ields Commercial fields are supposed to be synchronized between a customer and their commercial entity. Nevertheless, the synchronization doesn't work for company_dependent fields whose values are only copied for the current company. This commit makes sure the values are properly synchronized for company_dependent fields (+ pricelist) between the contacts and their commercial partner. opw-4523466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submi

…ields

Commercial fields are supposed to be synchronized between a customer and their commercial entity. Nevertheless, the synchronization doesn't work for company_dependent fields whose values are only copied for the current company.

This commit makes sure the values are properly synchronized for company_dependent fields (+ pricelist) between the contacts and their commercial partner.

opw-4523466


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

Forward-Port-Of: odoo/odoo#201251

…CIG or CUP is present **Issue:** When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete. **Steps to Reproduce:** 1. Install the Accounting app 2. Install the l10n_it_edi module 3. Navigate to Accounting > Customers > Invoices 4. Select or create an invoice 5. Choose a customer with a PA index 6. Open the Electronic Inv

…CIG or CUP is present

**Issue:**
When only one of the CIG or CUP fields is filled in the Electronic Invoicing tab, without specifying an Origin Document, the system still allows sending the e-invoice to the tax agency, even though the data is incomplete.

**Steps to Reproduce:**
1. Install the Accounting app
2. Install the l10n_it_edi module
3. Navigate to Accounting > Customers > Invoices
4. Select or create an invoice
5. Choose a customer with a PA index
6. Open the Electronic Invoicing tab
7. Fill in either the CIG or CUP field, but leave the Origin Document Type empty
8. Click Send & Print
9. No error is displayed and the e-invoice XML can be sent

Expected Behavior: An error should be triggered, preventing the e-invoice from being sent if the Origin Document Type is missing, even when only one of CIG or CUP is present.

Actual Behavior: The system allows sending the e-invoice despite missing critical information, leading to incomplete data submission.

**Root Cause**

The existing validation only checks if both CIG and CUP are missing, but it does not account for cases where only one is filled while the Origin Document is still absent.

**Fix**
The condition has been updated to trigger an error whenever the Origin Document Type is missing, even if only one of CIG or CUP is present.

Opw-4590205

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

Forward-Port-Of: odoo/odoo#198758

Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195395

Allow to limit to max failures or errors in odoo test suite
when environment variable ODOO_TEST_MAX_FAILED_TESTS is set.
Above that limit, skip all following tests

ODOO_TEST_MAX_FAILED_TESTS must be a non zero int

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

Forward-Port-Of: odoo/odoo#195395

**Issue** Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation. **Cause** The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail. **Solution** Ensure the table is empty after uninstall. **Steps

**Issue**
Re-installing Project is not possible if the Project Share Wizard has been used shortly before the module uninstallation.

**Cause**
The `project_share_wizard_res_partner_rel` table for the `partner_ids` field of the `project.share.wizard` is not dropped at uninstall (this is a known ORM limitation) and if it contains rows, restoring the foreign keys constraint for the `project_share_wizard_id` column will fail.

**Solution**
Ensure the table is empty after uninstall.

**Steps to reproduce**
- Project Kanban View > 3 dots > Share
- Add a recipient and Send: this should add a row to the `project_share_wizard_res_partner_rel` table.
- Uninstall Project shortly after (before the row is deleted by the auto-vacuum).
- Try to re-install Project:
```
The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.

Model: Unknown (unknown)
Constraint: project_share_wizard_res_partner_r_project_share_wizard_id_fkey
```

opw-4593125

Forward-Port-Of: odoo/odoo#200984
Forward-Port-Of: odoo/odoo#200555

The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201614 Forward-Port-Of: odoo/odoo#201489

The export is completely wrong when
it comes to multiple taxes affecting
each others.

It would recompute the withholding
taxes one by one based on the price
subtotal instead of taking into account
all other taxes as you would expect.

task-4641930

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

Forward-Port-Of: odoo/odoo#201614
Forward-Port-Of: odoo/odoo#201489

I spotted three mistakes in the naming of the lines in the Modelo 303 and 390 reports. This PR fixes them and updates the .po, .pot files accordingly. Forward-Port-Of: odoo/odoo#200201

I spotted three mistakes in the naming of the lines in the Modelo 303 and 390 reports. This PR fixes them and updates the .po, .pot files accordingly.

Forward-Port-Of: odoo/odoo#200201

Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid. Also update the code that do the match of the document types related to docs types: * all cases that accepted A now also accept M documents * remove deprecated responsibility match * add match to new responsibility LATAM 1300 / Adhoc Task 47476 --- I confirm I have signed the CLA and read the PR

Some of them were deprecated by AFIP so we target them with that tag (we deactivate them) Also add new AFIP responsibilities and fix the code and active status of the one valid.
    
Also update the code that do the match of the document types related to docs types:

* all cases that accepted A now also accept M documents
* remove deprecated responsibility match
* add match to new responsibility    

LATAM 1300 / Adhoc Task 47476


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

Forward-Port-Of: odoo/odoo#200503
Forward-Port-Of: odoo/odoo#198247

Steps to reproduce: ------------------- - Install 'Project' module - Create a new project - Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default) - Open the Odoo instance in a new incognito browser (or erase cache) - Login and open the created tasks in kanban view Issue: ------ Kanban view is slow to load. Cause: ------ Retrie

Steps to reproduce:
-------------------

- Install 'Project' module
- Create a new project
- Create 20 tasks and set a large image as `Kanban Cover` for each task (for test purposes, create multiple stages and move the tasks inside them to ensure that all tasks are visible and loaded by default)
- Open the Odoo instance in a new incognito browser (or erase cache)
- Login and open the created tasks in kanban view

Issue:
------

Kanban view is slow to load.

Cause:
------

Retrieving the covers in their original quality/size.

Solution:
---------

Hardcode the image height and width in the call of the route so that the retrieved image is cropped/resized.

opw-4438965

Forward-Port-Of: odoo/odoo#199395

If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset. When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible. task-4643664 Forward-Port-Of: odoo/odoo#201586

If a chat window is closed with the escape key while the composer is focused, the focus out event is never triggered and the focus flag of the composer is never reset.

When this flag is kept, new messages received in this channel are automatically marked as read, even if the messages are not actually visible.

task-4643664

Forward-Port-Of: odoo/odoo#201586

Scenario: - create marketing email in 17.0 or above - use the Cover widget - change the cover image to get a base64 endoded image - send the mail Result: no image is sent Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue when parsing the CSS because of having inside a CSS value eg. url("data:image/webp;base64,..."), then when the CSS was modified, the background image would be broken (with a :undefined after the value). Fix: instead of replacing all the style to change t

Scenario:
- create marketing email in 17.0 or above
- use the Cover widget
- change the cover image to get a base64 endoded image
- send the mail

Result: no image is sent

Cause: commit 1605b81b12e0dee78905e6eb3526fdb7e4908050 could have issue
when parsing the CSS because of having inside a CSS value eg.
url("data:image/webp;base64,..."), then when the CSS was modified, the
background image would be broken (with a :undefined after the value).

Fix: instead of replacing all the style to change the border-style,
update it with regex.

opw-4613524

Forward-Port-Of: odoo/odoo#201394

Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on an empty recordset returns False. This PR fixes that by first searching on the categories before filtering using the domain --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201542

Currently the search on total_route_ids always returns `[('id', 'in', [])]` as filtered_domain on
an empty recordset returns False.

This PR fixes that by first searching on the categories before filtering using the domain

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

Forward-Port-Of: odoo/odoo#201542

Initial PR: https://github.com/odoo/odoo/pull/194141 It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`. For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways: - calling UNLISTEN * and committing - closing the connection - aborting the transaction

Initial PR: https://github.com/odoo/odoo/pull/194141

It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`.

For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways:
 - calling UNLISTEN * and committing
 - closing the connection
 - aborting the transaction (before committing the listen)

`UNLISTEN *` is a good candidate for this, but closing the connection seems to be the safer option.

Forward-Port-Of: odoo/odoo#201401

This commit gives the users access to the XML of an invoice whose submission to JoFotara failed. This allows for better debugging of failed invoices. It also prevents the users from deleting PDFs of successfully submitted invoices. task-4571479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199210

This commit gives the users access to the XML of an invoice whose submission to JoFotara failed.
This allows for better debugging of failed invoices.
It also prevents the users from deleting PDFs of successfully submitted invoices.

task-4571479



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

Forward-Port-Of: odoo/odoo#199210

When an employee with the "Team approver" role was using the digitization feature on an expense, a user error would be raised when clicking on the "Refresh" button. This is related to commit 92284e7 which added an access right check when writing on the `state` field of the expense. After this commit, only expense managers are allowed to write the state field (except for the "Submit" state). Since the OCR is resetting the expense state to draft it was raising this access right check. Writin

When an employee with the "Team approver" role was using the digitization feature on an expense, a user error would be raised when clicking on the "Refresh" button.

This is related to commit 92284e7 which added an access right check when writing on the `state` field of the expense. After this commit, only expense managers are allowed to write the state field (except for the "Submit" state).

Since the OCR is resetting the expense state to draft it was raising this access right check. Writing the state to "Draft" should also be allowed as it's obviously not bypassing the validation process.

[opw-4613260](https://www.odoo.com/odoo/49/tasks/4613260)

Forward-Port-Of: odoo/odoo#201786
Forward-Port-Of: odoo/odoo#201636

Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacu

Description of the issue/feature this PR addresses:
After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP.

Current behavior before PR:
Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long.
In particular, many asset files will be regenerated, and old assets immediately become garbage.

Desired behavior after PR is merged:
After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP.
Ideally, it shouldn't be run before old assets are discarded.  So maybe the cron should be triggered after some little delay.

task-3970360

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

Forward-Port-Of: odoo/odoo#197128

- if employee has no avatar his badge was broke in the kisok mode Task: 4629546 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200524

- if employee has no avatar his badge was broke in the kisok mode

Task: 4629546


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

Forward-Port-Of: odoo/odoo#200524

How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-446

How to reproduce the issue:

- Create an analytic distribution model.

- In the bank reconciliation, create a new transaction. In manual operations, remove the analytic.

If you reload the reconciliation, the analytic distribution is not deleted.

In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line.

opw-4460079

Forward-Port-Of: odoo/enterprise#78732

- Fix access rights (again) on employee view for wage statements - Fix condition on ACC rule that prevents manual edition of payslip lines Forward-Port-Of: odoo/enterprise#81317

- Fix access rights (again) on employee view for wage statements
- Fix condition on ACC rule that prevents manual edition of payslip lines

Forward-Port-Of: odoo/enterprise#81317

Steps fo reproduce : - create a product (in the inventory tab, the route should be 'Manufacture') - click on the smart button 'bill of materials' - create a BOM for this product with at least one operation - in the quality app navigate to Quality Control/Control Points - create a new control point - in the field product select the product that you created - in the operations field select "YourCompany: Manufacturing" - in the work order operation field select the operation that you wrote

Steps fo reproduce :
- create a product (in the inventory tab, the route should be 'Manufacture')
- click on the smart button 'bill of materials'
- create a BOM for this product with at least one operation
- in the quality app navigate to Quality Control/Control Points
- create a new control point
- in the field product select the product that you created
- in the operations field select "YourCompany: Manufacturing"
- in the work order operation field select the operation that you wrote in the BOM you created (if multiple operations with the same name make sure that you selected the one linked with the BOM)
- in the type field select "Measure"
- in the norm field enter a unit of measure with at least an upper case
- create a manufacturing order for this product
- open the shop floor app and on the manufacturing order you created select the quality check point

Current Behavior:
The unit of measure appears in lower case. This could change its meaning for instance form MW (mega-watt) to mw (mili-watt)

Expected Behavior:
The unit of measure string should respect the letter case wrote by the user

Cause of the issue:
In the xml file, inside the <span> tag the class was "text-lowercase"

Fix:
I removed this class from the span

https://github.com/odoo/enterprise/blob/43e7aec36ddee8a3ff3de8793427a183dfd29b30/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.xml#L47

opw-4584509

Forward-Port-Of: odoo/enterprise#81274

If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318

If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token.

https://firebase.google.com/docs/cloud-messaging/manage-tokens

Forward-Port-Of: odoo/enterprise#81318

LATAM Task 1300 - ADHOC Task 47476 Forward-Port-Of: odoo/enterprise#80844 Forward-Port-Of: odoo/enterprise#79635

LATAM Task 1300 - ADHOC Task 47476

Forward-Port-Of: odoo/enterprise#80844
Forward-Port-Of: odoo/enterprise#79635

Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test). This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user. Forward-Port-Of: odoo/enterprise#

Before this commit, if the `property_warehouse_id` field is set on the current user inside the test, the expected warehouse could not be found with the search made on the test (if more than one warehouse exists on the second company used in the test).

This commit makes sure the test expects the right warehouse by calling the `_get_default_warehouse_id` defined in `res.users` model to assert the stock move is done in the default warehouse of the current user.

Forward-Port-Of: odoo/enterprise#81309

### Issue: You can not print label for an mo is the qty_producing is at 0. ### Steps to reproduce: - Create a storable product FP tracked by LOT. - Create a bom for that product with 1 operation containing an instruction of type: "print label" - Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0). - Process the operation in the shopfloor and print label #### > The printed label is empty. ### Cause of the issue:

### Issue:

You can not print label for an mo is the qty_producing is at 0.

### Steps to reproduce:

- Create a storable product FP tracked by LOT.
- Create a bom for that product with 1 operation containing an instruction of type: "print label"
- Create and confirm an MO for 10 units and set a lot by hand (but ensure that the qty_producing of the MO is still at 0).
- Process the operation in the shopfloor and print label
#### > The printed label is empty.

### Cause of the issue:

The qty of label printed depends solely on the qty_producing of the workorder but in case this one is not set we should rather rely on the qty to be produced.
https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L344-L351 https://github.com/odoo/enterprise/blob/2a91cb194d070879b5e1e5f5fa03178aa2dcc7ec/mrp_workorder/models/quality.py#L327-L332

opw-4583573

Forward-Port-Of: odoo/enterprise#80802

Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company Task: 4625747 Forward-Port-Of: odoo/enterprise#80740

Issue: When an offer is generated for an employee from Company A, the Contract Type field is incorrectly fetching a value from Company B. This causes an access error

Solve: drop the default value from be localization to let the user choose the correct value from the available values for the company

Task: 4625747

Forward-Port-Of: odoo/enterprise#80740

**Steps to reproduce:** 1.Go to Documents > Configuration > Settings: -Enable Accounting (Centralize accounting files and documents) -Open Journals and synchronize a chosen journal with a workspace 2.Create a new activity type with: `action`: `Upload Document` `folder_id`: The same workspace we set in the settings 3.Create a journal entry in the journal you chose 4.Add the new activity to the journal entry. 5.Upload a document. **Issue:** The attachment is up

**Steps to reproduce:**

1.Go to Documents > Configuration > Settings:
  -Enable Accounting (Centralize accounting files and documents)
  -Open Journals and synchronize a chosen journal with a workspace 
2.Create a new activity type with:
        `action`: `Upload Document`
        `folder_id`: The same workspace we set in the settings 
3.Create a journal entry in the journal you chose
4.Add the new activity to the journal entry.
5.Upload a document.

**Issue:**
The attachment is uploaded, but we get a Missing Record error for an `ir.attachment` record, and the activity isn't set to done

**Cause:**
This commit was meant to prevent this issue: https://github.com/odoo/enterprise/commit/6c4bbf2fe0577fe1f4fc9f6a408c5904eb1cf92b

What it is meant to do is to add a `no_document` flag to prevent the creation of two documents when an attachment is uploaded to an activity, since the second one will by unlinked, along with the attachment. See:
https://github.com/odoo/enterprise/blob/a46594b2d3529d86a40a1567e0e4e0207399a3a8/documents/models/mail_activity.py#L41

But a particular case was not included:
  - if the attachment fits at least one of these criteria:
        - attachment of a misc operation
        - first attachment of an invoice
        - xml file after it has been succesfully registered as move attachment
  - if the journal in which the entry was created is synchronized with the activity's workspace

In this case, a second document is created, since we don't check for the flag `no_document` in this flow.

see:
https://github.com/odoo/enterprise/blob/28b6a5d30274f4265c978433b8d02b758d9a032e/documents_account/models/ir_attachment.py#L24

and:
https://github.com/odoo/enterprise/blob/85c139237015a7c3f1233eb9d977ead126b7d7d6/documents_account/models/account_move.py#L87

**Solution:**
Added a check for the `no_document` flag before calling `_update_or_create_document`

opw-4547561

Forward-Port-Of: odoo/enterprise#80662

To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour:

To reproduce:
- Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation.
- Enable packages in inventory settings.
- New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg).
- Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg).
- Validate the picking.

Current behaviour:
Crashes when trying to create the return label with nondescript error coming from FedEx.

Expected behaviour:
Ideally, a correctly validated picking with generated return labels. However, this appears to currently not be supported by the FedEx REST API... (multi-package single-shot return shipments of print label type)
We compromise and will create the outgoing shipment as usual, but not the return shipment in case of multi-package shipments. A helpful message informing the user of this limitation will be put in the chatter of the picking instead of the generated return label in this specific case.

opw-4556415

Forward-Port-Of: odoo/enterprise#81326

When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation. Forward-Port-Of: odoo/enterprise#81203

When using a custom engine, and defining warnings that should be displayed on the report, it has been detected that data were not up to date since the only flush made in the report generation is in the _get_lines() function. The existing flush_all() is therefore called 'too late' when generating a report. To solve it, another flush_all() is called at the beginning of the report generation.

Forward-Port-Of: odoo/enterprise#81203

Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710'). However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions. This commit proposes to use sanitized_acc_number from mandate partner bank account. opw-4536189 Forward-Port-Of: odoo/enterprise#81238

Partner bank account number with valid IBAN will be rewrite with space to be more human readable(ex: 'BE17 4126 1491 9710').

However bank transaction uses the raw number('BE17412614919710') so there is no match during validation of SEPA payment transactions.

This commit proposes to use sanitized_acc_number from mandate partner bank account.

opw-4536189

Forward-Port-Of: odoo/enterprise#81238

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves. The assumption is that rec

Before this commit, the function _generate_deferred_entries was basically a big for-loop in which a lot of account.moves and lines are created in each iteration. This was extremely inefficient because it wasn't leveraging any batch optimization of the ORM. This PR breaks down the for-loop into smaller ones that aggregate vals and performs a single call to create records, instead of individual creations. Same approach was taken for unlinked records and posting moves.

The assumption is that records are created in the same order of the values list. This allows for breaking the for-loop because consecutive for-loops can simply inherit the order from the lists created in the loop just before. Another leverage point is that simply adding move_id to account.move.line(s) before creation is equivalent to `move.write({'line_ids': \[...\]})`. Based on the 2 assumptions, we could decouple the creation of moves and their lines into separate loops to aggregate their values.

After this PR creations, unlinks and posting operations are all batched to leverage the power of ORM optimization.


Benchmarks:
|Num deferred expenses | Time before | Time After | Num queries before | Num queries After |
|--------------------- | ----------- | ---------- | ------------------ | ----------------- |
| 100 		| 23.9s 	| 13.1s 	| 3768 		| 2918 			   |
| 1,000 	|181.4s      	| 66.5s       	| 17885         | 9530              	   |
| 10,000	|TIMEOUT(>1200s)| 616,7s    	| 1379          | 1010              	   |

opw-4480919
opw-4403217

Forward-Port-Of: odoo/enterprise#79255