Daily updates from Odoo
Wednesday, April 15, 2026
15 changes · 19.0
Enhancements to existing features
This update simplifies the calculations for 'Retained Earnings' and 'Result for the Year' within the French Balance Sheet report. This change ensures greater accuracy and consistency in financial reporting for French-speaking businesses using Odoo Enterprise. It's a routine improvement to the reporting functionality.
Original PR description
Simplify the formulas of 'Retained earnings' and 'Result for the year' in the french Balance Sheet. task-6087994
This update simplifies the Balance Sheet report to clearly separate Earnings and Equity, enhancing financial reporting clarity. The changes improve the charts of accounts to better show how earnings are allocated, providing a more straightforward view of key financial metrics. This impacts both the standard and US versions of the report.
Original PR description
Simplifying the structure of the Balance Sheet in order to distinguish clearly **Earnings** and **Equity**, in the generic and US balance sheet. Improving the generic and us charts of accounts to better highlight the account pair for the allocation of earnings. task-6053852
Resolved issues and error corrections
This update resolves an issue where very small order weights (under 1kg) weren't being correctly converted to grams before being sent to the shipping carrier. Previously, the system treated these as zero, leading to rejected orders. Now, all non-zero lightweight orders are accurately converted, ensuring shipments meet carrier minimum weight requirements.
Original PR description
Before this commit, `sendcloud_convert_weight()` used the source UoM rounding to short-circuit zero values. On databases where the weight UoM is `kg` with a rounding of `1.0`, any weight below 1kg was treated as zero and returned unconverted. For example, 0.23kg stayed 0.23 instead of being converted to 230g, `int()` turned it into 0, and Sendcloud rejected the order as being below the carrier minimum weight. This commit ensures that non-zero lightweight orders are properly converted before Sendcloud weight checks are applied. opw-6014572
This update resolves a problem where navigating back in the documents module (specifically in kanban and list views) caused the page to reload unnecessarily. The fix ensures correct page restoration and avoids reopening the same folder after a back navigation, improving the user experience. This prevents data inconsistencies and frustration for users.
This update fixes a calculation error in the employment bonus payments for Belgian companies using the l10n_be_hr_payroll module. The change ensures that bonus calculations now precisely align with the requirements outlined by Belgian social security regulations, as detailed in the official documentation. This correction guarantees accurate and compliant bonus payments.
Original PR description
The employment bonus computation was missing two roundings steps that are explicitely asked for in the following documentation: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/deductions/workers_reductions/workbonus.html
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update fixes an issue where refunds weren't correctly reflected when calculating outstanding balances in the POS system. Previously, only regular orders were considered, leading to inaccurate due amounts. Now, refund orders with negative totals are included, ensuring accurate due calculations and a better user experience.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113458 Forward-Port-Of: odoo/enterprise#107883
This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change corrects a previous omission, ensuring accurate equity reporting for Swiss clients. The change improves the report's precision and aligns with accounting standards.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108This update corrects a bug in how Odoo calculates depreciation for assets with shortened fiscal years. Previously, the system incorrectly skipped months during depreciation, particularly in the transition between fiscal years. This fix ensures accurate depreciation calculations for companies using non-standard fiscal year cycles.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113521
This update corrects a technical issue impacting delivery processing for Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding service to ensure correct zip code formatting, improving delivery reliability.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181
This update fixes an error in how invoice periods are calculated for subscriptions with 'Align to Period Start' enabled. Previously, invoices displayed an incorrect date range. Now, invoice periods accurately reflect the subscription's start date and end on the last day of the month, ensuring accurate billing.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users working with the Germany + Fiskaly setup. This improves usability and avoids requiring specialized user permissions.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618
This update resolves an issue where the AI composer was causing instability in the base mail composer. The fix ensures that focus events are correctly passed, preventing a crash when the AI composer triggers focus. This improves the overall reliability of the AI composer within the Enterprise module.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#113763
This update resolves a crash issue that occurred when confirming rental orders with kit products using multiple pick locations. The change utilizes a safer method to handle multiple pick transfers, preventing a 'singleton error' and ensuring rental orders can be processed correctly. This improves the reliability of the rental product functionality.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#112543Features or functions removed from Odoo
This pull request removes specific localization data related to Uzbekistan reports from the .weblate.json file. This streamlining simplifies the localization process and ensures that only the necessary language resources are included in the Odoo Enterprise software. The change improves build times and reduces potential complexity.
Original PR description
Related: https://github.com/odoo/odoo/pull/259342