Daily updates from Odoo
Friday, October 11, 2024
18 changes · 17.0
New functionality added to Odoo
This update adds support for currency rates from the Bank of Italy, which is required for legal compliance in Italy. The Bank of Italy is the only authorized institution in Italy to publish official currency rates, and this integration ensures your system uses the correct rates for financial transactions and reporting.
Original PR description
This commit adds support for the Bank of Italy currency rates. The Bank of Italy publishes the currency rates on its APIs, of which the most recent one is available at https://tassidicambio.bancaditalia.it/terzevalute-wf-web/rest/v1.0/latestRates. Documentation can be found at https://tassidicambio.bancaditalia.it/terzevalute-wf-ui-web/assets/files/Istruzioni_tecnico-operative.pdf. This is necessary for Italian law compliance, as the Bank of Italy is the only institution allowed to publish currency rates in Italy. Forward-Port-Of: odoo/enterprise#55502
Enhancements to existing features
This update improves the French translation in the accounting module by refining a key phrase. The message "Vous avez lettré 2 transactions dans 45 secondes" has been corrected to "Vous avez lettré 2 transactions en 45 secondes" for better grammar and clarity. This ensures French-speaking users see more natural and professional language when using the accounting features.
Original PR description
In this context, the sentence seems better phrased with "en" rather than "dans": - Vous avez lettré 2 transactions dans 45 secondes. Becomes: - Vous avez lettré 2 transactions en 45 secondes. Forward-Port-Of: odoo/enterprise#70449
The GST tax calculation system has been improved to be faster and more accurate. The changes simplify how tax information is retrieved and processed, ensuring that all tax amounts—including those with 0% tax or no tax—are handled correctly. This results in more reliable GST return reporting for Indian businesses.
Original PR description
In this PR: - Simplified tax detail retrieval using Odoo ORM instead of complex SQL queries. - Directly mapped tax amounts from tax lines to improve accuracy. - Enhanced handling of journal items with 0% tax or no tax. Task ID: 4032825
This update adds flexibility to timesheet planning by allowing custom cutoff dates instead of always using today's date. This enables teams to create future-dated planning scenarios when needed, making the forecasting tool more adaptable to different business planning cycles and requirements.
Original PR description
### Before this PR There is no way to use a custom cutoff date for timesheet generate planning ### After this PR New technical function to get a custom cutoff date. Default is Datetime.now() but it is overridable by custom module to manage date other than today (Sometimes it is needed to create future planning) Forward-Port-Of: odoo/enterprise#71394
Resolved issues and error corrections
This fix corrects an issue where auditing expense categories with vehicle split enabled was showing duplicate line items. Lines associated with vehicles were appearing both in the category audit and in individual vehicle audits. The fix ensures vehicle-related lines are excluded from category audits when vehicle split is active, eliminating the duplication.
Original PR description
…le split Currently, when auditing a DNA category with the vehicle split option leads to incorrect values. All the lines from the account being audited are displayed, including those with a 'vehicle_id'. That is wrong, since these lines will be grouped with the corresponding vehicle inside said category. They will appear both when auditing the category as well as when auditing each vehicle from this category. The solution is simply to exclude lines related to a vehicle when auditing a category while the vehicle split is active. task-4023543 Forward-Port-Of: odoo/enterprise#71382
This fix prevents incorrect validation errors when posting expense reports with incomplete partner addresses. The tax address validation is now only applied to customer invoices and credit notes, where external tax integrations are actually used, rather than blocking expense report processing.
Original PR description
1. Enable "auto-detect" on the Avatax fiscal position, 2. Go to "Abigail Peterson" contact and set "United States" as country 3. Expenses > My Expenses > New 4. Enter a description, set a total and "Abigail Peterson" as employee 5. "Create Report" > "Submit to Manager" > "Approve" > "Post Journal Entries" Issue: Validation error will raise because of the incomplete address However we only handle customer invoices and customer invoice refunds (aka credit notes) with external tax integrations so the constraint should only show for journal entries of this type. opw-4151193 Forward-Port-Of: odoo/enterprise#71543
When a company changes its global appraisal plan in settings and has appraisal automation enabled, the system now automatically recalculates the next appraisal date for all employees. This ensures that employee appraisal schedules stay synchronized with the company's current plan settings.
Original PR description
There is an *Appraisal Plan* section in the setting that allows setting the global plan for the company. If *Appraisal Automation* is enabled and the plan is changed, we want to recompute the next appraisal date based on it for all the company employees. task-4167727
This fix ensures that when two support tickets are merged together, the total hours spent on both tickets are correctly combined and displayed. Previously, the system was not recalculating the total hours after a merge, resulting in incomplete time tracking data.
Original PR description
### Steps to reproduce: - Create two helpdesk tickets - Create a timesheet for each one of those tickets - Merge the tickets together - Check the 'Hours spent' field where it doesn't show the addition of the two tickets' total_hours_spent ### Current behavior before PR: This is happening because when flushing after merging the tickets the total hours spent does not show in the recomputation tree so it doesn't get recomputed. ### Desired behavior after PR is merged: The idea of the fix came from this commit https://github.com/odoo-dev/enterprise/commit/f4aedadbd6180049573c2b4d90ffc0dd4656ea06#diff-9a1216d4c95d4f60296c59d0294e505970b4d97ad4ac256e1a87c7289f1f8129R17 since the issue got resolved in 17.4 because of this commit where it changed the dependency of the project_id which leads to the existance of the total_hours_spent in the tree of recomputation that is depending on the helpdesk.ticket.project_id opw-4226970
This fix corrects an error in the Holiday Attest (N-1) document used in Belgian payroll processing. The end date on the attestation was incorrect and has been updated to match the end of the notice period, ensuring employees receive accurate documentation when leaving the company.
Original PR description
The end date on the Holiday Attest (N-1) was wrong. It should be the same as the end of the notice period.
This fix resolves an error that occurred when generating customer statement reports for WhatsApp templates. The system was failing to retrieve the correct data needed for the report, causing the template generation to crash. This update ensures that customer statement reports can now be successfully created and submitted for approval.
Original PR description
Install whatsapp Create a new template as follows: - Account: any (real values not needed to reproduce the issue) - Header Type: Document - Report: Customer Statement - Body: Any Save and Submit for Approval Issue: Tracback will raise during template generation """ TypeError: 'NoneType' object is not subscriptable Template: l10n_account_customer_statements.customer_statements """ This occurs because when generating the report for the template we miss the correct data. Partial backport of f0a82fc57826346d7edae1465b35303bc7d1649c opw-4133970
This fix corrects a display issue in inter-company transactions where purchase order confirmation messages were showing the wrong company name. When syncing sales orders across companies, the system was incorrectly displaying the current user's company instead of the actual company that created the order. This fix ensures users see accurate company information in their purchase order notifications.
Original PR description
Reproduce the issue: - Turn on inter-company transactions to sync Sales and Purchases - Create an SO in one company for the second company - Chatter displays an incorrect message noting the record was created from the current company instead of the triggering company The issue: In the sale_order.py model of sale_purchase_inter_company_rules.py, the field of the current company was used instead of the field of the order's company. opw-4199979 Forward-Port-Of: odoo/enterprise#71624
This fix enables customers to print receipts directly from the self-order kiosk using IoT-connected printers, a capability that was previously unavailable. This improves the customer experience by allowing them to obtain physical receipts at the point of sale without manual intervention.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/e2da8c4fbbfb50ddc033cf30885fef4394cbe2dc It enables printing receipts in the kiosk using the iot which was not supported before. opw-4120145
This fix corrects how currency exchange rates are calculated for Mexican invoices paid in a different currency. Previously, the system was using rounded amounts to calculate rates, which caused inconsistent exchange rate values in payment documents. The fix now uses the proper conversion rate calculation to ensure all payment records show consistent and accurate exchange rates.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a…
### Steps to reproduce the issue: 1. Activate Mexican localization 2. Create multiple Invoices in USD with different amounts (add the Invoice Date) 3. Send and Print them for the CFDI 4. Register a grouped Payment in MXN for those invoices 5. Go to one of the Invoices and click on Update Payments 6. Go to the CFDI tab and, on the Payment line, click on Force CFDI 7. On the Payment line, you should now be able to Download an XML document 8. In the document, the EquivalenciaDR attributes should have the same values, which is not the case ### Explanation: When calculating the rate (which then is used in EquivalenciaDR) in `_l10n_mx_edi_add_payment_cfdi_values`, we are using amounts that have been rounded out, leading to rates that differ when aiming for certain decimal precisions. ### Fix reasoning: While `_get_conversion_rate` can be used to avoid the inconsistencies of the rounded amounts, it should not be used if the values do not match once they are converted, since the rate would then be wrong. opw-4090269
This fix corrects an accounting discrepancy in German DATEV tax reports where invoice line amounts were being rounded incorrectly, causing amounts to appear 0.01 currency units lower than actual (e.g., 19.94 instead of 19.95). The fix ensures that the original invoice price is used directly in the report rather than a recalculated rounded value, improving accuracy of exported financial data for German tax compliance.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity:…
**Steps to reproduce:** - Install Accounting and l10n_de_reports - Switch to a German company - Create a 19% included tax - Create an invoice with the following line: * Product: [any] * Quantity: 1.00 * Price: 19.95 * Taxes: [the 19% included tax] - Confirm the invoice - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" **Issue:** The line for the created invoice has an amount of 19.94 instead of 19.95. **Cause:** As the tax is included, the balance on the line is computed and rounded. When the report is generated, "compute_all" is executed with the rounded balance to retrieve the total price with the taxes. Because the balance used in "compute_all" has been rounded and therefore is not exactly the same than the original computed value, there can be a 0.01 difference. **Solution:** Use directly "price_total" field when available. opw-4191876 Forward-Port-Of: odoo/enterprise#70801
The restart buttons for the Odoo service and IoT box in the backend were not functioning after the IoT homepage was redesigned. This fix updates the restart buttons to use the correct endpoints from the new homepage, restoring their functionality.
Original PR description
In the rewrite of the IoT homepage, the endpoint for restarting the Odoo service or rebooting the IoT box was changed, leaving the restart buttons in the backend nonfunctional. This PR changes the endpoints used by the buttons to match the new homepage, fixing the issue.
Fixed a bug in the General Ledger search functionality where searching for non-existent accounts would display all lines instead of showing no results. The search filter now correctly shows an empty result set when no matching accounts are found, improving the accuracy and usability of the search feature.
Original PR description
Open General Ledger Search for a non existing account/aline (ex. "1111111111111") Issue: All lines are shown This occurs because we update matched lines only if there is a match, otherwise we reset the filter opw-4160605
This fix ensures that when a subscription product is purchased and paid for at the point of sale, the next invoice date is properly updated in the system. Previously, the next invoice date was not being updated after payment, which could cause billing timing issues for recurring subscriptions.
Original PR description
Steps to reproduce: - Install subscription and pos_sale_subscription - Create a sale order with a recurring product (a subscription) - Settle the sale order in the point of sale - The date of the next invoice is not updated To fix this issue, when the pos_order is paid, we will update the next invoice date of all sale orders in lines that are of type subscription. opw-4072950
Miscellaneous changes
The Iraq localization module (l10n_iq) has been moved from the Enterprise edition to the Community edition of Odoo. This change makes Iraq-specific accounting features, tax configurations, and localization data available to all users at no additional cost, expanding accessibility to businesses operating in Iraq.