Arbeitszeit / Zeiterfassung - Gedanken und Modellierung

[KonradN]

Die Einführung von Software unterliegt immer der Mitbestimmung, weil es Rechtsmeinung ist, dass Software immer zur Leistungs- und Verhaltenskontrolle geeignet ist.

Ja, das meinte ich oder besser - sowas in der Art meine ich, in der Vergangenheit schon gehört zu haben. Danke für die Erläuterung.

 

[mrBrown]

Mir ist gerade der Begriff "Snapshot" dafür in der Sinn gekommen. Für die aktuelle Berechnung kann man sich auf den letzten (z. B. monatlich automatisch erstellten) Snapshot beziehen. Im Notfall könnte aber von einem beliebigen, früheren (aus den Rohdaten, ggf. mit Korrekturen) Zeitpunkt (oder Snapshot) gerechnet werden.

Snapshots ist auch der passende Begriff dafür, das ist bei Event-Sourcing eine völlig gängige Praxis. @internet dazu findet man im Internet auch einiges dazu, was hilfreich sein könnte.

 

[AndiE]

@internet ich sehe noch nicht, dass #66 und #74 zusammen funktionieren.

Um noch mal auf mein Beispiel zurückzukommen, Es gibt 20 Arbeitnehmer in der Firma. Jeder von ihnen hat ein Objekt, dass ihn eindeutig identifiziert( Stempelkarte).

Wie soll damit eine Datei Zeit( An-ID,Start, Ende, Arbeitszeit,Pause) gefüllt werden, um deine Idee man etwas abzukürzen.
In #66 hältst du in deinem Modell keine Daten der Form Stechuhr( Zeit, AN-ID, Ereignis).

 

[mrBrown]

@internet ich sehe noch nicht, dass #66 und #74 zusammen funktionieren.

Das haben deshalb ja auch fast alle Beiträge seit #66 zum Thema

 

[temi]

Snapshots ist auch der passende Begriff dafür, das ist bei Event-Sourcing eine völlig gängige Praxis.

Danke für diese Information, das wusste ich nicht. Ich kenne das Prinzip von Event-Sourcing, aber das ist schon alles. Manchmal findet auch ein blindes Huhn mal ein Korn, ich fand einfach den Begriff so schön passend.

 

[mihe7]

Ich tue mir noch schwer, was die Ermittlung des "Gleitzeitkontos" anbelangt.
Prinzipiell ist das ja nur eine Zahl, die sich dynamisch berechnet.
Also möchte ich eine Auswertung von Tag X bis Tag X machen, bekomme ich den Wert des Saldos
-> Was sind die Ist - Stunden & was sind die Soll - Stunden.... Die Differenz ist dann der Gleitzeitsaldo

Ich sehe da kein Problem.

In der Buchhaltung hast Du ein Journal, das sämtliche Buchungssätze aufzeichnet. Außerdem hast Du Konten, die von den Buchungssätzen berührt werden, mindestens insofern als dass sich die Salden ändern.

Nichts anderes passiert hier auch. Die Arbeitszeitkonten werden auf der einen Seite mit den Sollzeiten belastet, auf der anderen mit den Istzeiten. Der aktuelle Saldo ist nichts anderes als der Stand des AZ-Kontos. Die Abrechnung entspricht dann einem Monatsabschluss. Ausgabe für den MA ist nichts anderes als ein Kontoauszug. Mit dem Abschluss können bestimmte Salden vorgetragen werden.

Eine Auswertung vom 15. bis zum 10. wäre dann einfach der Anfangssaldo am 15., gefolgt von den Buchungen bis zum 10., die dann zum Endsaldo führen.

 

[internet]

wie sieht das denn bei den Urlaubstagen eines Mitarbeiters aus?
Gibt es hier auch einen Snapshot pro Monat, wieviele Tage der Mitarbeiter noch zur Verfügung hat?
Es gibt ja so Regeln wie, Urlaub vom Vorjahr muss bis 31.03 zum Beispiel genommen werden?

Hat hier jemand eine Idee?

 

[KonradN]

