When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

Issue:
When a shopper pays for an online order entirely using a reward (e.g. a discount code covering 100% of the total), the order total is zero. With automatic invoicing enabled, an invoice with an amount of 0 is created. But, the 0 invoice is never emailed to the customer. Whereas, for orders where the total is more than 0, an invoice is created, then emailed to the customer. The customer should be emailed the invoice, even if its amount is 0.

Steps to reproduce:
1. Enable automatic invoicing.
2. Create a code for a 100% discount.
3. As a shopper, add a product to cart on the website.
4. While checking out, apply the 100% discount code to the order.
5. Complete the checkout.
6. Confirm that an invoice was created and posted, but was not emailed to the customer.

Explanation:
Normally, order confirmation and invoicing are handled by the `_post_process` method on the `payment.transaction` model. With automatic invoicing enabled, `_post_process` confirms the sale order, creates the invoice, and sends the invoice via `_send_invoice` (another method on the `payment.transaction` model). If `sale.async_emails` is enabled, `_post_process` will trigger a cron that invokes `_send_invoice` instead of invoking it directly.

When an order is fully covered by a reward, there's nothing to pay. In this case, no payment.transaction record is ever created, and `_post_process` never runs. Instead, the order is confirmed through the `_validate_order` method on the `sale.order` model. The `sale_loyalty` module extends `_validate_order` so that, with automatic invoicing enabled, it will create and post an invoice for zero-amount orders. But, nothing in this path ever calls `_send_invoice` or an equivalent. So, the invoice is created and posted but never sent.

Solution:
This adds logic for sending invoices to the extension of `_validate_order` in the `sale_loyalty` module. We mirror the logic used in `_send_invoice` in the `payment.transaction` model.

Notes:
There is duplicated code from `_send_invoice` in this fix. That is because `_send_invoice`, a method on the `payment.transaction` model, can't be used in this flow. A fix that avoids code duplication would require serious refactoring.

This will never trigger a cron to send the invoice, even if `sale.async_emails` is enabled. That is because the cron invokes `_send_invoice`. Since fully reward-covered orders are probably not common, any performance benefits of using a cron are probably not significant. But, making a new cron to be used in this case is also an option.

opw-6363334

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

Forward-Port-Of: odoo/odoo#277678
Forward-Port-Of: odoo/odoo#275190

When importing an EnvioDTE XML containing several DTEs (journal upload or incoming DTE mail server), one vendor bill is created per DTE, but the first bill receives the invoice lines and references of ALL the DTEs in the file, causing the total amount mismatch.

Cause: `_split_xml_into_new_attachments()` creates new attachments for the documents beyond the first one but leaves the original `file_data['xml_tree']` untouched; the decoder must scope itself to the first document (as l10n_it_edi and l10n_es_edi_facturae do), which `_l10n_cl_import_dte()` never did.

e.g. l10n_es_edi_facturae:633:

```python
# Only decode the first invoice of the Factura-e file.
tree = tree.xpath('//Invoice')[0]
```

Fix: scope the tree to the first DTE node before filling the bill. Kept behind a `len > 1` guard so files with a bare <DTE> root (matched by `xpath('//ns0:DTE')` but not by `findall('.//ns0:DTE')`) keep working.

Introduced in: https://github.com/odoo/enterprise/pull/75327.

opw-6378954

Forward-Port-Of: odoo/enterprise#124691

Steps to reproduce:
===================
1. Create a subscription product, allow one-time sale, sale price 5
2. Add a recurring price 10/month
3. On the pricelist, add an advanced rule: -10% for the monthly plan
4. Open the shop page and look at the product tile

Cause:
=======
On the /shop page, the subscription price displayed on a product tile is computed by `_get_sales_prices`. The cart has no plan selected yet at that point, so `request.cart.plan_id.id` is empty and was passed as `plan_id` to `_compute_price`.

In `product.pricelist.item._compute_base_price`, the recurring base price is only looked up when a `plan_id` is given: if rule_base == 'list_price' and product.recurring_invoice and plan_id: ... # find the recurring rule -> base = recurring price

