openerp-expert-service team mailing list archive
-
openerp-expert-service team
-
Mailing list archive
-
Message #00053
HR resources allocations wonders: should resource template be a resource.resource or a product.product?
Dear OpenERP service experts (and specially Olivier Dony which Fabien
pointed to when I was asking about the project_long_term refactoring),
For some customers selling engineering projects (civil, mechanic,
software...), *we use to allocate HR resource by project phase*. That
allocation can eventually derivate from project task allocation or just be
a plain time base allocation on the phase.
Also, those guys tend to have a *complex quotation process where quotes are
derived from the draft project until the project is sold*. The basics of
this is managed by the *base_project_costing* module from Akretion (while
OpenERP itself is more focused on deriving tasks from quotes), but it
receives many extension depending on the exact business logic.
Here is my doubt:
*during that project quotation phase, the project manager or the salesman
uses to allocate GENERIC resource on a phase or task*. *This is only at the
time the project or even the phase actually starts that we allocate
specific users or employees. In the following I'll present the 2 options
I'm hesitating between in how I model those generic resource templates.*
So we need to have "resource templates" en specific resource belonging to
those templates.
example: I allocate 8 days of "electrician resource" and when the project
starts I allocate John Doe as the specific electrician to work.
*OpenERP Context:*
In 6.0, by default the specific HR allocation would have been an employee
(hr.employee). This was causing major headaches to maintain users and
employees data (like HR manager need to be admin to create a user) and
users had to be used because later hr.attendances would be user based. In
any case the OpenERP client (web or GTK) also knows the current logged
user, not the employee, meaning filtering of personal tasks, phases,
allocations, attendances would work a lot better using the res.users object
instead of of an hr.employee.
In 6.1, the project_long_term module is one of those that received the most
refactoring and despite it's not used at all, resource allocation on phase
is now user based instead of resource (via hr.employee based).
So be it, I can understand that move.
*Now, I still need to solve my template resource issue:*
Also, because it will be sold, a resource template also better point to a
product at some point.
Because on v6.0 it was already too much headache to maintain the re.users
and the hr.employees, *I ended up modelling that a resource template would
be a product.product object*. Then a hr.employee would point to a product
and the rights specific resource would have to be allocated when the
project starts. That did the job but certainly lacks of universality and as
you can deduce, it would mach well the new res.users based allocation
refactoring of 6.1.
Moreover, In the 6.1 demo data, you can see some generic HR resource
modeled as resource.resource objects, like "analyst" or "developer".
So in fact you are now telling the a generic resource is a
"resource.resource" object?
So now, resource.resource objects are both such generic resource AND ALSO
specific employee resources (via inheritance because hr.employee inherits
resource.resource) that are however used nowhere (both).
*Question 1*: is it by accident or are you serious about that?
I should say that at some point I can understand that model: in fact is was
the very first model I adopted in 2010 on 6.0 but moved to modelling HR
resource templates as products because it was to much different kind of
data/level of indirection to maintain for the HR/project manager folks.
But because on 6.1 you are saving us some trouble on the specific resource
allocation (which is now a res.users), I could imagine to re-introduce some
complexity here eventually.
*Suggestion*: so eventually I would say: a resource model like
"electrician" is a resource.resource object. Then every user can point to a
some of those resource model (what user can do in the company) and if
ever instantiated, the hr.employee could be related to to those resource
templates via the related hr.employee res.users instance. Also, to be sold
efficiently, those resource.resource instances would point to a product
with appropriate sale and cost prices, taxes...
One of the expected benefit of such a more complex model would be in the
future to be able to be smarter about the resource availability and load.
Indeed, I believe OpenERP will end up coming with features to monitor the
availability and load of specific resources over a given time period (there
is actually some piece of such features even in 6.1 even if today
allocating some res.users on a phase won't book any matching hr.employee
resource). Or else let's better admit now that the resource.resource object
would just be totally useless and especially the fact the hr.employee
inherits it.
Now, one could be interested in monitoring both the availability and load
of specific resources (like electrician John Doe) but also of the generic
resources like "electrician" in general.
In the future would could even imagine to make a more sophisticated system
where the availability of generic resource is derivated from the users or
employees matching the skills and take their specific planned allocations
into account.
*So, Am I correct to imagine that a resource template should be a
resource.resource object (eventually pointing to a product and with users
or employees pointing at resource templates) or those demo data are only
here by accident and that would be a dangerous overkill choice that OpenERP
SA would not never endorse in the future?* (in that case I could stick with
simpler models like the template to be the product directly).
Please could you confirm that I'm not going in a wrong direction here? Or
please give your view else.
Thank you and happy 2012!
--
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com
Follow ups