Kannst Du machen, musst Du aber nicht.
Die Anzahl der Datensätze ist relativ übersichtlich - daher sollte es unproblematisch sein, solche Daten über Abfragen aus den "Rohdaten" zu ermitteln.

Was Sinn machen würde, sind aber Snapshots an Stichtagen. So kann man sowas wie ein Jahresabschluss machen, d.h. es wird ein jahr abgeschlossen und es gibt für das neue Jahr einen klaren Startpunkt mit festen Daten: Wie viel Urlaub hat der Mitarbeiter dieses Jahr? Wie viel Resturlaub gibt es noch u.s.w.

Und die Regeln sind erst einmal egal. Das würde dann einfach dazu führen, dass halt Datensätze hinzu kommen. So ist es ja ein einfaches, den genommenen Urlaub vom 1.1 - 31.3 zu ermitteln. Wenn das weniger Urlaubstage waren als der Mitarbeiter hatte, dann wird die Differenz über einen neuen Eintrag, dass diese Urlaubstage direkt "genommen" wurden, eingetragen.
Solche Eintragungen sind natürlich wichtig. Denn es kann ja auch immer zusätzliche Urlaubstage geben.

 

[internet]

Genau, das meinte ich...
Das Ermitteln der Urlaubstage für ein Jahr ist ja nicht schwierig...

Aber irgendwo muss ja festgehalten werden, wieviel Urlaubstage der Mitarbeiter in das neue Jahr mitnimmt, das würde ich dann ebenfalls anhand einem Snapshot sehen?
Ich bin mir nur noch nicht sicher, was im Snapshot stehen soll?
Ich erstelle zB jeden Monat einen Snapshot.
- Ist es die Anzahl an verbrauchten Urlaubstagen?
- Ist es die Anzahl an Urlaubstage, die noch zur Verfügung stehen?

Beispiel:
Ich speichere am 01.01 den Snapshot für den 31.12.
- Speichere ich dann hier: Anzahl Urlaubstage = 25

Die offenen zu speichern, sehe ich eher problematisch an, denn was ist, wenn der Mitarbeiter in seinem Vertrag zB statt 30 Urlaubstage nun 35 Urlaubstage / Jahr bekommt... Dann stimmen die Snapshots ja nicht mehr, wobei man hier auch diskutieren könnte, denn zu dem damaligen Zeitpunkt hatten die gestimmt.

Dann müsste bpsw. auch noch eine Logik implementiert werden, die prüft, bis wann der Mitarbeiter den Urlaub im neuen Jahr genommen haben werden muss. Das heißt er muss vor dem 31.03. den Urlaub nehmen, die dann vom Konto des restlichen Urlaubsbudget abgezogen wird.

Das Speichern nur der offenen Urlaubstage (im Snapshot) würde es allerdings dann wieder vereinfachen.
Demnach die Frage, was genau muss gespeichert werden? (Offene und verbrauchte) ?

 

[KonradN]

Ich weiss nicht, ob Snapshot wirklich der richtige Name ist. Ich würde das Kalenderjahr als entscheidend ansehen. Dazu gibt es dann halt irgendwelche Datensätze, die angeben, an welchen Tagen ein Mitarbeiter Urlaub hat. Womöglich mit Unterscheidung: Geplant, Beantragt, Freigegeben, Abgelehnt, Genommen.

Dann sollte es Datensätze geben, die das Urlaubskonto beeinflussen:

01.01.2022 "Jahresurlaub" +30
01.01.2022 "Resturlaub 2021" + 13
01.04.2022 "Resturlaub verfallen" -4
01.07.2022 "Zusatztag Tod Mutter" +1
31.09.2022 "Korrektur Urlaub" -7
31.09.2022 "Auszahlung" -14

=> Was für Möglichkeiten es gibt, ist erst einmal etwas, das Du definieren musst. Dazu wirst Du hoffentlich Anforderungen haben.
=> Jede Anpassung sollte Zusätzliche Infos haben, also ggf Kommentar aber evtl. gibt es auch eine Referenz auf einen Beleg oder einen Bearbeiter.
=> Generell betrachte ich immer nur Jahre. Also ich schaue mir die Einträge eines Jahres an und habe dann einfache Summen.

