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

**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