### Reproduction Steps

1. Install `knowledge`, `spreadsheet`, and `planning` modules
2. In the knowledge app on an admin account, ensure an article is publicly available and invite a portal user
3. Log in as the portal user and attempt to print/export the article
4. Also attempt to print/export the same article from the public (unauthenticated) view

**Result**:

* As a portal user: a blank page is displayed instead of the article.
* As a public user: a blank page is also displayed instead of the article.

### Root Cause

The blank print issue comes from multiple problems with CSS asset loading in print mode:

1. **Spreadsheet Conflict (Portal View)**
   The spreadsheet module’s print styles were incorrectly included in the `web.assets_backend` bundle, causing conflicts. These styles are already properly loaded through `spreadsheet.assets_print` and shouldn’t be duplicated in the backend.

2. **Missing Print Assets (Portal View)**
   The knowledge portal template was missing the `web.assets_web_print` bundle, which contains the core print styles needed for proper article formatting.

3. **Planning Conflict (Public View)**
   The planning module’s print styles in the `web.assets_frontend` bundle were globally hiding elements, conflicting with the display of knowledge articles.

4. **Missing CSS rules (Public View)**
   The public knowledge templates were also missing specific CSS rules required for proper article rendering in print mode.

### Fix

This PR fixes problems 2, 3 and 4 by:

* Removing the unused/irrelevant planning print styles
* Ensuring `web.assets_web_print` is loaded in portal
* Creating a new print bundle for the frontend view
* Hiding the knowledge header in the public view when printing (to improve layout)


The first issue is tackled in odoo/odoo#223434

opw-4816241

Forward-Port-Of: odoo/enterprise#96656
Forward-Port-Of: odoo/enterprise#92665

Description of the issue/feature this PR addresses:
When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. 

<img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" />

Each reconnect attempt causes a log entry: 
```
2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 
2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Lead/Opportunity, Modern Open Space (crm.lead: 25)

Blame the following rules:
- Personal Leads

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. 

```



Current behavior before PR:
Reconnect loop.

Desired behavior after PR is merged:
Do not add channels without sufficient rights.


Related to: https://www.odoo.com/de_DE/my/tasks/5026412

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

Forward-Port-Of: odoo/odoo#231599
Forward-Port-Of: odoo/odoo#223890

## Steps to reproduce

### Bug 1
1. Create a bill receipt
2. Add deferred dates
3. They're reset to False

### Bug 2
1. Create a bill
2. Set the deferred dates
3. Switch to receipt type
4. Confirm
5. The account of the generated deferral entries is incorrect

## Fix

While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value.

In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates.

In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator.

For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account.

opw-5129561

Forward-Port-Of: odoo/enterprise#97824
Forward-Port-Of: odoo/enterprise#97653

…xported pdf

#### Issue
In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name.

#### Step to reproduce:
- Create an account group (e.g Group_101 from 101 to 101)
- Create some AML in an account related to the previously created group (e.g. in 101501 Cash)
- Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance )
- In the Options select "Hierarchy and subtotals"
- Add a filter including your group name (e.g. Group_101)
- Export to pdf

#### Current behavior:
- No lines are displayed in the pdf as the backend uses only the account name to apply the filter

#### Expected behavior:
- Lines are displayed using account name and group name to filter

#### Cause:
- Filter was applied only on account name

#### Solution:
- If hierarchy is enabled, display accounts where filter appears on either account or group

opw-4906593

Forward-Port-Of: odoo/enterprise#96338
Forward-Port-Of: odoo/enterprise#90403

Description of the issue/feature this PR addresses:
When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. 

<img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" />

Each reconnect attempt causes a log entry: 
```
2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 
2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Marc Demo (id=6) doesn't have 'write' access to:
- Lead/Opportunity, Modern Open Space (crm.lead: 25)

Blame the following rules:
- Personal Leads

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. 

```



Current behavior before PR:
Reconnect loop.

