The partner form now places the Avatax address validation button next to the country field. This makes the validation action easier to find while users are entering address details, improving the flow without changing the underlying process.

The purpose of this PR is to inline the "Validate" button
with the `country_id` field on the partner form view
when using Avatax.

task-2947705

The Homeworking feature is no longer marked as an application because it does not function as a standalone app. This keeps the app list clearer and prevents users from seeing it in the wrong category.

The homeworking was wrongfully marked as Application, which is not the case.

This fixes the placement of an employee document sharing field so it displays inside the intended employee form. It prevents confusion from the field appearing outside the form layout and keeps the HR documents screen tidy.

The field was added after the invisible `user_id`, hence it was showing outside of the form view.

This change makes an automated test for financial reports more reliable by adding extra checks before it proceeds. It helps reduce rare false failures in the testing system, improving confidence in release validation without changing user-facing behavior.

The tour was failing very rarely on runbot, probably due to some race condition.

This fixes an incorrect dependency between spreadsheet dashboard editing and document spreadsheets. Shared spreadsheet code is now placed in a common module used by both, reducing setup issues and improving reliability without changing business workflows.

Following 03eb62b65b5fdfe25868869f640f37ae8faa2471, spreadsheet_dashboard_edition incorrectly depends on documents_spreadsheet.

This revision move the code which is common between documents_spreadsheet and spreadsheet_dashboard_edition in spreadsheet_edition, which is a dependency of both modules.

Runbot-id 4993

Checkboxes and radio buttons now use their previous visual style after a recent simplification made them harder to read. This improves clarity for users when selecting options in the enterprise web interface.

Since https://github.com/odoo/odoo/pull/98770, the style of checkboxes
and radio buttons has also been simplified. This simplification makes
them less readable.

To fix that, this commit restores the previous style for checkboxes
and radio buttons.

Requires:
- https://github.com/odoo/odoo/pull/99632

A previously skipped spreadsheet editing test has been re-enabled. This helps ensure list autofill behavior continues to work correctly and reduces the risk of regressions in future updates.

This update renames internal spreadsheet components to make their purpose clearer and restores a previously skipped test. It helps keep spreadsheet-related features easier to maintain without introducing major visible changes for users.

The barcode scanner code has been moved into the core enterprise web area so it can be reused more consistently across related apps. This internal reorganization should make barcode features easier to maintain while preserving existing scanning behavior for users.

This change removes unnecessary Helpdesk setup code related to email alias domains. It should not affect day-to-day use, but it makes future improvements to multi-company email alias handling easier and safer.

Remove unnecessary code to ease future changes in alias management.

Prepares Task-36879 (MultiCompany Aliases)

Steps to reproduce: - Install sale_ebay module - Create a system parameter ebay_sales_team = 4 - Uninstall the module Solution: 1- We're trying to get a record with the wrong id so we set the good one 2- We ensure that the record returned is not None opw-2952241 Forward-Port-Of: odoo/enterprise#31298

Steps to reproduce:
- Install sale_ebay module
- Create a system parameter ebay_sales_team = 4
- Uninstall the module

Solution:
1- We're trying to get a record with the wrong id so we set the good one 
2- We ensure that the record returned is not None

opw-2952241

Forward-Port-Of: odoo/enterprise#31298

It seems in some CAMT files that the rate is sometimes rounded to 4 digits: ``` <AmtDtls> <TxAmt> <Amt Ccy="CHF">25805</Amt> </TxAmt> <CntrValAmt> <Amt Ccy="EUR">25000</Amt> <CcyXchg> <SrcCcy>CHF</SrcCcy> <TrgtCcy>EUR</TrgtCcy> <XchgRate>0.9688</XchgRate> </CcyXchg> </CntrValAmt> </AmtDtls> ``` While the real computed rate would be:

