Saturday, June 14, 2025
8 changes · master
Miscellaneous changes
This PR fixes the condition used to show "Pairing code expired" on the iot box homepage and the status screen task-4852692 Forward-Port-Of: odoo/odoo#213233
Original PR description
This PR fixes the condition used to show "Pairing code expired" on the iot box homepage and the status screen task-4852692 Forward-Port-Of: odoo/odoo#213233
Previously, when selling a product to a foreign customer, the translated product name was stored in the order line description. However, the salesman could update this description, and if he did, the product name would be automatically included in the quotation's line description but kept hidden to ensure it appears in the final quotation PDF. Unfortunately, the product name was not translated into the partner language. This commit keeps the previous behavior with the exception that the produ
Original PR description
Previously, when selling a product to a foreign customer, the translated product name was stored in the order line description. However, the salesman could update this description, and if he did, the product name would be automatically included in the quotation's line description but kept hidden to ensure it appears in the final quotation PDF. Unfortunately, the product name was not translated into the partner language. This commit keeps the previous behavior with the exception that the product name included in quotations' line descriptions is now translated into the partner language. opw-4760300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214099 Forward-Port-Of: odoo/odoo#209141
- rounding_method is there on the python code but not js-side. - rounding_method is passed to the taxes computation but not used after to decide if the total_excluded has to be rounded or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214278 Forward-Port-Of: odoo/odoo#213820
Original PR description
- rounding_method is there on the python code but not js-side. - rounding_method is passed to the taxes computation but not used after to decide if the total_excluded has to be rounded or not. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214278 Forward-Port-Of: odoo/odoo#213820
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5 units and backorder - Validate the backorder R2 for 3 units and backorder - Validate the backorder of the backorder R3 for 1 units and backorder #### > The on hand qty of the product is at 99 even thought you registered only 9 units. ### Cause of the issue: Currently, the above flow as
Original PR description
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5…
### Steps to reproduce: - Create a storable product P with a vendor and a subcontracting bom for that vendor. - Create a purchase order for 100 units with that vendor. - Validate the receipt R1 for 5 units and backorder - Validate the backorder R2 for 3 units and backorder - Validate the backorder of the backorder R3 for 1 units and backorder #### > The on hand qty of the product is at 99 even thought you registered only 9 units. ### Cause of the issue: Currently, the above flow associate with the last receipt move with a qty of 1 both a move line for 1 unit and a move line for 90 units. As both will be picked at validation time, the receipt for 1 unit will effectively be treated as a receipt of 91 units. Here are the details: Updating the quantity of the move of R1 to 5 will in turn update the quantity of the move line to 5 and pick it by the "_set_quantity": https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L78-L82 https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L139-L143 Then, the first validation (of R1) for 5 units instead of 100 is well processed: it creates a backorder with a receipt move for 95 units and assign it with a single move line of 95. Similarily, setting the quantity on R2 will set the move line to 3 picked units. However, at validation, the situation will be quite different when assigning its backorder since the move of R2 now has an `move_orig_ids`. This will result in R3 to be assigned by 2 move lines: - one for 2 units - one for 90 units instead of one for 92 units. Indeed, during the action_assign of R3 (triggered by the `_create_backorder` of R2), we try to determine the qty available from done move lines related to our move_orig_ids and its `move_dest_ids` in order to see if there is already an available quantity (bacause more was processed in than out for instance). We will then first create a move line for that available quantity: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1873-L1886 and finish the assignment with the `missing_reserved_quantity`: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1907 The issue is that in our case, we should not find any available quantity to assign and the method responsible for this computation `_get_available_move_lines` will still find a discrepency between the available_move_lines_in qty and the available_move_lines_out qty for 5 - 3 that is 2 units -> We will end up with one move line for 2 units and one for 90. The discrepency is due to the fact that the `_get_available_move_lines_in` finds one in move line **done** for 5 units of R1. But that the `_get_available_move_lines_out` first finds the move line **done** for 5 units related to R1: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1817-L1821 But then erase the values by the demand of 3 provided by the **partially_available** move line of R2 that we are currently validating and that we should not have considered in the present flow: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_move.py#L1822-L1823 In particular, we end with a picking R3 for 92 units and 2 move lines. Now, setting the quantity of R3 to 1 will update the quantity of the first move line to 1 and set it as picked without altering the second one as the update of the quantity can totally be handled by the first move line. We therefore end up with a move with a move with a quantity of 1 and 2 move lines: 1 picked unit and 90 unpicked unit: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/mrp_production.py#L124-L143 Now, this would be fine if the second move line was not automatically picked as it would be ignored by the action done. However, since the move it self was not picked since subcontracted moves are never automatically recomputed as picked from their move lines: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/mrp_subcontracting/models/stock_move.py#L61-L63 the _pre_action_done_hook of the picking validation will pick the entire move and hence set the other move line as picked: https://github.com/odoo/odoo/blob/d7daf7dc075896ec4707f912acd41fb1249d5959/addons/stock/models/stock_picking.py#L1486-L1487 In particular both move lines will be validated and update the related stock quants. ### Fix: Since in the case where there is no done move line we still find the outgoing partially reserved quantity that we are currently validating we should add the values of both **done** and **reserved** outgoing qties for the behavior on backorders to be the same as on the first picking validation. opw-4822646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213768
rounding_method is there on the python code but not js-side. Forward-Port-Of: odoo/enterprise#87698 Forward-Port-Of: odoo/enterprise#87433
Original PR description
rounding_method is there on the python code but not js-side. Forward-Port-Of: odoo/enterprise#87698 Forward-Port-Of: odoo/enterprise#87433
In this commit: --- - Adds a new worksheet to the XLSX export of the Journal Audit report, summarizing all filters and options active at the time of export. - This feature was already available for other accounting reports but was missing in the Journal Audit report. --- task-4859786 Forward-Port-Of: odoo/enterprise#87395
Original PR description
In this commit: --- - Adds a new worksheet to the XLSX export of the Journal Audit report, summarizing all filters and options active at the time of export. - This feature was already available for other accounting reports but was missing in the Journal Audit report. --- task-4859786 Forward-Port-Of: odoo/enterprise#87395
Since [^1] company customers are always invoiced by default. To Invoice should always be false for Brazil POS orders which is why the button on the payment screen was hidden, however, there is now no way to uncheck it. Fix: Set "To Invoice" to false always if the company's fiscal country is Brazil. [^1]: https://github.com/odoo/odoo/pull/202515 opw-4861672 Forward-Port-Of: odoo/enterprise#87586 Forward-Port-Of: odoo/enterprise#87389
Original PR description
Since [^1] company customers are always invoiced by default. To Invoice should always be false for Brazil POS orders which is why the button on the payment screen was hidden, however, there is now no way to uncheck it. Fix: Set "To Invoice" to false always if the company's fiscal country is Brazil. [^1]: https://github.com/odoo/odoo/pull/202515 opw-4861672 Forward-Port-Of: odoo/enterprise#87586 Forward-Port-Of: odoo/enterprise#87389
Before, if you marked the to publick check in an invoice, the generated cfdi would force the Without fiscal obligations regime at the receptor data, but this wasn't done on the invoice which caused a mismatch on what was being reflected on the invoice and what was on the cfdi. This commit targets to show the same info on the invoice if invoice is set to public target: 18.0 -> master task-4685440 Forward-Port-Of: odoo/enterprise#87263
Original PR description
Before, if you marked the to publick check in an invoice, the generated cfdi would force the Without fiscal obligations regime at the receptor data, but this wasn't done on the invoice which caused a mismatch on what was being reflected on the invoice and what was on the cfdi. This commit targets to show the same info on the invoice if invoice is set to public target: 18.0 -> master task-4685440 Forward-Port-Of: odoo/enterprise#87263