Tuesday, March 10, 2026
12 changes · saas-18.3
Enhancements to existing features
This update simplifies the process of downloading attachments from account moves like invoices and vendor bills. Previously, users had to download each attachment individually. Now, all attachments are automatically bundled into a ZIP file, making it easier to manage and share important documents.
Original PR description
before: - In v17, account moves (invoices, vendor bills, etc.) did not provide any ZIP export. - Users wanting to download move attachments (e.g. for vendor bills) had to download each file individually. after: - Add an Action on account moves to export attachments as a ZIP archive. - The ZIP contains all attachments linked to the move (PDF, XML, and any other files present in the mail thread), not only the report PDF. - The action is available for all move types (customer invoices, vendor bills, journal entries, etc.) task-5232551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250269 Forward-Port-Of: odoo/odoo#241647
Resolved issues and error corrections
This update fixes an issue where timesheets weren't correctly selecting the appropriate Service Order Line (SOL) when creating timesheets in a multi-company environment. Now, the system automatically links the user to the correct employee record based on billing rates, ensuring accurate SOL assignment for invoicing.
Original PR description
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific…
****Behavior:**** **Current:** In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user. **Expected:** The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list. **Steps to reproduce:** - Be in a multicompany environment: company A and B - Create User with access to both but only one employee record for company A - Switch to company B - Create 2 services product, both creating a task in the same project. - Activate Billable Rate Indicators in the settings - Create a quote with both services and confirm - Go to the related project, and in the Invoicing tab, link employee from company A to SOL2 - As the user, check both companies but set company B as current active - Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured. opw-5159195 Forward-Port-Of: odoo/odoo#234200
This pull request reverts a previous change that incorrectly applied taxes to down payments in point-of-sale and sales transactions. The update ensures that taxes are applied correctly, aligning with business requirements and improving the accuracy of financial reporting. This resolves an issue impacting sales and invoicing processes.
Original PR description
This reverts commit 6831d64b80ebc542ed814d322e8e7ec2ca3b044e. opw-5853070 Forward-Port-Of: odoo/odoo#252069 Forward-Port-Of: odoo/odoo#251942
This update fixes an issue where instructions added to work orders weren't properly linked when creating purchase orders (MOs) via the mobile app. The problem stemmed from a previous change that removed a key data field, preventing the mobile app from correctly associating instructions with the MO. This ensures instructions are accurately reflected when creating MOs on mobile devices.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250090
This update fixes a technical issue where the ECPay integration for Taiwanese companies wasn't working reliably. The change ensures the integration triggers correctly for any company using the Taiwan fiscal localization by checking the company's fiscal country instead of its physical address. This improves the accuracy and functionality of ECPay transactions for our Taiwanese customers.
Original PR description
Previously, the module checked `company_id.country_id.code == 'TW'` to determine if Taiwan's ECPay logic should be applied. However, `country_id` only represents the physical address of the company. This commit replaces `country_id` with `account_fiscal_country_id` across the sale order model and website controllers. This ensures that the ECPay integration correctly triggers for any company using the Taiwan fiscal localization. Task-6002433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252373 Forward-Port-Of: odoo/odoo#251924
This update ensures accurate e-invoicing for Malaysian credit, debit, and refund notes. Specifically, the system now correctly sets the 'prepaid amount' to zero for these document types, aligning with Malaysian e-Invoicing (MyInvois) API requirements. This ensures proper data transmission and compliance.
Original PR description
Currently, the `prepaid_amount` in the UBL export is calculated as `amount_total - amount_residual` for all document types. However, for credit notes, debit notes, and refund notes (both standard and self-billed, corresponding to document type codes 02, 03, 04, 12, 13, and 14), this amount should be 0 to comply with Malaysian e-Invoicing (MyInvois) API requirements. This commit introduces the following fixes: - Sets the `prepaid_amount` to 0 for document types '02', '03', '04', '12', '13', and '14'. - Update the `payable_amount` to the full `invoice.amount_total`. Task-5971843 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252382 Forward-Port-Of: odoo/odoo#251915
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly produced negative amounts, leading to incorrect settlement calculations. This change ensures accurate outstanding balance reporting for sales orders.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#252343 Forward-Port-Of: odoo/odoo#233248
This update ensures that timesheet entries are correctly removed when a time off record is deleted, preventing data inconsistencies. Previously, timesheets remained even after time off was removed, leading to inaccurate tracking. This fix addresses a bug related to how the system handles the link between time off and timesheet records.
Original PR description
BUG 1: ----------- **Steps to reproduce:** 1. Install Time Off and Timesheets with demo data. 2. Create a time off for an employee and approve it. 3. Check the related timesheet entry for that…
BUG 1: ----------- **Steps to reproduce:** 1. Install Time Off and Timesheets with demo data. 2. Create a time off for an employee and approve it. 3. Check the related timesheet entry for that employee. 4. Delete the approved time off. 5. Check the timesheet entries again. **Issue:** The timesheet entry remains even after the related time off record is deleted. **Cause:** Following commit 944c11e, admins can delete [approved time off ](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L956-L959)records. The relationship between the leave and the analytic line (timesheet) did not have a deletion policy defined. When the leave was [unlinked](https://github.com/odoo/odoo/blob/f6cf0d067e5f30e2b22ea513071cd7c5e3d9f44c/addons/hr_holidays/models/hr_leave.py#L961-L964), the analytic line remained without its parent reference. **Solution:** Explicitly remove related timesheet entries before deleting the leave record. BUG 2: ----------- Currently, refusing/cancelling a time off record can lead to orphan timesheets/duplicated hours (16h instead of 8h) if a public holiday exists on the same day. **Root cause:** The issue comes from this write method: https://github.com/odoo/odoo/blob/79ff1d63caed2c1058aa338947b9af90ebb6cd20/addons/project_timesheet_holidays/models/hr_leave.py#L128-L130 The method first unlinks the holiday_id from the timesheets and then attempts to delete them. However, once the holiday_id is set to False, the timesheets are no longer linked to the leave. As a result, leave.timesheet_ids becomes empty, and nothing is deleted. This leads to orphan timesheet records. When the leave is later refused or cancelled, a new public holiday timesheet entry is generated (if applicable), resulting in duplicated timesheet entries for the same day. **Steps to reproduce:** 1. Create a time off for one day and validate it (8h timesheet generated). 2. Create a public holiday for the same day. 3. Observe that leave duration becomes 0, but the timesheet remains. 4. Refuse or cancel the time off. 5. Observe two timesheet entries for the same day (16h total). opw-5384428 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where currency exchange differences weren't correctly displayed in DATEV exports. The fix adjusts how the export generates amounts for exchange difference entries, ensuring accurate reporting of financial transactions. This improves the reliability of data sent to DATEV for accounting.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954 Forward-Port-Of: odoo/enterprise#109655 Forward-Port-Of: odoo/enterprise#107268
This update resolves a bug where the barcode scanning app incorrectly identified products when using barcodes that include product prices (starting with '23'). The fix mirrors the functionality in the Point of Sale app, ensuring accurate product recognition for these common barcode formats. This improves the reliability of product scanning and reduces potential order errors.
Original PR description
Issue ----- Barcode app doesn't match products when using price-embedded barcodes. Steps to reproduce ----- - Use default nomenclature (so price embedded barcodes are 23...) - Create a product with barcode 2355555000004 - Go to barcode and scan 2355555009502 > The product isn't recognised Cause ----- There is no logic in place to handle such barcodes, but it can be added to mimic how it works in POS. https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L212 ----- Ticket: opw-5901412 Forward-Port-Of: odoo/enterprise#109815 Forward-Port-Of: odoo/enterprise#109627
This update corrects a bug where the 'Documents' button for employees was displaying documents from other users, even when 'Human Resources' file centralization was disabled. The fix ensures that users only see documents associated with their own employee records, restoring the intended functionality. This resolves a usability issue for employees accessing their personal documents.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914
This update fixes an issue where certain salary deductions weren't being properly calculated in the Kenyan payroll module. The changes add four new lines to the 'Total deductions' line, adjusting their sequence and sign to accurately reflect attachments of salary, ensuring correct net pay calculations for employees in Kenya.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#107033