**Description of the issue/feature this PR addresses:**
This PR adds the AFIP document type 110 - CREDIT NOTE TICKET, which is required for the Argentinian localization

**Current behavior before PR:**
When users in Argentina tried to create a credit note for a ticket, the corresponding document type was not available as an option.

**Desired behavior after PR is merged:**
After this change, users can now select "110 - CREDIT NOTE TICKET" to issue the document correctly.

[HERE](https://app.screencastify.com/watch/fVBWwSD6DAcodKO57qUZ) is a video replicating the issue
1) In localization Argentina, check document types and see that 110 CREDIT NOTE TICKET exists
2) Create a new journal as shown in the video
3) Create an invoice selecting that journal, and (83) TICKET as Document Type
4) Confirm the invoice and try to create a credit note. See that (110) CREDIT NOTE TICKET does not appear as an option

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

Self-billed invoices are invoices which are created by the customer on behalf of the vendor. These can be used in certain business flows, typically when the customer needs to create an invoice internally for accounting purposes.

Peppol provides the ability for customers to send self-billed invoices to the vendor over the Peppol network. This way the vendor can verify whether the invoice is correct.

See the Peppol documentation at https://docs.peppol.eu/poacc/self-billing/3.0/bis-sb/

#### This PR provides
(1) the ability to export vendor bills as self-billed invoices conformant to the BIS3 standard
(2) the ability to import BIS3 self-billed invoices as customer invoices
(3) the ability to send vendor bills as self-billed invoices over Peppol
(4) the ability to receive self-billed invoices from Peppol in a specified Sales journal.

#### Configuration
Purchase journals now have a `Is Self Billing` boolean field. Self-billing journals have a per-partner sequence, and can send vendor bills as self-billing invoices via Peppol if the option is activated in the Peppol configuration.

We also add the self-billed invoice Peppol document type IDs in the list of documents which the user can select or deselect to allow/prevent reception of those document types.

Backport of https://github.com/odoo/odoo/pull/222658

Enterprise PR: https://github.com/odoo/enterprise/pull/97803
Upgrade PR: https://github.com/odoo/upgrade/pull/8886

task-5153851

Problem:
When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

## How to reproduce:
- Enable Wave transfert in setting
- Go to the Receipt Operation type:
    - Create Backorder: always
    - Automatic Batches: Enabled
    - Wave Grouping: Products
- Create and confirm (don't validate) 2 Receipts for 10 units of a storable product P
- The 2 receipt should have been added to a new wave transfer with 2 lines for P
- On the first line, set the quantity to 0
- On the second line, set the quantity to 1
- Try to validate the wave transfer ==>> UserError "The following transfers cannot be added to batch transfer WAVE/XXXX. Please check their states and operation types."

## Issue:
Backorders are generated before the current batch is marked 'done' (it waits for empty pickings to be detached). The auto-batch logic incorrectly identifies the current 'in_progress' batch as a candidate for the new backorders, attempting a merge that violates validation constraints.

## Solution:
Exclude the current wave/batch from the auto_wave search domain using a context variable passed during validation.

OPW-5413921

---

Test result before fix:
```
2026-01-13 10:37:26,541 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: Starting TestAutoWaving.test_auto_wave_skip_current_batch ... 
2026-01-13 10:37:26,820 27952 INFO oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ====================================================================== 
2026-01-13 10:37:26,820 27952 ERROR oes_test_18.0 odoo.addons.stock_picking_batch.tests.test_auto_waving: ERROR: TestAutoWaving.test_auto_wave_skip_current_batch
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/tests/test_auto_waving.py", line 440, in test_auto_wave_skip_current_batch
    wave.action_done()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 264, in action_done
    return pickings.with_context(**context).button_validate()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 145, in button_validate
    res = super().button_validate()
          ^^^^^^^^^^^^^^^^^^^^^^^^^
...
  File "/home/odoo/Odoo/src/18.0/odoo/odoo/fields.py", line 1418, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking.py", line 112, in write
    self.batch_id._sanity_check()
  File "/home/odoo/Odoo/src/18.0/odoo/addons/stock_picking_batch/models/stock_picking_batch.py", line 323, in _sanity_check
    raise UserError(_(
odoo.exceptions.UserError: The following transfers cannot be added to batch transfer WAVE/00012. Please check their states and operation types.
```

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

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

**For r+: Needs a few changes at 18.0 (hours per day of employee is retrieved differently for example)**

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error, the call of the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

### Note:

We had to also adapt this line in 18.0+:
https://github.com/odoo/enterprise/blob/e04ecb45cc99f74e9956a0c1e669bb2c05816fde/stock_barcode/static/src/models/barcode_picking_model.js#L921-L925
Since the wrapper is equivalent to itself while `super.validate()`  calls the `_validate` of the `BarcodeModel` and not of the 
`BarcodePickingModel`  and since we need to bypass the regular validate  call to avoid an infinite loop:
https://github.com/odoo/enterprise/blob/6b0585d2776392c32b190f6e77761d805da49802/stock_barcode/static/src/models/barcode_picking_model.js#L931-L935

opw-5388297

Forward-Port-Of: odoo/enterprise#103835