Sunday, June 2, 2024
10 changes · saas-17.1
Resolved issues and error corrections
Invoice or accounting lines in the Indian localization now refresh their HSN code when the related product's HSN code is added or changed later. This helps keep tax and compliance data accurate without manual correction.
Original PR description
Before this commit: creating a move line with a product without hsn code and later adding the hsn code on the product. The hsn code on the move line doesn't get updated After this commit: We solve the above issue and add dependency of `product_id.l10n_in_hsn_code` on the compute method task-3958797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
ZATCA updated the VAT exemption reason codes to be provided for 0% taxes. This commit aims to expand the list of existing tax exemption reason codes in odoo to include the new reason: VATEX-SA-OOS Description of the issue/feature this PR addresses: Currently the VAT exemption reasons defined in the l10n_sa_edi module do not include all the reasons listed by ZATCA Current behavior before PR: Current VAT exemption reasons do not include reason VATEX-SA-OOS, i.e: "Not subject to VAT" De
Original PR description
ZATCA updated the VAT exemption reason codes to be provided for 0% taxes. This commit aims to expand the list of existing tax exemption reason codes in odoo to include the new reason: VATEX-SA-OOS Description of the issue/feature this PR addresses: Currently the VAT exemption reasons defined in the l10n_sa_edi module do not include all the reasons listed by ZATCA Current behavior before PR: Current VAT exemption reasons do not include reason VATEX-SA-OOS, i.e: "Not subject to VAT" Desired behavior after PR is merged: Add VAT exemption reason VATEX-SA-OOS --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166104
To reproduce: ============= - Install sale_loyalty_delivery - create a loyalty card where customer gets free delivery for 10 points and gets 1 point per 1$ spent - create a sale order with more than 10$ and apply the loyalty card - free delivery line is added - change the price to be less than 10$ -> free delivery line is not removed Problem: ======== we have a logic that prevents deleting the free delivery line, it's not explained why we have this logic, and there is no test for i
Original PR description
To reproduce: ============= - Install sale_loyalty_delivery - create a loyalty card where customer gets free delivery for 10 points and gets 1 point per 1$ spent - create a sale order with more than 10$ and apply the loyalty card - free delivery line is added - change the price to be less than 10$ -> free delivery line is not removed Problem: ======== we have a logic that prevents deleting the free delivery line, it's not explained why we have this logic, and there is no test for it. on the other hand, the use-case on the support ticket is valid, so we should remove this logic. opw-3879945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166484
Before this commit: The label for Transporter Doc Number and Date was visible but the field was seemed to be hidden After this commit: We fix the above issue, now the field is visible when the mode is selected to `By Road` task-3959862 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#167
Original PR description
Before this commit: The label for Transporter Doc Number and Date was visible but the field was seemed to be hidden After this commit: We fix the above issue, now the field is visible when the mode is selected to `By Road` task-3959862 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#167339
The issue: When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not match the xml_id produced by the _load_translations function. The new COAs' xml_id is a composite of the module ('l10n_fr_fec_import' in this case), company ID, prefix ('account' in this case), and a key derived from the account number code in the CSV file (not Odoo's default code). Consequently, when
Original PR description
The issue: When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not…
The issue:
When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not match the xml_id produced by the _load_translations function. The new COAs' xml_id is a composite of the module ('l10n_fr_fec_import' in this case), company ID, prefix ('account' in this case), and a key derived from the account number code in the CSV file (not Odoo's default code). Consequently, when calling the _load_translations function, it attempts to update translations using a different xml_id, causing failure in locating records.
The fix:
Include the template_data, if available, during COA translation, as it is more efficient than loading and parsing the entire CSV file. This template data already contains the necessary information, including the correct xml_id. Additionally, introduce a key 'is_xml_generated' in the context to prevent the generation of an incorrect xml_id.
Enterprise PR: https://github.com/odoo/enterprise/pull/55537
opw-3646861
Forward-Port-Of: odoo/odoo#152090This commit implements a new (bridge) module that adds the spanish TBai QR code on the Point of Sale checkout order receipt. Problem: Right now, with the l10n_es_pos, it works when the EDI is SII as it creates the invoice automatically and sends it in the background. In the case of simplified invoices, we even skipped the downloading of the PDF because that takes time. But there, you do not need any response from the government to show to your client. With TicketBai however, this is differe
Original PR description
This commit implements a new (bridge) module that adds the spanish TBai QR code on the Point of Sale checkout order receipt. Problem: Right now, with the l10n_es_pos, it works when the EDI is SII as it creates the invoice automatically and sends it in the background. In the case of simplified invoices, we even skipped the downloading of the PDF because that takes time. But there, you do not need any response from the government to show to your client. With TicketBai however, this is different, as we need the QR code on the ticket. Solution: when processing the data in the PoS payment, we look for the move created and asks for the qr url right away. If it doesn't have them (because the sending is not done yet), we synchronously call the post method and get the url. This URL is then transfered to the javascript code and eventually the XML of the receipt, where the QR code is shown. task-id: 3916236 Forward-Port-Of: odoo/odoo#166019
Steps to reproduce: - Open planning - Create a recurrence task for a user - Click on the slot and select the recurrence option and click on delete Issue: - You can see that no matter what the option is selected in form it is not reflected in delete dialog confirmation. So in this commit the recurrence option is synced in deleted conformation dialog task:3850839 Forward-Port-Of: odoo/enterprise#60601
Original PR description
Steps to reproduce: - Open planning - Create a recurrence task for a user - Click on the slot and select the recurrence option and click on delete Issue: - You can see that no matter what the option is selected in form it is not reflected in delete dialog confirmation. So in this commit the recurrence option is synced in deleted conformation dialog task:3850839 Forward-Port-Of: odoo/enterprise#60601
When a purchase order was matched and imported by the OCR, it wasn't working properly, the data imported was overwritten with the detected fields of the OCR. This happened because, in the implementation before this commit, a flag `force_write` was used to indicate that the data should be overwritten, but this implied that the data imported from the PO was also overwritten. In this new implementation, the content of the invoice is first reset and then the logic to fill in the invoice with t
Original PR description
When a purchase order was matched and imported by the OCR, it wasn't working properly, the data imported was overwritten with the detected fields of the OCR. This happened because, in the implementation before this commit, a flag `force_write` was used to indicate that the data should be overwritten, but this implied that the data imported from the PO was also overwritten. In this new implementation, the content of the invoice is first reset and then the logic to fill in the invoice with the OCR data and/or purchase order is applied. Task: [#3834665](https://www.odoo.com/odoo/project.task/3834665?cids=1) Forward-Port-Of: odoo/enterprise#63510 Forward-Port-Of: odoo/enterprise#63290
**Steps to reproduce:** - Install Timesheet module - Check the grid view and make sure you have odd number of rows - Scroll horizontally and see the row of the column total **Current behavior before PR:** The values of the column total still visible when scrolling horizontally while it should be hidden. This is happening because in this commit https://github.com/odoo/enterprise/pull/48406/commits/ec733d78385dee23ca2e338f49c089030b83f4c4 the bg-100 has been removed so when the row of
Original PR description
**Steps to reproduce:** - Install Timesheet module - Check the grid view and make sure you have odd number of rows - Scroll horizontally and see the row of the column total **Current behavior before PR:** The values of the column total still visible when scrolling horizontally while it should be hidden. This is happening because in this commit https://github.com/odoo/enterprise/pull/48406/commits/ec733d78385dee23ca2e338f49c089030b83f4c4 the bg-100 has been removed so when the row of the column total is not in even position its cell in the first column won't have a bg in its class so when values get behind this cell it will still be visible and will overlay. **Desired behavior after PR is merged:** We added the bg-100 once again so when the row is not in even position it will still hide the values when scrolling horizontally opw-3943960 Forward-Port-Of: odoo/enterprise#63446
The issue: When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not match the xml_id produced by the _load_translations function. The new COAs' xml_id is a composite of the module ('l10n_fr_fec_import' in this case), company ID, prefix ('account' in this case), and a key derived from the account number code in the CSV file (not Odoo's default code). Consequently, when
Original PR description
The issue: When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not…
The issue:
When importing a FEC file, the created COAs lack correct translation for languages other than English. This discrepancy arises because the xml_id generated during COA creation does not match the xml_id produced by the _load_translations function. The new COAs' xml_id is a composite of the module ('l10n_fr_fec_import' in this case), company ID, prefix ('account' in this case), and a key derived from the account number code in the CSV file (not Odoo's default code). Consequently, when calling the _load_translations function, it attempts to update translations using a different xml_id, causing failure in locating records.
The fix:
Include the template_data, if available, during COA translation, as it is more efficient than loading and parsing the entire CSV file. This template data already contains the necessary information, including the correct xml_id. Additionally, introduce a key 'is_xml_generated' in the context to prevent the generation of an incorrect xml_id.
Community PR: https://github.com/odoo/odoo/pull/152090
opw-3646861
Forward-Port-Of: odoo/enterprise#55537