Desired behavior after PR is merged:
Do not add channels without sufficient rights.


Related to: https://www.odoo.com/de_DE/my/tasks/5026412

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

Forward-Port-Of: odoo/odoo#231599
Forward-Port-Of: odoo/odoo#223890

Cherry pick of two commits from 18.4

Commit 1: 379d324

Previously, the link popover did not support frontend website pages
(e.g., /contactus, /shop, etc.).

Steps to reproduce:
- Enter edit mode.
- Click on a link to a frontend page, such as "Contact Us".
- An error was thrown in the browser console.
- Also, the link popover did not show the page description (even if it
  existed).

This commit:
- Fixes the error that occurred in the browser console.
- Adds support for frontend website pages in the link popover.
- Displays the page description in the linkpopover, if available.
  (The page description refers to the SEO field that can be set via:
  Site > This Page > Optimize SEO > Description)

Commit 2: b8908f3

Before this commit: the condition to check if an url is internal is not complete
as the user could user the odoo instance domain instead of the real domain. The
check if an internal url is a frontend one is rather naive as there are cases
where the url ends with a number but actually not leading to a record.

Reproduction for the second use case:
1. create a link with frontend url for example `/shop/category/16`
2. click on the link, when it loads the preview, a warning pops up

After this commit, the cases explained above are included.

task-4971829



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

Forward-Port-Of: odoo/odoo#232537

The system crashes when a user tries to edit a website form field and that field has already been deleted from the model.

**Steps to produce:-**
- Install the `website` module.
- Create a `new custom field` on a model(for example, a field on the `mail.mail` model).
- Website > edit > `add Form` widget to a page, and configure it to use the `mail.mail` model.
- Add the newly created custom field to the form and save the page.
- Now, `delete` the custom field which is created previously.
- Return to the website page > edit > mark the deleted field as required, and attempt to save the changes.

**Error:-**
`ValueError: Unable to whitelist field(s) [''] for model 'mail.mail'.`

**Root cause:-**
- At [1], we can see that in the current version, it `only logs an error` using the logger, but in later versions, it `raises a ValueError` instead.

**Solution:-**
- This fix prevents a field from being deleted if it is actively used in any website form.
- It adds a validation check that blocks the deletion and raises an error, forcing the user to remove the field from the form first.

[1]: https://github.com/odoo/odoo/blob/d4f424d731fa93ccd232d0def0a7612997345ef7/addons/website/models/website_form.py#L123-L126

**sentry-5689731444**

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

Forward-Port-Of: odoo/odoo#219590

Currently, when a user uses the 'Set Account' button to reconcile a
statement line, the system may also create a reconciliation model
for fees for the given journal/account combination, based on the
previous statement line reference pattern.

To extract a patter from the references, the system computes the
normalised longest common substring. This will be used as regex
matching pattern of the newly created reconciliation rule.

However, the common substring may end up with '\\', which is not a valid
termination of a regex, leading to the error:
`Invalid operation. The regex is invalid.`

Steps to reproduce:

- Have an account '646000 Test Account'
- Create a Bank statement with label 'TEST REFERENCE BNK 2024'
- Set Account 646000
- Create a Bank statement with label 'TEST REFERENCE BNK.OTHER'
- Set Account 646000

Issue:

Error `Invalid operation. The regex is invalid.` will raise
blocking the action

