When switching a bank journal to the new SEPA Pain version, existing payments in the batch may lack required data, such as the UETR field.

### Steps to Reproduce

1. Install `l10n_be`, `account_accountant`, and `account_sepa_pain_001_001_09`.
2. In the settings, enable 'SEPA Credit Transfer (SCT)'.
3. Switch to a Belgian company.
4. Set up an IBAN bank account on the bank journal.
5. Ensure a partner has an IBAN bank account defined.
6. Create and confirm an outgoing payment for that partner, setting the payment method to 'SEPA Credit Transfer'.
7. In the Outgoing Payments tab of the bank journal, set the SEPA Pain Version to 'New generic version'.
8. Create a batch payment with the payment you just created.
9. Attempt to validate it.

### Expected Result

The payment should be validated successfully.

### Actual Result

A traceback occurs: `TypeError: Argument must be bytes or unicode, got 'bool'`

### Cause

The payment in the batch was created before the SEPA PAIN version was updated on the bank journal. Consequently, the payment is missing some necessary data (specifically, the UETR field is not set) required for the new SEPA version.


opw-3973374

Forward-Port-Of: odoo/enterprise#67665
Forward-Port-Of: odoo/enterprise#65614

The amount to settle was not shown in the tree view for the older column due to the [domain prepared](https://github.com/odoo/enterprise/blob/17.0/account_reports/models/account_aged_partner_balance.py#L380-L392) for the older column being capped between 30 days, similar to the other columns(1-30, 31-60, etc.) in the Aged Receivable report.

**Step to reproduce:**
 - create an invoice with due date 150 days back
 - open the Aged receivable report and find that invoice
 - The record of `account.move.line` will not be shown in the tree view (Amount to settle)

This patch handle the domain for `period5`.

**Before fix:** 
![Screenshot from 2024-07-18 16-45-10](https://github.com/user-attachments/assets/8b0be875-cc6b-4365-a003-c37781094387)

![Screenshot from 2024-07-18 16-45-28](https://github.com/user-attachments/assets/49b5a875-7fa7-420d-bba4-24bd7098031b)

**After fix:**
![Screenshot from 2024-07-18 16-45-59](https://github.com/user-attachments/assets/b615a080-deb8-4955-8426-a7fe53b02f93)


OPW - 4048535

Forward-Port-Of: odoo/enterprise#66884

**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings**
> How to reproduce:
> - Create a product tracked by lots and set a barcode for this product;
> - Create a receipt for this product, with at least 2 quantities and confirm it;
> - Create a second similar receipt (you can duplicate the first one) and confirm it;
> - Add these two receipt in a new batch and confirm the batch;
> - Go in the Barcode App and open the batch, you should have two lines, one for each picking;
> - Scan the product -> the first line should be selected;
> - Scan a lot -> the lot is set on the first line and its qty is incremented;
> - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue.
> 
> Expected behavior:
When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed.
To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. 

**[FIX] stock_barcode: increment right qty**
> When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity.
That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore.
> 
> How to reproduce:
> - Create a product tracked by lots and set a barcode;
> - Update the quantity on hand for this product like following:
>   - 3x lot1
>   - 3x lot2
>   - 3x lot3
> - Create a delivery for 6x this product and confirm it;
> - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have:
>   - 0/3 lot1, [+3]
>   - 0/3 lot2, [+3]
> - Scan lot1 one time and lot3 three times, you now have:
>   - 3 lot3, [+1]
>   - 1/3 lot1, [+2]
>   - 0/3 lot2, [+3]
> -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity.
> 
> To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity.

task-3688770

Forward-Port-Of: odoo/enterprise#67479
Forward-Port-Of: odoo/enterprise#54589