Daily updates from Odoo
Wednesday, July 22, 2026
4 changes
1 change
New functionality added to Odoo
Adds the detailed Latvian VAT report attachments needed for domestic, EU, purchase, sales, import, and export transactions. Businesses can now review the supporting transaction breakdowns and export the full tax report package in XML for easier filing and compliance.
Original PR description
This commit adds 4 attachments to the Latvian tax report and an XML export for the tax report (including the attachments). The attachments are the following - PVN 1-I: domestic purchase / import -…
This commit adds 4 attachments to the Latvian tax report
and an XML export for the tax report (including the attachments).
The attachments are the following
- PVN 1-I: domestic purchase / import
- PVN 1-II: EU purchase
- PVN 1-III: domestic sales / export
- PVN 2: EU sale
The attachments give more details for the tax report.
The lines of the attachments are "transactions"
A "transaction" is identified by the move and the transaction type or document type.
The transaction type is given via a tax tag (see community PR).
- PVN 1-I: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
independently of the move
- 'V': All small transactions of a partner in case the total of all their small transactions reaches 150€
- There is max 1 line per partner
- 'T': All small transactions that are not grouped under some 'V' line
- There is max 1 line like this; it has no partner information
- PVN 1-II: transaction type, move
- Small transactions (< 150€) are aggregated separately under transaction types 'V' or 'T'
(like PVN 1-I)
- PVN 1-III: document type, move and line in the main tax report
- All transactions with (document) type 'X' are aggregated on a single line
- Small transactions (< 150€) are aggregated separately under document types 'V' or 'T'
(like PVN 1-I)
- The line in the main tax report is ignored for 'X' and small transactions
- PVN 2: transaction type, move
- No aggregation is performed here
Only account move lines that are tagged with a transaction type (1-I, 1-II, 2)
or a relevant tag for the main report (1-III) are shown in the reports.
The tags `Rep` and `C (car)` only take 40% and 50% respectively of the
base amounts. The tax amount is assumed to be split correctly.
task-4251184
Forward-Port-Of: odoo/enterprise#841353 changes
New functionality added to Odoo
Adds support for Uruguayan electronic e-Resguardos so businesses can issue, submit, store, and print compliant withholding documents directly in Odoo. The feature integrates with the existing Uruware electronic invoicing flow and includes standard withholding setup, automatic calculations, regulatory threshold handling, and document validation.
Original PR description
This PR introduces support for electronic e-Resguardos for Uruguay, fully compliant with DGI regulations and integrated into the existing electronic invoicing flow via Uruware. The implementation is…
This PR introduces support for electronic e-Resguardos for Uruguay, fully compliant with DGI regulations and integrated into the existing electronic invoicing flow via Uruware. The implementation is based on the existing withholding framework from Ecuador, with references to Argentina’s approach, and includes the necessary adaptations to meet Uruguayan legal and functional requirements. Key features included in this PR: - Out-of-the-box availability: once the module is installed, users can create e-Resguardos without additional activation steps. - Base configuration for withholdings: - Common withholding taxes (VAT and IRPF). - New field for DGI Withholding Code on taxes. - Configurable destination and default withholding accounts. - Two main functional flows: - Creation of e-Resguardos from a single vendor bill. - Creation of e-Resguardos with multiple or no invoice references, including proper reference handling in XML depending on payment context. - Automatic calculations of withheld amounts based on selected tax and base. - XML generation and submission through the existing Uruware connection, including reception of validated XML (CAE) and PDF with electronic stamp. - Compliance with the 10,000 UI threshold, enabling users to generate e-Resguardos when required by regulation. - Storage and visualization of XML and PDF directly in Odoo, with printing support. - Comprehensive testing coverage: single and multi-invoice cases, without reference, threshold logic, XML validation, and PDF rendering. This PR lays the foundation for future extensions to additional e-Resguardo types while delivering a complete and compliant solution for the most common withholding scenarios in Uruguay. Task: 4557347
Enhancements to existing features
Payroll batch processing has been optimized so companies can generate and calculate large payroll runs much more quickly. In benchmark testing, a run of 1,000 payslips dropped from about 1 minute 36 seconds to 8.42 seconds, reducing waiting time for payroll teams during busy periods.
Original PR description
## Description This PR improves payroll batch performance around payrun and payslip computation. More details are available on each commit. ## Benchmark Individual benchmarks and reproduction are available on each commit. The following is an aggregate timing for this PR: Running a payroll run for 1,000 payslips went from 1m36s to 8.42s, **11.4x** faster. ## Reference task-6395469
Resolved issues and error corrections
This fix prevents Point of Sale payment flows from getting stuck when real-time device communication fails or when kiosk payments run without a signed-in user. It improves reliability for card payment confirmation and kiosk checkout scenarios.
Original PR description
A change from odoo/enterprise#116705 made the `iot_http_service` try to access the `self_ordering_mode` on the session`, leading to longpolling failure on non-self order as data would be undefined. Also, a mistake in error catching in the longpolling service made it so that an event request thrown would abort directly with the previous one, instead of only the previous one. If websocket was unavailable at the same time, it would result on the PoS getting stuck waiting for confirmation of the payment. In addition, we fixed Six payments in Kiosk, failing because it tryed to access `user.id` where user was `undefined`. task-6391166 Forward-Port-Of: odoo/enterprise#124782