Saturday, May 4, 2024
5 changes · saas-17.1
Resolved issues and error corrections
This change prevents an internal company car flag from influencing Belgian salary package and payroll calculations. It keeps compensation and fleet-related payroll results consistent now that the flag is only used for technical tracking.
Original PR description
Following cleanup of #enterprise/61262, we neutralize the field new_car completely since this is now a technical field, it should not affect any computation anymore
Miscellaneous changes
This PR addresses two issues related to creating repair orders from return transfers: ### The First issue: Steps to reproduce the issue: - Activate `is_repairable` option on any picking type, let's say "Receipts" - Create a delivery order with any product(s). - Validate it. - Return it. - Validate the generated receipt transfer. - From the generated receipt, click on "Repair" button on the top. - Fill the required fields of the repair order and confirm it. - Add any part (`stock.move
Original PR description
This PR addresses two issues related to creating repair orders from return transfers: ### The First issue: Steps to reproduce the issue: - Activate `is_repairable` option on any picking type, let's…
This PR addresses two issues related to creating repair orders from return transfers: ### The First issue: Steps to reproduce the issue: - Activate `is_repairable` option on any picking type, let's say "Receipts" - Create a delivery order with any product(s). - Validate it. - Return it. - Validate the generated receipt transfer. - From the generated receipt, click on "Repair" button on the top. - Fill the required fields of the repair order and confirm it. - Add any part (`stock.move`) to the repair order. Expected behavior: - The new `stock.move` is created and the availability is determined based on quantities in stock. Current behavior: - The created `stock.move` is not only attached to the repair order, but is also attached to the related return transfer. - Since the return transfer may be done, no stock move lines are assigned to the newly linked move, which affects the availability making it unavailable. - This availablity status also affects the repair order making it unable to reserve any quantity for its parts. The issue is because clicking on "Repair" button from `stock.picking` form, adds `default_picking_id` to the context variable to be used on the `repair.order` form. When creating stock moves from the repair order form, the `default_picking_id` key in the context is propagated and used to link the new move to a picking, hence, leading to this undesired behavior. ### The Second Issue: Steps to reproduce the issue: - Create a delivery order. - Validate it. - Return it. - Without navigating to another page, validate the generated receipt order. - Click on "Repair" button. - Select any product on the RO form. Expected behavior: - Form is saved and the repair order is created. Current behavior: - Validation error shows: "A mandatory field is not set", `parts_location_id`. The issue is caused by `default_picking_type_id` key that exists in the context variable when a return order is created from another transfer. This variable propagates to the creation of the repair order and is used instead of the correct picking type which is "Repairs" in that case. Task-3877625 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164385 Forward-Port-Of: odoo/odoo#162452
The fixed test only passed in April as it hardcoded the date of the date filter that was toggled. This commit patches the date to simulate that we're on April. 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#164291
Original PR description
The fixed test only passed in April as it hardcoded the date of the date filter that was toggled. This commit patches the date to simulate that we're on April. 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#164291
Order changes are sent to the preparation display before printing the receipt. This slows down the workflow as users have to wait for other requests to finish before the receipt is printed when a preparation display is connected. opw-3756416 Forward-Port-Of: odoo/enterprise#60441
Original PR description
Order changes are sent to the preparation display before printing the receipt. This slows down the workflow as users have to wait for other requests to finish before the receipt is printed when a preparation display is connected. opw-3756416 Forward-Port-Of: odoo/enterprise#60441
Remove unwanted matches of POS orders that have already been invoiced Also, speed improves if max of orders is invoiced. taskid: 3906396 Forward-Port-Of: odoo/enterprise#61865
Original PR description
Remove unwanted matches of POS orders that have already been invoiced Also, speed improves if max of orders is invoiced. taskid: 3906396 Forward-Port-Of: odoo/enterprise#61865