Odoo Changelog — 2024-11-14

Thursday, November 14, 2024

4 changes · 17.0

Bug Fixes(4)

Resolved issues and error corrections

[FIX] l10n_br_edi: more reliably detect cancellation errors

Enterprise17.0l10n_br_ediMEDIUM

This update strengthens how Odoo detects failed invoice cancellations for Brazilian e-commerce (BR-EDI). Previously, the system only checked for a specific 'error' key in the response, which wasn't reliable due to various government rejection reasons. Now, the system checks for the return of XML data, ensuring a failed cancellation is detected regardless of the specific reason.

Original PR description

Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the
response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed.

[1] 4.4. Lista das Regras de Validação in
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J%20I%20v4eN00E=

#BR-EDI#cancellation#e-commerce

[FIX] sale_external_tax: error when recomputing taxes in a locked order

PR #73505

Enterprise17.0saleMEDIUM

This update resolves an issue where recomputing taxes on locked sales orders triggered errors, preventing users from completing actions like sending emails. The fix prevents tax recalculation when sending emails from locked orders, addressing a user error blocking functionality. This ensures locked orders remain unchanged and reliable.

Original PR description

1. Set up Avatax on the current company
2. In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales'
3. Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)'
4. Add a partner and product having avatax category defined
5. Compute taxes
6. Confirm order, it will be automatically locked
7. Click "Send by Email"

Issue: Action will be blocked by User Error
```
It is forbidden to modify the following fields in a locked order
```

This occurs because when sending by email we recompute external taxes, but it
should not be the case for locked orders
It also occurs on the web shop when finalizing the payment

opw-4261396

#sales#taxes#locked orders#avatax

[FIX] stock_barcode: assign mto moves in barcode split

PR #73773

Enterprise17.0stockMEDIUM

This update resolves an issue where the barcode app wasn't correctly creating stock move lines when splitting MTO (Multiple Throughput Order) moves. The fix ensures that when a user splits a delivery using the barcode app, new move lines are generated, allowing the app to accurately track inventory. This prevents a single line from appearing in the barcode app.

Original PR description

### Steps to reproduce:

- In the settings: enable multi-steps route
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable prodcut with MTO, buy routes and a set vendor
- Create and confirm a sale order for 3 units of your product
- Confirm the purchase order and the associated reciept
- Go to the barcode app on you delivery
- set the quantity to 1/3 and leave the barcode app
- Go back to the the delivery
### > only one line 1/1 appears

### Cause of the issue:

The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line:
https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`:
https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422
As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on.

opw-4232106
---

#inventory#mto#barcode#stock_move

[FIX] quality_control: require quality check only for received products

PR #73407

Enterprise17.0stock

This update ensures quality checks are only triggered for products that have actually been received into inventory. Previously, a product could trigger a quality check even if it was part of a pending order. This change corrects a bug related to backorders, improving inventory accuracy and preventing unnecessary quality check processes.

Original PR description

**Steps to reproduce the bug:**
- Create a tracked product by SN: “P1.”
- Create a storable product: "P2."
- Create a receipt for one unit of P1 and P2.
- Mark it as "To Do."
- Set the done quantity of P1 to 0.
- Attempt to perform the quality check.

**Problem:**
You must perform a quality check for P1 even though it has yet to be received.

Since the move_line is set to 0 rather than deleted in the original
picking, it will be linked to the backorder when it is created.
Therefore, to avoid unexpected behavior we can ignore linking its
quality check to the backorder.

https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832


opw-4187521

#stock#quality check#inventory

Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1] 4.4. Lista das Regras de Validação in https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J%20I%20v4eN00E=

1. Set up Avatax on the current company 2. In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' 3. Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' 4. Add a partner and product having avatax category defined 5. Compute taxes 6. Confirm order, it will be automatically locked 7. Click "Send by Email" Issue: Action will be blocked by User Error ``` It is forbidden to modify the following fields in a locked order ``` This occurs because when sending by email we recompute external taxes, but it should not be the case for locked orders It also occurs on the web shop when finalizing the payment opw-4261396

### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a set vendor - Create and confirm a sale order for 3 units of your product - Confirm the purchase order and the associated reciept - Go to the barcode app on you delivery - set the quantity to 1/3 and leave the barcode app - Go back to the the delivery ### > only one line 1/1 appears ### Cause of the issue: The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`: https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422 As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on. opw-4232106 ---

**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521