Yes, you should follow the feature design.
As a reference you can see the Quality Inspection but any other will do.
I chose to log only break times in attendance. For entrepreneurs it is quite interesting when someone always comes half an hour late from the siesta 
Absence in the sense of holidays, trainings etc. must also be planned. Only unexcused absences and illness can only be recorded afterwards. Here it is a question of how to record them. On the one hand, they can be calculated from the difference between expected time and actual attendance. Unfortunately, this is not enough from the employer’s point of view: it makes a big difference whether someone is absent because of illness or without excuse, and in Germany also if the child is ill. I think this should be recorded in a separate model within the module, as it can also be a matter of half days or hours. This is where my current approach is wrong.
Yes, absenses may be recorden on separte model and from your explanation I deduce that some absense type should be approved and others not.
What I mean is that on the attendance report we may also include the absense time of the worker. This way the manager will easly see that someboddy did not log any attendance because it has an absense record (authorized or not)
yep - got it. I think there is no need to approve - is self explaining by names. We can not know on an generic way what are the consequences of each possible type of absence.
Yes, eg the absense-status “ill” won’t be approved in advance, but (as I think about it) it could be a feature, to assure that the employee turned in a doctors statement.
And yes, the report shows (at least) one row per day, so every day is transparent to management and employee.
Our attendance-modul does record/report all of this already (but it is all retrospective): attendance-time, flexible types of absences: breaks, vacation, hours-off, time-to-reduce-overtime, parental leave, ill, trainings … whatever. We although keep track of not-taken-days of vacation up to the end of year planned. Our “tarif-modell” will define/check, how the attendance-time has to be handled: flexible (eg the employee has the option to start working sometime between 7 and 9 am) or restrictive (eg shift starts at 8 am, if someone shows up earlier, the attendance-time will “skip” the time before 8 am). Moreover we may define different attendance-targets on eg Tuesday, like 9 hours … Our tarif-model although tracks the rules for different overtimes/supplements (eg evening(eg19-21pm), night(eg21pm-6am, weekend, Sunday or combinations of that)). Not to forget flexible holidays … At the end of the month every employee gets a nice report. Still todo on our side: Change-request still have to be sent “Off”-Tryton to the human-resource-lady, so we need a workflow for this. And so far our raspi has to be online, it doesn’t cache rfid-logs. (Don’t ask me if Frederik handled the case of start/ending in different timezones or switch to/off daylight-saving-time or nightshift over midnight, which we luckally not happen to deal with …). Anyway, our module is on live-test with 10 employees for nearly a year now and we hope to make the role-out within the next 3 month.
For the Off-Time-Request/Approval-Module too come, we only look in the future. Imho the only dependancies for module are: The current vacation-status Taken/Requested/Approved/Not-Taken, the local holidays, and the “work-plan-modul” to come. Keeping in mind special off-times, like: to reduce the overtime collected “abbummeln”. Or trainings which are requested by an employee (resticted up to eg 5 days/a) being not vacation but treated analog.
I see this different (hope I understood you right): We need to know and keep in mind all and every special cases of absenses - I tell you from my expierience over the last 5 years working with a different external software for this department. And one thing for sure: The employees will check their report for minutes! My last discussion (believe it or not) was the rounding of seconds to minutes (the monthly report showed seconds on a daily basis, but not in the monthly sum 
We give the option to report brakes. But in general we use (as wishes by the customer) the offical “brake”-rule by autimation: After 6h work you must take 30 min off, after 9h another 15min. So, if someone is working just 6h20min 20min are calculated as brake. If someone takes 3 brakes (input manually) a day (what happend) not only the system but oneself gets crasy
The rule is included in my scheme and used to generate the forecast. But also I record the real live.
We plan to start working on a resource planning module and will have another look at Jan’s work. But before we get started, I’ld like to ask for your proposals. To manage the schedules and events we would like store these in ical-like objects (GnuHealth contains one). Single events do not cause any trouble (goocalendar), the topic we are discussing is the handling of recurrent events (with exceptions). “dateutils” is a library able to handle these recurrent/exeptional events.
Decision Question
To match resources we have to query on busy/free slots also within recurrent events, we ask ourself, what might be better:
(1) to create real event-instances for each event within recurrent (ical-like) event within the database for a limited period (e.g. by the end of next year) or
(2) to work with “virtual” event-instances as views to match
I will sugest having a look at ical · PyPI
I’ve used such library on the past to export calendars to a .ics file (which can be read by any calendar software) and it works like a charm.
For me it depends if you want to get track of what is done or not.
If you want to explicitly say that the employee has done some work you must create the planning record so the employee can update its state latter.