Daily updates from Odoo
Thursday, June 11, 2026
9 changes · master
Resolved issues and error corrections
This change prevents the calculation of NSSF deductions for employees who are 60 years or older. It ensures accurate payroll processing and aligns with Kenyan regulations regarding retirement age and social security contributions. The system now correctly stops deductions when an employee reaches the specified age.
Original PR description
This commit refactors the document completion flow to enforce the SRP and resolve duplicate attachments on reference records. Changes include: - Moved PDF generation (`_generate_completed_documents`) from the send method directly into `_sign` to guarantee documents are built exactly when the state changes to 'signed'. - Extracted reference record updates into a dedicated `_update_reference_document` method for cleaner code structure. - Resolved duplicate attachment displays on the source record by explicitly creating the attachment once and removing the redundant `attachment_ids` from the chatter message. - Updated the completion chatter message to notify users that the files are in the attachment tray, and set the message author to the original request creator. - Overrode `_generate_done_message` to cleanly bypass generic activity messages. Task: 6127862
This update fixes an issue where the payroll system incorrectly processed employee data when the NISS (a Belgian employee identification number) was missing or formatted as '/'. The change ensures accurate date extraction for payroll calculations, particularly for employees without a standard NISS.
Original PR description
follow-up of https://github.com/odoo/enterprise/pull/116002 Steps to reproduce: - Belgian company - Have an employee with a NISS set to '/' (accepted value for no NISS) - go on the payroll dashboard `_extract_date` expects the niss that is given to be in the correct format, however the field could be empty or be '/'. This commit returns False in both those situations. no related task/ticket
This update ensures that Wijninckx contributions (code 867) are only processed for the final quarter of the year. The system now prevents incorrect declarations outside of Q4, triggering a user error and a payslip warning to avoid potential payroll issues. This improves accuracy and compliance with Belgian tax regulations.
Original PR description
The Wijninckx contribution (code 867) should only be declared on the last quarter of the year. This commit introduces a restriction to ensure this: - Triggers a UserError in the DMFA if the code 867 is used in a declaration outside of Q4. - Adds a python-based payslip warning if the `ONSSWIJNINCKX` salary rule is applied to a payslip from January to September. Task Id: 6267562
This update resolves an issue in the l10n_mx_edi module related to dependencies on PINT and CEN. The change ensures proper functionality for Mexican electronic invoicing, aligning with current tax regulations. This fix improves the reliability of the module for businesses operating in Mexico.
Original PR description
X-original-commit: 3675550ec7a8ccc0b4646f8e24aa38a3b52cf36c Forward-Port-Of: odoo/enterprise#119983
This update corrects inaccuracies in how Omani payslips are generated, specifically for employees using attendance tracking. The changes ensure that key figures like SPF and provision rules are calculated based on the employee's total paid amount, not just their hourly rate. This improves the accuracy of payroll reporting for Omani employees.
Original PR description
This commit fixes the following problems over Omani payslips: - before, when an employee had attendances as a tracking method, some of its slip lines values (such as SPF and provision rules) were computed over its hourly rate and not its total paid amount - adapted the way the overtime computation is made: if wage is hourly we just take the hourly rate and multiply it by number of overtime hours multiplied by the rate, while if wage is fixed it need to compute hourly wage, which is paid_amount / (Number of worked paid hours). task-6263732
This update addresses a previous issue where unmapped mobile carrier codes (MCCs) caused expense transactions to be rejected, leading to user confusion. Now, a warning is displayed in settings if MCCs are missing, guiding users to correctly map them and preventing future transaction rejections. This ensures smoother expense reporting and accurate financial data.
Original PR description
Before this commit: - If the default expense category was deleted or MCC mappings were manually modified, some MCC codes remained unmapped. - Transactions with unmapped MCC codes were refused without clearly indicating that the issue was due to a missing configuration. - Users could misinterpret the behavior as a feature bug, while it was actually a setup issue. After this commit: - When the Expense Card feature is activated and the account is verified, ensure that all MCC codes are mapped to an expense category. - If any MCC is not mapped, display a warning in the settings. - Clicking on 'Open MCC' should open the MCC list view filtered to show only records where “Expense Category to Use” is not set. - If a transaction is refused because of an unmapped MCC, we create the expense at the refused state without any category set, and show the refused expense message on Chatter. task-5932712
This update resolves an issue preventing users from customizing the font style of headings on the appointment page. By wrapping the heading tag in a div, the system now correctly recognizes font style changes, allowing for consistent branding and design adjustments. This ensures a better user experience for appointment scheduling.
Original PR description
*: appointment Before this commit: The page title ("Choose your appointment") on controller page "/appointment" is a bare `<h1>` element at the root of an editable arch section, and it does not offer…
*: appointment
Before this commit:
The page title ("Choose your appointment") on controller page
"/appointment" is a bare `<h1>` element at the root of an editable arch
section, and it does not offer the Font Style selector in the website
builder, preventing users from changing their headings.
The Font Style option is intentionally hidden on such elements by the
`isRetaggingSafe` check. Retagging the section root (h1 -> h2/...) is
not safe because `replace_arch_section` only saves the content of an
editable section, never its root element (see 4469b36, "only save view
section content"). As a result, a root node tag change would not be
persisted and would silently revert on save.
After this commit:
The `<h1>` is wrapped in a `<div>`. The div becomes the OE directive
section root (kept intact on save) and the inner `<h1>` becomes part of
the editable content. As a result a Font Style change becomes a child
mutation rather than a root node change.
Community PR: https://github.com/odoo/odoo/pull/261797
Upgrade PR: https://github.com/odoo/upgrade/pull/10322
Upgrade Util: https://github.com/odoo/upgrade-util/pull/441
task-[6170946](https://www.odoo.com/odoo/project/974/tasks/6170946)This update corrects a technical issue in the VAT record book export that was incorrectly displaying '01' for invoices with 'No Sujeto por reglas de localización' taxes (like Portuguese VAT). The fix ensures the correct '17' operation code is used, aligning with Spanish VAT regulations and SII reporting requirements. This ensures accurate VAT reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax…
**Steps to reproduce:** * Install the **l10n_es_edi_sii** module. * Create a **Portuguese customer**. * Go to **Settings** and enable **EU Intra-community Distance Selling**, then refresh the tax mapping. * Create a customer invoice with a **"No Sujeto por reglas de localización"** tax (e.g. **23.0% PT VAT**). * Go to **Accounting → Reporting → Tax Report → OSS Sales**. * Export the **VAT Record Books (XLSX)** file and open it. **Observed behavior:** * The "Clave de Operación" column shows "01" for lines with no_sujeto_loc taxes instead of "17". * The SII JSON for the same invoice correctly shows "ClaveRegimenEspecialOTrascendencia": "17". **Cause:** * In `_l10n_es_libros_get_common_line_vals()`, `operation_code` was computed manually as `'02' if exempt_reason else '01'`, which only handled the E2 exempt case and defaulted everything else to "01". * This missed OSS/no_sujeto_loc taxes (e.g. FR VAT, PT VAT) that should produce "17" per the Spanish VAT regime code table. **Fix:** * Extract operation code computation into a new dedicated method `_l10n_es_libros_get_operation_code()`. * For customer invoices, delegate to the existing `_l10n_es_get_regime_code()` method already used by SII, which correctly returns "17" for OSS-tagged taxes, "02" for E2 exempt, and "01" otherwise. * For vendor bills, mirror the SII logic by checking whether the invoice taxes include tags from `mod_303_casilla_10_balance` or `mod_303_casilla_11_balance` (intra-community indicators), returning "09" if so and "01" otherwise. opw-6197141,6216485 Forward-Port-Of: odoo/enterprise#119467 Forward-Port-Of: odoo/enterprise#117236
This update resolves an issue where portal users couldn't access photos attached to completed field service reports. The fix ensures that non-internal users can now view these images within the portal, improving the customer experience and providing more complete service records. This aligns with our commitment to providing a fully functional portal for our customers.
Original PR description
Photos were not accessible in the portal field service report for non-internal users. **Steps to reproduce** - Create a planning slot, set a portal user as the customer and mark the slot as "Completed". Add an image in the chatter. - Logged in with the customer's portal user account, access the field service report in the portal. The "Photos" section displays the name of the picture, but it is not possible to view it. <img width="888" height="320" alt="image" src="https://github.com/user-attachments/assets/523d1d1a-7c9c-4c9a-85f5-acd4df86d7ff" /> **Change** Similar to what is done in `project/controllers/portal.py` to give access to attachments to non-internal users from the portal, generate the necessary access tokens. opw-6236038 Forward-Port-Of: odoo/enterprise#118672