Daily updates from Odoo
Wednesday, March 4, 2026
26 changes · saas-18.3
Resolved issues and error corrections
This update ensures that One Stop Shop (OSS) invoices for intra-EU B2C sales in Italy are correctly formatted for the Italian Revenue Agency (Agenzia delle Entrate). Previously, the system rejected these invoices due to incorrect VAT formatting. Now, the system generates invoices with the necessary line items and tax summaries to meet FatturaPA compliance standards.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 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#249243 Forward-Port-Of: odoo/odoo#243740
This update fixes an issue where down payment invoices generated from sales orders or Point of Sale weren't automatically including tax. The fix adds a 0% tax line to down payment invoices to ensure compliance with tax regulations. This ensures accurate invoicing and avoids potential discrepancies.
Original PR description
In certain conditions all lines in invoice require a tax. When making a down payment from an order containing products using fixed price tax, the corresponding invoice line was created without tax.…
In certain conditions all lines in invoice require a tax. When making a down payment from an order containing products using fixed price tax, the corresponding invoice line was created without tax. The issue appear both when making the down payment from the sale order and from the PoS. Steps to reproduce: ------------------- * Create a fixed price tax of 10€ * Create a product with this tax * Create a sale order with this product and make a downpayment of 10% > Observation: The down payment line has no tax set. * Open PoS and make a down payment of 10% for the same order * Pay and invoice the order > Observation: The down payment line has no tax set. Why the fix: ------------ If the tax is required on every invoice line we manually add a 0% tax to the down payment line to ensure that the invoice is compliant. At the moment we only add the tax when peppol is activated on the current company. But the `_require_tax_ids_on_invoice_lines` method can be overriden by other modules if downpayment lines also require tax. opw-5853070 Forward-Port-Of: odoo/odoo#251459 Forward-Port-Of: odoo/odoo#247748
This update resolves an issue where product variant pricelists were not correctly updating when a product was removed from the list. Specifically, the system was failing to reset the data associated with the pricelist rule after a product was deleted. This fix ensures accurate pricing information is displayed for product variants, preventing potential revenue discrepancies.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250531 Forward-Port-Of: odoo/odoo#249417
This update fixes a minor issue where a warning about leaving a chatbot conversation was displayed even after the conversation had already ended. Now, the warning only appears when a chatbot conversation is actively in progress, creating a smoother and less disruptive user experience for customers interacting with the chatbot.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251335 Forward-Port-Of: odoo/odoo#247918
This update resolves a bug where the selected time slot for self-order pickup was incorrect due to timing considerations. The fix now explicitly specifies the desired time slot and verifies its availability after execution, ensuring accurate scheduling and order fulfillment. This improves the reliability of the self-order process.
Original PR description
The selected time slot was not the right one as the time of the execution influed on the first choice available. We now specify which time slot to take, and check that this specific timeslot is not available anymore afterwards. runbot-233381
This update fixes a minor issue where the dynamic snippet carousel wasn't displaying correctly when showing a small number of items. The fix ensures a smoother, more consistent scrolling experience, especially with limited product data. It optimizes how the carousel handles data presentation for better performance.
Original PR description
Steps to reproduce: 1. Add a Dynamic Snippet Carousel(Products). 2. Set the number of records to 4. 3. Enable Single Scroll mode. Issue: When a dynamic snippet carousel is in single scroll mode (`o_carousel_multi_items`) and the number of fetched items is less than or equal to the visible slots per slide (`chunkSize`, typically 4 on desktop), the carousel still slides one item at a time. Cause: When `scrollMode` is single, the QWeb template generates each data item in its own `carousel-item` div. So with 3 products and 4 visible slots, we got 3 separate slides(this is the usual behavior of single scroll mode). But due to this bootstrap would slide between them one by one. Fix: If the number of fetched records is less than or equal to the number of elements per slide (chunkSize), use "all" scroll mode so that all items are grouped in a single slide instead of being split into individual carousel-items (which would cause unwanted sliding).
This update fixes a potential issue where VIES validation errors caused errors in Odoo, specifically impacting OCR invoice processing. By catching a broader range of exceptions from the VIES service, the system is now more resilient to invalid XML responses and prevents errors from propagating.
Original PR description
Catch all `zeep` exceptions instead of only `zeep.Fault`. On 14th of February 2026, the VIES service wasn't working properly, they were returning invalid XML in their response. This caused the `check_vies` call to raise a `zeep.XMLSyntaxError` which wasn't caught, causing a traceback every time VIES was used to validate a VAT number. opw-5938723 (OCR couldn't be refreshed on an invoice because it tried to create a partner from its VAT number and it couldn't be checked with VIES). Forward-Port-Of: odoo/odoo#249853
This update expands the color field options within the Odoo Gantt editor, allowing users to select all integer fields for color customization. Previously, the color field was limited to fields already present in the view. This change provides greater flexibility for visualizing project timelines and tasks.
Original PR description
Before this commit, only fields already present in the view were selectable for the color field in the gantt editor. After this commit, all int fields of the model are available task-5981029
This update resolves a problem with the CSV reports generated for Peru (l10n_pe_reports) that was triggered by a recent Python update. The fix ensures the reports are correctly formatted, preventing errors during export. This improves the reliability of financial reporting for our Peruvian customers.
Original PR description
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises ValueError: bad delimiter or lineterminator value This is due to…
Revealed when l10n modules got enabled on the "distro builds" nightly: on Trixie, `delimiter="|", lineterminator='|\n'` raises
ValueError: bad delimiter or lineterminator value
This is due to python/cpython#113797 which added new validations to dialect definitions. For this issue, that the delimiter can not be in the line terminator. This can be fixed via a different trick, which is documented:
> The optional `restval` parameter specifies the value to be written
> if the dictionary is missing a key in `fieldnames`.
so if we add a trailing fieldname which *can not* be found in the row dicts, then `DictWriter` will always write out an empty trailing cell (the default `restval` is an empty string), which should result in the same output.
Also remove the `csv.register_dialect` calls, that's so subsequent CSV calls can easily refer to a common configuration but here two different dialects are being registered under the same name, and each one is only used for the following `DictWriter` call, so at best this is a complete waste of time and at worst this is a race condition in threaded configurations. Just pass the formatting parameters directly to the `DictWriter`.
https://runbot.odoo.com/odoo/error/240950
Forward-Port-Of: odoo/enterprise#109081This update adds the street number to the demo company data for Denmark (l10n_dk). This is necessary to ensure accurate reporting and integration with nemhandel, a key payment processing system, improving the demo data's realism and usefulness for testing and demonstration.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes an issue where credit notes incorrectly rounded prices, leading to discrepancies in accounting. The change ensures that credit notes accurately reflect the original purchase price, regardless of rounding settings. This improves financial accuracy and reduces potential errors.
Original PR description
**Steps to reproduce:** - Setup a rounding of 0.05 - Add it to the PoS settings, turn on the only for cash setting - Make a purchase for 13.01, pay by card - Go to the backend, we have the correct price of 13.01 - Revert the invoice by making a credit note - The price is only 13.00 and we have a rounding of -0.01 **Why the fix:** When making a credit note, we round the price if we find a rounding method, not taking the **only_round_cash_method** setting into account. After this commit, we now check if the reversed entry (the invoice) has a rounding line. If it does not, we skip the rounding. If a rounding is found on the reversed entry, we still round the current account move. opw-5871514 Forward-Port-Of: odoo/odoo#249894 Forward-Port-Of: odoo/odoo#247617
This update fixes an issue where modifying production quantities in a Manufacturing Order would incorrectly create duplicate work orders. The fix ensures that work orders are correctly updated instead of duplicated, maintaining accurate production tracking. This improves the reliability of the MRP process.
Original PR description
Steps to reproduce: 1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty). 2. Create a Manufacturing Order (MO) for the product selecting BoM A. 3. Switch BoM A to BoM B, then…
Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.
The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.
Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.
TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855
opw-5489862
Forward-Port-Of: odoo/odoo#246995This update resolves an issue preventing multiple tax lines (like Enasarco and RIT) from being added to Italian invoices within the Odoo system. Previously, only the DOI tax could be listed on a single line. This change aligns with Italian tax regulations, allowing for more accurate invoice processing and reporting.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
A test failure related to invoice data formatting was resolved. The update ensures the correct data structure is used when generating electronic invoices, preventing potential errors and improving the reliability of the export process. This fix addresses a technical issue that could have impacted invoice generation.
Original PR description
In the `test_which_service_to_call` test, we are calling `_call_web_service_before_invoice_pdf_render` with invoice_data. But invoice_data is just a dict with `invoice.read()` and the extra key extra_edis. Instead of manually building invoice_data, we should call `_get_default_sending_settings`, which is meant to be used in the base `account.move.send` flow. Why this fix? Because by not calling `_get_default_sending_settings`, we risk changing the expected invoice_data format used in `_call_web_service_before_invoice_pdf_render`, which could lead to KeyErrors. Spotted while developing https://github.com/odoo/enterprise/pull/80590, the test failed, raising the ['invoice_edi_format'] key error. no-task Forward-Port-Of: odoo/odoo#232105
This update corrects a display issue where by-products tracked with serial numbers incorrectly showed extra lines in the shop floor manufacturing order view. Enabling a setting to pre-fill serial numbers for shop floor moves caused these extra lines to appear. The fix ensures by-products only show lines registered manually, improving clarity and accuracy in the shop floor workflow.
Original PR description
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in…
When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views). Steps to reproduce: 1. Create a bill of materials for a final product 2. Add a consumable component 3. Create an operation without steps 4. Add a by-product tracked by serial number 5. Specify that the by-product is produced in the operation above 6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves" 7. Create a manufacturing order for the BOM and confirm it 8. Open the Shop Floor view from the MO 9. Observe the extra line for the by-product in both overview and work center views Root cause: The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button. Solution: Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled. Task-5431295
This update resolves an issue where vendor bills from foreign VAT companies were not correctly identifying their country of origin. The fix adds the necessary country code to the beginning of the data, ensuring accurate reporting for JPK exports. This improves compliance with Polish tax regulations.
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This change ensures that the Website Studio XML editor only uses translated views for websites, preventing incorrect translations from being displayed. The update modifies how the Studio editor retrieves related views, specifically targeting the Website module to improve the user experience and avoid unintended translation behavior.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#249938 Forward-Port-Of: odoo/odoo#237000
This update ensures that the Website Studio XML editor correctly uses translations only for the specific website being edited. Previously, it incorrectly defaulted to translations for the first website in the database, leading to potential inconsistencies. This fix improves the accuracy of translations within the Studio environment.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#108199 Forward-Port-Of: odoo/enterprise#107459
This update fixes an issue where credential errors in the HR EDI system were displayed in a confusing format. It now presents these errors in a more user-friendly way and corrects XML generation for partners lacking OIB information. New tests have been added to ensure these changes function correctly.
Original PR description
- Credentials errors have a separate format in MER, they should now be displayed in a more user-fiendly manner - Correcting XML generation for partners with no explicit OIB provided - Adding tests for both changes task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249448
This update ensures that disabled user accounts are no longer incorrectly flagged as blacklisted when checking email restrictions. This change improves the accuracy of email delivery and prevents potential issues for users who have been deactivated. The fix was originally reported and addressed in a previous pull request.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update corrects a display issue where upsell sale orders created from subscriptions were incorrectly labeled as "Quotation". The fix ensures that upsell orders now display as standard sales orders, aligning with the naming convention for initial subscriptions. This improves clarity and consistency for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767This update resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for Early Payment Discounts (EPD) within this format, ensuring accurate invoice generation for businesses using this standard. This improves compliance and reporting accuracy.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251736 Forward-Port-Of: odoo/odoo#244659
This update corrects inaccuracies in the XML files used for Swedish payments (SEPA). Specifically, it ensures the correct BIC number is used instead of a placeholder, and allows users to manually select the SEPA payment version, regardless of the payment method chosen. This improves the accuracy and reliability of payment processing for Swedish customers.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536
This update ensures that product weights sent to the Sendcloud shipping API are always at least 0.001. Previously, the API required a minimum weight of 0.00099, which caused issues with certain products. This change ensures accurate shipping calculations and data transmission to Sendcloud.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update fixes an issue where tax reports were generating negative values for carried over tax lines (81-88). The change ensures that the XML output accurately reflects tax calculations, preventing potential errors in reporting and compliance. This improves the reliability of tax reports.
Original PR description
When generating the xml for tax report, negative values should not be present in the xml for carried over lines (81, 82, 83, 86, 87, and 88) Steps: - Create a RBILL for today - 1 month, add an invoice line with tax using one of the following tags: -81, -82, -83, -86, -87 or -88 in its base refund repartition line - Open the tax report on the month of the RBILL - Generate the xml, either by the dedicated button, or by creating and posting the closing entry -> there is line(s) for negative amounts opw-5955323 opw-5428395 Forward-Port-Of: odoo/enterprise#109389 Forward-Port-Of: odoo/enterprise#108916
This update corrects a previous error that prevented users from sending follow-up reports by post when they lacked sufficient permissions to modify company settings. The fix allows for report sending by automatically granting necessary access, ensuring reports can be generated without interruption. This resolves a potential roadblock in the reporting process.
Original PR description
Issue: Before this commit, when sending a follow up report by post, an access error is thrown if the user doesn't have enough access to modify the res.company model Fix: modifying the external_report_layout_id as sudo opw-5482855 Forward-Port-Of: odoo/odoo#248677