Daily updates from Odoo
Friday, November 15, 2024
10 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where nested lines within account reports were not fully unfolding, preventing users from seeing all related financial data. The fix ensures that all child lines are correctly expanded, providing a more complete and accurate view of financial reports. This improves data visibility and reporting accuracy.
This update ensures that images taken during quality checks linked to Manufacturing Orders (MOs) or Work Orders (WOs) are now correctly displayed within the quality check wizard. Previously, picture-type quality checks didn't show the associated image, which is now resolved to improve the visual clarity of quality control processes.
Original PR description
When opening a validated quality check from a MO/WO, if the type of the quality check is 'picture', the QC wizard should show the image taken.
This update fixes a problem preventing the system from correctly processing CFDI XML invoices containing the `InformacionGlobal` element. The fix ensures proper encoding of special characters like 'ñ' during XML processing, resolving parsing errors and allowing invoices to be imported successfully. This improves invoice processing reliability for Mexican VAT compliance.
Original PR description
When uploading a CFDI XML invoice containing the `InformacionGlobal` element, the system fails to parse the document correctly and displays an error message. ### Steps to Reproduce 1. Install the…
When uploading a CFDI XML invoice containing the `InformacionGlobal` element, the system fails to parse the document correctly and displays an error message. ### Steps to Reproduce 1. Install the `l10n_mx_edi` module. 2. Create a blank invoice. 3. Add a CFDI XML file containing an `InformacionGlobal` as an attachment to the invoice. (You can use the file `enterprise/l10n_mx_edi/tests/test_files/test_global_invoice_year_month_format.xml` for testing.) The chatter displays the following error: Error importing attachment 'xml_file_name.xml' as invoice (decoder=_l10n_mx_edi_import_cfdi_invoice) ### Cause The `InformacionGlobal` element in the XML requires an `Año` attribute (note the special character `ñ`). Correct encoding is crucial here to handle special characters accurately. When the XML file is first uploaded, it is parsed with the correct encoding. However, during processing, the XML is converted back to a string, losing its original encoding in the process. This causes issues with special characters like `ñ`, which can no longer be read correctly by the system, resulting in a parsing error. opw-4226968
This update fixes an issue where rental dates on ecommerce carts weren't automatically updating when the rental period was changed. The fix ensures that the order line name, which determines the rental period, is recalculated whenever the rental dates are modified, resulting in accurate rental durations displayed in the cart.
Original PR description
Steps:
add a rental product in cart in ecommerce
go to cart and update the rental dates on datepicker
Issue:
The new dates are not applied to cart lines
Cause:
rental dates on cart line come from order_line name
order_line name is not updated on change of rental dates
Fix:
Updated _cart_update_renting_period to update order_line name for rental lines
opw-4137981
opw-4124061
opw-4191403This update corrects a discrepancy in how medical assistance work entries are handled within the payroll system. Previously, they didn't align with standard credit-time entries, leading to potential reporting inconsistencies. This fix ensures medical assistance entries now use the same DMFA code, improving accuracy and compliance.
Original PR description
The medical assistance work entry should be behaving like the credit-time and should have the same DMFA code. Task: 4247631 Forward-Port-Of: odoo/enterprise#71872
This update ensures that simple POS users can accurately view the total due amount for customers, regardless of whether the customer was initially loaded. Previously, this information was missing when searching for new customers, creating a discrepancy in reporting and settlement. This fix aligns the POS user experience with the functionality available to other users.
Original PR description
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: -------------------…
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount due for multiple customers * Search for the customer created * Select search more > You can't see the amount due for that customer Why the fix: ------------ Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load. Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4 When loading the pos session `_loader_params_res_partner` is called first and later is called `_get_pos_ui_res_partner`. It is in the function `_get_pos_ui_res_partner` that the amount due is compted if the user does not belong to the group `account.group_account_readonly`. https://github.com/odoo/enterprise/blob/a35a4755cdf86bcfeda0aca6c06397748ba27362/pos_settle_due/models/pos_session.py#L22-L28 However when we load a customer that wasn't previously loaded, only `_loader_params_res_partner` is loaded. And since the users does not belong to the group `account.group_account_readonly`, the field witll not get loaded. We now compute the amount due with the same logic as in `_get_pos_ui_res_partner`. opw-4141955
This update resolves a bug preventing the validation of Factura B invoices for 'Consumidor Final' customers in Argentina when the invoice amount exceeds $344487. The fix ensures proper reporting to AFIP, allowing validation of invoices with this customer type and DNI identification, addressing a critical issue for Argentinean sales operations.
Original PR description
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification…
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice. The bug was introduced on this pr: https://github.com/odoo/enterprise/pull/71562 --> The goal of this pr was to be able to create Factura B for a foreign customer. But prior to this pr the user was allowed to validate an invoice Factura B to a customer "Consumidor Final" without a country set on that customer, with "DNI" identification type, with a vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487 **Video explaining the bug**: https://drive.google.com/file/d/1Qb2oUtT26twjCI-pB6oMGMC9gZ6_EBSz/view **Steps to reproduce**: 1) Log ing with admin user on runbot odoo enterprise 16 or 17 instance, activate developer mode and install l10n_ar_edi module. 2) Take position on company "Responsable Inscripto". 3) Create an electronic invoice "Factura B" for customer "Consumidor Final Anónimo" with an invoice line with quantity 1 and price 500000. Select electronic journal. The Partner doesn`t have country and has "dni" identification type, dni and "Consumidor final" afip responsibility type.   4) Validate the invoice and then you will receive this message:  **Current behavior before PR**: It is not allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. **Desired behavior after PR is merged**: It is allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. Ticket Adhoc side: 82498 Task latam side: 1283 Forward-Port-Of: odoo/enterprise#73200
This update ensures that only the necessary Electronic Data Interchange (EDI) fields related to Mexican tax regulations are displayed for Odoo companies with a Mexican fiscal country. This improves data accuracy and reduces clutter for users working with Mexican businesses, streamlining reporting and compliance.
Original PR description
We only need to shown MX EDI fields for move/invoices related to a company where fiscal country is Mexico, hide it for other companies. Forward-Port-Of: odoo/enterprise#73623
A technical issue causing a traceback when managing addresses on the Odoo website for Colombian businesses has been resolved. The fix ensures consistent data access, preventing errors related to how address information is handled, improving the user experience for our Colombian customers.
Original PR description
Steps to Reproduce: - Set up a website for a Colombian company. - Go to the shop section. - Purchase any product. Issue: - Traceback occurs when opening the address form for an existing or new address. Cause: - The error occurs because the form data for state_id, city_id, and other field is not consistently accessible, depending on whether values is a object or a dictionary. Fix: - Added checks to ensure fields like state_id and city_id are accessed only if they exist within values. opw-4314031
This update resolves an issue where Mexican tax reports generated from the Chart of Accounts failed validation due to incorrect account group codes. The fix filters out invalid codes from root account groups, ensuring reports comply with SAT requirements. While not a perfect solution, it addresses the primary cause of the validation failure.
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account:…
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account: * Account Name: [any] * Code: 123456789 * Type: Bank and Cash - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx) **Issue:** The validation fails because the XML contains lines with incorrect or missing value for "CodAgrup" attribute. **Cause:** The "CodAgrup" in the "COA SAT (XML)" refers to the code of the account groups. The accepted values are defined in the "Catálogo de Códigos Agrupadores" XSD file. https://github.com/odoo/enterprise/blob/ecce698637dc2ef13dfdb27dfde303a7f1191aaf/l10n_mx_xml_polizas/data/xsd/1.3/CatalogosParaEsqContE.xsd#L4-L1086 The created account [123456789] is put in the root account group with code "1" and a line is added in the "COA SAT (XML)" with this value. However, it is not an accepted value. **Solution:** From the account groups created automatically by MX localization, only the root account groups (i.e. with code "1", "2", "3",...) do not have a valid code for the "COA SAT (XML)". These ones can be ignored. This solution is not perfect as it is still possible to create an account group with an invalid code that is not a root account group. However, handling this use case would require to check that each code is included in the set of valid codes (there is more than a thousand). opw-4209089 Forward-Port-Of: odoo/enterprise#73647