Daily updates from Odoo
Thursday, December 26, 2024
2 changes · 17.0
Resolved issues and error corrections
This update fixes an issue where the kitchen display incorrectly reduced quantities after a POS order change. Now, the system prioritizes quantity reductions based on the display line's current stage, ensuring accurate updates in the kitchen preparation view. This improves order fulfillment efficiency.
Original PR description
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line…
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage). Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines. Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. opw-4354093
This update simplifies the process of generating credit notes (CN) and debit notes (DN) in Uruguay. By removing a previous requirement for accepted original documents, users can now create credit notes immediately after invoice errors, and generate CN/DNs even when the original invoice was created with different software. This streamlines workflows and reduces delays.
Original PR description
We delete a constraint that requires to have an accepted original document in order to be able to generate CN or DN. This is not actually needed: 1. if there is a problem with the original document then DGI response will let us know and will reject our DN/CN 2. In the case I create an invoice, and immediately found an error we can now generate the credit note: not need to wait the invoices has been process. They will process together by the cron. 3. For the case that we need to generate DN and CN where the original related document was generate with other sofware (for example a DN or CN from an old invoice genrated in previos sofware provider) without this constraint is possible. LATAM 1301 / ADHOC Ticket 46212