Daily updates from Odoo
Friday, October 18, 2024
7 changes · 18.0
Resolved issues and error corrections
Sales orders now show the warehouse field by default when needed, so users can select the newly created warehouse before confirming an order. This prevents a blocking error after creating a warehouse for a new company and helps sales confirmations proceed smoothly.
Original PR description
### Steps to reproduce: - Create a new company and select it - Create a SO for an Good and try to confirm > you raise a redirect warning to create a warehouse - Proceed and create a warehouse - Try to confirm the SO once more #### > Since the newly created warehouse was not set on the SO you raise a #### > user Error: 'You must set a warehouse on your sale order to proceed.' ### Issue: The 'warehouse_id' should be visible on the SO for it to be set but it is not. ### Cause of the issue: The field is actually present in the view as soon as your have 2 WH in your company: https://github.com/odoo/odoo/blob/73a62537c4010831cfab4be40f91dba9c56c2175/addons/sale_stock/views/sale_order_views.xml#L24 https://github.com/odoo/odoo/blob/73a62537c4010831cfab4be40f91dba9c56c2175/addons/stock/models/stock_warehouse.py#L321-L336 opw-4250791 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores and corrects several payment flows for Argentine localization, especially around checks, withholdings, and payment transfers. It prevents configuration-related payment errors, fixes receipt printing and unnamed check crashes, and ensures check transfers and withholding amounts behave correctly again.
Original PR description
In this commit: https://github.com/odoo/odoo/commit/2609fc2e38b8a82c773f27f910f2030b5d704633 We made the journal entry optional for payments. But this pr broke some flows for l10n_ar. This commit…
In this commit: https://github.com/odoo/odoo/commit/2609fc2e38b8a82c773f27f910f2030b5d704633 We made the journal entry optional for payments. But this pr broke some flows for l10n_ar. This commit will correct the following issues: - Domain where we check the posted state, the posted state don't exist anymore, we will adapt this by checking for in_progress and paid status. - Adding outstanding accounts on argentinian bank and cash journals. - Adding back the synchronisation of payment -> move for withholdings - Adding a check that we can't have a payment with a checks payment method that has no outstanding accounts - Fixing a traceback when the check has no name - When being in the payment wizard with check and withholding, a commit (https://github.com/odoo/odoo/commit/774d76682a72a786986bbcb70099c2a3be7a09d6) removed a dependency on the compute net amount which made the warning to never be displayed. - Check transfer wizard was not working anymore cause internal_transfer logic was removed. This commit reintroduce it, when being on a third party check and making a transfer it will create a first payment to reverse the check and a new one on the destination journal. - Correct the payment receipt traceback when trying to print it. task: 4204366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures tax rounding differences are handled after negative or refund lines are matched, preventing small rounding adjustments from being lost or assigned incorrectly. It helps keep invoices, refunds, and related electronic reporting totals accurate in accounting workflows.
Original PR description
The method '_round_base_lines_tax_details' must be called after the dispatching of negative lines. Suppose a line has a delta due to round globally with price included taxes. Then this line is refunded completely by a line without a delta. The current delta is lost and probably should go to another line. task-id: 4261885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now add combo products from website shopping snippets without running into the wrong flow. The site opens the combo configurator as expected, helping shoppers complete purchases smoothly.
Original PR description
The "add to cart" and "products" snippets didn't handle combo products correctly. This fix opens the combo configurator when a combo product is added to the cart via one of those snippets. opw-4250695
Cancelling an unsent restaurant POS order no longer causes an error. This makes the checkout workflow smoother by ensuring draft orders can be cancelled reliably the first time.
Original PR description
Steps to reproduce : -------------------------- - Install the pos_restaurant module. - Add some products to order don't order them. - Try to cancel order from action button. Issue : -------- - There will be a traceback as it was trying to fetch & delete order from preparation display as well. - If you have never visited floor screen the order won't be synced and have string id so at the time of cancellation at first try it can't get order's int id and we have to again click on cancel order to delete it. Cause : -------- - The condition applied was now not relevant as structure of data changed. - The order was still not synced at backend so have temparary string id at time of action click. Fix : ----- - Changed condition as per the new structure. - Fetched data from backend at time of getting id to remove it.
Sales orders now show the warehouse field by default when a warehouse needs to be selected. This prevents users from getting blocked after creating a warehouse because the order could not be confirmed without one.
Original PR description
### Steps to reproduce: - Create a new company and select it - Create a SO for an Good and try to confirm > you raise a redirect warning to create a warehouse - Proceed and create a warehouse - Try to confirm the SO once more #### > Since the newly created warehouse was not set on the SO you raise a user Error: #### > 'You must set a warehouse on your sale order to proceed.' ### Issue: The 'warehouse_id' should be visible on the SO for it to be set but it is not. ### Cause of the issue: The field is actually present in the view as soon as your have 2 WH in your company: https://github.com/odoo/odoo/blob/73a62537c4010831cfab4be40f91dba9c56c2175/addons/sale_stock/views/sale_order_views.xml#L24 https://github.com/odoo/odoo/blob/73a62537c4010831cfab4be40f91dba9c56c2175/addons/stock/models/stock_warehouse.py#L321-L336 opw-4250791 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing visible rows in the Master Production Schedule no longer resets the page filter. This keeps users in the expected schedule view, such as the products linked to a specific bill of materials, avoiding confusion and extra navigation.
Original PR description
Steps:
- create 2 boms:
-- bom_A: product_A with component_A
-- bom_B: product_B with component_B
- add all 4 products to the MPS
- go to bom_A and click on the 'Schedules' smart button, there should
only be 2 records (product_A & component_A)
- open the search dropdown menu and select a 'Rows' option
Issue:
When changing the rows to be shown in the MPS (e.g. Actual Demand),
OWL calls `write` directly via the orm on res.company because those
fields are set on res.company. This is due to 'company_service.js':
```js
if (!error && model === "res.company" && UPDATE_METHODS.includes(method)) {
if (!browser.localStorage.getItem("running_tour")) {
action.doAction("reload_context");
}
}
```
This cause the page to do a full refresh, which loses the domain.
Fix:
This fix makes it so that when changing the rows in the search menu,
OWL calls a specific function that will do the same job but without
the full reload, thus keeping the domain.