Alle Projekte

Es ist möglich Zeiteinträge zu erzeugen, die eine größere Dauer als das zulässige Arbeitszeitmodell besitzen. Dies führt unweigerlich zu Fehlern.

z.B. Bei einem Urlaubseintrag von 8:00 bis 19:00 Uhr und einem Arbeitszeitmodell mit 8 Std, würde einen 3 Std. längerer Urlaubseintrag bewirken als zulässig ist.

Beim Speichern müssen solche Einträge korrigiert werden.
Zudem soll der Client solche Einträge direkt in der Oberfläche abfangen und eine Korrektur vorschlagen.

TimePunch soll nach einer definierten Zeitdauer (voreingestellt sind 7 Tage) prüfen, ob neue Updates verfügbar sind.

Damit soll es dem Anwender leichter gemacht werden, den aktuellen Entwicklungs-Stand zu verfolgen.

Je nach Wunsch, werden Update Checks für Releases, Betas oder Nightly Builds durchgeführt.

Das Abmelden von Windows oder das Herunterfahren des PCs muss die Protokollierung des Tp-Watchers stoppen.
Aktuell funktioniert dies im Nightly Build noch nicht korrekt.

Das Speichern des Datenbank Passworts für Access Dateien funktioniert nicht korrekt.
Vorläufiger Workaround: Entfernen des Datenbank Passworts mit Microsoft Access.

Sind vor der Migration von TimePunch 1.82 nach TimePunch 1.91 bereits Zeiteinträge in der Zukunft vorhanden, dann sind nach der Migration alle Monate in TimePunch gesperrt.

Als Workaround können die Monate mit folgendem SQL wieder entsperrt werden.

@p01: der aktuelle Monat
@p02: das aktuelle Jahr
@p03: das aktuelle Jahr

UPDATE TP_SUMMARY SET LOCKED=0 WHERE (CUR_MONTH>=@p01 AND CUR_YEAR=@p02) OR CUR_YEAR>@p03;

z.B.: UPDATE TP_SUMMARY SET LOCKED=0 WHERE (CUR_MONTH>=9 AND CUR_YEAR=2008) OR CUR_YEAR>2008;

Es muss eine Unterscheidung zwischen Application Version und Datenbank Version eingeführt werden, die es erlaubt eine neue Application Version zu releasen - ohne, dass die Datenbank Version auch aktualisiert werden muss.

Ziel ist es, neue TimePunch Versionen zu veröffentlichen zu können, die nicht zwingend eine Datenbank Migration benötigen.

⇒ auch für Tp 1.92 soll keine neue Datenbasis benötigt werden.

Die Verwendung des VirtualStore, zur Ablage von Benutzerdaten ist von Microsoft nicht gewollt und eine Altlast bei TimePunch.

Neues Verzeichnis zur Ablage der Logdateien lautet:
c:\users\{Benutzername}\AppData\Local\TimePunch\Logs

Das neues Verzeichnis zur Ablage der Benutzerdaten lautet:
c:\users\{Benutzername}\AppData\Roaming\TimePunch

Für jeden Mitarbeiter sollten auch die folgenden Felder hinterlegt werden können:

- Adresse,
- Geburtsdatum
- Anfangsdatum

und andere hinterlegt werden können.

Beim erstellen eines mehrtägigen Eintrags von Morgens bis Mittags (des gleichen Tages) wird die Pause hinzugerechnet. Es entsteht eine falsche Arbeitszeit.
Beispiel 8:00 bis 16:30 mit 30 Minuten Pause

Eintrag morgens bis mittags
Ergebnis: 8:00 bis 12:30 = 4:30
Richtig ist: 8:00 bis 12:00 (ohne Pause) = 4:00

Kundendaten besitzen in TimePunch einen eindeutigen Schlüssel der sich aus "Kundennummer" und "Name des Kunden" zusammensetzt.
Aktuell muss beim Import die "Kundennummer" und der Name" stimmen, damit die Daten aktualisiert werden. Dies verhindert jedoch die Änderung des Namens, bzw. erzwingt eine Neuanlage.

Hier sollte der Import intelligenter vorgehen.
NEU, Fall 1: Die Kundennummer ist einmalig und passt mit dem Import.
In diesem Fall soll der Kundenname + die Kundendaten aktualisiert werden, d.h. auch eine Namensänderung ist möglich.

NEU, Fall 2: Der "Name des Kunden" ist einmalig und passt mit dem Import
In diesem Fall soll die Kundennummer + die Kundendaten aktualisiert werden, d.h. auch eine Änderung der Kundennummer ist möglich.

Fall 3: Name und Kundennummer passen.
Das ist der ursprüngliche Fall, der die Kundendaten aktualisiert.

Fall 4: Name und Kundennummer passen nicht.
Auch dies ist ein bisher schon berücksichtigter Fall, der einen neuen Kunden anlegt.

Es soll eine neuer Service angelegt werden, der es erlaubt über die TimePunch API, an Mitarbeiter mittels der UserId oder Angabe der Mail Adresse Mails zu versenden.

Implementation eines Verrechnungsfaktors pro Tätigkeit. Der Verrechnungsfaktor wird mit dem hinterlegten Stundensatz des Projekts/Mitarbeiters multipliziert.

