Tuesday, April 8, 2025
31 changes · 18.0
Enhancements to existing features
This pull request appears to be a test or work-in-progress update rather than a functional business change. Based on the provided file sample, it is unlikely to affect day-to-day users or business workflows.
Original PR description
just a test PR
This update adds a dedicated test class for tax total handling in the Italian Point of Sale module. It helps reduce the risk of tax calculation regressions and supports more reliable compliance-related behavior.
Resolved issues and error corrections
This fix prevents an error when users quickly click a breadcrumb after returning with the browser Back button from a form view. Navigation now remains smooth and reliable, reducing interruptions during everyday work.
Original PR description
Before this commit: When a user opened a form view and clicked browser's Back button, then immediately clicked on the breadcrumb, a traceback occurred. After this commit: Navigation works smoothly without crashes. Task-4667911
Miscellaneous changes
With this commit, the mail's body and subject is rendered when it was sent to the vehicle's driver. task-4671895 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#203250
Original PR description
With this commit, the mail's body and subject is rendered when it was sent to the vehicle's driver. task-4671895 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#203250
This fix prevents an error when a user clears the date while creating a journal entry. Odoo now checks for a date before preparing the placeholder entry name, helping users continue their workflow with clearer handling of missing information.
Original PR description
Description of the issue/feature this PR addresses: When creating a new journal entry, clearing the date field causes an error because the system tries to compute the placeholder name field using the date, which is missing. Current behavior before PR: An error is raised when the date field is cleared while creating a journal entry, as the computation of the name field relies on the date field being present. Desired behavior after PR is merged: The system will check if the date field is present before computing the name field. If the date field is missing, a default value will be used, or a clear validation error will be displayed to the user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Tax Return screen no longer shows the Print button for journal entries that cannot be printed as PDFs. This prevents users from hitting an error during document layout configuration and makes the reporting workflow clearer.
Original PR description
This error occurs when `o.tax_totals` returns `False`, causing an AttributeError when accessed in the QWeb template. Steps to Reproduce : - Install the module `accountant.` - Go to Reporting and open…
This error occurs when `o.tax_totals` returns `False`, causing an AttributeError when accessed in the QWeb template. Steps to Reproduce : - Install the module `accountant.` - Go to Reporting and open Tax Return. - Open Closing Entry and Print. `AttributeError: 'bool' object has no attribute 'get'` The error occurs when printing the tax report for the first time. The system first attempts to display the document configuration popup for the user based on the account move. However, since `o.tax_totals is not available` in the tax report `(as it is a journal entry)`, and when the user`Configure Document Layout`, it raises a validation error. At [1] we cannot print pdf when `move_type == entry` so it is better to hide `Print` button in this condition. This error is resolved by hiding the `Print` button in the `Tax Return` `Journal Entries`, as it only contains journal items. Link [1] : https://github.com/odoo/odoo/blob/63fc0d1cefaf8f59acd0743a225d1002425ff156/addons/account/models/ir_actions_report.py#L72 sentry-6115648026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the Set Default Values popup no longer crashes when a record includes hidden fields. This keeps debug tools usable for administrators and support teams without interrupting their workflow.
Original PR description
Problem: When trying to open the "Set Default Values" modal, a traceback occurs if the record contains an invisible field, due to `displayed` being `undefined`. Solution: Safely check the length of `displayed` before using it. Steps to reproduce: 1. Open CRM. 2. Open any record. 3. Enable Debug Mode. 4. Click "Set Default Values". 5. Observe the traceback. opw-4707774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printed documents using the Bubble layout now keep long customer names and document titles properly aligned. This prevents invoice titles from being cropped or misplaced, improving the reliability of customer-facing PDFs.
Original PR description
### Steps to reproduce: - Create a contact with a very very long name - Change the layout of documents to "Bubble" - Create an invoice with the new contact - Confirm and Print - The invoice title is unaligned or cropped ### Cause: The layout is using a flexbox to display the contact and the title on the same level. But flex boxes are not supported by whtmltopdf so the result is random. ### Solution: Use a `table` mimicking the flex display. Before:  After:  opw-4653504
When a manager refuses an employee's overtime, the validated extra hours are now reset to zero. This prevents refused overtime from incorrectly appearing as approved time in attendance records and related reporting.
Original PR description
### Steps to reproduce: - Go to settings, set the overtime of an attendance to be validated by a manager - Go to attendance, create an attendance with an overtime - Worked Extra Hours and Extra Hours are the same - Refuse the overtime - Extra Hours is not 0 ### Cause: This is happening because when computing the overtime validated hours we are just setting it equals to the worked extra hours value when the status of the attendance is to_approve but when it got refused we don't re-compute the value. https://github.com/odoo/odoo/blob/0d0c1bc7c075f49a461c66a433e20b431276ff12/addons/hr_attendance/models/hr_attendance.py#L164-L166 ### Fix: We are overriding the value for the validated overtime hours now when it got refused and set it equals to 0 opw-4675268
Chilean PDF invoices using the boxed layout now display total amounts with the same styling as standard invoices. This prevents totals from appearing in hard-to-read black text on colored backgrounds, making invoices clearer for customers and staff.
Original PR description
## Version:
18.0+
## Issue:
PDF invoices in boxed document layout always display a black font for total amount value only for Chile. This black font is not easily readable for most background colors (incl. standard background).
## Steps to reproduce:
- Navigate to the Settings app:
- Under the `Companies` section, configure the document layout: - Ensure the `Boxed` layout is selected;
- Navigate to the Invoicing app:
- Open any invoice record from `Customers / Invoices`;
- Via the `Actions` gear button, print the `PDF without Payment`.
## Cause:
Template inconsistency compared to standard report template: https://github.com/odoo/odoo/blob/3ebd200a76d490ed97bc164e80ed2837fb2f650f/addons/account/views/report_invoice.xml#L443-L450.
opw-4698105
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where some customer invoice pages could fail to display when payment installment information was missing. The invoice template now handles missing installment status safely, improving reliability for portal users viewing invoices.
Original PR description
Previously, when installment_state was None,
the template raised an error because None in ('next', 'overdue') is not a valid operation.
This change ensures safe access to installment_state using .get(), preventing potential errors when
the key is missing or its value is None.
**Description of the issue/feature this PR addresses:**
The invoice template was raising an error when installment_state was None, as the condition None in ('next', 'overdue') is invalid.
**Current behavior before PR:**
If installment_state is None, the template crashes due to an invalid comparison.
**Desired behavior after PR is merged:**
The template now safely retrieves installment_state using .get(), preventing errors when the key is missing or its value is None.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where some images in emails could appear incorrectly because a common image sizing style was being removed. Emails that rely on fitted images should now render more consistently for recipients.
Original PR description
The 'object-fit' CSS property is currently not whitelisted in the sanitizer, leading to images not being displayed correctly in mails. opw-4655989
Small typo in .po file 'YVotre' => 'Votre' Steps to reproduce: ------------------- * Create an RFQ * Add a vendor with french contact language * Add a vendor reference * Print the pruchase order > Observation: Why the fix: ------------ Typo opw-4677629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Small typo in .po file 'YVotre' => 'Votre' Steps to reproduce: ------------------- * Create an RFQ * Add a vendor with french contact language * Add a vendor reference * Print the pruchase order > Observation: Why the fix: ------------ Typo opw-4677629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the German Intrastat XML report generation by adding a missing supplementary unit code. It helps ensure the report can be generated correctly and reduces the risk of failed compliance reporting exports.
Original PR description
account_intrastat_report.xml: missing SUCode for xml report generation in l10n_de_intrastat build_error-160011
When you add a table via "/table" when you're in editing mode, and if there's a lot of content, then the content overlaps. This is noticable in the small devices as well as bigger devices. We'll stop the overflow by using overflow-wrap: break-word. Steps To Reproduce on Runbot: 1. Go to editor via website/elearning. 2. Add table via command "/table" 4. Make the table like size 11*2, and keep typing on a cell, eventually the text will start overflowing. opw-4317744 Forward-Port-Of:
Original PR description
When you add a table via "/table" when you're in editing mode, and if there's a lot of content, then the content overlaps. This is noticable in the small devices as well as bigger devices. We'll stop the overflow by using overflow-wrap: break-word. Steps To Reproduce on Runbot: 1. Go to editor via website/elearning. 2. Add table via command "/table" 4. Make the table like size 11*2, and keep typing on a cell, eventually the text will start overflowing. opw-4317744 Forward-Port-Of: odoo/odoo#192128
### Steps to reproduce: - Install "l10n_it_edi" and switch to Italian company - Accounting > Customers > Invoices - Create a new invoice - Add a partner and go to this partner form - Change the field "Codice Fiscale" with a lowercase value, like "Mrtmtt91d08f205j" - Confirm the invoice and send it to the Tax Agency - The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to
Original PR description
### Steps to reproduce: - Install "l10n_it_edi" and switch to Italian company - Accounting > Customers > Invoices - Create a new invoice - Add a partner and go to this partner form - Change the field "Codice Fiscale" with a lowercase value, like "Mrtmtt91d08f205j" - Confirm the invoice and send it to the Tax Agency - The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to return the uppercase value. (Already the case for "Destination Code (SDI)") To increase the user experience, also add `text-uppercase` on the input in `l10n_it_edi_website_sale` so the text entered there is always capital. Same for "Destination Code (SDI)". opw-4655364 Forward-Port-Of: odoo/odoo#204865 Forward-Port-Of: odoo/odoo#203217
Versions -------- - 17.0+ Steps ----- 1. Configure website to prevent sale of zero-priced products; 2. add a zero-priced product as an alternative product to a product; 3. open the product in eCommerce. Issue ----- The alternative products block with the zero-priced product isn't shown. Cause ----- The `_get_products_alternative_products` method filters out zero-priced products out of its end result. It is the only snippet filter to do this. Solution -------- Don't filter
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to prevent sale of zero-priced products; 2. add a zero-priced product as an alternative product to a product; 3. open the product in eCommerce. Issue ----- The alternative products block with the zero-priced product isn't shown. Cause ----- The `_get_products_alternative_products` method filters out zero-priced products out of its end result. It is the only snippet filter to do this. Solution -------- Don't filter out zero-priced products, as users may still want those products to be visible, even if not available for sale. opw-4443410 Forward-Port-Of: odoo/odoo#204777
Versions -------- - 17.0+ Steps ----- 1. pay for a cart in eCommerce using Xendit; 2. leave the confirmation page before the payment confirms; 3. open cart & empty it. Issue ----- The payment gets confirmed for an empty cart. Cause ----- If a sale order has a transaction linked with a state of `pending`, `authorized` or `done`, the next call to `website.sale_get_order` will no longer return the order that was paid. The transaction's state only changes away from `draft` afte
Original PR description
Versions -------- - 17.0+ Steps ----- 1. pay for a cart in eCommerce using Xendit; 2. leave the confirmation page before the payment confirms; 3. open cart & empty it. Issue ----- The payment gets…
Versions
--------
- 17.0+
Steps
-----
1. pay for a cart in eCommerce using Xendit;
2. leave the confirmation page before the payment confirms;
3. open cart & empty it.
Issue
-----
The payment gets confirmed for an empty cart.
Cause
-----
If a sale order has a transaction linked with a state of `pending`, `authorized` or `done`, the next call to `website.sale_get_order` will no longer return the order that was paid.
The transaction's state only changes away from `draft` after receiving notification data from the provider. For Xendit, this can take up to half an hour[^1], leaving customers with a lot of time to (unintentionally) modify the cart they paid for.
Solution
--------
Use Xendit's `success_redirect_url` to mark transactions as pending while waiting for full notification data.
This way, any attempt to change the cart will force open a new one.
opw-4438779
[^1]: for this ticket's case:
8:26 AM: payment was sent to Xendit for Rp 18,000,000.00
8:39 AM: customer emptied their cart, setting total to Rp 0.00
8:56 AM: received confirmation that the transaction for Rp 18,000,000.00 was confirmed
Forward-Port-Of: odoo/odoo#204863
Forward-Port-Of: odoo/odoo#201611It is currently not possible to scan a combo. To reproduce the issue: (Use demo data) 1. Point of Sale > Products > Product Variantes, edit Office Combo - Add a barcode 2. Start the PoS Furniture Shop 3. Scan the barcode Error: a line is added on the left-side panel. Scanning the combo should actually open a popup so that the PoS user can select the products. About the behaviour: since [1], the barcode field is invisible on the template form of a combo. It is even mentioned o
Original PR description
It is currently not possible to scan a combo. To reproduce the issue: (Use demo data) 1. Point of Sale > Products > Product Variantes, edit Office Combo - Add a barcode 2. Start the PoS Furniture…
It is currently not possible to scan a combo. To reproduce the issue: (Use demo data) 1. Point of Sale > Products > Product Variantes, edit Office Combo - Add a barcode 2. Start the PoS Furniture Shop 3. Scan the barcode Error: a line is added on the left-side panel. Scanning the combo should actually open a popup so that the PoS user can select the products. About the behaviour: since [1], the barcode field is invisible on the template form of a combo. It is even mentioned on the excalidraw. However, the field is still visible on all other views. Moreover, there isn't any constraint or anything to prevent such a template from having a barcode. Discussed with the PO, for spec clarifications: > Scanning a combo wasn't really planned in the first place. > I can imagine the case where they print the barcodes on the side. > It's OK if it's scannable, but that doesn't mean we should make > the field visible About the issue: quite simple, when scanning the barcode, it leads to https://github.com/odoo/odoo/blob/6a6b70c9bf2420380ae91ca8f5b21f2bfbc1a5b9/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L209-L213 Where the third argument is `false`, cf `needToConfigure`: https://github.com/odoo/odoo/blob/7a2923af64bd196a8271af4c99a37ac8ce3e15f8/addons/point_of_sale/static/src/app/models/product_product.js#L39-L49 The call to `addLineToCurrentOrder` will lead to `addLineToOrder`, where the parameter `configure` is `false` (as explained just above). As a result, even if the product is correctly identified as a combo, we don't open the popup https://github.com/odoo/odoo/blob/14d51bd960d7dd49cb234722b7725b98549feb04/addons/point_of_sale/static/src/app/store/pos_store.js#L735-L742 Taking the `configure` parameter doesn't seem to make sense with combo products, as these ones always stand for some other products that the user should select. [1] https://github.com/odoo/odoo/commit/65652c73ba5331f77911186543062dfddf50f077 OPW-4474214 Forward-Port-Of: odoo/odoo#203314
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Enterprise PR: https://github.com/odoo/enterprise/pull/81644 task-4587067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Enterprise PR: https://github.com/odoo/enterprise/pull/81644 task-4587067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204462 Forward-Port-Of: odoo/odoo#202228
This pull request makes broad internal updates across Odoo’s core startup and base components. The changes appear to focus on maintenance and compatibility foundations rather than introducing a specific user-facing feature.
Original PR description
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
Avoid using a set when loading server-wide modules to ensure a deterministic and consistent module loading order. This change ensures 'base' and 'web' are always loaded in that specific order, improving predictability. Forward-Port-Of: odoo/odoo#204967
Original PR description
Avoid using a set when loading server-wide modules to ensure a deterministic and consistent module loading order. This change ensures 'base' and 'web' are always loaded in that specific order, improving predictability. Forward-Port-Of: odoo/odoo#204967
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human readable format, the XML invoice itself will still be added as an attachment as specified in ISO 19005-3 titled "Document management - Electronic document file format for long -term preservation - Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", and contain the compliant
Original PR description
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human…
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human readable format, the XML invoice itself will still be added as an attachment as specified in ISO 19005-3 titled "Document management - Electronic document file format for long -term preservation - Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", and contain the compliant XML invoice as an embedded object.` Current behavior before PR: - Generated Saudi Localization PDF Invoice had not embedded attached EDI XML documents - Generated Saudi Localization PDF Invoice was not PDF-A Compliant - Generated Saudi Localization PDF Invoice file name did not adhere to ZATCA business rules of the following: `Seller Vat Number (BT-31), Date (BT-2), Time (KSA-25), Invoice Number (BT-1)` Desired behavior after PR is merged: - Generated Saudi Localization PDF Invoice has the XML EDI documents embedded as an attachment - Generated Saudi Localization PDF Invoice is PDF-A Compliant - Generated Saudi Localization PDF Invoice is named as per the ZATCA business rules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr opw-4528551 Forward-Port-Of: odoo/odoo#204689 Forward-Port-Of: odoo/odoo#198158
Factur x cannot have negative lines on <ram:ChargeAmount> which can happen when there is a discount on the invoice. - Create a sale order with a global discount, generate the invoice and generate the factur x xml. - The amount on <ram:ChargeAmount> is negative. We can instead invert both price unit and quantity to have the same result. Inspired by 6f0642d62b6a07141553b655ee3c2b4369bf8ffb which did the same fix for ubl. opw-4668558 Description of the issue/feature this PR addresse
Original PR description
Factur x cannot have negative lines on <ram:ChargeAmount> which can happen when there is a discount on the invoice. - Create a sale order with a global discount, generate the invoice and generate the factur x xml. - The amount on <ram:ChargeAmount> is negative. We can instead invert both price unit and quantity to have the same result. Inspired by 6f0642d62b6a07141553b655ee3c2b4369bf8ffb which did the same fix for ubl. opw-4668558 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#204397 Forward-Port-Of: odoo/odoo#203298
Commit f494e9d addressed an issue with an edge case of move/picking state conflicts. But in v16 this has the adverse effect of breaking valuation for scrap actions by generating additional corrective SVLs during the confirmation of a stock scrap. We should revert the change for v16, as the original use-case is very non-critical and the more changes made in this version, the higher chances of inadvertently breaking other things. opw-4574728 Forward-Port-Of: odoo/odoo#203945 Forward-Port
Original PR description
Commit f494e9d addressed an issue with an edge case of move/picking state conflicts. But in v16 this has the adverse effect of breaking valuation for scrap actions by generating additional corrective SVLs during the confirmation of a stock scrap. We should revert the change for v16, as the original use-case is very non-critical and the more changes made in this version, the higher chances of inadvertently breaking other things. opw-4574728 Forward-Port-Of: odoo/odoo#203945 Forward-Port-Of: odoo/odoo#203478
Discounts on non recurring products were being recomputed every time the subscription was paused and resumed. Added a protecting similar to action_confirm in order to prevent this behavior. opw-4440500 Forward-Port-Of: odoo/enterprise#82858
Original PR description
Discounts on non recurring products were being recomputed every time the subscription was paused and resumed. Added a protecting similar to action_confirm in order to prevent this behavior. opw-4440500 Forward-Port-Of: odoo/enterprise#82858
PR https://github.com/odoo/enterprise/pull/82924 makes use of the field l10n_ar_currency_rate. But that field is not present in Odoo versions above 17.0 This field was removed in favor of invoice_currecy_rate from account_move, that stores the currency rate used for a document in Odoo 17 and above. This fix adapts the l10n_ar module to use that field instead. opw-4708505 Forward-Port-Of: odoo/enterprise#82974
Original PR description
PR https://github.com/odoo/enterprise/pull/82924 makes use of the field l10n_ar_currency_rate. But that field is not present in Odoo versions above 17.0 This field was removed in favor of invoice_currecy_rate from account_move, that stores the currency rate used for a document in Odoo 17 and above. This fix adapts the l10n_ar module to use that field instead. opw-4708505 Forward-Port-Of: odoo/enterprise#82974
Partial revert of the odoo/enterprise#78827 fix. The payment due date is in facts the payment date itself. This way we are able to handle different lines each with a different due date. The user will have to put it correctly manually in the Register Payment wizard even if the Payment Terms are specified on the invoice. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4703520) opw-4703520 Forward-Port-Of: odoo/enterprise#82950
Original PR description
Partial revert of the odoo/enterprise#78827 fix. The payment due date is in facts the payment date itself. This way we are able to handle different lines each with a different due date. The user will have to put it correctly manually in the Register Payment wizard even if the Payment Terms are specified on the invoice. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4703520) opw-4703520 Forward-Port-Of: odoo/enterprise#82950
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82733 Forward-Port-Of: odoo/enterprise#81644
Original PR description
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82733 Forward-Port-Of: odoo/enterprise#81644
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#81842 Forward-Port-Of: odoo/enterprise#79775
Original PR description
Change VAT in invoice report if the invoice is set as cfdi to public to use a generic vat for both national and international clients to have more coherence with the xml that is generated for the invoice. task-4588311 Forward-Port-Of: odoo/enterprise#81842 Forward-Port-Of: odoo/enterprise#79775
This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715
Original PR description
This fix aims to increase the operation timeout to reduce the risk of timeouts when sending documents. If a timeout occurs when sending a document, Odoo will consider it an error and allow the resend, even though the document will have been successfully accepted by the Carvajal service. opw-4608647 Forward-Port-Of: odoo/enterprise#82715