With `plan_id` empty, that branch is skipped and the percentage rule falls back on the product's one-time `list_price` instead of the recurring price.

Example: one-time price 5, recurring price 10/month, pricelist rule -10% on the monthly plan.
=> Tile showed 4.5/month (5 * 0.9) instead of 9/month (10 * 0.9).

Solution:
=========
The chosen pricing already targets a plan, so pass `pricing.plan_id.id` to `_compute_price`, matching what the product page does in `_get_additionnal_combination_info`.

opw-6307398

Forward-Port-Of: odoo/enterprise#120872

### Issue before this commit:
When a company generates an EC Sales List for a foreign country (e.g., a Luxembourgish company running a Belgian report), the exported XML and PDF files incorrectly display the company's primary domestic VAT number instead of the foreign VAT number defined in the fiscal position in the tag DeclarantReference.

### Steps to reproduce the issue:
1. Download Accounting and l10n_lu
2. Switch to LU company
3. Go to Fiscal Positions in settings and create the Belgian position (insert country as Belgium and Foreign Tax ID as BE0477472701)
4. A pop up will appear saying: Click  to create the taxes for this country. so click there to create the taxes
5. Go to Invoices and create a new invoice and be sure that:
	1. be sure the customer has a VAT number in their profile
	2. in tab Other Info the Fiscal Position is set to Belgium
	3. the tax applied is 0% EU S (BE)
	4. date of invoice is in June
6. Open the tax return in 1 July
7. Open EC Sales List June 2026 (BE) and mark as reviewed all the lines
8. Click on Validate
9. Open the XML and PDF file created and see that the tag DeclarantReference is wrong because it reports the data of LU company instead of BE company

### Cause of the issue:
The `export_to_xml_sales_report` method relied on legacy code (company.partner_id.vat) to fetch the VAT number. It failed to use the centralized `get_vat_for_export(options)` method, thereby completely bypassing the foreign VAT logic correctly implemented in other tax reports.

### Reason to introduce the fix:
To ensure tax compliance by appling the correct VAT number from the foreign fiscal position.

opw-6170447

Forward-Port-Of: odoo/enterprise#125210
Forward-Port-Of: odoo/enterprise#124698

## Steps to reproduce:

1. Install `l10n_br`, `l10n_br_avatax`, and `l10n_br_edi_fiscal_reform`.
2. Ensure that Demo mode is activated if not on Runbot.
3. Navigate to Contacts, then click into "BR Company Customer Estimated Profit".
4. Duplicate this contact, then set the following fields:
   1. Tax Regime set to individual
   2. ICMS Taxpayer Type set to Non-Taxpayer
5. Swtich to the BR Company and go to Accounting / Configuration / Settings.
6. Set up a Sandbox Avalara account and enable logging payload responses.
7. Navigate to Accounting > Customers > Invoices.
8. Create an invoice with:
   1. Customer set to the copy created earlier.
   2. Operation Type set to Sale of Goods
   3. Document Type set to 55
   4. Payment Method Brazil set to Money
   5. Presence set to Present
   6. One sales order line with:
      1. Regular Consumable Product
      2. quantity set to 1
      3. price set to 100.0
9. Confirm the invoice.
10. Navigate back to Accounting > Configuration > Settings to view the response from Avalara. The customer will have the CFOP 6102 instead of CFOP 6108.

Explanation:

PR #97845 introduced `_l10n_br_deep_clean_dict()` to remove falsy values and empty dictionaries from the payload we send to Avalara. This fix was applied as broadly as possible to prevent excessive if statements.

However, if the falsy values in taxSettings of the customer are not communicated, Avalara will assign the customer to an incorrect CFOP.

opw-6085964

Forward-Port-Of: odoo/enterprise#120783

**Problem:**
After partially invoicing a timesheet-delivered sale order line, a second invoice for the remaining delivered quantity can no longer be created.

**Steps to reproduce:**
1. Install Sales and Timesheets
2. Sell a service invoiced on delivered timesheets
3. Log a timesheet covering the whole period
4. Create an invoice, reduce its quantity to part of the delivered amount, and post it
5. Create an invoice again for the rest

