Daily updates from Odoo
Friday, December 20, 2024
10 changes
1 change
Resolved issues and error corrections
Point of Sale now includes lot and serial number information for products stored in sub-locations. This helps staff select the correct tracked products during sales and reduces stock visibility issues.
Original PR description
Also display lot/serial numbers products that are located in sub-locations. opw: 4415220 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Resolved issues and error corrections
This fix prevents accounting reports from crashing when users select multiple companies that use different currencies. It ensures date values are handled consistently so reports can load reliably in multi-company setups.
Original PR description
Steps: - Have 2 companies with different currencies - Select both in company selector - Go to any report - Traceback: `psycopg2.errors.UndefinedFunction: operator does not exist: text >= date` Cause: https://github.com/odoo/odoo/blob/cacf3fd9fda3624193e6668e7d3e311707db5dad/addons/account/models/res_currency.py#L211 this condition is never met because the NULL value is casted as a text, therefore we ends up trying comparing 'NULL' to '<date>'. Fix: Casting both `date_from` and `date_to` into date format opw-4367588
This fix ensures invoices using global tax rounding calculate the final total from the unrounded base amount, then derive the displayed base consistently. It prevents small one-cent discrepancies in tax summaries and invoice totals, improving accounting accuracy.
Original PR description
Setup the round globally. Suppose a tax of 23% applied on 2 lines: quantity=1, price_unit=0.5 quantity=12.12, price_unit=12.12 Current behavior: base: (12.12 * 12.12) + 0.5 = 147.3944 ≃ 147.39 tax: 147.3944 * 0.23 = 33.900712 ≃ 33.9 total: 147.39 + 33.9 = 181.29 Expected behavior: raw_base: (12.12 * 12.12) + 0.5 = 147.3944 total: 147.3944 * 1.23 = 181.295112 ≃ 181.3 tax: 147.3944 * 0.23 = 33.900712 ≃ 33.9 (same) base: 181.3 - 33.9 = 147.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where financial reports could crash when users selected multiple companies with different currencies. The correction ensures currency date values are handled consistently, so affected reports open reliably in multi-company setups.
Original PR description
Steps: - Have 2 companies with different currencies - Select both in company selector - Go to any report - Traceback: `psycopg2.errors.UndefinedFunction: operator does not exist: text >= date` Cause: https://github.com/odoo/odoo/blob/686d098d59a6078e264c8b2633020b23c5902702/addons/account/models/res_currency.py#L211 this condition is never met because the NULL value is casted as a text, therefore we ends up trying comparing 'NULL' to '<date>'. Fix: Casting both `date_from` and `date_to` into date format opw-4367588
This fixes Italian point-of-sale pricing so calculations consistently treat prices as tax-included where required. It helps prevent checkout totals and tax amounts from being shown or recorded incorrectly for Italian POS transactions.
Online food delivery order calculations now use Odoo's standard calculation method instead of custom manual logic. This reduces the risk of incorrect totals for UrbanPiper, Swiggy, and Zomato orders and makes future maintenance easier.
Original PR description
After this commit : ==== - Replace manual calculation with predefined method to enhance reliability and maintainability. task-4405397
4 changes
Resolved issues and error corrections
This update resolves an issue where the "Request Cancel" button on payments for Mexican companies (l10n_mx) was not working correctly. The fix ensures the correct cancellation process is initiated, allowing users to properly request the cancellation of CFDI payments as required by Mexican regulations. This improves compliance and reduces potential errors.
Original PR description
### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create an invoice with a Mexican partner and confirm
- Create a Payment
- In the invoice form view, go to the "CFDI" page
- Click "Update CFDI"
- The payment appears, click on "Show"
- The button "Request Cancel" does nothing
### Cause:
the method `button_request_cancel` on move is called from the payment model but does not return anything:
```
def button_request_cancel(self):
self.move_id.button_request_cancel()
```
But the `button_request_cancel` from `l10n_mx_edi` is returning a wizard that is never caught.
### Solution:
When clicking the "Request cancel" button, the method `action_request_cancel` is called instead of `action_cancel` which will dispatch the request depending on the type of move being cancelled.
opw-4332483This update resolves an issue preventing non-administrator users from accessing attachments linked to Global Invoices in the Mexican CFDI localization. The fix ensures the correct link between the Global Invoice document and its attachment, allowing authorized users to view the necessary invoice information. This improves usability for users generating and managing Mexican CFDI invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create…
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and linked to the Global Invoice `l10n_mx_edi.document`, but if the link from document to attachment is complete, the opposite is not the case. `ir.attachment.res_id` has a value of 0, and, when checking access rights for `ir.attachment`, we will use the `_search` method in which one of three conditions, two of them having a `res_id` check, must be fulfilled for `ir.attachment` to be considered available to the user. https://github.com/odoo/odoo/blob/afdfbc4041f167ba6d6ff6c17b8432eb531df6b1/odoo/addons/base/models/ir_attachment.py#L561-L570 A user that did not Create Global Invoice and without `base.group_system` in their `groups_id` fulfills none of those conditions. ### Fix reasoning: The issue lies more within `res_id` not being `l10n_mx_edi.document.id` rather than a flaw in `_search`. This change should only apply when creating a Global Invoice. When sending an Invoice to the CFDI through the regular `action_send_and_print` process, `ir.attachment` is linked to `account.move` instead. opw-4365535
This update resolves a bug where the OdooEditor was incorrectly removing spans without attributes, disrupting translation matching. By preventing this removal, the system now correctly uses span keys for accurate translations, ensuring consistent localization across the platform. This improves the quality and reliability of reports for international users.
Original PR description
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++]
This update resolves an issue where product prices in the l10n_ke_edi_oscu module were not including the correct decimal precision, leading to potential errors in VAT reporting for Kenyan businesses. The fix ensures accurate price calculations, improving the reliability of financial data within Odoo Enterprise. This impacts the accuracy of sales and inventory reporting related to products subject to Kenyan VAT.