Daily updates from Odoo
Wednesday, July 17, 2024
6 changes
4 changes
Resolved issues and error corrections
Inventory receipt line destinations now stay aligned when the destination location is changed on a purchase reception. This prevents mismatches between stock moves and their detailed move lines, helping warehouse teams route received products to the correct storage location.
Original PR description
Steps to reproduce: 1. Enable storage locations in Inventory settings. 2. Create a purchase order for a storable product and confirm it. 3. Change the destination location of the product reception. 4. Stock move destination is updated but not the SML destination. Bug: once location is set on the SML it is not updated any more by the compute opw-3971603
Changing the destination location on a stock transfer now correctly updates the related stock moves and move lines. This prevents warehouse records from becoming inconsistent and helps ensure goods are routed to the intended location.
Original PR description
When changing the destination location on a picking, it will also be updated on the included stock moves and stock move lines. However, due the introduction of the compute on the location_dest_id field on a stock move in [1], this propagation no longer works. This commit restores the updating of the stock moves when changing it on the parent picking. [1] https://github.com/odoo/odoo/pull/156437 task-3390325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an inventory reception issue where changing a product's destination location updated the stock move but not its related move line. Businesses can rely on receptions reflecting the correct storage location, reducing picking and warehouse placement errors.
Original PR description
Steps to reproduce: 1. Enable storage locations in Inventory settings. 2. Create a purchase order for a storable product and confirm it. 3. Change the destination location of the product reception. 4. Stock move destination is updated but not the SML destination. Bug: once location is set on the SML it is not updated any more by the compute opw-3971603
This fixes an issue that blocked users from creating repair orders for product lots that are not tied to a specific company. Businesses using shared or cross-company lots can now process repairs without encountering a company validation error.
Original PR description
**Steps to reproduce the bug:** - Create a lot without company set with any product - open the repairs list from this lot - Try to save the repair **Problem:** An error is raised: “Invalide fields: Company” Since this commit: https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69 A lot can be created without a company set, but the repair order still requires a company: https://github.com/odoo/odoo/blob/17.0/addons/repair/models/repair.py#L36-L39 This key is passed in the context as 'default_company_id', but since the lot does not have a company, the value is set to False, which triggers an error. opw-4046897
1 change
Resolved issues and error corrections
Fixed an issue in restaurant Point of Sale preparation displays where adding an internal note to a newly added item could incorrectly apply that note to an earlier identical item already sent for preparation. The system now keeps those lines distinct, ensuring kitchen staff see the right note on the right item.
Original PR description
If you already ordered product A and add another product A with an internal note. The internal note would end up on both product A. The correct behavior would be to have the internal note on only one…
If you already ordered product A and add another product A with an internal note. The internal note would end up on both product A. The correct behavior would be to have the internal note on only one of them. Steps to reproduce: ------------------- * Setup a PoS restaurant and a preparation display * Open PoS session * Add 1 product A to the order and send it to preparation * Add 1 product A, and add an internal note on it * Send it to preparation > Observation: On the preparation display both product will have the internal note Why the fix: ------------ To fix the issue, when adding an internal note we only add it on the product that hasn't been sent in preparation and split the order line in 2 if necessary. We also take the order line uuid in account when processing the orders in the preparation display to differentiate the line correctly. The behavior should be the following: - If you add a note on a line that has no quantity sent in preparation the note will be on all the quantity - If you add a note on a line that has all quantity sent in preparation the note will be on all the quantity - If you add a note on a line that has a part of the quantity sent in preparation the note will be on the quantity not sent, and the line will be split in 2. One line with already sent, and one with the rest. opw-4000386
1 change
Resolved issues and error corrections
This fix corrects inverted period filter settings in the HR Payroll Dashboard. The "current" period column was incorrectly filtering on previous data, while the "previous" period column had no filter applied. This ensures the dashboard displays the correct financial data for each period.
Original PR description
- Go to Dashboards > Configuration > Dashboards - Open the Human Resources section - Open the payroll dashboard - Open the Period filter configuration panel - the field matching period offset of pivot 3 and 4 are inverted. In the Data sheet, the column named "current" (pivot 3) is filtering on previous, and the one called "previous" (pivot 4) is not filtering on anything. Note that this fix is only active on new databases or if the dashboard is deleted then the module "spreadsheet_dashboard_hr_payroll" is updated. Task: 4056412