Wednesday, September 11, 2024
4 changes · saas-17.2
Resolved issues and error corrections
Credit notes for vendor bills linked to a project are now treated as negative costs in the project profitability view. This prevents reversed bills from incorrectly increasing project costs and gives users a more accurate profitability picture.
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Enable analytic accounting; 2. create a project with a new analytic account; 3. create a purchase order with a line linked to the analytic account; 4. confirm order; 5. create bill, add bill date, confirm bill; 6. click the "Credit Note" button; 7. confirm the credit note to reverse the bill; 8. go to project profitability panel. Issue ----- Instead of reversing the project's costs, the credit note doubled them. Cause ----- Commit 9c14dfdf2302 changed the retrieval of profitability costs from purchase orders to vendor bills. In doing so, it assumed each move line's listed amount to be a cost. Solution -------- If the line has `is_refund` set, multiply the cost by -1. opw-4100220
Kitchen receipts in Point of Sale now handle very long product names without text overlapping other lines. This keeps order preparation tickets readable for restaurant staff and reduces confusion in the kitchen.
Original PR description
When printing order changes that contains a product with a really long name, the product name would overlap on the kitchen receipt. Steps to reproduce: ------------------- * Modify the name of a product so that it is really long * Setup a kitchen printer on a PoS restaurant * Add some product on an order and send the order in preparation > Observation: The kitchen receipt has overlapping lines Why the fix: ------------ We make sure to hide the overflowing text so that it is not overlapping on other lines. opw-4136775 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from getting stuck repeatedly switching between list and form screens after a network or session error. Instead of looping endlessly, the system now shows the error clearly when there is no previous screen to return to, improving stability and reducing user confusion.
Original PR description
Go to a kanban view (directly from a menu, s.t. it's the first item in the breadcrumb), open a record. Simulate a global network error (connection loss, server down, outdated session...). For…
Go to a kanban view (directly from a menu, s.t. it's the first item in the breadcrumb), open a record. Simulate a global network error (connection loss, server down, outdated session...). For instance, remove the session_id cookie. Click on the breadcrumb to go back to kanban. Before this commit, this caused an infinite loop of reloading the kanban and the form views. When the first rpc error occurs, we land into the onError handler in the action service. We detect that we are trying to restore a controller from the stack, which crashes. At that point, we would like to restore the controller which appears before the faulty one in the stack. In our case, there's no such controller (we are the first one). So we reach the other part of the error handling, which concerns controllers that are not yet in the stack. For that case, we try to restore the last controller of the stack (the form view). This one fails as well, so we land again in the onError handler, for a controller that is already in the stack, but not the first one this time. So we try to restore the one before it (the kanban), which fails, and so on. The issue has been introduced in [1], where we simply forgot to handle the case where the faulty controller is the first one of the stack, and that's exactly what we do in this commit. In that case, there's nothing to do but display the error (there's no controller to restore). [1] ad35b3069e2efc69b97a283476da4154d49dda8b 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
Manual purchase orders for products received through two-step warehouse routes now record the final stock destination correctly. This prevents incoming purchased goods from being ignored in forecasts and avoids unnecessary extra supplier requests.
Original PR description
Problem --- Using the default 2 steps receipt routes (input -> stock), when we manually create and confirm a purchase order for a storable product, the incoming products are not being taken into…
Problem --- Using the default 2 steps receipt routes (input -> stock), when we manually create and confirm a purchase order for a storable product, the incoming products are not being taken into account for the stock forecast Steps --- * install purchase, mrp, sales_management * In the setting enable multi-step routes, and configure the main warehouse to use the 2 step route. * create a product P: * storable * has a supplier line * route = buy * create a corresponding 0,0 auto buy reordering rule. * create a purchase order for 10 P, confirm it. * => the forecast for the reordering rule is still 0 * create a SO for 10 P and confirm it * => a new RFQ is wrongly generated Cause --- Previously, when using multi step routes, creating a purchase order would create a move for every step of the route, and the destination of the last move of the chain was the main stock. But as of 11e69870db1c49d9a6af79ffd263e4e162b34b6b, we create moves one step at a time, and use `location_final_id` to keep track of the eventual destination. However, in purchase when creating the moves for a manual PO, we do not set this location. So the forecast doesn't take the move into account, as its destination is not the stock but the input. opw-4033857