Monday, March 10, 2025
3 changes · saas-17.4
Resolved issues and error corrections
Working schedules now calculate average daily hours correctly even when schedule lines have start and end dates. This prevents the average from incorrectly showing as zero, helping businesses rely on accurate planning and workload information.
Original PR description
### Steps to reproduce: - Go to Working schedule - Add the starting and ending dates for each line - Notice that the average hours per day will become 0 ### Cause: When computing 'hours_per_day' we are fetching the attendances sum all their duration and divide them by their count. When fetching those attendances we are filtering them on some conditions one of those is not getting the attendance line if it has start and end dates. https://github.com/odoo/odoo/blob/74784c26b7cfcea13e75b2939f377521aa40a492/addons/resource/models/resource_calendar.py#L164-L168 ### Fix: As per discussed with GMF it is better to remove the date condition. opw-4471522
Paid restaurant orders can now have receipts printed correctly when Saudi Arabia PoS localization is installed. This prevents errors or silent failures at receipt printing, helping staff provide receipts reliably after payment.
Original PR description
Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This…
Prior to this commit, attempting to print a receipt for a paid order in the PoS restaurant with l10n_sa_pos installed resulted in an error. In later versions, the process would fail silently. This error occurred because the getReceiptHeaderData method in the PoS restaurant used ‘this.get_order()’ to retrieve the order, which is not applicable for paid orders. The order is now passed as an argument to the getReceiptHeaderData function, allowing it to be used when assigning the is_settlement field. This was actually resolved in PR: #145252 but was accidentally reverted during this PR: #142566 Current behavior before PR - In saas-17.4, we get a traceback for the is_settlement field In 18.0+ it will silently fail Desired behavior after PR: Print the order Steps to reproduce: 1.) Install point_of_sale; pos_restaurant; l10n_sa_pos; 2.) This should have created a company 'SA Company' with the country code of 'SA', currency of 'SAR', country_id of Saudi Arabia. If not create one and activate it. 3.) Create a Restaurant point of sale shop 4.) Create a sale > validate so we had orders in the 'Paid' state 5.) Ensure no table is selected 6.) Navigate to orders > filter 'Paid' 7.) Select a paid order and 'Print Receipt' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resetting an invoice to draft with audit trail enabled now handles deferred entries correctly. Deferred entries that were never posted are deleted instead of being reversed, preventing extra pending entries from remaining in accounting records.
Original PR description
Steps to reproduce: - 1. Activate audit trail. 2. Make a customer invoice with start and end date [end date should be in future months], and post. 3. Reset the invoice to draft - Result: All deferred entries are reversed with new entries at the date of the reset to draft. The unposted deferred entries are still there with auto post At Date. Cause: - Audit trail alone doesn't prevent the moves from being deleted if they were not posted before, so the check shouldn't be only on the company_id.check_account_audit_trail, but also we should consider move.posted_before and if not, it should be deleted not reversed. Fix: - Replace the company_id.check_account_audit_trail check with _is_protected_by_audit_trail() which includes checking if the move is posted before or not. opw - 4562732