Kopierte Zeiteinträge sollten beim Einfügen im markierten Tag eingetragen werden.
Aktuell werden die Zeiteinträge nach dem letzten freien Tag eingefügt.

Das Entsperren von Zeiteinträgen sollte nur mit HR oder Admin Berechtigung möglich sein.

Die bisherige Lohnabrechnung in TimePunch basiert auf den berechneten Sollstunden des Arbeitszeitmodells.

In vielen Unternehmen erfolgt die Lohnabrechnung jedoch unabhängig von den definierten Sollstunden. Daher soll es möglich sein, die tatsächlich ausgezahlten Stunden im Arbeitszeitmodell fest zu hinterlegen.

Eine monatliche Anpassung in Form von einer gesonderten Überstundenauszahlung ist bereits in der aktuellen Version 2.8 implementiert und soll auch weiterhin fortbestehen.

Um die Zugriffssicherheit auf Cloud basierte Datenbanken zu erhöhen, muss ein sog. Transient Fault Handling für den Datenbankzugriff implementiert werden.

Nähere Information sind hier zu finden:
https://msdn.microsoft.com/en-us/library/hh675232.aspx

und hier:
http://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/transient-fault-handling

Das Projekt soll um folgende neue Attribute ergänzt werden.

• Konto
• Kostenstelle
• Auftragsart (Privatwirtschaft / Öffentlicher Dienst)
• Vertrags-Nr.
• Ort der Leistungserbringung

Die neuen Attribute dienen ausschließlich für das Reporting und die Filterung der Projekte bei der Datenselektion für die Berichte.

Für die Abrechnungsrelevanten Berichte soll die fakturierbare Arbeitszeit gerundet dargestellt werden können.

Die Rundungseinstellung ist dazu projektabhängig in den Projektdaten hinterlegt sein.
Es soll zwischen dem mathematisch korrektem Runden, und dem Auf –bzw. Abrunden unterschieden werden können. Auch das Rundungsintervall soll im Projekt gespeichert werden.

Dazu Vorgesehen ist:
• Minutengenau
• auf 3 Minuten
• auf 5 Minuten
• auf 6 Minuten
• auf 10 Minuten
• auf 12 Minuten
• auf 15 Minuten
• auf 30 Minuten

Durch das Runden der fakturierbaren Arbeitszeit soll sich auch indirekt der Rechnungsbetrag ändern.

Um bei komplexen Arbeitszeitmodellen die Urlaubsberechnung Stundengenau abbilden zu können, wird eine Urlaubsberechnung nach Stunden benötigt.

Beispiel der Urlaubsberechnung nach Stunden mit effektiver Arbeitszeit

Mo. -
Di. 8
Mi. 4
Do. 6
Fr. 2
= 20 Std. insgesamt

In diesem Beispiel lassen sich die Urlaubstage nicht genau auf die Wochentage verteilen. Daher ist hier eine stundengenaue Berechnung erforderlich.

Hätte der Mitarbeiter bei Vollzeit 30 Tage Urlaub, dann wären es 30*8 = 240 Stunden Urlaub
Bei 50% Teilzeit könnte der Urlaub auf 120 Stunden mit je 4 Std./Tag = 30 Tage
oder auf 120 Stunden mit je 8 Std./Tag = 15 Tage verteilt werden.

Dies bedeutet aber auch, das z.B. am Dienstag mit 8 Stunden effektiv 2 Urlaubstage genommen werden können, sofern der Urlaubstag auf 4 Stunden festgelegt wurde.

Wenn ein Feiertag mit Arbeitsfrei überbucht wird, dann darf der Feiertag in der Lohnabrechnung NICHT als Arbeitszeit gezählt werden.

Aus bis jetzt ungeklärtem Grund kann der Fehler "Leave Carry Forward (never) ist not supported" auftreten.

Zur schnellen Behebung sollte folgendes SQL ausgeführt werden.

UPDATE [dbo].[TP_YEARLYSUMMARY] SET LEAVE_CARRYFORWARD=1 where LEAVE_CARRYFORWARD=0
UPDATE [dbo].[TP_ANWENDER] SET LEAVE_CARRYFORWARD=1 where LEAVE_CARRYFORWARD=0

=⇒ Wahrscheinlich entsteht der Fehler beim Anlegen eines Mitarbeiters durch Kopieren oder Import der Mitarbeiterprofile. Dies muss noch geprüft werden.

Ist im Arbeitszeitmodell ein 1/2 Arbeitstag hinterlegt, dann wird der Feiertag als Soll-Zeit berechnet.

Das Ändern des Arbeitszeitmodells führt nicht zu einer direkten Neuberechnung / Bewertung des aktuellen Monats.
Erst nach dem Neustart und gleichzeitigem öffnen und speichern eines Zeiteintrags wird der Monat neu berechnet.

Beim Kopieren eines Projektes von einem Projektmanager werden die Berechtigungen auf die Kopie übertragen, aber nicht kopiert.
D.H. er wird "ausgeschnitten" und sieht anschließend das Kopierte Projekt nicht mehr, weil er nicht Authorisiert ist.

Wenn ein Urlaub mit Serieneinträgen angelegt wird, dann werden die Urlaubstage auch am WE gebucht.