### Steps to reproduce:
- Install l10n_bg
- Install the Bulgarian language
- In the Accounting Settings, tick the option "Total amount of invoice in letters"
- Change a contact's language to Bulgarian
- Create an invoice for this partner, select BGN as the currency
- The total should be with a unit in thousands (for example 8500)
- The text transcription of the number substracts 1000: Седем Хиляди И Петстотин = 7500

### Cause:
The class `NumberToWords_BG` is a copy of the library num2cyrillic except for the initialization of the variable `_digits` which specifies three arrays with variants of the numbers (1-9). We do it by copying the index 0, which is the default variant, for the non-different spellings.
 The issue comes from the line `_digits[-1] = [None, 'една', None] + _digits[0][2:]` which have an unneeded `None` which offsets the array by one. So when reading `_digits[-1][8]` we end up with "seven".

### Solution:
Remove the `None`.

opw-4753418

Forward-Port-Of: odoo/odoo#212914

**Description**

The label **"Identification Number"**, displayed in the website checkout form, was not being translated despite being properly marked with `_()` in `portal.py`.

---

**Why the fix**
- When the translatable term was introduced the `.pot` file wasn't updated. By exporting the `.pot` file from the db we are able to update it to make it translatable
---

**Steps to Reproduce**

1. Install the `l10n_latam` module.
2. Create an Argentinian company.
3. Create a new website , add spanish to its languages and assign it to the          Argentinian company.
4. Switch the current user’s **default company** to the Argentinian one.
6. Go to Inventory → Create and publish a new product.
7. On the website:
   - Add the product to the cart.
   - Proceed to checkout.
8. Observe that the **"Identification Number"** field in the address form remains untranslated.

---

**Before**

- The "Identification Number" label appeared only in English and could not be translated.

---

**After**

- It shows up in the translation interface and can be translated into Spanish.

---

Ticket ID: opw-4814341

Forward-Port-Of: odoo/odoo#212947

**Current behavior:**
Using the return & exchange functionality when the product to exchange is a kit's component will not correctly update the SOL `qty_delivered` field upon validation of the exchange (out) picking.

**Expected behavior:**
accurate `qty_delivered`

**Steps to reproduce:**
1. Create a product w/ kit bom like:
* 2 units componentA
* 1 units componentB

2. Sell 1 unit of the kit product, validate delivery

3. Create a return for the 1 unit of componentB and select the exchange option on the wizard

4. Validate the return, then validate the exchange

5. Look at the sale order line `qty_delivered` -> it's 0

**Cause of the issue:**
The exchange picking move doesn't get a `bom_line_id` and thus is not properly aggregated in the computation of qty_delivered when incoming and outgoing quantities are being calculated (wherein these quantities must offset, but can't in this situation).

**Fix:**
When the procurement occurs to create the exchanging move, find the `bom_line_id` by looking at the original sale line's moves' bom's bom lines.

opw-4676609

Forward-Port-Of: odoo/odoo#207955

If you have 2 invoices and 2 dropship picking linked to 1 Dropship Sale Order, and the two dropship have different SVL cost: The 2nd invoice will have incorrect COGS

https://github.com/user-attachments/assets/79f15933-0449-4081-aff0-daa5709889bf

## To reproduce
- Create Product P-DROP:
    * category: AVCO automated
    * Routes: Buy & Dropship
    * Purchase Vendors: Azure Interior @ $10
- Create Sale Order for 1 unit of P-Drop ⇾ Confirm
- Go to Purchase Order ⇾ ensure unit price is $10 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $10**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
    * **COGS value is $10**  (ok)
- In Sale Order, set ordered quantity to 2 units
    * New draft PO should have been created
- Go to New Purchase Order ⇾ set price to $20 ⇾ Confirm
- Receive products ⇾ ensure **valuation is $20**
- Create Vendor Bill (optional) ⇾ Confirm
- Create Invoice ⇾ Confirm
    * COGS should be $20, but they are actually **$16.67** (KO)

---

## Test result without fix
```
2025-06-11 11:25:32,230 29041 ERROR oes_test_17 odoo.addons.stock_dropshipping.tests.test_stockvaluation: FAIL: TestStockValuation.test_dropship_cogs_multiple_invoices
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/stock_dropshipping/tests/test_stockvaluation.py", line 382, in test_dropship_cogs_multiple_invoices
    self.assertEqual(dropship2_cogs_line.balance, -16)
AssertionError: -13.33 != -16
 ```

OPW-4665635

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

