Thursday, July 10, 2025
4 changes · saas-18.3
Resolved issues and error corrections
This update fixes how Mexican electronic invoices report cuota taxes, such as fuel taxes charged per quantity, so the tax rate, base, and amount are calculated and displayed correctly. It also cleans up related tax tests to make future invoice tax issues easier to diagnose and prevent regressions.
Original PR description
**[FIX] l10n_mx_edi: Fix wrong management of Cuota taxes** Cuota taxes are wrongly reported. For example, a GAZ cuota tax expressed as 4.6555 per quantity has to be reported as TasaOCuota=4.6555 Base=quantity Importe=TasaOCuota * Base Currently, it's reported as: TasaOCuota=abs(tax_amount_currency/base_amount_currency) Base=base_amount_currency Importe is recomputed as TasaOCuota * Base instead of tax_amount_currency task-id: 4761658 **[IMP] l10n_mx_edi: Make test suite a bit less messy** Having a single test testing all taxes combination, testing 100% discount on it + IEPS breakdown and global invoice makes the whole thing difficult to debug. Also, it forces the generation of files that are not always relevant. Forward-Port-Of: odoo/enterprise#89658 Forward-Port-Of: odoo/enterprise#88357
Barcode receipt processing now removes the correct serial-number line when users decrement scanned items. This prevents valid serial numbers from being incorrectly flagged as already used, reducing receiving errors for serialized products.
Original PR description
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines has the lot_name fixed on the first scanned serial_number. So when decrementing the last_line, it will always use the virtual_id of the first serial_number scanned, leading to decrementing the wrong serial number. It starts showing that the next scanned number is already used, because it wasn't properly removed in the first place. opw-4646765 Forward-Port-Of: odoo/enterprise#88829 Forward-Port-Of: odoo/enterprise#88130
Swiss payroll users can once again view and manage employee work permit information in the employee record. This restores important localization data that is heavily used for Swiss HR and payroll processes.
Original PR description
In this PR we reintroduce the work permit fields for the swiss localization, which is heavily used. Forward-Port-Of: odoo/enterprise#89864
Bank reconciliation now avoids incorrectly matching payments when a reference is only partially present in a transaction label. This reduces the risk of linking a bank statement line to the wrong accounting entry, especially for references that look similar such as date-based numbers.
Original PR description
Actually, we are matching to blindly for full matches. We only check if aml.move_name or aml.ref is present in st_line label.
But this cause issues with move names like dates, where you could have :
- move_name = 2025/123
- label contains 2025/1234567
In this case, we don't want to match, as 2025/123 is not perfectly present in the label.
So this commit update the condition so we need now to have a perfect full match between st_line label and aml.ref or aml.move_name.
no-task