It seems in some CAMT files that the rate is sometimes rounded to 4
digits:
```
        <AmtDtls>
          <TxAmt>
            <Amt Ccy="CHF">25805</Amt>
          </TxAmt>
          <CntrValAmt>
            <Amt Ccy="EUR">25000</Amt>
            <CcyXchg>
              <SrcCcy>CHF</SrcCcy>
              <TrgtCcy>EUR</TrgtCcy>
              <XchgRate>0.9688</XchgRate>
            </CcyXchg>
          </CntrValAmt>
        </AmtDtls>
```

While the real computed rate would be: 25000/25805 = 0.968804495

This leads to a rounding issue:
25805 * 0.9688 = 24999.88 while we should have 25000.

We also faced another example with a batch payment and large amounts
with a rate rounded to 4 digits:

```
                <Amt Ccy="CHF">19736.93</Amt>
                <AmtDtls>
                    <TxAmt>
                        <Amt Ccy="EUR">19946.37</Amt>
                        <CcyXchg>
                            <SrcCcy>EUR</SrcCcy>
                            <TrgtCcy>CHF</TrgtCcy>
                            <XchgRate>0.9895</XchgRate>
                        </CcyXchg>
                    </TxAmt>
                </AmtDtls>
                <NtryDtls>
                    <Btch>
                        <NbOfTxs>3</NbOfTxs>
                    </Btch>
                    <TxDtls>
                        <Amt Ccy="EUR">21.85</Amt>
                    </TxDtls>
                    <TxDtls>
                        <Amt Ccy="EUR">19717.52</Amt>
                    </TxDtls>
                    <TxDtls>
                        <Amt Ccy="EUR">207</Amt>
                    </TxDtls>
                </NtryDtls>
```

This leads also to a rounding issue:
21.85 * 0.9895 = 21.62
19717.52 * 0.9895 = 19510.49
207 * 0.9895 = 204.83

21.62 + 19510.49 + 207 = 19736.94 while we should have 19736.93.

In this second case, we do not have the single transaction amount in
journal's currency directly, and we need to look at batch level to
retrieve the globalized amount in journal's currency to compute the
correct rate.

We should handle these cases properly to avoid forcing the user to
manually modify the retrieved amount after.

Forward-Port-Of: odoo/enterprise#31312
Forward-Port-Of: odoo/enterprise#30121

When canceling a PO, if the user only has an access to Purchase, an access error will be triggered: "Sorry, you are not allowed to delete documents of type 'Quality Check'" Cancelling a PO leads to the SM cancellation. At that step, we check if we need to unlink some QC (`/quality_control:StockMove._action_cancel`). To avoid any access issue, we consult all related QC in sudo mode and each time a QC must be deleted, we append it to an existing recordset `to_unlink`. But here is the issu

When canceling a PO, if the user only has an access to Purchase, an
access error will be triggered: "Sorry, you are not allowed to delete
documents of type 'Quality Check'"

Cancelling a PO leads to the SM cancellation. At that step, we check if
we need to unlink some QC (`/quality_control:StockMove._action_cancel`).
To avoid any access issue, we consult all related QC in sudo mode and
each time a QC must be deleted, we append it to an existing recordset
`to_unlink`. But here is the issue: `to_unlink` has not been created in
sudo mode. Therefore, even if the added records have the `su` flag, the
recordset itself does not have it as it keeps its initial environment.

More generically, if `a` and `b` are two existing records:
```py
(a | b.sudo()).env.su == False
(a.sudo() | b).env.su == True
```

That's the reason why, when calling `unlink` on the recordset, an access
error is raised.

Forward-Port-Of: odoo/enterprise#31285
Forward-Port-Of: odoo/enterprise#31260

With an MX company create an invoice, send CFDI for validation Open Accounting>Report>General Ledger Click on EXPORT(XML POLIZAS) The resulting file will not have any node PLZ:CompNal According to Anexo 20 "C" of Contabilidad electrónica "Pólizas de diario" the information is needed when we have it in invoices, vendor bills, and Complementos de Pago opw-2871127 Forward-Port-Of: odoo/enterprise#30437 Forward-Port-Of: odoo/enterprise#29091

