Daily updates from Odoo
Friday, June 20, 2025
6 changes · 18.0
Enhancements to existing features
Taiwan localization now defaults to calculating VAT rounding at the whole-invoice level instead of line by line. This better matches local invoicing practice, where tax is based on the total sales amount, improving accuracy and compliance for Taiwanese invoices.
Original PR description
For general invoicing purposes, VAT of Taiwan is rounded per invoice level, not per invoice. Also, they do not separately compute the tax amount per each line to generate the final totals. They use total sales amount * tax. task - 4875546
Resolved issues and error corrections
This update adjusts Turkish Nilvera e-invoice exports so they no longer include unsupported buyer reference data or ID fields missing the required type information. This helps prevent invoice rejections by Nilvera and improves reliability for Turkish electronic invoicing.
Original PR description
[FIX] l10n_tr_nilvera_einvoice: exclude ID without schemeID Nilvera expects a `<schemeID>` with every `<ID>`. In Odoo currently, we only support VKN or TCKN as a schemeID that get impacted from the VAT Number. Also, Nilvera reject any `<BuyerReference>` tag. Before: - The generated XML contains some `<ID>` tags without 'schemeID' attribute. - The generated XML contains some `<BuyerReference>` tag. After: - The `<ID>` tags with no 'schemeID' are removed from the XML. - The `<BuyerReference>` tag is removed from the XML. Task-4822777 runbot: https://runbot.odoo.com/runbot/bundle/18-0-tr-nilvera-partner-ref-override-tax-id-roto-376352
Portal users can now view the leads and opportunities assigned to them across all companies they are permitted to access, not just the main company. This fixes missing records in multi-company setups and helps partners reliably follow their sales opportunities.
Original PR description
Correct multi-company lead visibility in portal. [task-4482622](https://www.odoo.com/web#view_type=form&model=project.task&id=4482622) Description of the issue/feature this PR addresses: In a…
Correct multi-company lead visibility in portal. [task-4482622](https://www.odoo.com/web#view_type=form&model=project.task&id=4482622) Description of the issue/feature this PR addresses: In a multi-company environment, portal users (partners) were unable to access Opportunities and Leads belonged to them, when these records belonged to company(branch) that is not main company. Their visibility was restricted to records from the main company, even if their access rights were configured to allow access to multiple companies. Steps to reproduce: 1. Create a new company 2. Create a partner and grant them portal access 3. Grant the partner access right to the new company. 4. Switch to the new company and create an opportunity and assign it to this partner (Under assigned Partner tab). 5. Log in as the partner, go to "my/opportunities." 6. The opportunity is not there. Desired behavior after PR is merged: Partners can see lead/opportunities from multiple companies. --- Current behavior exists for other portal endpoints such as my/subscriptions, my/sales, my/invoices but I believe that the current behavior is expected and normal for these endpoints. --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This fix restores a default invoice description for Spanish TicketBAI point-of-sale orders when no origin is provided. It prevents submission errors and helps affected POS invoices meet the required tax reporting format.
Original PR description
Before PR #187439, the field DescripcionFactura defaulted to `manual` when the origin was False.
That PR removed the fallback and moved the default assignment to `_l10n_es_tbai_get_invoice_values` in `l10n_es_edi_tbai` module, but forgot to apply the same logic in `_l10n_es_tbai_get_values`.
Steps to reproduce:
- Create a new TBAI POS order
- Try to submit it
- You’ll get an error:
```cvc-complex-type.2.4.a: Invalid content was found starting
with element 'DetallesFactura'. One of '{FechaOperacion,
DescripcionFactura}' is expected.
```
This fix restores the fallback value 'manual' for POS invoices
to ensure schema compliance.
opw-4834333Task assignees on private projects can now see documents linked to their tasks when they should have access. The update also removes document access when people are no longer followers, helping keep project documents visible to the right users only.
Original PR description
**Steps to reproduce:** - Install the `documents_project` module. - Create a project, set visibility to '**Invited internal users (private)**', and add Marc Demo as a follower. - In the project…
**Steps to reproduce:** - Install the `documents_project` module. - Create a project, set visibility to '**Invited internal users (private)**', and add Marc Demo as a follower. - In the project settings tab, hover over the folder name and open it. - Click the gear icon and select 'Share', ensuring Marc Demo is listed under '**People with access**'. - Set both '**Internal Users**' and '**Anyone with the link**' to None, then click 'Done'. - Create a task for the project and add Marc Demo as the assignee - Upload a document via the document smart button - Now go to the task with Marc Demo Marc Demo cannot see the document but can see the attachment. The document smart button shows 0 count. **Issue:** Marc Demo, a project follower and task assignee, cannot see the document because it’s not shared with his user’s partner. **Solution:** - Grant 'view' access to task assignees if project visibility is set to 'Invited internal users (private)', allowing assignees to access the documents. - Revoke document access for partners who are unsubscribed and no longer followers of the associated project and task. - Also, implemented a test case to cover these use-cases. opw-4702911
Purchase order lines now show budget warnings only when their analytic distribution actually matches the relevant budget line. This avoids misleading red warnings and ensures over-budget purchase lines are highlighted consistently when multiple lines are present.
Original PR description
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type:…
**Steps to reproduce:** - Install account_budget - Activate "Budget Management" in Accounting settings - Go to "Accounting / Accounting / Analytic Budget" - Create a new budget: * Budget Type: Expense * Period: [this month] * Budget Lines: [a line with an analytic account (AA) in 2 plans] - Open the budget **Issue 1:** Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount. The PO line and the Budget button appear in red, but it shouldn't because the analytic distribution of the line doesn't match all the accounts defined on the budget line. The line will not impact the budget, but it appears in red, which is confusing. **Cause 1:** When computing the budget lines linked to the PO line, the domain that is used is only taking into account the plans that are set on the PO line, ignoring the plans that are not set. For the Budget button, all the PO lines are used instead of just those having the correct analytic distribution. **Issue 2:** - Create a PO at the current date with 2 lines: 1) a line with the same AA than the budget line and an amount higher than the budget amount 2) a line with the same AA than the budget line and an amount lower than the budget amount - Save the PO The first line should be red, but it is not. **Cause 2:** When computing the budget lines linked to the PO lines, only the last PO line has its value set. opw-4757067