Tuesday, September 30, 2025
4 changes · 17.0
Resolved issues and error corrections
Intrastat reports now take the region from the warehouse when it is defined, instead of always falling back to the company setting. This helps ensure cross-border goods reporting reflects the correct regional information and avoids inaccurate report lines.
Original PR description
## Issue: The Intrastat report currently uses the company region from settings instead of the warehouse region even when the warehouse has a region defined. ## Cause: The original…
## Issue: The Intrastat report currently uses the company region from settings instead of the warehouse region even when the warehouse has a region defined. ## Cause: The original 'stock.intrastat.report.handler' model defines a `_name` and implements `_fill_missing_values()` to override the company region with the warehouse region. However, this model does not appear to be called directly in the report and, in this particular case, its `_fill_missing_values()` method is not executed. For aggregated header lines, `_fill_missing_values()` cannot restore the region even if it were called, because these lines do not contain `invoice_ids` or `move_ids`. Without such identifiers, the warehouse cannot be determined post-query, so the company region was always used. https://github.com/odoo/enterprise/blob/03d9353d85ed80c6e44fd231e5340d2378af8c81/stock_intrastat/models/account_intrastat_report.py#L11-L37 ## Fix: Introduce a new model that _inherits from 'account.intrastat.report.handler' without a _name. The _fill_missing_values() method is kept in the model to preserve potential future usage, but in this case, the query changes already ensure that the region in the report is correct. ## Steps to reproduce: Note: Belgium localization is used here because it provides pre-defined regions that are easy to modify in the Settings App. - Install l10n_be_intrastat + sale_management + stock - Select a Belgium Company - In Settings, set Company Intrastat Region to "1 Flemish region" - Create a Product (Commodity Code: 01012100..., Weight: 10, Country of Origin: Belgium) - Set Warehouse > Intrastat region to "3 Brussels region" - Create and confirm a Sale Order for a French Customer (Tax ID: FR23334175221, Country: France) - Create and confirm the invoice - Open Accounting > Reporting > Intrastat Report - Select the Report: Intrastat (Goods) and This Month as date - Before the fix, the Region is 1 and it's the same for the details lines opw-5011272
This fixes a display issue where online shop prices could show unnecessary decimals for currencies configured to round to whole amounts. Customers now see prices consistently across product pages and configurator flows, matching the website's currency precision.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878
This fix prevents users from removing the journal linked to an active payment provider. It helps avoid payment failures caused by incomplete journal settings, especially in multi-company or branch-company setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an active payment provider; 2. create a branch company; 3. set payment provider's company to branch; 4. leave Payment Journal unchanged (parent company Bank); 5. go to Accounting / Configuration / Accounting / Journals; 6. open Bank journal; 7. open "Incoming Payments" tab; 8. enable the "Payment Provider" column; 9. unset the payment provider on the active provider's line & save; 10. attempt paying using the provider. Issue ----- > Error: psycopg2.errors.NotNullViolation: > null value in column "journal_id" of relation "account_payment" violates not-null constraint Cause ----- We shouldn't be able to change the related journal of active providers. Solution -------- Make the field read-only if the payment method is active. opw-5045000
Future time off balances now account for leave that employees have already taken when accrual limits are applied. This prevents overstated or incorrect projected balances on future dates, helping HR teams plan and communicate available leave more accurately.
Original PR description
Computing the future accrued days/hours would become incorrect when using a cap when total lifetime accrued allocation was higher than the cap. This caused issues when looking at how much accrued time an employee would have on a certain date where the accrued time would be correct on today, but become incorrect on any other future day. This was due to the fake allocation being used to compute the remaining time not considering the taken leaves, thus the cap was the maximum being considered across lifetime accrued time. opw-5059276