Daily updates from Odoo
Monday, March 10, 2025
12 changes · 18.0
New functionality added to Odoo
This adds new Bulgarian purchase and sales ledger tax reports, helping companies meet local reporting requirements more directly in Odoo. It also adds related fields on journals and invoices/bills so the new reports can capture the needed ledger details.
Original PR description
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/enterprise/pull/74258
The point of sale customer display now shows the customer name and, on the ticket screen, the amount per guest. Refunded items are separated into their own refunds section, making the display easier for customers and staff to understand.
Original PR description
In this commit : - Show customer name on the customer Display - Show amount / guest if we are on ticketscreen - Refunded lines should be separately segregated under refunds subsection 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
Adds new purchase and sales ledger tax reports for Bulgarian localization, helping companies meet local reporting requirements more directly in Odoo. It also adds supporting company, journal, and invoice data fields so the reports can capture the required ledger information accurately.
Original PR description
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/odoo/pull/187779
Enhancements to existing features
This update lets Odoo recognize point-of-sale categories by their full hierarchy, so products can be imported into nested POS categories without errors. It improves data import reliability for businesses using multi-level POS category structures.
Original PR description
Description of the issue/feature this PR addresses: Adding new field for `_rec_name` (`complete_name`) which will be computed by hierarchy Current behavior before PR: Currently we cannot import product's POS category if it's nested. Odoo will show error because the POS category is not found Desired behavior after PR is merged: Will be able to import nested POS category --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vendor bills are now checked more broadly for potential duplicates, including when dates are missing or only the same year matches. Suspected duplicates stay visible, are highlighted in list views, and prevent automatic posting so teams can review them before payment or accounting actions proceed.
Original PR description
See commits :) Entreprise PR: https://github.com/odoo/enterprise/pull/79471
Mexican localization now recognizes received vendor bills when checking SAT status, so users can see the SAT validation field on vendor bill forms. This brings vendor bill visibility closer to the existing invoice workflow and helps accounting teams verify compliance status more easily.
Original PR description
Adding 'invoice_received' as an accepted state in l10n_mx_edi_document.py -> _update_document_sat_state and account_move.py -> _compute_l10n_mx_edi_cfdi_state_and_attachment appears to be enough to enable the SAT functionality that is already present for invoices. With account_move SAT state no longer remaining None, the SAT field on the form view shows up by itself. Concern: adding 'invoice_received' state in l10n_mx_edi_document.py -> _create_update_invoice_document_from_invoice might also be needed to keep up the consistency, but I am not certain since that appears to go farther into CFDI-side logic. task-4368532
Potential duplicate vendor bills are now kept visible even after posting, including in list views. Automatic posting is stopped when a possible duplicate is detected, helping businesses avoid accidental duplicate payments.
Original PR description
Purpose ======= Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important…
Purpose ======= Recent changes have made bill encoding easier than ever (most notably, a bill date is set by default if left empty), but offering a robust duplicate bill detection is more important than ever in the modern electronic invoicing world, where bills are more and more handled automatically. We want to make sure that: - Potential duplicates remain visible at all time, including in list view - Automated actions like auto posting are not done when a potential duplicate is detected. Specs ===== 1. Do not hide the warning on potential bill duplicate for posted invoices. The information remains pertinent. 2. When a move should be posted automatically (by the Auto-post feature on account.move or by the OCR auto-post), but a potential duplicate is found, prevent the auto-post from happening. Log the information in the chatter: "Auto-post was disabled on this invoice because a potential duplicate was detected." 3. In list view put the reference in red background when a potential duplicate on that invoice is detected. task-4578751 Community PR: https://github.com/odoo/odoo/pull/197891
Resolved issues and error corrections
Tasks created from sales orders that use quotation templates will now show the product name as the task title instead of the line description. This makes project tasks easier to identify and keeps the quotation description available in the task details.
Original PR description
### Steps to reproduce: - create a new quotation with configured quotation template - the descriptions are added by default (thanks to the template) - confirm the SO - the task is created, but it shows the description in the title (instead of the name of the product) and the description tab is empty ### Cause: In 'Quotation Templates' the description of each line is being stored under the name of 'name' so when using this quotation template in an SO the SO line name will be the template line name not the product name + the description and so when creating the task we use the name of the SO line which in that case will be the description. ### Fix: We are checking if we have a quotation template or not and if we don't we use the name of the SO line to get the name and the description of the task if we have a quotation template we use the product name for the name of the task and the name of the template line as a description. opw-4482867
Public shoppers could encounter an access error when viewing product pages that include published combo items with tax-included prices. This fix allows the page to load correctly by safely reading the needed combo product tax information.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set website to display prices tax included; 2. have a combo item published; 3. open product's eCommerce page as public user. Issue ----- Access Error. Cause ----- Commit 4ec8d2198a1a0 added a disclaimer for combo items products tax calculations. It checks the `taxes_id` fields of the `combo_item_ids`. Issue is that the `product.combo` model isn't accessible for public users (unlike `product.product` and `product.template`. Solution -------- Use `sudo` on the combo product. opw-4608719
Accounting email aliases now mark bounce messages so the system can recognize and stop repeated rerouting. This prevents potential email loops when messages without attachments are rejected, reducing unnecessary email traffic and operational noise.
Original PR description
Sending emails with no attachments now bounce when sending to account.move aliases. This can cause loops if the bounce email is then rerouted because are not using any loop detection. Added the loop detection message id to the bounce email in order to prevent any loops. opw-4576526
This fixes a problem where indenting a bullet list item while multiple people edit the same document could trigger an error for other collaborators. The editor now handles the list structure safely, reducing interruptions and improving reliability during shared editing.
Original PR description
**Problem**: When collaborating, indenting a list item (`LI`) using "Tab" causes a structural issue in the DOM. **Scenario**: 1. User C1 and C2 both edit a list item in collaboration mode. - Common…
**Problem**:
When collaborating, indenting a list item (`LI`) using "Tab"
causes a structural issue in the DOM.
**Scenario**:
1. User C1 and C2 both edit a list item in collaboration mode.
- Common structure at the beginning:
`<ul><li>[]</li></ul>`
- When C1 presses "Tab", the DOM updates to:
`<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
2. At this point C2 still has:
`<ul><li>[]</li></ul>`
3. When C2 receives a mutation update, it tries to insert:
`<ul (new)><li (new)><ul><li>[]</li></ul></li (new)></ul (new)>`
before:
`<li>[]</li>`
- **Issue**: `li` is already inside `li (new)`, causing a DOM error.
**Solution**:
- Before inserting, remove `li2`, then reinsert it at the
correct position.
- This ensures the `.before()` operation does not conflict
with `li1`.
**PS**: I adapted `createPeers` and `Wysiwygs` to make it work with
custom content and by default it will use `initialValue`, because in
this test i needed to test collaboration with `ul`, `li`.
**Steps to Reproduce**:
1. Open two tabs with the editor.
2. Create a bullet list in the first tab.
3. Press "Tab" to indent a list item.
4. Observe a traceback error in the second tab.
opw-4538671
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prDraft invoices in the Peru electronic invoicing module can now be printed correctly. The fix prevents a printing error caused by draft invoices having no invoice number yet in Odoo 18.0.
Original PR description
Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean.