**Steps to reproduce:**
- enable automatic accounting
- set dollars as the main currency
- activate euro and set a rate of 10 euro -> 1$
- create a storable product with category fifo/ automated
- create and confirm a PO for 1 unit for 10 euros (no tax)
- validate the receipt
- return the product and validate return
- return the return and validate
- open journal items and search your product

**Current behavior:**
- there is 6 correct lines (those with credit or debit of
1$)
- there is two incorrect extra lines one with credit 9$ and
one with debit 9$

**Expected behavior:**
those two extra lines should not be there

**Cause of the issue:**
those lines are compensation account move lines
for the case where the price of the product returned
is different than the price of the product initially received,
in the cases of:
- a return: compensate the difference.
- the return of a return (our case): de-compensate the difference.

(see PR https://github.com/odoo/odoo/pull/162697 and more specifically
test test_fifo_return_twice_and_bill).
But in this case, the compensation is wrongly triggered because
the difference comes from the fact that the currency is not
taken into account.
https://github.com/odoo/odoo/blob/c89d109c460d51fc90b6b13d5f6bc114c7316e42/addons/purchase_stock/models/stock_move.py#L208

**Fix:**
we use the original svl instead of the PO
because it avoids currency problem.
If we wanted to convert the currency of the PO,
we would need to find the date that was used to convert
the value at the creation of the first svl.
And that date came from _get_currency_convert-date()
https://github.com/odoo/odoo/blob/d3599e70973e27ed17e403cf498f76bd31e9c236/addons/purchase_stock/models/stock_move.py#L97
which can take the date of the last invoice
(if product was invoiced before the move was validated).
https://github.com/odoo/odoo/blob/57c1c510425dcd491c794a0262063db398348640/addons/purchase_stock/models/stock_move.py#L123-L125
We can not use this method because we're doing the
return of a return and if the first return
also has an invoice, the return value
of the method could be the date of this invoice
(which is not the date we're looking for).
Furthermore there is no way to know if the date returned
by _get_currency_convert_date() at the time of the creation
of the first svl is the date of the time of the creation of
the svl or the date of an invoice previously confirmed.


opw-5179239

### 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 the call 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.

opw-5388297

… not being registered

**PROBLEM**
When scanning a barcode for a subcontracting receipt, the lot/serial number field of the "register component" pop-over isn't populated with the serial number of the barcode. This forces the user to enter the serial number by hand. Also if the barcode contains an expiration date, when confirming the pop-over, the expiration date will not be taken into account and will be computed using today's date.

**STEPS**
1. Create a product, with barcode 42248387498744, tracked by SN
2. Create a subcontracting BOM for this product
3. Select the GS1 nomenclature and activate expiration date.
3. Create a SO with this product
4. Go to the barcode app, select the receipt for the SO, scan the barcode 01422483874987441725102321122345.
5. A pop-over should appear to register the component of the product, notice the Lot/Serial number field is empty, forcing the user to enter the number manually.
6. Enter the SN manually and click on "record component", the expiration date will be set to today, instead of taking the expiration date in the GS1 barcode (oct 23 2025).

**CAUSES**
1. In `stock_barcode_mrp_subcontracting/static/src/models/barcode_picking_model.js`, we try to save the line before presenting the pop-over to register component. But because the line is not marked as dirty, the line isn't saved.
2. Subcontracting receipt spawn a pop-over (on the `mrp.production` of the origin move of the receipt)  to register the component of the received product when scanning a barcode. The `lot_producing_id` of this `mrp.production` isn't set.

opw-5033444

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

**Steps to produce:**
- Install the `Accounting` module.
- Enable analytic accounting in settings.
- Create an analytic account (e.g., "test").
- Create a journal entry and assign the analytic account in the analytic
  distribution.
- Post the entry and export it(Make sure `journal items/account` and
  `journal items/analytic distribution` are also included).
- `Archive` the analytic account.
- Import the exported entry `OR` Duplicate the previous created entry.
- Try to post the imported entry.

**Issue:**
- The entry is posted even if the analytic account used in the analytic distribution is inactive.

**Root cause:**
- The `analytic_distribution` field is stored as JSON.
- At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error.

**Solution:**
- Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active.

[1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202

opw-5350980

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