Wednesday, October 22, 2025
14 changes · saas-18.2
Enhancements to existing features
All Finnish tax report lines now have codes, ensuring each line can be clearly identified during export. This improves the reliability of tax report exports by giving the export template consistent keys to work with.
Original PR description
The aim of this commit is adding code for all the tax report lines. Before, some lines didn't have any code set on it, now all these lines have a code. The change is motivated by the tax report export where we use the code as key in the dict given to the export template. task-5135868 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229876
The accounting tax calculation helper now extracts records from the grouping key automatically. This reduces manual setup for developers and lowers the chance of errors in tax-related customizations.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231947
Resolved issues and error corrections
Export invoices marked as Registered For Export now show the payable amount after VAT deduction in the electronic invoice XML. This helps ensure Turkish e-invoices report the correct total for compliance and customer-facing documents.
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 Forward-Port-Of: odoo/odoo#231221
Saudi e-invoices now keep the negative value of exempt invoice lines instead of converting it to a positive amount. This prevents avoidable ZATCA validation warnings when invoices include negative lines with 0% tax.
Original PR description
Adding a negative line with 0% tax on an invoice will make the validation succeed with a warning Steps to reproduce (with a SA company setup): - Create an invoice - Add a negative line with 0% tax - Confirm and send to Zatca Issue: The following warning can be observed in chatter [202] BR-O-08 : [BR-O-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is ' Not subject to VAT' the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are 'Not subject to VAT'. This occurs because in the e-invoice, the tax base is transmitted in absolute value opw-5072577 Forward-Port-Of: odoo/odoo#231737
The update process now avoids overwriting certain default marketing tracking records, preventing duplicate-name errors when users have customized or added similar entries. This helps module updates run smoothly without interrupting users who manage link tracking values such as LinkedIn.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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#202567
Point of Sale orders with a general note now carry that note through to the generated accounting invoice. This keeps customer-facing documents consistent and prevents important order context from being lost after checkout.
Original PR description
**Issue** When a POS order is completed with a general note, the note appears on the POS receipt but is missing from the generated accounting invoice. **Steps to Reproduce:** 1. Install Accounting and Point of Sale apps. 2. Start a POS session. 3. Add a product and a general note via Actions → General Note. 4. Add a customer and enable invoicing. 5. Complete the order. **Expected Behavior:** The general note appears in both the POS receipt and the accounting invoice. **Actual Behavior:** The note only appears in the POS receipt. **Root Cause** The _prepare_invoice_lines method only handles customer notes. General notes are not processed and thus excluded from the invoice report.https://github.com/odoo/odoo/blob/ba779f01975c4665eb84086d86b167a2c0f9625e/addons/point_of_sale/models/pos_order.py#L251-L255 opw-4747903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209312
The donation form is now safer when page data loads slowly, preventing accidental duplicate submissions and avoiding crashes or unresponsive clicks. This improves reliability for website visitors making donations, especially on slower networks.
Original PR description
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using…
This fixes a very rare race condition in the `test_01_donation` tour... but it is actually surprising it is not more frequent than it is. Steps to reproduce: - Simulate a slow network (e.g. using Chrome DevTools) - Load a page with a donation snippet - Quickly fill in the donation form and click the submit button => You'll sometimes get a crash. Or a more precise one: - Add a 1 minute delay to the `/website/get_current_currency` route - Load a page with a donation snippet - Fill in the donation form and click the submit button once the page is fully loaded. => You'll definitely get a crash. This commit makes that button's handler async-protected, meaning it will now properly wait for what is needed (the currency) before proceeding, but it will also display a loading effect for the duration and prevent double clicking. Once the form is submitted, the loading effect is removed for stability safety. In master it can probably be improved. runbot-220885 Forward-Port-Of: odoo/odoo#232408
Long mailing list names now fit within their assigned area instead of overlapping nearby fields. This keeps the mailing list screen easier to read and prevents layout issues when users enter lengthy names.
Original PR description
Issue: When you create a long name for your maling list, the name overflows over the other fields in the view. Repro: Go to marketing -> mailing lists -> create a fairly long name -> notice name overflows in the view. Cause: Small bootstrap issue, name field not limited to it's container. Fix: Added a simple w-100 to limit the field to 100% of it's container. opw-5153270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232312
When creating an invoice, changing the customer's language now refreshes the terms and services text in the selected language. This helps ensure customers receive invoice terms they can understand without needing to recreate the invoice or customer record.
Original PR description
Issue: When changing the customer’s language during invoice creation, the terms & services were not retranslated, unlike when creating a new partner in a different language. Repro Steps: 1. Create an invoice with terms link or plain enabled. 2. Change the partner's language from the invoice creation view. 3. Terms is not translated. Cause: The translation compute was only triggered on partner change, not language change. Fix: Added dependency for partner_id.lang to the narration compute to ensure it updates when the language changes. opw-5031933 Forward-Port-Of: odoo/odoo#230800
Point of Sale receipts now keep the same numbering format whether an order is created online or offline. This avoids confusing extra wording on offline orders while preserving the ability to identify offline sales through the receipt number structure.
Original PR description
**Steps to reproduce:** - Go to PoS, make an order and pay for it - Before clicking next order close your connection with the server - Make a purchase like this - Go back online and check the orders…
**Steps to reproduce:** - Go to PoS, make an order and pay for it - Before clicking next order close your connection with the server - Make a purchase like this - Go back online and check the orders in the backend The order made online only has the receipt number, but the order made offline has *Order* in front of it. **Why the fix:** The receipt number on a PoS order should be consistand and should not be changed depending on if the purchase was made online or offline. With this commit, every order will have only it's receipt number without the *Order* in front of it even if it was made offline. It is still possible to see if an order was made online or offline with the **F** variable, which is the first number of the last part of the receipt number. If it is 1, the order was made offline, if it is 0, it was made online. The *refPrefix* parameter from the *getNextOrderRefsLocal* function is not used anymore, so it has been replaced by an empty string in the function call in stable and could be deleted when in master. opw-4965095
Shopee orders marked as delivered but awaiting buyer confirmation will no longer be treated as delivery errors in Odoo. This prevents unnecessary error states and gives users a more accurate view of shipment progress.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
A point-of-sale restaurant preparation display test was corrected to match the latest behavior for empty preparation tickets. This helps keep automated quality checks reliable and reduces the risk of false test results during updates.
Original PR description
pos_* = post_restaurant_preparation_display Before this PR (https://github.com/odoo/odoo/pull/231733), the checkPreparationTicketData method returned True if the preparation ticket was empty. This is no longer the case, so the test has been updated to work correctly now. Related Community PR: https://github.com/odoo/odoo/pull/231733
A spelling mistake in Odoo Studio’s field options was corrected from “Multine” to “Multiline.” This helps users see the intended field name clearly when configuring views.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline' Forward-Port-Of: odoo/enterprise#97713
Sales users planning service work from a sales order can now see and enter allocated hours when creating a planning slot. This restores an important scheduling field in the specific flow where the combined date-and-hours widget is hidden, helping avoid incomplete shift planning.
Original PR description
Steps to reproduce: - Create a Sales order with planning services. - Click on To Plan stat button. - Click on empty cell Issue: - Plan dialog is opened but has missing allocated_hours field. Reason: - In this commit https://github.com/odoo/enterprise/commit/d21bd4b694ec63ba83bea077714a8fe928d6e014 allocated hours was merged with start_datetime using a widget and thus removed from view. - But in planning list view we hide start_datetime when we schedule shifts from sales order. Fix: - Add back allocated_hours conditionally to be visible when we schedule shifts as in other cases start_datetime is present. task-5117776