Berechnung von Arbeitstagen in Antragsverarbeitungssoftware

Fristberechnung in Arbeitstagen für Antragsbearbeitungssysteme

Antragsbearbeitungssysteme müssen Arbeitstage statt Kalendertage für genaue Fristberechnungen verfolgen. Die Zählung beginnt am Tag der Veröffentlichung während der Geschäftszeiten oder am nächsten Arbeitstag, falls außerhalb des Zeitplans veröffentlicht. Der Kalender wird automatisch beim Start von einem externen Dienst geladen und täglich auf Daten für das aktuelle und nächste Jahr überprüft. Ohne Kalender greift das System auf Kalendertage zurück.

Die Registrierung erfolgt sofort bei Veröffentlichung, ohne auf einen Arbeitstag zu warten. Beispiel: Veröffentlichung um 23:00 Uhr an einem Arbeitstag verschiebt den Start auf den nächsten Arbeitstag; Veröffentlichung um 6:00 Uhr am selben Tag bleibt der aktuelle Tag, wenn der Zeitplan später beginnt.

Regeln für die Anzeige des Zählers

Der Zähler zeigt die Anzahl der vollen Arbeitstage an, die vergangen sind. Unabhängig von der Veröffentlichungszeit zeigt er am Starttag der Frist 0/N an.

• Veröffentlichungstag während der Geschäftszeiten: 0/N bis 00:00 Uhr des nächsten Tages.
• Veröffentlichung außerhalb des Zeitplans: 0/N bis 00:00 Uhr des ersten Arbeitstags.

Der Zähler erhöht sich um 00:00 Uhr, nachdem ein voller Arbeitstag beendet wurde. Eine Frist gilt als verpasst, wenn der Wert ≥ N ist (z.B. 5/5).

In der Diskussion abgelehnte Alternativen

• Zähler beginnt bei 1/N ab dem Zeitpunkt der Veröffentlichung – erschwert die Wahrnehmung voller Tage.
• Erhöhung am Ende des Arbeitstags – ignoriert Mitarbeiterverzögerungen.
• Markierung als überfällig am Ende des Arbeitstags – unlogisch für 17:59 Uhr vs. 18:01 Uhr.

Berechnungsbeispiele

Beispiel 1: Veröffentlichung am 1. Januar (Feiertag), erster Arbeitstag 12. Januar, Frist 16. Januar (5 Tage). Bearbeitung am 13. Januar – Zähler 1/5 (voller Tag: nur 12. Januar).

Beispiel 2: 2 Tage Bearbeitungszeit, Veröffentlichung an einem Arbeitstag um 9:00 Uhr (Montag). Montag: 0/2; Dienstag: 1/2; Mitternacht Dienstag: 2/2 (überfällig).

Beispiel 3: Gleiche Aufgabe, Veröffentlichung um 20:00 Uhr Montag. Montag: 0/2; Dienstag: 0/2; Mittwoch: 1/2; Mitternacht Mittwoch: 2/2.

Zeitzonen werden zur Vereinfachung auf Serverzeit vereinheitlicht.

Implementierungsdetails im Backend

• Kalender im Cache speichern: aktuelles Jahr + nächstes Jahr (mit Bereinigung alter Daten).
• Zählerwerte und ursprüngliche Fristen in der Datenbank für jeden Antrag speichern – minimiert Neuberechnungen.
• Fristverlauf speichern: separate Tabelle für Konfigurationen nach Typ/Zeitraum oder Spalte in der Entität.

Kalenderaktualisierung: API-Anfragen beim Start, täglich um 00:00 Uhr.

Testen wichtiger Szenarien

Verhalten in Echtzeit testen oder über Datenbank/API simulieren:

• Normaler Arbeitstag.
• Feiertag.
• Abend eines Arbeitstags (nach Zeitplan).
• Fehlen des Kalenders – Fallback und automatische Aktualisierung.
• Überfällige und normale Fristen.
• Last: mehrere Kalender über Jahre.
• Inaktive API-Dienste.

Wichtige Punkte

• Die Zählung beginnt am Tag der Veröffentlichung innerhalb des Zeitplans oder am nächsten Arbeitstag.
• Zähler: volle vergangene Tage, beginnend bei 0/N.
• Überfällig: ≥ N um 00:00 Uhr nach der Frist.
• Caching und Datenbankaufzeichnung reduzieren die Last.
• Grenzfälle testen: Feiertage, Abende, fehlende Daten.

— Editorial Team