### Description of the feature this PR addresses:
**Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.**

A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190.

### Current behavior before PR:

Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it.
This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model).

**In practice, this separation is necessary because:**

- Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment.
- Withholdings made on these amounts must be declared in specific sections of Form 190.
- If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted.

### Desired behavior after PR is merged:

A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to:
- Correctly identify and calculate the related amounts.
- Report them separately in the AEAT Model 190.
- A new tax group has also been created to distinguish these withholdings from regular ones.

### Benefits:

- It allows you to correctly generate Form 190, separating income derived from and not derived from work disability.
- It facilitates the accounting and tax traceability of this type of income.
- It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing.
- It improves the flexibility of the Odoo tax system, adapting it to actual tax needs.

### Technical summary:

- A **new specific tax** has been created for withholdings associated with incapacity for work benefits.
- This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.**
- In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income.

The related issue: https://github.com/OCA/l10n-spain/issues/4416

### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies”

**Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group.

**Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections.

These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll.

Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations.

**Outcome:**

- Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**.
- Clean separation from other withholdings via the new tax group.
- Consistency between accounting, payroll, and the 190 export.

Would you accept this change?


@moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 

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

Forward-Port-Of: odoo/odoo#245553
Forward-Port-Of: odoo/odoo#232515

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

Forward-Port-Of: odoo/enterprise#106881

Currently, an error occurs when user creates a payment for an invoice.

**Steps to Reproduce:**

 - Install `l10n_uk_bacs` with demo data.
 - Switch to the `UK company`.
 - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`.
 - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero.
 - `Confirm` the invoice.
 - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`.

`ValueError: Expected singleton: res.partner.bank()`

This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment 
method. The constraint check bacs bank account trigger [1], but since the journal has no bank 
account number, it raises an error here [2].
Similar error also occurs when validating a batch payment [3].

This commit ensures that if the journal has no bank account, or if the bank account is invalid, 
the system raises the same validation error. In batch mode, it raises a UserError when the 
account is missing.

