Thursday, May 14, 2026
24 changes · saas-19.3
Resolved issues and error corrections
This update corrects a discrepancy in how ARCA-related invoices (document types 51-59) are displayed. The change ensures the documents align with current ARCA regulations and avoids potential issues with tax reporting. This update maintains backward compatibility with existing ARCA validations.
Original PR description
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a…
**Context:** * ARCA (formerly AFIP) has deprecated the "Documentos M" classification for document types with codes 51-59. * These are now classified as "Documentos A con leyenda 'Operación sujeta a retención'" while retaining the same codes for backward compatibility with ARCA validations. **Steps to Reproduce:** * Install `l10n_ar` module. * Go to `Accounting -> Configuration -> Document types`. **Observed behavior:** * Document types 51-59 still display letter "M" and use the old naming convention (e.g. "INVOICES M", "DEBIT MEMOS M"), which no longer reflects the current ARCA classification. **Fix:** * Updated `name` fields to include the "WITH LEGEND" / "CON LEYENDA" suffix. * Changed `l10n_ar_letter` from "M" to "A" so the PDF header renders an "A". * Changed `doc_code_prefix` from `*-M` to `*-A` (FA-A, ND-A, NC-A, RE-A). * The existing `res.config.settings` option for injecting the PDF legend remains untouched. Sources: - ARCA: https://www.afip.gob.ar/facturacion/regimen-general/comprobantes.asp Ref: https://www.odoo.com/mail/message/1025488740 opw-5953504 Forward-Port-Of: odoo/odoo#254975
This update resolves an issue where reports would fail when the fiscal year ended on February 29th. The fix ensures that the system correctly handles leap year fiscal years, defaulting to March 1st for calculations. This prevents reporting errors and ensures accurate financial data.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965 Forward-Port-Of: odoo/enterprise#115400
This update resolves an issue that prevented users from creating quality checks when a product wasn't specified during the quality point setup. The fix ensures that the system handles missing product information gracefully, preventing a ValueError and allowing quality checks to be created successfully. This improves the reliability of the quality control process.
Original PR description
When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763 Forward-Port-Of: odoo/enterprise#115292
This update resolves an issue that occurred when installing the Saudi Arabia EDI module, specifically during demo data setup. The problem arose from deleting demo invoices, which triggered an error when the system attempted to update records. The fix ensures the system handles missing records gracefully, preventing the error and allowing users to successfully install and utilize the module.
Original PR description
Currently, error occurs when user tries to install Saudi Arabia EDI module. Steps to replicate: - Install `l10n_sa` with demo and switch to SA company. - Open Invoices > `INV/2026/00001` > Reset to…
Currently, error occurs when user tries to install Saudi Arabia EDI module.
Steps to replicate:
- Install `l10n_sa` with demo and switch to SA company.
- Open Invoices > `INV/2026/00001` > Reset to draft > Delete.
- Open Invoices > `INV/2026/00002` > Reset to draft > Delete.
- Install `l10n_sa_edi`.
Error:
```
File '/home/odoo/src/odoo/saas-19.2/addons/l10n_sa_edi/demo/account_demo.py', line 16, in _l10n_sa_edi_onboard_sa_sale_demo
self.ref('demo_sa_invoice_1', raise_if_not_found=False)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
```
Cause:
- As the user deleted `INV/2026/00001` (linked to `demo_sa_invoice_1`) and `INV/2026/00002` (linked to `demo_sa_invoice_2`), [here] when we try to create a recordlist to update we get this error.
Solution:
- Avoided direct concatenation of `self.ref(...)`, which may return None.
- Iterated over the expected IDs, fetched records safely, and skipped missing ones before processing.
[here]: https://github.com/odoo/odoo/blob/b8bcaa6af2531f49654d804231942b6af2261933/addons/l10n_sa_edi/demo/account_demo.py#L15-L20
sentry-7458234787
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262666A technical issue preventing background video previews was resolved. The commit removed a broken Vimeo video link from the system, preventing error messages when users selected background videos. This ensures a smoother experience for website builders.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772 Forward-Port-Of: odoo/odoo#264080 Forward-Port-Of: odoo/odoo#263555
This update fixes an issue where discount lines in Czech VAT summary reports were incorrectly calculating values. The root cause was a conversion process that was incorrectly handling negative balances. The fix ensures accurate reporting of VAT amounts, particularly for invoices with discounts.
Original PR description
Step to reproduce: - install l10n_cz_reports_2025 and switch to cz company - create a invoice, with cz company ( as partner), of 100. - when adding products, add "Transaction code" (optional fields) to "Goods" - Add discount line, set to -10, add "Transaction code" in this line too. - confirm it Observation: - invoice is 90$ - open vies summary report for this year - value turn out to 110 Cause: - commit [1](https://github.com/odoo/enterprise/commit/892268c44b1bbc838a9f03ef36a079bfff625ca6) converts every balance to +ve and only negate it, in case of refund - in case of discount lines, price is -ve, ABS() turn it to +ve and value comes out to be wrong Fix: - instead of applying ABS() directly, we flip the signs only for out_* moves, in short when a account is credited, its balance is < 0 then we flip its sign opw- 5979262 Forward-Port-Of: odoo/enterprise#117038 Forward-Port-Of: odoo/enterprise#113087
This update fixes a minor discrepancy in the Norwegian tax settings. The tax rate for code 32 was incorrectly set to 11.0. This change ensures accurate tax calculations for Norwegian businesses using Odoo, aligning with official tax regulations. This was coordinated with a related Enterprise PR.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027 Forward-Port-Of: odoo/odoo#264221 Forward-Port-Of: odoo/odoo#258390
This update corrects errors in the Norwegian VAT XML export that were preventing successful validation by Skatteetaten (the Norwegian tax authority). The changes ensure accurate decimal formatting, mathematical calculations, and required legal notes are included, allowing VAT returns to pass government scrutiny. This resolves a critical issue impacting accurate tax reporting.
Original PR description
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal…
Before commit: The Norwegian VAT XML export fails Skatteetaten validation due to incorrect decimal formatting, mathematical rounding mismatches between base and tax amounts, missing mandatory legal notes, and invalid KID number formats. Fix: To strictly follow Skatteetaten validation rules for the Norway VAT XML, the following changes were implemented: - Ensured standard rates drop the decimal (e.g, `25.0` to `25`), and formatted fractional rates like `11.11` to `11,11` in XML. - Rounded down the `tax_amount` to align precisely with government mathematical expectations. - `base_amount` converted into absolute value to ensuring the calculation (`base * rate = tax`) resolves perfectly. - Add the mandatory `<merknad>` explaining the reverse charge method for codes 81, 83, 86, 88, and 91. - Clean the `company_kid` by safely stripping the 'NO' prefix, and 'MVA' suffix. Expect: The generated XML payload now adheres perfectly to Skatteetaten's strict structural and mathematical rules, allowing the VAT return to pass government validations successfully. Related Community PR: https://github.com/odoo/odoo/pull/258390 Task-6033027 Forward-Port-Of: odoo/enterprise#117168 Forward-Port-Of: odoo/enterprise#110792
This update resolves an issue where Ctrl+A selection in the HTML editor would crash when used with images that had captions. The fix ensures the selection correctly targets the editable content, regardless of whether it's an image or a caption, improving the user experience and preventing unexpected errors.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261968
This update fixes a limitation in how attachments are uploaded through cron jobs. Previously, a single cron job was restricted to uploading only one attachment at a time. Now, the system allows multiple attachments to be uploaded within a single cron job run, improving efficiency for automated uploads.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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 Forward-Port-Of: odoo/odoo#264328
The 'Waiting for Me' filter in the Sign app was incorrectly fetching all documents instead of filtering those requiring the current user's signature. This update corrects a technical issue related to how the system processes filter criteria, ensuring the filter functions as intended and displays only relevant documents.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#117049
Forward-Port-Of: odoo/enterprise#113760This update resolves a crash within the Odoo website event editor when the event is set as the homepage. The issue stemmed from a missing match case in the event ID retrieval process. By adding a default return value, the editor now functions correctly, ensuring a stable user experience when editing homepage events.
Original PR description
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the…
**Description of the issue/feature this PR addresses:** The `WebsiteEvent._getEventObjectId` method lacks a specific match case for the root directory, causing event ID retrieval to fail on the homepage. In order to resolve this, I've implemented a default return of 0 when the URL pattern matching fails [following the pattern established by later revisions of this code](https://github.com/odoo/odoo/blob/2199f71070ce3e9a4717eb6b750c14485406f7aa/addons/website_event/static/src/website_builder/event_page_option_plugin.js#L67). **Steps to reproduce bug:** 1. Create an event website 2. Create an event and visit it 3. On the page click Site > Properties 4. Enable `Is Homepage` 5. Return to the homepage of the application and open the editor https://drive.google.com/file/d/1OpCUAp4LJKqkoStciWeJEGVVlR3qpw1R/view?usp=drive_link **Current behavior before PR:** https://drive.google.com/file/d/1c7ACqaQx03mePzJSV_RoPn8mlLWSMa1I/view?usp=drive_link **Desired behavior after PR is merged:** https://drive.google.com/file/d/1L3Ne9h6-yB3v7VbXipjly9OrDSkZvDOu/view?usp=drive_link opw-6101680 Forward-Port-Of: odoo/odoo#263548 Forward-Port-Of: odoo/odoo#258502
This update resolves a bug that caused invoices with specific address configurations to fail during the cash rounding process. The fix ensures the correct partner information is used when applying cash rounding, preventing data deletion and ensuring accurate invoice processing. This improves stability and reliability for invoicing operations.
Original PR description
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install…
When applying a cash rounding with 'biggest tax' strategy, it happens that we end up with a MissingError when the invoice's partner is not defined as commercial_partner_id. Steps: - Install membership module - Create a cash rounding with the 'biggest tax' strategy and 0.05 rounding - Enable customer addresses and create a partner P with an invoice address I - Create an invoice, select I as customer (P will be assigned as delivery address but this is not relevant) - Add an invoice line for 100.03 and any tax and apply the cash rounding - Confirm -> MissingError: record has been deleted Cause: - When creating the cash rounding lines, we set the `partner_id` from the invoice's partner (in our case partner I, which has P as `commercial_partner_id`). - When posting the invoice we look for lines that have partner id different than the invoice's commercial partner id and we call the write method to set the commercial partner id instead https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L5234-L5239 - In some cases, for example in the `membership` module, the override of the write method calls the super() before using `self`. https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/membership/models/account_move.py#L45-L49 But the super triggers the `_sync_tax_lines` mechanism, during which the rounding line in deleted https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_tax.py#L3102-L3110 https://github.com/odoo/odoo/blob/832165841f66675c0238652c5b0e5e0b6f75ca43/addons/account/models/account_move.py#L3113-L3114 Therefore `self` doesn't exist anymore when comming back in the override Fix: Setting the commercial partner on the rounding line to avoid calling the write method opw-6128868 Forward-Port-Of: odoo/odoo#262759
This update fixes a potential issue where users could accidentally assign multiple POS shops to a single cash payment method. Now, the system will prevent this, ensuring accurate payment tracking and avoiding errors when processing transactions. This improves data integrity and simplifies the payment process.
Original PR description
**Before this commit** The user will be able to assign two different POS shop to a cash payment method by going to POS -> Configuration -> Payment Methods -> Cash -> Point of sale, this will not raise a validation error when they try to save it but it will prevent the user from opening the POS session. **After this commit** It will raise a validation error if a user tries to assign more than one POS shop to one cash payment method and save it. opw-6015025 Forward-Port-Of: odoo/odoo#252603
This update resolves an issue where users could create attachments that pointed back to themselves, leading to errors. The fix prevents attachments from being linked to themselves in the user interface and during data writing, ensuring data integrity and preventing system crashes. This improves stability and reliability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591 Forward-Port-Of: odoo/odoo#264439 Forward-Port-Of: odoo/odoo#263591
A test within the l10n_latam_check module failed due to a dependency on the l10n_ar module not being installed. This update ensures the test runs correctly by requiring l10n_ar to be present, resolving a technical error.
Original PR description
Steps to reproduce: 1- Install l10n_latam_check on a fresh database instance 2- Run the test `test_invoice_status_after_voided_check` Issue: `ValueError: External ID not found in the system: l10n_ar.dc_liq_uci_a` Why this happens: The test used a document type from the l10n_ar module, so running the test without it being installed caused an error. runbot-243341 Forward-Port-Of: odoo/odoo#262800
This update ensures Odoo's audit trail feature in India (l10n_in) complies with Ministry of Corporate Affairs regulations. Previously, the audit trail could be disabled, but this change permanently restricts deactivation, guaranteeing ongoing compliance and data integrity for Indian users. This is a critical fix for businesses operating in India.
Original PR description
After the refactor introduced in https://github.com/odoo/odoo/commit/f280f762b6417fa1a0b09649ffbdecafcc7e7579, The audit trail feature was split into two modes: a lightweight general-purpose mode and a force-restricted mode for specific localizations (e.g., Germany), where deactivation is not allowed once enabled. In India, as per the requirements of the Ministry of Corporate Affairs, the audit trail must be maintained and cannot be disabled once activated. This commit extends the force-restricted audit trail mode to the Indian localization (l10n_in) to ensure compliance with statutory requirements. task-6182002 Forward-Port-Of: odoo/odoo#264569 Forward-Port-Of: odoo/odoo#262508
This update corrects inaccuracies in the French Chart of Accounts translations within the Odoo accounting module. The fix ensures that financial reports and data displayed in French adhere to the correct accounting standards, improving accuracy and compliance.
Original PR description
task-6210436
This update resolves an issue where dragging calendar events on touch screens would cause the application to crash. Now, dragging and releasing events works smoothly on both touch and mouse devices, improving the user experience for all calendar users.
Original PR description
When using the Calendar app on a touch screen, dragging an event and releasing it would raise a client error. Releasing a dragged event now works smoothly on both mouse and touch devices. task-6124833 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 Forward-Port-Of: odoo/odoo#263361
This update fixes a previous issue where the closing popup for bank payments didn't accurately display the number of payments made. Now, the popup correctly shows the total count of payments associated with a bank method, reducing user confusion and improving the clarity of payment information. This enhancement ensures users have a complete understanding of their transactions.
Original PR description
Before this commit, in the closing popup if a bank payment method had more than one payment, it would not show the count of payments, which could lead to confusion for the user. opw-6198656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263234
This update fixes an issue where large tablets with touch capabilities incorrectly displayed the mobile toolbar instead of the desktop toolbar. The change now considers screen size, ensuring the correct toolbar is shown on all devices, improving the user experience for tablet users.
Original PR description
Problem: On large tablets with touch capability and high resolution, the mobile toolbar is displayed instead of the desktop toolbar. Cause: The mobile toolbar condition relied on touch capability alone, without considering screen size. Devices with large screens but touch support were therefore incorrectly treated as mobile. Solution: Use `utils.isSmall()` to determine whether the device should display the mobile toolbar, ensuring screen resolution is taken into account. Steps to reproduce: - Open the editor on a large tablet. - Observe that the mobile toolbar is shown. - The desktop toolbar should be displayed instead. task-6106531 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259605
This update resolves an issue where changing a heading tag within a selection didn't properly remove the original heading style. The fix utilizes a different function within the HTML editor to ensure heading styles are accurately reset when a tag is modified, improving the consistency of formatting.
Original PR description
Problem: When applying `h1` to part of a selection already inside an `h2`, the selected content still keeps the `class="h2"` style. Cause: `removeFormats` internally uses `formatSelection`, but in this case we only want to change the tag and not reformat the selection. This causes existing heading styles to remain applied. Solution: Use `removeFormat` instead, as it removes formatting without applying additional formatting to the selection. Steps to reproduce: - Go to Website and drop the "Text-Image" snippet. - Copy the text "Enhance Your Experience". - Paste the text into a new To-Do. - Select part of the pasted text. - Change it from "Header 2" to "Header 1 Display 1". - Observe that part of the text still keeps the "Header 2" style. task-6204505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263810
This update resolves an issue that prevented invoices with combo products lacking taxes from being processed correctly when generating Peru UBL invoices. The fix ensures that combo product lines without taxes are properly validated, preventing a traceback and ensuring successful invoice generation. This improves the reliability of the Peru UBL integration.
Original PR description
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data -…
A traceback occurs when sending an invoice to Peru UBL if a combo product invoice line does not have any taxes applied. Steps to reproduce the error: - Install ``l10n_pe_edi`` module with demo data - Switch to PE Company - Create an invoice > Add a Office Combo product > unset the taxes > Confirm - Process now https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_xml_ubl_pe.py#L549-L552 Here, the ``grouping_key`` becomes ``None`` when no taxes are present on the invoice line. Normally, invoices without taxes are restricted at [1], but combo products are excluded from this validation at [2]. As a result, combo product lines without taxes bypass the restriction and trigger a traceback. [1]: https://github.com/odoo/enterprise/blob/d7f71a68fbd5ff9c7cd52f96e1616671a6b8d77c/l10n_pe_edi/models/account_edi_format.py#L928-L929 [2]: https://github.com/odoo/odoo/blob/42b8852df9b323984364c41a13cf27d19fbe04a7/addons/account/models/account_move_line.py#L3433-L3434 sentry-7430552834 Forward-Port-Of: odoo/enterprise#117365 Forward-Port-Of: odoo/enterprise#114798
This update fixes an issue where UBL invoices could incorrectly apply taxes due to differences in fiscal positions. The change ensures that only taxes matching the invoice's fiscal position are used during import, improving the accuracy of financial data. This prevents errors related to tax calculations and reporting.
Original PR description
When importing a UBL invoice, multiple taxes may share the same rate (e.g. 21%) but differ by fiscal position. Without filtering, the wrong tax (e.g. the domestic one for a foreign partner) could be selected. task-6138749 Forward-Port-Of: odoo/odoo#264597 Forward-Port-Of: odoo/odoo#263872