Tuesday, February 3, 2026
10 changes · saas-18.3
New functionality added to Odoo
This update introduces a new field for 'CPV code' on products, addressing a requirement for B2C invoices in Romania. When enabled, the module now populates the RO-CIUS XML generated for invoices with the specified CPV code, ensuring compliance with local regulations.
Original PR description
In This PR: - We add a new module to add a new field 'CPV code' in the product. - Till now, in Odoo, customers can't input that CPV identification number on products, and the field is always left empty. That's an issue with B2C invoices, where the field is mandatory. - If the module is installed and a product with a CPV category is set on an invoice, we add the value of the CPV code in the RO-CIUS XML generated on an invoice. Task [link](https://www.odoo.com/odoo/project.task/5416833) task-5416833 Forward-Port-Of: odoo/odoo#240219
Resolved issues and error corrections
This update ensures Odoo correctly generates ZATCA XML files for non-Saudi partners by making the 'additional buyer ID' visible when operating in Saudi Arabia. It prioritizes VAT as the buyer ID if available, and uses the 'additional identification number' as a backup, ensuring compliance with Saudi regulations.
Original PR description
This commit makes l10n_sa_additional_identification_number visible for non-Saudi individuals and company partners when the active company is in Saudi Arabia and keeps the identification scheme fixed to OTH, keeping it invisible. When generating ZATCA XML for non-Saudi partners, VAT is used as the primary buyer ID if present, and fall back to the additional identification number when VAT is missing. task-4525956 Forward-Port-Of: odoo/odoo#245832
This update corrects a problem where the carrier type selection was incorrectly disabled after validating a mobile barcode. The fix ensures the carrier number input remains editable when the carrier type is changed, allowing users to accurately select and input their carrier information during the order process. This prevents data loss and improves the checkout experience.
Original PR description
carrier type After the user clicks on "Validate" button to validate the mobile barcode, the carrier type selection is disabled and the carrier type pass to the SO is None. This commit fixes the issue by instead of disabling the carrier type selection, we just set the input box of carrier number to readonly and set back the carrier number to not readonly when the user changes the carrier type to ensure the carrier number input is editable. task-5880421 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246438 Forward-Port-Of: odoo/odoo#246053
This change reverts a recent update that prevented public holidays from being correctly applied to work schedules without a company assigned. This resulted in public holidays not appearing in the Time Off dashboard and incorrectly including them in requested time off durations. The fix will be implemented directly in the 'project' module to avoid impacting other Odoo modules.
Original PR description
Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8 **Steps to reproduce** 1.…
Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).
Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration
**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51
**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.
opw-5496999
opw-5401425
Forward-Port-Of: odoo/odoo#244052This update fixes an issue where purchase orders generated through the MTO route were incorrectly using expired vendor information. Now, the system prioritizes vendors with active contracts, ensuring purchase orders are based on current supplier availability. This prevents the creation of purchase orders with outdated supplier details, improving order accuracy and supply chain efficiency.
Original PR description
_______________________________________ ## Short functional explanation of the error Let's say we have a products that has 2 suppliers. In the list of suppliers, the first one set has an expired…
_______________________________________ ## Short functional explanation of the error Let's say we have a products that has 2 suppliers. In the list of suppliers, the first one set has an expired date. If we generate a PO from an SO with the MTO route, the assigned supplier for this product will be the first one set in the list, therefore having an expired date. ## Reproduction Steps 1. Go to Inventory > Configuration > settings. Check the option Multi-Step routes. 2. Click on Configuration > routes and unarchive the Replenish On Order (MTO) route. 3. Create or use an already existing product. Go to the Inventory tab, and under Operations, check the routes Replenish on Order (MTO) and Buy. 4. Click on the Purchase tab. There, set a first vendor for which the end date is earlier than today. For the second one, set an end date for which the date is later than today. 5. Go to Sales and create a new quotation. Set a customer and add a line with the product you just set. Click confirm. A smart button 'Purchase' should appear. Click on it. ### Expected behavior The assigned vendor of the PO should be the second vendor as it isn't expired yet. ### Unexpected behavior The assigned vendor is the first vendor, expired. ## Origin of the issue When generating a PO from an SO, the partner is the person ordering the product, not the vendor. Therefore, when this code is executed: https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L62-L66 no corresponding supplier is found, as ```self._get_partner_id(procurement.values, rule)``` returns the customer and not the vendor. This leads us to the fallback: https://github.com/odoo/odoo/blob/6b677319c47baacb5bee829b7e41448dec4136eb/addons/purchase_stock/models/stock_rule.py#L68-L72 which doesn't take into account the end date of vendors. __ opw-5030849 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245313 Forward-Port-Of: odoo/odoo#225684
This update corrects a bug where canceled refunds were incorrectly included in global invoices generated from Point of Sale (PoS) orders. The fix filters out canceled refund lines during invoice generation, ensuring accurate reporting and invoicing for Mexican VAT (EDI) transactions. This improves data integrity and compliance.
Original PR description
When generating global invoices for orders in the PoS, refund of those orders are also included in the global invoice. However, if the refund has been canceled, it should not be included in the global invoice. Steps to reproduce: ------------------- * Create a PoS order and validate it. * Go to the backend and create a refund for that order. * Cancel the refund. * Go to the PoS order list and select the original order * Click on "Generate Global Invoice" > Observation: The canceled refund is included in the global invoice. Why the fix: ------------ We simply filter out the canceled orders when searching for refunded order lines. opw-5492576 Forward-Port-Of: odoo/enterprise#105959 Forward-Port-Of: odoo/enterprise#105868
This update resolves a bug where the timer stopped appearing for survey participants after submitting their answers in live sessions. The fix ensures the timer correctly displays for the intended time limit, improving the participant experience and data accuracy. This change was made to align the survey logic with live session behavior.
Original PR description
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a…
Description of the issue/feature this PR addresses: Fixes timer not showing to participants of a live session after submitting an answer. Current behavior before PR: Steps to reproduce: Create a Survey with two questions of any type. Set some Question Time Limit on both. Create Live Session for that Survey. Access Live Session as a participant. Start Survey as the host. The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question. Bug: timer for the second question does not appear to the participant. Desired behavior after PR is merged: Fix: The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function. Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function. This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress` and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'` Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246147 Forward-Port-Of: odoo/odoo#241086
This update resolves an issue where customers receiving invoices through Peppol were receiving multiple copies of the same invoice. The root cause was a technical glitch in how Odoo handles invoice creation with EDI API calls, leading to repeated sending. This fix ensures invoices are sent only once, improving efficiency and accuracy for Peppol customers.
Original PR description
Steps to reproduce: - Set up a test company with Peppol enabled - Create a Peppol customer and ensure they can receive invoices - In the POS settings, enable the “Self-service invoicing” option - Create a POS order linked to the Peppol customer - Log in as this customer - Enter the POS order information to access the invoice download view (from /pos/ticket) - Repeatedly click the “Request invoice” button - On the Peppol side, you will notice that the same invoice is sent as many times as the button is clicked Why ? This error is not really Peppol related, it can actually happen with all EDI making API call: the transaction is rolled-back when Odoo tries to create multiple invoices with a serialization error but the API call happened so, in this cas, the invoice is sent over Peppol. opw-5469467 Forward-Port-Of: odoo/odoo#246731
This update resolves an access error that occurred when cancelling subscriptions for internal users (like 'Mitchel Admin'). The fix uses 'sudo' to allow necessary changes to the partner record, ensuring the cancellation process functions correctly. This prevents disruptions to subscription management.
Original PR description
*: sale_subscription_partnership To reproduce: ============= 1/ be sure Marc Demo has only sales admin righ 2/ as admin create a subscription with customer = Mitchel Admin (or other internal user) and confirm it (only confirm, do not invoice) 3/ as demo, cancel the SO => Acccess error on res.user Problem: ======== When cancelling a subscription we want to write some fields on the partner related to the SO. If the partner is an internal user, and the current user has no access to write on res.users, we get an access error. Solution: ========= Use sudo when writing on the partner when cancelling a subscription. opw-5857627
This update resolves an error in the calculation of secondary contract payslips for Kenyan companies. The fix replaces a missing variable with the total taxable gross, ensuring accurate payroll processing for employees on secondary contracts. This improves the reliability of payroll reporting for our Kenyan customers.
Original PR description
Steps to reproduce: With a Kenyan company, create an employee. Check the "Secondary Contract" on the employee form view. Create a payslip and compute. There is an error in the payslip computation. Cause: There is an undefined variable "remaining_gross". Fix: Replace it by the total taxable gross. Task: 5462310 Forward-Port-Of: odoo/enterprise#103229