Was ich jetzt hier herum gesponnen habe:
- Der Jahresurlaub muss natürlich einem Mitarbeiter zugewiesen werden.
- Dann gibt es ggf. Resturlaub
- Resturlaub kann verfallen
- Dann ggf. Zusätzliche Tage - die kann man dann auch erfassen ..
- 31.09 hat der Mitarbeiter evtl. die Firma verlassen. 1/4 der Urlaubstage entfallen da er nur 3/4 des Jahres in der Firma war. Und von mir aus hatte er 14 Urlaubstage nicht genommen - die werden dann am Ende noch ausbezahlt.

Das sind aber Gedanken, die muss Du Dir machen. Das ist so problemlos möglich. Aber wenn Du andere Anforderungen hast, dann passt es ggf. nicht.

 

[Meniskusschaden]

wie sieht das denn bei den Urlaubstagen eines Mitarbeiters aus?
Gibt es hier auch einen Snapshot pro Monat, wieviele Tage der Mitarbeiter noch zur Verfügung hat?
Es gibt ja so Regeln wie, Urlaub vom Vorjahr muss bis 31.03 zum Beispiel genommen werden?

Hat hier jemand eine Idee?

Beim Urlaubsanspruch sehe ich erst einmal keine Besonderheiten gegenüber anderen Konten. Ich würde mir da jedenfalls ungern eigene Gedanken machen müssen, sondern versuchen, das für Urlaub, Überstunden, Samstagsbonus, Freischichtzähler, Geschirrspülprämie, ... einheitlich zu lösen. Irgendeinen Mechanismus um Salden vorzutragen, benötigst du ja sowieso (z.B. Snapshots). Andernfalls könntest du keine Altdaten löschen, ohne dass sich die aktuellen Salden verändern.

Eine Möglichkeit könnte sein, das beim Jahresabschluß in Form von Eröffnungsbuchungen in einer eigens vorgesehenen Buchungsperiode 00 abzubilden. Dann gibt es keinen technischen Unterschied zwischen Anfangsbeständen und laufenden Buchungen, so daß man immer nur die Buchungen des betrachteten Jahres auswerten muss.

Ob man (zusätzlich oder stattdessen) Snapshots z.B. als monatliche Summen- und Saldensätze führt, ist dann eine Abwägung von Performance und Komplexität. Da muss man dann auch überlegen, ob man nur die Veränderungen der Periode oder auch den jeweiligen Abschlußsaldo speichern will. Wenn man nur die Veränderungen speichert, hat man den Nachteil, dass man mehrere Snapshots braucht, um einen Saldo zu ermitteln. Wenn man auch die Salden speichert, muss man ggf. mehrere Snapshots aktualisieren, wenn man Korrekturbuchungen in der Vergangenheit erlaubt.

Eine weitere Variante könnte sein, auf Snapshots zu verzichten, Eröffnungsbuchungen vorzusehen und zusätzlich zu den Einzelbuchungen nur die aktuellen Salden zu speichern. Dann bekommt man die (meistens benötigten) aktuellen Daten performant und die (seltener benötigten) Zwischenstände weniger performant.

Was letztendlich das Beste ist, wird von den Anforderungen und Datenvolumina abhängen.

 

[internet]

@KonradN : der Ansatz gefällt mir ganz gut.... Vielen Dank....

Ich würde es wie folgt lösen:
- Neue Entity erstellen:

TimeRecordingAccountEmployee (Name kann man natürlich noch ändern)

private Long id;
private double calculateValue; // Wert, der abgezogen oder hinzugefügt wird
private double currentValue; // Aktueller Wert (also vorheriger Wert -/+ calculateValue)
private LocalDateTime createDate;
private LocalDateTime updateDate;
private Employee employee; // Referenz auf Mitarbeiter

Um verschiedene Konten (nicht nur das Urlaubskonto) abzubilden, könnte man dann noch die Referenz auf eine Kontenart hinzufügen.
Anstatt Kommentar, könnte man ein ENUM nehmen, bei dem dann festdefinierte Werte stecken (Jahresurlaub, Resturlaub...), oder eben beides (Kommentar und Typ)....

