Daily updates from Odoo
Wednesday, September 18, 2024
8 changes · 17.0
Resolved issues and error corrections
This fix resolves an error that occurred when trying to generate invoices from POS transactions in Chile. The system was looking for customer information in the wrong location, causing the invoice process to fail. With this correction, customers can now successfully create invoices from their POS orders without encountering errors.
Original PR description
Problem was we try to get partner from `order.partner` instead of `order.partner_id` Steps to reproduce: - Install l10n_cl - Select the CL Company - Go to POS - Select products - Change the client to Blanco Martin & Asociados EIRL (has all the information for l10n_cl) - Click on "payment" - Select any payment method - Select the option "Invoice" - Validate - Console error opw-4180894
The Accounting dashboard's comparison formulas have been updated to correctly handle monthly and quarterly date filters, not just yearly comparisons. Previously, the dashboard only worked accurately when comparing full years, but now it properly calculates deltas across different time periods that users can select.
Original PR description
The `Accounting` dashboard was using very naive formulas to compute deltas between years. Namely, the formulas were based on the assumpution that we'd only compare values year by year but the filters allow to work with quarters or months as well. This revision updates the dashboard file to take the months/quarters into account. task-3957037
This update removes two empty and outdated fields ("Operation Type" and "Subdivision") from the external trade section of Mexican invoices. These fields were removed from the official Mexican external trade regulations and were appearing as blank cells on printed invoices, causing confusion. The change aligns Odoo's invoice format with current Mexican tax compliance requirements.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_extended - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Configure external trade according to: https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade - Make sure that USD has up-to-date rates - Create an external trade invoice: * Customer: [a US customer] (e.g. Deco Addict) * Currency: USD * Usage: Without fiscal effects * Incoterm: EX WORKS * External Trade: Definitive - Confirm the invoice - Print the invoice **Issue:** In the external trade section of the invoice, there are 2 empty cells: "Operation Type" and "Subdivision". According to https://facture.com.mx/nuevo-complemento-comercio-exterior-2-0/ they both have been removed. opw-4078535 Forward-Port-Of: odoo/enterprise#70178
This fix resolves a system error that occurred when changing product types in companies set to Kenya. The system was trying to access an incorrect company attribute, causing the product type change to fail. The fix corrects the attribute reference so product type changes now work properly for Kenya-based companies.
Original PR description
Currently, an error occurs when the system tries to access the attribute name 'account_fiscal_id' through 'company_id' [1] but it is not available in 'res_company' model. Step to produce: - Install the 'l10n_ke_edi_oscu_stock' module. - Create a product, Set a company as Kenya, Change a 'Product Type' storable to service or consumable. - Again change a 'Product Type' to a storable product. ```AttributeError: 'res.company' object has no attribute 'account_fiscal_id'``` Link [1]: https://github.com/odoo/enterprise/blob/3f0113b0d95200466f51b9c1f75b58a3534fb34c/l10n_ke_edi_oscu_stock/models/product.py#L21-L22 To resolve this issue, Get a product country code from 'account_fiscal_country_id' instead of 'account_fiscal_id' Sentry-5862212825
A broken link in the GST Return (GSTR) report that previously displayed a 404 error has been fixed. Users can now click on the "Checkout our tutorial" link and be directed to the proper Odoo documentation for GST filing, improving the user experience and providing easy access to helpful resources.
Original PR description
Before this commit: whenever user clicked on `Checkout our tutorial` broken url on GSTR report a new page with 404 Not Found opened After this commit: We fix the `Checkout our tutorial` broken url, now when user clicks on the page it redirects user to Odoo documentation of GSTR filing
This fix resolves an issue where text in the general ledger report would overlap and become unreadable when printing to PDF. The problem occurred when journal entries contained longer text descriptions (like partner names and transaction details). The fix improves the text formatting rules to prevent overlapping regardless of text length, ensuring reports are always clear and professional-looking.
Original PR description
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the…
Steps to reproduce ================== - In the accounting app, go to 'Journal Entries'. - Create a new entry. - Set the 'reference' field to 'Receipt'. - Add 2 accounts in Journal Items. - For the 1st account, select 'Account Receivable' (e.g., 121000 Account Receivable). - Set the Partner field to "0h3n-abcdefg@yahoo.example.com" and the label field to "Online transfer reced agst INV-00171, Dt:01.08.2024". - For the 2nd account, set it to any other type, such as "101401 Bank". - Add a credit amount in the 'Account Receivable' and the same amount in the 2nd account. - Save and post the transaction. - Navigate to the general ledger. - Ensure you expand the list of this newly created account move under the 121000 Account Receivable to observe overlapping text. - Click on 'PDF' and print the report. - Notice the overlapping text.  Cause of the issue ================== The o_overflow_value class is only applied when the cell value length is longer than 65 chars Solution =======  Here are the differences, only the following lines are pushed down  opw-4130917
Users can now reorder projects in the Field Service Configuration menu. Previously, the reordering feature was unavailable because the sequence field wasn't properly configured in the project list view. This fix enables drag-and-drop reordering functionality, giving users more control over how their projects are organized.
Original PR description
Before this commit, it was not possible to resequence the projects in any list views of Project and Field Service because the `handle` widget is not defined in the sequence and the default order applied in those list views does not begin with `sequence` field. This commit shows the sequence field in the list view of `Field Service > Configuration > Projects` and change the default of that list view to allow the user to resequence the projects as he wishes. Community PR: odoo/odoo#180403 Close odoo/odoo#176961
Fixed a bug in the Chilean localization module where claim status updates from the tax authority (SII) would fail when multiple events were returned instead of a single event. This was causing repeated error messages and preventing proper status tracking. The fix now handles both single and multiple event responses correctly, and adds support for an additional response code (NCA) that was observed in customer data.
Original PR description
When parsing a claim status from the SII, the list of events in the response can either be a single event or a list of events. If a list was returned this would fail with a parsing error because the…
When parsing a claim status from the SII, the list of events in the response can either be a single event or a list of events. If a list was returned this would fail with a parsing error because the original implementation only expects a single event. That then led to the status getting repeatedly checked and logging "list indices must be integers or slices, not str" when done through a cron. This fix supports both the single and multiple event scenario. The l10n_cl_claim field is not displayed anywhere by default and is only used to check if the claim status still needs to be logged in the chatter or not. Since multiple response codes are possible, in theory it should be a list instead of a single value, but that would be more appropriate for a change in master. A boolean flag would also suffice if the response code doesn't need to be displayed separately. We currently just set the last code that was returned. The responses observed in the customer database include the code NCA, which isn't expected by Odoo. This code was added as a valid one. opw-3920273 Forward-Port-Of: odoo/enterprise#70167 Forward-Port-Of: odoo/enterprise#66498