Friday, February 13, 2026
10 changes · 19.0
New functionality added to Odoo
This update ensures Odoo's Point of Sale system in Guatemala complies with local regulations. It automatically sets a default customer, prevents invoices for unidentified customers exceeding a set threshold, and applies company-specific tax phrases, ensuring successful submission to the Guatemalan tax authority (SAT).
Original PR description
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders…
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders had no default customer. - Invoices generated for unidentified customers exceeding the legal threshold, leading to SAT rejections after submission. - GT Phrases configured on company were missing on the invoices generated through POS causing the electronic document to be rejected by SAT. After this commit: - Consumidor Final is set as the default customer on POS orders. - POS invoices cannot be generated for unidentified customers when the total exceeds the legal threshold (currently Q2500). - GT phrases configured on the company are now applied to POS invoices, ensuring valid electronic document submission to SAT. Technical Details: - Added a configurable legal threshold field on POS configuration. - Added validation to block invoicing when an unidentified customer exceeds the configured threshold. - Added a missing `super()` call in `l10n_mx_edi_pos` to ensure proper method chaining when multiple POS localizations are installed. related PR https://github.com/odoo/odoo/pull/242985 task-4393614
Resolved issues and error corrections
This update corrects a bug where holiday attest reports incorrectly rounded leave allocations (e.g., 19.5 days became 19 days). The fix replaces integer fields with float fields to accurately represent leave balances, ensuring correct reporting of holiday entitlements. This improves payroll accuracy for Belgian employees.
Original PR description
Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation). The same problem happens if the number of leaves taken is not an integer…
Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
The same problem happens if the number of leaves taken is not an integer
Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves.
- on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee.
- now click on action button -> Departure: Holiday Attests, you'll see that the employee has 19 allocated instead of 19.5
Reason : The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.
Fix : Create two new float fields leave_count_float and leave_allocation_count_float to replace their corresponding integer fields.
task - https://github.com/odoo/enterprise/commit/5461268c9411d36feac90cd45dcff42aab59599bThis update fixes an issue where multi-employee payslips were defaulting to the language of the first employee. The change ensures that each employee's payslip is printed in their correct, selected language, improving accuracy and user experience. This resolves a previous bug related to date formatting and caching.
Original PR description
Steps to detect the bug: - Install payroll - Create more than one employee with different payslip languages - Add a contract for the employees - Payroll -> Payslip -> Pay run - Create a new payroll for more than one employee - Select all the employees in the pay run - Click 'print' button - Dates for the employees that are not the first one are in the language of the first employee This commit will allow the user to create multiemployee payslips maintaining the correct selected payslip language for each one of them. The issue was caused by a cache dictionary that used only the date and date format as a key, failing to include the user language. This led the system to reuse the first translated date for all subsequent employees. opw-5865260 Forward-Port-Of: odoo/enterprise#106575
This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The change adjusts the allowed date range to align with Colombian regulations, ensuring invoices are properly processed and preventing unnecessary errors. This improves the reliability of invoice submission.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107348 Forward-Port-Of: odoo/enterprise#105763
This update fixes a discrepancy in the Belgian payroll system by updating the Annual Tax Notification (ATN) data up to 2026. This ensures accurate tax calculations for employees with company cars in Belgium, complying with current tax regulations. The change corrects a potential error impacting financial reporting and employee compensation.
Original PR description
TaskID: 5932573 Forward-Port-Of: odoo/enterprise#107237
This update resolves an issue where users with limited inventory access experienced an access error when validating recurring product deliveries. The fix addresses a permissions problem preventing access to necessary invoice data, ensuring these deliveries can be processed correctly.
Original PR description
When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error. Steps to reproduce: ------------------- * Install sales,…
When a user that only has inventory access right validate a delivery that has an recurring product it will trigger an access right error. Steps to reproduce: ------------------- * Install sales, inventory, subscription, * Create a subscription product * Create and validate a sale order with this product and a recurring plan * Connect to Odoo with an user that only has inventory user right * Validate the delivery -> Access Error Observation: ------------- When we validate the delivery,we call button_validate that will call [_action_done](https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_picking.py#L1427) During this we try retrieve invoices information [here](https://github.com/odoo/enterprise/commit/b07b1c47c97bb6d6da9fa61dacb5cba66aff2a16#diff-dbf7b40a6942fbcc81ebc4c3009a8a37a5a620cffac74889bd0ff2bccd52b1e3R30-R36). The issue is that this user doesn't have access right to several records: * sol.order_id.invoice_ids -> sale.order.invoice_ids * sol.order_id.last_invoice_date -> sale.subscription.plan opw-5869446
This update resolves a bug that prevented users from correctly applying amounts to bank reconciliation lines. The fix ensures that amounts are calculated using the correct currency (amount currency) rather than the balance, improving the accuracy of reconciliation processes. This change impacts the account reconciliation functionality.
Original PR description
In this commit: We broke the way the apply amount work, this commit will solve that. For the apply full amount, we modified the field fetch by fetchReconciledLines and also the substraction of the amount currency to use the amount currency and not the balance For the partial, keep it like before we actually take the value of the suspense so it's ok. opw-5925046 Forward-Port-Of: odoo/enterprise#107377
This update resolves an error that occurred when users disabled the 'Partners' filter in the Partner Ledger report. The fix ensures the report functions correctly regardless of whether partners are selected, preventing a system crash. This improves usability for all users.
Original PR description
Currently, an error occurs when the user opens the Partner Ledger report. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1nM6WZW0_knAoDZP0G3VZsv1RMxtY5ZEI/view)):** - Install the…
Currently, an error occurs when the user opens the Partner Ledger report. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1nM6WZW0_knAoDZP0G3VZsv1RMxtY5ZEI/view)):** - Install the `Accounting` module. - Go to `Accounting Reports` (in developer mode). - Open the `Partner Ledger report`. - Go to `Options and disable Partners`. - Now navigate to `Reporting > Partner Reports > Partner Ledger`. `KeyError: 'partner_ids'` When the user disables the Partners filter, the partner_ids key is not included in the report options. Later, when the report is opened, the system tries to add amounts from move lines without a partner and, after [this commit], attempts to access partner_ids. Since partner_ids is not present, an error is raised [1]. similar error also occurs here [2]. This commit ensures that when filter_partner is disabled, opening the report works the same way as when no partner is selected by default. [this commit]: https://github.com/odoo/enterprise/commit/2b429ec8b019df2983144dfd31193cfbd2cfd1ad [1]- https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/account_reports/models/account_partner_ledger.py#L406 [2]- https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/account_reports/models/account_partner_ledger.py#L550 sentry-7138579048
This update enables users to delete orderlines when using the LNE certified scale module in Point of Sale. Importantly, the system still prevents manual quantity adjustments beyond zero, ensuring accurate inventory tracking. This improves operational efficiency for businesses utilizing the certified scale solution.
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
This update resolves an issue where the number of rental products that could be grouped on the Gantt chart was limited. The fix adjusts a technical setting to allow for a larger group expansion, ensuring that more rental products can be displayed and managed effectively. This improves the usability of the rental scheduling feature.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Create more than 30 rental products. 2. Override or raise `group_limit` on the `sale_renting.sale_order_line_gantt_schedule` view to 40 (>= 30). 3. Open the rental schedule and group by products. Issue ----- Only 21 products expand even when the limit is increased. Cause ----- Commit 9010416881857c5b810a56e74db04a5fcd869f63 added a hard limit to the search expanding product groups, based on the gantt default limit of 20. When the gantt limit is increased, the Python limit remains. Solution -------- Increase the Python-side limit to what it was before 9010416881857c5b810a56e74db04a5fcd869f63, i.e. 80, which is the default limit at the action level. opw-5887837