…ed PO

**Steps to reproduce:**
- Create a new product and track by lots
- Add a BOM for this product, setting type to Subcontracting
- Create a PO for the product and confirm it (with the vendor as the subcontractor specified on the BOM)
- With debug enabled: go to Inventory/Operations/Procurement: run scheduler
- Go to Inventory > Reporting > Locations and search for the product note the quant line at the subcontractor location with no lot number
- Return to the PO and recieve, specifying lot number
- Go to Inventory > Reporting > Locations
- Search for the product again

**Current behavior:**
there are now 2 quant lines at the subcontractor location: one with lot and one without lot

**Expected behavior:**
There shouldn't be any visible quant line at the subcontractor location because the quantity and reserved quantity of the product at subcontractor location should both be 0

**Cause of the issue:**
Step 1:
When we confirm the PO, this creates a picking and a stock move (move A) from the sbc location to the stock location.
When _action_assign is run on this move, self._should_bypass_reservation() will return true because the move is subcontract
https://github.com/odoo/odoo/blob/95ed5c75582631c7cc417b000569ff6451cc5006/addons/mrp_subcontracting/models/stock_move.py#L302-L307 so we will not create a quant.
(another move (move B) is also created from Production location to sbc location). However when we open Locations this triggers _clean_reserations() and because should_bypass_reservation() returns false for the sbc location, we will run update_reservation_quantity and create a new quant with a reserve quantity of 1 and no lot_id
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_quant.py#L1167-L1172

Step 2:
Then, when we recieve the products and validate the picking, this will call _action_done() on move A.
which will call synchronize_quant()
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_move_line.py#L690 which will call _update_available_quantity() for a quantity of -1, the location sbc and the lot that we just created in the steps. https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_move_line.py#L712 Inside _update_available_quantity(), the call to _gather() will return the quant that we created in step 1 (even though the existing quant has no lot and we give the lot we created as parameter). https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_quant.py#L1055 So we don't create a new quant but we update the existing one that has no lot.

Step 3:
_action_done() is then called on move B which calls _synchronize_quant() https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_move_line.py#L691 which calls _udpate_available_quantity() for a quantity of 1, the location sbc and the lot created in the steps.
Inside _update_available_quantity(), the call to _gather() will return the quant that we created in step 1.
BUT this time, because the quantity is positive,
the quant will be filtered out
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/models/stock_quant.py#L1056-L1057 so we will create a new quant with a lot_id this time and a quantity of 1.

As a consequence instead of having the quantities zeroed out, we end up with two quants one with a lot and a quantity of 1 and one with no lot and a quantity of -1.

opw-4935822

The system will crash with error when user tries to install module `Barcode`.

**Steps to produce: -**
- Install `Inventory` module.
- `Inventory > configuration > products > Barcode Nomenclatures`.
- Delete the `Default Nomenclature` record.
- Go to settings uncheck `Barcode Scanner` and save settings.
- Now, again `enable' that and save.

**Error: -**
```py
ValueError: External ID not found in the system: barcodes.default_barcode_nomenclature 

ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/stock_barcode/data/data.xml:40, somewhere inside <record id='scale_up_alias_1' model='barcode.rule'>
            <field name='name'>Scale Up Receipt</field>
            <field name='type'>alias</field>
            <field name='pattern'>WH-RECEIPTS</field>
            <field name='alias'>WHIN</field>
            <field name='barcode_nomenclature_id' ref='barcodes.default_barcode_nomenclature'/>
            <field name='sequence'>0</field>
        </record>
```

**Root cause: -**
- At [1], the records use the ref of `default_barcode_nomenclature` which is defined in `barcode` module. So, when the ref is deleted and we are trying to use it then it gives error.

**Solution: -**
- This commit resolves the error by providing a False value for the field, if the reference is missing.

[1] https://github.com/odoo/enterprise/blob/400171c9cebc46ecdd907ada210c65f3bbd2dd66/stock_barcode/data/data.xml#L40-L71

**sentry-6823596992**

Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
  - 0.049216958195 for day 1
  - 0.053418803419 for day 2
- Create an invoice in USD as follows:
    - line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI

Issue: Payment validation will fail with error

Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862

This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.

opw-4750981

Forward-Port-Of: odoo/enterprise#92768

backport of https://github.com/odoo/odoo/commit/b7b987c4077c064fdfdb6b956379455cbdd93de3 on generating ewaybill through irn following traceback is produced

```py
File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 165, in _ewaybill_generate

return self._ewaybill_make_transaction("generate", json_payload)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 157, in _ewaybill_make_transaction

response = self._ewaybill_get_by_consigner(

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 181, in _ewaybill_get_by_consigner

'message': self.DEFAULT_HELP_MESSAGE % 'generated',

~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~

TypeError: unsupported operand type(s) for %: 'LazyGettext' and 'str'
```

In this commit we resolve this issue
opw-5079789


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

[FIX] account_reports: external value check lock date

This commit add the check that protects external values from being edited out of the lock date.
For example when the tax report is submitted, the user is not supposed to modify any external values anymore.

To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow.

Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error.

task-5012442

Previously existing Peppol connections were only switched to `test`. This is not enough and incorrect:
- someone connected in production does not necessarily have a registration on the test network, therefore the database is in an inconsistent state, and calls to the test network are very likely to fail
- if you create a new connection to Peppol on a neutralized database, since the system parameter was not changed, the new connection was on production

After this commit:
- existing connections are switched in `demo` where everything is mocked locally, no call to the network (whether it's `test` or `prod` can happen)
- the system parameter is switched to `test`, therefore new connections will register to the Peppol test network
- Also added some fields on the Edi Proxy User to display the mode of the user, as well as the proxy_type in list view.
(Those records are only accessible in debug already.)

<img width="579" height="333" alt="image" src="https://github.com/user-attachments/assets/87847726-d954-4f68-8336-07771747365f" />

task-none (report from PMAX + WTA)

Forward-Port-Of: odoo/odoo#226435

The system crashes with an error when a user tries to `download the e-Faktur` document.

**Steps to produce:-**
- Install `Accounting` and switch to `ID Company`(with demo data).
- Create a `new invoice` and select customer as `ID Company`.
- Add the product and in `taxes add 11% and 0% (2 non-luxury taxes)` and confirm the invoice.
- Click on gear icon and click on `Download e-Faktur` button.

**Error:-**
`ValueError: ValueError('Expected singleton: account.tax(5, 15)') while
 evaluating 'action = records.download_efaktur()'`

**Root cause:-**
- When more than one non-luxury tax is applied and the e-Faktur document is downloading, the code at [1] expects a single tax record, but multiple non-luxury taxes are found.

**Solution:-**
- Since luxury tax is already excluded from the regular tax computation at [2], I think we can directly sum all non-luxury taxes.

[1]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L52
[2]: https://github.com/odoo/odoo/blob/52aa6231130ea165fdb44e6370ec3e396b7603cc/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L24-L25

**sentry-6837559933**

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