Daily updates from Odoo
Tuesday, March 10, 2026
24 changes · saas-18.3
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 clarifies the message users receive when a live chat conversation ends. Previously, the message used ellipses, which could be confusing. Now, it clearly states 'Conversation has ended,' ensuring a better user experience.
Original PR description
This commit updates the chatbot completion message from 'Conversation ended...' to 'Conversation has ended.' The previous version used ellipses, which typically suggest an incomplete thought. Since the message is meant to clearly indicate that the conversation has concluded, the ellipses were unnecessary and potentially confusing. Forward-Port-Of: odoo/odoo#252461 Forward-Port-Of: odoo/odoo#251166
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
Previously, users couldn't search for tasks assigned to them within the Odoo portal. This update fixes a bug that prevented the 'Search In Assignees' feature from returning accurate results. Now, users can successfully find and manage tasks assigned to them through the portal.
Original PR description
Description of the issue/feature this PR addresses: - On the portal task, "Search In Assignees" always returns no tasks. <img width="1482" height="979" alt="Screenshot 2026-02-04 at 23 02 53" src="https://github.com/user-attachments/assets/263429b4-0c32-4323-bf88-2dfaf2115181" /> <img width="1430" height="943" alt="image" src="https://github.com/user-attachments/assets/3c196cc1-f12d-4064-838d-8e29914e5fab" /> Current behavior before PR: - Cannot search for tasks in the portal by assignee. Desired behavior after PR is merged: - Can search for tasks in the portal by assignee. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247239
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 resolves an issue where users without sufficient permissions to view certain dashboard data would cause the dashboard to fail to load. The fix ensures that dashboards check data access correctly, allowing users to consistently access the dashboard regardless of their permissions. This improves the overall user experience.
Original PR description
## Description When opening a dashboard, `_dashboard_is_empty()` may call `search_count()` on one of the dashboard's main data models to decide whether sample data should be loaded. If the current user does not have read access to one of these models, `search_count()` raises an access error and the dashboard loading can fail, even though the user has access to the dashboard itself. To avoid this, only unreadable models are checked with `sudo()`, while readable models are still evaluated with the current user rights. This prevents the access error in `_dashboard_is_empty()` and allows the dashboard to open instead of failing early. Task: [5905166](https://www.odoo.com/odoo/project/2328/tasks/5905166) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249784
This update fixes an issue where the 'Today' button in the Gantt view wasn't functioning properly when navigating from yesterday. The fix ensures the Gantt view accurately returns to the current date when the 'Today' button is clicked, improving usability for scheduling and reporting.
Original PR description
**Version:** 18.0 **Steps to reproduce:** - Install Attendance modules. - Navigate to yesterday using the arrow button. - Then click on Today button. **Issue:** The view does not return to the current day when Today button is clicked. **Cause:** The condition to check this scenario fails for this case. **Fix:** Updated the condition to include the this scenario. task-5451384 Forward-Port-Of: odoo/enterprise#109245 Forward-Port-Of: odoo/enterprise#103139
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 resolves a technical problem where the spreadsheet edition occasionally crashed when trying to save a thumbnail. The issue stemmed from a race condition during thumbnail creation, which could cause the spreadsheet to be unexpectedly closed. This fix ensures thumbnails are reliably saved, improving the user experience.
Original PR description
When we leave a spreadsheet, we take a screenshot of the canvas to save as thumbail. But it's sometime possible for the spreadsheet to be unmounted whe trying to screenshot it, leading to a traceback. Task: [5914708](https://www.odoo.com/web#id=5914708&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#109531
This update resolves a problem where Razorpay payments failed due to customer names containing commas or exceeding 50 characters. The fix ensures Razorpay receives only clean names (without commas) and limits them to 50 characters, preventing payment errors and improving the reliability of Razorpay transactions.
Original PR description
Steps: - Install and set up Razropay. - Create order and set customer with long name or name with comma. - Try to pay with Razorpay. Issue: - Error name is invalid. Cause: - Razorpay only take name without comma and upto 50 character, so having longer name or name with comma would cause an issue. Fix: - Replace comma with empty space and only take first 50 character of name while creating customer in Razorpay. Forward-Port-Of: odoo/odoo#252444
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 corrects a display issue on Arabic POS receipts where phone numbers were printed right-to-left. The fix ensures phone numbers are correctly formatted left-to-right in Arabic, improving the user experience for Arabic-speaking customers. The change involves adjusting the receipt header XML to explicitly set the direction for the phone number.
Original PR description
# Steps to reproduce: - Open the company, change the language to Arabic - Go to POS, open the shop - Buy anything and click on receipt # Problem: When clicking on the receipt, you would find the…
# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt
# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.
# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12
# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />
There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
get phoneText() {
return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
}
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />
**Drawback:**
- The inconsistency between how the number is stored and how we view it.
# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+ get direction() {
+ return localization.direction;
+ }
```
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
<t t-if="props.data.company.phone">
- <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ <t t-if="direction == 'ltr'">
+ <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ </t>
+ <t t-elif="direction == 'rtl'">
+ <div><t t-esc="props.data.company.phone" />Tel:</div>
</t>
</t>
```
**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability
opw-5881503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251975
Forward-Port-Of: odoo/odoo#249060This update resolves a technical issue preventing the Quote Builder from generating PDF quotes, which was causing a traceback. The fix addresses a change in the PDF library dependency, requiring a specific version (5.4.0) to ensure proper PDF form creation.
Original PR description
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall…
Issue: --- Due to this issue, generating PDF Quote using Quote Builder leads to traceback. Steps to reproduce: --- 1- Using a python 3.13 env, install requirements.txt. (You could instead uninstall pypdf2 and install pypdf==5.4.0) 2- Enable Quote Builder. 3- Create a SO and in quite builder tab, select a document. 4- Print -> PDF Quote. This will lead to traceback. Cause: --- There is a requirement change on https://github.com/odoo/odoo/pull/233600, as pypdf2 will not be supported in future. Instead we use pypdf==5.4.0. In pypdf 5.4.0 it is required to have `Fields` present in `Acro Form` (introduced in [1] v3.13.0): https://github.com/py-pdf/pypdf/blame/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/_writer.py#L1060-L1061 FIX: --- We could add an empty `fields` dictionary when it's not present. The entry should be `/Fields`: https://github.com/py-pdf/pypdf/blob/f20954f2241640feb484800e191373f8fbdfa44b/pypdf/constants.py#L362-L370 Note: --- In this fix, we replace `is_upper_version_pypdf2` with specific version comparison. To be precise `getNumPages` is depreciated in version 1.28.0 [2]. References: --- [1]- https://github.com/py-pdf/pypdf/commit/dcf997a028e993b215457c5629cb4e78186e11c0 [2]- https://github.com/py-pdf/pypdf/blob/3ab1581a51f446f86dd445662005f8747941c2b6/pypdf/_writer.py#L507-L514 opw-5784464 Forward-Port-Of: odoo/odoo#250329
A previous shortcut conflict in the asset management module caused users to incorrectly navigate to the Posted Entries view instead of the previous asset. This update resolves this issue by changing the shortcut from ALT+P to ALT+SHIFT+P, ensuring consistent and correct navigation within the asset form.
Original PR description
# How to reproduce - Have atleast two assets - Go to the last asset - Type ALT + P on your keyboard # The problem We enter the Posted Entries view instead of going to the previous asset # Why This PR (https://github.com/odoo/enterprise/pull/67840) added shortcuts to the asset form view, but used ALT + P for the Posted Entries. This shortcut is already used on all form views for the "previous page" button. After consulting with the developer of the original PR, we decided to move the Posted Entries shortcut to ALT + SHIFT + P opw-5948523 Forward-Port-Of: odoo/enterprise#109022
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 resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status is actively in progress, preventing this race condition and maintaining accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
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 ensures the Odoo spreadsheet functionality is running on the latest version of the library. This resolves a potential compatibility issue and improves the overall stability of the spreadsheet feature. The update was made by a team of developers to maintain optimal performance.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/05cefeb33a [REL] 18.3.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0bb9142855 [FIX] Model: reject data that postdate the library version [Task: 5895572](https://www.odoo.com/odoo/2328/tasks/5895572) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where the HTML editor toolbar would incorrectly appear on elements that shouldn't have formatting options. Now, the toolbar only displays for editable content, ensuring a more stable and predictable user experience within the HTML editor. This prevents unexpected formatting changes and improves overall editor functionality.
Original PR description
Current behavior before PR: - Removing formatting on a contenteditable false element infinite loop when removing format. - The toolbar could appear even when the target element had contenteditable false Desired behavior after PR is merged: - Now,the toolbar no longer opens when the selected element is contenteditable false - The toolbar is now only shown for elements with contenteditable true, except for QWeb and icon elements, where it remains accessible. task-5265416 Forward-Port-Of: odoo/odoo#248364 Forward-Port-Of: odoo/odoo#231613
This update fixes a minor display issue where a small floating-point number was appearing in down payment percentages for sale orders. The fix ensures that percentages are rounded correctly, providing a more accurate and professional presentation of payment information. This improves the user experience when accepting and paying for sales.
Original PR description
Issue: --- Due to this issue, a small floating point is shown in down payment percentage of a sale order. Steps to reproduce: --- 1- Create a sale order with lines. 2- From `other info` tab, uncheck `online signature` and check `online payment`, and set it to 14 percent. 3- Click on preview. 4- Click on `Accept & Pay`. The percentage shown is `14.000000000000002`, which is unexpected. Fix: --- By setting the percentage as `float` widget it will be rounded properly: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/odoo/addons/base/models/ir_qweb_fields.py#L185-L208 opw-5975047 Forward-Port-Of: odoo/odoo#252169
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