TimePunch

Datum der Generalumkehr stimmt nicht mit dem Datum des Daten-Exportes überein.

018702

Fest eingestellt ist die Tatsache, dass es sich um eine Monatsanalyse handelt. Für mich und meine Kollegen (mit freier Arbeitszeitgestaltung) wäre es wichtig zu wissen, wieviel Überstunden wir im Laufe einer Woche angesammelt haben.
Somit käme das Programm uns entgegen, wenn der
Analysezeitraum individuell eistellbar wäre.

Es sollte eine Möglichkeit existieren, die max. Minusstunden festzulegen.
Alle Minusstunden darüber hinaus sollten ignoriert werden.

Ist es auch möglich, daß man den wirklichen und den tatsächlichen Stundenstand auswerten kann? Das heißt, ich würde einmal ein Überstundenkonto für mich als Geschäftsführer haben wollen, wo ich sehen kann, was der Mitarbeiter tatsächlich an Überstunden gemacht hat, und eines, wo nach der Überstundenregelung anzeigt wird (d.h. mit gekürzten/ausbezahlten Überstunden).

Folgende Fragen kamen auf:

1. Kann man das Anmeldeprotokoll des Datafox Moduls speichern?
2. Wie weit reicht das Anmeldeprotokoll zurück? Z.Zt. geht es wohl bis zum 13.04.2015.
Kann man diese Zeit verlängern?

→ Das Anmeldeprotokoll sollte exportierbar sein
→ Der Auswertezeitraum sollte variable einstellbar sein

Eine schöne Sache wäre es, wenn man mit der Rolle "Administrator" die Möglichkeit hätte per Abfrage und/oder Rechtsklick auf einen Eintrag die Historie sehen könnte.

Also eine revisions-sichere Version von Timepunch.
Wurde ein Eintrag mehrfach geändert, so kann man das direkt per Rechtsklick als auch in einem Bericht sehen:
Edit-Datum/Zeit | Zustand | Projekt | Tätigkeit | Start | Ende | User | … 14.04.2015 09:00 | initial | Timepunch| DB | 9:00 | - | mv |… 14.04.2015 12:00 | update | Timepunch| DB | 9:00 | 12:00 | mv |… 14.04.2015 12:15 | update | Timepunch| prg. | 9:00 | 12:00 | ab |… 15.04.2014 09:00 | update | Timpunch2 | prg. | 09:00 | 12:00 | mv| ..
15.04.2014 09:08 | update | Timpunch2 | prg. | 08:00 | 12:00 | mv | ..
usw.

Da ich über die Zeiterfassung auch meine Abwesenheit von zu hause erfasse
(Verpflegungsmehraufwendungen…) und viel Nachtarbeit mache, ist es für mich wichtig, dass Tätigkeiten, die über den Datumswechsel hinaus gehen als ein Zeiteintrag gewertet werden und nicht automatisch zweigeteilt werden.

Für Schwerbehinderte Mitarbeiter sollte es möglich sein einen Sonderurlaub anzulegen, der dann auch gesondert ausgewiesen wird.

z.B. 27 Tage Urlaub + 5 Tage Sonderurlaub

Es sollte möglich sein, einen Zeiteintrag auf mehrere Kunden aufzuteilen.

Die Anzeige der Dauer muss dabei bei jedem Kunden gleich sein.
Nur die Abrechnungsdaten ändern sich.

Beispiel 1 Std. Zeit wird abgerechnet auf Kunde A (60%) und Kunde B (40%)

Zeit 1 Std. Kunde A mit 36 Minuten verrechnet
Zeit 1 Std. Kunde B mit 24 Minuten verrechne

–> Ohne Angabe der genauen Zeit, sollte die Zeit des Eintrags auf alle Kunden gleichermaßen verteilt werden.

Es sollte möglich sein das Arbeitsverhältnis befristet anzulegen.
Das hätte den Vorteil, dass sich das Profil automatisch deaktivieren und die Lizenz freigegeben würde.

Jahresdaten (YearlySummary), die in der Zukunft liegen, werden nicht ordentlich aufgeräumt, wenn ein versehentlich erzeugter Zeiteintrag wieder gelöscht wird.

Dies ist daran zu erkennen, dass die Objekte noch in der Datenbank vorhanden sind und daher Fehlerhafte jahresdaten zurückliefern können.

Premisse - wenn im Zeitraum kein Zeiteintrag vorhanden ist, dann sollte auch die jährliche Zusammenfassung (genau wie die Monatsdaten) nicht persistiert werden.

Wir haben bei Projekten oft eine Stundenanzahl eingegeben.
Es sollte eine Möglichkeit geben, eine automatische Meldung zu bekommen wenn die Stunden z.B. zu 80% verbraucht sind.

Da sich der Freitext bei Zeiteinträgen öfters wiederholt, sollten pro Projekt/User die letzten Freitexteinträge als Vorschläge im Dialog angezeigt werden.

Das Datum für den Stichtag zur Überstundenbegrenzung sollte selbst festgelegt werden können (aktuell ist dies immer Ende des Monats).

Dies ist wichtig, wenn die Lohnzahlungen an den Steuerberater übergeben werden müssen.

Die Felder Projekt, Tätigkeit und Kunde sollten optional als Pflichtfelder definiert werden können.
Ein entsprechender Schalter soll im Administrationsbereich von TimePunch vorgesehen werden.

