Wednesday, September 24, 2025
77 changes
3 changes
Resolved issues and error corrections
Fixed an issue that could block sending certain Colombian electronic invoices when a debit note reference was missing. This prevents users from hitting an error during invoice email submission and improves reliability for Colombian localization workflows.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763
The follow-up report no longer crashes when users load more entries for customers with many invoices. This helps accounting teams reliably review customer payment follow-ups without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes the spreadsheet component and fixes an issue when sorting certain array formulas. Users should see more reliable spreadsheet behavior when working with formulas and sorted data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0c9130545 [REL] 18.4.12 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e9cb9e1b9 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
3 changes
Resolved issues and error corrections
Fixed an issue in Accounting reports where the Follow-Up Report could crash when users loaded additional invoice lines for customers with many invoices. This ensures users can review large follow-up reports without interruption.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
2 changes
Resolved issues and error corrections
The Accounting reports follow-up view has been corrected so users can load additional invoice lines without hitting an error. This prevents interruptions for teams reviewing customer statements or follow-up reports with many invoices.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
4 changes
Resolved issues and error corrections
Colombian electronic invoices no longer fail when users send an invoice with a debit note operation type but no linked reference invoice. This prevents a blocking error during email/DIAN submission and makes invoice sending more reliable for Colombian companies.
Original PR description
8 changes
Resolved issues and error corrections
The Mexican electronic invoicing flow now handles customer legal names entered with accents when creating invoices from the self-invoicing portal. This prevents avoidable invoice stamping failures when government records store the same names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
1 change
Resolved issues and error corrections
The Czech VAT return now places invoices without a partner VAT number in section A5 regardless of their value. It also consistently classifies special VAT regime entries for travel services and margin schemes in A5, helping businesses submit more accurate VAT control statements.
Original PR description
Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787
4 changes
Resolved issues and error corrections
Imported Chilean supplier invoices now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being recorded with overstated positive values, improving accounting accuracy for affected DTE imports.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103The spreadsheet component was updated to the latest version for this Odoo release. This fixes an issue where sorting could fail for certain array formulas, helping users work more reliably with spreadsheet data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/fb227d71f [REL] 18.3.22 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/220054c18 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Customers using in-store pickup will now have the default pickup location properly saved at checkout, even if they did not choose it before adding an item to the cart. This prevents a confusing checkout error that blocked customers from continuing to payment when the page appeared to show a valid pickup location.
Original PR description
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user…
Description of the issue/feature this PR addresses: This commit fixes the issue where the pickup location does not get set even though it is present on the checkout page. This happens when the user directly adds an item to cart without specifying the pick up location before adding to cart. This results in the location not being set but at the checkout page, the default pick up location appears as one of the warehouses given the way the default pickup location is set when loading the checkout page values. This makes the user think that the pickup location is set, but when they try to go to the pay page, an error is thrown saying the pick up location was not specified. This commit sets the pickup location data in such a case. [This commit] refactored the way in which the default location would be set on the checkout page but did not take into account the possbility that the customer might not select the pickup location when they are adding to cart, thus only rendering the value at the checkout page but not actually setting it. Refactored the test cases to avoid the redundancy in the setup process. Steps to reproduce on runbot: 1. Set the pick up in store as the default delivery method by updating the sequence 2. Go the shop on the website and add any item to cart which has stock in the specified pickup location, but don't select the pickup location here 3. Go to the cart and click checkout 4. The default pickup location will be set here 5. Click on Confirm 6. An error will appear saying the location was not set opw-4954187 [This commit]: https://github.com/odoo/odoo/commit/1d3942c75e59ac9538d112df43b4e39f2462fee4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. The system also prevents merging entries tied to different tickets, helping avoid lost ticket history and reporting errors.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763 Forward-Port-Of: odoo/enterprise#92714
This update fixes issues in Colombia DIAN electronic invoicing where new vendor bills did not show the correct commercial status and repeated event submissions could block the workflow. It also corrects issuer acceptance events so they are accepted properly by DIAN, helping accounting teams process supplier documents more reliably.
Original PR description
this commit solves following issues: - the commercial status was missing on newly created vendor bills - the flow got stuck when an event had already been sent and we tried to send it again - The accept by issuer event generated errors on DIAN's side task: 5064534
Merging timesheet entries from the same helpdesk ticket now keeps them connected to that ticket. This prevents lost ticket history and blocks merges when selected timesheets belong to different helpdesk tickets.
Original PR description
…helpdesk ticket **Steps to reproduce** - Register 2 timesheet lines on 1 helpdesk ticket - Go to the timesheets app and select these 2 lines - Go to Actions -> Merge timesheets Issue: the timesheets are merged but unlinked from the helpdesk ticket. **Change** Preserve the link to the helpdesk ticket when merging timesheets. An error is raised if attempting to merge timesheets not having all the same `helpdesk_ticket_id` value. opw-5086090 Forward-Port-Of: odoo/enterprise#94780
The Mexican electronic invoicing flow now handles customer names entered with accents when comparing them to official legal names that omit accents. This helps prevent failed invoice validation for self-invoicing customers after point-of-sale purchases.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95280 Forward-Port-Of: odoo/enterprise#95207
Product images on website sales pages now keep their original quality instead of being compressed to a lower setting. This improves the visual presentation of products, especially where image detail matters for customer confidence and purchasing decisions.
Original PR description
Product image quality was set to 75% not good enough in some cases. So it increased to 100% to keep the original quality of the image. opw-5094063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Accounting reports page no longer crashes when users load more lines in a Follow-Up Report with many invoices. This improves reliability for customers reviewing large partner statements or follow-up details.
Original PR description
**Steps to reproduce:** 1. Install the Accounting module. 2. For partner X, create minimum 90 invoices for `See more/Load more` option into page. 3. In the partner form view, click the Customer…
**Steps to reproduce:**
1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.
**NOTE**
- You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
invoice = env['account.move'].create({
'move_type': 'out_invoice',
'partner_id': 10,
'company_id': env.company.id,
'invoice_line_ids': [(0, 0, {
'product_id': 16,
'quantity': 1,
'price_unit': 100.0,
})],
})
invoice.action_post()
```
**Issue:**
`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.
**Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73
- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />
- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />
**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.
**opw - 5083894**
Forward-Port-Of: odoo/enterprise#95103This update refreshes Odoo’s spreadsheet component and fixes several small user-facing issues. Users should see more reliable spreadsheet sorting and cleaner chart and carousel visuals, improving day-to-day reporting and dashboard presentation.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c84edcb45 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192) https://github.com/odoo/o-spreadsheet/commit/0e823e20a [FIX] Carousel: the sidepanel cogwheel has a weird look [Task: 5090177](https://www.odoo.com/odoo/2328/tasks/5090177) https://github.com/odoo/o-spreadsheet/commit/b2aec82f2 [FIX] charts: truncate radar chart labels correctly [Task: 5078858](https://www.odoo.com/odoo/2328/tasks/5078858) https://github.com/odoo/o-spreadsheet/commit/b1f21db41 [FIX] carousel: missing color for empty carousel header [Task: 5082459](https://www.odoo.com/odoo/2328/tasks/5082459) https://github.com/odoo/o-spreadsheet/commit/13482eefd [IMP] test: improve `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update prevents crashes for public website visitors using older Safari versions by adding missing browser support needed for translation caching. Visitors on Safari before version 17 should now be able to load pages normally instead of encountering failures at launch.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). 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#228120
Odoo now handles printer setup errors more gracefully when the system cannot add a printer, such as on read-only devices or when a printer name is invalid. Instead of stopping the printer interface, the error is logged and printing services can continue running.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227307 Forward-Port-Of: odoo/odoo#227121
Fixes an issue that could block sending certain Colombian customer invoices when a debit-note-related operation type was selected without a linked reference invoice. This prevents an error during the send process and helps users complete DIAN invoice delivery smoothly.
Original PR description
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** -…
Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail. **Steps to Reproduce:** - Install Accounting and l10n_co_dian modules. - Switch company to "CO Company". - Create new customer invoice. (e.g; Operation Type (CO) = Nota Débito que referencia una factura electrónica) - Click on "Send" button. Ensure DIAN is selected in template and then send it. - Error occurs. **Error:** AttributeError - 'bool' object has no attribute 'isoformat' **Cause:** The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1] In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None. **Fix:** This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None. [1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730 [2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496 sentry-6810908763 Forward-Port-Of: odoo/enterprise#92714
Italian XML invoices marked as TD01 are now kept as the correct document type when imported as vendor bills. This prevents purchase invoices from being mislabeled as TD05, improving compliance accuracy and reducing manual corrections.
Original PR description
**Issue** When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing. **Steps to Reproduce** 1. Install Accounting, l10n_it and l10n_it_edi 2. Go to…
**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.
**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05
**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891
**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.
opw-4931438
Forward-Port-Of: odoo/odoo#219310Odoo now accepts Taiwan VAT numbers under the latest official validation rules. This prevents valid new Taiwanese business identifiers from being incorrectly rejected as number ranges expand.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225468
Subscriptions linked to archived companies are now skipped by the automatic recurring invoice process. This prevents hidden or unexpected invoices from being created for companies that users have intentionally archived, reducing cleanup work and billing confusion.
Original PR description
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is…
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is archived, the cron still periodically invoices them as usual but the user is not able to see it because they don't show up in the views. To avoid having to unarchive the comany and check every subscription one by one, this PR aims at making the cron ignore any subscription tied to an archived company, as intended. The only modified cron is the one that creates invoices since the other one of interest (the one that sends reminders) operates only on invoiced orders, which we avoid having with this change. Also added a test to ensure that if the company related to a subscription sale order is archived, the cron won't invoice it. ## Steps to reproduce: - Create a company A - Create a subscription belonging to company A with a next invoice date <= today - Archive the company - Run the scheduled action “Sale Subscription: generate recurring invoices and payments” The deferred information in the Settings must be correct - Unarchive the company and check the subscription. It has been invoiced. You may need to add back the Company A from the Allowed Companies of the user backport-of: a93e7ec opw-4904325
This fixes a regression that prevented portal users from creating project tasks by sending an email to a project alias. It restores an expected collaboration workflow, so external users can continue submitting tasks without manual intervention.
Original PR description
The new safety belt introduced in 745f3accaf775550294d6f1bf562a0dcc15f7a08 made it impossible for portal users to create tasks by sending emails to the project alias. @moduon MT-11332 Forward-Port-Of: odoo/odoo#225321