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

Forward-Port-Of: odoo/odoo#232763
Forward-Port-Of: odoo/odoo#230762

…rmation

**Steps to reproduce:**
- Have a self order with the mobile setting (QR menu + self ordering)
- Make a purchase, confirm it in the orders in the regular PoS
- Make another purchase
- The order number did not increase and "Pay X at the counter" is not displayed

**Why the fix:**
Before this commit, on the confirmation page, we displayed the self order's current order, which was not correctly set in the case of a mobile self order.

This is why we had the same order number (tracking_number) on the confirmation page. This is also why we did not display the "Pay X at the counter" part of the page, as the wrong order was chosen.

With the current flow, the selectedOrderUuid was set to null after an rpc call, and was only set back if there was an open order and the current screen was different from confirmation.
In this case, we had neither, because the current screen was confirmation and the function did not return any open order, as they are only considered open if they are older than the order we are currently working with.

So with this, the selectedOrderUuid was set to null, just to stay like this. We then used the fallback in the currentOrder's getter (which works fine with the kiosk but not on mobile, and that's why it only works in kiosk), which gave us the wrong order (the last paid order).

Right now, we do not set the selectedOrderUuid to null in the case where the current screen is the confirmation screen, as this seems to be the only issue we have with it.

I couldn't find a way to test this, as we need to confirm the order from the regular PoS, then go back to the self order
and make another sale.

opw-5112561

**Problem:**
When we have a combo product that has a variant product, if we order it from the Kiosk, all the variants for that product will be displayed. The extra price will also be added, even though it is not specified on the combo definition.

**Steps to reproduce:**
- Create a combo that has a variant product (like aluminium chair) 
- Go to the Kiosk and order said combo
- In the combo page, click on the variant, all the possible variants are displayed

**Why the fix:**
When creating a combo, we should specify which product variant we want, so that only those are displayed on the combo selection page. The way it is done right now, every variant is displayed whether we want them or not, without a way to refrain them from being displayed. After this commit, if the variants are specified on the combo, only
those are displayed in the Kiosk once we click on the combo. If we specify a product that has variants in the combo, all variants will still be displayed when clicking the product in the Kiosk, as it was before.

opw-4924019

Forward-Port-Of: odoo/odoo#219908

Steps to reproduce:
1) Install l10n_es and l10n_es_edi_tbai.
2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list view, select them and send to TicketBAI. 5) The TicketBAI “chain index” is inverted: the newest invoice gets the
   smallest index and the oldest gets the largest. The first invoice in
   the legal/chronological sequence is not index 1.

Current behavior:
- When sending multiple invoices at once, the processing loop uses the batch order as-is, which (from the list view) often arrives in reverse chronological order. The chain index is assigned incrementally based on that order, yielding an inverted chain (newest=1, oldest=N).

Expected behavior:
- The TicketBAI chain index must follow issuance/confirmation chronology: the oldest posted invoice in the batch is index 1, then 2, … up to the newest.

Technical reason:
- `_call_web_service_before_invoice_pdf_render` iterates `invoices_data.items()` without an explicit ordering by confirmation (posting) date. Depending on how the selection is built, items are processed newest-first, so the computed `chain_index` is reversed.

Solution:
- Sort the invoices before sending by posting date (`move.date`) ascending, with fallbacks to `invoice_date` and `create_date`, and a deterministic tiebreaker by `id`. Process sequentially after sorting and keep the per-invoice commit.

 opw-[5072667](https://www.odoo.com/odoo/my-tasks/5072667)


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

Forward-Port-Of: odoo/odoo#229736

**Problem:**
With a valued by lot/SN product,
assigning a partial barcode move line to a new package will trigger 
a lot error when validating even if there is a lot on the line.

**Steps to reproduce:**
- Create product tracked by lot and valued by lot/SN.
- Set on on hand quantity of 100 in stock with a package that 
you create and a lot that you create.
- Create an internal transfer for 100 of this product.
- Mark it as to do.
- Open it in barcode.
- Scan stock.
- Scan the package.
- Edit the line to quantity of 50.
- Scan any other empty package already existing to set 
it as the delivery package.
- Validate.
- On the incomplete transfer widget, also click on validate.

**Current behavior:**
An error 'Lot/Serial number is mandatory for product valuated by lot'
is triggered even though there is a lot on the line.

**Cause of the issue:**
When _assignEmptyPackage() is called to assign the new package, 
it calls shouldsplitline() which returns true because line.qty_done is 
smaller thant line.reserved_uom_qty
https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/stock_barcode/static/src/models/barcode_picking_model.js#L949-52
Therefore, splitLine() is called and a new line is created with
no package and no lot.

Then, when we validate, _action_done() is called on the move which calls
_action_done() on the move lines.
https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock/models/stock_move.py#L2065
In the stock_account override, the error is raised for the line newly created
because it has no lot_id and no lot_name.
https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock_account/models/stock_move_line.py#L90-L91

opw-5028008

Forward-Port-Of: odoo/odoo#231482