We did not have any model to define departments (as we did not need for any module). So we should start by thinking hoq to define such and where they should be used.
It is important if you want to manage both employees and also freenlancers because the latter will mean that properties should be defined on all parties, but if you want to support just for employees it can be added on employee level.
For me this should be a separate module as it may be used without the work planning, and its quite common. So I will probably start by designing such module and latter the demmand planning you have.
Hi Sergi, I guess, you are very right to split it in two modules.
My idea is to pay b2ck/Cedric to develop an “offical” module for work planning. Even so, we just need it for a single customer, it should attract Tryton from a human resource perspective.
It would be great if Cedric and you (vacation-request-workflow) could clear in advance that both modules work together smoothly.
I’d be happy to find some more people - hoping to get some more ideas/support on this module.
It generates planned dates based on predefined schemes, so you know how many “men hours” are available at each day.
I restart working on this module, because it was not very helpful in real world usage. It is missing grouping of teams/workspace/skills. I need to cluster the available hours by such a superordinate property because its useless to know, that there are 20 people available for 8h on a date if they are half carpenter and the other half locksmith
I did not have reviewed this code since two years, but I think that even an unfinished train of thought can help us to think further.
I think a kind of free tagging by skill would be nice. In another system, for example, I have seen subdivisions into apprentice, journeyman and foreman, who were then assigned percentages of how much they can really contribute to the work. For example, apprentice 20%, journeyman 100%, but master craftsman only 70% because he is busy with planning.
I have hardcoded reasons
[(‘work’, ‘Worktime’),
(‘holiday’, ‘Holiday’),
(‘training’, ‘Training’),
(‘sickness’, ‘Sickness’),
(‘sickness_child’, ‘Sickness Child’),
(‘overtime’, ‘Overtime’),
(‘missing’, ‘Missing’)]
this should be configurable, but filled with sensible default values on installation
I was using a tree with colors. If I remember right I used the calendar view of tryton as well.
… and because I did not know which model then contains the planned time (project or sales, for example), you have to specify in the configuration which field on which model contains the time already booked on a date.
Yes, this must be flexible. Actually we have a developed a “attendance time module” (incl. a raspi-hardware with RFID-reader), this module already has personal data like weekly-working-hours, days-of-vacation, how-many-hours-per-workday, … we call it “tarif-modells”, so not each employee has to be cared for induvitually …
At the time, I decided to handle it in only one module. One can plan all other reasons that are not “work” in advance for certain employees (holiday planning, etc.).
If you then use largely prefabricated working time schemas to plan future time periods, these times are already blocked and ignored.
Changes that occur at short notice and unplanned (absences, illness) are then only entered subsequently and are more of a protocolary use.
So, how should we appraoch? … review Jan’s code and improve it … or starting new from scratch? As I said, I’ll be happy to see it become a core module.
Additionally, we don’t really have time to work on it by ourselfs.
I called it WorkTimeModel - one example is “Alternating shift” (Wechselschicht). So you can define a lot of WorkTimeModels with many different schemes, combine them or put them away for a time (seasonal fluctuations)
So one uses a schema to automatically generate the ideal planning for a certain period in the future. If you have already planned public holidays, personal holidays or training courses, these days are ignored while generating. After you have fired the wizard, the result is displayed and you can of course make changes.
I’m missing the link with the current timesheet module. How does that compare to this and where will it fit in? The timesheet module at the moment is a “sheet with times for a workaction”. However it can be extended to be a “sheet of times for a week” or a month if you want. That sheet will have all the timesheet lines for a user for that week.
This can be added to the “sheet of times for a week”. A user adds the times if it is work or vacation etc and then ask for approval. The supervisor checks the times and confirms it. At that time the timesheet lines are readonly. For each off-time there can be a “sheet with times for a workaction” created eventually.
Review, improve or starting a new results in the same - but we should possibly decide who is the leader of development for the moment. Maybe a small team working on it because it needs the functionality now? In my opinion, there are things where there is no right or wrong, but only the result that one side has finally prevailed It would be good for me to know where the journey is going so that I can decide whether to continue on my path or save myself the time. At the moment, I’m not really in a hurry and for once I would have the time to join in the discussion. How is it with you?
If you have planned 40 hours with an employee, it is one thing to know how much of this time he was actually there (retrospective). For this I have a simple “come, take a break, leave”-model. If you manage to plan all future times (with the timesheet model), that’s nice and possible - but practice has shown me that recording attendance and precisely planning work are completely different areas. I think this has to be decided individually in each company. For this purpose, I have made it configurable which field on which model contains the already planned time for the purpose of planning (could be packing shipments, do production, handling sales, making projects with all the possible modules) - not for subsequent evaluation.
Actually our attandance-modulune is done before the timesheet-module came up, so far we didn’t have the time to integrate/migrate. - Thats why I’m interested in building a new core module for work planning, (beside strengthen the framework) - not ending up in doing this migration-work someday later.
We do this for the “collected times”, but off-time is (often? - at least in our case) handled different: first step a very rough planning (everybody puts in personal “wishes” (about in Dec./Jan. for the whole year) without approval. If the rough planning is fine 4-8 weeks before vacation is requested for approval. If the rough planning doesn’t work, there are talks for adjustments. Moreover (in our case) the approval is 2-step (one by the workgroup leader, one by the human-resource-manager). The human resource manager told me, that if they make the restrictive planning right away (what they did years ago) it often ended in a mess, because a good amount of people changed for some reason their vacation plans … So with this solution management and employees go along much better.
If you want it to be a core module we should start by having a desing that fits the needs.
Also splitting the desings and developments helps advancing as we go step by step (but without loosing the big picture).
An attendance module already existig in tryton. So you should consider using it. Indeed we should probablyt think on integratting the time-off with the attendance.
This can be managed by tryton button rules. So we can design it a single step and add the rule that requires two differnent people the approbal.