Die Einträge kann man dann natürlich nicht mehr verändern oder löschen.
Sollte es noch kein Konto für einen Mitarbeiter geben, muss eben erst ein Eintrag in der TimeRecordingAccountEmployee - Tabele für diesen Mitarbeiter erstellt werden.

Anträge für Urlaube etc. speichere ich sowieso in einer anderen Tabelle.
Ich müsste dann nur je nach Ausführung der Aktion (Freigabe, Stornierung etc.) eben einen weiteren Eintrag dann in die neue Tabelle (TimeRecordingAccountEmployee) hinzufügen... Damit ist alles sauber dokumentiert.

Möchte ich nun den Urlaubsanspruch von einem Mitarbeiter bekommen, rufe ich einfach den letzten Eintrag in der Tabelle ab (currentValue)...
Oder hat jemand andere Ideen?

 

[KonradN]

Möchte ich nun den Urlaubsanspruch von einem Mitarbeiter bekommen, rufe ich einfach den letzten Eintrag in der Tabelle ab (currentValue)...
Oder hat jemand andere Ideen?

Das kann man durchaus so machen. Aber die Information ist zum einen redundant und hat damit generell die "üblichen" Probleme mit Redundanz.

 

[internet]

Das kann man durchaus so machen. Aber die Information ist zum einen redundant und hat damit generell die "üblichen" Probleme mit Redundanz.

warum redundant? wo steht der Wert denn dann noch, außer dass ich mir diesen onthefly kalkuliere?
Vielleicht hatte auch ein entscheidendes Wort gefehlt: Möchte ich nun den aktuellen Urlaubsanspruch (in diesem Kalenderjahr) von einem Mitarbeiter bekommen...

Was dann eben noch dazu kommt, dass je nach Einstellung es einen automatischen Job (Schedule) am Anfang des Jahres (Monat) gibt, der den Übertrag in das neue Kalenderjahr (Periode) macht...

 

[KonradN]

Der Wert des Resturlaubs ist ein Wert, der sich aus den anderen Werten ermitteln lässt. Daher ist die Speicherung erst einmal redundant.

Und typische Probleme sind dann, dass Veränderungen an einem Datensatz alleine dann inkonsistente Zustände herbei führen. Ich lösche einfach einen Datensatz heraus. Du hast also Datensätze wie:
- 5 tage Urlaub im Januar, Resturlaub 25 Tage
- 3 Tage Urlaub im Februar, Resturlaub 22 Tage
- 5 Tage Urlaub im März, Resturlaub 17 Tage

Ups, den Urlaub im Februar hatte ich ja gar nicht genommen! Da war doch dieses riesen Kundenproblem und ich habe die 3 Tage gearbeitet ... dann löschen wir den Datensatz und erhalten dann:
- 5 tage Urlaub im Januar, Resturlaub 25 Tage
- 5 Tage Urlaub im März, Resturlaub 17 Tage

Nur ein einfaches Beispiel. Ich wäre daher relativ offen was die Datenspeicherung angeht. Und ich würde da auf jeden Fall darauf achten, dass Korrekturen einfach sind (die kommen nun einmal vor ist meine Erfahrung! Fehleingaben, nicht zeitig erfolgte Änderungen u.s.w.)

Das geht dennoch alles. Dann gibt es halt Routinen, die alles prüfen. Oder bei einer Anpassung wird auch deutlich mehr geändert. Das erhöht aber vermutlich die Komplexität - und das auf Grund einer solchen Datenstruktur.