Forward-Port-Of: odoo/odoo#213887
Forward-Port-Of: odoo/odoo#213763

If a currency not supported by AsiaPay is selected during payment, the system will crash, resulting in a KeyError. In the `const.py` file at [1], we have already defined the `CURRENCY_MAPPING`. Therefore, if a currency is chosen that is not included in the `CURRENCY_MAPPING`, it will cause a crash during the payment process.

[1]
https://github.com/odoo/odoo/blob/bcaafd941c1b4cae65a71900858894556805762e/addons/payment_asiapay/const.py#L19-L42

**Steps to produce:-**
1. Install `eCommerce`.
2. Set up the `AsiaPay` payment provider, and in the configuration, set the Currencies as `EGP`.
3. Now, go to `Website > Shop` and add the product to the cart.
4. Try to make the `payment` for the cart using `AsiaPay`.

**Error:-**
`KeyError: 'EGP'`

**Solution:-**
- This commit adds a constraint that ensures only currencies defined in `CURRENCY_MAPPING` (from `const.py`) can be selected for the AsiaPay payment provider. If any unsupported currencies are selected, a ValidationError is raised listing the invalid entries.

**Sentry - 6665716944**

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

Forward-Port-Of: odoo/odoo#213496

**Problem**
Given a form with three elements, A, B, and C, where C visibility depends on the content of B, and B visibility depends on the content of A, when form element B becomes visible, even if its content should trigger the visibility of C, C remains hidden.
Since [1], the check of visibility condition for C fails because it is based on a FormData object created before removing the attribute disabled from B. This doesn't work because FormData does not contain information from disabled elements.

**How to reproduce**
1. Add a form snippet on the page
2. Add three new fields to the form
3. Label the fields `fieldA`, `fieldB` and `fieldC`
4. Set `fieldB` to be `visible only if` `fieldA` `Is equal to` `test`
5. Set `fieldC` to be `visible only if` `fieldB` `Is equal to` `test`
6. Save
7. Type `test` in `fieldA` -> `fieldB` becomes visible
8. Type `test` in `fieldB` -> `fieldC` becomes visible
9. Delete `test` from `fieldA` -> both `fieldB` and `fieldC` disappear
10. Type `test` in `fieldA`
11. BUG: `fieldB` appears, contains `test`, but `fieldC` is hidden

**Solution**
A new function `getFormDataIncludingDisabledFields` is added, which generates a `FormData`-like object that includes disabled elements.

[1] odoo@b9b3a60

task-4367641

Forward-Port-Of: odoo/odoo#213643

**Problem:**
When internal transfer operation type has a manadatory destination
in barcode, the transfer can still be validated without destination
location scanned if it's a package

**Steps to reproduce:**
- In settings, enable the "packages" settings
- Navigate to Inventory/Configuration/Warehouse Management/
Operations Types
- Select "Internal Transfers", in the "Barcode App" page for Source
Location, select Mandatory Scan
- for "Destination Location" select "after each product"
- create a new storable product
- Navigate to Inventory/Operations/Physical Inventory
- Create a new line and select stock as the location
- Select your product
- In the package column, create a package and give it a name
- Set a quantity > Apply
- Open the barcode app, select operations and then internal
transfers
- Click on New and then Scan WH-Stock and the package name: PACK

**Current behavior:**
 The validate button is higlighted in green and clickable

**Expected behavior:**
Because we didn't scan a destination location it shouldn't be 
green and clickabel

**Cause of the issue:**

When a package barcode is scanned, when _processBarcode calls
_processPackage 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007
Inside _processPackage 
barcodeData.stopped is set to true (1)
and this.selectedLineVirtualId is set to false (2) 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533
Because of (1) _processBarcode returns here 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011
and doesn't reach the part of the method where _selectLine is called  
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182
(Inside _selectLine the value of selectedLineVirtualId is defined
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274
)

So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is 
false when a package is scanned

When the validate method is called when the user clicks on validate,
the method uses the value of this.selectedLine
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779
Because this.selectedLineVirtualID is false, get selectedLine returns false
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309
So the if condition is false, the method is allowed to run and 
the error notification is not triggered


**Fix:**
After scanning a package there is no selectedLine so we need another
condition


opw-4590345

Forward-Port-Of: odoo/enterprise#87184
Forward-Port-Of: odoo/enterprise#83710

When importing a coda statement, in case of globalisation,
Odoo doesn't take into account the different levels of details.
Instead of that, we keep every lines even if one is already
the sum of each detailed lines.

