Monday, October 20, 2025
5 changes · 17.0
Enhancements to existing features
This update refreshes Luxembourg payroll parameters for 2025, including minimum social salary values and employee tax credit calculations. It helps payroll teams apply the latest official Luxembourg social security and tax rules accurately in salary computations.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf - https://impotsdirects.public.lu/fr/az/c/CIP/cip2025.html - https://impotsdirects.public.lu/fr/az/c/credit-impot-salaries/cis2025.html task-5176255
Resolved issues and error corrections
Fixed an issue in Point of Sale where loyalty points did not refresh when a global discount was applied after selecting a customer. This ensures customers see accurate loyalty rewards without staff needing to remove and re-select them.
Original PR description
In V17, when a global discount was applied to an order after adding the customer, loyalty points were not updated. Steps to reproduce: ------------------- * Open POS. * Select a customer. * Add products to the order. * Apply a global discount. * Check loyalty points → not updated. > Observation: Points are updated if you remove and re-select the customer. Why the fix: ------------ The `add_product` method, called when adding the global discount did not trigger a rewards recalculation. By overriding `add_product` to call `_updateRewards()` after the super call, the loyalty points are now correctly updated in such cases. opw-5072604
The Planning Analysis report now excludes employee time off and public holidays when calculating planned hours. This prevents leave days from being counted as project work, giving managers more accurate planning and timesheet reporting.
Original PR description
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in…
**Description** The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects. **Steps to Reproduce** 1. Create a planning slot for an employee spanning a full month 2. Add employee time-off (resource.calendar.leaves) during that period 4. Navigate to Timesheets > Timesheets / Planning Analysis report 5. Filter by the employee and date range 6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project **Root Cause** The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy. **Solution** Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates. opw-5126359
After users validate their email for e-learning access, outdated validation messages no longer keep reappearing on the website. This avoids confusion and gives users a cleaner confirmation experience without requiring them to log out and back in.
Original PR description
**Description** External users signing up for e-learning courses. They encounter an "account not validated" banner on the website. After clicking the "Validate Account" button in the email, users are…
**Description** External users signing up for e-learning courses. They encounter an "account not validated" banner on the website. After clicking the "Validate Account" button in the email, users are redirected back to the website, and the> 1. **When user validates email**: The system sets `request.session['validation_email_done'] = True` 2. **Template shows banner based on session**: `validation_email_done` from session determines if congratulations banner appears 3. **Session persists but doesn't sync**: Even after user is fully validated, the session flag stays `True` 4. **Page refresh = banner reappears**: Every page reload checks session and shows banner again 5. **Clicking "X" only hides temporarily**: The close button doesn't actually clear the session flag properly **Cause**: When clicking on close button, bootstrap detach `.validated_email_close` alert component from the DOM. When jQuery should call `_onCloseValidatedEmailClick` handler, it finds that `.validated_email_close` is not a child of `.o_wprofile_email_validation_container` so it ignores the event. **Fix**: Check that the event target was `.validated_email_close` inside `_onCloseValidatedEmailClick` instead of using delegation. **Result**: The congratulations banner shows once after validation, then automatically disappears forever without requiring logout/login. **Additional issue identified**: After implementing the frontend fix, the `validation_email_sent` banner persists because this session flag is never reset. This creates a new UX issue where users continue to see "verification email sent" messages inappropriately. **Solution**: Clear the `validation_email_sent` flag when email validation succeeds. This ensures proper session state cleanup and prevents stale banner messages. opw-4817084
Mexican global invoices now use the invoice sequence configured for the branch company when one exists. This ensures the CFDI series shown on invoices matches the branch issuing the document, reducing numbering errors and manual corrections.
Original PR description
**Issue description:** When generating a Mexican global invoice (CFDI), the system uses the sequence from the parent company, even when a separate sequence was defined for the branch company.…
**Issue description:** When generating a Mexican global invoice (CFDI), the system uses the sequence from the parent company, even when a separate sequence was defined for the branch company. **FIX:** We first check for a dedicated sequence on the branch company. If it does not exist, we use/create the sequence for the parent company. **Steps to reproduce:** 1. Ensure that `l10n_mx_edi` is installed 2. Create a Mexican company and a branch for it. 3. Create a sequence for the parent company with code = `l10n_mx_global_invoice_cfdi` and set the prefix, or try to generate a global invoice from the parent company to create the sequence automatically (similar to step 6). 4. Create a similar sequence for the branch company (set company = branch), but use a different prefix to distinguish it from the parent company sequence. 5. Using the branch company, create an invoice. 6. From the invoice list view, select the invoice and use the action "Create Global Invoice". 7. Open the invoice and check the CFDI XML. The `Serie` field is incorrectly set to the prefix of the parent company's sequence instead of the branch's sequence. opw-5096687