Saturday, November 30, 2024
4 changes
2 changes
Enhancements to existing features
Payroll payslips now use a more efficient way to retrieve worked-days information, reducing unnecessary database work. This should improve payroll processing performance, especially for companies handling many payslips or country-specific payroll reports.
Original PR description
In the payslip, we have a few inefficient methods to get info on the worked days lines. We should always use the _get_worked_days_line_values method which only does 1 SQL query. Task: 4188372
Planning shifts that span a weekend are now split into more accurate time blocks for flexible and open resources. This prevents incorrect shift times and makes weekend shifts easier to reassign while also improving performance during the split process.
Original PR description
Prior to this commit, a planning slot spanning over a weekend would not get the correct start/end time in the case of flexible resources, since it will try to take the availability of the resource into account. ex: A slot from Sunday 8:00 to Monday 17:00 would be split into two slots - Sunday 8:00 to Sunday 17:00 - Monday 8:00 to Monday 17:00 However, as we do not take working calendars as reference for flexible resource, the expected split should be: - Sunday 8:00 to Sunday 23:59 - Monday 00:00 to Monday 17:00 Additionally: - open slots will also follow the same split as the one for flexible resources. - weekend slots for regular resources will have their start/end time set to 8AM/5PM instead of having empty slots of 0 minutes. This will allow to pass shifts to other flexible resources more easiy. - reduce the number of ORM calls by providing a specific method for the split. task-id: 4074987
2 changes
Resolved issues and error corrections
Loading a new chart of accounts for a company no longer deletes accounting records that are shared with other companies. This prevents one company’s setup changes from accidentally disrupting accounting configurations used elsewhere.
Original PR description
When loading a chart template on a root company, we check whether any journal items have already been created for the company, and if not, we delete the existing accounting configuration before loading the new CoA. However, we must take care in the case of records that are shared between several companies, to just unlink them from the active company, rather than delete them (which would affect other companies as well). This commit fixes that. task-none
Mexican global invoices can now be created from invoices or POS orders in a foreign currency, as long as all selected documents use the same currency. This prevents unnecessary blocking for valid USD or other foreign-currency transactions while still avoiding mixed-currency global invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and switch to Mexican company 2. Create a POS Order or an Invoice in USD 3. Select the Order/Invoice and create a Global Invoice 4. Receive the error: > You can't process orders having a foreign currency. or > You can't process invoices having a foreign currency. ### Explanation: The intended behaviour, blocking multicurrency on Global Invoicing, was explained as an interdiction on foreign currencies. ### Fix reasoning: Intended behaviour is to block the user when all `pos.order` or `account.move` do not have the same `currency_id`. opw-4302180