Daily updates from Odoo
Thursday, December 26, 2024
5 changes
1 change
Resolved issues and error corrections
Duplicated shifts in Planning now recalculate allocated hours when assigned to a different employee. This prevents employees with different working schedules from receiving incorrect planned hours, improving schedule accuracy and payroll-related planning data.
Original PR description
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When duplicating a shift and assigning it to another resource, the copy() method is called with the resource_id of the target resource (an employee in this case). But _compute_allocated_hours() is not called so we have to call it explicitly in this case. task-3978590
2 changes
Resolved issues and error corrections
Brazilian customers can now properly choose a city when adding or editing a delivery address during checkout. This prevents checkout validation errors caused by an empty city list and avoids asking for VAT details where they are not needed for delivery addresses.
Original PR description
In BR localization, when a logged user tries to edit the delivery address during checkout it may occur that the city field is missing the selection list, causing the form to always return a validation error Steps to reproduce (with a BR company setup) - In Website > Configuration > Settings, set BR company as owner of website - Log in as new user - Add an item to the cart - Go to checkout and add all the address info - In the addresses selection page, uncheck 'Same as delivery address' and add a new delivery address Issue: City selection list will be empty This occurs because, when user is editing the delivery address without 'Save as delivery address' the system won't provide the city list. Moreover it will attempt to validate VAT info (fields `vat` and `l10n_latam_identification_type_id`) for delivery addresses opw-4411470
Italian Point of Sale now relies on standard accounting tax calculations so it better matches fiscal printer totals when products are sold with tax included. Businesses using Italian POS should configure tax-included pricing, with a pricelist and fiscal position workaround available for tax-excluded catalog prices.
Original PR description
Remove patches around tax calculations. Use the accounting calculations natively. As a result, there will be a limitation to use the `l10n_it_pos` properly. The taxes should be price-included when selling products in pos, otherwise, the system's calculations will deviate from the connected fiscal printer's calculations. The accounting team is looking for a native solution to make the fiscal printer work with price-excluded taxes. A workaround for the limitation is to introduce pricelist and fiscal position. The pricelist maps the originally tax-excluded price to tax-included price, and the fiscal position maps the price-excluded tax to price-included equivalent.
2 changes
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