Friday, April 18, 2025
33 changes · saas-18.1
Miscellaneous changes
After clearing the cache you can have inconsistent reward lines that have no coupon associated with them. Steps to reproduce: ------------------- * Create an order and add any reward (Buy X Get Y for example) * Go to the backend to make sure the order is saved in the database * Go back to the POS and clear the cache > Observation: You are stuck on the loading screen Why the fix: ------------ To avoid having inconsistent reward lines that have no coupon associated with them, we delet
Original PR description
After clearing the cache you can have inconsistent reward lines that have no coupon associated with them. Steps to reproduce: ------------------- * Create an order and add any reward (Buy X Get Y for example) * Go to the backend to make sure the order is saved in the database * Go back to the POS and clear the cache > Observation: You are stuck on the loading screen Why the fix: ------------ To avoid having inconsistent reward lines that have no coupon associated with them, we delete all the lines of an order that contains wrong data. As this is not supposed to happen (clearing the cache is a debug functionality), we can safely delete the lines because it's wont impact the real workflow of the users. opw-4655422 Forward-Port-Of: odoo/odoo#202752
From the first of July 2025, the standard rate of VAT in Estonia is 24% instead of the current 22%. This commit adds the new tax. Also, one of the EU Intra-Community mappings was missing, specifically the 22% G (Purchases) -> 0% EU G 22% (Purchases). This was also added. task-4595806 Forward-Port-Of: odoo/odoo#205436 Forward-Port-Of: odoo/odoo#199789
Original PR description
From the first of July 2025, the standard rate of VAT in Estonia is 24% instead of the current 22%. This commit adds the new tax. Also, one of the EU Intra-Community mappings was missing, specifically the 22% G (Purchases) -> 0% EU G 22% (Purchases). This was also added. task-4595806 Forward-Port-Of: odoo/odoo#205436 Forward-Port-Of: odoo/odoo#199789
The original issue was that when you duplicated a pos restaurant, it would also duplicate it's floors. And when you would make an order on the same table in the 2 restaurant the second one would take the first one and override it. Steps to reproduce: ------------------- * Duplicate a restaurant * Make an order on the same table in the 2 restaurant * The second one will take the first one and override it > Observation: The new order contains the first order lines in it if you check the d
Original PR description
The original issue was that when you duplicated a pos restaurant, it would also duplicate it's floors. And when you would make an order on the same table in the 2 restaurant the second one would take the first one and override it. Steps to reproduce: ------------------- * Duplicate a restaurant * Make an order on the same table in the 2 restaurant * The second one will take the first one and override it > Observation: The new order contains the first order lines in it if you check the db Why the fix: ------------ To avoid confusion when duplicating restaurant we prevent duplicating the floor plans automatically. opw-4536327 Forward-Port-Of: odoo/odoo#205590
Steps to reproduce: 1. Install Indian E-waybill(`l10n_in_edi_ewaybill`) 2. Activate Unit of Measures 3. Create a Invoice with a move line product as default UOM as units. 4. Change the UOM on line to Dozens 5. Confirm and send the E-waybill On portal the E-waybill for that line is Unit instead of Dozens In this commit we fix the issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206400 Forward
Original PR description
Steps to reproduce: 1. Install Indian E-waybill(`l10n_in_edi_ewaybill`) 2. Activate Unit of Measures 3. Create a Invoice with a move line product as default UOM as units. 4. Change the UOM on line to Dozens 5. Confirm and send the E-waybill On portal the E-waybill for that line is Unit instead of Dozens In this commit we fix the issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206400 Forward-Port-Of: odoo/odoo#206191
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Cr
Original PR description
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it…
…unding method **Problem:** The bug is in pos, when the products are tax included and the rounding method is UP. When, the client is paying more cash than the amount, the change is not rounded as it should be. **Steps to reproduce:** - Open point Of Sale/Configuration/Taxes - Create a new tax, with an amount of 7% - In the Advanced option tab set "Included In Price" to "Tax Included" - Create a product A with a Sales Price of 95$ and select the tax you created as the "Sales tax" - Create a product B with a Sales Price of 42$ and select the tax you created as the "Sales tax" - Open Accounting/Configuration/Management/Cash Roundings and create a new rounding - As Rounding Precision select 1.00 (the bug can happen also with other values here) - Set Rounding Strategy as "Add a rounding line" - Set Rounding Method to "Up" - Open the point of Sale app and open a store - Select one product A and two product B in the order - Click on payment and Cash - Enter a cash value of 200$ **Current behavior:** The Change has a value of 20 **Expected behavior:** The change should have a value of 21 **Cause of the issue:** In account_tax.js tax_totals_summary.base_amount_currency takes the values of values.total_excluded_currency https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L871 values.total_excluded_currency is computed as the sum of two floats With the values of our steps it creates a floating-point rounding error (the value is 88.79+78.50=167.29000000000002 and the rounding error is 0.00000000000002) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1166 tax_totals_summary.base_amount_currency is then used in another float addition to compute total_amount_currency.Because it's the second float addition the rounding error increases. (the value calculated is 167.29000000000002+11.71=179.00000000000003 and now the rounding error is 0.00000000000003) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/account/static/src/helpers/account_tax.js#L1011 total_amount_currency is then used in pos_order.js to compute the remaining https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L157 https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L161 The remaining is used inside of the get_change method https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/point_of_sale/static/src/app/models/pos_order.js#L887 this 0.00000000000003 rounding error has propagated to there and the value is 20.99999999999997 instead of 21 Because the rounding error comes from two consecutive float addition it's too big to be compensated by epsilon (here epsilon has a value of 1.8651746813702624e-14 which brings the value to 20.99999999999999) https://github.com/odoo/odoo/blob/b9535901fb5a4b2b32e3e6c6c84ae12aca3930d6/addons/web/static/src/core/utils/numbers.js#L71 Consequently when it's rounded down (the inversion from up to down is because the change value is negative) it's rounded to 20 instead of 21 **Fix:** Because this rounding mistake only appears with the value of "remaining" I added a rounding inside getRoundedRemaining before applying any customized rounding method. opw-4615638 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#204301
`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639 Forward-Port-Of: odoo/odoo#206613
Original PR description
`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639 Forward-Port-Of: odoo/odoo#206613
Steps to reproduce the bug: - Create a storable product P1: - Tracked by: Lot - Update the quantity of P1 with one unit and Lot 1 - Create a storable product C1 - Tracked by: Serial Number - Update the quantity of C1 with one unit and SN1 - Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders - Create a repair order: - Add part: Select product C1 with SN1 - Try to save Problem: The lot "Lot 1" is incompatible with the product "C1". Since we access
Original PR description
Steps to reproduce the bug:
- Create a storable product P1:
- Tracked by: Lot
- Update the quantity of P1 with one unit and Lot 1
- Create a storable product C1
- Tracked by: Serial Number
- Update the quantity of C1 with one unit and SN1
- Navigate to Product P1 → Lot/SN → Click on Lot 1 → Repair Orders
- Create a repair order:
- Add part: Select product C1 with SN1
- Try to save
Problem:
The lot "Lot 1" is incompatible with the product "C1".
Since we access the Repair Order view from the Lot/SN view, a default
key is added with "Lot 1". As a result, when trying to create the
"stock.move.line" for C1, this incorrect lot is used.
opw-4576741
opw-4576004
Forward-Port-Of: odoo/odoo#205383
Forward-Port-Of: odoo/odoo#202979This error occurs when a user creates multiple rewards of the same program using below steps : Steps to Reproduce : - Install module `sale_management` and `sale_loyalty. - In Products, go to Discount & Loyalty. - Create two new `Discount & Loyalty` with the program type `Coupons` and `Generate coupons. ` - Add multiple rewards to one coupon program. - Create a sale order and apply a coupon code from the first Discount & Loyalty program. Repeat the process with the coupon code from
Original PR description
This error occurs when a user creates multiple rewards of the same program using below steps : Steps to Reproduce : - Install module `sale_management` and `sale_loyalty. - In Products, go to Discount & Loyalty. - Create two new `Discount & Loyalty` with the program type `Coupons` and `Generate coupons. ` - Add multiple rewards to one coupon program. - Create a sale order and apply a coupon code from the first Discount & Loyalty program. Repeat the process with the coupon code from the second program. ValueError : Expected singleton: loyalty.reward(3, 4, 5) This error occurs when the system tries to fetch global_rewards but receives multiple values instead of a single record. This commit resolves the error by ensuring that only the global reward with the highest discount is selected. Sentry - 6417784661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202524
Steps to reproduce the bug: - Go to inventory settings and enable dropshipping option -> the operation type: dropship in created - Disable the drop-shipping option in the settings -> The module is uninstalled, but the operation type is not archived so it can cause a traceback if using it. Problem: The best solution, is to remove completely the picking type, but as is linked to several other records, like rule or purchase order, it will be impossible to delete everything related, so the b
Original PR description
Steps to reproduce the bug: - Go to inventory settings and enable dropshipping option -> the operation type: dropship in created - Disable the drop-shipping option in the settings -> The module is uninstalled, but the operation type is not archived so it can cause a traceback if using it. Problem: The best solution, is to remove completely the picking type, but as is linked to several other records, like rule or purchase order, it will be impossible to delete everything related, so the best solution is to archive it, so we can limit the impact of the uninstallation. opw-4690502 Forward-Port-Of: odoo/odoo#205391
In [1], a mechanism was introduced to detect when notifications were lost due to the bus table being cleared during a disconnection. However, this approach used the autovacuum cron dates to detect this scenario. Other actions can clear the bus table, which is typically the case on odoo.com where another cron runs more frequently. This PR fixes the issue by comparing the disconnection time with the oldest bus notification's create date. [1]: https://github.com/odoo/odoo/pull/188003 De
Original PR description
In [1], a mechanism was introduced to detect when notifications were lost due to the bus table being cleared during a disconnection. However, this approach used the autovacuum cron dates to detect this scenario. Other actions can clear the bus table, which is typically the case on odoo.com where another cron runs more frequently. This PR fixes the issue by comparing the disconnection time with the oldest bus notification's create date. [1]: https://github.com/odoo/odoo/pull/188003 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#206106
Add a placeholder for eInvoice format. task-4544834 (Part-of) Forward-Port-Of: odoo/odoo#206498
Original PR description
Add a placeholder for eInvoice format. task-4544834 (Part-of) Forward-Port-Of: odoo/odoo#206498
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/odoo#206423 Forward-Port-Of: odoo/odoo#205900
Original PR description
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/odoo#206423 Forward-Port-Of: odoo/odoo#205900
Add a placeholder for Peppol EAS field. task-4544834 (Part-of) Forward-Port-Of: odoo/odoo#206385
Original PR description
Add a placeholder for Peppol EAS field. task-4544834 (Part-of) Forward-Port-Of: odoo/odoo#206385
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users Steps to reproduce: - Select company BE Company CoA - Open Settings > Accounting > PEPPOL Electronic Invoicing - Activate Electronic Invoicing (if is not activated) - Go to
Original PR description
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test…
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users
Steps to reproduce:
- Select company BE Company CoA
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Activate Electronic Invoicing (if is not activated)
- Go to Accounting / Configuration / EDI Proxy Users
- Select the unique record (demo2peppol)
- Edit the id_client of the record to another one (this must need Odoo Studio or Odoo Inspector > Write > {"id_client": "another"})
- Go to tree view of EDI Proxy Users
- Archive it
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Remove from PEPPOL (archived record will not be deleted)
- Activate Electronic Invoicing Again (now you have one record active and another not)
- Go to Contacts > Search "BE Company CoA" > Select Contact
- Go to Accounting Tab > Customer Invoices section > Enable eInvoice Format (BIS Billing 3.0)
- Go to Contact & Addresses Tab
- Try to add a new Contact type (error while saving)
opw-4572074
Forward-Port-Of: odoo/odoo#201606The commercial partner country field is required for later improvements namely filtering or reports related ones. --- task-4725240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205952
Original PR description
The commercial partner country field is required for later improvements namely filtering or reports related ones. --- task-4725240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205952
Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry. Forward-Port-Of: odoo/odoo#206465
Original PR description
Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry. Forward-Port-Of: odoo/odoo#206465
When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203893
Original PR description
When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203893
This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA
Original PR description
This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206372 Forward-Port-Of: odoo/odoo#180313
Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112 Forward-Port-Of: odoo/odoo#206437
Original PR description
Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112 Forward-Port-Of: odoo/odoo#206437
Steps: - Install `project` - Open a task - Create a subtask - Try to access chatter - It works on desktop, because you have the expand button - It doesn't work on mobile This commit adds this button on mobile too opw-4631478 Forward-Port-Of: odoo/odoo#205843
Original PR description
Steps: - Install `project` - Open a task - Create a subtask - Try to access chatter - It works on desktop, because you have the expand button - It doesn't work on mobile This commit adds this button on mobile too opw-4631478 Forward-Port-Of: odoo/odoo#205843
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4. Steps to reproduce ================== - Install account_accountant - Go to accounting - Close the onboarding banner => TypeError: Cannot read properties of null (reading 'context') at _preprocessAction Cause of the issue ================== With commit 4c7942e6bd04, the response when calling the action changed ```diff - {"jsonrpc": "2.0", "id": 10} + {"jsonrpc": "2.0", "id": 10, result: null} ``` https:
Original PR description
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4.
Steps to reproduce
==================
- Install account_accountant
- Go to accounting
- Close the onboarding banner
=> TypeError: Cannot read properties of null (reading 'context')
at _preprocessAction
Cause of the issue
==================
With commit 4c7942e6bd04, the response when calling the action changed
```diff
- {"jsonrpc": "2.0", "id": 10}
+ {"jsonrpc": "2.0", "id": 10, result: null}
```
https://github.com/odoo/odoo/blob/c412f11c028a8c7ff6e6c10da0e3f9dbc55e8e80/addons/web/static/src/views/view_hook.js#L86-L89
The condition `action !== undefined` is no longer met since the result is null.
Solution
========
Since this can happen anywhere we make an RPC call and there's no easy way to detect it, we revert the commit in stable.
Forward-Port-Of: odoo/odoo#206444Steps to Reproduce : - Drag and drop a "Text" snippet. - Click on "Hide on desktop". - Toggle on the eye button to force its visibility. - Click on a text outside the snippet & press enter. - Bug: the invisible snippet disappears. The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" c
Original PR description
Steps to Reproduce : - Drag and drop a "Text" snippet. - Click on "Hide on desktop". - Toggle on the eye button to force its visibility. - Click on a text outside the snippet & press enter. - Bug: the invisible snippet disappears. The issue comes from the fact that when we press Enter, a new paragraph is created and a history rollback is triggered at that moment. So when we go back in the history because of that rollback, the invisible snippet loses the "o_snippet_override_invisible" class that had just been applied. Actually, adding and removing this class should not be inside the observer. This commit prevents that from happening. task-4690318 Forward-Port-Of: odoo/odoo#206266
`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637 Forward-Port-Of: odoo/enterprise#83691
Original PR description
`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637 Forward-Port-Of: odoo/enterprise#83691
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83665
Original PR description
`TestPayslipValidation.setUpClass` tries to create an `hr.leave.type` but that requires hr admin access. So add that. Issue likely became visible from the removal of demo data, though it only popped up on April 1st instead of March 27th or whenever the demo data change was merged. https://runbot.odoo.com/odoo/error/162257 Forward-Port-Of: odoo/enterprise#83665
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/enterprise#83596 Forward-Port-Of: odoo/enterprise#83497
Original PR description
The percentage sign is missing on the tax line in the invoice report opw-4661577 Forward-Port-Of: odoo/enterprise#83596 Forward-Port-Of: odoo/enterprise#83497
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ
Original PR description
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian…
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occured in the generation of the return label ### Cause of the issue: The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here: https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point. #### Note: Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels. opw-4562040 Forward-Port-Of: odoo/enterprise#83436 Forward-Port-Of: odoo/enterprise#83357
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of material for a final product FP with one raw: - 3 x COMP (storable product with 10 units in stock) - Create and confirm an MO for 1 unit of FP. > This create a picking from stock to preprod for 3 unit of COMP - In the shopfloor on your MO click on the 3 dots and add components - Register
Original PR description
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of…
### Step to reproduce:
- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
- 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units
### Cause of the issue:
When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.
opw-4562965
Forward-Port-Of: odoo/enterprise#83555
Forward-Port-Of: odoo/enterprise#81818`(stock.picking).move_ids_without_package.lot_ids` is gated on `stock.group_production_lot`, if the user doesn't have this group, the field is unavailable and trying to set it via the form fails. https://runbot.odoo.com/odoo/error/163100 Forward-Port-Of: odoo/enterprise#83588
Original PR description
`(stock.picking).move_ids_without_package.lot_ids` is gated on `stock.group_production_lot`, if the user doesn't have this group, the field is unavailable and trying to set it via the form fails. https://runbot.odoo.com/odoo/error/163100 Forward-Port-Of: odoo/enterprise#83588
This PR fixes two behavior on the lipe xml export in Italy. --- The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry. --- The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it. --- no-task Forward-Port-Of: odoo/ente
Original PR description
This PR fixes two behavior on the lipe xml export in Italy. --- The first one linked to this fix: https://github.com/odoo/enterprise/commit/7323435468c8db15cd5643f7d6ecf5928ab2f3dc . It makes sure the options are gathered the right way depending on whether we export the xml from the report or from the closing entry. --- The second one makes sure the closing entry move is posted when the xml export is done pressing the "Post" button on it. --- no-task Forward-Port-Of: odoo/enterprise#83628 Forward-Port-Of: odoo/enterprise#83503
This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905
Original PR description
This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905
Avalara populates those fields as "false" in the account, which causes issues during EDI. We keep sending the fields, but send empty string instead. opw-4716571 Forward-Port-Of: odoo/enterprise#83550
Original PR description
Avalara populates those fields as "false" in the account, which causes issues during EDI. We keep sending the fields, but send empty string instead. opw-4716571 Forward-Port-Of: odoo/enterprise#83550
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83490 Forward-Port-Of: odoo/enterprise#81018
Original PR description
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83490 Forward-Port-Of: odoo/enterprise#81018
In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default. We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts. task-4734669 Correction for: task-4369979 [1]: 7a593a4aa5040998dc12468dec12dca62f573030 Forward-Port-Of: odoo/enterprise#83562
Original PR description
In [1] we added a compute on wa_account_id in stead of a default to allow for a smarter default. We forgot to mark the field readonly in the process. This prevents the import of existing templates, or of templates from different accounts. task-4734669 Correction for: task-4369979 [1]: 7a593a4aa5040998dc12468dec12dca62f573030 Forward-Port-Of: odoo/enterprise#83562