Wednesday, July 2, 2025
18 changes · saas-18.4
New functionality added to Odoo
Adds check printing layouts tailored for Dominican Republic companies, based on the existing U.S. check printing functionality. This helps businesses in the Dominican Republic print checks directly from Odoo using localized layouts, though some layout fine-tuning may still be needed for exact paper alignment.
Original PR description
Essentially a copy of the l10n_us_check_printing module, adjusted to work with DO stuff. The layouts is adjusted to qualify as 'vaguely matching the target check layout', which I was told is enough.
Concern: I can't fit the layout closer without being able to overlay it over an example blank check background.
Concern: The width of partner address lines (ckdo_payee_addr class in print_check.xml) is a bit too limited (so even Azure Interior's ordinary address turns into a vertical mess) by the generic address line widget ir_qweb_widget_templates.xml -> <template id="contact">. Adding a width parameter directly to .ckdo_payee_addr{} in report_check_*.scss solves this, but it doesn't seem like the correct solution.
task-4290725
Forward-Port-Of: odoo/enterprise#88967
Forward-Port-Of: odoo/enterprise#75498Enhancements to existing features
Indonesian localization now displays the required DPP tax base amount on invoice forms and reports. This helps businesses comply with local tax rules where the taxable base is adjusted by 11/12 before applying the 12% tax rate.
Original PR description
Due to government regulations, tax base amount is multiplied by factor of 11/12 and tax value of 12% resulting to essentially 11% of tax. We need to display this DPP value both on invoice form view and reports 4485693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215366 Forward-Port-Of: odoo/odoo#202832
Resolved issues and error corrections
Invoice reports now show the standard invoice date and the Saudi confirmation date separately, reducing confusion when invoices are backdated. Issue dates are consistently shown using Saudi Arabia timezone, regardless of the customer’s location.
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216684 Forward-Port-Of: odoo/odoo#214937
Partner enrichment from CRM now automatically includes category tags when updating company or contact details. This saves users from manually adding missing tags and keeps enriched partner records more complete and consistent.
Original PR description
when using partner enrich from CRM category tags were not fetched now category tags are autofilled when using partner enrich from CRM --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216531 Forward-Port-Of: odoo/odoo#215807
When creating a bank account, Odoo now checks whether the same account is already linked to another partner. If a duplicate is found, users see a non-blocking warning with a link to the existing partner, helping reduce accidental duplicate records without interrupting their workflow.
Original PR description
If a bank account is already linked to a partner, display a non-blocking warning on the bank account creation form, containing a link to the other partner. task-4431041 Forward-Port-Of: odoo/odoo#216189 Forward-Port-Of: odoo/odoo#198127
Live chat agents can now send a past conversation transcript to a visitor after the chat has closed. This helps visitors receive records they may need later, while logging the resend action in the conversation for traceability.
Original PR description
**Purpose of this PR:** Agents can resend previous chat transcripts to visitors. This PR adds a 'Send Conversation' action available after the live chat is closed. Agents can enter the visitor’s email to resend the transcript, and a notification is logged in the conversation for reference. task-[4775228](https://www.odoo.com/odoo/project/1519/tasks/4775228)
Argentina B invoices for final consumers now include the required tax breakdown even when VAT is 0.00. This helps businesses produce compliant customer invoices and avoids missing tax legend information on printed PDFs.
Original PR description
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or…
### **Description of the issue/feature this PR addresses:** When doing an Invoice B to exempts customer we have a problem the RG Legend new table is not showing: this because if the VAT Content or other taxes sum is 0.0 (we are not showing any information if sums 0.0) After checking with ARCA Online PDF sxampels, and some feedback of Argentinen users, we found out that the Legend should be always present. event if the totals of theTax Breakdown are shown with 0.0 ### **Steps to reproduce** Go to an Argentina Company Create a new invoice for "Final Consumer" with document type "Invoice B" Create a product line with tax 0 (could use either VAT Exempt, VAT 0, VAT Not Taxed) Print the PDF ### **Current behavior before PR:** The PDF is NOT showing the Tax Breakdown table  ### **Desired behavior after PR is merged:** The PDF is showing the Tax Breakdown with the line VAT Content 0.0  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/207367 Forward-Port-Of: odoo/odoo#214866
This fix prevents an error from appearing in Point of Sale when a self-order is paid while the related POS configuration is open. It avoids processing empty synchronization data, making ticket printing and session updates more reliable for staff.
Original PR description
The issue is not reproducible in saas-18.2 however since the method _read_pos_record is introduced in saas 18.2 the issue could arise in this version. Step to reproduce in saas-18.3: - Make an order in self order mode - Pay it, while the linked pos config is open - A traceback will be shown in the pos config Issue: When printing the ticket on the pos config, notify_synchronisation function is called with no records in the session model. _post_read_pos_data will be called with empty data array. Fix: Prevent calling _post_read_pos_data with empty records. 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#216229
This fixes Malaysia e-invoicing so credit notes can still be reported to MyInvois even when the original invoice was not previously sent there, such as invoices created before MyInvois adoption. It also aligns the reported issue date with MyInvois requirements by using today's UTC date.
Original PR description
So far, we have enforced that credit notes must be linked to an invoice that has been sent to MyInvois. In real life, this is too strict. Users could be issuing credit notes for invoices created before MyInvois was used, in which case these must still be reported to MyInvois even though the original invoice isn't on the platform. This also fixes a small issue with the issue date, which was set to the invoice date up until now but on their platform they explicitly ask for today in UTC timezone. task-4889022 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216988 Forward-Port-Of: odoo/odoo#215347
Fixed an issue where delivery orders could calculate the wrong quantity for components in nested kit bills of materials when rounding was involved. This helps ensure inventory movements match the quantities shown in the BoM overview and prevents overstated component usage.
Original PR description
## How to reproduce - Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision - Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1" - Create Kit BoM…
## How to reproduce
- Create 3 products: "FNS" / "CMP 1" / "CMP 2", the three of them with an UoM of 2 digits precision
- Create Kit BoM for 1 Unit of "FNS" using 10 Units of "CMP 1"
- Create Kit BoM for 5000 Units of "CMP 1" using 50 of "CMP 2"
- Check "FNS" BoM Overview:
- "CMP 2" quantity shows the correct 0.10 Units (1 * 10 / 5000 * 50) (ok)
- Create Delivery order for 1 Unit of FNS
- "CMP 2" quantity is 0.50 Units (KO)
OPW-4804958
---
### BoM Overview
### BoM exploded
---
### Test result without fix:
```
2025-06-25 00:00:00,000 28629 ERROR oes_test_17 odoo.addons.mrp.tests.test_bom: FAIL: TestBoM.test_02_explode_rounding
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp/tests/test_bom.py", line 63, in test_02_explode_rounding
self.assertEqual(lines[0][1]['qty'], 0.10)
AssertionError: 0.5 != 0.1
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216709
Forward-Port-Of: odoo/odoo#215821The system now blocks E-way bill generation when the related document is not in an allowed state, such as cancelled. This helps businesses avoid creating invalid compliance documents and ensures E-way bills are generated only for finalized, valid records.
Original PR description
In this commit: --- - Introduced a validation to raise a `UserError` when attempting to generate an E-way bill if the document is not in a valid state (e.g.- `cancelled`). - This ensures E-way bills are only generated when the document is in the correct state (e.g.- `posted`) --- Forward-Port-Of: odoo/odoo#216167 Forward-Port-Of: odoo/odoo#206867
Embedded live chat calls now support picture-in-picture controls correctly. This helps visitors and agents keep video conversations visible while continuing to use the website or chat interface.
Original PR description
Forward-Port-Of: odoo/odoo#214956
Employees in Mexico with only variable pay, such as commissions or bonuses, can now have payslips generated without an error. The fix ensures the employer social security contribution calculation handles wages outside expected ranges correctly, improving payroll reliability for affected employees.
Original PR description
BUG An error is raised when trying to generate a payslip for an employee with only variable income (e.g., commissions/bonuses, no fixed base salary) FIX The rule's find_index function needs to return 0 instead of None in case the daily_wage does not fall within any of the measure ranges Task: 4723413 Forward-Port-Of: odoo/enterprise#89041 Forward-Port-Of: odoo/enterprise#85756
This fixes the conditions used to apply payroll subsidies in the Mexican payroll module. It helps ensure employee payslips calculate the subsidy only when appropriate, reducing payroll errors and correction work.
Original PR description
task-4690544 Forward-Port-Of: odoo/enterprise#84780
CSV bank statement imports now avoid failing when automatic matching encounters an issue, because matching is handled in the background after import. The reconciliation process also prevents multiple statement lines from being matched to the same already-used entry, reducing import errors and incorrect matches.
Original PR description
When doing an import of a csv in the bank rec widget, it could happens that the try_auto_reconcile throw an error which will lead in the rollback of the import. By triggering the schedule action auto_reconcile_bank_statement_line we will do the try_auto_reconcile in the back ground which will speed up the import process When importing, we pass a batch of statement lines to the try_auto_reconcile function, which identifies possible reconciliation candidates for each line. The issue arises because we iterate through each statement line and assign its potential candidate without checking for conflicts: if two statement lines map to the same candidate, we don’t verify whether that candidate has already been reconciled with a different line. opw-4888045,4890008 Forward-Port-Of: odoo/enterprise#88529
The Spanish Mod 349 BOE export now includes required rectifications when an invoice is fully cancelled by a credit note in a later period. It also prevents draft-reset invoices and credit notes from being wrongly included, improving compliance and report accuracy.
Original PR description
How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#88625 Forward-Port-Of: odoo/enterprise#86127
Users can now connect an online bank account even when Odoo Fin reports a currency that differs from existing journal or bank account entries. Instead of blocking setup with an error, Odoo skips updating the currency and lets synchronization continue.
Original PR description
This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654
Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. Only an actual customer opening the close link in the expected way will close the ticket, reducing accidental closures and support confusion.
Original PR description
Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#89026 Forward-Port-Of: odoo/enterprise#88547