Monday, May 18, 2026
14 changes · saas-18.3
New functionality added to Odoo
This update allows users to correctly account for VAT credits carried forward from previous months when preparing their French tax returns. Specifically, it adds the ability to adjust for information appearing on line 25 of the return, ensuring accurate reporting of VAT credits. This improves compliance with French tax regulations.
Original PR description
This commit will add the possibility to do an adjustment on the line 25. Useful when you start using Odoo but have a VAT credit carried forward from the previous month (which should appear in box 25 of your return). task-6072474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256107
Enhancements to existing features
This update adds a test to ensure the payment data sent to Odoofin remains consistent. This safeguards against unexpected changes that could disrupt payment processing and highlights the need for corresponding updates on the Odoofin side. It’s a preventative measure to maintain reliable payment functionality.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID Forward-Port-Of: odoo/enterprise#117260
Resolved issues and error corrections
This update streamlines the self-order checkout process by skipping the payment page when the order total is zero. Previously, zero-amount orders were unnecessarily redirected, creating a clunky user experience. This change provides a smoother and more intuitive checkout flow for customers.
Original PR description
Before this commit: -------- - Self-orders with a total amount of zero are still redirected to the payment page, which was unnecessary. After this commit: -------- - The payment step is now skipped for zero-amount self-orders, providing a smoother checkout flow. task-5106938
This update simplifies the process of retrieving transaction data from Codabox. 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 an issue where the Danish EC Sales List CSV export incorrectly used 'LIST' instead of the required 'LISTE' column name. This change aligns with official Skat documentation and prevents file rejection by tax authorities. The fix was previously implemented in 19.0 and is now being re-applied.
Original PR description
### Issue: When exporting the Danish EC Sales List to CSV, the column name is `LIST` instead of `LISTE` According to the official documentation: https://info.skat.dk/data.aspx?oid=392&chk=217608 The correct value is `LISTE`, with a fixed length of 5 characters This cause rejection of the file This was already fixed in 19.0 when the two modules were merged: https://www.odoo.com/odoo/unassigned-tasks/4826286 ### Cause: The value `LIST` is hardcoded in the export https://github.com/odoo/enterprise/blob/b9e4fc1ba08db22dafd10f62a7d9159f963dc949/l10n_dk_reports/models/account_sales_report.py#L104-L107 ### Steps to reproduce: - Install `l10n_dk_reports` - Switch to DK Company - Go to EC Sales List - Download the CSV in the dropdown menu The column name should be LISTE opw-6127427 Forward-Port-Of: odoo/enterprise#116554
This update resolves an issue where archived sales teams were appearing in opportunity dropdowns. The fix removes a redundant setting that was causing this behavior, ensuring archived teams are accurately reflected when selecting a team for a new opportunity. This improves the user experience and data accuracy within the CRM.
Original PR description
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and…
When you open a contact, click the Opportunities smart button, then click New and open the Sales Team dropdown, archived sales teams show up in the list. The same thing happens for the user, tags and stage dropdowns. Creating an opportunity from the CRM app does not have this issue.
`res.partner.action_view_opportunity` sets `active_test: False` in the action context so archived opportunities show up in the list view. That context is passed down to the form opened from the action, and to every search the form runs to fill its dropdowns. So the dropdowns also return archived records.
The action's domain already has `('active', 'in', [True, False])`, which is enough to keep archived opportunities in the list on its own (the ORM only adds the "active = True" filter when `active` is not already in the domain). So we can just remove `active_test: False` from the context. This is what 18.0 was doing before https://github.com/odoo/odoo/commit/59feed9f26937ae8e2cab5cd7d2b6743ab6c0717 put the context flag back in.
The override in `website_crm_partner_assign` was setting `active_test: False` back on the action context for the same reason (so its extra search for assigned leads picks up archived ones). The flag is now applied locally on the `crm.lead` handle used for those searches, so archived leads are still found without polluting the action's context.
Steps to reproduce:
1. Archive a Sales Team in CRM > Configuration > Sales Teams
2. Open the Contacts app and pick any contact
3. Click the Opportunities smart button
4. Click "New" and open the Sales Team dropdown
=> Archived teams appear in the dropdown
Ticket [link](https://www.odoo.com/odoo/project.task/6134801)
opw-6134801
Forward-Port-Of: odoo/odoo#261300This update resolves an issue where Point of Sale orders would fail if a product used an archived unit of measure. We've now implemented a fix to load archived UOMs during the POS order process, ensuring orders can be created smoothly regardless of UOM status. This improves the reliability of the POS system.
Original PR description
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6197465 Forward-Port-Of: odoo/odoo#264441 Forward-Port-Of: odoo/odoo#263838
This update fixes a discrepancy in how contract type IDs are defined within Odoo's payroll modules, specifically impacting the Belgium localization. The definitions have been standardized to ensure accurate reporting and calculations for Belgian employees. This change ensures consistent data across all payroll versions.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#117224 Forward-Port-Of: odoo/enterprise#113244
This update resolves a confusing user experience where discount codes wouldn't re-apply after being discarded. Now, users can successfully re-apply a discarded code, ensuring rewards are correctly reflected without creating unintended side effects. This improves the overall usability of the loyalty program.
Original PR description
Issue: --- ### Steps to reproduce: 1- Create a `Discount Code` program. 2- In SO, use `Coupon Code` wizard and use the code. 3- After available rewards are shown, discard the wizard. 4- Re-apply the code. Validation Error: The promo code is already applied. As the reward is not applied, this is functionally confusing. At this point We can see the reward only inside the rewards wizard view. If we allow re-apply the code in case no reward line is created for the `rule.program_id`, we can still see the reward by re-applying the same code, without any side effects. opw-6164198 Forward-Port-Of: odoo/odoo#264105 Forward-Port-Of: odoo/odoo#261950
This update resolves an issue that prevented the correct CSV export of general ledger reports, particularly when dealing with large datasets or foreign currencies. The fix ensures accurate currency formatting and avoids errors related to inactive currencies, resulting in more reliable and complete financial reports.
Original PR description
Follow-up to 8dfe4c0, addressing four issues in `_generate_csv_lazy_export`: 1. `AttributeError: 'int' object has no attribute 'id'` when `col['currency']` is a raw integer on aggregate lines returned by `_get_lines` with `no_format=True`. 2. `KeyError` on `decimal_places_per_cur_id` when a foreign currency account uses an inactive currency. The currency lookup was built with the default `active_test=True`, excluding archived currencies. opw-5994050 Forward-Port-Of: odoo/enterprise#116853 Forward-Port-Of: odoo/enterprise#112500
This update corrects an issue where the 'Send an Email' form would display an error if the Subject field was hidden. The fix changes the field's requirement status, ensuring the form correctly validates input and prevents empty subject submissions. This improves the user experience and data integrity.
Original PR description
Cause: ====== Commit [1] kept model-required fields enabled when conditionally hidden so their default value is still submitted (needed e.g. for the "Create an Opportunity" action where the Subject…
Cause: ====== Commit [1] kept model-required fields enabled when conditionally hidden so their default value is still submitted (needed e.g. for the "Create an Opportunity" action where the Subject field has to reach the server). The Subject field of the "Send an Email" form was incorrectly flagged as `modelRequired`, but `mail.mail.subject` is not actually required on the server. As a side effect of the above commit, hiding the Subject field through visibility conditions left the empty input enabled, which then triggered the client-side "Please fill in the form correctly" error (when no default value was set) or sent an empty subject. Solution: ========= Mark the field as `required` instead of `modelRequired`: it stays required for the user when visible, but when conditionally hidden it is disabled like any other non-model-required field and excluded from submission. Steps to reproduce: =================== 1. Drop a Form snippet on a page (default action: Send an Email). 2. Edit the Subject field, set a visibility condition that is not met. 3. Save and submit the form. => "Please fill in the form correctly". [1]: https://github.com/odoo/odoo/commit/c00508f9d29d opw-6199682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue with the XML structure used for Swedish payments (l10n_se_bban). The changes ensure accurate transmission of payment data to banks like Nordea, addressing a previous incompatibility with their specific requirements. This improves the reliability of payment processing for Swedish customers.
Original PR description
Here is few fixes added to the swedish iso 20022 XML: - CdtrAgt seems to be always mandatory, change the condition in `_skip_CdtrAgt` to always use the CdtrAgt if payment_method is iso20022_se - The `_is_se_bban` is too restrictive, this should be always True when payment method is swedish iso - The `FinInstnId` node can either contain BIC or ClrSysMmbId. But as ClrSysMmbId seems to change from one bank to another, it's more relevant to always use the BIC. opw-5395736 Forward-Port-Of: odoo/enterprise#114662
This update removes unnecessary progress tracking from Odoo's automation and autovacuum processes. Previously, these tasks were incorrectly reporting progress, leading to the scheduler retrying jobs unnecessarily and causing errors. This change ensures more reliable job execution and prevents redundant processing.
Original PR description
Base automation and autovacuum should not log progress as this is makes the job scheduler think that something progresses and can be retried leading to the same error because we process the same (all) items. In general, progress numbers are only relevant for jobs that act as job queues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue where an approval rule was being applied incorrectly due to a duplicate XML ID. The change ensures that approval rules are applied correctly based on user and manager access levels, improving the reliability of the approval process. This resolves a potential inconsistency in how approvals were handled.
Original PR description
The XMLID `approval_approver_manager` was defined twice, causing the rule to be applied with the last evaluated access configuration for both `group_approval_user` and `group_approval_manager`. This commit renames the first occurrence of the duplicated XMLID to `approval_approver_user` to restore the intended separation between user-level and manager-level approval access rules. task-6095010 Forward-Port-Of: odoo/enterprise#113480