**Current behavior:**
"Cannot create an invoice. No items are available to invoice." is raised, even though qty_delivered - qty_invoiced is still positive.

**Expected behavior:**
A second invoice is created for the remaining delivered quantity.

**Cause of the issue:**
Since opw-6001094, `_recompute_qty_to_invoice` runs on every invoice creation, not only when a timesheet period is provided. It re-derives `qty_to_invoice` from un-invoiced timesheets alone. Posting the first invoice already linked every timesheet of the line (the linking ignores the invoiced quantity), so no un-invoiced timesheet is left, and `qty_to_invoice` is forced to 0 — discarding the still-billable remainder.

**Fix:**
Forcing the quantity to zero is only meaningful when the invoice is restricted to a timesheet period, where a line whose timesheets all fall outside that period genuinely has nothing to invoice. Without a period, the standard delivered-versus-invoiced quantity is the authoritative measure of what remains to bill, so the timesheet-based recomputation must not override it.

opw-6295941

Forward-Port-Of: odoo/odoo#274677

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Forward-Port-Of: odoo/odoo#277640
Forward-Port-Of: odoo/odoo#272161

### Description of the issue/feature this PR addresses:

- Opening Studio on a form containing a Many2many field using the many2many_tags_email widget crashes with an OWL prop validation error.

- **Steps to reproduce:**

1. Open any form view (e.g., Contacts) and enter `Studio`.
2. Create a new `Many2many` custom field on a model such as `res.partner`.
3. Set the field's widget to `many2many_tags_email` and save the customization.
4. Exit Studio and populate the field with one or more related records.
5. Open Studio again on the same form view.

This results in the following error:
```.js
Error: Invalid props for component 'RecipientTag': 'onDelete' is undefined
(should be a value)

```
### Current behavior before PR:

- When opening Studio on a form containing a `Many2many` field with the `many2many_tags_email` widget, the field is rendered with `onDelete` set to undefined by `Many2ManyTagsField`. Starting from `saas-19.1`, the `many2many_tags_email` widget uses the new [RecipientTag] component, which requires onDelete to be defined. As a result, Owl's prop validation fails when RecipientTag receives `onDelete = undefined`, causing Studio to crash with an I nvalid props for component 'RecipientTag' error.

### Desired behavior after PR is merged:

- RecipientTag should allow onDelete to be optional so that it can also be used when the parent field does not provide a delete callback. This prevents the Owl prop validation error when opening Studio, while keeping the existing delete functionality unchanged for editable fields where onDelete is available.

opw:6395209

[RecipientTag]: https://github.com/odoo/odoo/blob/saas-19.1/addons/mail/static/src/core/web/recipient_tag.js

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

Forward-Port-Of: odoo/odoo#277934

Before this commit, validating transfers of several companies at once could assign a lot of one company to the move lines of another one, because the search for existing lots used a variable left over from a previous loop (the last move line iterated) instead of the company of the group of lines being checked.

Steps to reproduce:
- in a multi-company database, create a product tracked by lots
- create a lot with the same name for that product in each company
- create one receipt per company with that lot name typed in the detailed operations, select both receipts in the Transfers list view and validate them together

The lines of one company are linked to the lot of the other company and the validation is blocked by "Incompatible companies on records". When the lot only exists in one of the companies, the search misses it and the validation fails on the lot uniqueness constraint while recreating a lot that already exists.

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

Forward-Port-Of: odoo/odoo#277227
Forward-Port-Of: odoo/odoo#276688

Steps to reproduce
1. Go to Website Settings.
2. Configure the "Contact Us" form to create an Opportunity.
3. Select a "Default Sales Team" (ensure this team has a Team Leader set).
4. Leave the "Default Salesperson" field empty (None).
5. Submit the "Contact Us" form on the website.

Current behavior
The resulting Opportunity is automatically assigned to the Team Leader.

Expected behavior
The Opportunity should remain unassigned, respecting the empty
"Default Salesperson" configuration.

