Tuesday, July 22, 2025
9 changes · 17.0
Resolved issues and error corrections
This fix updates the Saudi e-invoicing VAT exemption reason code for international passenger transport to the correct official value. It helps ensure invoices use the right compliance code and reduces the risk of reporting or validation issues.
Original PR description
The code for The international transport of Passengers was wrong. It was VATEX-SA-34-1 instead of VATEX-SA-34-2. This commit fixes the code. task-id: 4949581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Companies in Greece and Ireland with valid VAT numbers now correctly show the Intra-Community Valid checkbox. This fixes cases where country code differences prevented proper VAT verification visibility.
Original PR description
Current behavior before PR: - Intra-Community Valid checkbox (for vies verification) was not showing for Greece and Ireland companies with valid VAT number. This was because Greece ISO is GR and Ireland ISO in IX, but their VAT start with EL and IE Desired behavior after PR is merged: - Checkbox is shown despite differences between ISO and beginning of VAT Link to task : - https://www.odoo.com/odoo/project/967/tasks/4575784
The Point of Sale session closing message now displays cash differences using the currency's normal decimal format instead of showing long, confusing numbers caused by calculation precision. This makes session closing records clearer for store managers and accounting teams without changing the underlying balances.
Original PR description
**Issue:** When closing a PoS session with negative balances, the closing difference is displayed in the chatter box with an excessive number of decimal digits. **Steps to Reproduce:** 1. Install the…
**Issue:** When closing a PoS session with negative balances, the closing difference is displayed in the chatter box with an excessive number of decimal digits. **Steps to Reproduce:** 1. Install the Point of Sale app. 2. Navigate to Point of Sale > Open a new session. 3. Set the Opening Cash to 496.45. 4. Add a product priced at 65.86 to an order. 5. Confirm the payment via Payment > Cash > Validate. 6. Close the session and set Counted Cash to 560.40. 7. Navigate to Orders > Sessions. 8. Open the last closed session. 9. Observe that the closing difference is displayed with more than two decimal digits. Expected Behavior: The closing difference should be rounded to two decimal places for clarity. Actual Behavior: The closing difference is displayed with excessive decimal digits. **Root Cause** Floating-point arithmetic in Python causes small precision errors when performing calculations involving monetary values. Since Odoo's Monetary fields are based on float types, operations such as balance calculations retain unnecessary decimal places instead of rounding them correctly to two digits. **Fix** To prevent this from happening, at the moment of crafting the message to display on the chatter, it is explicitly requested to only show two decimal digits of the rounded closing difference. Opw-4483487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could occur when users customized RFQ lines to edit the received quantity directly. The change keeps purchase teams from hitting a crash in this unusual but supported customization scenario, improving reliability when using Studio with purchasing workflows.
Original PR description
Currently, an error occurs if a user makes the **Received Quantity** field editable on an RFQ order line and modifies it directly. **Steps to reproduce:** - Install the `purchase_stock` and…
Currently, an error occurs if a user makes the **Received Quantity** field editable on an RFQ order line and modifies it directly. **Steps to reproduce:** - Install the `purchase_stock` and web_studio modules. - Create a new **Request for Quotation (RFQ)** with at least one product, then **confirm** it. - Using **Studio**, make the **Received** field editable in the products list view (disable the *readonly* property). - Modify the **Received Quantity** of the product. **Error:** `KeyError: <NewId origin=9>` **Cause:** When the received quantity is modified, the `_track_qty_received` method tries to post a message on the PO. This calls `message_post_with_source`, which renders a QWeb view using `record.id` - [1]. However, for unsaved records, `record.id` is a temporary `NewId`, which cannot be used in the rendering context, resulting in a `KeyError`. [1] - https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/mail/models/mail_thread.py#L2573-L2578 This commit ensures that the computation and message tracking are applied to the original saved record with a valid ID. Sentry - 6597371221
Creating a new website could fail if a required setup item had been deleted. The change handles that missing setup reference more clearly, preventing an unexpected crash during website creation.
Original PR description
This error occurs when a new website is created. Steps to reproduce: --- - Install `website` module - Search for `website_configurator_todo` in External Identifiers and Delete - Webiste > Configuration > Setting > Create a New website Traceback: --- `ValueError: External ID not found in the system: website.website_configurator_todo` This commit resolves the issue by raising an error when the reference ID is not found. sentry-6635248240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vietnam localization no longer blocks VietQR generation when the city field is empty but a valid state such as Hà Nội or Hải Phòng is provided. This reduces payment setup errors and aligns the QR behavior with VietQR requirements where merchant city is not mandatory.
Original PR description
* Problem: Using Vietnam localisation, leave city empty and just input state_id as Hà Nội or Hải Phòng, try to use vietqr code -> Raise error missing city * Solution: Just like https://github.com/odoo/odoo/pull/218984 we should check for state too although according to VietQR document, merchant city is not required see (https://vietqr.net/portal-service/download/documents/QR_Format_T&C_v1.0_VN_092021.pdf and search for term 'Merchant City') 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
This fix ensures invoice policy calculations only consider consumable products, avoiding incorrect behavior when other product types are present. It helps keep sales and localization-related invoicing tests consistent and prevents errors in affected workflows.
Original PR description
steps to reproduce: 1- install l10n_ke_edi_oscu_mrp 2- run test test_discount_and_untaxed_subtotal The compute_invoice_policy method was not correctly filtering products by their type. This fix ensures that only consumable products are considered when computing the invoice policy. build_error-70728
The depreciation schedule now skips imported assets that are missing a fixed asset account. This prevents the report from crashing when draft entries are included, helping finance users view schedules reliably even when some asset records are incomplete.
Original PR description
Steps to reproduce:- - Import an asset with Depreciated Amount and without Fixed Asset Account and Depreciation Account. - Open Depreciation Schedule report with draft entries included. Error: StopIteration Cause: At [1], we get `line_vals` empty because no `account_id` is set. Solution: Don't consider asset without `account_asset_id` in Depreciation Schedule report. [1]: https://github.com/odoo/enterprise/blob/0515335bd44373d0b10d47b31edb711ead648736/account_asset/models/account_assets_report.py#L454
French FEC imports now show a clear user-facing message when a date is not in the required format, instead of causing a system error. This helps accounting users understand and correct invalid files more easily.
Original PR description
Currently, an error is raised if a date field in the FEC file does not match the expected format `%Y%m%d`. **Steps to reproduce:** - Install `accountant` and `l10n_fr_fec_import` modules. - Navigate to accounting settings and Under **Accounting Import** click to **import** button. - Click **Import FEC** button and upload [this](https://drive.google.com/file/d/13sykii_1O6fd6s92kra3EPyvML8tDU9N/view?usp=sharing) file. **Error:** `ValueError - time data '01/12/2023' does not match format '%Y%m%d'` The error occurs when the system tries to evaluate `datetime.datetime.strptime()`, which raises a `ValueError` if the format is incorrect. - [1] [1] - https://github.com/odoo/enterprise/blob/124506e7a9bbd5156aaf806a5d2b5a9eda46faeb/l10n_fr_fec_import/wizard/import_wizard.py#L438-L441 This commit prevents the error by raising a user error if the date is not in the accepted format. Sentry - 6578857172