Daily updates from Odoo
Wednesday, April 15, 2026
8 changes · saas-18.4
Resolved issues and error corrections
This update corrects a minor issue in the Batch Payment reports. Previously, the report would incorrectly display default 'demo' values (like 'ABC Holder Name') when a customer's name wasn't provided. Now, the report correctly leaves these fields blank, ensuring accurate and professional-looking payment documents.
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 error in how Odoo calculates depreciation for companies with non-standard fiscal years. Previously, depreciation entries were incorrectly skipped for months within the wrong fiscal year. The fix ensures accurate depreciation calculations, particularly for companies using shortened fiscal years like May-December.
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 discrepancy in the sale and purchase journal dashboards. Previously, receipt data wasn't included, leading to inaccurate counts. Now, receipts are incorporated, ensuring dashboard metrics align with actual sales and purchase records for a more reliable view of business activity.
Original PR description
- The sale and purchase journal dashboards excluded receipts while the action view included them, causing a mismatch between counts and displayed records. Include receipts in the dashboard query to ensure consistency. Related PR:https://github.com/odoo/odoo/pull/254295 taskID-6040828 Forward-Port-Of: odoo/enterprise#111142
This update resolves an issue where users without administrator privileges accessing invoices created from email aliases with CFDI attachments would encounter an access error. The fix ensures that attachment records are properly configured, allowing the system to correctly fetch and display the attached XML files.
Original PR description
When accessing a bill created from an email alias with a user that is not system administrator, we get an access error if there is an xml attachment. Steps: - Configure an email alias for the…
When accessing a bill created from an email alias with a user that is not system administrator, we get an access error if there is an xml attachment. Steps: - Configure an email alias for the purchase journal - Receive a mail wth an xml attached - Create a user with group_user role and administrator right on accounting - log in with new user - access the created bill -> Access Error The root of the issue is that we don't attach xml files when we receive them from an email alias. To do so, we set res_model and res_id fields to False/0 (see `AccountDocumentImportMixin._fix_attachments_on_record`) Then, when trying to access the bill the method `AccountMove._get_mail_thread_data_attachments` add the `l10n_mx_edi_cfdi_attachment_id` to the attachments to fetch. Then the fetch method get a query from the `_search` method or `ir.attachment` and because the attachment has no res_id or res_model and user is not system (see https://github.com/odoo/odoo/blob/8f7807a763e7e272347e9c1622be862700409c34/odoo/addons/base/models/ir_attachment.py#L564-L578) we don't fetch the record and we end up with an access error (https://github.com/odoo/odoo/blob/8f7807a763e7e272347e9c1622be862700409c34/odoo/orm/models.py#L3497-L3500) Fix: Adding res_model and res_id to the `l10n_mx_edi_cfdi_attachment_id` record in its compute method opw-5953578
This update fixes a previous error that prevented invoice settlement when the associated customer information wasn't fully loaded. The change streamlines the process by directly using the customer's ID, ensuring smoother invoice processing and preventing disruptions to the payment workflow. This improves reliability and efficiency.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-6023150 Forward-Port-Of: odoo/enterprise#111957
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's data handling, ensuring the button now functions as intended and allows users to create new payslips when needed. This improves the usability of the W2 report generation process.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770)
This update resolves a crash that occurred when confirming rental orders with kit products containing multiple components in different locations. The change uses a safer method to handle multiple pick transfers, preventing a common error related to assigning return IDs. This ensures rental orders with kits can be processed reliably.
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#112543This update corrects a flaw in how Odoo calculates the available capacity for appointments booked through Google Reserve. The previous system incorrectly reserved the full party size, leading to potential overbooking. This fix ensures accurate capacity allocation, improving the reliability of appointment scheduling.
Original PR description
The current logic inside the appointment google reserve controller to compute reserved and used capacity per resource was incorrect. It was reserving the full party size for each resource instead of properly computing how much spots we are reserving for each. The code was fixed and a test was adapted for proper coverage. Task-6120016 Forward-Port-Of: odoo/enterprise#113805