Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Forward-Port-Of: odoo/enterprise#124728
Forward-Port-Of: odoo/enterprise#124027

Steps to reproduce:
- install Timesheets
- create an employee for a user in company B
- switch to company A (where the user has no employee)
- the systray icon is hidden even though the user can
create timesheets in company B via the company selector

Current behavior:
the systray only checks the current company for a valid
employee, ignoring other selected companies.

Expected behavior:
the systray should be visible whenever the user can create
timesheets i.e. when they have an active employee in any
of the selected companies.

Issue:
the check used a stored boolean on `res.partner` that has no
company scope and becomes stale when an employee is archived
(the stored dependency does not re-fire). the timesheet
creation logic checks all selected companies for active
employees, but the systray did not mirror that.

Fix:
use `employee_ids` a `One2many` that checks all selected
companies and excludes archived employees, matching the
timesheet creation logic exactly.

task-6330539

Forward-Port-Of: odoo/enterprise#124761
Forward-Port-Of: odoo/enterprise#121730

Steps to reproduce:
---

Case 1:

1. Add a carousel at the top of the page.
2. Apply the parallax effect to all slides.
3. Reload the page and navigate to the second slide without scrolling.
4. Scroll slightly and observe the jump in background position.
5. Scroll back to the top and notice the changed background position.

Case 2:

1. Add a carousel to the page.
2. Apply the parallax effect to each slide.
3. Add text over the carousel and enable animation on appearance and on every time.
4. Slide between images and observe the bouncing effect.


https://github.com/user-attachments/assets/d11ee430-8b95-4903-b001-1b9ba8ee58cd

Why this change?
---