[opw-5086638](https://www.odoo.com/odoo/project.task/5086638)
[opw-5062965](https://www.odoo.com/odoo/project.task/5062965)
[opw-5123963](https://www.odoo.com/odoo/project.task/5123963)
[opw-5166160](https://www.odoo.com/odoo/project.task//5166160)
[opw-5159871](https://www.odoo.com/odoo/project.task/5159871)
[opw-5160108](https://www.odoo.com/odoo/project.task/5160108)
[opw-5109454](https://www.odoo.com/odoo/project.task/5109454)
[opw-5086638](https://www.odoo.com/odoo/project.task/5086638)
...

Steps to reproduce:
===================
1. Add a meeting product to the cart with the "Rental" option checked.
2. Go to the cart and change the date range. → The cart layout shifts to the left, and quantity buttons become unclickable.

Cause:
======
Two separate issues caused this behavior:

1. **Layout shift:** When updating the date range, `cart_quantity` can be undefined. The logic that determines whether to toggle the `col-lg-7` class relies on this value. When undefined, it incorrectly assumes the cart is empty and shifts the layout to the left.

2. **Unclickable buttons:** The following line replaces the entire `.js_cart_lines` element: https://github.com/odoo/odoo/blob/abf9bc083c5a219a0b6fc0346dcd2a2cb503e081/addons/website_sale/static/src/js/website_sale_utils.js#L88 This removes all old elements (and their event listeners) and inserts new ones from the server. As a result, interactive buttons (e.g., quantity update) lose their functionality.

Older versions didn't face this issue because they used jQuery event delegation, which automatically handled dynamic elements.

Solution:
=========
1. Use a reliable check for cart emptiness by falling back on `data['website_sale.total']` when `cart_quantity` is undefined,
2. Restart the cart interaction after re-rendering to restore event bindings for clickable buttons.

opw-5167866

related : https://github.com/odoo/enterprise/pull/97715

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

…xported pdf

#### Issue
In the Trial Balance when using a filter if hierarchy is enabled, the exported report filters only on the account name, not on the group name.

#### Step to reproduce:
- Create an account group (e.g Group_101 from 101 to 101)
- Create some AML in an account related to the previously created group (e.g. in 101501 Cash)
- Go to the Trial Balance ( Accounting > Reports > Audit Reports > Trial balance )
- In the Options select "Hierarchy and subtotals"
- Add a filter including your group name (e.g. Group_101)
- Export to pdf

#### Current behavior:
- No lines are displayed in the pdf as the backend uses only the account name to apply the filter

#### Expected behavior:
- Lines are displayed using account name and group name to filter

#### Cause:
- Filter was applied only on account name

#### Solution:
- If hierarchy is enabled, display accounts where filter appears on either account or group

opw-4906593

Forward-Port-Of: odoo/enterprise#96338
Forward-Port-Of: odoo/enterprise#90403

| saas-18.4 and above | This PR |
|--------|--------|
| <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img width="437" height="392" alt="image" src="https://github.com/user-attachments/assets/b6896545-34b5-4816-a35f-5c2605d4153b" /> | 

Prior to Commit[^1], the front-end badges using `.badge.o_tag` were receiving a `12px` font size, which came from a rule defined in portal. This looked fine, although odd, since a style from portal was affecting the entire front end.

After Commit[^1], this rule no longer exists, meaning that `.o_tag` now falls back to `0.875rem` (14px by default), while standard badges use a default font size of `0.75em` (12px by default)

Since using `.badge.o_tag` never allowed overriding the `font-size` value, we fixed the issue by assigning the `--badge-font-size` CSS variable directly to the badge definition, ensuring the correct visual result.

task-4900376

[^1]: https://github.com/odoo/odoo/commit/8f8a370a84d136f3d2316eb1a55c7168b7ae6ccf#diff-23677f06a9aaf2e3395e957cfb9580ce6fcc9aba2635b560fe8f15fa27707313L29
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#230530

## Steps to reproduce

### Bug 1
1. Create a bill receipt
2. Add deferred dates
3. They're reset to False

### Bug 2
1. Create a bill
2. Set the deferred dates
3. Switch to receipt type
4. Confirm
5. The account of the generated deferral entries is incorrect

## Fix

While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value.

In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates.

In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator.

For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account.

opw-5129561

Forward-Port-Of: odoo/enterprise#97824
Forward-Port-Of: odoo/enterprise#97653

Issue
-----
After splitting a MO, the linked delivery's quantity only gets updated when the original MO is validated. Validating the backorder MOs doesn't affect the shown quantity.

Steps to reproduce
-----
- Unarchive MTO route
- Create a stored product
	- Routes MTO & Manufacturing
	- Empty BoM
- Create a Sale Order for 3 units of the product & confirm it
- Go to the linked MO and split it in 2 (quants of 1 and 2)
- Confirm both MOs (and produce)
- Go to the sale's delivery
> The delivery's move only shows 1 unit of the product

Why the move quantity is only 1
-----
After confirming the first of the 2 backorder productions, when we manufacture the product, we go through

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/mrp/models/mrp_production.py#L2054

Since the first backorder kept the existing move, it has the delivery move in `move_dest_ids` so we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

Which creates a SML for the delivery move when reserving it

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1853-L1858

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L1950-L1971

This in turn triggers the computation of the move's quantity since it depends on the move's lines

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L382-L383

Our move ends up with a quantity of 1.

When we proceed with the second MO, things are a little different since there is nothing in `moves_todo.move_dest_ids` when we do

https://github.com/odoo/odoo/blob/e6b87a2a37b4550faf60a77981c533d19aa054d4/addons/stock/models/stock_move.py#L2088-L2091

This means we don't create a new SML for the delivery move, so the quantity stays at 1.

Why there is no move_dest_id
-----
When splitting the production, we go through

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1815-L1829

We create new a MO and SM for the backorder. The SM is created here

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1894-L1915

When preparing the values, we correctly copy the `move_dest_ids` of the original MO's SM, see

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/stock_move.py#L646-L656

So when the backorder is created, its' SM has a correct `move_dest_ids`. The problem actually comes from what happens after `_split_productions` in `action_split` when we set the `date_start`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/wizard/mrp_production_split.py#L68-L78

In the write, we get to a line where we access the production's state

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L931

This triggers a recompute of the field.

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L539-L552

In the compute, we access `move_finished_ids`, which again triggers a recompute. In this compute, we call `_create_update_move_finished`

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L800

The problem is that the move we create gets its' `move_dest_ids` from the MO instead of using the one populated using `group_orders` (098af2f).

https://github.com/odoo/odoo/blob/bc22cf5a225a4e7d58548a8d6dedbcd84d771acb/addons/mrp/models/mrp_production.py#L1142-L1167

-----
Ticket:
opw-4865082

## Issue:
When a lot has remaining quantity not included in the landed cost’s moves, the resulting `stock.valuation.layer` amounts are incorrect
Even though `compute_landed_cost()` provides the correct base values

## Cause:
The cost repartition used `lot_id.quantity_svl` that's the total quantity of the lot , which leads to an incorrect ratio when only part of the lot is impacted
As a result, the landed cost amount can be overstated, depending on the difference between the lot's total remaining_qty and the move's remaining_qty
This logic only works when all `stock.valuation.layer` of the lot are involved, which is not always the case
https://github.com/odoo/odoo/blob/e72b25fffc8f07c51e9a72fe6310e8dd046da793/addons/stock_landed_costs/models/stock_landed_cost.py#L125-L142

## Steps to reproduce:
- Enable Lots & Serial Numbers in Settings
- Create a product (Tracked by lot + Valuated by Lot + AVCO)
- Create and validate two receipts for the same product and lot
- Open Inventory > Products > Lots / Serial Numbers page of Inventory and select your lot (The cost should be 0)
- Add Landed Costs for the first receipt
- Add a line for a cost of 100$ and compute (You’ll see that one line with 100$ should be added)
- Confirm the Landed Cost and click Valuation (The value of the line is doubled to 200$)
- On the Lot/Serial Number page of your lot, the cost is also double that the expected value

opw-5128570

Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.

Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.

This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.

This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.

Description of the issue/feature this PR addresses:
In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively.
In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners.

With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers.

Current behavior before PR:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers

Desired behavior after PR is merged:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected.


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

Forward-Port-Of: odoo/odoo#228635

Steps to Reproduce:
-------------------------
1. Install the Website and Employees modules.
2. Create a Test User and It's Employee.
3. On the Employee record, go to Private Information, create a Bank Account
with a custom Account Holder Name.
4. Log in to the Website using the Test User.
5. Navigate to My Account and click Edit Information.
6. Fill in the address details (without changing the Name) and click Save.
7. Go back to the Employee’s Bank Account and check the Account Holder Name.

Observation:
-------------------------
The Account Holder Name was overwritten to the partner's name.

Issue:
-------------------------
In `_compute_account_holder_name` method,
https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107
The Account Holder Name is always recomputed using the Partner’s name.
When submitting the form from the frontend, the name field is included in the
values sent to update the Partner, even if the user did not actually change
the name.
https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205
which re-triggers this compute and as a result, the Partner’s name overwrites
the Account Holder Name on the linked Bank Account

Solution:
 -------------------------
Prevent the Account Holder Name compute method from being triggered when
updating information from the frontend if the Partner’s name has not been
changed.


opw-5059247

**Current behavior:**
The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report.

**Expected behavior:**
Same values

**Steps to reproduce:**
1. Make a workcenter and a BoM with an operation performed at the workcenter

2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration)
* example: 0:20 expected, 1:01 actual

3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different

**Cause of the issue:**
the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values.

**Fix:**
Don't use the rounded intermediary values in computing `oee`.

Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value).

opw-4795463

**PROBLEM**
When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation.

**STEP TO REPRODUCE**
1. create a BoM of product with 3 or more operations
2. Create a Manufacturing order for i.e. 10 unit
3. Open shop floor
4. Register the production in shopfloor:
- Op1 – 10 units registered
- Op2 – 7 units registered
- Op3 – 5 units registered

5. At the end, a backorder is created for 5 units.
6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step.

**CAUSE**
When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order.

**FIX**
We should pass `qty_production` instead which is the quantity to produce for the specific step.

opw-5011739

Description of the issue/feature this PR addresses:
In this [commit](https://github.com/odoo/odoo/commit/5c07f9c0c1065d88022dc6d1299fec1d42dfc0af) we split 'Proveedor del Exterior' from 'Cliente del Exterior' which are both AFIP responsabilities for foreing supplier and customer respectively.
In this [commit](https://github.com/odoo/odoo/commit/7e45c6ec768950b6296d991a8375577aed45c4dd), we added the possibility to create 'B' invoices for foreign partners.

With this PR we are fixing the logic to suggest the correct document type for foreign vendor bills so it has a similar behavior as for customers.

Current behavior before PR:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for Foreign Customers but 'B Invoices' for Foreign Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be 'INVOICES AND RECEIPTS FROM ABROAD' for Foreign Customers and 'B Invoices' for Foreign Suppliers

Desired behavior after PR is merged:
In customer invoices the document type suggested by default depends on the journal:
--> Expo journal will suggest 'Expo invoices' for both Foreign Customers and Suppliers
--> Local electronic journal  will suggest 'B Invoices' for Foreign Customers as well as for Foreign Suppliers

In vendor bills the document type suggested by default will be always 'INVOICES AND RECEIPTS FROM ABROAD' as expected.


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

Forward-Port-Of: odoo/odoo#228635

### Steps to reproduce:
- Install l10n_es_edi_verifactu and switch too Spanish company
- Create an invoice, add a nonzero product and Confirm
- Select "Reverse" to create a credit note
- Confirm the credit note
- Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm
- An error appears that takes the user to the failed record
- Navigate to Accounting > Customers > Credit Notes
- Select the credit note created and at least one other credit note, then select "Send"
- Navigate to Settings > Technical > Scheduled Actions
- Click into the "Send Invoices Automatically" record, then select "Run Manually"
	- Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs
	- Version 18.0 and lower: The scheduled action fails, but an error message does appear

### Cause:
When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent.

### Solution:
The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error.

So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there.
We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed.


opw-5091347