Um das Feature schon vorab zu aktivieren sind folgende DB Checks notwendig:

ALTER TABLE TP_ENTRIES WITH NOCHECK ADD CONSTRAINT CHK_NOTEMPTY CHECK 1)

ALTER TABLE TP_ACTIVE_ENTRIES WITH NOCHECK ADD CONSTRAINT CHK_ACTIVENOTEMPTY CHECK 2)

TimePunch sollte es erlauben selbst Plan und -Schwellwerttrigger für bestimmte Projektkombinationen zu setzen.

Beispiel:
Kombination zwischen: Mitarbeiter, Projekt, Tätigkeit und Kunde.

Wobei nicht alle Kombinationen gesetzt sein müssen.

Ist ein Wert nicht gesetzt, dann gilt er für alle möglichen Werte:

Beispiel:

Geplante Stunden: 50 Std.
Schwellwert : 30 Std.

Mitarbeiter: -
Projekt : Bäckereiumbau
Tätigkeit : -
Kunde : Bäckerei Fritz

Ebenfalls könnten damit andere Kombinationen verwaltet und kontrolliert werden.

Wir haben öfters Nachteinsätze und von 23Uhr bis 05.00 Uhr dürfen wir 25% mehr Stunden aufschreiben. Gibt es eine Funktion, welche so etwas automatisch mit einrechnen kann?

- Die Nachtarbeit sollte automatisch zu den Überstunden hinzugerechnet werden.

Die Dienstreise sollte als eigenständiger Buchungstyp angelegt werden können.
Dies hätte den Vorteil, dass

a:) eine Dienstreise auch in TimePunch direkt gebucht werden könnte (nicht nur über den Kalender)
b:) die Dienstreise auch in der Anwesenheitsliste Berücksichtigung finden könnte.

Eine potentielle Fehlerquelle liegt darin, dass die Tabelle TP_ACTIVE_ENTRIES keinen Unique Schlüssel auf der User Spalte hat. Dies kann zu Fehlern führen.

Es sollte möglich sein, die aktuellen Projektdaten (im Stundennachweis) mit den Daten aus dem Gleitzeitkonto zu kombinieren, um z.B. einen Stundennachweis mit integrierter Anzeige des Gleitzeitkontos zu ermöglichen.

Prüfen und Testen wie der SQL Server Express im Docker Container für eine TimePunch Server Installation genutzt werden kann.

Dazu gehört:
- Installation des SQL Server Express im Container
- Konfiguration, damit der TimePunch Server damit arbeiten kann
- Backup Problematik: Wie werden Backups erstellt? Stichwort: Kompletter Container, oder nur die Datenbank?

https://store.docker.com/images/mssql-server-windows-express?tab=description

Das Datenbank-Backup Script soll so funktionieren, dass alle Backup Dateien, die älter sind als die vorgebebene Anzahl an Tagen (z.B. 30 Tage) gelöscht werden.

Ausnahme: Es darf nicht gelöscht werden, wenn kein Backup vorhanden ist, welches neuer als die eingestellte Anzahl an Tagen ist.

Damit soll sichergestellt werden, dass mindestens ein aktuelles Backup zur Verfügung steht.

Das Aufräumen der alten Backups soll sowohl lokal, als auch auf einem Netzwerk-Share funktionieren.

Nach der Installation des TimePunch Clients mit der Option /VerySilent öffnet sich das Browser Fenster mit TimePunch. Dies sollte bei dieser Installationsvariante unterbunden werden.

Beim Export der Projektmitarbeiter tritt ein Fehler auf, wenn zu viele Daten exportiert werden sollen.

Bei der Berechnung des bezahlten Urlaubs tritt ein Fehler auf, wenn

a) in den Optionen der Wert auf "durchschnittlicher Verdienst innerhalb der letzten 13 Wochen" eingestellt ist
b) das Arbeitszeitmodell 0 Sollstunden aufweisst
c) Urlaub gebucht wird und im Monat davor dann Arbeitszeit eingetragen wird.

Beim Eintragen der Arbeitszeit erscheint eine Fehlermeldung weil die Berechnung des durchschnittlichen Verdiensts hier auf einen Fehler läuft.

Fehlermeldung:
2018-02-05 15:56:38,108 [16] FATAL: Transaction
AdFactum.Data.Exceptions.SqlCoreException: Der eingehende Tabular Data Stream (TDS) für das RPC-Protokoll (Remote Procedure Call) ist nicht richtig. Parameter 3 ('@p01'): Der angegebene Wert ist keine gültige Instanz des float-Datentyps. Überprüfen Sie die Quelldaten im Hinblick auf ungültige Werte. Ein Beispiel für einen ungültigen Wert sind Daten eines numerischen Typs, deren Dezimalstellen den Wert für die Genauigkeit überschreiten. —> System.Data.SqlClient.SqlException: Der eingehende Tabular Data Stream (TDS) für das RPC-Protokoll (Remote Procedure Call) ist nicht richtig. Parameter 3 ('@p01'): Der angegebene Wert ist keine gültige Instanz des float-Datentyps. Überprüfen Sie die Quelldaten im Hinblick auf ungültige Werte. Ein Beispiel für einen ungültigen Wert sind Daten eines numerischen Typs, deren Dezimalstellen den Wert für die Genauigkeit überschreiten.