[1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58

[2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19

[3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74

sentry-7259107152

Forward-Port-Of: odoo/enterprise#107235

Currently, an error occurs when searching by date on the shop page.

**Steps to Reproduce:**

- Install the `website_sale_renting_planning` module.
- Go to `Products` and create a product with the following configuration:
  - `Type`: `Service`
  - Under the `Sales` tab, set the `Periodicity` value.
- Go to `Planning` > `Configuration` > `Roles` and switch to `Kanban` view.
- Create a record by adding a `Resource` and the `service` product.
 - Enable `Sync Shifts and Rental Orders` in this role.
- Go to `Website` > `Shop`.
- Click `Edit` > `Style` > enable `Rental` by selecting it in the `toolbar`, then `save`.
- Set the `start date` and `end date` and `apply` the filter.

**Error1:**

`ValueError: Invalid field 'resource_id' on model 'planning.slot' for 'resource_id:recordset'.`

**Error2:**

 ` File "/home/odoo/odoo18/community/addons/resource/models/resource_calendar.py", line 455, in _leave_intervals_batch for _, resources in resources_per_tz.items():`
`AttributeError: 'resource.resource' object has no attribute 'items'`

This error occurs because after this [recent commit], the field `resource_id` was replaced by 
`resource_ids` with a M2M relation. When the user searches by date, the system attempts 
to group planning slots by `resource_id`, which raises the error[1].
After this [new commit], _leave_intervals_batch expects resources grouped by timezone, 
but here only resources are passed [2], which raises the error [3].

This commit ensures that `search_fetch` is used to retrieve `resource_ids`, since `read_group` 
cannot group records by M2M fields. It also ensures that resources with their timezone are 
correctly passed to _leave_intervals_batch.

[recent commit]: https://github.com/odoo/enterprise/commit/fbf8b2ac67c71ca0abfc75df543069696bd2d29b

[new commit]: https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be#diff-11ecbc9f00711187e60b88f84c618046bb24ada8c39cb29037568c1aa46f06a5

[1]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L30

[2]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L50

[3]: https://github.com/odoo/odoo/blob/9e41753a14c7398927445d8dc8f69dc57047b0b6/addons/resource/models/resource_calendar.py#L453

sentry-7325252044

Issue before this commit:
=========================
Clicking Produce All on a Manufacturing Order as a user with Manufacturing and Timesheet rights raised an AccessError.

During Manufacturing Order completion, Odoo creates analytic lines for work center cost distribution and links them to the work order through the wc_analytic_account_line_ids Many2many field. With the stricter ORM security checks, linking records in a Many2many field requires read access to those records. Since analytic lines are created using sudo() but the relation update runs under the current user's permissions, the operation fails due to timesheet-related record rules.

Steps to Reproduce:
=========================
1. Install mrp_account and hr_timesheet modules.
2. Create a Work Center with an analytic distribution.
3. Create a Product with a Bill of Materials (BoM) that includes a work order using the created Work Center.
4. Log in as a non-admin user with Manufacturing and Timesheet permissions.
5. Create and confirm a Manufacturing Order for that product.
6. Click Produce All.

Cause of the Issue:
=========================
Analytic lines are created with sudo(), but when linking them to the work order through the Many2many field wc_analytic_account_line_ids, the ORM checks whether the current user has read access to those records. Due to timesheet record rules restricting access to analytic lines, the linking operation raises an AccessError.

With This Commit:
=========================
This commit allows users to complete Manufacturing Orders without encountering access errors when analytic lines are linked to work orders, while preserving the existing analytic distribution and security logic.

For Reference: [Security checks on Many2many](https://github.com/odoo/odoo/pull/217277/changes#diff-720a85988e5f3afc3b2596b9521964ef4a99e03e5b1ea8bea2e8ee476187526aR1467)

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/1HsZjpFSsnsYxZ4xwM8CBDeLhlcIHIP5t/view)

opw-5971807

Forward-Port-Of: odoo/odoo#253496

When opening invoice HTML preview in the portal, the layout was displayed in LTR
even if the invoice partner language was RTL (e.g. Arabic). This happened when
the portal user language was LTR. PDF structure was correct, but HTML preview had
wrong text flow and alignment.

Root cause was that RTL asset processing depends on `env.lang`, not on `t-lang`
in templates. Since the ORM context language remained the portal user’s language,
CSS was compiled in LTR and hardcoded `direction: ltr;` rules from `report.scss`
were overriding the `<html dir="rtl">`.

To fix this, the portal controller now checks the partner language and, if it is
RTL, updates the request context before rendering. This ensures `_render_qweb_html`
runs with the correct `env.lang`, triggering proper RTL CSS conversion via rtlcss.

Additionally, the subtotal section in the Saudi invoice report could have its
values visually cut due to insufficient width allocated to the tax totals
column. The column width has been slightly increased to ensure totals are
properly displayed.

task-5878719

Forward-Port-Of: odoo/odoo#248822

If an order in overpaid using bank, no move line is created for the change.

Steps to reproduce:
-------------------
* Make an order, add a customer
* During payment, select invoice, pay more than the order amount with bank pm
* Validate
* Close register
* Check customer
> Observation: It says we owe the customer money, although change was given.

Why the fix:
------------
Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it.

Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted.

opw-5149700

Forward-Port-Of: odoo/odoo#254125
Forward-Port-Of: odoo/odoo#247621

Currently an exception is generated when the user tries to submit
a job application through the form.

Steps to produce an error:
- Install the `web_studio` and `website_hr_recruitment` modules
- Add a new File field to the `hr.applicant` module with the studio.
- Go to the website editor and add the form `Apply for a Job` and
  add the recently created field into the form and save it
- An error will occur when submitting the form with the added field

Error: `KeyError: 'manual'`

This issue occurs because the `manual` key(attribute) is not included in the
`authorized_fields` variable, which is generated by the `get_authorized_fields`
method. After the recent refactoring introduced in commit [1], the code
was changed to fetch only a limited set of attributes instead of all attributes,
and the manual attribute was not added to this list.

This commit resolves the above issue by including the `manual` attribute when
retrieving model fields, which was not added in commit [1].

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

Sentry-7271118700
opw-5933992

Forward-Port-Of: odoo/odoo#249240

### Description of the feature this PR addresses:
**Specific tax on withholdings for incapacity to work created to correctly reflect the amounts derived in Form 190 of the AEAT.**

A new tax called "**100% WHI monies**" has been created with the aim of correctly reflecting the income derived from incapacity for work in the AEAT's Model 190.

### Current behavior before PR:

Currently, Odoo does not allow automatic differentiation between monetary payments derived from work incapacity and those not derived from it.
This creates a problem when generating Model 190, as the Spanish Tax Agency (AEAT) requires both types of payments to be reported separately (according to the codes and subcodes established in the model).

**In practice, this separation is necessary because:**

- Income derived from incapacity for work (e.g., sick leave) is considered employment income with differentiated tax treatment.
- Withholdings made on these amounts must be declared in specific sections of Form 190.
- If they are not separated correctly, the totals on the form may be incorrect or incomplete, affecting the accuracy of the tax information submitted.

### Desired behavior after PR is merged:

A new tax has been added to represent “100% Withholding income tax (workers)”, allowing Odoo to:
- Correctly identify and calculate the related amounts.
- Report them separately in the AEAT Model 190.
- A new tax group has also been created to distinguish these withholdings from regular ones.

### Benefits:

- It allows you to correctly generate Form 190, separating income derived from and not derived from work disability.
- It facilitates the accounting and tax traceability of this type of income.
- It ensures consistency with the information structure required by the Spanish Tax Agency (AEAT), avoiding errors in the annual filing.
- It improves the flexibility of the Odoo tax system, adapting it to actual tax needs.

### Technical summary:

- A **new specific tax** has been created for withholdings associated with incapacity for work benefits.
- This tax **allows the amounts corresponding to these benefits to be identified, accounted for, and reported independently.**
- In addition, a **new tax group "Whitholdings IRPF Workers" has been added that groups these withholdings together**, allowing them to be clearly distinguished from other withholdings on earned income.

The related issue: https://github.com/OCA/l10n-spain/issues/4416

### Follow-up suggestion: adjust Odoo’s base tax “15% WHI monies”

**Proposal:** Change the base tax “15% WHI monies” to 100% and move it to the new “Whitholdings IRPF Workers” tax group.

**Why:** The current 15% rate is not aligned with how AEAT Model 190 requires amounts to be computed: the base should reflect 100% of the earnings derived from temporary incapacity, with the withholding rate applied on top of that base. Keeping 15% leads to misclassification and wrong totals in the "_percepciones_" and "_retenciones_" sections.

These are variable withholdings, not fixed taxes — each worker’s rate can change monthly depending on their income and number of days worked. Therefore, having a fixed 15% rate is conceptually incorrect and causes misclassified amounts and inaccurate totals, forcing users to adjust values manually after payroll.

Ideally, this tax should not have any fixed percentage defined. Since Odoo currently requires a rate, setting the base to 100% is a pragmatic workaround that ensures more accurate and flexible withholding calculations.

**Outcome:**

- Correct calculation and reporting of **_percepciones derivadas de incapacidad laboral_**.
- Clean separation from other withholdings via the new tax group.
- Consistency between accounting, payroll, and the 190 export.

Would you accept this change?


@moduon @rafaelbn @EmilioPascual @chklop @jco-odoo MT-11667 

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

Forward-Port-Of: odoo/odoo#245553
Forward-Port-Of: odoo/odoo#232515

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

Forward-Port-Of: odoo/enterprise#106881

Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1".

In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed.

Solution: we should never have considered anything else than left-button actions anyways.

[1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb
[2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185
[3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28
[4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3

task-6055182

## [FIX] account: sequence mixin cache on cr.cache instead of precommit
The aim of this commit is to prevent the creation of Savepoint in chain.
This is achieved by preventing the `sequence.mixin` cache to be cleared
as soon as a flush happens and to prevent the `bank.statement.line`
creation to clear the cache.

### Context:
During an import of document, like a big CSV of bank statement for
example, if any issue arises, the ORM rollback to the savepoint of
import and retry to import one record at a time and rollback again
later on to collect the errors and show the faulting line to the
customer.

### Cause:
1) As we flush for every single record, the `precommit.data.cache` gets
   cleared during the flush and the `sequence.mixin` cache gets wiped
   out.
2) The creation of bank statement set the name of its move_id to False
   which results in the `sequence.mixin` code to clear its own cache by
   itself.
   [name set to False](https://github.com/odoo/odoo/blob/1361c0bc98c91f1e601b0fc3beaa948df3a3bfcd/addons/account/models/account_bank_statement_line.py#L410-L412)

Both (1) and (2) results in the sequence.mixin code to recreate the
cache and, for that, to create a new Savepoint.
This is done at each iteration of the import loop which could results
in this case in 300+ savepoints existing at the same time eating all
Postgres shared buffers memory putting the whole production database
on its knees.

task-id: None (investigated for odoo.com)

Forward-Port-Of: odoo/odoo#250827

Backport of https://github.com/odoo/odoo/pull/249869

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

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

When vendor bills digitization is deactivated, subscribers to the "Purchases" journal are not notified when a vendor bill is sent to the email alias set on the "Purchases" journal

Steps to reproduce:
1. Install Accounting
2. Go to Settings > Accounting > Digitization and set Vendor Bills to "Do not digitize"
3. Go to Settings > Technical > Email > Alias Domains and create a new alias domain (e.g. "odoo.com")
4. Go to Settings > Technical > Email > Incoming Mail Servers and create a new incoming mail server (e.g. "megu@odoo.com", you may need to setup POP access on your email address and create an app password, see https://support.google.com/mail/answer/7104828)
5. Go to Accounting > Configuration > Journals and open journal "Purchases"
6. Go to Advanced Settings tab and set the Email Alias and the Send Copy To fields (e.g. "megu@odoo.com" for both)
7. Send a mail with an attachment to the email alias set on the "Purchases" journal
8. Go to the previously created incoming mail server and click on Fetch Now
9. Go to Settings > Email > Technical > Emails
10. No email has been sent to the subscriber of the "Purchases" journal

Issue:
`_extend_with_attachments` returns None if the OCR import failed https://github.com/odoo/odoo/blob/b44295bb6ce621ff87cbc96860492650d90d0ad7/addons/account/models/account_document_import_mixin.py#L340-L349 which prevents the call to method `_notify_invoice_subscribers`

Solution:
Send an email regardless of the result of the OCR import

opw-5914096

Forward-Port-Of: odoo/odoo#252442

Trying to investigate this common issue:

https://runbot.odoo.com/runbot/build/104596176 script timeout exceeded -> internal error during screenshot + timeout error when trying to shut down service workers (but oddly `Page.stopLoading` worked so the browser might not be entirely hosed?)

https://runbot.odoo.com/runbot/build/104598123 and https://runbot.odoo.com/runbot/build/104599315 only parsed a timeout during service workers shutdown, but looking at the logs they actually have the same error, it's just that the in-band error is suppressed by the retry, but then the traceback finder goes and triggers on the TB it finds in the logs (but only the last link of the TB so the thing is cut off):
```

2026-03-19 03:48:11,239 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Asking for screenshot 
2026-03-19 03:48:11,241 26 INFO 104599315-saas-19-1-all odoo.addons.website.tests.test_snippets.TestSnippets.test_03_snippets_all_drag_and_drop: Couldn't capture screenshot: Internal error 
2026-03-19 03:48:21,249 26 _WARNING 104599315-saas-19-1-all odoo.tests.common: Error during browser shutdown 
Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 2566, in browser_js
    self.fail(str(error))
  File "/usr/lib/python3.12/unittest/case.py", line 715, in fail
    raise self.failureException(msg)
AssertionError: Script timeout exceeded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1664, in _websocket_request
    return f.result(timeout=timeout * self.throttling_factor)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/concurrent/futures/_base.py", line 458, in result
    raise TimeoutError()
TimeoutError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/data/build/odoo/odoo/tests/common.py", line 1375, in _ws_winddown
    self._websocket_request('Runtime.evaluate', params={'expression': """
  File "/data/build/odoo/odoo/tests/common.py", line 1666, in _websocket_request
    raise TimeoutError(f'{method}({params or ""})')
TimeoutError: Runtime.evaluate({'expression': "\n            ('serviceWorker' in navigator) &&\n                navigator.serviceWorker.getRegistrations().then(\n                    registrations => Promise.all(registrations.map(r => r.unregister()))\n                )\n            ", 'awaitPromise': True})
```

Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres.

Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error.

The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemps to decode it. The `b64decode` function silently discard non-b64 characters and only complain if the final thing lacks the b64 `=` padding (to make the length a multiple of 4).

So when it downloaded something, it downloaded crap.

The thing actually is:

* Binary fields, accept raw bytes, store raw bytes in db.
* Image fields, reject raw bytes, want base64, store base64 in db.

When reading Image fields it is easy: always decode the base64.

For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the beginning.

**Binary-field with non-b64 value** (original fix)

Forward-Port-Of: odoo/odoo#214412
Forward-Port-Of: odoo/odoo#213997

**binary can store raw bytes** (fix of *Binary-field with non-b64 value*)

Forward-Port-Of: odoo/odoo#214915
Forward-Port-Of: odoo/odoo#214758

This PR contains the squashed code of the above two PRs.

Forward-Port-Of: odoo/odoo#253382
Forward-Port-Of: odoo/odoo#249544

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/6626b4649d [REL] 18.3.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/62a1fd4307 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382)
https://github.com/odoo/o-spreadsheet/commit/09873f6c22 [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009)
https://github.com/odoo/o-spreadsheet/commit/4d29b1d901 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296)
https://github.com/odoo/o-spreadsheet/commit/d901f29b3f [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#253625

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Case 1:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment > down payment of 300 is created in SO.
- In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order.

**Issue:**
- The down payment line is added twice in the POS order.

**Root cause:**
- At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order.
- At [2], the down payment line from the SO is added again.
- Here, when `Automatic invoice` is on and we make the online payment
  then `amount_paid` is updated and the downpayment invoice is also created.
- So, we have also downpayment line in sale order also.

**Solution:**
- Ensure that if a downpayment line has already been added to the POS order,
  the first downpayment line matching `amount_paid` is skipped.

[1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93
[2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111

Before:
<img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" />


After:
<img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" />

Case 2:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
-The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice
  is automatically created and amount_paid is also updated.
- At [3], the logic subtracts both the total invoice amount and amount_paid from
  the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to
  an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is
  encountered again, it should be skipped to avoid double-counting.

[3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

How to reproduce :
- Create a product
- Create an attribute with a value set to "free text"
- Add 2 different vendors to the purchase tab of the product with different Vendor Code and/or Vendor Name
- Put Dropship as the route for the product to create a PO on a SO confirmation
- Create a SO with that product
- Confirm the SO and go to the PO
- Change the vendor in the SO

The problem :
The Vendor Code and/or Vendor Name does not change correctly in the product description

Why :
The way the description generation for a change in a purchase order line works as follows : Create a collection of default descriptions based on the product and the different vendors. If the collection contains the current description, it means the description was not changed by the user and it can be modified. This is done to prevent resetting a custom description made by an user.

This logic is pretty broken because the code that generate the description when going from a PO to a SO and the code that generate the description when changing the PO partner are different. This makes it so the current description is almost never found in the list of default descriptions.

It looks tempting to try to "resynchronize" those part of the code so the description generation is the same in both cases. This would be done by overriding the _get_product_purchase_description method in the purchase_stock module and using the product_description_variants field. Sadly, this does not work because it conflicts with the purchase_product_matrix module and its own override of that method.

The fix that I implemented checks that the Vendor Code and Name are the right one every time the description is computed following a change.

opw-5888233

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

In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path.

Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths.

For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive.

This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request.

This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request.

Benchmarks

|No. files in addons path| No. concurrent threads  | Registry loading time Before PR | Registry loading time After PR |
|--------|--------|--------|--------|
| 93447 | 5  | 53.23 s  | 4 s  |



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

Forward-Port-Of: odoo/odoo#254660