Daily updates from Odoo
Monday, December 1, 2025
5 changes · saas-18.2
Resolved issues and error corrections
This update resolves an issue that prevented users from placing test orders when a product's tax was set to a Group of Taxes without any defined tax rates. The fix corrects a technical error within the Urban Piper integration, ensuring test orders can now be successfully created under this scenario. This improves the reliability of the PoS testing process.
Original PR description
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module -…
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module - Configure Urban Piper integration for the PoS - Create a new tax without Definition > ``Tax Computation: Group of Taxes`` > Save - Create a new product > Set the above tax in sales taxes > Save - Open the session for PoS - Go to Settings > Urban Piper Location > Set Food Delivery Platforms > Save - Click Test Order > Select the product and Delivery Provider > Place Order Traceback: ```py IndexError: list index out of range ``` https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/pos_urban_piper/controllers/main.py#L319-L322 The issue happens because ``flatten_taxes_hierarchy()`` calls ``_flatten_taxes_and_sort_them()`` method at [1], which returns an empty record when the group tax has no children at [2]. As a result, ``tax_types`` becomes an empty list ([]), leading to an IndexError when trying to access ``tax_types[0]``. [1]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L2786 [2]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L795 sentry-6984648461
This update resolves a technical issue that prevented the printed receipt tour from functioning correctly after installing the `l10n_it_pos` or `l10n_se_pos` modules. The fix corrects a code error that was causing a runtime error, ensuring the POS receipt tour operates as intended for our international retail customers.
Original PR description
in this commit: - Fixed TypeError: this.get_order is not a function raised during the `test_printed_receipt_tour` in POS after installing `l10n_it_pos` or `l10n_se_pos`. runbot-233248
This update fixes an issue where vendor bills created in the Documents module defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and simplifies reconciliation.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
This update corrects a bug where credit notes weren't automatically generating deferred revenue entries. The system was incorrectly using a setting designed for invoices. Now, credit notes will correctly create deferred revenue entries when configured to 'On bill validation', ensuring accurate financial reporting for credit note transactions.
Original PR description
The system incorrectly uses the `Deferred Expense Entries` configuration to determine whether to create deferrals for credit notes, while it should follow the `Deferred Revenue Entries` setting, as invoices do. As a result, deferred entries for credit notes are not created when expected. Steps to reproduce: - Go to Accounting → Configuration → Settings. - In the Deferred Expense Entries section, set Generate entries to: Manually & Grouped - In the Deferred Revenue Entries section, set Generate entries to: On bill validation - Navigate to Accounting → Customers → Credit Notes. - Create a credit note with at least one line containing Date From and Date To (i.e., deferrable line). - Validate the credit note. - No deferred revenue entries are created. Ticket [link](https://www.odoo.com/odoo/project.task/5187051) opw-5187051 Forward-Port-Of: odoo/enterprise#100211
This update fixes a technical issue that prevented the 'fuel_type' field in the HR contract module from being properly translated. By directly using the available options, this change ensures all text within the field can be localized, improving the system's internationalization capabilities.
Original PR description
The selection field `fuel_type` in the `hr.contract` model was not properly translatable, because it used a function yielding static strings for the options. This commit changes the field to use the variable directly, allowing them to be translated. Forward-Port-Of: odoo/enterprise#100748