Daily updates from Odoo
Tuesday, July 21, 2026
14 changes · master
Enhancements to existing features
GSTR-1 JSON generation now uses tax details prepared in advance on invoice lines instead of calculating them each time the file is created. This should significantly reduce waiting time for businesses that generate GSTR-1 reports with large invoice volumes.
Original PR description
Currently, when the GSTR-1 JSON is generated, we calculate and fetch the tax details at runtime. Due to this, the system takes significant time when generating JSON for a large number of invoices. This PR proposes to precompute this computation and store it on individual lines. By doing this, we expect a reduction in JSON generation time. task-3941950 Community PR - https://github.com/odoo/odoo/pull/268457
The Indian GSTR-3B report now includes Non-ITC reverse charge tax amounts in Table 3.1(d). This helps businesses produce more complete GST return figures and reduces manual adjustments during compliance reporting.
Original PR description
With this **PR** support for Non ITC RC tax in Table 3.1(d) of GSTR-3B report has been introduced. **task**-3973469 **Community PR** - odoo/odoo#168627
Brazilian fiscal settings can now be defined on operation types, so the same product can be reused across different transaction contexts without creating duplicate product records. The system applies the most specific available setting and improves missing-data warnings to guide users toward operation type configuration when needed.
Original PR description
*: l10n_br_avatax,l10n_br_avatax_sale,l10n_br_edi_fiscal_reform In Brazil the same physical product can have different fiscal profiles (purpose of use, source of origin, SPED type, IS taxability) depending on the nature of the transaction. Since these fields only existed on the product, users had to duplicate products per usage context (e.g. "Product X - Resale" and "Product X - Consumption"). Allow configuring them on the operation type as well. Values resolve through a priority cascade: line override operation type, then header operation type, then the document-level purpose of use, then the product. IS taxability is a tri-state selection on the operation type because a boolean could not fall through to the product value. The missing-data banner now only warns when the whole resolution chain leaves a field empty and mentions the operation type as a way to resolve it. IS taxability is not part of the banner checks. task-6064560
The planning and point-of-sale payment integration has been consolidated into the main planning POS module. This removes a separate bridge component because the main module already depends on online payments, making maintenance simpler without changing expected business workflows.
Original PR description
Since `pos_sale_planning` depends directly on `pos_online_payment`, this commit removes the bridge module `pos_sale_planning_online_payment` and merges its logic into `pos_sale_planning`. Task-6128503 Related PRs: - Community: https://github.com/odoo/odoo/pull/264942 - Upgrade: https://github.com/odoo/upgrade/pull/10659
The Timesheets print option is now hidden on helpdesk tickets that have no logged timesheet entries. This prevents users from accidentally generating blank PDFs and keeps the ticket actions menu more relevant.
Original PR description
Before this PR --- - The "Timesheets" print action was visible in the gear menu of helpdesk tickets even when no timesheet entries were logged on the ticket. - Clicking the action generated an empty timesheet PDF. After this PR --- - The "Timesheets" print action is now hidden on helpdesk tickets when no timesheet entries are linked (timesheet_ids is empty). - Empty timesheet PDFs can no longer be triggered from the ticket view. task-5361456
Resolved issues and error corrections
Argentine electronic invoices for final consumers now validate the customer identification type before confirmation. Instead of a system error when an invalid ID such as a passport with letters is used, users receive a clear warning so they can correct the customer record.
Original PR description
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina…
After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina - Identification Type: `Passport` - Identification Number: `1234567890a` - AFIP Responsibility Type: `Consumidor Final` - Create a new invoice for this customer with: - Journal: `Electronic Invoice (FE)` - Document Type: `(6) INVOICES B` - Try to confirm the invoice. **Error:** ValueError: invalid literal for int() with base 10: '1234567890a' **Expected behaviour:** For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, the identification type must be `DNI` or `CUIL/CUIT`. If another identification type is used, the user should receive a proper warning instead of a traceback. (see [1]) **Root Cause:** After the community fix, `_get_id_number_sanitize()` can return an alphanumeric value, which is later converted with `int()` at [2] and [3], causing an error. **Fix:** This commit adds an explicit validation for Argentinean contacts with AFIP Responsibility Type Consumidor Final before converting the identification number to an integer, ensuring the user receives the proper warning message. [1]: https://www.odoo.com/mail/message/1118392033 [2]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798 [3]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931 Related community PR: https://github.com/odoo/odoo/pull/272651 opw-6333998 Forward-Port-Of: odoo/enterprise#124789 Forward-Port-Of: odoo/enterprise#123729
Commission adjustment entries no longer crash when someone types a non-matching user name in the Add to or Reduce From fields. The quick-create option was disabled there, so users must select an existing valid user and can continue working without server errors.
Original PR description
Steps to reproduce: - Go to Sales > Commission > Adjustments - In Add to/Reduce From, type a name with no match - Click Create '<name>' -> server crashes (RPC_ERROR) Cause: `sale.commission.plan.user._rec_name` is a Many2one (`user_id`). Default `name_create` wrote the typed text into that integer column, which Postgres rejected. Fix: - Disable quick-create on `add_user_id`/`reduce_user_id` in the Adjustments list view Version: saas-18.3 to master opw-6384909 Forward-Port-Of: odoo/enterprise#124431
Point of Sale transactions using AvaTax now calculate taxes based on the company/shop location instead of requiring a customer address. This makes tax handling more reliable for regular in-store sales and fixes an issue where quantities were not properly included in subtotal calculations.
Original PR description
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on…
The module behaves in an unexpected way: - Tax is based on a customer's home address, - To calculate tax a customer must be selected, - Tax is calculated as if shipped from the warehouse selected on pos_warehouse_id This could be useful in very obscure scenarios (B2B sales, traveling salesmen), but for those cases customers can already use our Avatax integration on sale orders. We want this module to be useful for normal B2C POS sales. Taxes they charge are the same regardless of where the customer may live. This commit makes many changes: - Stop requiring a customer to be selected, - Always calculate local sales (from company location to company location) if the Avatax option is enabled on pos.config, - Fix a bug where price_subtotal is not multiplied by quantity, - Removes copy/pasted code from sale.order that serves no purpose, This makes the module useful for companies that don't want to manually figure out what taxes to charge. This could be especially useful for companies with many shops in different locations. A tour test was added to make sure the module keeps working. The test added before [1] was removed because it was redundant and less complete than the one included here. This is deliberately not backported to Odoo 18 [2]. We keep the current behavior there. [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Closes odoo/enterprise#82779 task-4710463 Forward-Port-Of: odoo/enterprise#124778 Forward-Port-Of: odoo/enterprise#123190
Duplicating certain Sign templates with multiple documents, signers, and fields could fail because the system tried to process the same signer role more than once. This fix skips roles that were already handled, making template duplication reliable for affected signing workflows.
Original PR description
Issue: This [loop](https://github.com/odoo-dev/enterprise/blob/55bb2cc570451361701d53583f019ed832a5e5d3/sign/models/sign_item.py#L59-L63) runs multiple times with the same approvers(sign.item.role), but doesn't take into account the already 'seen map' inside the base copy function for batching. If they are already seen they will return a non-iterable [None]. To replicate: 1) Sign -> Template -> upload PDF 2) Go into the template 3) Add 2 Documents, with 2 signers and multiple fields on both documents 4) Save -> gear Icon -> make into template 5) Go back to the list view of templates 6) Select the template -> Gear Icon -> Duplicate Fix: add an already seen check to skip if already seen. opw-6352408 Forward-Port-Of: odoo/enterprise#123814 Forward-Port-Of: odoo/enterprise#122667
Swiss QR-IBAN payment references are now cleaned before payment files are generated. This helps prevent ISO 20022 bank files from being rejected when a reference contains unsupported characters such as the degree symbol.
Original PR description
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with…
**Steps to reproduce:** * Configure a Swiss company with the Swiss accounting localization. * Install `account_sepa`. * Configure a bank journal with a valid Swiss **QR-IBAN**. * Create a vendor with a valid Swiss bank account. * Under **Accounting -> Configuration -> Settings** enable QR Payments. * Go to the vendor and enter the correct QR-IBAN number under the Accounting Section. * Navigate to **Accounting -> Configuration -> Journals** and in the **bank** journal, add the account number of QR-IBAN. * Create and post a vendor payment using the bank journal. * Set the payment reference (`ref`) to contain the `°` character. * Add the payment to a batch payment and generate the ISO 20022 payment file. * Inspect the generated XML. **Observed Behaviour:** The `°` character is preserved in the payment reference for QR-IBAN payments, producing an ISO 20022 file that may be rejected by Swiss banks because it does not comply with the EPC minimum character set. **Cause:** The QR-IBAN branch validates the structured reference before sanitizing it, allowing unsupported characters to remain in the generated XML. **Fix:** Sanitize the payment reference before validating it as a QR structured reference, ensuring invalid characters are removed while preserving valid QR references. opw - 6350931 Forward-Port-Of: odoo/enterprise#125049 Forward-Port-Of: odoo/enterprise#123267
This fix removes an unnecessary repeated reload action from an automated restaurant appointment test. It prevents false test failures caused by a timing issue while keeping the same coverage for the intended business flow.
Original PR description
The `RestaurantAppointmentTour` performed two consecutive "Reload Data" actions. The first reload starts synchronizing data from the server to IndexedDB. If the second reload is triggered before the synchronization completes, it deletes the IndexedDB while it is still in use, causing the synchronization process to crash. This race condition can be reproduced locally by running the tour with `cpu_throttling` enabled. In practice, users never trigger two consecutive reloads, so the second reload step in the tour is unnecessary. Remove it to avoid the artificial race condition while preserving the intended test coverage. Task-[6364951](https://www.odoo.com/odoo/project/1737/tasks/6364951) Runbot Error-[941343](https://runbot.odoo.com/odoo/error/941343), [941344](https://runbot.odoo.com/odoo/error/941344), [941345](https://runbot.odoo.com/odoo/error/941345) Forward-Port-Of: odoo/enterprise#125028 Forward-Port-Of: odoo/enterprise#123429
The Documents search panel now updates its layout when users switch between smaller and larger screen sizes. This keeps the interface usable and consistent when resizing a browser or moving between devices.
Original PR description
The DocumentsSearchPanel selected its template and sub-templates once, from `uiUtils.isSmall()` evaluated at class-definition/setup time. The layout was thus frozen to the breakpoint active when the component was created and did not follow later small/large changes. Move the small/large branching into the templates: `documents.SearchPanel.Responsive` wrapper (and the matching `.Category` and `.FiltersGroup` wrappers) now switch on `env.isSmall` at render time , so the panel always renders the layout matching the current breakpoint.
Code cleanup and technical improvements
The Documents app was updated to use newer underlying interface technology as part of Odoo’s Owl 3 migration. This keeps the file viewer aligned with the platform upgrade without changing day-to-day business workflows.
Original PR description
As part of the Owl 3 migration, this pr aims to replace **onWillUpdateProps** hook with the appropriate Owl 3 alternatives.
The Documents app was updated as part of the broader Owl 3 migration, replacing an older internal component update pattern with the newer supported approach. This helps keep the app compatible with the platform’s evolving frontend framework without changing day-to-day user workflows.
Original PR description
As part of the Owl 3 migration, this pr aims to replace **onWillUpdateProps** hook with the appropriate Owl 3 alternatives.