Friday, March 14, 2025
25 changes
5 changes
Enhancements to existing features
Odoo is changing its company information provider from Clearbit to Dun & Bradstreet to improve the reliability of partner and invoice data enrichment. Company logos will still come from Clearbit for now, while the main business data is fetched through the updated provider routes.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/196373 Enterprise PR: https://github.com/odoo/enterprise/pull/78489 Upgrade PR: https://github.com/odoo/upgrade/pull/7192 IAP PR: https://github.com/odoo/iap-apps/pull/984
Rental product checkout now avoids repeating stock checks already handled by the standard ecommerce flow. This simplifies the availability logic and should make cart validation faster while keeping stock controls consistent.
Ecuadorian companies can now record required dividend details when creating purchase withholdings for shareholder profit payments. This helps ensure electronic withholding documents and ATS reports include the payment date, related company income tax, and fiscal year required for compliance.
Original PR description
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. Fields required in…
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. Fields required in withholding wizard, XML and ATS report - **Dividend payment date:** it can be different to withhold date. It must be showed in ATS **`<fechaPagoDiv>`** and XML **`<fechaPagoDiv>`** - **Dividend income tax:** value of the Income Tax paid by the company that corresponds to the reported dividend. The computation of this value can be quite varied because of several parameters (exemptions, non-deductible expenses, deferred taxes, shareholder participation,annual withholding table with fixed withholding for the basic fraction, etc...). It must be showed in ATS **`<imRentaSoc>`** and XML **`<imRentaSoc>`** - **Dividend fiscal year:** The fiscal year in which earnings on the reported dividend are generated. The company could pay previous periods. It must be showed in ATS **`<anioUtDiv>`** and XML **`<ejerFisUtDiv>`** - **Show fields dividend:** Computed field to show the dividends fields. latam-865
Duplicating Helpdesk tickets and Planning shifts now avoids assigning archived users or resources. This prevents work from being accidentally assigned to people or resources that are no longer active, improving data accuracy and day-to-day operations.
Original PR description
_*=planning ### Before this commit: In Helpdesk, archived user are copied into new tickets when a ticket is duplicated. In Planning, archived resources are added to new shift entries during duplication and recurrence. ### After this commit: In Helpdesk, archived user are removed from new tickets when duplicated. In Planning, archived resources are excluded from new shift entries during duplication and recurrence. task-4419770
Resolved issues and error corrections
Manufacturing workcenter costs now use the intended hourly employee cost from the workcenter setup instead of being overwritten by an employee-specific rate. This helps keep inventory valuations using average cost and FIFO methods accurate.
Original PR description
The workcenter employee cost per hour was always being replaced by the employee's individual cost per hour, impacting the valuation of AVCO and FIFO. To fix this, if the employee's cost per hour is set in the employee form and is greater than zero, we will use the value defined in the workcenter form. task: 4300974
20 changes
New functionality added to Odoo
A new Belgian payroll module lets companies export payroll work entry data for the Prisma social secretariat. This reduces manual handling when preparing payroll submissions and helps Belgian employers share the required payroll information more efficiently.
Original PR description
Create a new module to export payroll data for Prisma. task-3750799
Enhancements to existing features
Stock transfers involving many serial numbers now validate much faster by avoiding repeated checks during inventory valuation. This reduces waiting time for warehouse and purchasing workflows, especially for large batches.
Original PR description
### Description: Validating a picking with serial numbers can be slow. This is caused by the method `_account_entry_move` which was made to be called one by one on each valuation layer. The issue is each time this method is called, it needs to check if the move is in or out, which is not optimal since each valuation layer can have the same move. ### Fix: We can't change the way `_account_entry_move` works in stable but we can batch `_is_in` and `_is_out` outside the method. This change will reduce the time taken by each `_account_entry_move` and remove unnecessary calls. ### Benchmark (in 18): | # of moves | Before | After | |---------------------|----------|---------| | 8 (with 1000 each) | 13:57 | 3:46 | | 3 (with 1489 each) | 8min | 2:53 | | 1 (with 1489) | 2:47 | 36s | ### Reference: opw-4550348
Resolved issues and error corrections
Fixed an issue where manufacturing orders could miss operations and byproducts tied to product options that do not create separate variants. This ensures production plans correctly reflect the selected product configuration, reducing manual corrections and production errors.
Original PR description
Steps to reproduce: - Create a Product with an attribute that 'Never' create variants, with two attributes - Create a Bom for that product that has: - 2 components, one restricted to the first variant - 2 operations, one restricted to the first variant - 2 byproducts, one restricted to the first variant - Set that product to MTO/Manufacture - Create a sale order for that product, and pick the first variant - Confirm the sale order and check the linked MO. Issue: Both the operation and byproduct set for that specific variant won't be in the Manufacturing Order, despite the variant-specific component being properly added. Since the requirements to skip the bom/operation/byproduct line is the same, regardless of the model, extract it and use it in the three `_skip` methods so we handle it in each case. opw-4636956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printing a delivery order for a kit no longer fails when the kit uses one unit of measure and its component uses another, such as units and kilograms. This prevents an error screen and lets warehouse users produce delivery documents as expected.
Original PR description
Steps to reproduce the bug:
- Create a storage “P1”:
- UoM: Kg
- Create a storable “Kit 1”:
- UoM: unit
- BoM:
- 1 Kg of P1
- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print
Problem:
A traceback is triggered because we try to convert 1kg to unit:
```
odoo.addons.base.models.ir_qweb.QWebException: Error while render the
template
UserError: L'unité de mesure kg définie sur la ligne de commande
n'appartient pas à la même catégorie que l'unité de mesure unités
définie sur le produit. Veuillez corriger l'unité de mesure définie
sur la ligne de commande ou sur le produit, elles doivent appartenir à
la même catégorie.
Template: stock.stock_report_delivery_has_serial_move_line
```
opw-4619140This fix ensures manufacturing labor cost entries are posted only once when a production order is validated. It prevents duplicate accounting entries in cases where extra confirmation steps, such as overconsumption warnings, appear before final validation.
Original PR description
By overriding `button_mark_done` to post labor entries, multiples entries could be posted in case of action returned (overconsumption wizard for instance) before the actual validation. This commit change the override by `_post_inventory()` which is called only once per validation. opw: 4571535 opw: 4532096 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
Invoices for Spanish freelancers using TicketBAI now show a clear warning when the required epigrafe tax activity code is missing. This prevents users from reaching submission only to receive a confusing XML schema error from TicketBAAI/Bizkaia, making the issue easier to understand and resolve before sending.
Original PR description
Previously, the epigrafe validation error was only triggered for non-'is_sale' documents. As a result, invoices without a defined epigrafe failed silently until submission to TicketBAI, causing an unclear TicketBAI error.
This fix ensures that the user error appears for invoices as well, preventing the misleading "El XML no cumple el esquema" error.
Steps to reproduce:
- Set up a Spanish freelance company
- Change tax agency to Bizkaia
- Try to send an invoice
The TicketBAi error `B4_1000001: El XML no cumple el esquema.[Linea:17 Columna:5] Error:cvc-complex-type.2.4.b: The content of element 'Ingreso' is not complete. One of '{Renta}' is expected.`
opw-4559069This fix prevents access errors when opening contacts whose billing settings depend on a related commercial partner in another company. It helps multi-company users continue viewing accessible contacts without being blocked by behind-the-scenes invoice format calculations.
Original PR description
Relevant conversation: https://github.com/odoo/upgrade/pull/7113 The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id…
Relevant conversation: https://github.com/odoo/upgrade/pull/7113
The error happens when a partner record doesn't have a company_id, making him accessible for the user, but its commercial_partner_id has a company_id that is different from the user's current company, causing an issue here:
https://github.com/odoo/odoo/blob/18.0/addons/account/models/partner.py#L643
```
File "/home/odoo/src/odoo/18.0/addons/account_edi_ubl_cii/models/res_partner.py", line 190, in _compute_invoice_edi_format
super()._compute_invoice_edi_format()
File "/home/odoo/src/odoo/18.0/addons/account/models/partner.py", line 643, in _compute_invoice_edi_format
if partner.commercial_partner_id.invoice_edi_format_store == 'none':
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4058, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4101, in fetch
raise self.env['ir.rule']._make_access_error('read', forbidden)
odoo.exceptions.AccessError: Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Omar Ahmed Omar Al Himyari (id=2) doesn't have 'read' access to:
- Contact (res.partner)
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: Overseas Warehouse Management.
```
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-prFixed an issue where POS session reports could show the counted card payment amount incorrectly after closing adjustments. This ensures business users see accurate expected versus counted payment totals when reviewing register sessions.
Original PR description
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the…
- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the session report, the difference in the card payment is not displayed correctly. It shows the expected amount as 100 and the counted amount as 100, whereas it should be expected at 100 and counted at 80. Commit https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892#diff-143d17de807d23650088a8c12f0a5b5cc2246b1b51e0bb7634e85247b6e535ea made journal entry optional for payments and removed the `synchronize_from_moves` method from `account_payment`. This mean that there is no longer a synchronization between account_payment and its potential journal entries. The source (here pos_session) is now responsible for creating and linking the moves to the payment. The amount field of account_payment, which is used to construct the session report and created in `_create_combine_account_payment` was not updated with the new balance created in `_apply_diff_on_account_payment_move`. opw-4494656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an export error that could occur when users exported fields from grouped lists, such as Lots / Serial Numbers grouped by Location. The export process now passes the expected field information correctly, preventing a traceback and allowing the export to complete.
Original PR description
**Problem**: When exporting, the field dictionary is expected to have a `type` key. However, when adding `parent_field`, the `type` value is stored in `field_type` instead of `type`, causing issues. **Solution**: Ensure that `parent_field` creates a `type` key in the dictionary. **Steps to Reproduce**: 1. Go to **"Lots / Serial Numbers"**. 2. Group by **"Location"** (or any other field). 3. Select any item from the list. 4. Open the **Export** modal. 5. In the modal: - Add **"Product/External IDs"** to the fields to export. - Click **Export**. 6. **Issue**: A traceback occurs. **opw-4563055** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event follow-up emails set to go out after registration were previously delayed until after the event had started. This fix ensures those messages are sent at the intended time, improving communication with attendees.
Original PR description
Until now, the after_sub are only sent after the start of the event
This fixes a point-of-sale loyalty issue where changing a product quantity in a specific way could fail to update the number of free products. The correction helps ensure loyalty rewards are calculated consistently during checkout.
Original PR description
This commit fixes an undeterministic behavior error in POS. Changing the number of products with "⌫", "8" does not recalculate the number of free products. To recalculate, you must type "⌫", "⌫", "1", "8". 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
Branch company users can now find and select products assigned to their parent company when using Barcode inventory counts. This fixes a product lookup issue that blocked inventory adjustments in multi-company branch setups.
Original PR description
Issue ===== When logged in a branch company, it is not possible, in the Barcode app inventory adjustment, to select a product with its `company_id` set on the parent company. How to reproduce ================ 1. Create a branch company; 2. Create a product and set its company field on parent company; 3. Select the branch company as the current user company; 4. Go to Barcode > Inventory Count > Add Product; 5. In the product field, search the parent company's product -> Nothing found. Cause of the issue ================== There was a domain on the `product_id` field who restrain products only to the current company (both for quants and stock move line.) [OPW-4603831](https://www.odoo.com/odoo/project/49/tasks/4603831)
Fixed an issue that prevented users from scanning lot numbers from the barcode kanban view. This ensures inventory teams can identify and process tracked products correctly even when lots are not tied to a specific company.
Original PR description
It doensn't work to scan a lot in the kanban view of stock.barcode. It's not recognize since the company_id is not required on the lot since 18.0 but the domain was not adapt and expect it. opw-4626206
Documents created inside a company-specific folder now automatically use that same company, restoring the expected behavior. When a folder's company is changed, the update is also applied to accessible child documents so company ownership stays consistent.
Original PR description
Documents created in a company folder should by default be assigned to the same company, as it was before sharepocalypse. Editing a folder company should then propagate to the accessible children. Task-4491333
Users working in a child company can now open the General Ledger without being blocked by access errors tied to the parent company. This improves day-to-day accounting access in multi-company and multi-branch setups for non-admin users.
Original PR description
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222
Fully discounted invoices using external tax services can still require tax, but the related accounting tax lines were sometimes missing. This fix creates the needed tax lines so journal entries better match the externally calculated tax amount and invoice total.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. We handle this case by manually creating the omitted tax lines. This is only a rough approximation but should hopefully be enough to handle these special cases. opw-4493544 [1] https://github.com/odoo/odoo/blob/9201c60f6a3a9ab6546f190cec0293eea273ce60/addons/account/models/account_tax.py#L2405-L2413 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80097.
This fixes an issue where paying multiple invoices by SEPA direct debit could create separate payments instead of one grouped payment. Keeping eligible payments grouped helps avoid unnecessary bank transaction fees and preserves the user’s chosen payment option.
Original PR description
…sepa Steps to reproduce: - have EU loca (l10n_be) - activate sepa - activate a mandate for a customer - create two invoices for this customer - in invoice list view, select the two invoices > click on pay > select sepa and group payment > create payments Issue: Two separate payments are being created, which significantly increases transaction fees. Cause: A write operation on line_ids triggers a chain of computations that deactivates group_payment. Solution: To minimize unnecessary writes, we prevent modifications when wizard.line_ids.partner_id consists of partners with valid mandates. Additionally, we explicitly include the current group_payment state in the write operation. This ensures that if multiple partners are selected—some with valid mandates and some without—the group payment setting remains correctly applied. opw-4551825
This fixes an error that could stop users from validating UK BACS Direct Debit Instructions. The change updates the accounting lookup to use the correct stored payment information, restoring the expected workflow for BACS direct debit setup.
Original PR description
### Steps to reproduce: - install "l10n_uk_bacs" - Go to Accounting > Customers > BACS Direct Debit Instruction and create a new one - Fill necessary values and validate - Traceback ### Cause: This [commit](https://github.com/odoo/enterprise/commit/54965c8d62301ba1fa8409709a1a1fd77150f722#diff-e00ec661d761679265d152ef44c96f9f1bb896e7dc148ea8ad7ce94cd3c28e11) changed the field `bacs_ddi_id` in `account.move` to a computed field and moved the storage to `account.payment`. But it did not change `_compute_from_moves` which was using SQL queries with `move.bacs_ddi_id`. So the method crashes because the table account_move does not have a column named bacs_ddi_id anymore. ### Solution: Adapt the SQL queries to use `payment.bacs_ddi_id`. opw-4593098
Commission report details now include sales that do not have a sales team, such as many POS sales, so salesperson commissions are visible consistently. Team-based commission calculations for subscriptions were also corrected to better reflect the right salespeople and teams.
Original PR description
Sales made without a team (like in POS by default) did not show up in the commission report "details". This commit backports the change made in later versions. **Steps to reproduce** - Create a commission plan for a Salesperson. - Create an invoice from a sale in POS. - The commission appears in the `sale.commission.report`, but not in the details (`sale.commission.achievement.report`) if there are other invoices for that period with a team set. opw-4488615
Service sale confirmations can now create project documents correctly in multi-company setups, even when a shared documents folder is linked to another company's website. This avoids blocking sales order confirmation with an access error during automated project setup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates…
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` has to match the website's `company_id`; - OR the website's `company_id` has to be in `self.env.companies`. The Projects folder was created without `website_id`, but was assigned company 1's website by the `_compute_website_id` method. When a document gets created by the sale order, it inherits the `website_id` of the Projects folder. Hence having a shared folder between companies can lead to access errors if the website's `company_id` isn't selected in the company selector. Solution -------- Bypass the constraint when in sudo mode, so you don't have to enable the website's company in the company selector when setting up a sale order. opw-4548619