When the parallax effect is applied to carousel slides, only the first slide is initialized with the correct [parallaxHeight](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/parallax/parallax.js#L49). The remaining slides are initialized while hidden, resulting in a computed height of 0. When scrolling, the background height is recalculated with the correct value, producing a visible jump effect.

Additionally, when text or any animated content is added on top of the carousel (especially animations triggered on appearance or on every slide change), a [resize event](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/animation.js#L111) is triggered on each transition. This causes `updateBackgroundHeight()` to run again. Since hidden slides were initialized with height 0 and later receive their actual height, the recalculation produces a noticeable bouncing effect.

After this commit:
---

The parallax computation now relies on the parent element’s `getBoundingClientRect().height` when used inside a carousel. Since the carousel slide height is already defined and consistent, this ensures correct initialization even when the slide is not yet visible.


OPW: 5909351




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

Forward-Port-Of: odoo/odoo#250290

Steps to reproduce
---
1. Install a carrier that requires a positive package shipping weight (e.g. UPS) and enable Packages.
2. From the Barcode app, process a delivery and Put in Pack the products.
3. Validate the transfer.

Issue
---
Validation is refused because the package has no positive shipping weight, even though its computed weight is correct.

The package shipping weight is only set in `_post_put_in_pack_hook` from `context['weight']`, which is filled exclusively by the put in pack wizard. Flows that bypass the wizard, like the Barcode app, never provide that key, so the stored `shipping_weight` stays 0 while carriers reading it directly reject the delivery. The Barcode app suppresses the wizard through the `barcode_view` context, so its put in pack goes straight to the hook without any weight.

https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/stock_barcode/models/stock_move_line.py#L193-L196

This handling was centralized in this hook by 9a2ff6f4033e, so every wizard-bypassed pack leaves the field empty. Defaulting it to the package computed weight via `_get_weight` when the context did not provide one makes the stored value correct for any carrier, independently of the flow that created the package.

https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/stock_delivery/models/stock_move.py#L111-L115

opw-6297689

Forward-Port-Of: odoo/odoo#273876
Forward-Port-Of: odoo/odoo#272510

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#277131
Forward-Port-Of: odoo/odoo#269100

Currently an error is generated when the user clicks on the AI
icon as per the below steps:

- Install `ai_app` 
- Go to `AI` > Configuration > Default Prompts
- Duplicate `Ask AI` record (`ai.composer`)
- An error occurs on clicking the `AI` icon on the navbar menu systray

Error: `ValueError: Expected singleton: ai.composer(4, 14)`

This issue was introduced during the refactoring in [1]. In the previous
implementation, the AI Composer search was executed with `limit=1` (see [2]),
ensuring that only a single composer record was returned. After the changes
in [1], the limit=1 constraint was removed (see [3]), causing the search to
return multiple composer records. As a result, the code now encounters
an error when it expects a single record.

This commit fixes the issue by adding `limit=1` to the AI Composer search,
ensuring that only a single record is returned.


[1]: https://github.com/odoo/enterprise/commit/800208fdc485b9e37f77648a01100b8eff118490
[2]: https://github.com/odoo/enterprise/blob/188dcc5078be7c7fee1a52f86505144d3b6309cf/ai/models/ai_composer.py#L71-L83
[3]: https://github.com/odoo/enterprise/blob/2972805fd1a4daacd7f1c47d5e3c7672e2aec61c/ai/models/ai_composer.py#L74-L77

Sentry-7549108967

Steps to produce:
---
- Install the `Sales` module.
- Go to Invoicing > Configuration > Accounting > Taxes.
- Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the Advanced Options tab.
- Create a sale order with multiple sections, apply the 0% Exports tax to the order lines, and enable `Hide Composition` on one of the sections.
- Preview the sale order.

Issue:
---
- The tax displayed in a collapsed section summary differs from the tax shown on regular order lines for the same tax.

Root cause:
---
- At [1], `_get_grouped_section_summary()` only returns `tax_labels`, which are then used when rendering the collapsed section summary. As a result, the invoice label is displayed instead of the actual tax name.

Solution:
---
- Add `tax_names` to the values returned by `_get_grouped_section_summary()` and use them when rendering the collapsed section summary, ensuring consistent tax information across the preview.
- Also removed the unnecessary fallback in the return statement, as `res` is always populated.

[1]https://github.com/odoo/odoo/blob/be0bf1365e054521ece224f5e3a4b7cbce402315/addons/sale/models/sale_order_line.py#L1572-L1604

Before:
---
<img width="1068" height="156" alt="image" src="https://github.com/user-attachments/assets/8030c35e-5c73-4fed-9feb-c4729add7894" />

After:
---
<img width="1057" height="143" alt="image" src="https://github.com/user-attachments/assets/336030ed-68b2-4d14-b26f-ff391257d6d4" />

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

Forward-Port-Of: odoo/odoo#270544

Steps to reproduce:
---

Case 1:

1. Add a carousel at the top of the page.
2. Apply the parallax effect to all slides.
3. Reload the page and navigate to the second slide without scrolling.
4. Scroll slightly and observe the jump in background position.
5. Scroll back to the top and notice the changed background position.

Case 2:

1. Add a carousel to the page.
2. Apply the parallax effect to each slide.
3. Add text over the carousel and enable animation on appearance and on every time.
4. Slide between images and observe the bouncing effect.


https://github.com/user-attachments/assets/d11ee430-8b95-4903-b001-1b9ba8ee58cd

Why this change?
---

When the parallax effect is applied to carousel slides, only the first slide is initialized with the correct [parallaxHeight](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/parallax/parallax.js#L49). The remaining slides are initialized while hidden, resulting in a computed height of 0. When scrolling, the background height is recalculated with the correct value, producing a visible jump effect.

Additionally, when text or any animated content is added on top of the carousel (especially animations triggered on appearance or on every slide change), a [resize event](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/animation.js#L111) is triggered on each transition. This causes `updateBackgroundHeight()` to run again. Since hidden slides were initialized with height 0 and later receive their actual height, the recalculation produces a noticeable bouncing effect.

After this commit:
---

The parallax computation now relies on the parent element’s `getBoundingClientRect().height` when used inside a carousel. Since the carousel slide height is already defined and consistent, this ensures correct initialization even when the slide is not yet visible.


OPW: 5909351




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

Forward-Port-Of: odoo/odoo#250290

Steps to Reproduce
---
- Create a normal parent task with one normal sub-task and one template sub-task.
- Open the parent task form view and observe the Sub-tasks stat button count and
notebook tab, check the subtask view as well.
- Create a template parent task with one normal sub-task and one template sub-task,
then repeat the same checks.

Issue
---
- Task templates are handled like regular subtasks in the subtask count, notebook, and
subtask view, without taking the parent task type into account.

Current Behaviour
---
- For a normal parent task, both the normal sub-task and the template sub-task are
counted and shown in the opened subtask view and notebook.
- For a template parent task, the same filtering is applied, even though template subtasks
should remain accessible in that context.

Expected Behaviour
---
- For a normal parent task, only real sub-tasks should be counted and shown in the subtask
view and notebook, and on the project kanban card.
- For a template parent task, template subtasks should remain available in the subtask
view and notebook according to the parent template context.
- In the project kanban card, tasks must not be counted when their parent task is a template,
 even if the child task itself is not a template.

Fix
---
- Apply template-aware filtering to subtask counting,project kanban task count and subtask view
 behavior, depending on whether the parent task is a normal task or a template task.

task-5966684

Forward-Port-Of: odoo/odoo#275901
Forward-Port-Of: odoo/odoo#252403

Steps to reproduce
---
1. Install a carrier that requires a positive package shipping weight (e.g. UPS) and enable Packages.
2. From the Barcode app, process a delivery and Put in Pack the products.
3. Validate the transfer.

Issue
---
Validation is refused because the package has no positive shipping weight, even though its computed weight is correct.

The package shipping weight is only set in `_post_put_in_pack_hook` from `context['weight']`, which is filled exclusively by the put in pack wizard. Flows that bypass the wizard, like the Barcode app, never provide that key, so the stored `shipping_weight` stays 0 while carriers reading it directly reject the delivery. The Barcode app suppresses the wizard through the `barcode_view` context, so its put in pack goes straight to the hook without any weight.

https://github.com/odoo/enterprise/blob/6b18215bfa98ef636b63f4fafbba1d25264f4883/stock_barcode/models/stock_move_line.py#L193-L196

This handling was centralized in this hook by 9a2ff6f4033e, so every wizard-bypassed pack leaves the field empty. Defaulting it to the package computed weight via `_get_weight` when the context did not provide one makes the stored value correct for any carrier, independently of the flow that created the package.

https://github.com/odoo/odoo/blob/4235b48c86077bd5bceb9e817cc45b2eec8697e8/addons/stock_delivery/models/stock_move.py#L111-L115

opw-6297689

Forward-Port-Of: odoo/odoo#273876
Forward-Port-Of: odoo/odoo#272510

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Forward-Port-Of: odoo/odoo#277131
Forward-Port-Of: odoo/odoo#269100

### [FIX] web: fix mocked dates in tests

Dates are mocked in all unit tests by default; either to a default static
value, or to one defined in the test/suite. To do so, the `window.Date`
constructor is overridden to have the arguments auto-filled with the current
mock date paramters.

Before this commit, an additional offset was always added to the given
arguments to reflect:
- the time elapsed from the beginning of the test;
- any virtual offset added by a helper such as 'advanceTime'.

The issue is that the spec of the Date constructor wants that the returned date
object has to match all given arguments, and any omitted argument will be
defaulted to the current date/time. This was not the case in tests, as the
offset was always added, regardless of the given arguments.

With this commit: only the arguments that are NOT given and that have been
defaulted to current (mocked) date/time will be offset by the adequate value.
Furthermore: as these mocked parameters are meant to reflect UTC values, the
offset now also considers the *actual* browser offset to generate a local date
from the mock date parameters.

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

Forward-Port-Of: odoo/odoo#277041
Forward-Port-Of: odoo/odoo#275391

Root cause:
WhatsApp reminders are logged as mail.message records on calendar.attendee, which is not a mail.thread. Deleting a calendar event or a partner removes the attendees through the database cascades on calendar.attendee.event_id and calendar.attendee.partner_id, which do not call calendar.attendee.unlink, so each reminder keeps a model and res_id pointing to an attendee that no longer exists.

mail.message access filters the related documents through exists() since https://github.com/odoo/odoo/commit/617d4a32409b730e0fb7d351553e4c6e10bf6c5f, so a reminder whose attendee is gone is no longer readable by anyone but its author or recipient. whatsapp.message.body reads mail.message.body without sudo, so opening WhatsApp > Messages raises an access error on the orphaned reminders, and the queue retry cron hits the same error and stops sending the rest of the queue.

Fix:
Read the related body with sudo. Orphaned messages are not specific to whatsapp, any model that is not a mail.thread keeps its messages after a record is deleted, so cleaning them up is a mail framework concern rather than a whatsapp one. One message the user cannot read should not block the whole message list. Who can read the body stays controlled by the access rights of whatsapp.message itself.

Steps to reproduce:
1. Install WhatsApp and configure an account
2. Create an Appointment Type with a WhatsApp reminder
3. Book an appointment to create the calendar event
4. Settings > Technical > Automation > Scheduled Actions > Calendar: Event Reminder > Run Manually so the reminder is sent
5. Open the calendar event and delete it with the trash icon, not Cancel
6. Open WhatsApp > Messages

=> Access error, the user has no access to the mail.message

Ticket [link](https://www.odoo.com/odoo/project.task/6297099)
opw-6297099

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#124299
Forward-Port-Of: odoo/enterprise#123267

To reproduce the issue:

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

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

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

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

Forward-Port-Of: odoo/enterprise#124144

Steps to reproduce:
1. Install Accounting and create an invoice for a customer which has a due date in the past
2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice.
3. Open the contact form and click on the Customer Statement smart button
4. Exclude the invoice using the 'No Follow-Up' toggle
5. In the Accounting tab in the contact form, click on send
6. Open the internal link of the Content Template, go to the options tab and select
'Print Follow-up Letter' in Dynamic Reports
7. Save the configuration and send the email

Issue:
Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF.

Why this happens:
Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless.

opw-6310602

Forward-Port-Of: odoo/enterprise#124750
Forward-Port-Of: odoo/enterprise#122249

Steps to reproduce:
---

Case 1:

1. Add a carousel at the top of the page.
2. Apply the parallax effect to all slides.
3. Reload the page and navigate to the second slide without scrolling.
4. Scroll slightly and observe the jump in background position.
5. Scroll back to the top and notice the changed background position.

Case 2:

1. Add a carousel to the page.
2. Apply the parallax effect to each slide.
3. Add text over the carousel and enable animation on appearance and on every time.
4. Slide between images and observe the bouncing effect.


https://github.com/user-attachments/assets/d11ee430-8b95-4903-b001-1b9ba8ee58cd

Why this change?
---

When the parallax effect is applied to carousel slides, only the first slide is initialized with the correct [parallaxHeight](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/parallax/parallax.js#L49). The remaining slides are initialized while hidden, resulting in a computed height of 0. When scrolling, the background height is recalculated with the correct value, producing a visible jump effect.

Additionally, when text or any animated content is added on top of the carousel (especially animations triggered on appearance or on every slide change), a [resize event](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/animation.js#L111) is triggered on each transition. This causes `updateBackgroundHeight()` to run again. Since hidden slides were initialized with height 0 and later receive their actual height, the recalculation produces a noticeable bouncing effect.

After this commit:
---

The parallax computation now relies on the parent element’s `getBoundingClientRect().height` when used inside a carousel. Since the carousel slide height is already defined and consistent, this ensures correct initialization even when the slide is not yet visible.


OPW: 5909351




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

Forward-Port-Of: odoo/odoo#250290

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#123729

# How to reproduce
- Have a lot of reusable & locationless packages (e.g. > 10 000)
- Go to any transfer via the barcode application

# The issue
There is a very long loading time, even in local testing. The client of the tickets experiences loadings up to 120 seconds with 50k packages

# Cause
When opening a transfer, we load barcode data by doing an API call to `_get_stock_barcode_data` : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L85

During this we preload a lot of records, notably packages : https://github.com/odoo/enterprise/blob/fe058ef501767b7ed9758fc9264f664b32c6bae8/stock_barcode/models/stock_picking.py#L128

The issue is that in the fields we read for the packages, two of them (`location_dest_id` & `contained_quant_ids`) have a `_read_group` in their compute (or in the compute of one of the fields they depend on) :
https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L65 https://github.com/odoo/odoo/blob/625e6bcbd66c45ea2f699df14e2ea12e2e28a893/addons/stock/models/stock_package.py#L146

Fortunately, this does not mean that we make a query for every records. Instead, in Odoo, we fetch records in batch of 1000.

So, for the case of the client, every time he loads the database, the backend does 50 000 / 1000 x 2 = 100 queries, which hinders performance a lot

A [PERF] commit was done to limit the number of packages that are fetched base on a config parameter. The problem is that this parameter does not have a default value, so clients still end up with the problem.

[PERF]: https://github.com/odoo/enterprise/commit/efe18bc1ea479270e42846986d7ed449b0865617

# Proposed Solution
Add a default value for that config parameter. The exact value is up to discussion

opw-6200730

Forward-Port-Of: odoo/enterprise#123696

To reproduce the issue:

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

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

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

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

Forward-Port-Of: odoo/enterprise#124144

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#124299
Forward-Port-Of: odoo/enterprise#123267

**Problem:**
When a template is restricted to a department, appraisals for employees of that department do not use it — a generic (global) template is used instead.

**Steps to reproduce:**
1. Create an appraisal template and restrict it to a department.
2. Make sure at least one global (no department) template also exists.
3. Open a new appraisal and select an employee of that department.
4. Observe the appraisal template stays on the global one.

**Current behavior:**
The global template that was auto-selected before an employee was chosen is kept, ignoring the department-restricted template.

**Expected behavior:**
The template restricted to the employee's department is selected.

**Cause of the issue:**
On a new appraisal the template is computed before an employee (and therefore a department) is set, so a global template is pre-selected. When the employee is then chosen, `_compute_appraisal_template` reruns but the `appraisal.appraisal_template_id or ...` clause short-circuits on the already set global template and never falls through to the department's template.

**Fix:**
Evaluating the department's template before the existing value ensures a department-restricted template takes precedence over a template that was only auto-selected as a default. The existing value is still preserved when the department has no template of its own, so deliberate choices are untouched.

opw-6293936

Forward-Port-Of: odoo/enterprise#121377

Steps to produce:
---
- Install the `Sales` module.
- Go to Invoicing > Configuration > Accounting > Taxes.
- Open the 0% Exports tax and set a value in the `Label on Invoices.` Field under the Advanced Options tab.
- Create a sale order with multiple sections, apply the 0% Exports tax to the order lines, and enable `Hide Composition` on one of the sections.
- Preview the sale order.

Issue:
---
- The tax displayed in a collapsed section summary differs from the tax shown on regular order lines for the same tax.

Root cause:
---
- At [1], `_get_grouped_section_summary()` only returns `tax_labels`, which are then used when rendering the collapsed section summary. As a result, the invoice label is displayed instead of the actual tax name.

Solution:
---
- Add `tax_names` to the values returned by `_get_grouped_section_summary()` and use them when rendering the collapsed section summary, ensuring consistent tax information across the preview.
- Also removed the unnecessary fallback in the return statement, as `res` is always populated.

[1]https://github.com/odoo/odoo/blob/be0bf1365e054521ece224f5e3a4b7cbce402315/addons/sale/models/sale_order_line.py#L1572-L1604

Before:
---
<img width="1068" height="156" alt="image" src="https://github.com/user-attachments/assets/8030c35e-5c73-4fed-9feb-c4729add7894" />

After:
---
<img width="1057" height="143" alt="image" src="https://github.com/user-attachments/assets/336030ed-68b2-4d14-b26f-ff391257d6d4" />

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

Forward-Port-Of: odoo/odoo#270544

Steps to reproduce:
---

Case 1:

1. Add a carousel at the top of the page.
2. Apply the parallax effect to all slides.
3. Reload the page and navigate to the second slide without scrolling.
4. Scroll slightly and observe the jump in background position.
5. Scroll back to the top and notice the changed background position.

Case 2:

1. Add a carousel to the page.
2. Apply the parallax effect to each slide.
3. Add text over the carousel and enable animation on appearance and on every time.
4. Slide between images and observe the bouncing effect.


https://github.com/user-attachments/assets/d11ee430-8b95-4903-b001-1b9ba8ee58cd

Why this change?
---

When the parallax effect is applied to carousel slides, only the first slide is initialized with the correct [parallaxHeight](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/parallax/parallax.js#L49). The remaining slides are initialized while hidden, resulting in a computed height of 0. When scrolling, the background height is recalculated with the correct value, producing a visible jump effect.

Additionally, when text or any animated content is added on top of the carousel (especially animations triggered on appearance or on every slide change), a [resize event](https://github.com/odoo/odoo/blob/616e82d7b3a53b1facf481e783baed3e99393d3c/addons/website/static/src/interactions/animation.js#L111) is triggered on each transition. This causes `updateBackgroundHeight()` to run again. Since hidden slides were initialized with height 0 and later receive their actual height, the recalculation produces a noticeable bouncing effect.

After this commit:
---

The parallax computation now relies on the parent element’s `getBoundingClientRect().height` when used inside a carousel. Since the carousel slide height is already defined and consistent, this ensures correct initialization even when the slide is not yet visible.


OPW: 5909351




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

Forward-Port-Of: odoo/odoo#250290

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#123729

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#124299
Forward-Port-Of: odoo/enterprise#123267

Issue:
----------------------------------------
There is a fiscal regime where the company is actually an individual but is authorized to generate documents.

Steps to reproduce:
----------------------------------------
- Install "l10n_mx_hr_payroll_account_edi"
- Change the current company fiscal regime to '621'
- Add an VAT of length 13 to the current company
- Add a CURP number on the current company
- In Payroll generate a payslip, validate it
- Post the Journal entry
- On the payslip, click "Generate CFDI"
- An error is returned, saying the Emisor:Curp applies to individuals

Cause:
----------------------------------------
An RFC of length 13 means that the sender is an individual. It's intended with the fiscal regime '621'.

We add the curp number in the CFDI XML only when `self.company_id.partner_id.is_company` is `False`. Since saas-19.1, `is_company` is computed to be truely if a VAT is present. So as soon as the VAT is entered, the CURP number is absent from the XML.

Solution:
----------------------------------------
We change the condition to add the CURP number in the XML: A VAT number of length 13 means the contact is an individual (12 for companies). This is what is used to validate the XML: if the vat is of length 13, then the curp number should be present.

opw-6351558

Forward-Port-Of: odoo/enterprise#124868
Forward-Port-Of: odoo/enterprise#124027

Steps to reproduce:
- install Timesheets
- create an employee for a user in company B
- switch to company A (where the user has no employee)
- the systray icon is hidden even though the user can
create timesheets in company B via the company selector

Current behavior:
the systray only checks the current company for a valid
employee, ignoring other selected companies.

Expected behavior:
the systray should be visible whenever the user can create
timesheets i.e. when they have an active employee in any
of the selected companies.

Issue:
the check used a stored boolean on `res.partner` that has no
company scope and becomes stale when an employee is archived
(the stored dependency does not re-fire). the timesheet
creation logic checks all selected companies for active
employees, but the systray did not mirror that.

Fix:
use `employee_ids` a `One2many` that checks all selected
companies and excludes archived employees, matching the
timesheet creation logic exactly.

task-6330539

Forward-Port-Of: odoo/enterprise#124830
Forward-Port-Of: odoo/enterprise#121730

## Current behavior:
When rescheduling a task in Project's Gantt chart view, if user switches to a different browser tab using the Ctrl shortcuts (either Ctrl + Tab, Ctrl + Shift + Tab or Ctrl + PgUp / PgDn), and navigate back to Gantt chart view, the task will get duplicated unexpectedly when getting dragged around even when the Ctrl button is released

## Expected behavior:
Dropping a task without Ctrl held should reschedule even after a tab switch using the Ctrl shortcuts

## Steps to reproduce:
1. Install `project` module
2. Create a project and switch to Gantt chart view
3. Hold Ctrl and start dragging a task while switching browser tab with Ctrl+Tab, Ctrl+Shift+Tab, or Ctrl+PgUp/PgDn
4. Return to the Gantt tab and drop the task without holding Ctrl
5. The task is duplicated instead of rescheduled

## Cause of the issue:
Copy and reschedule actions are tracked internally via interaction.dragAction, updated only on window keydown/keyup for Control. Currently, we're not keeping track of the `visibilitychange` event when switching tabs, causing the state of `ctrlPressed` to stale after a tab change, causing the dragAction to stay on copy mode

## Fix:
Reset `dragAction` and `ctrlPressed` on document's `visibilitychange` when the tab has been changed

opw-6298440

Marketplace orders with discount lines could not match the
platform total: Odoo accumulated a small rounding residue vs Shopee's
total_amount / Lazada's order price.

sale_shopee
-----------
Changes:
- Fetch buyer-side escrow amounts via `_fetch_order_income` and pass them
  through `self.env.context` (`order_income`).
- Build item lines from the buyer-paid item price with `discount=0` and a
  recomputed tax-exclusive `price_unit`.
- Distribute order-level discounts (seller/platform vouchers and coins) as
  dedicated negative lines per product tax group via
  `_prepare_discount_lines_values`.
- Append a shipping line from `buyer_paid_shipping_fee` with fiscal-position
  mapped taxes.
- Reconcile any leftover residue with `_adjust_order_total` using a single
  tax-free amount-adjustment line.
- Register `default_discount_product` and configure it on upgrade (v1.1).


sale_lazada
-----------
- Port the same reconciliation model as shopee: reconciled line specs, discount=0 with
  discounted unit from paid_price, shipping line from shipping_fee, order-level
  "Discount line" distributed at order-level.

task-6112062

Steps to reproduce:
-------------------
1. Install pos_avatax.
2. Enable Avatax in accounting, and use the testing credentials of Odoo.
3. Enable "Use AvaTax API" and "Detect Automatically" on the default fiscal position (or another fiscal position available in PoS).
4. In a PoS shop, enable "AvaTax PoS Integration"
5. Find a product sell in that PoS, and assign it an "Avatax Category"
6. Open that PoS, add the prodct of step 5, and choose a customer (make sure the fiscal position of step 3 is being used).

Observation: Error modal "Error while loading Avatax taxes", and error
in the terminal `KeyError: 'base_line'`.

Why it's happening:
-------------------
Commit 0404086db567 changed the return of
`_get_line_data_for_external_taxes`. Before, pos was returning something with `id`, `qty`, `price_subtotal` etc. After the commit the return should have a `base_line` key (the accounting base line we get from `_prepare_base_line_for_taxes_computation`).

But that commit forgot to update the override in pos. So when avatax tries to read `line_data['base_line']` we get the KeyError.

The fix:
--------
Update the override in pos to return the new format, same way `sale_external_tax` is already doing it for sale orders.

opw-6244141

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#123729

**Problem:**
When a template is restricted to a department, appraisals for employees of that department do not use it — a generic (global) template is used instead.

**Steps to reproduce:**
1. Create an appraisal template and restrict it to a department.
2. Make sure at least one global (no department) template also exists.
3. Open a new appraisal and select an employee of that department.
4. Observe the appraisal template stays on the global one.

**Current behavior:**
The global template that was auto-selected before an employee was chosen is kept, ignoring the department-restricted template.

**Expected behavior:**
The template restricted to the employee's department is selected.

**Cause of the issue:**
On a new appraisal the template is computed before an employee (and therefore a department) is set, so a global template is pre-selected. When the employee is then chosen, `_compute_appraisal_template` reruns but the `appraisal.appraisal_template_id or ...` clause short-circuits on the already set global template and never falls through to the department's template.

**Fix:**
Evaluating the department's template before the existing value ensures a department-restricted template takes precedence over a template that was only auto-selected as a default. The existing value is still preserved when the department has no template of its own, so deliberate choices are untouched.

opw-6293936

**Steps to reproduce:**
* Configure a Swiss company with the Swiss accounting localization.
* Install `account_sepa`.
* Configure a bank journal with a valid Swiss **QR-IBAN**.
* Create a vendor with a valid Swiss bank account.
* Under **Accounting -> Configuration -> Settings** enable QR Payments.
* Go to the vendor and enter the correct QR-IBAN number under the Accounting Section.
* Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the 
  account number of  QR-IBAN.
* Create and post a vendor payment using the bank journal.
* Set the payment reference (`ref`) to contain the `°` character.
* Add the payment to a batch payment and generate the ISO 20022 payment file.
* Inspect the generated XML.

**Observed Behaviour:**
 The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that 
 may be rejected by Swiss banks because it does not comply with the EPC minimum character set.

**Cause:**
 The QR-IBAN branch validates the structured reference before sanitizing it,
 allowing unsupported characters to remain in the generated XML.

**Fix:**
 Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters 
 are removed while preserving valid QR references.

opw - 6350931

Forward-Port-Of: odoo/enterprise#124299
Forward-Port-Of: odoo/enterprise#123267

To reproduce the issue:

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

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

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

Forward-Port-Of: odoo/enterprise#124811

**Steps to reproduce:**
* Install the **l10n_pe_edi** module.
* Change the company currency to **USD**.
* Configure **Peruvian detraction** settings:
  * Set a **withholding percentage** on a product.
  * Set a **withholding code** on the same product.
* Create a customer invoice in **USD**.
* Set the **Operation Type** to **[1001] Operation Subject to Detraction**.
* Add the configured product to the invoice.
* Confirm the invoice, **send it to SUNAT** by *process now**, and generate the ZIP which has XML.

**Observed behavior:**
* The generated XML contains: `<cbc:Amount currencyID="PEN">116.82</cbc:Amount>` The `currencyID` is `PEN` but the amount is the raw USD value instead of being converted to PEN using the exchange rate.
* The PDF report also shows the withholding amount with the wrong currency symbol.

**Cause:**
* `_l10n_pe_edi_get_spot()` computed `spot['amount']` as `amount_total_signed * percent`, where `amount_total_signed` is stored in the **company currency**. When the company currency is PEN this works correctly, but when it is changed to USD the value is in USD while the XML node hardcodes `currencyID="PEN"`.
* `spot['currency']` was also set to `company_id.currency_id`, so the PDF rendered the amount with the wrong currency symbol.
* In `_add_invoice_payment_terms_nodes`, `spot_amount` was selected via `spot['amount'] if invoice.currency_id == invoice.company_id.currency_id` which relied on company currency being PEN as a proxy for the invoice being in PEN, breaking when company currency is USD.

**Fix:**
* In `_l10n_pe_edi_get_spot()`, compute `spot['amount']` by explicitly converting `amount_total` from the invoice currency to PEN using `currency_id._convert(..., env.ref('base.PEN'), ...)`, ensuring the detraction amount is always in PEN regardless of the company currency.
* Set `spot['currency']` to `env.ref('base.PEN')` so the PDF report always displays the withholding amount with the correct PEN symbol.
* In `_add_invoice_payment_terms_nodes`, always use `spot['spot_amount']` (invoice currency amount) for the `FormaPago`/`Cuota` arithmetic, since `spot['amount']` is now exclusively the PEN amount for the detraction XML node.

opw-6327571

Steps to reproduce:
- Post a Peruvian invoice so it is sent to SUNAT (directly or through Estela/Digiflow).
- SUNAT's sendBill call hangs and Odoo's request times out (ReadTimeout / ConnectionError), even though SUNAT actually finishes registering the document on its side a moment later.
- Odoo retries sending the same invoice (either automatically through the EDI cron, or manually). SUNAT now replies with a "document already exists" SOAP fault (code 1033/4000), since it processed the previous attempt.
- Odoo tries to recover from this by fetching the CDR through getStatusCdr, but SUNAT has not finished generating it yet, so the lookup also fails.

Cause of the issue:
_l10n_pe_edi_post_invoice_web_service() already has recovery logic for error codes 1033/4000: it calls _l10n_pe_edi_retrieve_cdr() to fetch the CDR and treat the invoice as sent. But when that lookup itself fails (CDR not generated yet), the resulting error keeps the 'blocking_level' set to 'error' from the original SOAP fault. Documents with blocking_level 'error' are excluded from the automatic EDI cron retries (see account.edi.document._cron_process_documents_web_services), so the invoice gets stuck needing a manual retry, which can lose the same race against SUNAT again and again.

Solution:
When the CDR can't be retrieved yet after a 1033/4000 duplicate error, mark the result as 'blocking_level': 'warning' instead of leaving it at 'error'. This keeps the invoice eligible for the automatic EDI cron retries, so Odoo keeps polling SUNAT until the CDR becomes available, instead of requiring manual intervention every time this race is lost.

opw-6393231

Issue:
In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to.

Steps to reproduce:
In a multi-company setup, activate only Company B. Open any chatter and attach a file.
Navigate to Settings > Technical > Data Structure > Attachments.

Current behaviour:
The created attachment has its company_id set to the user's default company, rather than the currently active company, or the company of the record, even when the record has a company_id field. This behavior introduces inconsistencies in data visibility, particularly when attachments appear to belong to a company different from the one associated with the related business record.

Behaviour After Fix:
If the related record (i.e., the model the attachment is linked to) contains a company_id field, its value will be used as the attachment's company_id otherwise, the attachment's company_id will be set to the currently active company's id.

This logic ensures proper alignment between attachments and their related business records and also maintaining consistency in multi-company scenarios.

task-4563173


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

Steps to reproduce:
- Go to the Website app and enter Edit mode.
- Drop an 'Embed Code' snippet onto the page.
- Paste an external embed code (e.g., an Instagram iframe or YouTube video).
- Change the alignment of the snippet to 'Center' or 'Right' using the editor options. Observation: The embedded content remains left-aligned regardless of the alignment option selected.

Cause:
Embedded elements (like iframes or injected scripts) do not inherently respect the parent's 'text-align' properties, and standard auto-margins fail if the injected element behaves as an inline block without a defined width.

Solution:
Update '000.scss' to apply Flexbox properties to the '.s_embed_code_embedded' wrapper. By using 'align-items' (center, flex-start, flex-end) corresponding to the parent snippet's alignment classes, the embedded content is forced to respect the chosen UI alignment. Additionally, apply 'max-width: 100%' to child elements to ensure responsiveness and prevent overflow.

opw-5429966