Issue
In https://github.com/odoo-dev/odoo/commit/d136e79d1ea0a4793ba9d447603e6f0e29b40770, a fallback was introduced to
explicitly assign the Team Leader (`team_id.user_id`) whenever a team was
present but a salesperson was not, provided rule-based assignment was disabled:
https://github.com/odoo/odoo/blob/d136e79d1ea0a4793ba9d447603e6f0e29b40770/addons/website_crm/models/crm_lead.py#L55-L56

This incorrectly overrides the intentional configuration in the website
settings. Additionally, in https://github.com/odoo-dev/odoo/commit/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91, the
website_form_input_filter was made to fall back to request.website.crm_default_team_id
and crm_default_user_id when the form did not submit those fields:
https://github.com/odoo/odoo/blob/ba6a5ddc8dec971f8b810dfad3d9934e7b581c91/addons/website_crm/models/crm_lead.py#L14-L17

The Contact Us form already passes the configured team and salesperson as
hidden inputs. When they are not configured, nothing is submitted for those
fields. The fallback to request.website caused leads to be assigned a team
even when neither field was intentionally configured, because crm_default_team_id
defaults to the first sales team on website creation.

opw-6050663

Forward-Port-Of: odoo/odoo#257134

Description of the issue/feature this PR addresses:

report_stock_quantity uses m.quantity instead of the done quantity converted to the product's base UoM when computing the forecast for done inter-warehouse moves. This causes incorrect forecast values when a done stock move uses a UoM with a factor greater than 1.

Current behavior before PR:

When a done inter-warehouse move uses a UoM with factor > 1 (e.g. a box of 25 units), the forecast only subtracts the raw done quantity (e.g. 2 boxes) instead of the converted quantity in the product's base UoM (e.g. 50 units). This causes the forecast chart to show incorrect negative values before the move date.

Steps to reporduce:

- Create a storable product with base UoM = Units
- Create a UoM "Box of 25" with factor = 25 in the Units category, and add it to the product's allowed UoMs
- Create a second warehouse
- Do an inventory adjustment of 800 units into warehouse 1
- Create an inter-warehouse transfer of 2 "Box of 25" (= 50 units) from warehouse 1 to warehouse 2 and validate it
- Open the forecast chart for the product filtered to warehouse 1

Desired behavior after PR is merged:

The forecast report for done inter-warehouse moves correctly converts the done quantity to the product's base UoM using the move's UoM factor, so the forecast chart shows accurate values regardless of the UoM used on the move.


opw-6266745


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

Forward-Port-Of: odoo/odoo#271766

Problem:
When computing inventory valuation or available quantities for a date in the past (using the  context), the system calculates the past quantity by taking the current stock quants and rolling back the stock moves that occurred after the requested date.

However, when the environment context specified an ownership filter (e.g.,  to calculate company-owned valuation), this filter was only being applied to the  domain. The rollback domains for incoming and outgoing  records remained completely open.

As a result, the system would correctly see 0 company-owned current stock, but it would erroneously subtract incoming consigned stock moves from that balance. This resulted in an artificially negative past quantity and a negative inventory valuation for company-owned stock.

Solution:
This commit ensures the  context is applied symmetrically by filtering the rollback moves via the  field. The
time-travel calculation will now only evaluate stock moves that match the queried ownership context.

Steps to reproduce (runbot v19):
- Consignment enabled
- FIFO perpetual product w/ nonzero value
1. Create an inventory adjustment for an internal location, set the owner on the quant
2. Create a delivery for this product, but don't zero out all of the available stock
3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, before any move history in the db. The product's current on hand value will appear in ending stock, but negative.

opw-6300582

Forward-Port-Of: odoo/odoo#270409

**Description of the issue/feature this PR addresses:**

[FIX] account: prevent access error for branch users

When a user restricted to a branch company opens the accounting dashboard,
they may encounter an AccessError preventing the app from loading.

This occurs because the dashboard logic attempts to read the 
`fiscalyear_lock_date` from the journal's company. In a branch setup, 
this configuration often belongs to the parent company, which the user
typically does not have read access to. The system then blocks the action
and gives an AccessError.

