Tuesday, October 21, 2025
19 changes · 18.0
New functionality added to Odoo
When Uruguay electronic invoices are rejected by the tax authority, the system now alerts the relevant internal users or Accounting Administrators. This helps teams notice cancelled invoices quickly, review the issue, and resubmit when needed.
Original PR description
before this change we we get a rejected status from DGI we were setting to Cancel all the related invoices without notifying to any user that this happened Now we try to notify to the internal users if the invoice has them, if not then we notify to the Accounting administrators.
Enhancements to existing features
Luxembourg payroll parameters have been updated to reflect 2025 changes to the minimum social salary and employee tax credits. This helps ensure payroll calculations stay aligned with the latest official Luxembourg social security and tax requirements.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf - https://impotsdirects.public.lu/fr/az/c/CIP/cip2025.html - https://impotsdirects.public.lu/fr/az/c/credit-impot-salaries/cis2025.html task-5176255 Forward-Port-Of: odoo/enterprise#97608
Resolved issues and error corrections
Third-party checks are now classified correctly when the same check has both received and paid-out activity. This prevents checks from incorrectly appearing as still on hand, improving the accuracy of check tracking and payment follow-up.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`. 2. Create a third-party check journal: * Add payment methods: *New Third Party Checks* (inbound) and…
**Steps to reproduce:** 1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`. 2. Create a third-party check journal: * Add payment methods: *New Third Party Checks* (inbound) and *Existing Third Party Checks* (outbound). * Configure outstanding accounts for both methods. 3. Create a vendor payment: * Use the third-party check journal. * Select the *Existing Third Party Checks* method. * Leave the check list empty. * Keep the payment in *Draft*. 4. Create a customer payment: * Use the same journal and select the *New Third Party Checks* method. * Add a new check under the *Checks* tab. * Post the payment. 5. Return to the draft vendor payment created in step 3: * Add the newly created check to it (via *Add a line*). * Post the payment. 6. Go to **Customers → Third Party Checks**. **Observed behavior:** - The check still shows a `current_journal_id` even though it has both inbound and outbound operations. - As a result, the check incorrectly appears in the 'On Hand' filter. **Root cause:** - `_get_last_operation` was sorting operations by `date`. - In some scenarios or flows where multiple operations share the same `date`, the wrong operation could be selected as the "last one", leading `_compute_current_journal` to assign a journal incorrectly. **Solution:** - Sort operations by `write_date` to always pick the true last operation. - This ensures `_compute_current_journal` correctly clears `current_journal_id` whenever both inbound and outbound operations exist. opw-5012903
The Trial Balance report has been updated with improvements from a newer version and aligned across several country-specific accounting reports. This gives finance teams a more consistent and improved reporting experience in Odoo 18.0, especially for consolidation-related work.
Original PR description
*: account_intrastat, account_reports, l10n_be_reports, l10n_co_reports, l10n_ee_reports, l10n_es_reports, l10n_lu_reports, l10n_mx_reports, l10n_ro_reports --- This commit is a backport of both the following commits whose targets are to refactor the Trial Balance report. https://github.com/odoo/enterprise/commit/a7e1ec20e07efc39bca44d3ae613a54770175273 https://github.com/odoo/enterprise/commit/a6508b0b91a34921668ddc039e2b006746b78351 18.0 is a major version for consolidation and the improved trial balance should accompany it. --- task-4728887
Finnish accounting reports can now be exported in a file format suitable for submission to the tax administration. This helps customers meet local reporting requirements more easily and reduces manual work when preparing tax filings.
Original PR description
The aim of this commit is adding the tax report export file to allow our customers to send their tax reports to their administration. task-5135868
The Chinese ASBE balance sheet report now includes the correct lines and account so assets and liabilities balance properly. This improves the reliability of financial reporting and the related automated checks.
Original PR description
Fixes the balance_sheet_balanced test for asbe where the wrong line was set as liability. Also fixes the report itself that was ignoring one line, and missing one account. task-5175789
Budget line reports now show the correct committed amount when a bill is split across multiple analytic plans. This prevents duplicated totals in budget reporting, helping teams rely on accurate budget figures.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677
This fixes an issue where users without Point of Sale or Inventory access could not delete contacts because the system checked related sales data they were not allowed to view. Contact deletion now avoids that unnecessary access error, helping regular users manage contacts according to their actual permissions.
Original PR description
Versions affected 18 (and any where the fw port has been deployed) A user with no point of sale or inventory permissions wouldn't be able to delete contacts anymore since commit 082b7d3 Steps to reproduce: - In runbot, strip demo user permissions so he doesn't have inventory or point of sale access. - Go to a contact and try to delete it. - An **Access Error** error raises, as that user doesn't have `pos.order` permissions and the new unlink check is trying to check if the partner has related orders. (anyway, maybe the right approach would be to set an `ondelete='restrict'` in the `partner_id` field of `pos.order`) cc @moduon MT-12281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where automated subscription payment processing could repeatedly create new invoices and payment transactions after a validation payment. Subscriptions now correctly recognize validation transactions as already processed, preventing duplicate invoices and unnecessary payment retries.
Original PR description
**Steps to reproduce** - Enable the Stripe payment provider in test mode. - Create a subscription for a portal user. - With that portal user, automate the payment via the portal. - Run "Sale…
**Steps to reproduce** - Enable the Stripe payment provider in test mode. - Create a subscription for a portal user. - With that portal user, automate the payment via the portal. - Run "Sale Subscription: generate recurring invoices and payments" cron. - OK: 1 invoice generated. 1 new transaction in "Pending" state. - Run "Payment: Post-process transactions" cron. - Issue: a new invoice is generated. The previous one is cancelled. A new payment transaction has been created. The next cron calls will repeat the issue, leading to multiple invoices and transactions being generated. **Cause** - `_post_process` is called on the validation transaction in `done` state. But as the `_post_process` override in sale applies a filtering https://github.com/odoo/odoo/blob/a1ce545f73266c0cf7ca876a1b8cde44b064a56b/addons/sale/models/payment_transaction.py#L44-L45 only `pending` transactions are marked as post-processed by the method in `payment`. - once the first invoice for the subscription is created, a new transaction is created for the actual payment and the `pending_transaction` flag is set on the subscription. - when the "Payment: Post-process transactions" cron runs after that, the already post-processed validation transaction is processed again, calling https://github.com/odoo/enterprise/blob/580d406e07a60a34f258eebb65cfd6c33c2ea3ca/sale_subscription/models/payment_transaction.py#L154-L155 - this resets the `pending_transaction` flag on the subscription, leading to the creation of a new invoice and a new transaction opw-4962416
This update fixes several operational issues in accounting, inventory barcode scanning, quality checks, payroll, planning, and inter-company sales. It also refreshes translation files and adds missing translation coverage, helping users avoid errors and ensuring regional compliance updates are available.
FedEx rate requests no longer fail when a customer's state or province code is longer than FedEx accepts, such as East Flanders in Belgium. Odoo now leaves out invalid state codes when FedEx does not require them, helping users get shipping rates without interruption.
Original PR description
**Issue**: Sending a `stateOrProvinceCode` longer than 2 characters causes a FedEx error. **Steps to reproduce**: - Ensure the FedEx delivery carrier is installed. - Open the Sales application. - Create a new quotation with a Belgian customer whose state is set to `East Flanders`. - Click on "Add shipping". - Select "FedEx International" and click on "Get rate". - An error is raised. **Cause**: Some Odoo state codes are longer than 2 characters and are not covered by [this commit](https://github.com/odoo/enterprise/commit/38276c9a237a1779ce7a3e6f31102ff615691690). **Solution**: According to FedEx developer support, in such cases the `stateOrProvinceCode` field is not required. Therefore, we simply omit sending it when the code length is invalid. **Additional note** This commit also fixes 3 mistakes among the mandatory countries: - 3 for United Arab Emirates opw-4875939
UPS shipment requests now include the sender and customer VAT information, so commercial invoices generated for cross-border deliveries show the correct tax details. This prevents blank VAT fields on UPS invoices and supports smoother customs and billing processes.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744
This fixes an issue where employees with more than one payslip in the same batch could have the full expense amount applied to multiple payslips. Payroll expense amounts are now assigned to the correct payslip, helping prevent inaccurate payroll calculations.
Original PR description
since 9435b76 an issue arise when an employee gets two payslip generated for them in the same batch as both would get the full expense input line amount whereas only one gets the expenses linked to it. This adds a context key to bypass the computation when the payslips are created from a batch and trusting the create of the payslip to handle the proper assignation of expenses and computation of the lines
Receipt documents now keep their deferred dates and use the correct account when deferred entries are generated. This prevents accounting errors and avoids users having to re-enter deferred information for receipt-based bills.
Original PR description
## Steps to reproduce ### Bug 1 1. Create a bill receipt 2. Add deferred dates 3. They're reset to False ### Bug 2 1. Create a bill 2. Set the deferred dates 3. Switch to receipt type 4. Confirm 5. The account of the generated deferral entries is incorrect ## Fix While checking the document type with the `is_purchase_document` and `is_sale_document` helper methods, the receipts were ignored as this is the default value. In bug 1, this means that the method `_has_deferred_compatible_account` method would always return `False` when using the receipt type, therefore reseting the deferred dates. In bug 2, this means that when generating the deferrals entries, the `deferred_type` would always be `revenue` in case of a receipt because of the ternary operator. For both bugs, we can simply set `include_receipts` to `True` to take these into account while veryfing/setting the account. opw-5129561
This fix prevents errors when Odoo updates analytic accounting lines that do not have a distribution set. Accounting workflows can continue normally because empty analytic distributions are skipped safely instead of stopping the update.
Original PR description
Description of the issue/feature this PR addresses: This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions,…
Description of the issue/feature this PR addresses: This pull request addresses a bug in Odoo's analytic accounting module. Specifically, when updating analytic lines that have empty distributions, the vals_list[0] ends up being empty. This situation causes an error in the write method, which prevents the system from properly updating analytic lines without distributions. Current behavior before PR: Before this fix, attempting to update analytic lines with empty distributions triggers an error in the write method. As a result, operations that involve updating such lines fail, potentially interrupting normal accounting workflows. Desired behavior after PR is merged: After merging this PR, the system will first check whether an analytic line has a valid distribution before attempting to update it. Lines with empty distributions will be safely skipped, preventing errors and allowing the rest of the analytic updates to proceed smoothly. This ensures more robust handling of analytic lines and avoids runtime exceptions during updates. Video: https://app.screencastify.com/watch/03zuCLh984kWun2Q71tK Odoo Task: https://www.odoo.com/es_ES/my/tasks/5181171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Registered export invoices in Turkey now show the correct payable total in the electronic invoice XML by accounting for deducted VAT. This helps ensure exported invoice documents match legal and business expectations, reducing the risk of incorrect amounts being sent to customers or authorities.
Original PR description
When the invoice's type is "Registered For Export", the total of the invoice which is shown in the cbc:PayableAmount node in XML, has to reflect the VAT deducted amount. This PR fixes the given issue. task-5159638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an Email Marketing display issue where separators in the showcase template could appear incorrectly after saving. Recipients should now see the email layout as intended, improving the professionalism and consistency of marketing emails.
Original PR description
Problem: When adding the `s_showcase` template in Email Marketing and saving, the separator is not properly rendered in the received email. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 opw-5077992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops users from changing invoices linked to Point of Sale orders back to draft status. It helps avoid blocked PoS session closures and guides users to use refunds or credit notes instead.
Original PR description
Before this commit, it was possible to set the invoice of a PoS order to draft, which could prevent closing the session since unposted invoices block the session closing. This commit prevents that by raising a user error suggesting to refund the order or create a credit note instead. opw-5079889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Refreshing a signature document no longer hides the Sign Now and Cancel buttons or replaces the document name with “unnamed.” This keeps the signing flow clear and reliable for users who reload the page.
Original PR description
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel…
Version: - 18.0 Steps to reproduce: - Open document which is send for signature. - Refresh the browser. Before: - Refreshing the page was hiding the `sign now` and `cancel` button from control panel and also the name of document get replaced by 'unnamed' in breadcrumbs - The `needToSign` value was loaded from the context and used later to show those button, which is only available when navigating from `go_to_document`. On refresh, the context was lost, leading to the error. - Breadcrumbs were not getting set properly on reload. After: - Added `needToSign` to the URL query string.On page refresh, the data is retrieved from the URL as a fallback instead of relying on the context. - Add name of document to URL query string and on page refresh use that name to get correct name of document and update name to breadcrumbs using `setDisplayName`. Impact: - Buttons remain visible after refresh. - Correct document name is shown in breadcrumbs. - Ensures a smoother and more stable user experience when viewing documents. task-4805166