Wednesday, December 3, 2025
13 changes · saas-18.4
Enhancements to existing features
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new feature has been added for Belgium, leveraging the VAT number to automatically identify the Peppol identifier, streamlining data entry and validation.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#238251 Forward-Port-Of: odoo/odoo#233160
Resolved issues and error corrections
This update resolves an issue where duplicate account IDs were causing data overwrites. The changes accurately reflect new Singapore tax specifications by segregating CPF and SHG accounts and adjusting account numbers. This ensures accurate financial reporting for Singapore businesses.
Original PR description
Two accounts were using the same XML ID `account_account_864`, causing second definition to overwrite the first. This commit resolves the duplication and updates/segregates accounts for CPF and SHG according to new specifications.
Changes:
- Update `account_account_864` (Employee Expense) to `account_account_866`.
- Update in accounts:
* 862 → CPF Withheld (Employee)
* 863 → CPF Accrued (Employer)
* 864 → SHG Withheld (Employee)
* Add new 865 → SDL Accrued (Employer)
* 859 → CPF Employer Expense
* 860 → SDL Employer Expense
* Removed 861
- Fix `transfer_account_code_prefix` in the template:
* Change from `101100` to `10110` to avoid generating 7-digit account codes.
task-5360160
Forward-Port-Of: odoo/odoo#238264
Forward-Port-Of: odoo/odoo#237506A technical error was preventing users from correctly adjusting salary benefits during the offer generation process. This update resolves a 'TypeError' that occurred when a specific benefit type ('Always Selected') was used, ensuring the salary package website page functions smoothly for all users. This improves the user experience and prevents potential data inconsistencies.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update fixes an issue where discounts on purchase orders weren't correctly reflected in accrued expense entries. The system now accurately displays the total tax excluding the discount, ensuring accurate financial reporting. This resolves a discrepancy between the purchase order and the expense record.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848 Forward-Port-Of: odoo/odoo#229441 Forward-Port-Of: odoo/odoo#225375
This update fixes an issue where Argentinian invoices weren't correctly displaying taxes in the company's local currency, even when the setting was enabled. The previous code was unintentionally removing the tax section. This change ensures invoices accurately reflect tax amounts in the appropriate currency for Argentinian businesses.
Original PR description
**Steps to reproduce:** - Install l10n_ar - Switch to a Argentinian company (e.g. (AR) Responsable Inscripto) - In Accounting settings, enable "Taxes in company currency" option - Activate another currency (e.g. USD) - Create an invoice in USD - Confirm the invoice - Print the invoice **Issue:** The section showing the taxes in the company currency doesn't appear on the invoice despite the enabled option. Cause: An override of "report_invoice_document" from l10n_are is removing the section no matter what the configuration. **Solution:** Do not remove the section. It was done originally in 17.0 where "Taxes in company currency" option didn't exist. opw-5351010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238204
This update resolves an issue where PayPal payments were failing due to missing shipping address information. The fix adds a default value to shipping address fields, ensuring PayPal transactions can proceed smoothly. This improves the reliability of our payment processing system.
Original PR description
Paypal was failing when the address fields were `False` **Solution:** Add a fallback to missing fields in the shipping address Fixes: https://github.com/odoo/odoo/issues/237360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238340
This update resolves an issue where administrators could still access documents from archived companies within the Documents app. The fix ensures that archived company folders are excluded from the admin search, maintaining data privacy and security. This prevents sensitive information from being inadvertently viewed by non-admin users.
Original PR description
**Steps to reproduce:** - Install Documents app - Create a bunch of companies with their own folders - Archive the companies - Try to open Documents app with admin - Access Error is raised **Issue:** Archived companies not properly taken into account in the search permission. **Fix:** Explicitly check of archived status for the folders company. The behavior is that normal users won't see documents from archived companies but admins still can. From related PR: > Also need to ensure archived companies are not removed from the admin search > domain even if the user has `active_test=False` related: https://github.com/odoo/enterprise/commit/b7e6acba60e50c86627b177a86b357d2bb956cbc opw-5127040 Forward-Port-Of: odoo/enterprise#100652 Forward-Port-Of: odoo/enterprise#100133
This update fixes a bug where reverse charge tax amounts were incorrectly recorded as debits when creating invoices with down payments from sales orders. The change ensures the tax amount is correctly applied to the credit side, aligning with accounting regulations and improving invoice accuracy. This resolves issue OPW-5172402.
Original PR description
When creating an invoice with down payment from a sales order, the reverse charge tax amount goes into the debit side. Make sure the reverse charge tax amount goes into the credit side. opw-5172402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237557
This update fixes a usability issue where replying to messages with only attachments didn't clearly show the original message being responded to. Now, users will always see the context of the message they're replying to, regardless of whether they include text or attachments, leading to a smoother and more intuitive communication experience.
Original PR description
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent…
**Description of the issue/feature this PR addresses:** ---------------------------------------------- Currently, when replying to a message with only attachments (no text content), the parent message context is not displayed. This makes it unclear which message the user is replying to when they only attach files without typing any text. **Current behavior before PR:** ---------------------------------------------- - Reply messages with only attachments do not show the parent message context - Users cannot see what message they are replying to when only attaching files - The MessageInReply component is not rendered for attachment-only replies **Desired behavior after PR is merged:** ---------------------------------------------- - Reply messages with only attachments now display the parent message context - Users can clearly see what message they are replying to, even with only attachments - The MessageInReply component renders consistently for all reply types - Visual structure maintains proper Odoo message styling - Better user experience with clear reply context Task-5109159 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238066 Forward-Port-Of: odoo/odoo#230574
This update resolves an issue where Sale Orders with lot-tracked products were incorrectly duplicated when imported into POS. The fix prevents unnecessary line splitting during import, ensuring accurate order processing and avoiding data inconsistencies. This improves the reliability of the POS system when handling lot-based inventory.
Original PR description
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the…
## Issue: After confirming a Sale Order for a lot-tracked product (in grams for example) and having available quantities, importing the SO in POS duplicates the order lines ## Cause: In the `settleSO` function, the line is first split because the UoM differs and is not `pos_groupable` Among the default UoMs, only Units, Pack of 6, and Dozen have `is_pos_groupable` = True, meaning most other UoMs will trigger a line split After duplicating the line due to the UoM split, an additional line is then added for each lot to link, causing duplicate entries in the POS order ## Steps to reproduce: - In Settings, enable Lots & Serial Numbers and Units of Measure & Packagings - Create a Product (Tracking: Lot, Sale Unit: g) - Update the Quantity On Hand (Lot: "LOT", Quantity: 5) - Create and confirm a Sale Order for the product (Quantity: 2) - Open POS and import the SO - Before the fix, there is 3 lines (2x no lots, 1x with lot + qty 2 ## Other issues: - The discount was not imported on the lot lines - Some lines were missing when importing lines where part of the quantity had no available lot - (This fix was already made in PR: https://github.com/odoo/odoo/pull/229075/files but was not forward-ported) opw-5018295 Forward-Port-Of: odoo/odoo#238237 Forward-Port-Of: odoo/odoo#234165
This update corrects a previous issue where an IoT printer was still loaded when both an IoT and ePos printer were set up. Now, the system automatically prioritizes the ePos printer, ensuring the correct printer is used as intended. This improves the user experience and prevents errors.
Original PR description
When setting an IoT printer and an ePos printer, a message is displayed to inform the user the ePos printer will be used. However, this is not the case and the IoT printer is still loaded. We now avoid loading if there already is a printer.
This update corrects a bug that caused inconsistent start dates for financial returns due to reliance on the current date. The fix ensures returns are generated with the correct fiscal year start date, regardless of the current date. This improves the accuracy of financial reporting across Belgium, New Zealand, and the UK.
Original PR description
compute_fiscalyear_dates using date.today() is wrong and can lead to different start_dates depending the current date. For instance if we create a custom fiscal_year from sept 2025 to Dec 2025 and we are currently the 10th Sept 2025. Then, we try to generate a return for January. The start date would be set to the 1st Sept. Then later, when trying to generate the same return for January 2025 but being after that custom fiscal year (for instance 20th January 2026), We get a completely different start date. The fix is to avoid using the custom fiscal years in get_start_date_elements. An improvement will be done in master to add that feature. We can also safely remove the custom start_date from the belgian localization as now it is not used anymore. See: https://github.com/odoo/enterprise/pull/100034
This update resolves an issue where commas in payment memos for EFT files were causing errors and rejections. The fix removes commas from generated files, ensuring they conform to the BNZ export format and preventing payment processing failures. This ensures accurate EFT file submissions.
Original PR description
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This…
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field. - The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124'). - The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002'). - The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124' This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields. While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220) opw-5099220 Forward-Port-Of: odoo/enterprise#100670 Forward-Port-Of: odoo/enterprise#98613