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.

Add the modelo 130 report for spain localization

task-3866238

Linked PR : https://github.com/odoo/odoo/pull/164946

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.

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

Fixed a bug where AvaTax fixed tax amounts were incorrectly being interpreted as percentage-based taxes. When computing taxes for invoices using AvaTax, fixed fees (like a $0.29 delivery fee) were being displayed as percentages (29.0000%), causing incorrect tax calculations. This fix ensures that fixed taxes from AvaTax are properly recognized and applied as fixed amounts rather than percentages.

To reproduce:
Activate Avatax (in Sandbox mode)
Create an invoice to a partner from Colorado
Put the 0F4000000 code on the Avatax Category of a product 
Create a line with this product
Click on "Compute Taxes"

=> A tax named "Retail Delivery Fee [08] (29.0000 %)" is created

The issue is that if you look on Avatax, it's supposed a fixed 0.29 tax.

opw-4036105

Forward-Port-Of: odoo/enterprise#66973

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.

In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs.

The barcode command labels in the Manufacturing work order system have been updated from "CONTINUE/PAUSE" to "CONTINUE/START" for better clarity. This change improves the user experience by using more intuitive terminology for barcode-based operations in the manufacturing workflow.

Part of a UI task.

Changed CONTINUE/PAUSE to CONTINUE/START
Regenerated the PDF file

task-id: 3646156
community: https://github.com/odoo/odoo/pull/171616

This update fixes an issue where delivery tests were failing when run without demo data. The tests were referencing a demo partner ('Deco Addict') that doesn't exist in no-demo environments. The fix ensures tests create the necessary partner data when needed, making the test suite more reliable across different configurations.

The Issue:
Before this commit, the test always assumed the existence of the 'Deco Addict' partner. However, in the 'no demo' test, we run tests without demo data, so this partner does not exist.

The Fix:
Create the demo Partner

runbot-58765

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.

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.

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 fixes multiple compliance issues in Ecuador's ATS (Anexo Transaccional Simplificado) tax report to align with SRI (tax authority) requirements. The changes remove unsupported document types that cause validation errors, correct how sales transactions are filtered and reported by commercial partner and establishment location, and update related test cases to ensure accurate tax reporting.

### Fixes in ATS report:

- Remove foreign documents '15' and '110'. SRI DIMM returns a validation error

    ![image](https://github.com/user-attachments/assets/02b9ef2b-73b1-4cb9-bf2f-9b58ae6d0358)

- In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number).
- In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS
![image](https://github.com/user-attachments/assets/33d4196d-1849-4281-be75-9eb7dab45e29)


- In sales, Get all the establishments registered at the SRI (tag "ventasEstablecimiento"). As it says the Technical Sheet of ATS
![image](https://github.com/user-attachments/assets/7a648240-d11e-43fa-901d-7e82ea25da41)

- Fix Unit tests

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.

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: