Daily updates from Odoo
Friday, February 13, 2026
27 changes · 18.0
New functionality added to Odoo
This update introduces a new feature that allows other Odoo modules to dynamically adjust timesheet values within the helpdesk timesheet wizard. This improves the flexibility of time tracking and ensures timesheets accurately reflect the work performed across different departments. It allows for more precise reporting and integration with other business processes.
Original PR description
Add a hook in helpdesk_timesheet timer wizard for other modules to modify timesheet values.
Enhancements to existing features
This update improves the generation of XML files for HR payroll in Croatia (l10n_hr_edi) by streamlining the process and adding more robust testing. Specifically, it addresses issues with tax calculations and API compatibility, ensuring accurate and compliant payroll reporting.
Original PR description
- Improving the ubl_hr method chain to include less overrides in favor of extensions - Adding proper handling of multiple tax total and tax category nodes for hrextac - Refining docstrings and comments for ubl_hr - Adding a test with multiple tax types - Adding a test for account_edi_ubl_cii_tax_extension integration - Adjusting MER methods to correspond to API changes: fiscalization queries are now only available for own documents task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces support for the new NFC-e QR Code v3, mandated by recent regulations in Brazil. Users can now select which QR code version (v2 or v3) to use for their companies, ensuring compliance with evolving industry standards and improving POS order validation.
Original PR description
Purpose: The NT2025.001 v1.02 released QR Code v3 for NFC-e. QR Code v3 should only include the following information: - Access Key - QR Code Version - Type of Enviroment Some states/UFs are starting to enforce the new QR Code v3 and it is mandated for the industry, Produtor Rural(Pessoa Fisica). Both QR Code v2 & v3 will need to be supported. Current Behavior: Only QR Code v2 is supported and is the default. Expected Behavior: The user will have the option to specify which QR Code version for each company in settings. When the user validates a POS order, the appropriate QR code version will be generated. The default version will be QR Code v2. task-5086655
Resolved issues and error corrections
This update resolves an issue preventing a key test case for website redirection functionality. The fix ensures the test runs correctly even without the standard demo data, which previously required a specific user group to be enabled. This change is limited to versions 18.2 and earlier.
Original PR description
Commit f86f6f6a3dc6bbeb8c68308aab2462b9c7bb935d (6th February 2026) added the test test_website_force_domain_redirect but it doesn't work without demo data because it was requiring "website.group_multi_website" group to be enabled. Fix: add the group for the test case in case it's not enabled. runbot-[238897](https://runbot.odoo.com/odoo/runbot.build.error/238897) opw-5441957 Note: this was noticed in saas-18.3 forward port so this is only necessary up to saas-18.2 version. Forward-Port-Of: odoo/odoo#248304
This update resolves a delay in reading data from Toledo scales. Previously, the system waited up to one second for a response. Now, it reads the scale data until a carriage return character is received, eliminating this delay and improving responsiveness. This ensures more accurate and timely data collection from these scales.
Original PR description
Before this commit, the `_get_raw_response` method would wait until the read timed out (1 second) before returning the response. After this commit, for the Toledo scale we instead read until we reach a `\r` character, which is at the end of the response. This eliminates the 1 second delay. Enterprise: https://github.com/odoo/enterprise/pull/107241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where comments within invoice XML files, specifically added to the TaxExclusiveAmount field, were causing the system to fail to recognize invoices. The fix ensures that the system correctly parses numerical values from XML, preventing empty invoices and improving invoice upload functionality.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
This update fixes a potential error that could occur when customers refunded orders, specifically when multiple orders were associated with the same customer. The change ensures that product information is loaded before refunds are processed, preventing errors and improving the reliability of the refund process. This enhances the overall customer experience and reduces the risk of order processing issues.
Original PR description
Before this commit, it was possible the cached toRefundLines included orderlines whose products were not loaded in the POS. This would cause an error when refunding another order for the same partner. This commit ensures that the product is loaded before refunding an orderline by using a new method in the POS store that loads the product if it is not already present in the database. opw-5384010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244553
This update strengthens invoice security by preventing the use of untrusted accounts when processing inbound invoices. The team removed unnecessary calculations and logging logic, streamlining the process and relying on existing methods. This ensures invoices are handled securely and reduces potential risks.
Original PR description
fixed some tests and remove the computation logic from account_move_reversal wizard, to rely on existing compute method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247954
This update fixes an issue where the working time to assign for tasks wasn't accurately calculated when switching between companies with different holiday settings. Now, the system correctly considers company-specific holidays when determining the task's working time, ensuring accurate time tracking across multiple companies.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883
This update corrects a display issue within the Italian tax module (l10n_it_edi) where TC-XX codes weren't shown alongside pension fund type names. Previously, all other selection fields displayed codes first, but this field was an exception. This ensures accurate and consistent reporting for Italian businesses.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update resolves an issue where importing EDI invoices would fail when products were restricted to a different company. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors and improving the reliability of multi-company invoice processing. This improves data accuracy and reduces import failures.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912
Forward-Port-Of: odoo/odoo#248149This pull request fixes a problem where descriptions and product names were not consistently displayed on invoices during printing, particularly when importing factur-x e-invoices. The update ensures that complete invoice details, including descriptions and product names, are accurately printed in both standard and e-invoice formats. This improves the accuracy and clarity of invoices for customers and internal reporting.
Original PR description
**Issue 1** Steps to reproduce: - Create a new invoice - Add an invoice line, with just a description - Save - On the same line, add any product - Print Issue: Only the custom description will be visible on the line opw-5471809 --- **Issue 2** Steps to reproduce: - Import factur-x e-invoice - Print pdf Issue: Only product name will be printed, even if the invoice record include the complete description opw-5471809
This update fixes a potential issue where translation mapping could fail when the number of translated terms didn't perfectly match the base language. Now, the system gracefully falls back to the base language's values, preventing errors and ensuring more accurate translations. This improves the reliability of our translation process.
Original PR description
When the number of translated terms differs between the base language and its translation, fall back to the base value instead of attempting to map terms. This avoids potential errors and incorrect translation mappings. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor bug in the HTML editor component that was causing errors when the focus element was missing. The fix uses a technique called 'optional chaining' to safely access the previous sibling, preventing the traceback and ensuring smoother editor functionality. This improves stability and reliability of the HTML editor.
Original PR description
Before this commit: in rectifySelection, the focusTarget can be null and causing an error when calling the previousSibling After this commit: now we do an optional chaining(?.) on previousSibling task-5481248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when items were placed in packages. The fix ensures that the total weight of items within a package is correctly reflected in the delivery's shipping information, improving order accuracy and fulfillment.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#238917This update fixes an issue where the tax report (mod 390) was displaying duplicate amounts for EU import transactions. The problem stemmed from an incorrect tax tag definition within the Spanish localization module. This ensures accurate reporting of VAT on imported goods, aligning with Spanish tax regulations.
Original PR description
How to reproduce: - Install the l10n_es module - Switch to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for 0% EU G, there is two tags for the mod 390, the one for grid 26 being wrong Before: <img width="818" height="447" alt="image" src="https://github.com/user-attachments/assets/0565802d-5d98-4e0f-9e08-50776f0a5aec" /> After: <img width="834" height="443" alt="image" src="https://github.com/user-attachments/assets/89696c83-7022-439d-adaa-d456c2dbadf8" /> opw-5867849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247590
A recent test was causing build errors due to inconsistent leave requests, particularly when coinciding with legal holidays. This commit corrects the test to ensure leave is always requested for the intended date, resolving the build issues and improving test stability. This change ensures accurate leave processing during testing.
Original PR description
The test 'test_holiday_responsible_refuse_leave' is creating build errors in the runbot, it requests a leave for the current day, which can fall on a legal day off, and will then result in an error. This commit ensures the leave is consistently requested for a correct date. https://runbot.odoo.com/odoo/runbot.build.error/237917
This update corrects a technical issue that was preventing Odoo e-invoices from passing PDF/A-3 validation. The previous code incorrectly stored file sizes as text strings instead of numbers, leading to validation errors. This fix ensures our e-invoices meet industry standards for archiving, improving compliance and reducing potential issues with document processing.
Original PR description
The `/Size` parameter in embedded file `/Params` was being set using `NameObject` instead of `NumberObject`, resulting in the size value being stored as a PDF Name Object (e.g., `/19410`) rather than a numeric integer (`19410`).
This causes PDF/A-3 validators to report zero-size or invalid attachments, breaking compliance with ISO 19005-3 (PDF/A-3A).
Steps to reproduce:
- Generate an e-invoice PDF with XML attachments (e.g., Factur-X)
- Validate the PDF with veraPDF or Adobe Acrobat Preflight
- Embedded file size is reported as zero or invalid
Fix:
```diff
- NameObject('/Size'): NameObject(f"/{len(attachment['content'])}"),
+ NameObject('/Size'): NumberObject(len(attachment['content'])),
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where invoices created in foreign currencies weren't accurately displaying the converted amount in the company's local currency (Saudi Riyal) on the invoice report. The change ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for Saudi Arabian businesses using Odoo. This resolves a discrepancy in the reporting of invoice totals.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245840
This update resolves an issue where users could trigger errors when entering non-numeric values in the serial/lot number field. By changing the field's input type to 'number' and adding a keypress handler, the system now correctly validates input, preventing errors and ensuring reliable serial number generation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed. Forward-Port-Of: odoo/odoo#248221
This update corrects a bug where nodes containing directives (like 'groups') were incorrectly identified as translatable. This prevented proper translation of certain elements within the Odoo interface. The fix ensures that only standard elements are considered for translation, improving the accuracy of translated content.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag. Forward-Port-Of: odoo/odoo#246354
This update resolves a discrepancy in the scale certificate checksum, aligning it with a recent fix implemented in the core Odoo platform. This ensures accurate verification of the certificate and maintains compliance standards. The change was driven by a community-developed improvement.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413.
This update strengthens invoice security by preventing untrusted accounts from being used in 'is_inbound' invoices. The fix addresses a vulnerability that could have allowed unauthorized access. It involved updating and running tests to ensure the change is effective.
Original PR description
fixed some tests see odoo#247954 Forward-Port-Of: odoo/enterprise#106980
This update optimizes the MPS report to handle large production schedules more efficiently. By reducing unnecessary data retrieval and memory usage, the report now runs faster and avoids errors, particularly when dealing with complex inventory scenarios. This results in a smoother and more reliable experience for users.
Original PR description
Problem: When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error. Solution: We…
Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.
Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.
Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()
<table>
<tr>
<th rowspan="2"># of Production Schedules</th>
<th colspan="3">Before</th>
<th colspan="3">After</th>
</tr>
<tr>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
<th>Time</th>
<th># of Queries</th>
<th>Memory usage</th>
</tr>
<tr>
<td>20</td>
<td>22.846s</td>
<td>1,379</td>
<td>882.0MB</td>
<td>8.046s</td>
<td>1,180</td>
<td>103.4MB</td>
</tr>
<tr>
<td>300</td>
<td>41.098s</td>
<td>6,297</td>
<td>1.0GB</td>
<td>43.694s</td>
<td>5,732</td>
<td>363.5MB</td>
</tr>
<tr>
<td>1000</td>
<td>N/A (MemoryError)</td>
<td>N/A (MemoryError)</td>
<td>>2GB</td>
<td>88.416s</td>
<td>22,629</td>
<td>1.1GB</td>
</tr>
</table>
Average memory usage reduction: 75%
opw-5225472This update fixes an issue where tags and followers weren't carried over when renewing subscriptions. Now, tags added to a subscription will be included on the renewed version, and followers are correctly associated. This ensures consistent tracking and management of subscriptions.
Original PR description
This commit is a backport of https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823 and https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424.…
This commit is a backport of https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823 and https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424.
## Issue
When renewing a subscription, the tags and followers are not copied from the original subscription to the new one.
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a confirm a subscription S
- Any *Customer*
- Any *Recurring Plan*
- Any Product
- In the *Other Info* tab, add a tag T
3. There should be two followers on the subscription S: the creator of the subscription, and the customer. If it is not the case, add at least one follower.
3. Create and confirm an invoice for subscription S
4. Back on the subscription S, click *Renew*
5. **The tag T is missing on the new subscription. Also, the followers were not copied from subscription S.**
## Cause & Fix
### Tags
In `SaleOrder._prepare_upsell_renew_order_values`, tags are not part of the `values` generated when renewing a subscription:
https://github.com/odoo/enterprise/blob/a650fb74fd79965a6f0e441e61d8977c599057e6/sale_subscription/models/sale_order.py#L1149-L1171
They were added by https://github.com/odoo/enterprise/commit/245759ef82250a8eb32f38853e5c5f6aac841823:
https://github.com/odoo/enterprise/blob/245759ef82250a8eb32f38853e5c5f6aac841823/sale_subscription/models/sale_order.py#L1173-L1175
### Followers
Similarly to the tags, followers were not added/subscribed to the subscription when generating the renewed subscription. This was fixed by https://github.com/odoo/enterprise/commit/a35d64133cc3c598c66fcadc2310b0118a678424, by creating and calling the `_subscribe_followers_to_new_order(order)` after creating the new subscription (`order`):
https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L956-L958
https://github.com/odoo/enterprise/blob/a35d64133cc3c598c66fcadc2310b0118a678424/sale_subscription/models/sale_order.py#L2147-L2157
opw-5478071This update corrects a bug in the timesheet approval reminder email. The email was referencing an outdated action, which caused it to fail. This change ensures the approval reminder email functions correctly, prompting timely approvals for timesheets.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269
This update enables users to remove line items from Point of Sale (PoS) orders when the LNE certified scale module is in use. Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring data accuracy for certified transactions. This improves usability for users relying on the certified scale.
Original PR description
This PR allows the user to delete PoS orderline when using LNE certified scale module while still forbidding to manually set quantity to anything other than 0