Aber wir hatten das Thema ja schon meine Ich. Gewisse Redundanzen machen durchaus Sinn um eben die Berechnung zu vereinfachen. Man will nicht die letzten 30 Jahres des Mitarbeiters durchgehen, wenn es um den Urlaub geht. Zumal da ja auch Urlaub verfällt und so.
Daher bin ich durchaus der Meinung, dass man da am Jahresende / Jahresanfang entsprechende Buchungen haben kann.
Und dann wird immer nur das Jahr betrachtet. Änderungen am Vorjahr sind evtl. auch nicht mehr möglich. (So ist es bei uns - Zeitbuchungen sind immer nur im aktuellen Monat möglich. Am Anfang des nächsten Monats wird der Vormonat geschlossen und ein Monatsabschluss findet statt. Nachträgliche Änderungen gehen dann nur noch mit zusätzlichen Aufwänden (weil dann ggf. auch Berichte angepasst werden müssen - also Dinge, die gar nichts mit der Zeiterfassung zu tun haben!) Aber das muss man dann immer ganz klar so sehen.

Das ist aber einfach nur meine Sicht. Hier ist generell auch eine andere Sicht möglich. Die können auch besser sein - weil es evtl. Anforderungen gibt, die ich schlicht nicht kenne und daher natürlich auch nicht berücksichtige.

Daher ganz klar: Das was Du da machen willst, ist so bestimmt möglich. Aber denk an die Probleme, die durch so eine Redundanz auftreten können!

 

[internet]

Der Wert des Resturlaubs ist ein Wert, der sich aus den anderen Werten ermitteln lässt. Daher ist die Speicherung erst einmal redundant.

Und typische Probleme sind dann, dass Veränderungen an einem Datensatz alleine dann inkonsistente Zustände herbei führen. Ich lösche einfach einen Datensatz heraus. Du hast also Datensätze wie:
- 5 tage Urlaub im Januar, Resturlaub 25 Tage
- 3 Tage Urlaub im Februar, Resturlaub 22 Tage
- 5 Tage Urlaub im März, Resturlaub 17 Tage

Ups, den Urlaub im Februar hatte ich ja gar nicht genommen! Da war doch dieses riesen Kundenproblem und ich habe die 3 Tage gearbeitet ... dann löschen wir den Datensatz und erhalten dann:
- 5 tage Urlaub im Januar, Resturlaub 25 Tage
- 5 Tage Urlaub im März, Resturlaub 17 Tage

Nur ein einfaches Beispiel. Ich wäre daher relativ offen was die Datenspeicherung angeht. Und ich würde da auf jeden Fall darauf achten, dass Korrekturen einfach sind (die kommen nun einmal vor ist meine Erfahrung! Fehleingaben, nicht zeitig erfolgte Änderungen u.s.w.)

Das geht dennoch alles. Dann gibt es halt Routinen, die alles prüfen. Oder bei einer Anpassung wird auch deutlich mehr geändert. Das erhöht aber vermutlich die Komplexität - und das auf Grund einer solchen Datenstruktur.

Aber wir hatten das Thema ja schon meine Ich. Gewisse Redundanzen machen durchaus Sinn um eben die Berechnung zu vereinfachen. Man will nicht die letzten 30 Jahres des Mitarbeiters durchgehen, wenn es um den Urlaub geht. Zumal da ja auch Urlaub verfällt und so.
Daher bin ich durchaus der Meinung, dass man da am Jahresende / Jahresanfang entsprechende Buchungen haben kann.
Und dann wird immer nur das Jahr betrachtet. Änderungen am Vorjahr sind evtl. auch nicht mehr möglich. (So ist es bei uns - Zeitbuchungen sind immer nur im aktuellen Monat möglich. Am Anfang des nächsten Monats wird der Vormonat geschlossen und ein Monatsabschluss findet statt. Nachträgliche Änderungen gehen dann nur noch mit zusätzlichen Aufwänden (weil dann ggf. auch Berichte angepasst werden müssen - also Dinge, die gar nichts mit der Zeiterfassung zu tun haben!) Aber das muss man dann immer ganz klar so sehen.

Das ist aber einfach nur meine Sicht. Hier ist generell auch eine andere Sicht möglich. Die können auch besser sein - weil es evtl. Anforderungen gibt, die ich schlicht nicht kenne und daher natürlich auch nicht berücksichtige.

Daher ganz klar: Das was Du da machen willst, ist so bestimmt möglich. Aber denk an die Probleme, die durch so eine Redundanz auftreten können!

danke... Aber ich würde das einfach umgehen, dass man gar nicht löschen kann.
Klar, könnte man jetzt hart in die Datenbank eingreifen und hier den Datensatz löschen, aber dann hat man m.M. ein ganz anderes Problem...
Ich würde das dann einfach umgehen, sodass man den Urlaub "stornieren" muss, somit hat man eine genaue Transparenz

 

[internet]

Ich habe mir das mal bei einer Software angeschaut, die bereits auf dem Markt ist...
Hier wird das so gemacht, dass es eine Tabelle gibt, in der folgende Infos stehen:

Abrechnungsjahre
- MitarbeiterID
- Jahr
- UrlaubstageAktuell
- UrlaubstageUebertrag
- UrlaubstageVerwendet
- UrlaubstageVerfallen
- UrlaubstageAusbezahlt
- Krankheitstage

Was habt ihr für Meinungen zu diesem Ansatz?

 

[mrBrown]

Ich habe mir das mal bei einer Software angeschaut, die bereits auf dem Markt ist...
Hier wird das so gemacht, dass es eine Tabelle gibt, in der folgende Infos stehen:

Abrechnungsjahre
- MitarbeiterID
- Jahr
- UrlaubstageAktuell
- UrlaubstageUebertrag
- UrlaubstageVerwendet
- UrlaubstageVerfallen
- UrlaubstageAusbezahlt
- Krankheitstage

Was habt ihr für Meinungen zu diesem Ansatz?

Eine Datenbank-Tabelle oder eine Tabelle in der UI?

 

[internet]

Eine Datenbank-Tabelle oder eine Tabelle in der UI?

Eine Datenbank Tabelle

 

[internet]

Eine Datenbank Tabelle

@mrBrown wie ist dann deine Meinung dazu?

 

[mrBrown]

Ist das die einzige Tabelle?

Wenn nein -> Informationen stehen also doppelt in der DB, dann gilt der Punkt von @KonradN
Wenn ja -> WTF?

 

[internet]

Nein, es gibt mehrere Tabellen:

Diese zwei Tabellen dienen wohl als Snapshots:
- Abrechnungsjahre (siehe oben)
- Abrechnungsmonate (ähnliche Struktur wie Abrechnungsjahre, nur eben auf Basis von einem Monat)

Weitere Tabellen (Rohdaten):
- Urlaub (hier wird der Urlaub erfasst)
- Zeiten (Zeiterfassung)

Die Informationen hält man dann natürlich doppelt vor.
Bspw. für den Urlaub:
1x in der Urlaubstabelle

- "UrlaubstageVerwendet" könnte man bpsw. auch anhand einer DB - Query dann herausbekommen. Ich sehe aber schon den Vorteil dies in einer "Snapshot" - Tabelle zu persistieren.
Sobald man einen Urlaub storniert, erstellt etc. - muss eben ebenfalls eine Änderung in der Snapshot - Tabelle i.d.R. erfolgen.
Prinzipiell kann ich mich mit den 2 "Snapshot" - Tabellen anfreunden, man könnte es aber bspw. auch noch dynamischer gestalten, sodass man bspw. für das Urlaubskonto einen Snapshot erstellt (jährlich und monatlich). Hier wäre es dann eben einfacher, wenn noch eine weitere Info dazu kommt, die man speichern möchte.

Die Frage ist aber eher, will man sich diesen Aufwand machen oder reichen nicht wirklich diese Felder (UrlaubstageAktuell, UrlaubstageUebertrag, UrlaubstageVerwendet....)

 

[mrBrown]

Ich sehe aber schon den Vorteil dies in einer "Snapshot" - Tabelle zu persistieren.
Sobald man einen Urlaub storniert, erstellt etc. - muss eben ebenfalls eine Änderung in der Snapshot - Tabelle i.d.R. erfolgen.

Einer der wesentlichen Punkte von Snapshots ist, dass man sie niemals aktualisiert.
Snapshots Stellen den Zustand zu Zeitpunkt X da, und der Zustand zu Zeitpunkt X kann sich im Nachhinein nicht mehr ändern - stell es dir als Foto vor, nur weil sich das fotografierte Motiv ändert, malst du ja auch nicht auf dem Foto rum.