When the number of employees grows it is complex to define a cost for each of them.
Normally the company creates a group of employees and defines a cost to all of them.
The group depends on the departement but may also depend on the place to work.
Proposal
Add employee.salary_scale model to define groups of employees. This model should contain a name and active field.
On each employee add a Many2One to employee.salary_scale.
Extend timesheet_cost module to allow defining cost per employee.salary linked to a specific date. and compute the cost based on the category when there is no cost found for the employee.
I do not really buy this. Each employee has a specific contract and evolve differently in the company over time. Some have better wage increase than others.
It is common that the salary is determined by a position type (which is mapped to a category). If the employee salary (and cost) changes when he moves from a category to another.
Of course not, the category will have a cost which evolves in time. So when updating the costs of the category all related employees cost is directly updated.
Exactly the same as we do for employee costs but just creating a new cost for the category and not for all of the employees of such category.
Hum, this can happen but only on specific category of employee like worker or in public service when there is a salary scale.
For me it will be better named salary scale because category of employee are more for workers, managers etc.
We know now that using “empty” list as a “configuration” does not work well. If an employee is linked to a salary scale, his cost should always be taken from there.
Does it make sense to have a checkbox to use costs from salary scale?
Similar to what we have for accounting categories to use parent accounts or taxes
Why? As it related to cost we can just include everyting into employee_cost module.
I do not think as long as salary scale is only for salary (maybe named cost) and that the employee cost is hidden.
Because I think only a fraction of businesses need that. So it is better that the others have not this in the way.
But maybe the code could be factorized if written in employee_cost.
It may be a bit off-topic, but I like the idea of grouping employees by categories, I’m messing with frepple and the concept there is that each employee can have skills and the routing steps can have skills needed. When frepple does the plan, it computes based on the resources available (restricted by skills).
Maybe these groups could be also used for assigning skills (categories) to each employee, so for me each employee can have multiple categories. I’m wondering how the cost can be computed if there are multiple categories by employee.
I know this is discussion for another topic, but I think that affects this in order to have modularity.
This seems the feature that we are requesting, but I see you also have payroll associated to the cost price. But as we do not have any payroll management for now we do plan to manage it.
After reading through this discussion, the issue and the MR, I think there is a misunderstanding. I also was thrown of track when reading the name salary scale. So I read the proposal again and tried to understand it.
Correct me if I’m wrong (please don’t crush me ) but I think:
@pokoli talks about employee costs the customer is charged with
@ced talks about employee costs for the company and the salary of the employee
There are a lot of companies who charge a customer a certain cost per hour and it doesn’t matter in what salary scale that employee exist. Look for example at a production company with a lot of employees.
So creating groups and add a cost price to it with a history like the current employee_cost is a nice thing. Employees can be added to a group and based on that, their cost price can be calculated. When the next year the cost price has to be changed, only the cost price of the group has to be changed and not every single employee.
This is not about HRM or payroll management. Because then you are starting to talk about the individual employee again.
You crushed it. What you describe is exactly what I wanted to implement.
This is exactly the use case our user was requesting. As far as they explained to me it is a common feature that other ERP system (he mentioned SAP IIRC) provide by default.
Whoa! The confusion comes from that in Tryton we always name concepts from the company perspective.
I think this blueprint should be abandoned because it is full confusion.