Daily updates from Odoo
Tuesday, January 13, 2026
29 changes · master
New functionality added to Odoo
This update introduces a new module specifically for India payroll, aligning salary configurations with new Indian employee pay structures. It includes features like spouse/children coverage calculations and a new Provident Fund (PF) opt-in system, ensuring accurate cost projections and compliance with Indian regulations.
Original PR description
In this PR, define new salary configuration according to new fields introduce for indian employees pay structure. Adds the new l10n_in_hr_contract_salary module with its manifest, benefit definitions, resume lines, and demo data so India-specific packages show up in the configurator. Extends the India salary configurator controller to copy tailored fields into new versions, toggle optional allowances via radio choices, recompute yearly cost deltas, and keep resume totals aligned with dependent medical insurance pricing. Updates hr.contract.salary.offer so selecting spouse/children coverage adds the true incremental cost to monthly benefits using a helper that contrasts base vs extended medical insurance. Introduces an explicit PF opt-in flag on versions/employees and wires PF employee/employer computations and serialized values to that flag, ensuring contributions drop to zero when someone opts out. task-4929771
Enhancements to existing features
This update enhances the Gantt view's visual representation of employee schedules. It now correctly displays partial working schedules with diagonal coloring, providing a clearer and more accurate view of employee availability and workload. This improves scheduling accuracy and reduces potential misunderstandings.
Original PR description
. Override the framework logic for cell coloring to apply diagonal coloring in cases of partially worked schedules. task-5470365
This update enhances the configuration of Belgian payroll data by allowing for flexible selection of ONSS categories (DIMONA and DMFA) instead of fixed codes. This change improves accuracy and compliance with Belgian regulations, particularly for employees under 18, by adding warnings for invalid category usage. The update also streamlines the calculation of required joint commission data.
Original PR description
In this commit, we introduced configurable DIMONA and DMFA categories on the employee instead of hard-coded values. The DIMONA worker type is now taken from a new “DIMONA Category” field, and the DMFA XML uses the employee’s DMFA Category instead of the fixed code 495. The Joint Commission is derived from the first 3 digits of the employee value (or 'xxx' if empty). DIMONA and DMFA categories are required only when the ONSS certificate is enabled, and a new warning is added when an invalid DMFA category is used for under-18 workers (categories 035 and 439). task-5421176
This update significantly improves the EPF Summary report, providing employees and HR with detailed information on Provident Fund (PF) and Voluntary Provident Fund (VPF) contributions. The report now generates a downloadable XLSX file with a comprehensive PF summary for each employee, ensuring accurate record-keeping and compliance.
Original PR description
This PR introduces an improved EPF Summary report, providing detailed information on employee and employer contributions to Provident Fund (PF) and Voluntary Provident Fund (VPF) accounts for a specified month or period. The report generates an XLSX file containing a comprehensive PF summary for each employee. task-4250905
This update allows staff to print visitor badges during the 'checked-in' stage of the frontdesk process, in addition to the 'planned' stage. This streamlines the visitor check-in experience and reduces the need for manual intervention. It improves efficiency and ensures visitors receive badges promptly.
Original PR description
Before: The 'Print Badge' button was only available when the visitor state was 'planned`. After: The 'Print Badge' button is now visible when the visitor state is either `planned` or `checked_in`. Task - 5382655
This update enhances the demo data for the Odoo Enterprise Mexican payroll module (l10n_mx_hr_payroll) to facilitate testing and validation. Specifically, it incorporates a realistic working schedule common in Mexican companies and supports testing the new CFDI batch generation feature, ensuring compliance with Mexican tax regulations.
Original PR description
Update the DEMO DATA so we can validate CFDI's and XML for all the PAC's and to test the new "CFDI batch generation" feature. Create a new working schedule, this schedule it's the most used in MX companies. target: 19.0 task-5239031 Forward-Port-Of: odoo/enterprise#102726 Forward-Port-Of: odoo/enterprise#100557
This update adds crucial reports for the Philippines' Computerized Book of Accounts (CBA) requirements, aligning with BIR regulations. It includes four key reports – General Ledger, Journal, and Sales/Purchase – and a new Inventory report, supporting PDF and CSV export formats for easy submission. This ensures compliance and streamlines financial reporting for Odoo Enterprise users in the Philippines.
Original PR description
# Related odoo/enterprise#103257 # Commit Messages ### [IMP] l10n_ph_reports: Add Book of Accounts to fulfill PH's CBA This commit adds the "Computerized Book of Accounts" (CBA) reports to fulfill…
# Related
odoo/enterprise#103257
# Commit Messages
### [IMP] l10n_ph_reports: Add Book of Accounts to fulfill PH's CBA
This commit adds the "Computerized Book of Accounts" (CBA) reports to
fulfill the Computerized Accounting System (CAS) requirements mandated
by the Philippines Bureau of Internal Revenue (BIR).
This includes 4* reports:
1. General Ledger
2. General Journal
3. Sales Journal
4. Purchase Journal
*The 5th report, Inventory Report, is located in `l10n_ph_reports_stock`
The BoA report primarily supports `.pdf` and `.csv` exports to fulfill
BIR requirements. BIR requires a `.dat` format for e-submission. As
there is no prescribed format, we use the subset `.csv`. We added this
as the primary export button on the reports
All Reports:
- Supports `filter_analytic_groupby`
General Ledger (GL):
- A copy of standard GL, without "Partner" and "Currency" column
General Journal:
- Akin to GL, except it shows `account.move.line` details
- Groups `account.move.line` by `account.move` by a root line. The root
line exists to make use of the "load more" function.
Sales and Purchase Journal:
- Grouped by month, Ordered by displayed name
- Custom handling of the taxes (price_include/exclude) and manual tax
override splitting
PDF:
- forces landscape printing for simplicity
- displays custom headers in `company_information` column as BIR requires:
- non-vat / vat
- company phone / mobile
- reporting period
CSV:
- Flattens any groupings into a more compact form, similar to raw data.
Technical:
- Added `res.company.l10n_ph_is_vat_registered` field for users to
control the PDF exports non-vat/vat display.
Testing:
- Every report has snapshot testing of the web view and csv export data.
- Input test data has been formulated to test key features.
task-[https://github.com/odoo-dev/enterprise/commit/45092825263b67321a135c160a70aaf6405391f5](https://odoo.com/odoo/all-tasks/4509282)
Community-odoo/odoo#232035
Co-authored-by: Nicolas Viseur <vin@odoo.com>
---
### [ADD] l10n_ph_reports_stock: Add Inventory Report to Book of Accounts to fulfill PH's CBA
CBA: Computerized Book of Accounts. Part of the requirements to fulfill
CAS (Computerized Accounting System).
This commit adds the 5th and final Book of Accounts (BoA) report:
Inventory. The report supports the custom `.csv` and `.pdf` exports like
all other BoA reports do.
Technical:
- The data is similar to /stock-report, except with only key details.
- Custom "Hide Out Of Stock" filter
Testing:
- Snapshot testing of the web view and csv export data.
- Input test data has been formulated to test key features.
task-[https://github.com/odoo-dev/enterprise/commit/45092825263b67321a135c160a70aaf6405391f5](https://odoo.com/odoo/all-tasks/4509282)
Community-odoo/odoo#232035
---
### [IMP] account_reports: support landscape printing and custom footer layout in pdf report options
- The current methods for determining when the PDF report should be
printed in landscape is insufficient and this allows custom reports to
easily force it by adding `force_landscape_printing` option in
`_custom_options_initializer()`
- It is difficult to modify the default `internal_layout` used in PDF
export. We modify `_get_layout_footer()` method to accept an optional
`options` parameter where a custom layout can be passed in via
`options['custom_display_config']['pdf_export']['internal_layout']`
- We make the `odoo.release.version` available in PDF export's
`rcontext` as it's a fairly common requirement for exported PDFs. In
particular, l10n_ph.
related task-4509282This update enhances the user experience by adding a search filter when opening records through the contact stat button. Previously, records were filtered based on action domains without a visible filter, leading to confusion. Now, users can directly see and control the search query, improving clarity and efficiency.
Original PR description
Purpose ======= Currently, when we open records of various models through the stat button from the contact form view, records are filtered based on the domain given on action, but the filter is not set so the user might find this confusing. Technical ========= Web Studio - When creating a stat button on a view using Studio, the search filter does not show if the target field is absent from the search view. Specification ============== - It adds a search filter to search the record so the user can visualize the query. - Web Studio - When creating a stat button with Studio, it will either add a search view if the model doesn't already have one, or it will add a field to the existing search view. This allows the user to set the default search using the stat button. Task-2671192
This update adds an extension number field to bank journals, specifically for Belgian IBANs synchronized with Codabox or Codaclean. This allows for accurate identification and import of bank statements by referencing a unique number found in the associated CODA file, streamlining the statement reconciliation process.
Original PR description
Bank journal can have the same bank account number, to be able to have a difference between them. We will add an extension number field on the journal that will be displayed only when having a synchronization with codabox or codaclean. This extension number can be found in the CODA file when the second line of the coda start with '12', which means that we have a belgian iban. With that we are able to know the journal to where we want to import the statement. task-5254158
This update adds a field to securely store sanitized IBANs for bank statements. This enhancement allows users to more effectively search for bank statements, regardless of whether the IBAN includes spaces, improving the accuracy of bank reconciliation processes.
Original PR description
This PR adds a field that is used to save the sanitized IBAN. This allows us to search for bank statements by IBAN with or without spaces. task-id: 4872851
This update enhances the process of fetching currency rates by prioritizing external providers and intelligently retrieving data. It now fetches rates in stages, starting with historical data and then utilizing specific APIs for daily or monthly updates, ensuring more accurate and timely currency conversions within the system.
Original PR description
When fetching currency rates, we fallback to the first existing rate if we didn't find any matches. Calling external providers to get missing rates first before we fallback. task-5046193
Resolved issues and error corrections
A technical error preventing users from booking appointments through the website has been fixed. The issue stemmed from a missing configuration update, which has now been implemented to ensure appointments can be booked correctly. This resolves a disruption in the appointment booking process.
Original PR description
Steps to reproduce ==================== 1- Create an appointment 2- Click on manage capacity 3- Go to the website and try to book an appointment 4- Traceback occurs Technical ========== Here https://github.com/odoo/enterprise/pull/86408/commits/1901670c2de667b57b647bc62b502176a0611220, we started using the range function instead of array keys, here we missed passing this range function to the template, that's why we were getting a traceback. After this commit =================== - This PR addresses the issue and resolves it by passing the range function to the template. Task-5484581
This update ensures that all fields in generated salary documents, including the legal name, now accurately reflect the applicant's updated name as entered in the Salary Configurator. Previously, documents displayed an outdated name, causing inconsistencies. This change improves data accuracy and provides a more reliable record of applicant information.
Original PR description
- When applicants updated their name in the Salary Configurator, the change was correctly reflected during the signature step. However, the generated document continued to use the original applicant name stored in the system, while only the signature block displayed the updated name. This caused an inconsistency between the document content and the signature details. - This commit ensures that the legal_name used in generated documents is updated in line with the name changes made in the Salary Configurator, keeping all displayed information consistent and accurate. Task-5374568
This update fixes an issue where payroll payments were incorrectly linked to the employee's bank account instead of the correct vendor account (like the IRS). The change ensures payments are accurately routed to the intended recipient, resolving a payment processing error. Automated tests have been added to verify this correction.
Original PR description
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying…
## Reproducing steps 1. Create a DB with demo data (hr,hr_payroll,accountant modules) 2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted") 3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050) 4. Create a new Off-Cycle Payslip : a. Payroll -> Payslips -> Payslips -> New Off-Cycle button b. Set Mitchell Admin as the employee of the payslip c. Change the Structure to "United States: Regular Pay" d. Compute Sheets 5. Create payments : a. Go to the Journal Entries linked to the payslip, and Post them b. Go back to the payslip and 'Pay' c. In the new wizard: Click on 'Create Payments' 6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!) 7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously) ## Purpose Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`. Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. ## Tests Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error. This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment. [community#235475](https://github.com/odoo/odoo/pull/235475) [task-4979220](https://www.odoo.com/odoo/action-4043/4979220) Forward-Port-Of: odoo/enterprise#103485 Forward-Port-Of: odoo/enterprise#99373
This update fixes a potential problem where users might unexpectedly gain bank access rights when a contract is signed. The change prevents this by ensuring proper authorization controls are in place, improving data security and compliance. This ensures accurate and controlled access to financial information within the HR contract management system.
Original PR description
Forward-Port-Of: odoo/enterprise#103807
This update resolves an issue in the Hong Kong payroll localization that prevented correct calculations. The team corrected a change in the underlying data structure and updated the related tests to ensure continued functionality. This ensures accurate payroll processing for employees in Hong Kong.
Original PR description
The commit https://github.com/odoo/odoo/commit/7eb89f35192ceb46f8d23f2443580c7e9b69488d changed the hr work entry leave_id field into leave_ids. The HK localization was not updated, and as it relies on this field it is no longer working. This updates the localization to fix the issue, as well as update the tests once more to fix the issues. We also add a dependency on test_l10n in the test module; and then set it as auto install to ensure it will be correctly tested on runbot.
This update resolves a bug impacting how absence data is tracked within the HR module. The fix ensures accurate recording and reporting of employee absences, improving the reliability of HR data and streamlining attendance management processes. This change was originally developed in a separate branch and now integrates into the main Enterprise version.
Original PR description
Task: 5470030 Forward-Port-Of: odoo/enterprise#103893 Forward-Port-Of: odoo/enterprise#103781
This update addresses several critical issues within the Belgian payroll module (l10n_be_hr_payroll) to ensure accurate calculations for the social balance sheet. Specifically, the system now correctly handles employees without payslips, avoids double-counting, and fixes floating-point comparison errors, resulting in more reliable reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#103786
This update resolves an error that occurred when creating attendance records using the 'Planning' work entry source. The fix corrects issues with date calculations and interval formatting, ensuring attendance records can be created successfully when using this work entry type. This improves the reliability of the attendance tracking process.
Original PR description
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to…
Currently, an error occurs when user creates an attendance with Planning as the Work Entry Source. **Steps to Reproduce([Video](https://drive.google.com/file/d/1vGIZswZ-0D_ISAKn8LltYlGgQ7gzI6oA/view)):** - Install the `hr_work_entry_planning_attendance` module. - Go to `Employees` and create a `new employee` or open an `existing one`. - In the `Payroll` section, set `Work Entry Source` to `Planning`. - Go to `Planning` and create a planning slot for this employee `(if it does not exist)` with `Allocated Time` set to less than 100%. - Go to `Attendance` and create `an attendance for this employee` within the planning slot start and end dates. **Error 1:** `AttributeError: 'method_descriptor' object has no attribute 'min'` **Error 2:** `TypeError: Intervals.__init__() takes from 1 to 2 positional arguments but 4 were given` **Cause:** When the Work Entry Source is set to Planning and an attendance is created for that employee, the system updates overtime (if any) and retrieves the scheduled working time from the planning slot. If the planning slot has less than 100% allocated time, it is split day by day, keeping only a portion of each day’s working hours based on the allocation percentage. While creating a datetime at the very start or end of a day, an error occurs due to incorrect access of the min or max attribute from datetime. Another issue occurs when creating intervals using the start and end dates: an error is raised because separate start and stop arguments are passed instead of a list of interval tuples. **Fix:** This commit ensures that the correct datetime.min.time() / datetime.max.time() values are used and that intervals are provided in a list-of-tuples format. [1]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L56-L57 [2]- https://github.com/odoo/enterprise/blob/ee8919530ef5835d539b3ade47fa450f736b22a3/hr_work_entry_planning_attendance/models/hr_employee.py#L60 **No Task ID** Forward-Port-Of: odoo/enterprise#103662
This update corrects a technical issue where the FAIA XML reports generated for l10n_lu companies weren't correctly including the `TaxBase` element when invoices had multiple taxes. This ensures compliance with Luxembourg tax reporting requirements and prevents potential reporting errors. The fix was implemented to accurately reflect product tax calculations in the FAIA XML.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#103862 Forward-Port-Of: odoo/enterprise#101178
This update resolves an issue where changing a Commission Plan's effective dates would erase associated targets and forecasts. Now, the system correctly compares new dates and removes outdated targets, ensuring accurate reporting and planning. This improves the reliability of commission calculations.
Original PR description
Before this commit, changing the Effective Period of a Commission Plan was erasing all the targets and forecast linked to that plan. After this commit, this is no longer the case as we compare if the new targets are within the range and delete the out-of-period targets. task-5469817 Forward-Port-Of: odoo/enterprise#103363
This update fixes an issue where the Helpdesk return wizard incorrectly defaulted to internal 'PICK' operations instead of the final 'OUT' operation for multi-step deliveries. The fix ensures the wizard always selects the correct, customer-facing delivery order, improving the accuracy of returns processing.
Original PR description
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a…
Steps to reproduce: - 1. Configure a warehouse for multi-step delivery (e.g., Pick + Ship). 2. Create a Sales Order for a product and fully process the delivery, including all steps. 3. Create a Helpdesk ticket for that customer. 4. From the ticket, click the "Return" button to open the wizard and select the sales order. Issue: - The return wizard incorrectly defaults to the first operation in the delivery chain (e.g., the internal 'PICK' operation) instead of the final, customer-facing 'OUT' operation. Cause: - Since picking is ordered by 'priority, scheduled_date asc, id desc', records are sorted by scheduled_date, this often resulted in selecting an internal 'PICK' operation instead of the final 'OUT' operation, making a more specific filter necessary. Fix: - The code now explicitly filters for pickings with the type code 'outgoing' and sets it as the default delivery order. task-4948134 Forward-Port-Of: odoo/enterprise#103883 Forward-Port-Of: odoo/enterprise#93154
This update resolves an issue where paid demo UrbanPiper restaurant orders couldn't be closed properly in POS sessions. By adding a payment record and assigning a payment method ID, the system now correctly handles these orders, allowing for a normal session closure and improved order management.
Original PR description
Before this commit: =================== - When closing a POS session with a paid demo UrbanPiper order in restaurant config, the session had to be force-closed because the paid UrbanPiper order did not have any related payment record. After this commit: ================== - Assign a XML ID to the delivery payment method so it can be used in a paid demo order. - Add a payment record for the demo UrbanPiper order, allowing the POS session to close normally. Task: 5454638
This update ensures that subscription sales now correctly integrate with our sale upsell features. The changes update the product field within subscriptions to align with recent updates to the sale order process, improving the overall sales experience and accuracy of subscription data. This ensures that upsells are properly reflected in subscription orders.
Original PR description
Adapt the sale product field inside subscription to adapt proper working of Sale Upsells.
This update enhances the performance of our payroll system by eliminating redundant calculations. Previously, the work time was calculated repeatedly within a loop, leading to slower processing times. This change streamlines the process, resulting in faster payroll generation.
Original PR description
Before the work time was calculated inside a for loop of worked_days, because this function can be called and is usually called by all worked_day_line_ids of a payslip, the same calculation is done multiple times. Forward-Port-Of: odoo/enterprise#102012
This update resolves an error that occurred when generating payslips for employees with secondary contracts (l10n_ke_is_secondary). A new test has been added to ensure accurate income tax calculations are performed in these scenarios. This ensures payroll processing is reliable for all employee types.
Original PR description
Computing a payslip for an employee with a secondary contract (l10n_ke_is_secondary) raised an error. An additional test was created. task-5469826
This update enhances the mobile experience by providing a more intuitive 'back' navigation system. It replaces unwanted back navigation behavior within modal windows with a native-like gesture, improving usability and reducing user confusion. This resolves previous issues impacting key workflows.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/229643 This commit expands the `useBackButton` hook to manage mobile "back" gesture and "back" navigation button. This allows modal-like components to be closed via "back" gesture, replacing the unwanted behavior of navigating back. fixes task-5041807 fixes task-4563827
This update resolves several critical issues impacting the Australian HR & Payroll module. Specifically, it corrects errors related to zeroing operations, Medicare calculations, STP reporting accuracy, and incorrect data structures, ensuring payroll processing is more reliable and compliant.
Original PR description
Tracebacks on zeroing Medicare computation to require the variation form Rounding error on STP reporting of Additional withholding task-5416549 Forward-Port-Of: odoo/enterprise#103929
This update fixes an issue where the automated PDF generation for multiple paychecks wasn't working. The problem stemmed from how the system handled multiple payslips, and the fix ensures that PDFs are correctly generated regardless of the number of paychecks being processed. This improves the reliability of payroll reporting.
Original PR description
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled…
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step) - Refuse all time off for "Anita Oliver" (to avoid side effect in next step) - Create a user for the employee "Anita Oliver" - Link the employee and the user - Create 2 payslips - 1 for "Mitchell Admin" - 1 for "Anita Oliver" - Compute sheet and confirm both payslips - Run scheduled action: "Payroll: Generate pdfs" - Nothing happens ### Cause: The traceback is raised on the line `self._get_document_partner().id` because `_get_document_partner()` can return a recordset. ### Solution: Call `ids` instead of `id`. ### Note: Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`. The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86). opw-5213979 Forward-Port-Of: odoo/enterprise#103749 Forward-Port-Of: odoo/enterprise#101911