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

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#251025

When vendor bills digitization is deactivated, subscribers to the "Purchases" journal are not notified when a vendor bill is sent to the email alias set on the "Purchases" journal

Steps to reproduce:
1. Install Accounting
2. Go to Settings > Accounting > Digitization and set Vendor Bills to "Do not digitize"
3. Go to Settings > Technical > Email > Alias Domains and create a new alias domain (e.g. "odoo.com")
4. Go to Settings > Technical > Email > Incoming Mail Servers and create a new incoming mail server (e.g. "megu@odoo.com", you may need to setup POP access on your email address and create an app password, see https://support.google.com/mail/answer/7104828)
5. Go to Accounting > Configuration > Journals and open journal "Purchases"
6. Go to Advanced Settings tab and set the Email Alias and the Send Copy To fields (e.g. "megu@odoo.com" for both)
7. Send a mail with an attachment to the email alias set on the "Purchases" journal
8. Go to the previously created incoming mail server and click on Fetch Now
9. Go to Settings > Email > Technical > Emails
10. No email has been sent to the subscriber of the "Purchases" journal

Issue:
`_extend_with_attachments` returns None if the OCR import failed https://github.com/odoo/odoo/blob/b44295bb6ce621ff87cbc96860492650d90d0ad7/addons/account/models/account_document_import_mixin.py#L340-L349 which prevents the call to method `_notify_invoice_subscribers`

Solution:
Send an email regardless of the result of the OCR import

opw-5914096

Forward-Port-Of: odoo/odoo#252442

Problem
------------------------
When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce:
1. Create allocated leave for employee and approve and validate it.
2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect.

Objective
---------------------------
Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable.

Solution
--------------------------
Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created.

Task: 5911074





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

Forward-Port-Of: odoo/odoo#253837
Forward-Port-Of: odoo/odoo#249527

…f uom

**Problem:**
partial cogs are computed incorrectly when 
the uom of the invoice is different than the one 
of the product

**Steps to reproduce:**
-1) created a stored product with category std price perpetual
-2) set a cost of 1 and an on hand quantity of 12
-3) for the invoicing policy select 'delivered quantities'
-4) in the sales tab add the packaging 'pack of 6'
-5) confirm a sale order for 2 packs of 6

Problem A: 
-6a) validate the delivery
-7a) create and confirm an invoice for all the quanity 
-8b) on the delivery create a return for a quantity of 6 and validate
-9b) select 'create invoice' on the sale order
-10b) confirm the credit note

Problem B: 
-6b) change the quantity to 6 units on the delivery
-7b) validate with backorder
-8b) create and confirm an invoice for the delivered quantity
(1 pack of 6)
-9b) validate the back order
-10b) create and confirm an invoice for the remaining (1 pack of 6)

**Current behavior:**
Problem A : 
the cogs lines are : 
- crediting stock valuation of 54$
- debiting expenses of 54$

Problem B: 
the cogs lines are: 
- debiting stock valuation of 24
- crediting expenses of 24

**Expected behavior:**
Problem A:
the cogs lines should be: 
- debiting stock valuation of 6
- crediting expenses of 6

Problem B: 
the cogs lines should be: 
- crediting stock valuation of 6
- debiting expenses of 6

**Cause of the issue:**
Both problems have the same cause.
To compute the price unit for the cogs we call _get_cogs_value()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value, in the computation of the return value:
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L74
- price_unit is computed (in both use cases) using _get_cogs_price_unit
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L68
and is expressed in the uom of the product 
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/stock_move.py#L238-L240
- self.quantity is expressed in the uom of the invoice (pack of 6)
- cogs_qty is computed using _get_cogs_qty()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L66
and is expressed in the uom of the invoices (pack of 6)

Because of this, in both use cases, the computation is incorrect.

**fix:**
we use the uom of the product everywhere because _get_cogs_value()
should return the price unit in the products uom
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L51-L52

opw-5901706

Forward-Port-Of: odoo/odoo#253938
Forward-Port-Of: odoo/odoo#250154

- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.

```sql

Traceback (most recent call last):
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
    delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
    delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
 MemoryError

(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682

Lot_id 11412: delivery_by_lot size = 7420, parents = 3

Lot_id 11753: delivery_by_lot size = 0, parents = 7

Lot_id 12845: delivery_by_lot size = 11, parents = 5

Lot_id 14646: delivery_by_lot size = 12, parents = 2

Lot_id 15801: delivery_by_lot size = 1700, parents = 3

Lot_id 19817: delivery_by_lot size = 0, parents = 4

Lot_id 22370: delivery_by_lot size = 0, parents = 1

Lot_id 25072: delivery_by_lot size = 6827, parents = 2

Lot_id 25134: delivery_by_lot size = 3, parents = 2

Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones

UPG - 3869661
OPW - 5900313

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

Forward-Port-Of: odoo/odoo#248826

# How to reproduce
- Create a BOM for a product
- Create a MO for a set quantity (Exemple: 1) for that product
- Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3)
- Confirm the unbuild
- Go to the stock moves of that unbuild via the smart button

# The problem
3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated

# Why
The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves.

When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected.

This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'.

opw-5915981

opw-5449109

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

Forward-Port-Of: odoo/odoo#254016
Forward-Port-Of: odoo/odoo#248056

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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