Then I do not understand what you are proposing here:
Is this message that makes no sense? Or what is the issue here?
P.S: If you do not want to have such feature just say it clear instead of making useless loops on the discussion. As you are our Project Leader you can just decide that without any argumentation.
Why abandon (should Add a document on stock consignment then also be abandoned because it is for now confusing)? The text of the proposal has to be improved so it makes everything clear. Maybe it’s a good improvement to let a native English speaker read the text and suggest changes / improvements.
I’m leaning toward ‘group’ because we are talking about a the cost price for a group of employees. So on company.employee you get a many2one field called cost_price_group and when calculating the cost price for an employee, it will look if the group is filled and take that cost price instead of the one on the employee itself. Also it should be made impossible to have both filled. So if one is filled the other will be readonly.
I would name the new model company.employee.cost_price_group or something like that. That model should also have the possibility to add new cost_prices by date like you now can do per employee.
Looking at the timesheet_cost module I would expect that this can be added directly into the module instead of creating a new one.
Because all the comment below are a complete mess following the misunderstanding.
I prefer to have a new proposal on which every can contribute using the proper wording.
But I still think people are not talking about the same concept because I still see the word “cost” used.
If this is the subject:
Then it is not a cost because it is not a cost for the company, it is a revenue. And this has nothing to do with the cost price field on employee.
What are we talking here is that the hourly cost of the employee to be used on the timesheet_cost module (and so as part as project cost when timesheet cost).
My initial proposal was to use “Employee Category”, but I’m also happy with “Employee Cost Category” or even “Employee Cost Group”.
Once we agree on a name, I do not think it will be very complex to have an implementation for it. I even have a MR for it which is also stalled probably because of the same missunderstading
Why are we making this so complicated? Cmon’ the feature can be just explained in two sentences:
Then I do not understand why you agree with Defining employee costs per category - #14 by edbo which is different than what you are saying here.
I really can not understand.
I think @edbo and me are having the same understanding as its sentences clearly describes our needs.
But it seems you understand something else. As far as you do not explain what you understand I can not say if we are having the same understanding or we are understanding something else.
So please, explain yourself so we can tell if we are on the same path or we are just saying something else.
What are the diferences that you see?
Nor we can understand you if you do not give more information.
This statement is clear. And this is not a cost for the company because it is for the customer. So it is a revenue for the company.
Just like a sale for the company is a purchase for the customer.
There is no Tryton feature to charge a company for the cost of an exact employee. We only charge for the list price of a task, which is never related to an employee. Or what feature are you talking about?
So I do not agree with the following concept:
It is not the cost the customer is charged with, but the cost the company is counting as estimation for the time spent by the employee of such category. I already explained that:
Are we understanding each other now? Or do you need some more clarifications?
Sorry for the confusion, looked a bit deeper and indeed
The proposal is that you want to have groups of employees who has the same cost price. So in larger companies only the cost_price of the group has to be changed and not each employee individually. It’s basically an extension what there is now already.
This has still nothing to do with salary or salary scales, just a more easy way to manage cost prices of employees.
So I would stay with ‘group’ instead of ‘category’ because ‘category’ assumes more like skill or position in the company.
Indeed “salary” is not a good name because the cost of employee is more than salary. And scale it probably to limiting as design.
It may probably look more like user_role module. But there is an additional difficulty to deal with the cost price history. How should it evolve when an employee changes of group? What date should be used for an employee added to a group?
Or maybe the group should not be keeping any cost price information, but there will be just a wizard to update the cost price of a set of employee, a little bit like product.modify_cost_price. And maybe there is no need for a group.
Well I think we are doing some progress and you are starting to understand our need here. 
I don’t think an employee should have multiple categories, but just the current one.
I’m not sure if most companies need to manage the history, but if they need the can just activate the history feature on the models and the cost will be correctly computed.
It will just make it more complex as the user will not know which employees are in each group. So it may update the price of other employees. So for me this is just adding more complexity to the user when we can directly show it.
This is not optional because it is the core module.
So my proposal is:
Many2One from employee to its category. So each employee can just be in a single category in time.This keeps the solution easy from the UX and keeps the code simple.
For those how need to compute the cost price of an employee in the past based on their category, they just activate the _history flag on the employee so all the category history is stored on the system.
If you think this is crucial, we can just activate the _history and we have all the history data.
Do you have any better proposal?
This is wrong as this is not what exists. Please consider existing and released code when making a proposal.
If you have groups of employees you can just select a group and update the cost price using the wizard. This will then update the cost price on each employee. Just add a button on the group view so a user can easily update the cost price, I like the idea. It’s just a small extension of the current system and because you are using the same cost price calculation as it is now, no need to do weird things.
The only difficulty is what to do when moving an employee from one group to another. Run the wizard automatically or do a check on the write function.
I think there is some missunderstanding here. Could you clarify which code are you talking about?
Another option which I may think interresting is to store the date where the employee joined the group and if changed update it to new date and store the group price as employee price for the past. But not sure if it’s worth the effort.
Well assuming this will be added to the timesheet_cost module, there is a table company.employee_cost_price which stores the cost price for the employee and creates a history of the cost price.
And rethinking the whole thing, the cost price must also be on the group otherwise there is no possibility to get the cost price for that group. I see a few scenarios:
employee model, it will automatically do update the cost price based on the group and adds a new entry in the company.employee_cost_price and disables the current entry by setting the end date. Otherwise it should be done by the wizard.UserWarning if you want to set the end date or not for that employee.Maybe the group should be added to the company.employee_cost_price model and on the company.employee it’s a Function field to get the right group.