| Age | Commit message (Collapse) | Author |
|---|
|
For more information about this decision, please read
https://www.odoo.com/fr_FR/blog/notre-blog-5/post/odoo-community-enterprise-532
|
|
We replace contribution register model by a many2one on res.partner
directly on the payslip.line
Task 1928607
|
|
It makes more sense to name an entry in the employee schedule like that.
TaskID: 1941598
|
|
1/ Remove the parent-children relation on salary structures
Currently it is difficult to see what rules are applied on salary structures.
Most of the structures are inheriting 3 rules (Basic, Gross, Net) from the
'Base for new structures', and those rules are not shown. Same issue if a
structure has another one as parent (as in the French localization).
This bring more annoying issues:
- Since the saas-12.1, we can already set different accounts for different
companies on the salary rules for which we want to post journal entries.
But for the parent rules, like the 'NET' amount, it's impossible to post
the journal entries on different account for different salary structures.
(eg: for CP200 employees and CP200 workers). As the rules are following
a M2M relation on the structure, we have to remove the parent_id and to
recreate all the rules in the final structure.
- If we are not at ease with the M2M relation (which is the case for most
of the end users), we will simply modify the rule on the parent structure.
This was already done on the French localization on which we modified the
code, sequence and the name. This could have some desastrous consequences
as this will break the order on which the rules are computed for other
structures for the sequence, or break other integration with the payroll
as we also modify the code, for example the salary configurator.
As this parent-children relation on structure could cause several issues
difficult to spot and as this is quite difficult to correctly visualize the
structure composition, it is better to remove it and define all the rules
inside the structure itself. This improves also the code readability as we
are not trying to recursively retrieve the rules and find a proper sequence
inside them.
2/ Make the rules on the salary structure a o2m instead of a m2m
The issues described just above indicates that it would be better to remove
the M2M relation between salary structures and salary rules, and make it
a O2M relation instead. That way, no more confusion and misconfiguration of
the rules fields (code, sequence, accounts, ...).
3/ Remove the parent-children relation on rules
A salary rule can have a parent salary rule. This mechanism, which is
not obvious at all for an end user allows to specify a parent rules.
If the condition is met for the parent rule (eg: the employee has at least
1 child), all the children rules could be applied (eg: Deduction of 90 euros
if the number of children is between 1 and 1).
Visually it doesn't make a lot of sense, as it displays one line with an
amount of 0 for the parent, and one line with the real amount for each
applied child. On the other hand, no child rule is linked to the structure
and an end user has to click on the parent rule, to see the children and
understand that something mystic and hidden is existing.
This is equivalent to define as many classic rules as we have children, or
even better, define 1 rule that will compute the real amount directly,
as the number of children can be accessed from the localdict when computing
the salary line.
This commit also removed the relation.
4/ Clean some brols in the code (technical)
The 3 first points of the spec allow us to clean a little the code readability
and complexity.
5/ Adapt all the localizations for these changes
All the localizations are impacted by those changes. What is done in this commit
is mainly:
- l10n_be_hr_payroll: Make 3 separated files for the 3 existing structures (the
fourth one, belgian worker, is not correct and is removed). For each
structure, define explicitely the rules (in the correct order by sequence).
This multiplies the total number of rules as some of them were shared (like
the withholding tax rule for example), but all the code that is supposed to be
modified each year/quarter/whenever the government decides to modify the law
has been moved into a python file, and is available the computation context.
This will also allow us to update the computation rules without having to
update the module.
- l10n_fr_hr_payroll: There were 3 rules following this scheme:
Base for new structure
|
Basic structure
|
----------------------
| |
Cadre Non-Cadre
All the rules parent rules have been duplicated into the 2 remaining
structures, cadre and non-cadre. There were a lot of parent-children relations
between the rules that have been adapted to the new model.
- l10n_in_hr_payroll: There was a lot of rules in data, and a structure in demo
data, which was using 4 or 5 of these rules. As the rules doesn't seem to make
a lot of sense altogether, everything was moved in demo data.
6/ Introduce a new Salary Structure Type model
Currently we have a model hr.contract.type with a M2O on the contracts. This has
never been used in 9 years and is removed in this commit. On the other hand, we
would like to define a new model hr.payroll.structure.type (eg: CP200 Employee),
which will line all the salary structures the Belgian localization could bring
(Classic salary, double holidays, 13th month, ...). This field is defined on the
structure, and is displayed on the contract (as the same place than the contract
type we just removed).
On this model we could also define some fields like:
- The default pay period: Selection field, default = monthly. This is applied on
the contract when selecting the structure.
- The Working Schedule, m2o. This is applied on the contract when selecting the
structure
For example, on the 'commission paritaire' for teachers, we could set the
default pay period to 'Every 15 days' and the working schedule to '19 hours /
week'. Every contract under this structure would take those values.
Migration
=========
For a migration point of view:
- All the rules that had a parent_rule_id should be set to
appears_on_payslip=False. The column parent_rule_id can be dropped afterward.
- All the rules that are coming from a parent structure or higher should be
duplicated and the field 'struct_id' should be set on the current structure.
The column parent_id can be dropped afterward.
- All the rules that were defined on the structure should have the field
'struct_id' defined on them.
- The rules that are not linked to a structure should be unlinked.
- The column type_id on the contract could be dropped, no need to keep the
values too.
- A default structure type is defined in data ('Employee'). This could be set to
all the existing structure for the newly created 'type_id' field.
TaskID: 1942832
|
|
Purpose
=======
We need to use an international word to define holidays and leaves, rename everything into Time Off.
Employees needs a good dashboard and leaves summary
Specification
=============
1/ Add a new dashboard: https://balsamiq.cloud/sm5j0d/pg5w04r
Create a new dashboard with a calendar and a summary of all time off and time off request
2/ Rename leaves into Time Off everywhere
3/ Improve general usability
TaskID: 1916871
closes odoo/odoo#29634
|
|
Purpose
=======
Currently the payroll doens't manage the multi company
Specification
=============
1/ Add ir.rules on hr.contract and hr.payslip to prevent users
to access a record in another company.
2/ Add ir.rules on hr.payroll.structure to prevent users to access
a record for another country.
3/ Remove company_id fields on models that doesn't require it, as
hr.salary.rule.category.
4/ Make the accounting fields on the salary rules company dependent.
5/ Specify the country on the salary structures on the
l10n_**_hr_payroll modules.
6/ Add demo data and modify the salary package tour.
7/ Make the car_atn and company_car_total_depreciated_costs fields
compute_sudo=True, as one car can be assigned on several contract,
for different companies
Closes #26866
Closes #25231
Closes #24683
Closes #23814
|
|
Purpose
=======
In order to be able to manage payroll, we need to know if a resource calendar
is a full time or a part time. For instance, in belgium, 23h a week is a full
time for a teacher but in cp 200 it is 38h. In belgium every employee can take a
parental leave in part time but he cannot take it in part time if they are not full time.
Having a field indicating if the contract is full time or not is useful for computing
salary rules.
Specification
=============
On the calendar model
- Display a computed field with the number of hours in the calendar
- Display a field with the required number of hours to be full time
- Display a computed checkbox, ticked if full time or not
On the contract model
- Add a related on these fields, to ease the access on the salary rules computation.
closes odoo/odoo#30034
|
|
Purpose
=======
For payroll purpose, we need to manage attendances.
For instance, someone is working only mondays, tuesdays and fridays, but works exceptionally an other day.
It must be recorded.
Specification
=============
The new models are used to represent attendances, extra hours and leaves (as `hr.benefit`s) in a new window called "Benefits".
The schedule of employees for the full month is visible in that view (calendar view).
First the benefits needs to be generated (via a button) based on the calendar attendances and leaves.
The manager can then check benefits, delete or add some. Only the benefit name and type can be edited (not start and end dates).
Once benefits are correct, they can be validated. Validation will fail if they are some leaves to approve or if some benefits overlap on the same day.
Benefits cannot be deleted or edited once validated.
When benefits are all validated, a button appears to generate payslips.
Closes #28261
|
|
Purpose
=======
Currently the wage reduced by a superior amount of 20 holidays is not taken into account in the brut2net computation.
Specifiation
============
Take also the wage deduction into account
|
|
- 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)
|
|
|
|
splitting)
[FIX] hr_payroll: Fixed wrong decorator.
|