According to https://febelfin.be/media/pages/publicaties/2023/archief-bankstandaarden/0c9e6e5026-1694763197/standard-coda-2.4-fr.pdf

Chapter 3.1

Transaction type are communicate like that:

- 0 -> simple amount without detailed data
- 1 -> amount as totalised by the customer
	- 5 -> detail of 1
- 2 -> amount as totalised by the bank
	- 6 -> detail of 2, simple amount without detailed data
	- 7 -> detail of 2, simple amount with detailed data
		- 9 -> detail of 7

Let's assume this case:

- 1 line with transaction type == 2, amount == 3000
- 1 line with transaction type == 7, amount == 2000
- 1 line with transaction type == 9, amount == 2000
- 1 line with transaction type == 7, amount == 1000
- 1 line with transaction type == 9, amount == 1000

Currently, Odoo will display lines 1, 2 and 4 in case of
split transactions instead of lines 3 and 5.
In case of not split transactions, Odoo sums up the same lines.

With this commit, we keep trace of last line's transaction type to:

- be able to delete it if it has detailed data, in case of split
  transaction
- to sum up only the relevant lines

opw-4619660
opw-4795349

Forward-Port-Of: odoo/enterprise#87523
Forward-Port-Of: odoo/enterprise#85006

### Steps to reproduce:

- In the settings: Enable `Units of Measure & Packagings`
- Create a storable product with 100 units in stock and an associated packaging such as 'pack of 6'
- Create and confirm a sale order for 5 pack of 6.
> This creates and reserve a delivery for 30 units (5 pack of 6).
- Process the delivery in the barcode app and scan a pack of 6
#### > A new line is created for 1 pack of 6 instead of updating the quantity of the line referring to these packs to 5/30.

### Cause of the issue:

Since the packaging/uom refactoring, packagings are just uoms. Now, scanning the packaging will launch a call of the `_processBarcode` method. During this call, the existing line will not be be found and considered as an appropriate candidate to be updated since the its prodcut_uom is in Unit and the packaging uom is not: https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1710-L1711 As such, there will be no `currentLine` to update and a new line will be created:
https://github.com/odoo/enterprise/blob/bdb3f3d959d6fd56e96e2299823fba6edbb5428c/stock_barcode/static/src/models/barcode_model.js#L1441-L1443

opw-4782296

Forward-Port-Of: odoo/enterprise#86659
Forward-Port-Of: odoo/enterprise#86180

Currently, an error occurs when a user tries to access `paid consultation` or `paid seats` if the booking fees are deleted by the user.

**Steps to Reproduce:**
- Install **appointment_account_payment** module without demo data.
- Delete **Booking Fees** product`from `invoicing->customer->products`
- Click on `Paid Seats` or `Paid Consultation` in the Appointment App.

**Error:**
`ValueError: No record found for unique ID appointment_account_payment.default_booking_product. It may have been deleted.`

**Root Cause:**
After deleting the **Booking Fees**, if user tries to open `Paid Seats` or `Paid Consultation`  the system will try to access id of `appointment_account_payment.default_booking_product` at [1] or [2] causing an error.

[1]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L43

[2]-
https://github.com/odoo/enterprise/blob/a4f68967a9826fac981c1141ece1791a0baf647a/appointment_account_payment/models/templates/appointment_type.py#L56

**Solution:**
This commit prevents error by restricting user from deleting the `Booking Product`.

Sentry-6013528364

Forward-Port-Of: odoo/enterprise#86159

Currently, the issue occurs when opening the achievement **Details** view from the commission report due to missing IDs in the view.

**Steps to reproduce:**
- Install the `sale_commission` module.
- Create and approve a new **Commission Plan**.
- Click the **Commissions** button on the form view.
- From the list view, click the **Details** button for a commission entry.
- Observe the error.

**Error:**
`ValueError: Expected singleton: sale.commission.report()`

Here, an error is triggered because the `action_achievement_detail` method at [1], expects a single `id` on the `sale.commission.report` record. However, when the commission report list loads, the `_table_query` method executes a SQL query - [2].

If any of `era.plan_id`, `u.user_id`, or `era.date_from` are **NULL**, the resulting id becomes `False`, which causes the singleton error when the user tries to open the details view.

[1] - https://github.com/odoo/enterprise/blob/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798/sale_commission/model/commission_plan.py#L174-L175
[2] - https://github.com/odoo/enterprise/blob/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798/sale_commission/report/commission_report.py#L111

This commit produces a valid, non-null ID, preventing the downstream error.

Sentry - 6587805735

Forward-Port-Of: odoo/enterprise#84785