Daily updates from Odoo
Wednesday, June 26, 2024
11 changes · 17.0
Resolved issues and error corrections
This fix corrects a syntax error in the ForecastedDetails template declaration within the subscription stock module. The template name attribute was incorrectly formatted, preventing customers from customizing the forecasted details report. The fix allows the template to be properly recognized and extended by other modules.
Original PR description
ForecastedDetails template inheritance wrong declaration of name (sale_subscription_stock) Steps to Reproduce customer want to add an additional column to the ForecastedDetails template. customer able to do it to basic template But not for prepared inheritances in sale_subscription_stock. The problem is that system can’t resolve symbol e.g t-inherit="sale_subscription_stock.ForecastedDetails” because somebody declatest in code ```py <t name="sale_subscription_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> instead <t t-name="sale_subscription_stock.ForecastedDetails" t-inherit="stock.ForecastedDetails" t-inherit-mode="extension"> ``` here is a issue link :- https://github.com/odoo/odoo/issues/167741
Fixed a bug in Belgian payroll tax reporting that prevented users from properly declaring 281.50 forms for Curaçao. The system now correctly maps Curaçao to the appropriate ONSS country code, allowing complete and accurate tax reporting for this jurisdiction.
Original PR description
The aim of this commit is to allow to declare a 281.50 for curaçao. context: issue spotted by odoo.com prod db Before the commit: `f2018_landwoonplaats` xml tag is empty After the commit: `f2018_landwoonplaats` xml tag is filled with the onss country code of netherlands. task-id: None Forward-Port-Of: odoo/enterprise#65503 Forward-Port-Of: odoo/enterprise#65466
This fix resolves issues where down payment invoices were not calculating taxes correctly when using AvaTax. Previously, down payments had no taxes applied, and when taxes were computed, they were based on the down payment product rather than the original sales order product, leading to incorrect tax amounts. The fix ensures down payments inherit the correct tax information from the original order and are excluded from automatic tax recalculation.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales and account_avatax_sale - Configure AvaTax in Accounting settings - Create a product with an AvaTax Category (e.g. [D00000000] Digital goods) -…
**Steps to reproduce:** - Install Accounting, Sales and account_avatax_sale - Configure AvaTax in Accounting settings - Create a product with an AvaTax Category (e.g. [D00000000] Digital goods) - Create a SO: * Customer: [US customer] (e.g. Azure Interior) * Product: [the created product] * Unit Price: [any] (e.g. $ 200.00) * Fiscal Position (Other Info tab): Automatic Tax Mapping (AvaTax) - Confirm the SO => The taxes will be recomputed with AvaTax (e.g. $ 20.50) - Create a down payment from SO (via "Create Invoice" button): * Create Invoice: Down payment (percentage) * Down Payment Amount: 50% **Issues:** 1) There is no tax on the down payment 2) When confirming the down payment, AvaTax taxes are computed from the Down payment product. It should not because the Down payment product may have a different AvaTax category than the product on the SO, which may lead to different computed taxes. The taxes on the down payment should be the same than the ones on the SO. **Cause:** 1) In "sale_external_tax" module, the "tax_ids" field is removed when preparing the invoice line (in "_prepare_invoice_line" method). Even though "account_avatax_sale" module depends on "sale_external_tax", we want to keep "tax_ids" when using AvaTax. **Solution:** 1) Create a method checking if taxes should be removed in "sale_external_tax" and override it in "account_avatax_sale" module to keep them. 2) Exclude down payments from external taxes recomputation. opw-3971513
This fix ensures that the "Consumidor Final Anónimo" (Anonymous Final Consumer) partner is always available in the Point of Sale system for Chile. Previously, this essential partner could be missing due to limitations in how partners were loaded, which could prevent POS transactions from completing properly. This update guarantees the partner is loaded regardless of system constraints.
Original PR description
Before this commit, the "Consumidor Final Anónimo" partner could be missing due to the limited partner loading mechanism. This commit ensures that the "Consumidor Final Anónimo" partner is always loaded, regardless of the partner loading limitations. opw-3988187
When subscription payments are processed, invoices are automatically created and sent. This fix adds a way to distinguish between invoices created automatically by the system versus those created manually by users. This matters because different business processes (like EDI document generation) may need to handle these invoices differently depending on how they were created.
Original PR description
**Issue:** When a transaction is done for a subscription, we force the creation and sending of an invoice. However, depending on the localization of the company, many additional processes can be performed when generating/sending an invoice, like the generation/sending of an EDI document. In these cases, we may want to distinguish these forced creations from the manual ones as the treament of the invoice could differ depending on the case. opw-3936227 Linked community PR: https://github.com/odoo/odoo/pull/170144
This fix resolves an issue where exporting Belgian tax reports to XML would include empty or invalid comment tags, which violates Belgian tax authority requirements. The system now properly handles empty comments by either omitting them or using a valid placeholder, ensuring exported tax reports comply with Belgian regulations.
Original PR description
When exporting tax report to xml, a comment tag is added in the xml even when empty or set to False. Per https://finances.belgium.be/fr/E-services/Intervat/comment-utiliser-intervat/deposer-declaration-periodique#q5 tags cannot be empty Steps to reproduce: 1.In a belgian company > accounting > Reporting > Tax Report 2.Export in xml 3.Do not fill information in the pop up > Export XML 4.Notice how the <comment> tag is present yet empty cause: comment is being added to the xml formatting even when empty Solution: add comment when not empty opw-3980954
Fixed an issue where document previews were not updating correctly after replacing a document with another one. The system was showing the old document's image instead of the new one. This fix ensures that when you replace and preview a document, you see the correct updated content.
Original PR description
Steps to reproduce: 1. Preview a document. 2. Replace it with another document. 3. Preview the document again. 4. Notice the document preview is not updated. After replacing a document and previewing it, it will show the previous images. Technical Reason: while computing 'URL', we were not passing the 'checksum' to uniquely identify each doc. After this commit: Able to preview correct documents while replacing. Task-3484390 Forward-Port-Of: odoo/enterprise#65021 Forward-Port-Of: odoo/enterprise#51926
Fixed an issue where quality control checks on product quantities were not being transferred to backorder shipments. When a partial receipt was validated and a backorder was created, the quality checks that should have been applied to the backorder were being lost. This fix ensures quality control checks are properly moved to backorders before the original shipment is finalized.
Original PR description
Steps to reproduce: - Create a QC with measure on quantity (move_lines) - Create a reciept and set move_line quantity to 0 - Validate and create a backorder - No QC on the backorder Bug: when create the backorder the sml is created first on the original picking and then it's picking_id is updated measure on quantity QCs are created at this time the QCs that are on the move_line should first be moved to the backorder before deleting the pending QCs on the original picking opw-3996782
This fix prevents custom product descriptions from being automatically overwritten when rental dates are changed in sales orders. Previously, when the Rental app was installed, changing rental start or end dates would reset all order line descriptions—even for non-rental products. Now, descriptions are only recalculated for actual rental items, preserving custom descriptions for regular products.
Original PR description
Issue ---- When a rental field like (e.g. `rental_start_date`) is changed in a sales order, its lines' description is recomputed. This makes sense for rental order lines as the description depends on these fields, but it messes with non-rental orders and non-rental order lines in rental orders when the Rental app is installed, so all descriptions get overwritten. Steps ----- - Install the rental app. - Create a new Quotation Template with whose line has a description that is different from the product name. - Create a new Quotation from the template. - The description gets overwritten. You can also reproduce this with creating a new rental order, then adding non-rental products with custom description. If you change the start date / end date the custom descriptions get overwritten. opw-3987175
This fix corrects an issue where currency exchange rates (TipoCambio) in Mexican electronic invoices were showing inconsistent decimal values depending on the product being invoiced. The fix ensures that all line items on an invoice use the same, exact exchange rate value, improving accuracy and compliance with Mexican tax requirements.
Original PR description
Impacted versions: - 17.0 Steps to reproduce: 1. Install l10n_mx_edi module. 2. Go to Company ESCUELA KEMPER URGATE. 3. Go to Settings / Automatic Currency Rates. 4. Run manually the currency rates.…
Impacted versions:
- 17.0
Steps to reproduce:
1. Install l10n_mx_edi module.
2. Go to Company ESCUELA KEMPER URGATE.
3. Go to Settings / Automatic Currency Rates.
4. Run manually the currency rates.
5. Go to Accounting / Customers / Invoices.
6. Create a new invoice with the next values:
- Customer: "INMOBILIARIA CVA"
- Currency: USD - Product: Any but set the UNSPSC Category (any)
7. Confirm the invoice.
8. Click send and print.
9. Check CFDI and click on Click send and print.
10. Open the generated xml
Current behavior:
- TipoCambio have many variations depending of product and currency value:
Example: June 17th: have:
| Product | Quantity | TipoCambio |
|---------------------------|----------|------------|
| [FURN_0006] Monitor Stand | 1 | 18.538484 |
| [FURN_0004] Letter Tray | 1 | 18.538558 |
| [E-COM09] Large Desk | 1 | 18.538498 |
Expected behavior:
- TipoCambio (inside XML) should have the exchange value of the currency (invoiced). Example: June 17th should have 18.5385 (USD)
Inspired in: [l10n_mx_extended](https://github.com/odoo/enterprise/blame/f030d17e07ae7b10fe95e054eb27ba35101cfc96/l10n_mx_edi_extended/models/account_move.py#L178)The organizational number format used in Swedish POS Blackbox serial communication was incorrect, preventing the device from communicating with the system. The format has been corrected from the display format (123456-4321) to the required serial communication format (1234564321) to restore proper Blackbox functionality.
Original PR description
The format for organisational number is wrong in the serial communication. This creates an error from the Blackbox. The format of an organistional number is "123456-4321" where the last number is a checksum. However, the format for the serial communication is a string of numbers in this format: "1234564321". This will stop the black box from communicating the the POS.