Wednesday, September 24, 2025
19 changes · 18.0
Enhancements to existing features
This change makes the automatic wave creation rules in stock picking batches easier for developers to customize. Businesses can adapt warehouse wave planning conditions to their specific operations without changing the core process.
Original PR description
This improvement just adds some hook methods that allow to decapsulate the logic of auto waves so its doable to extend the conditions for auto-waving. cc @moduon fyi @Shide TODO: for the sake of clarity I just inserted the hook method logic but a cleaner approach would be to extract the whole logic of each hook into their own separate method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fleet manufacturers now show counts based only on active vehicle models, making the displayed numbers more accurate for day-to-day use. An Archived filter was also added so users can more easily find inactive vehicle models when needed.
Original PR description
- Fixed count of models in manufacturer to count only active models. - Added 'Archived' search filter for 'model' model Task - 4921998 Forward-Port-Of: odoo/odoo#228174 Forward-Port-Of: odoo/odoo#222353
The Czech VAT return now places invoices without a partner VAT number in section A5 regardless of their value. It also consistently classifies special VAT regime entries for travel services and margin schemes in A5, helping businesses submit more accurate VAT control statements.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787
The online shop price range filter now uses the corrected search term when a customer's search is automatically adjusted for a close match. This keeps price filtering available and accurate after fuzzy searches, improving the shopping experience.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Navigate to the website shop page.
2. Search for a term that is close to an existing one, but not exact ("dask" instead of "desk" for example)
Issue
-----
The price range filter will stop functioning
Cause
-----
The domain used to get the minimum and maximum prices for the price range filter used the original search term regardless of whether the actual search results are from a fuzzy search term or not
Solution
--------
When there is a fuzzy search term use it to get the minimum and maximum prices for the price range filter instead of the original search term
opw-5020545
Forward-Port-Of: odoo/odoo#226059Odoo now validates Taiwanese business tax numbers using Taiwan’s revised official checksum rule. This prevents valid newly issued numbers from being rejected as the available number range expands.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228093 Forward-Port-Of: odoo/odoo#225468
Users with viewer access can now mark documents as favorites using the keyboard shortcut without hitting an access error. This makes the Documents app more consistent and avoids interruptions for users who rely on shortcuts.
Original PR description
steps to reproduce =================== - Select a document where you have viewer permission. - Try to toggle the favorite through a hotkey. - Access Error when toggling favorite. Technical =========== - To maintain compatibility with stable versions and avoid changing the return type of the existing method, created the helper method, which will call `toggle_favorited` as we need to handle it for multiple records. After this commit ================== - This commit handles the accessError for shortcut flow. As in 18.3 we already have documents_favorite widget https://github.com/odoo/enterprise/pull/82639 which will work for manually favoriting the document, but it is not handling the shortcut flow. Task-4910326
Vendor bill imports for Chilean electronic invoices now correctly treat lines marked with exemption code 6 as negative amounts. This prevents overstated bill totals and improves compliance with Chilean electronic invoicing rules.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#93393
Sales order invoiced amounts now exclude invoice section and note lines, keeping totals aligned with standard accounting behavior. This prevents non-financial display lines from affecting billing amounts and makes reported invoiced values more reliable.
Original PR description
When computing the invoiced amount for a SO, ignore the invoice's lines of `display_type` equal to `line_note` and `line_section` This matches the accounting features which always ignore such lines. **Current behavior before PR** Method `_get_sale_order_invoiced_amount` includes display lines. **Desired behavior after PR is merged** Method `_get_sale_order_invoiced_amount` ignores display lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228146
Chilean electronic delivery guides now show the quantity actually delivered, rather than the quantity originally planned. This prevents incorrect product quantities from appearing in official DTE XML documents when an order is partially delivered without a backorder.
Original PR description
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered…
**Issue** When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE. **Steps to Reproduce** 1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock. 2. Create and confirm a new Sale Order. 3. Click on the Delivery smart button. 4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder. 5. Generate the Delivery Guide. 6. Open the generated DTE XML and observe that the quantity is incorrect. **Root Cause** The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount. **Fix** Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE. Opw-4892276 Forward-Port-Of: odoo/enterprise#89633
The company switcher now correctly displays accessible companies even when they sit under an intermediate company the user cannot access. This helps users navigate complex company structures without missing available companies in the selector.
Original PR description
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2…
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled. This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list. `companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3. ### Solution: A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies. Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed. opw-4880477 Forward-Port-Of: odoo/odoo#217001
Point of Sale now correctly checks pricelist rule validity periods across time zones. This prevents valid discounts or special prices from being skipped before their intended end time, improving pricing reliability for stores.
Original PR description
Currently, when entering a validity period on a pricelist, it can happen that a pricelist rule is not applied while being before the end period. Steps to reproduce (for BE timezone):…
Currently, when entering a validity period on a pricelist, it can happen that a pricelist rule is not applied while being before the end period.
Steps to reproduce (for BE timezone):
-------------------------------------
* Create a pricelist
* Add a pricelist rule for a product (min qty=1, price=5$)
* Add a validity period for the rule, set the end date 30minutes after your current time
* In the settings of the pos add the pricelist to the list of available pricelists
* Open session
* Add the product related to the rule
* Change the pricelist
> Observation: The rule is not applied
Why the fix:
------------
Let's say on the computer it's 15h. The rule is thus set to end at 15h30.
`luxon.DateTime.now()` -> 15h, the zone name is brussels. `deserializeDate(item.date_end)` -> 13h30, zone name is brussels as well.
And 15h in brussels is greater then 13h30 in brussels.
`date_end` is already in UTC format, so we need to specify it. Now, `deserializeDate(item.date_end, { zone: "utc" })` -> 13h30, zone name is utc And 15h in brussels is before 13h30 in utc (since 13h30 is 15h30 in BXL)
opw-4992892Engineering change orders now correctly track small quantity changes when products use more precise units of measure. This prevents tiny but important bill of materials updates from being rounded to zero, improving accuracy for manufacturing teams.
Original PR description
Steps to reproduce the bug:
- Go to Decimal Accuracy → Product Unit of Measure → set digits to 4
- Go to Units of Measure Categories → select a unit → set rounding to 0.0001
- Create a storable product “P1” with a BoM:
- Component C1: 1.0000 unit
- Create an ECO for the BoM with type BoM update
- Start the revision
- Go to V2
Problem:
You cannot update the quantity of C1 to 1.0003 (for example) because the system uses the default 2 digits instead of the UoM digits.
opw-5082488This fix prepares Danish Nemhandel partner information during module installation instead of calculating it later during updates. It helps avoid lengthy update times and makes the installation/update process smoother for businesses using Danish e-invoicing.
Original PR description
To avoid lengthy update due to the compute of the records by the ORM, let's pre-compute the nemhandel fields on the install of the module. 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
Work order employee lists could appear empty for users without HR permissions because an employee avatar field triggered an access error. This change hides or limits that avatar field for non-HR users so the list can load normally while preserving HR access rules.
Original PR description
HR use an access right on field. However they have an issue with the avatar field that return an error while it should not. Until they provide a fix limit the avatar field when the user don't have the hr user group.
This fix ensures the Export option appears when users select documents in list view, even if list view was set as the default through Studio. It prevents confusion and restores the expected document export workflow.
Original PR description
To reproduce: ============= - Go to Documents app - With studio change default view to list - back to Documents app select some documents - on the action button you can see that the export option is not visible Problem: ======== The export action should only be visible in list view, so each time the control panel dropdown is opened we check the current view type from `currentController.state.view_type` which is not always set as clarified here: https://github.com/odoo/odoo/blob/f3761a8b5dc25d8ab711bb83c7c1402173418c01/addons/web/static/src/webclient/actions/action_service.js#L1744-L1747 Solution: ========= We now get the view type from `currentController.view.type` which is always set and contains the correct value. opw-5071617
Scheduled account report emails now skip partners that have been deleted before processing. This prevents the automatic sending job from failing and helps ensure remaining customer statements continue to be sent as expected.
Original PR description
When a partner included in a batch send is deleted before the cron "Send account reports automatically" runs, the cron fails because the partner no longer exists. Steps to reproduce: 1. Create partner A and a draft invoice linked to it 2. Go to Partner Ledger and select Customer Statement report 3. Click on Send and validate - Ensure the scheduled action is not executed immediately (e.g. by deactivating it) 4. Delete partner A 5. Run the cron "Send account reports automatically" -> Cron fails with "Record does not exist or has been deleted" This fix ensures only existing partners are kept for processing. opw-5085571
The General Ledger PDF footer now supports longer company names without cutting them off. Extra footer spacing was added so printed reports remain readable and professional for companies with longer legal names.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer,…
**Steps to reproduce:** 1. Install the Accounting module. 2. Set a company name longer than 24 characters. 3. Go to Accounting → Reporting → General Ledger. 4. Print the report → in the PDF footer, the company name is truncated. **Issue:** - The company name in the General Ledger report footer is cut off if it exceeds 24 characters. **Cause:** - The footer uses a static value limited to 24 characters: https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/account_reports/models/account_report.py#L5850-L5860 **Solution:** - Increased the footer text limit from 24 to 80 characters. - Adjusted page margin by changing `'data-report-margin-bottom': 15` → `'data-report-margin-bottom': 20` to ensure proper spacing for longer company names in the PDF. **After Apply Solution** <img width="1038" height="86" alt="After solution" src="https://github.com/user-attachments/assets/51ece47c-1950-4a54-8be3-f7ac2bbd8a0d" /> **Before Without Solution** <img width="1050" height="66" alt="Before Solution" src="https://github.com/user-attachments/assets/a13b9132-bf04-422a-8e32-1db5225afc33" /> opw - 5025972
The barcode Kanban view now only shows existing stock quantities instead of allowing new ones to be created. This prevents accidental inventory records and helps keep stock data accurate when users scan or enter product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones.
The delivery packing action now applies a package only to the move line the user selected, instead of packing every line in the delivery. This prevents products from being grouped into the wrong package and helps keep shipment contents accurate.
Original PR description
Steps to reproduce the bug:
- Create two storable products, e.g., “P1” and “P2”.
- Create a delivery:
- Add one unit of each product.
- Add any carrier (e.g., DHL).
- Mark the picking as "To Do".
- Set the quantity to 1.
- The move lines are created.
- Click on the Moves smart button.
- Select any move line (ML).
- Click Put in Pack.
- A wizard is triggered.
- Select any pack.
Problem:
The pack is applied to both move lines instead of only the selected one.
opw-5104034