Defining employee costs per category

Rational

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.

Implementation

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.

I still do not buy it. So an employee at the same position (which is common, not everybody ends CEO) will have the same wage until his retirement?

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.

Also this should be an optional module.

Ok, I just updated the naming.

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.

Salary does not depend on only on skills.

IYAI we implemented employee profiles long time ago.

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.

I’ve filled Issue 11862: Add salary scale to employees - Tryton issue tracker which implements this

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 :pray:) 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.

Hi @edbo

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.

Great, lets abandone it as we now resolved the confusion.

Irony mode off: So what will be the right name? Is salary Scale the right name? Or we should use another one?

All such conventions that you agreed with yourself should be documented somewhere so others can follow them and we will avoid such big confusions.

It is just the list price of work.

It is strange to call list price to “cost price” of the employee. We are talking about employee costs per category.

Are you proposing to rename also the current “Cost prices” field into list price?
And what about the category? We use them “List Price Category”?

This makes no sense following the naming convention.