When computing a salary sheet, a maximum recursion error could happen if there
is a cycle in the rules or in the categories.
Add constrains for salary rules and categories.
Closes#25405
Method `get_day_work_hours_count` can return 0 if no attendance is found
in the calendar. Therefore, we must make sure to not divide by zero,
otherwise, boom boom.
Closes#22900
opw-1815095
The function action_payslip_done has been overwritten in module hr_payroll_account.
Due to this overwrite, the function compute_sheet which creates the payslip lines
was called after the creation of the entries.
Then creating a refund payslip didn't create any entries.
opw:785033
- Create payslip
- Add a contract with any structure
- Add a structure in payslip, different from the one defined in step 2
- Confirm or compute sheet
Payslip is computed using the contract structure, while it should be
computed using the payslip structure.
Closes#21567
opw-787671
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
- Some label improvements
- Make the 'Working Schedule' required on a contract to work well on payslip. If not set, the working hours are not taken into account when computing the payslip, leading to a wage salary equal to 0.
- Add a hr.contract.advantage.template model. This is kind of a meta model to retrieve specific values for given advantages (like lower and upper bounds or default values). Add related views and actions too.
- Only add opened contract by default on a payslip in the onchange_employee_id
- Rewrite some method in new api style (with browse records)
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
The current calculation of work days is inconsistent with the leaves of
the employee in several cases.
The core of the problem is the logic of the algorithm: for a given day,
if we can find one hr_holiday within this day, we consider it as a
leave. One can easily spot several issues with the existing logic:
- if an employee takes less than a day-off (e.g. a half day), the
complete day is considered as a leave.
- the timezone (TZ) is not taken into account when searching for a
leave, while it is when computing the number of working hours. A leave
from 3:00 AM to 3:00 PM in the Los Angeles timezone would then be
considered as two days-off since it spread on two days in UTC.
The logic is therefore completely modified. For each day of the period:
- compute the work intervals (TZ taken into account, converted in UTC)
- search for a hr.holiday which completely includes the work interval
- if a holiday is found, the work interval is considered as a leave.
Otherwise, it is considered as a normal work period.
This is a first step in improving the logic. The first faulty use case
is partially solved, since we cover now complete work intervals.
However, a leave covering only partially a work interval will not be
taken into account.
The second faulty use case is solved.
opw-707897
The domain on the "Payslip Lines" has several consequences:
- Lines are duplicated every time the user clicks on "Compute Sheet"
- Contribution registers that have data are not computed because they
are not visible
- Hidden payslip lines don't go onto accounting entry
We remove the domain, since the purpose of it is to hide the lines in
the payslip of the employee, not hide them in the backend.
Closes#13926Fixes#13925Fixes#13987
opw-694011
PURPOSE
=======
For each and every Hr application there should be one user category (One app = one category).
SPECIFICATION
=============
HR remains as it is : Employee, Officer, Manager
Each Application should have 2 access rights: User and Manager. Example for Recruitment:
- The user has access to the recruitment process
- The manager has access to the job position configuration
Each Application should grant the employee user access right (Namely the 'HR Officer')
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
Swapnesh Shah