Friday, March 21, 2025
5 changes · 17.0
Resolved issues and error corrections
Spreadsheet line charts with time-based axes now refresh their cumulative data immediately when the option is enabled. This prevents users from seeing incomplete chart totals until they manually reload, improving accuracy during analysis.
Original PR description
Steps to reproduce: - insert a line chart into a spreadsheet with the horizontal axis being a time axis - ensures a domain is applied such that at least some past data is excluded - open the configuration side panel - check the "Cumulative data" checkbox => the chart doesn't take into account past data. When reloading it works. opw-4646477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia. Steps to reproduce: - Install l10n_es_edi_tbai and l10n_eu_oss - Set the Tax Agency to Bizkaia - Create a simplified invoice - Set fiscal position to OSS B2C - Poland - Use a Polish partner - Add a product - Validate the invoice - Attempt to send to Bizkaia The error raised is: `B4_
Original PR description
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia. Steps to…
An error occurs when a simplified invoice contains an OSS with a non-Spanish partner, and the Bizkaia tax agency is selected. This causes the B4_2000027 error to be returned by Bizkaia.
Steps to reproduce:
- Install l10n_es_edi_tbai and l10n_eu_oss
- Set the Tax Agency to Bizkaia
- Create a simplified invoice
- Set fiscal position to OSS B2C - Poland
- Use a Polish partner
- Add a product
- Validate the invoice
- Attempt to send to Bizkaia
The error raised is:
`B4_1000002: Todos los registros incluidos en la petición son incorrectos.
B4_2000027: La factura contiene un Tipo de desglose incorrecto. Ha de ser a nivel de operación cuando la factura es completa y, además, existe destinatario extranjero (tipo IDOtro o que sea NIF que empiece por N) o la Clave de IVA es 02.`
After investigation, it appears this issue occurs only with Bizkaia. This fix ensures that `DesgloseFactura` is used instead of `DesgloseTipoOperacion` for this specific case.
Reference:
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII_Descripcion_ServicioWeb_v1.1_en_gb.pdf?utm_source=chatgpt.com
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4464223)
opw-4464223
Forward-Port-Of: odoo/odoo#200391**Steps to reproduce:** - Install Accounting and l10n_ke_edi_tremol - Switch to a Kenyan company (e.g. KE Company) - Configure USD currency: * Rounding Factor: 0.000100 * Decimal Places: 4 * Rate: 0.007729205731 Unit per KES 129.379400000000 KES per Unit - Create a product with decimal in the price (e.g. 1234.56) - Create an invoice: * Customer: [a Kenyan customer] * Currency: USD * Product: [the created product] * Taxes: 16% - Confirm the invoice - Send the invoice t
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ke_edi_tremol - Switch to a Kenyan company (e.g. KE Company) - Configure USD currency: * Rounding Factor: 0.000100 * Decimal Places: 4 * Rate:…
**Steps to reproduce:**
- Install Accounting and l10n_ke_edi_tremol
- Switch to a Kenyan company (e.g. KE Company)
- Configure USD currency:
* Rounding Factor: 0.000100
* Decimal Places: 4
* Rate: 0.007729205731 Unit per KES 129.379400000000 KES per Unit
- Create a product with decimal in the price (e.g. 1234.56)
- Create an invoice:
* Customer: [a Kenyan customer]
* Currency: USD
* Product: [the created product]
* Taxes: 16%
- Confirm the invoice
- Send the invoice to fiscal device (It will not be possible without some credentials. However, if a breakpoint is set at the last line ("return" line) of "_l10n_ke_cu_lines_messages" method, the total amount in KSh sent to the fiscal device can be checked.)
**Issue:**
The total amount in KSh sent to the fiscal device is different than the total amount in USD converted to KSh with the used currency rate.
**Cause:**
In the "_l10n_ke_cu_lines_messages" method (the method used to compute the amounts sent to the fiscal device), a rounding is done by forcing the number of decimal to 2 without taking into account the configuration of the currency when computing the price.
opw-4567098
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202706**Steps to reproduce:** - Install Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Duplicate "Customer Invoices" journal: * Default Income Account: 500001 Sales Account * Electronic invoicing: [disabled] - Create a retention tax: * Name: Retention 10% * Amount: -10.00000% * Is Retention: [checked] - Create an invoice: * Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch) * Journal: Customer Invoices * Invoice Lines:
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Duplicate "Customer Invoices" journal: * Default Income Account: 500001 Sales…
**Steps to reproduce:**
- Install Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Duplicate "Customer Invoices" journal:
* Default Income Account: 500001 Sales Account
* Electronic invoicing: [disabled]
- Create a retention tax:
* Name: Retention 10%
* Amount: -10.00000%
* Is Retention: [checked]
- Create an invoice:
* Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch)
* Journal: Customer Invoices
* Invoice Lines:
- Price: 100.00
- Taxes: "Sales Tax 15%" + "Retention 10%"
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice with an app like "E-invoice QR Reader"
=> In the QR code, the total amount of the invoice with VAT included is 115.00 and the total amount of the VAT is 15.00.
The amount of the retention tax is excluded from the total and the VAT amounts, which is the expected behavior.
- Create the exact same invoice with the duplicated journal without electronic invoicing
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice
**Issue:**
In the QR code, the amount of the retention (-10.00) is taken into account.
The total amount of the invoice with VAT included is 105.00 and the total amount of the VAT is 5.00.
The QR code should provide the same amounts either the used journal has "Electronic invoicing" enabled or not.
**Cause:**
Depending on the presence of an electronic invoice document or not, the QR code is generated by the overriding compute method from "l10_sa_edi" or the original one in "l10n_sa".
However, the "Is Retention" field of the "account.tax" model is introduced by "l10n_sa_edi" module and when the QR code is computed by the original method, this field is not taken into account and the corresponding retention tax is wrongly handled like any other tax.
**Solution:**
Use the same total amounts than the ones computed in "l10n_sa_edi" (where retention tax are excluded) in the original compute method if "l10n_sa_edi" is installed.
opw-4525519
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196640Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - P
Original PR description
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 20 (correct). OPW: 4599614 Forward-Port-Of: odoo/enterprise#80214