TimePunch

Die Sollstunden werden bei folgender Einstellung fehlerhaft im Bericht angezeigt:

- Arbeitszeitmodell auf 0 Std.
- eingestellt als “Lohnabrechnung mit regelmäßiger Feiertagsarbeit” - Feiertage sind im Monat vorhanden (z.B. April 2019)

Ergebnis:

Die Feiertage werden im Feld “Sollstunden” als Plus angezeigt, obwohl sie (korrekterweise) nicht zu den ausbezahlten Stunden dazugerechnet werden.

D.h. die Berechnung stimmt, die Anzeige der Sollstunden bei der regelmäßigen Feiertagsarbeit nicht, denn hier dürfen die Feiertagsstunden nicht zu den Sollstunden addiert werden.

Das buchen eines halben Tag Urlaubs bei einem halben Feiertag (z.B. 24.12.) führt zu einem Viertel-Tag Urlaub.

Anzeige der aktuellen Tagesarbeitszeit (inkl. des laufenden Zeiteintrags), neben der aktuellen Arbeitszeit.

Die Pausenanzeige ist nicht korrekt, sofern zuerst ein Eintrag mit reiner Zeitdauer und danach ein regulärer Eintrag am gleichen Tag erzeugt werden.

Der Jahresurlaub wird in der aktuellen Version nicht korrekt berechnet, sofern der Urlaub in der Zukunft (also z.B. im nächsten Monat) liegt.

Über den Umweg des CSV Imports können Zeitdaten auf abgelaufene Projekte gebucht werden.
Dies stellt eine unzulässige Nutzung da und muss somit verhindert werden.

Das Berichtsmenü im TimePunch Client sollte der Übersichtlichkeit wegen in Kategorien aufgeteilt werden.
Die Unterteilung soll wie folgt aussehen:

• Projektberichte / Project reports
• Stundennachweise / Time sheets
• Lohnberichte / Wage reports
• Gleitzeitkontoberichte / Flexitime account reports
• DSGVO (ohne eigenen Menüpunkt, da nur ein Bericht)
• Mitarbeiterberichte / Employee reports
• Projektabrechnungen / Project accountings
• Barcodeberichte / Barcode reports

Berichte ohne eine gesetzte Kategorie sollen wie bisher eigenständig angezeigt werden

Das Datafox Modul muss für die Mandantenfähigkeit angepasst werden.
Dabei ist es wichtig, dass die einzelnen Zeiterfassungsgeräte dem jeweiligen Mandanten zugeordnet werden können.

-

Zudem muss der Hintergrundservice, der die Geräte nachts aktualisiert, die Daten des passenden Mandanten auf das Terminal hochladen.

Der TimePunch Cutter muss an die Mandantenfähigkeit angepasst werden.

D.h. der nächtliche Job, muss alle Mandanten durchlaufen, um dort eventuelle Kürzungen vorzunehmen.

Der Branch für TimePunch 3.6 muss auf den aktuellen Stand gebracht werden.

Eventuelle NUGET Pakete sollen aktualisiert werden.
Es soll für diese Version weiterhin das .NET Framework 4.6.2 verwendet werden.

Die automatische Anmeldung via der Windows Authentication muss für die Mandantenfähigkeit neu getestet werden.

Die API URL ist aktuell zugeschnitten auf einen einzelnen Kunden.
Durch die verschiedenen Bindings ändert sich die API URL allerdings pro Kunden und wird daher zukünftig von der Zugriff URL abgelöst.

Tipp:
Für das .net pipe binding kann evt. das Customer Token eingebunden werden.
bisher: net.pipe://localhost/TimePunch
später: net.pipe://localhost/TimePunch/demo1

Die zur Verbindung zum Server genutzte Request-URL muss intern auch für den Aufbau der verschiedenen Links genutzt werden.
Bisher wird dazu noch die API URL verwendet.

Das kann man z.B. sehen, wenn folgende URL aufgerufen wird
http://demo1.TimePunch.de

Beim Klick auf das Logo oder auf die Modul-Icons wird auf https://demo.timepunch.de umgeleitet.

Anhand es ausgewählten Customer Tokens muss im Backend entschieden werden, welche Datenbankverbindung genutzt werden soll.

Damit die einzelnen Module auf die korrekte Datenbank zugreifen können, wird ein Webservice benötigt, der das Customer Token anhand der verwendeten Zugriffs-URL liefern kann.
Dadurch wird sichergestellt, dass die Module mehrere Mandanten verwalten können.

Beim Modul Update oder der Modul Installation muss ebenfalls eine Datenbankprüfung stattfinden.
Im Gegensatz zu der Prüfseite im Menü "Datenbank" werden hier alle Datenbankverbindungen geprüft und eine Aktualisierung angeboten, falls ein Update für min. eine Datenbankverbindung notwendig ist.

Es muss möglich sein, im TimePunch Application Server, mehrere Datenbank Konfigurationen zu hinterlegen.
Die unterschiedlichen Datenbank-Konfigurationen benötigen dabei jeweils eine eindeutige Zugriffs-URL und einen eindeutigen Customer Token.

In TimePunch TEN sollte es ebenfalls wie im Datafox Modul von TimePunch PRO möglich sein, die Stunden auf das zuletzt aktive Projekt zu buchen.
Damit wäre es möglich, dass Mitarbeiter die Arbeitszeit auf unterschiedliche Projekte am Terminal buchen könnten.

Somit könnten z.B. Aushilfen auf eine andere Lohnart gebucht werden, als festangestellt Mitarbeiter.

In TimePunch soll eine neue Auszahlungsmethode für den Stundenlohn eingeführt werden.
In dieser Methode soll die max. Stundenzahl festgelegt werden, die ausgezahlt werden kann.

Arbeitet der Mitarbeiter weniger als die gesetzte Stundenzahl, dann werden dem Mitarbeiter alle gearbeiteten Stunden ausgezahlt.
Arbeitet der Mitarbeiter mehr als die gesetzte Stundenzahl, dann wird ihm max. die gesetzte Stundenanzahl ausgezahlt.

Beim Setzen einer Autorisierung Person sollte man die Möglichkeit haben eine generelle Vertretung auswählen zu können.

Die Entgeltfortzahlung für Lohnarbeiter (13 Wochen Schnitt) muss auf Krankheit und Feiertage ausgeweitet werden.
Die bisherige Implementierung unterstützt lediglich die Entgeltfortzahlung für Lohnarbeiter beim Urlaub.

siehe auch.
https://www.heimbrock-winkler.de/autonews/juni_2016/urlaubsentgelt_und_entgeltfortzahlung_bei_krankheit_und_an_feiertagen_was_sie_ihren_mitarbeitern_zahlen_müssen_aktueller_prüfungsschwerpunkt_/

Die Lohnart für den Export soll in der Tätigkeit überschrieben werden können.

Wird der TimePunch Application Server verwendet, so soll die bisherige Eingabe der Pflichtpause im Arbeitszeitmodell nicht mehr möglich sein.
Dies soll eine Fehlnutzung des TimePunch Cutters verhindern.