Daily updates from Odoo
Monday, June 8, 2026
3 changes · 17.0
Resolved issues and error corrections
This update fixes a bug where untaxed invoice lines were incorrectly inheriting the Datev code from the previous line. The fix ensures that untaxed lines now properly have an empty Datev code, resolving a discrepancy in the Datev export file. This ensures accurate reporting for German tax compliance.
Original PR description
**PROBLEM** Untaxed move lines would take the datev code of the previous line instead of having no datev code like they should. **STEP TO REPRODUCE** 1. On a german company, create an invoice with a line with tax 19% I, and a line that is untaxed (with a non-null price). 2. On the general ledger, generate the datev zip. 3. Unzip, and open the account entries csv, and notice the 2nd line of the invoice as the datev code set to something instead of it being empty (column BU-Schlüssel). opw-6141003
This update resolves an issue where users without write access to invoice sequences would receive an error when generating global invoices in the Point of Sale (PoS) module. The fix ensures that invoices can be generated correctly, even if the user doesn't have direct write permissions to the underlying sequence, improving the user experience for Mexican CFDI invoicing.
Original PR description
When generating a global invoice, if the user has no write access to the sequence, an access error is triggered even though he can generate the invoice correctly. Steps to reproduce: ------------------- * Create some order in the PoS * Try to generate the global invoice with Marc Demo > Observation: You get an access error. * Create an invoice with CFDI to public checked * Add any product and validate the invoice * Try to generate the global invoice with Marc Demo > Observation: You get an access error. opw-6041291
This update resolves an issue where international UPS shipments were failing due to incorrect commercial invoice addresses. The fix now uses the delivery address for the invoice, but a fallback mechanism is in place to handle country mismatches, along with a user warning to ensure accuracy. This ensures compliant UPS shipments and avoids delivery delays.
Original PR description
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- -…
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- - Create a belgian company - Setup UPS - Create a French customer - Add a different french delivery address - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > Commercial invoice `Sold To` uses the delivery address Solution for case 1 ----- Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases... Problematic case 2 (caused by case 1 fix) ----- - Create a belgian company - Setup UPS - Create a French customer - Add a delivery address in Switzerland - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.` Solution for case 2 ----- Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO). Warning looks like this (on SO): <img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" /> ----- Ticket: opw-6200263