Daily updates from Odoo
Saturday, August 2, 2025
7 changes · saas-18.4
Resolved issues and error corrections
Invoice base rounding differences are now spread across invoice lines instead of being placed on a single line. This helps generated UBL/PEPPOL electronic invoices stay within validation limits and reduces the risk of rejected invoices.
Original PR description
Before this commit, the behaviour of `_round_base_lines_tax_details` was to assign all the base line delta to the largest base line. However, when generating the UBL, the delta would then get included in the LineExtensionAmount, but BIS3 rule PEPPOL-EN16931-R120 enforces that the LineExtensionAmount must be at most 2 cents away from `(quantity * net price) + sum(charges) - sum(allowances)`. Effectively this means that we can put at most 2 cents base delta on each invoice line. After this commit, `_round_base_lines_tax_details` redistributes the base delta evenly over all the base lines. task-none Forward-Port-Of: odoo/odoo#221569 Forward-Port-Of: odoo/odoo#219244
Users limited to a company branch can now open the Accounting Chart of Accounts without hitting an access error. This removes a blocker for branch accounting teams while keeping company access rules intact.
Original PR description
#### Steps to reproduce
- Create a branch in a company that has a CoA installed.
- Create a user that only has access to the branch
- Login as the user
- Try to open Accounting > Configuration > Chart of Accounts
- You get an AccessError in your face.
#### Analysis
- When calling `web_search_read` on `account.account`, the `company_ids` field is loaded into cache by `search_fetch`.
- Since the user does not have access to the parent company, the parent company will not be in the account's `company_ids` in cache.
- When calling `_check_access` in `fetch`, the `filtered_domain` (even though it is called behind `sudo`) will use the `company_ids` in cache to determine whether the accounts can be accessed, triggering the `AccessError`.
#### Solution
- Set `depends_context=('uid',)` on the `company_ids` field to keep separate sudo / non-sudo caches for the field.
opw-4730107
Forward-Port-Of: odoo/odoo#220294
Forward-Port-Of: odoo/odoo#217752This fixes tax calculations for invoices, sales, purchases, and point of sale when down payments or global discounts are used across multiple currencies. Businesses should see more reliable totals and tax amounts, especially when manual tax adjustments or foreign currencies are involved.
Original PR description
…anual_tax_amounts When using 'manual_tax_amounts', both 'raw_tax_amount' & 'tax_amount' get the forced tax amount. However, by doing that, we lost accuracy in the raw amount. With this commit, the manual_tax_amounts become a way to ensure some results in '_round_base_lines_tax_details'. So after this commit, the manual_tax_amounts won't be manage in '_get_tax_details' anymore. That way, we could also use the manual_tax_amounts for amounts in company's currency. For down payment/global discount, let's handle both currencies instead of only the foreign one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219930
This fix adjusts the demo data setup so restaurant point-of-sale sample data loads in the right order. It prevents failures when demo restaurant data is loaded through a custom point-of-sale flow, improving setup reliability without changing day-to-day user features.
Original PR description
Finetuning of ffb976c3ed5fbcff2e5d06a3183bab2fbe0307ff to ensure that the product attributes demo data are loaded before loading the pos restaurant demo data --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that could block users from registering vendor payments in the Vietnam localization when bank account details were configured for sending money. The validation order was corrected so payments can proceed normally instead of showing an unexpected failure.
Original PR description
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in…
### Issue: When creating a vendor with a bank account and certain fields configured, trying to register a payment could raise a KeyError: 'none'. This was due to the incorrect order of validations in _check_for_qr_code_errors, introduced in PR #219566. This commit reorders the checks to ensure proxy_type is validated before being used. ### Affected Versions: 17.0 and later ### To reproduce: 1. Install account_accountant, l10n_vn 2. Select VN Company 3. Go to Accounting > Vendors > Vendors 4. Create a partner with country set to Vietnam 5. In Accounting tab, add a bank account with: - Account Name - Bank - Currency - "Send money" set to True 6. Go to Accounting > Vendors > Payments 7. Try to create a payment for that partner ##### Expected: Payment is created successfully ##### Current: KeyError: 'none' is raised OPW-4976541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221522
This fixes a display issue in Mail where an email recipient prompt could cover an alert when sending to a contact without an email address. Users will now see important warning messages clearly, reducing confusion during the send process.
Original PR description
## Before this commit When the user clicks the Send button and the partner does not have an email address, an alert message is raised. However, the recipient popover `(email input prompt)` appears above the alert, visually blocking it and breaking the expected `modal` behavior. <img width="1844" height="873" alt="image" src="https://github.com/user-attachments/assets/31585785-27d6-48d4-b64c-c88b5f9426d6" /> ## After this commit The recipient popover's `z-index` is adjusted so that it no longer overlaps alert messages. This ensures that alerts remain visible and unobstructed, preserving clarity in the UI and respecting the intended visual hierarchy. <img width="1736" height="764" alt="image" src="https://github.com/user-attachments/assets/9ff258b4-2072-4100-bcc4-b8420d5d1aa2" /> Forward-Port-Of: odoo/odoo#221313
This fixes UrbanPiper POS behavior so draft cart items are no longer lost when the page is refreshed. It also ensures product variants inherit the correct meal type during menu synchronization, helping restaurants publish accurate vegetarian or non-vegetarian information.
Original PR description
Steps to reproduce: - Installed urbanpiper - Open POS and add product to cart - Refresh the page . Issue: - Product in the cart automatically removes. Cause: - Order lines were filtered out when urban piper is enabled. Fix: - Filter out the order lines which are not associated with online order. Issue 2: - While menu sync to Urban piper, 'product variant' food_type is sent as NA although main product food_type is set as Vegetarian or Non-Vegetarian. Fix: - Set variant food_type as main product food_type. task- 4971503 Forward-Port-Of: odoo/enterprise#91098