This commit resolves the issue by adding `.sudo()` when reading the 
`fiscalyear_lock_date`. This safely bypasses the record rule restriction, 
allowing the dashboard to fetch the necessary accounting configuration 
without requiring the user to have broad access to the parent company.

**Steps to reproduce:**

- As Mitchell Admin:
  - Settings > Users & Companies > Companies > My Company (San Francisco) > Branches > create a branch
  - Settings > Users & Companies > Users > Marc Demo > Access Rights > change “Companies” and “Default Company” to only the newly created branch
- As Marc Demo:
  - Attempt to access Accounting app > observe Access Error


**Current behavior before PR:**

- Users belonging to only a branch company are unable to access the Accounting dashboard

**Desired behavior after PR is merged:**

- Users belonging to only a branch company are able to access the Accounting dashboard

opw-6369616

Forward-Port-Of: odoo/odoo#277877

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

[IMP] *: apply new icon implementation globally
---

This commit is a follow-up to odoo/odoo#273606.

It applies the new icon implementation across the entire codebase,
replacing almost all legacy icon usages.

Previous patterns such as `class="oi oi-fw oi-arrow-left"` or
`class="fa fa-fw fa-arrow-left"` are migrated to the new format
using `class="oi oi-fw"` with the data-icon attribute (e.g.,
`data-icon="west"`), ensuring consistency with the Material
Symbols-based system.

Community PR: odoo/odoo#256840

task-5901783

---

[IMP] web_{enterprise, studio}: adapt icon selector for Material Symbols
---
With the switch to Material Symbols as the icon set, the app/menu icon
pickers and the various places that render web icons no longer rely on
Font Awesome classes. The FontAwesomeIconSelector component is renamed to
the StudioIconSelector and now sources its choices from the html_editor
MediaDialog icon selector (via initFonts) instead of the removed
getFontAwesomeIcons util. Icons are rendered with the `oi` class and a
`data-icon` attribute holding the Material Symbols name rather than a
composed class string, and the st full icon
name (no more stripping the `fa ` prefix).

Templates and components across web_enterprise (home menu, navbar) and
web_studio (icon creator, editor  button box
dialog) are updated accordingly, the icon_selector asset is added to the
Studio minimal bundle, and the reusted to use
Material Symbols names.

task-5901783

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579

While trying to fix the SAT cron, we did not think it through
it could cause infinite cron triggering.
Indeed, the write_date is updated on every record that is handled.

Fix is manyfold:
- Avoid re-processing what we already check within the last 4 hours/12 hours
depending on the type of the document.
- The domain takes the *static* create date instead of the write_date
to make sure we don't endless re-process the same record and that
the window of 7/60 days applies.
- Limit the Vendor Bill to be checked only during 7 days after their creation.
- Use the create_date in the order of the search to ensure we process older
records first, before their time-window closes.
- Process the Vendor Bills last, this ensure Customer Invoices will be processed
in priority in case we are not able to process everything within the last 4/12 hours.

This is still imperfect and a little fragile, we will find a better solution
in master, most likely by adding a dedicated field to keep track of the
last SAT check.

See https://github.com/odoo/enterprise/pull/123213
See https://github.com/odoo/enterprise/pull/103272

task-none

When importing a WinBooks zip, contacts sharing the same number might fail VAT validation if distinct contact data is merged incorrectly.

Steps to reproduce:
- Create a database with the Belgian localization installed
- Install the account_winbooks_import module
- Navigate to Accounting > Configuration > Settings > Initial Setup > Import
- Import the WinBooks zip

Issue:

The import fails with the following error:
The VAT number [AAAAAA] for partner [BBBBBB] does not seem to be valid. Note: the expected format is BExxxxxxx.

Analysis:
In WinBooks, contacts can be of type Supplier or Customer, and it is possible for a supplier and a customer to share the same number. During the import, the system will merge contacts if found with the same number.

In the specific case, the VAT number from one contact without country is combined with the country information from another contact, resulting in a VAT validation error.
This change prevents the merger of partner data if their VAT numbers are explicitly different.

opw-6251772

Forward-Port-Of: odoo/enterprise#119579