With an MX company create an invoice, send CFDI for validation
Open Accounting>Report>General Ledger
Click on EXPORT(XML POLIZAS)

The resulting file will not have any node PLZ:CompNal
According to Anexo 20 "C" of Contabilidad electrónica "Pólizas de
diario" the information is needed when we have it in invoices,
vendor bills, and Complementos de Pago

opw-2871127

Forward-Port-Of: odoo/enterprise#30437
Forward-Port-Of: odoo/enterprise#29091

To reproduce the issue: (Let WH01 be the main warehouse) 1. Create a second warehouse WH02 2. Edit WH01: - Resupply From: WH02 3. Edit the resupply route of WH01: - Edit the rule from InterWH Transit to WH01/input - Lead time: 1 4. Create a storable product P: - Type: Storable - Routes: "WH01: Supply... from WH02" 5. Add P on MPS view and enable the row "Actual Replenishment" 6. Set a positive replenish quantity for P (not in the first interval) 7. Replenish

To reproduce the issue:
(Let WH01 be the main warehouse)
1. Create a second warehouse WH02
2. Edit WH01:
    - Resupply From: WH02
3. Edit the resupply route of WH01:
    - Edit the rule from InterWH Transit to WH01/input
        - Lead time: 1
4. Create a storable product P:
    - Type: Storable
    - Routes: "WH01: Supply... from WH02"
5. Add P on MPS view and enable the row "Actual Replenishment"
6. Set a positive replenish quantity for P (not in the first interval)
7. Replenish P

Error: The actual replenishment is updated on the previous interval. It
should be on the interval defined at step 6.

When computing the date of an incoming stock move, we get and use the
delay of its dest moves but we don't consider the delay of the move
itself.

Moreover, `_get_dest_moves_delay` handles the case where a SM does not
have any dest move, so `_get_moves_and_date` can be simplified

OPW-2906741

Forward-Port-Of: odoo/enterprise#31274
Forward-Port-Of: odoo/enterprise#31067

Com PR: https://github.com/odoo/odoo/pull/98910 Task ID - 2960827 opw-2954181 Forward-Port-Of: odoo/enterprise#30897 Forward-Port-Of: odoo/enterprise#30740

Com PR: https://github.com/odoo/odoo/pull/98910

Task ID - 2960827
opw-2954181

Forward-Port-Of: odoo/enterprise#30897
Forward-Port-Of: odoo/enterprise#30740

The discarded records were no longer showing when using the dedicated filter. task-2961886 Forward-Port-Of: odoo/enterprise#31294

The discarded records were no longer showing when using the dedicated filter.

task-2961886

Forward-Port-Of: odoo/enterprise#31294

Steps to reproduce the bug: - Have companies A and B - Select company A as current company and B as allowed company - Go to barcode app > Operations > Select receipts of the company B - Try to create a new picking Problem: An access error is triggered because we access company B data while only company A is in the allowed companies. When we get the record `stock.picking`, we make sure that the value of `env.company` is correct with the `with_company`, but this function will also re

Steps to reproduce the bug:
- Have companies A and B
- Select company A as current company and B as allowed company
- Go to barcode app > Operations > Select receipts of the company B
- Try to create a new picking

Problem:
An access error is triggered because we access company B data while only
company A is in the allowed companies.

When we get the record `stock.picking`, we make sure that the value of
`env.company` is correct with the `with_company`, but this function will
also redefine the authorized companies with the context key
`allowed_company_ids`, Except that this key is not present in the
context of the record. So`with_company` will define "company A" as the
current company (correct) but as the only authorized company
(incorrect):
https://github.com/odoo/odoo/blob/4c611efa959f8b856ef4ba1a16df664acd0cfecf/odoo/models.py#L5283-L5293

Instead, we can define the allowed companies with the `with_context`
function. The ORM will be able to deduce the current company:
https://github.com/odoo/odoo/blob/e902713648bca329e6821859462b2128aad62c09/odoo/api.py#L639

opw-2926638

Forward-Port-Of: odoo/enterprise#31068