Daily updates from Odoo
Monday, June 29, 2026
19 changes · master
New functionality added to Odoo
This update adds the 281.18 and 274.18 payroll reports for Belgium. It helps correctly handle withholding tax reporting linked to specific special leave situations, improving compliance and payroll accuracy.
This update adds a new leave type for employees who hold an elected political mandate in Belgium. Their leave is now treated as paid at 100% and follows the usual social security and withholding tax rules, so payroll remains aligned with public reimbursement requirements.
Original PR description
Add a new work entry/time off type for employees holding an elected political mandate, who are entitled to paid leave reimbursable by the relevant public authority. - l10n_be_hr_payroll: link category_ids (REMUNERATION_BASE, ONSS_BASE, WITHHOLDING_BASE) so the leave is paid at 100% with normal ONSS and withholding tax treatment Task: 6273678 PR community: odoo/odoo#272140
This change adds a new payroll structure and rules to handle Profit Sharing Bonuses in the Belgian payroll localization. It helps ensure these bonuses are calculated and reported correctly in payroll and related DMFA documents, reducing manual adjustments and compliance risk.
Original PR description
…d rules Task: 6274909
Enhancements to existing features
This update makes payroll setup easier for new Indonesian companies by automatically assigning the correct accounting accounts to salary rules. It also combines two duplicate BPJS Kesehatan rules into one set of rules without changing the calculated amounts, which helps keep payroll configuration simpler and more consistent.
Original PR description
Configure the default debit/credit accounts for the Indonesian salary rules so new ID companies get correct payroll journal entries out of the box. We also merge the BPJS Kesehatan allowance and deduction rules that were split by payroll type despite identical logic. The kept rules now apply to both gross and gross_up, leaving amounts unchanged. Community PR: https://github.com/odoo/odoo/pull/271991 Upgrade PR: https://github.com/odoo/upgrade/pull/10620 task-6316791
The Belgian payroll payslip now shows additional employee information, including Pay Category and Joint Committee, except for company executives. It also hides the Working Schedule for company executives, making payslip details more relevant and easier to read for each employee type.
Original PR description
This PR expected to update payslip information, such as: - Add Pay Category and Joint Comitte on Payslip in the employee information, except for company executive - Hide Working Schedule if employee_type is company executive task: 6330973
This update lets users manually set the withholding tax amount directly on company executives’ records. It improves flexibility for payroll handling in Belgium by allowing special cases to be entered more accurately.
Original PR description
Now, it is possible to manually define the withholding tax amount on company executives' form. task-6306993
This update ensures shifts created from a sales order stay attached to the correct project, even if that project is created after the order is confirmed. It prevents planning from becoming disconnected from the related event, making it easier for teams to group and track all related work in one place.
Original PR description
Before commit: When a project was created from the sales order (SO) after confirmation, the shifts already created from that order could stay without project. This split planning from the event and made project grouping unreliable. After commit: Shifts now pick up the SO project whether it already exists or is created later. Planning stays tied to the right event, so teams can group and follow all related shifts from one place. task-6121471
When users place a call by clicking the phone widget, the call is now automatically logged on the related record if an activity is available. This reduces manual follow-up work and helps teams keep a complete record of customer interactions.
Original PR description
When making a call by clicking on the phone widget, we will automatically log the call on current record if activity is available for the record. Task-[6204959](https://www.odoo.com/odoo/5778/tasks/6204959)
This update makes Belgian payroll more flexible when ONSS contribution rates are not yet available. It helps payroll teams continue processing payslips and reduces interruptions caused by missing rate data.
Original PR description
task-6328029
Payroll users can now open a new Audit Trail report to quickly see which payroll values have changed. The Payroll reporting menu was also cleaned up with clearer section and item names, making navigation easier and more consistent.
Original PR description
- This report is accessible to Payroll users. They can easily identify which values have changed. To open the Audit Trail report: Payroll -> Reporting -> Audit Trail
- Also, correct the section and menu names under "Payroll -> Reporting". Rename menu items:
- New Add Payslips: - Payslip Work Days Lines -> Working Days - Payslip Other Inputs -> Other Inputs - Payslip Lines -> Payslips
task-5223898When creating a new payroll run, the system now automatically starts it the day after the last validated run for the same payroll structure. This helps keep payroll periods continuous and reduces the risk of overlapping or missing dates.
Original PR description
Set a new payrun's start date to the day immediately following the last validated payrun for the selected structure. Task-6325826
Resolved issues and error corrections
When a new language is installed, the DIAN email templates will now be translated automatically. This fixes a gap that only affected languages added after the Colombian electronic invoicing module was already in place, so users will see the templates in their chosen language without extra manual work.
Original PR description
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly…
### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment Only languages installed afterwards are affected ### Cause: The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files The `TranslationImporter` finds nothing to import for them The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed `TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced This is the standard way to push translations while preserving any manually modified values ### Notes: Languages installed before this fix are not updated Only newly installed languages will get the synced translations ### Steps to reproduce: - Install `l10n_co_dian` - Enable Developer Mode in Settings - Install any language (e.g. `fr_FR`) - Go in Settings > Technical > Email > Email Templates - Search for DIAN and open Invoice or Credit Note Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html opw-6269979 Forward-Port-Of: odoo/enterprise#120855
Users can now sort project tasks by Planned Date in the portal without encountering an error. This resolves a broken sorting option so project teams can browse tasks more reliably.
Original PR description
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`),…
Currently, an error occurs when a user sorts tasks by Planned Date. **Steps to reproduce:** - Install the `project_enterprise` module with demo data. - Go to Projects in the portal (`/my/projects`), open any `project`, and sort the tasks by `Planned Date`. KeyError: 'order' After a [recent change], the sort order is retrieved from searchbar sortings. When sorting by Planned Date, it attempts to access the order key from the corresponding sorting configuration [1]. However, the planned_date_begin entry does not define an order key [2], which raises error when it tries to access order. This commit ensures that the order key is added with its value for planned_date_begin in searchbar sorting. [recent change]: https://github.com/odoo/odoo/commit/8be5dacf9fbfe8c23b04c876994bea2ce7cbb89a [1]: https://github.com/odoo/odoo/blob/2ae9b57b86cd0bc4816ff8ec207564631baa8ad6/addons/project/controllers/portal.py#L424 [2]- https://github.com/odoo/enterprise/blob/9dd3a9b2c09a6d23a3f71d3e531edd6d78b30277/project_enterprise/controllers/portal.py#L8-L11 sentry-7556050938 Forward-Port-Of: odoo/enterprise#121230 Forward-Port-Of: odoo/enterprise#121141
This update prevents errors when Shopee sends customer identifiers that are larger than the system expected. If an ID is too large to fit in the usual field, it is now stored and matched in a different customer reference field so contacts can still be created correctly.
Original PR description
When the Shopee connector was introduced, Shopee documented `buyer_user_id` as an int32. We therefore store it in an `Integer` field, which maps to a PostgreSQL int32 column. However, feedback showed that Shopee can send ids exceeding the int32 bounds, leading to a traceback when creating new contacts. Shopee has since updated their documentation to confirm the field is actually an int64. Since we are in stable and cannot change the column type, this commit falls back to the `ref` field of the `res.partner` model to store and match Shopee contacts whose identifier doesn't fit within an int32. opw-6325948 See also: - master: https://github.com/odoo/enterprise/pull/121507 - upgrade: https://github.com/odoo/upgrade/pull/10578 Forward-Port-Of: odoo/enterprise#121707 Forward-Port-Of: odoo/enterprise#121498
This fix prevents the AI from appearing to create project tasks twice when a creation request hits an error. It now checks that the required information is valid before showing the preview or confirming the action, which makes the user experience more reliable and avoids duplicate-looking prompts.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596 Forward-Port-Of: odoo/enterprise#118044
Debit notes for Colombian DIAN now send correctly without triggering an XML template error. The system no longer includes an unnecessary buyer reference on debit notes, which prevents the document from failing during submission.
Original PR description
Issue: Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference" Steps to reproduce on…
Issue: Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference" Steps to reproduce on any database with DIAN and Colombian localization: 1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”. 2. Find a res.partner with a ref field, or add a ref field to any partner. 3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it. 4. Send that invoice to DIAN. 5. Create a Debit Note for that invoice. Use the journal created in step 1. 6. Add a product, price, and tax to the debit note. Confirm it. 7. Send the debit note to DIAN. Explanation: The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents. Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output. opw-6181039 Forward-Port-Of: odoo/enterprise#121458 Forward-Port-Of: odoo/enterprise#121422
This change corrects the rules for CP302 temporary workers so they are no longer blocked by the seniority limit that does not apply to them. It also improves when the 13th-month amount is shown, ensuring end-of-contract dates at year end are taken into account, which helps employees receive the correct benefit at the right time.
Original PR description
Temporary workers (dimona "ext") are unable to have more than 2 days of seniority, since they cannot work more than two consecutive days (see [task 6128098](https://www.odoo.com/odoo/project/1251/tasks/6128098)) Partena's CP302 sectorial documentation says that no employee can get their 13th month if they have less than 2 months of seniority. But in fact, temporary workers are exempt of that rule. Instead, they just need to work at least 44 days during the year to be eligible. This PR changes the condition, adapts the tests, and fixes one thing on when to display the 13th month: - Now, the last contract date end of the year is also considered the last work day of the year (which makes sense). Thus temporary workers may have their remaining 13th month displayed at each end of contract they get. task-6314432
This change prevents the planning feature from trying to auto-assign or send updates when a shift has no start or end date. It avoids a traceback and helps users continue working without interruption when planning information is incomplete.
Original PR description
Add a guarding condition to the auto-plan or send behavior to avoid doing those operations when no start/end dates are defined --- Task: 6312650 Forward-Port-Of: odoo/enterprise#121808
Code cleanup and technical improvements
This change removes an old website selection helper and replaces it with more explicit ways to identify the active website. It reduces ambiguity and lowers the risk of the wrong website being used in requests, tests, and backend flows.
Original PR description
Finalized the deprecation roadmap by completely removing the
`get_current_website()` method. All remaining call sites have been
migrated to use explicit, precise syntax.
Migration strategy applied:
* Standard calls now use `self.env.website`, relying on the safely
injected context.
* Complex locations requiring explicit domain-based routing fallbacks
have been replaced with `self.env.website` or `self.env['website'].browse(self.env.context.get('host_id'))`.
* This brings total clarity to the codebase, ensuring that website
resolution is explicit, predictable, and fully traceable.