Thursday, November 7, 2024
9 changes · 17.0
Resolved issues and error corrections
This update ensures Odoo supports the new Brazilian tax regulations requiring a barcode on each line item. This change is being implemented for Odoo 17 and later versions, focusing on EDI processing. It's based on Avalara documentation to ensure accurate tax calculations for Brazilian transactions.
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168This update corrects a bug in the Spanish tax reporting module (l10n_es_reports) that prevented the 'Type for mod 347' field from automatically setting to the correct default value ('Regular operation'). This ensures invoices comply with Spanish tax regulations, resolving a potential reporting issue for Spanish customers.
Original PR description
**Steps to reproduce:** - Install l10n_es_reports and Sales - Create a SO for a Spanish customer - Create an invoice from the SO - Check "AEAT data" tab of the invoice **Issue:** "Type for mod 347" is not set. It should be set to "Regular operation" as it is done when creating an invoice manually. **Cause:** The default is handled by a function that depends on another field. However that other field is not set when computing the default value and the result is always False. **Solution:** There were a function for the default (_default_mod_349_invoice_type) and an onchange on partner (_onchange_partner_id_set_347_invoice_type). Both of them were checking different conditions. The fix is merging these 2 methods by converting the field into a computed stored field where both conditions are handled. opw-4194030 Forward-Port-Of: odoo/enterprise#72958
This update corrects broken links within the Helpdesk Team form view, ensuring users can easily access relevant documentation. The fix resolves inaccuracies in links to E-learning, Visibility, Email Alias, and Community Forum resources. This improves the user experience and facilitates proper Helpdesk setup and usage.
Original PR description
This PR corrects incorrect documentation links in the Helpdesk Team form view. Steps to reproduce: 1) Install the Helpdesk module. 2) Open any Helpdesk Team or create a new one. 3) Check the documentation links in the following sections: - E-learning - Visibility - Email Alias - Community Forum 4) Notice the incorrect or broken links. **Note**: We do not need to update the .pot file. task-4266660
This update resolves a test failure in the Amazon integration (sale_amazon) caused by a dependency on data that isn't available in the no-demo testing environment. The fix ensures that tests run correctly without relying on this unavailable data, maintaining the stability of the integration.
Original PR description
test_sync_pickings depends on street value, which does not exist in no-demo mode, thus breaking tests. This commit fixes the issue. [broken test](https://runbot.odoo.com/web#id=73283&view_type=form&model=runbot.build.error&menu_id=405&cids=1)
This update fixes an issue where the app logo wasn't immediately updated after a user changed its icon or image. Now, the logo updates dynamically when a user confirms the change, providing a more consistent and user-friendly experience. This ensures users always see the correct branding.
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545
This update fixes an issue where tax closing with fiscal positions wasn't working correctly in Odoo reports. The system now correctly handles all fiscal positions when generating reports, and the closing mechanism has been adjusted to align with intended functionality, particularly for versions prior to 18.0. This ensures accurate tax reporting.
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388
This update resolves a bug where the 'packaging' button wasn't visible when adding products via the barcode app during inventory adjustments. This prevented users from efficiently adding quantities of 15 units, impacting the speed and accuracy of stock management. The fix ensures the button appears correctly, streamlining the inventory adjustment process.
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 ---
This update resolves a bug where subscriptions weren't always creating all expected deliveries due to an error in how invoices were processed. Specifically, the system was incorrectly calling a hook function on empty data, leading to incomplete delivery creation. This fix ensures all subscriptions are correctly processed, preventing missed deliveries.
Original PR description
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook…
_post_invoice_hook was called on an empty RecordSet at the end of AccountMove._post when having the context "recurring_automatic". This context is voluntarily put here to prevent _post_invoice_hook to be run after the invoice posting, so that it can be run at the end of the cron, when all subscriptions have been handled.
However, if _post_invoice_hook is called on an empty RecordSet, it will search for all subscriptions currently handled by the cron.
This often resulted in a situation where only the first subscription was ready for the hook, while the others are not, resulting in only the first delivery created.
---
Test result before fix:
```
2024-11-06 15:41:52,210 35880 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_cron_product_multiple_delivery_creation
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 501, in test_cron_product_multiple_delivery_creation
self.assertTrue(bool(move_1))
AssertionError: False is not true
```
OPW-4166852This update resolves an issue where the barcode app incorrectly displayed a single unit count (1/1) after editing a delivery order. The fix ensures that the system accurately reflects the remaining quantity (0/4) when returning to the record, maintaining data consistency for barcode scanning.
Original PR description
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by…
### Steps to reproduce: - Create a delivery order for 5 units of a product - Scan 1 unit and click on the pencil icon to edit the record further - On the digipad access the backend (for instance by clicking the external link arrow next to the location). - Come back to the record #### > The line now displayed a 1/1 but does not records what remains: 0/4. ### Cause of the Issue: Setting a quantity of 1 on the move line will trigger a write call on the related stock move line to update its quantity. However, when you leave the barcode, even thought it will save these change, it will not split the move in 2 for the barcode app to be able to rely on the backend data to generate a correct sate of the record. Threfore, when you come back to the record, the main component will be regenerated from the backend values of the `get_barcode_data`: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L76-L80 And will onlydisplay the "1/1" line that was reported fromt he back end. ### Fix: The `split_uncompleted_moves` method taking care of splitting the moves for barcode data compatibility: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/models/stock_move.py#L9-L11 is already called when you exit the barcode via the exit button: https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/components/main.js#L228-L231 https://github.com/odoo/enterprise/blob/7b28f4bbd3c20559e529c3134e5b65b089b78806/stock_barcode/static/src/models/barcode_picking_model.js#L762-L765 These were added by commit 2eb6465e4f18c701efdf28ea4b8f95f3119d3db8 However, it should IMO be called every time you leave the app that is just before destroying the component. Furthermore, note that it will only split the moves if a save happend (which is the expacted behavior). opw-4232106 ---