Daily updates from Odoo
Friday, April 10, 2026
13 changes · master
Resolved issues and error corrections
This update corrects a previous issue where the Amazon fulfillment channel in the sales module was not editable for users. The fix ensures that users can now properly manage their Amazon fulfillment options, streamlining the order fulfillment process. This resolves a reported usability problem.
Original PR description
Commit 67c45d6494f082e2ee83b9a84611e8b8fe8f4fd5 intended to make `amazon_channel` editable by users. However, the field was displayed with the `badge` widget, which is read-only, so it remained uneditable. Use an editable display for `amazon_channel` so the original fix works as intended. Forward-Port-Of: odoo/enterprise#113196 Forward-Port-Of: odoo/enterprise#112866
This update fixes a limitation in Odoo Enterprise's delivery carrier options. Previously, cash on delivery was unavailable for UPS (legacy), UPS REST, and Shiprocket carriers. Now, these carriers will display the cash on delivery checkbox, providing users with more flexible payment choices.
Original PR description
*: delivery_ups,delivery_ups_rest,delivery_shiprocket Override `_compute_supports_cash_on_delivery` so that UPS (legacy), UPS REST, and Shiprocket carriers expose the cash on delivery checkbox. task-none See also: - https://github.com/odoo/odoo/pull/254459
This update fixes an issue where failed quality checks didn't correctly route items to their designated failure locations. Now, when a user marks an item as failed, a wizard appears to select the correct location, ensuring accurate stock management and preventing misdirected transfers. This improves efficiency and data consistency.
Original PR description
Currently, when a user clicks the 'FAIL' button on a quality check form with available failure locations for a control point, the quality check is directly marked as failed, and the user is not allowed to select the failure location. This leads to inconsistencies in stock management, as the failed items may be transferred to an incorrect location instead of the intended failure location. This improvement ensures that when the 'FAIL' button is clicked, and if failure locations are defined for the control point, a wizard is triggered, allowing the user to select the appropriate failure location. Once confirmed, the chosen failure location is set as the destination for the move. This change improves stock management for failed items and resolves inconsistencies in the transfer process. Task Id: 5367964
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures that the canteen cost is only applied when the employee has worked during the payslip period, aligning with accurate payroll processing. This improves the reliability of the Belgian payroll module.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#112462
Forward-Port-Of: odoo/enterprise#110991This update resolves an error that occurred during the registration of super payments in the Australian payroll system. By initializing the error message to an empty string, the system now correctly handles payment processing without returning NULL values. Associated tests have been added to ensure this fix functions as expected.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#113202 Forward-Port-Of: odoo/enterprise#112930
This update fixes a problem where users weren't receiving clear error messages when the SendCloud delivery service failed. A helpful hint has been added to the system, guiding users to resolve delivery issues more effectively. This improves the user experience and reduces potential delays.
Original PR description
Add hint with error message. ----- Ticket: opw-6072855 Forward-Port-Of: odoo/enterprise#112463
This fix resolves an issue where the bank reconciliation process would fail when using the liquidity account as an outstanding payment account. The update prevents automatic reconciliation attempts in this scenario, ensuring data integrity and preventing the form from becoming unsavable.
Original PR description
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity…
# How to reproduce - Create a new Journal - Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account - Go to the Transactions of the Journal - Add a new Transaction for partner X and amount Y - Add a second Transaction also for partner X and amount Y # The issue A popup appears that can never be saved # Cause When we click on "Add & New" or "Add & Close", we run the `validate()` function : https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16 Which tries to do a model save, but it fails so it show the Form dialog : https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163 The save fails because : This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so : https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385 https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245 But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once: https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737 opw-6063654 Forward-Port-Of: odoo/enterprise#113358 Forward-Port-Of: odoo/enterprise#112750
This update resolves a bug preventing users with sign access from editing custom fields created by other users. The fix ensures authorized users can correctly access and modify shared custom fields within sign templates, improving collaboration and usability. This change enhances the functionality of the sign process.
Original PR description
Steps to Reproduce: Create a custom field as User A. Log in as User B (with sign user access). Try to use the same field in a template or open its configuration. Attempt to edit the field. Issue: Users were facing access errors when interacting with custom fields created by other users in sign templates, limiting usability and collaboration. Current Behavior: Users cannot edit custom fields created by other users even if they are shared. Expected Behavior: Authorized users can use shared custom fields without any errors. Shared fields can be edited when access conditions are satisfied. Fix: Modified the backend flow so shared items are authorized during sign item creation instead of loosening record rule for shared templates and tests task id - 6102273
This update reverts a recent change to the Belgian payroll accounting rules, specifically related to ONSS total calculations. The change was rolled back to ensure accurate reporting and compliance with Belgian tax regulations. This ensures consistent and reliable payroll processing for our Belgian clients.
This update resolves issues with inconsistent tour experiences by refining the triggers used in various Odoo modules. The changes ensure tours run reliably and predictably, leading to a smoother user experience. This primarily impacts the visual onboarding and guidance provided within Odoo.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update fixes an issue where rental order confirmations didn't properly update the status of related shifts in the planning system. Now, shifts are automatically marked as 'published' when a rental order is created, ensuring accurate status tracking and consistency with other actions. This improves the reliability of rental planning workflows.
Original PR description
**Issue 1** **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. task-5075839 Forward-Port-Of: odoo/enterprise#113286 Forward-Port-Of: odoo/enterprise#99642
This update fixes an error in the Pakistan localization payroll calculation. Previously, tax was being calculated incorrectly for employees with annual salaries exceeding PKR 2,200,000. The fix ensures accurate tax calculations based on official Pakistani tax regulations, preventing overpayment of taxes.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265** Forward-Port-Of: odoo/enterprise#112875 Forward-Port-Of: odoo/enterprise#110939
This update fixes an issue where the filter for unfinished workorders would disappear after marking an operation as complete. The fix prevents the filter from being unintentionally erased during the process of marking operations as done, ensuring users can accurately track remaining tasks. This improves the usability of the shopfloor operations module.
Original PR description
While working on a workorder from the shopfloor, if there is several operation when closing the first one, the filter will disapear Steps to reproduce: ------------------- * Create a Product * Create a BoM for that product with two operation * Create a MO for this product * Click on the smart button "Shop Floor" * Open the Operations * Mark as Done one of the operation -> the filter disappears Observation: ------------- When cliking on "mark as done" or "closing production" both goes through validate(), At the end of this function the filter is erased: https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L384 opw-5959166 Forward-Port-Of: odoo/enterprise#111333