TimePunch

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.

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.

- die Übersicht "Mitarbeiterprofile" soll um eine Spalte "Personalnummer" erweitert werden.

Sofern eine Fehlerhafte Benutzeranmeldung stattfindet, soll ein interner Timeout gestartet werden, der die IP des Clients für eine erneute Anmeldung sperrt.

Die Sperrzeit soll dabei bei 1ner Sekunde starten und bei jeder falschen Anmeldung verdoppelt werden.
Zudem soll in der Administration eingestellt werden, ab welcher Anzahl falscher Anmeldungen der Mitarbeiter und/oder der Sicherheits-Admin eine Benachrichtigung per Email erhält.

Um Hackerangriffe unterbinden zu können, sollen benutzerdefiniert IP Blöcke grundsätzlich von der Anmeldung ausgeschlossen werden können.
Diese IP Blöcke sollen in Form von IP4 oder IP6 Adressen oder auch in CIDR Notation in einer Liste angelegt werden können.

Die Liste sollte eine einfache Editierung (Copy & Paste) ermöglichen.

Gesperrte IP Adressen erhalten sofort eine Ablehnung. Sie sind daher noch vor einem möglichen Timeout zu behandeln, bzw. starten diesen auch nicht.

In TimePunch Mobile erfasste Zeiten werden in TimePunch immer auf die Arbeitszeit synchronisiert; auch wenn die eigentliche Tätigkeit mit einem anderen Buchungstyp erstellt wurde. Dies führt zu Fehlern bei der Synchronisation, die nur durch das manuelle öffnen und speichern des Zeiteintrags behoben werden können.

Der Gruppenlink bei den Genehmigungen zeigt auf eine interne Server-URL, und nicht auf die hinterlegte externe URL.
Was zu Problemen führt, wenn der Link außerhalb des Intranets geöffnet wird.

Wenn man im Client Zeiteinträge erstellt/nachträgt, wird scheinbar für einen neuen Eintrag immer der letzte Eintrag des Tages als Vorlage verwendet.
Wenn man aber Lücken im Tag hat, wäre es sinnvoller zur nächsten Lücke zu springen und den Vorgänger als Vorlage zu nehmen; also auch die Uhrzeit zu berücksichtigen.

Nachtzuschlag wird von 6:00 bis 20:00 Uhr gewährt.
Es wird ein Eintrag von 5:00 bis 21:00 Uhr erstellt.

Erwartet wird eine Nachtarbeit von 2 Std.
Tatsächlich wird eine Nachtarbeit von 1 Std. ausgegeben.

⇒ Dies ist ein theoretischer Bug, da der Mitarbeiter dann 16 Std. am Stück! arbeiten müsste, um den Fehler zu erhalten.