Daily updates from Odoo
Monday, May 18, 2026
20 changes · master
New functionality added to Odoo
This update establishes the foundational setup for processing payroll in Oman, aligning with local labor laws. It includes a demo company, employee data, a standard working schedule, and a new salary structure with rules for bonuses, allowances, and social contributions. This provides a base for future payroll enhancements and testing within the Omani market.
Original PR description
[ADD] l10n_om_hr_payroll: base setup for Oman payroll localization [ADD] l10n_om_hr_payroll: accrual plan, SPF, Overtime, & EOS salary rules Introduce the foundational setup for the Oman payroll…
[ADD] l10n_om_hr_payroll: base setup for Oman payroll localization
[ADD] l10n_om_hr_payroll: accrual plan, SPF, Overtime, & EOS salary rules
Introduce the foundational setup for the Oman payroll localization based on Oman's Labor Law. This serves as the base for subsequent enhancements and related tasks.
The setup includes demo data, a standard working schedule, and an Omani salary structure with standard and specific rules aligned with local requirements.
The goal of this change is to establish an initial framework for the Omani localization, enabling consistent development and functional testing. Providing demo data for the company and employees facilitates immediate use and demonstration of payroll features, while the defined 9–5 working schedule (Sunday–Thursday, Asia/Oman timezone) reflects local business practices.
Technical summary:
- **Added demo company:** “My Omani Company”.
- **Added demo employees:** Linked to the company with localized education and contract data.
- **Defined standard working schedule:** (9:00–17:00, split morning/afternoon, Sunday–Thursday, Asia/Oman timezone).
- **Introduced salary structure “Oman: Monthly Pay”:** Includes standard salary rules and the following additions:
- **Bonus:** Added as an Other Input.
- **Other Allowance:** Salary input at employee level with a corresponding rule under category “Allowances”.
- **Total Wage:** New parent category grouping “Allowances” and “Basic Salary”.
- **Expenses Reimbursement:** Added as an Other Input.
- **Renamed “Taxable Salary” to “Gross”:** To align with local terminology.
- **Social Protection Fund (SPF):** Added fields and logic for Employee and Employer contributions covering Old Age, Disability and Death , Unemployment, Work Injury, Sick Leave, and Maternity.
- **End of Service (EOS):** Introduced an EOS eligibility toggle on the employee record and a "Provision Payout" salary rule category.
- **Leave Accrual:** Added an "Oman Employee Plan" with a monthly accrual of and annual sick leaves.
- **Overtime Rules:** Defined rules for Daytime, Nighttime, and Rest Day overtime within the attendance and work entry.
task-5189116
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prEnhancements to existing features
This update standardizes the handling of employee legal names (first and last) across all Odoo localization modules. Previously, each localization had unique logic for these names, leading to inconsistencies. This change aligns with a new, unified approach, ensuring accurate and consistent name formatting in payroll reports and documents for all supported countries.
Original PR description
Replace l10ns specific logic for legal first name and legal last name with the generic one introduced in https://github.com/odoo/odoo/pull/262180
This update simplifies the generation of 281.XX payroll reports by centralizing the process and improving the user interface. The changes consolidate report creation, standardize data formats, and enhance error handling, resulting in a more efficient and reliable payroll reporting system.
Original PR description
**Container, Mixin & Generation** * 281_xx is now the single entry point for all 281.xx reports. * Introduced a shared mixin (`l10n_be.281.mixin`) to centralize common logic (employee validation,…
**Container, Mixin & Generation** * 281_xx is now the single entry point for all 281.xx reports. * Introduced a shared mixin (`l10n_be.281.mixin`) to centralize common logic (employee validation, payslip filtering) and enforce a standard structure across all 281.xx forms. * Child reports (281.10, 281.45) are systematically created and linked to the container. * Forms are only generated for employees who require them (e.g., skipping 281.45 if the employee has no IP). * XML generation is centralized at the container level: subreports provide data, while the container defines header-level information. * Record names are adapted to include the year and a suffix sequence (e.g., `YEAR_281_suffix`). **UI & View Simplification** * Removed dedicated 281.10 and 281.45 form views, consolidating them into a unified container using tabs instead of smart buttons. * Updated list view to display the year as the first column, and expose reference, form types, sending type, treatment type, and state. * Introduced a shared employee declaration list view used across all 281 report types. **Sequence, Error Handling & Finalization** * The container holds the state (Draft, Error, Ready, Done). Draft state allows generating test XML; Ready state corresponds to final XML. * Validation errors from subreports are aggregated and set the container to an "Error" state, blocking the XML generation. * Confirmation wizard sets the final Belcotax reference, triggers the PDF generation, and sends the documents to the employees. Task: 5911065
This update introduces a new report required by the Slovak Financial Administration, enabling businesses to accurately file their VAT Control Statement (KVDPH). The report covers key sales and purchase data, automating calculations and ensuring compliance with Slovak tax regulations. It includes features like XML export and bad debt flagging for improved accuracy and efficiency.
Original PR description
*=l10n_eu_oss_reports This commit introduces the VAT Control Statement report (Kontrolný výkaz DPH) as required by the Slovak Financial Administration. The report covers all eight sections of the…
*=l10n_eu_oss_reports This commit introduces the VAT Control Statement report (Kontrolný výkaz DPH) as required by the Slovak Financial Administration. The report covers all eight sections of the KVDPH: - A.1: standard issued invoices to registered entities - A.2: domestic reverse-charge sales (§69) with commodity codes - B.1: reverse-charge purchases (EU acquisitions, triangular, imports) - B.2: standard domestic purchases with VAT deduction - B.3.1/B.3.2: simplified invoices (split by €3,000 threshold) - C.1/C.2: corrections to issued/received supplies (credit & debit notes) - D.1/D.2: e-KASA aggregates and other supplies (manual entry) Each section uses a custom SQL engine that handles grouping by move, partner, tax rate, and commodity tag depending on the section context. Sections A.2 and C.1 resolve product commodity codes (TK) and goods types (TD) from account tags defined in XML data. Also adds: - XML export following the KVDPH_2025 XSD schema - `l10n_sk_is_bad_debt` field on `account.move` for bad debt flagging - `l10n_sk_uom` selection on account.move.line for KVDPH unit of measure - product tag data for 54 commodity codes and 2 goods types - views to expose the new fields on invoices, journal items and products - Added dedicated return type and submission wizard with direct XML download Documentation: https://www.financnasprava.sk/sk/podnikatelia/dane/dan-z-pridanej-hodnoty/kontrolny-vykaz-dph Related: https://github.com/odoo/odoo/pull/241860 Related: https://github.com/odoo/upgrade/pull/9102 task-5213902
This update allows administrators to exclude specific employees from payruns directly within the payrun version list. When an employee's payslip is excluded from a payrun version, the payslip itself is also removed, providing greater control over payroll processing and ensuring accurate reporting.
Original PR description
This commits adds a button to the versions list in payruns to allow users to exclude employees from the payrun. If the employee has a payslip for that payrun, the payslip will also be excluded. Task-5955126
This update streamlines the calculation of prices on the website, particularly for subscription-based products. By directly using recurring plan prices when available, the system now computes prices faster and more accurately, leading to a better customer experience. The changes also incorporate updates from the Odoo community.
Original PR description
* website_sale_subscription: speed up prices computation when the plan is known When the cart already holds a recurring product (and therefore a recurring plan), it can be forwarded to the price computation logic to directly compute the right unit price (instead of the sales price). * Adapt to community changes
This update ensures compliance with UAE minimum wage laws for Emirati employees within the Odoo Enterprise HR payroll system. A warning is now displayed on payslips and the payroll dashboard if an employee's wage doesn't meet the minimum wage requirements or if their contract starts after January 1, 2026, promoting accurate payroll processing.
Original PR description
[IMP] l10n_ae_hr_payroll: minimum wage for Emirati employees Warning is added to the payslip of Emirati Employees when their wage does not satisfy minimum wage conditions and when their contract starts after 01/01/2026. task - 6110277
Resolved issues and error corrections
This update resolves a bug that prevented the JS tour for setting up overtime rules from functioning correctly. The fix ensures the tour accurately targets the correct fields and the save button is properly displayed, allowing users to successfully configure overtime rules. The test case confirms the fix.
Original PR description
Before: - Tour filled the ruleset name instead of the rule name due to selector mismatch. - Tour failed when saving ruleset because modal save did not close, hiding main save. After: - Target rule creation wizard via `.modal-dialog` selectors for accurate field editing. - Ensure modal save is clicked and form is visible before saving the ruleset. Impact: - JS tour `overtime_ruleset_flow` behaves as expected again. - Test `TestOvertimeRulesetFlow.test_overtime_ruleset_flow` passes. Task: - 5391395
This update simplifies access to Codabox transaction data. Previously, users needed write access to the company record, which wasn't necessary after the initial connection was established. This change streamlines the process and improves efficiency.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811 Forward-Port-Of: odoo/enterprise#117097
This update resolves discrepancies in order totals between Odoo and Shopee/Lazada due to rounding differences when handling marketplace discounts. The changes ensure accurate tax calculations and total amounts, improving order reconciliation and preventing financial inaccuracies.
Original PR description
Marketplace orders with discounted tax-exclusive lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee…
Marketplace orders with discounted tax-exclusive lines could not match the platform total: Odoo accumulated a small rounding residue vs Shopee's total_amount / Lazada's order price. sale_shopee ----------- - Use model_discounted_price as price_unit (discount=0) instead of a percentage discount. - Rename _recompute_subtotal to _compute_subtotal to derive tax-exclusive subtotals from tax-inclusive totals (aligned with sale_lazada). - Add _compute_reconciled_line_specs: price-include taxes keep the discounted unit price; tax-exclusive taxes use the nominal rounded tax-exclusive unit. - In _create_order_from_data, append a tax-free "Shopee Amount Adjustment" line for any residue vs Shopee total_amount. - Add a dedicated shipping line with fiscal-position-mapped taxes. - Structure SO line descriptions (SKU, promotion, original price) via _build_item_description. - Consolidate tests with build_order_mock(**extra); tax fixtures use an explicit tax group where required (Odoo 19+). sale_lazada ----------- - Port the same reconciliation model: reconciled line specs, discount=0 with discounted unit from paid_price, shipping line from shipping_fee, order-level tax-free "Lazada Amount Adjustment" vs order price. - Group by SKU: _build_item_description (SKU, voucher, original price); skip all-canceled SKU buckets. - Tests: build_order_mock(), same tax fixture pattern as sale_shopee. task-6112062
This update resolves an error that occurred when loading sample data for work orders. The issue stemmed from sample data containing missing BOM line information, which caused a system error. This fix ensures that the system only attempts to link BOM lines when they actually exist, preventing the error and allowing sample data to load correctly.
Original PR description
Currently, an error occurs when loading sample data in work orders. **Steps to Reproduce:** - Install `mrp_workorder` without demo data. - Go to `Settings` > `Users & Companies` > `Groups` and open…
Currently, an error occurs when loading sample data in work orders. **Steps to Reproduce:** - Install `mrp_workorder` without demo data. - Go to `Settings` > `Users & Companies` > `Groups` and open the `Manage Work Order Operations` group. - Add the `administrator` to the `users` list. - Open the `Shop Floor` and, if you see `Activate your Work center`, click on it and then click `Configure Later`. - Click on `Load Samples`. `AttributeError: 'NoneType' object has no attribute 'id'` After this [recent commit], sample data loading in mrp_workorder started linking Quality Points to a specific BOM line [1] using the provided sample data [2]. However, some sample entries contain None [3] as the bom_line, which raises the error [1]. This commit ensures that the BOM line ID is only set when a BOM line exists. [recent commit]: https://github.com/odoo/enterprise/commit/c2a3e89c3ff5bc201bf7307b3b7d322d7bd0eecc [1]- https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L233 [2]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L251 [3]: https://github.com/odoo/enterprise/blob/0b08377e4e485a1b1da347dd2384b6c17bbb089e/mrp_workorder/models/mrp_production.py#L242 sentry-7475493233 Forward-Port-Of: odoo/enterprise#117037
This update fixes an issue where the FEC import parser would fail due to empty lines in the input files. The change now automatically skips these empty lines, ensuring all valid FEC files are processed correctly and preventing import errors. This improves the reliability of the French localization import process.
Original PR description
It could happens that we have some empty lines in the fec files, the parser was returning an error when that happened. We still want to process the file so we will just skip the empty lines. task-6169168 Forward-Port-Of: odoo/enterprise#115758
This update corrects a problem in the French Intrastat export process. Previously, the system was missing crucial quantity data related to supplementary units when generating the DEBWEB2 XML file. This fix ensures that all relevant data is included, improving the accuracy of Intrastat reporting for French companies.
Original PR description
Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set…
Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.
Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61
opw-6139657
Forward-Port-Of: odoo/enterprise#117357
Forward-Port-Of: odoo/enterprise#117033This update resolves an issue where opening the historical payslip view for Indonesian employees was failing. The change involved updating a key reference and correcting a data structure update to ensure the view functions correctly and accurately displays payroll information.
Original PR description
The xml_id `hr_payroll.act_contribution_reg_payslip_lines` was removed in bd2a0767079, so opening the "historical lines" view from an Indonesian employee raised `ValueError: External ID not found`. Replace it with `hr_payroll.hr_payslip_line_action_report` and rename the stale context key `search_default_category_id` to `search_default_category_ids` to match the current search view's filter (the field became M2M). task-6208698
This update corrects an issue where the Website Studio XML editor incorrectly used translations for all websites, regardless of the active one. The change ensures that translations are only applied within the Website Studio's HTML/CSS editor when a specific website is selected, improving the user experience and preventing unintended translation conflicts.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should…
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. While in debug mode, enter Studio and navigate to a view that has translation terms (ex. Sale Order Form view), then open the XML editor. opw-5136124 Foward Port of https://github.com/odoo/enterprise/pull/110418 Forward-Port-Of: odoo/enterprise#116771
This update corrects a visual issue where a 'compute' button was incorrectly displayed for payslips that have already been finalized. The fix ensures this button is only shown for active payslips, improving the user experience and reducing potential confusion. This change was made to streamline the payroll process.
Original PR description
The Bug : Compute button appearing when payslips are in "done" state
The Reason : The action name of the compute button has been updated at the view level, but not the controller level,
given that the updated name doesn't appear in this list `displayHeaderButtonsTransitions`, The function
`displayButton` always return True (always displays it).
The Fix : updated the action name inside `displayHeaderButtonsTransitions`.
task - 6212789This update enhances the system's ability to accurately track employee attendance by now considering officially designated non-working days as absences. This ensures more precise reporting and analysis of employee time, leading to better workforce management decisions. The change improves the reliability of attendance data.
Original PR description
…non-working days as absence Task: 5076624
This update resolves an issue where tours in the Enterprise module were behaving inconsistently. The team refined tour triggers to ensure a more predictable and reliable user experience. This improves the overall usability and stability of the system for users.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update removes a confusing default toggle from the salary rule selection input, streamlining the process for users. The change ensures the first option is automatically selected as the default, improving usability and consistency across employee and payslip views. This simplifies the configuration of salary rules and ensures accurate payroll calculations.
Original PR description
[IMP] hr_payroll: remove salary rule selection input default
There was a default toggle in the selection input for determining the input_default_selection.
1 - I removed it and according to the sequence, the first one is selected as default.
2 - input_default_selection field is dropped.
3 - exclusive_toggle_boolean widget is deleted (its test is deleted as well)
4 - In l10n_lt_employees_salary_taxable_amount_disabled salary rule, it was including input_default_selection, that is removed.
4.1 - The sequences of hr_salary_rule_input_selection_disabled_(1,2,3) is adjusted to still satisfy the default for l10n_lt_employees_salary_taxable_amount_disabled salary rule.
task - 6023720This update simplifies the sales order form by removing a rarely used resource field. The change improves the overall user experience by decluttering the form and focusing on core sales functionality. This ensures a cleaner and more intuitive interface for sales teams.
Original PR description
Before this commit, a resource field has been introduced in sale.order.line model and added in the list view shown inside the form view of `sale.order` model. The problem is that field "pollutes a bit the form view" because that field is only useful in an use case. Since that field is not used in basic Sales flow, it is thus not needed to show it by default. This commit hides that field by default.