Friday, August 2, 2024
7 changes · 17.0
New functionality added to Odoo
This update adds support for the Spanish Modelo 130 tax report, a new compliance requirement for Spanish businesses. The feature includes the ability to generate and export tax reports in the official BOE (Spanish Official Gazette) format, helping Spanish companies meet their tax reporting obligations more efficiently.
Original PR description
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946
Enhancements to existing features
This update improves the CodaBox integration for Belgian accounting by adding a dashboard button to quickly view draft SODA entries, adding a password verification step during connection setup to prevent errors, and including a link to documentation for easier user guidance. These changes make the system more user-friendly and help prevent connection mistakes.
Original PR description
1. Add a button in the dashboard to view the number of drafts SODA entries for the CodaBox Soda journal. This button opens the SODA draft entries 2. Add a new non-stored field on the validation wizard to verify that the user has correctly copied the Accounting Firm password. If not, the 'Validate connection' button will be disabled 3. Add a link to the documentation in the connection wizard task-id 4008140
Resolved issues and error corrections
A bug was fixed in the Field Service Management timesheet creation process where a return statement was missing from the save_timesheet function. This fix ensures the function properly completes its operation and returns the expected result, preventing potential errors when users save timesheets for field service tasks.
This update fixes a technical issue in the timesheet timer feature where certain initialization steps weren't completing properly, which could cause display problems. The fix also improves performance by streamlining code and running multiple data requests simultaneously instead of sequentially.
Original PR description
In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs.
This fix resolves an issue where manufacturing order quantities of 1,000 units or more were being incorrectly truncated in the Shop Floor display (e.g., 2,500 units showed as "2"). The problem was caused by unnecessary data conversions in the display code. After this fix, quantities now display correctly and completely, improving accuracy in the manufacturing workflow.
Original PR description
Steps to reproduce: - Manufacturing > Products > BoM - Create BoM with at least 1 operation - New MO with Quantity to produce >= 1000 - Shop Floor > Remove filters What happens: Work order card…
Steps to reproduce: - Manufacturing > Products > BoM - Create BoM with at least 1 operation - New MO with Quantity to produce >= 1000 - Shop Floor > Remove filters What happens: Work order card truncates number of units to produce by 3 digits, i.e. a quantity of 2500 displays as 2, 34000 as 34, etc... This is caused by the successive conversions in formatFloat, they go: Number (quantityToProduce) > String (formatFloat) > Number (ParseFloat) > String (String()) Which looks to be a dirty solution to forcefully display the float as an integer value. What this fix does: Getting rid of the superfluous conversions fixes the truncating issue. The decimal precision was set to default to integer values if the precision props is not defined to conserve the original behavior since manufacturing fractions of a product seems nonsensical, but it seems a precision was passed all along and simply failed to display because of the aforementioned issue. So now 2500 displays as 2500.00 not sure if that was intended or just ignored because of the previous display weirdness. opw-4040457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where the Belgian tax report posting wizard incorrectly checked the company's country code instead of the report's country code. This caused errors when users tried to create closing entries for foreign VAT fiscal positions (such as French tax reports on a Belgian company). The fix now properly detects the correct country code for the report being processed.
Original PR description
Currently we just check whether the company has 'BE' fiscal country code. But this can be incorrect: We may want to create a report for a foreign VAT fiscal position. This situation can lead to a traceback (see below). After this commit we use the dedicated helper function `_get_report_country_code` to determine the right country code. Reproduce: 1. Install `l10n_be_reports` and `l10n_fr_reports` 2. On the Belgian company create a fiscal position with country 'France' and a 'Foreign Tax ID' 3. On the Belgian company open the tax report and select the French tax report 4. Click on the "Closing Entry" button to create a draft closing entry move 5. Try to post the move 6. Traceback (in which `l10n_be_reports_post_wizard` appears) task-4063968 Forward-Port-Of: odoo/enterprise#67548 Forward-Port-Of: odoo/enterprise#67122
This update corrects how currency exchange rates are calculated when currencies have different conversion ratios (like Turkish lire at 100 TRY = 18.30 BGN). Previously, the system was not accounting for these ratio differences, leading to inaccurate exchange rates. The fix ensures all currency conversions are calculated correctly by properly factoring in the ratio multiplier.
Original PR description
Description of the issue/feature this PR addresses: Added parsing and multiplication of 'RATIO' field with 'REVERSERATE' for more accurate currency rate calculations. For example, Turkish lire is per 100 TRY 18.30 BGN. The current date is also adjusted to use today's date correctly within the function. Current behavior before PR: Wrong calculation of currencies with different ratio <> 1.0 Desired behavior after PR is merged: