Diese Übersicht beschreibt die Einstellungen, die Berechnungsumfang, Ladeaufwand und Folgearbeiten beeinflussen. Die Einstellungen befinden sich in der Systemeinstellungsliste unter den jeweils genannten Gruppen. Größere Stapel sind nicht für jeden Datenbestand schneller; vergleichen Sie denselben Personenkreis und Zeitraum mit den gleichen fachlichen Ergebnissen.
Stand der beschriebenen Entwicklung: 25.10.2026. Die neue Trennung der Zeitdatenberechnung und der neue Schalter benötigen aktualisierte Programmkomponenten. Für die ausgewählte serverseitige Zeitberechnung muss auch der ZwWorker die neue Kennung 6012 kennen. Ein unbekannter Auftrag darf nicht durch den globalen Zeitlauf ersetzt werden.
Pfad: Calc > Optimierungen
Vorgabe: Aus
Kennung: CALC_ZW_PLANWERTE_AKTUALISIEREN
Eine reine Zeitdatenberechnung durchläuft keine allgemeine PEP-Vorbereitung. Der allgemeine Planungsmodus erzwingt dabei keine zusätzliche Vollberechnung der Planung.
Die Zeitbewertung benötigt berechnete Planergebnisse nur in diesen beiden Fällen:
CALC_GutschriftAbwesendAusPEP eingeschaltet sein und eine Rollsystem-Gutschriftart 10 bis 13 tatsächlich zur Anwendung kommen. Ein möglicher Modelltreffer allein löst keine Nachberechnung aus. Pauschalgutschriften und Gutschriften mit Anteil null lösen keine solche Nachberechnung aus.CALC_Saldoart2_ZuschlagAusPlan ist eingeschaltet und die Person verwendet Saldoart 2. Dann wird der berechnete Zuschlag aus der Planung übernommen.Ein: Bereits aktuelle Planergebnisse werden verwendet. Nur tatsächlich benötigte fehlende oder veraltete Ergebnisse werden für die betreffende Person und die erforderlichen Tage gezielt nachberechnet. Die notwendigen fachlichen Abhängigkeiten dieser Planberechnung bleiben erhalten.
Aus: Aktuelle Ergebnisse dürfen weiterhin verwendet werden. Fehlt ein benötigtes Ergebnis oder ist es veraltet, bleibt die Zeitberechnung mit einer verständlichen Fehlermeldung offen. Zuerst die betreffende Planung manuell berechnen und danach die Zeitberechnung erneut starten. Wegen der sicheren Stapelverarbeitung können auch weitere noch nicht abgeschlossene Tage dieses Stapels beziehungsweise dieser Person offen bleiben.
Die Einstellung gilt unabhängig vom allgemeinen Planungsmodus 0/1/2. Sie schaltet weder die planabhängige Gutschrift noch den Zuschlag fachlich ein oder aus. Das bestimmen weiterhin die beiden fachlichen Einstellungen und das Rechenmodell.
Keine PEP-Ergebnisberechnung benötigen: gespeicherte PEP-Kommen-/Gehen-Zeiten für Beschneidung und Kernzeitprüfung, gespeicherte Planpause, die Gutschriftart PEP-Sollzeit (Zeitspanne abzüglich Planpause), Öffnungsrahmen und Rechenmodellrahmen. Der optionale Planvergleich verwendet nur aktuelle Ergebnisse; sein Fehlen erzwingt keine PEP-Nachberechnung.
| Einstellung / Kennung | Gruppe und Vorgabe | Wirkung und Grenze |
|---|---|---|
Tage je Zeitberechnungsstapel / CALC_ZW_STAPELTAGE | Calc > Optimierungen; 100; zulässig 1–366 | Zusammenhängende Tage derselben Person werden gemeinsam geladen. Größere Stapel sparen Ladeaufrufe, benötigen mehr Speicher und melden bestätigten Fortschritt seltener. Lücken und Personen bleiben getrennt. Der Gesamtzeitraum wird nicht vergrößert. Größer ist nicht automatisch schneller. |
Separate Stundenlohntabelle verwenden / CALC_STUNDENLOHN | Calc > Allgemein; Aus | Aus spart die Ladung der separaten Tabelle ITStundenlohn. Grundstundenlohn und Lohnbewertung bleiben aktiv. Nur ausschalten, wenn die separaten Sätze je Kennzeichen/Bereich nicht benötigt werden. Ein lädt die gültigen Sätze gemeinsam je Zeitstapel. |
Änderungen während der Berechnung prüfen / CALC_ZW_EINGABEKONTROLLE | Calc > Optimierungen, Aus | Ein vergleicht den gelesenen nativen Zeitstempel mit dem Stand beim Speichern. |
Personensperre bei Zeitberechnung / CALC_ZW_PERSONENSPERRE | Calc > Optimierungen, Aus | Ein reserviert die Person während Direkt- und Stapelberechnung. Ist die Sperre belegt, bleiben die ausgewählten Tage offen. Der Schalter gilt ab dem nächsten Lauf im aktualisierten Desktop. |
Blockgröße / CALC_BLOCKSIZE | Calc > Technisch; 500 | Begrenzung älterer Ereignis-/Berechnungs-Ladeläufe. Keine zweite Einstellung für die Tage je aktuellem ZW-Stapel und keine garantierte Beschleunigung des neuen Auftragswegs. Nicht pauschal stark erhöhen. |
Früheste Berechnung / CALC_MINDATE | Calc > Allgemein; 01.01.2011 | Begrenzt reguläre offene Berechnungen nach unten. Ein späteres Datum reduziert alte Arbeit, schließt aber diese Vergangenheit vom regulären Lauf aus. Nur nach fachlicher Entscheidung ändern; kein Ersatz für die benötigte Rückschau bei Nachbuchungen. |
Diese Schalter können Arbeit reduzieren, verändern aber den Umfang oder die Funktion. Sie sind keine neutralen Geschwindigkeitsregler.
| Einstellung / Kennung | Gruppe und Vorgabe | Wirkung und Grenze |
|---|---|---|
Planungsberechnung / CALC_PEP_MODUS | Calc > Allgemein; ohne Altwert 1, aus dem bisherigen PEP-Schalter übernommen | 0: allgemeine automatische Planung aus. 1: vollständiger betroffener Planungszeitraum. 2: bedarfsgerecht mit Ist/Plan-Stichtag. Modus 2 kann unnötige historische Planung vermeiden. Reine Zeitdatenaufträge verwenden ausschließlich den oben beschriebenen Pflichtbedarf. Ausdrücklich beauftragte PEP-/kombinierte Läufe bleiben eigenständige Planung. |
Ist/Plan-Stichtag / CALC_PEP_ISTBIS | Calc > Allgemein; -1 = gestern | Bis einschließlich Stichtag Istzeitraum, danach Planzeitraum. Beeinflusst die bedarfsgerechte Planung und Hochrechnung. Kein beliebiger Filter zum Weglassen benötigter Tage; Auswertungen haben ihren eigenen Stichtag. |
Automatische Berechnung ZW bei Stammdatenänderung / CALC_AUTO_ON_STAMM_ZW | Calc > Allgemein; Ein | Aus spart den unmittelbaren Zeitlauf nach dem Speichern im Personenstamm. Die Zeitdaten bleiben bis zu einem späteren beauftragten Lauf offen. Der Personenwechsel oder das Schließen holt die abgeschaltete Berechnung nicht automatisch nach. |
Cache aktiv / GUI_Pep_CacheJazPlan | Allgemein > Jahrsplan; Aus | Ein aktualisiert beim Planungsspeichern zusätzlich den Jahresplancache für betroffene Personen/Jahre. Aus vermeidet diese Schreibarbeit, stellt diese Cachefunktion aber nicht bereit. Betrifft Planungsspeicherung, nicht das Laden des gespeicherten PEP-Rahmens für Zeitdaten. |
Kontingente in ZW verwenden / CALC_Kontingente | Calc > Urlaub; Aus | Aktiviert zusätzliche Kontingentverarbeitung der Zeitbewertung. Aus spart nur dann zulässig Arbeit, wenn diese fachliche Funktion nicht benötigt wird. |
Kontingente in PEP verwenden / CALC_KontingentePep | Calc > Urlaub; Aus | Zusätzliche Kontingentverarbeitung der Planung. Nicht zur Beschleunigung abschalten, wenn die Planung diese Funktion benötigt. |
Periodenabschluss aktiv / CALC_SALDO_ABSCHLUSS | Calc > Periodenbaschluss; Aus | Aktiviert zusätzliche Abschlussverarbeitung. Die Gruppe heißt in der bestehenden Oberfläche tatsächlich „Periodenbaschluss“. Nur bei fachlich nicht benötigtem Abschluss deaktivieren. |
Lohnberechnung / CALC_Lohn | Calc > Allgemein; 1 | 1 bewertet am Tagesende, 2 je Buchung mit deren Stundenlohn/Bewertungsfaktor und gegebenenfalls zusätzlichen Kostenstellenkonten. Unterschiedliche fachliche Verfahren; nicht allein wegen Laufzeit wechseln. |
Zusatzleistung aktiv / CALC_Zusatzleistung | Allgemein > Zusatzleistung; 0 | Aktivierte Zusatzleistungen verursachen zusätzliche Verarbeitung. Nur deaktivieren, wenn die Funktion nicht benötigt wird. |
Die älteren Einstellungen CALC_UrlaubsNachberechnung und CALC_FreieSamstagNachberechnung (Calc > Nachberechnung; jeweils Ein) betreffen im aktuellen Code den älteren Planungsspeicherweg. Sie schalten die fachlichen Abhängigkeiten der neuen Auftragsverarbeitung nicht ab und sind kein allgemeiner Beschleunigungsschalter für Zeitdaten.
Reine Zeitdatenberechnungen behalten die von SQL ermittelten Zeiträume durchgängig bei. Es wird keine vollständige Tagesliste im Client aufgebaut; auch zusätzlich gefundene Buchungstage werden noch in SQL zu Bereichen zusammengefasst. Tages- und Buchungsdaten werden nur für den aktuellen konfigurierten Stapel geladen (Vorgabe 100 Tage). Gesamtzahl und Fortschritt werden aus den Bereichen berechnet. Der Speicherbedarf für Tagesdaten hängt damit vom aktuellen Stapel und dessen Buchungsdaten ab, nicht von allen ausgewählten Jahren und Personen.
Reine Zeitdatenberechnungen lesen ihre ausgewählten offenen Tage direkt aus CStatus. Es wird keine Kopie aller Tageszeilen in PEP-Auftragstabellen angelegt und keine Jobspalte benötigt. Die Personenauswahl bleibt vom Lesen bis zum Abschluss erhalten. Bei einer ausgewählten Person bleiben offene Tage anderer Personen unverändert.
Die Vorbereitung prüft die Zeitraumgrenzen aller ausgewählten Personen gemeinsam in einem SQL-Aufruf. Der Dialog zeigt die Personen-/Bereichsanzahl und anschließend die Gesamtdauer dieses Schritts; es gibt keine Zehnergruppen oder hochzählenden Personenfortschritt während der Abfrage. Die eigentliche Tagesberechnung bleibt in begrenzten Stapeln. SQL ermittelt die zusammenhängenden ausgewählten Zeiträume direkt aus CStatus, ohne die Tabelle Tage. Übertragen werden nur die Zeiträume mit Anfang, Ende und Tagesanzahl. Für Buchungsabhängigkeiten werden nur Anfang und Ende jedes Zeitraums betrachtet; eintägige Zeiträume werden einmal geprüft. Innenliegende Tage sind bereits ausgewählt und benötigen diese zusätzliche Suche nicht. Bei offenen Lücken entstehen getrennte Zeiträume mit eigenen Randprüfungen. Nur zusätzliche abhängige Tage werden offen markiert. Der Wegfall der bisherigen Auftragskopie reduziert Schreibarbeit und die Dauer von Schreibsperren; eine konkrete Kundenlaufzeit ist damit noch nicht nachgewiesen.
Der Dialog und seine sichtbaren Steuerelemente verwenden den DevExpress-Stil, einschließlich Schaltflächen, Beschriftungen, Verlauf und Fortschrittsbalken.
Vergleichen Sie denselben Zeitraum, dieselben Personen, dieselbe Datenbasis und denselben offenen Zustand. Ein zweiter Lauf mit bereits aktuellen Ergebnissen ist kein direkter Vergleich mit einer vollständigen ersten Neuberechnung.
DEBUG-Builds protokollieren zusätzlich Berechnungszeiten und Phasensummen. Release-Builds führen diese Instrumentierung nicht aus. Dies ist eine Build-Eigenschaft und kein Systemeinstellungsschalter. Verschachtelte Phasenzeiten nicht addieren. Schichtmodus V1/V2 und SQL-Timeout sind ebenfalls keine neutralen Optimierungsschalter: V1/V2 unterscheiden sich fachlich in der Zuordnung, und ein höherer Timeout macht die Berechnung nicht schneller.
Siehe auch Extras – Verarbeitung, Zeitdaten und ZwWorker.
Nach allen ausgewählten Personen liest SQL die noch offenen Tage innerhalb der ursprünglichen Berechnungsbereiche als zusammenhängende Zeiträume zurück. Diese werden in genau einem Nachlauf verarbeitet. Ein erkannter Änderungskonflikt wird dafür zurückgestellt; bereits bestätigte Tage werden nicht pauschal erneut geöffnet. Unbearbeitete Resttage derselben Person werden ebenfalls berücksichtigt. Fachliche Fehler und anderweitig reservierte Personen bleiben aus diesem Nachlauf ausgenommen. Weitere Änderungen im Nachlauf bleiben offen für den nächsten Lauf; es gibt keine Endlosschleife. Andere Personen und neu geöffnete Tage außerhalb der ursprünglichen Bereiche werden nicht einbezogen.
Die Vorgaben 100 Tage und Änderungskontrolle Aus gelten für fehlende Einstellungen beziehungsweise das Zurücksetzen auf Vorgabe. Bereits gespeicherte gültige Werte werden nicht automatisch überschrieben.
Die drei Einstellungen „Tage je Zeitberechnungsstapel“, „Zusätzliche Änderungskontrolle ZW“ und „Benötigte Planwerte bei Zeitberechnung automatisch aktualisieren“ stehen gemeinsam unter Calc > Optimierungen. Vorgaben: 100 Tage, Aus, Aus. Vorhandene gespeicherte Werte bleiben erhalten.
Unter Calc > Optimierungen > Zeitberechnung: Laufzeitprotokoll schreiben (CALC_ZW_LAUFZEITPROTOKOLL, Vorgabe Aus) lässt sich die Messung auch im Release-Build einschalten. Danach im ausführenden Programm beziehungsweise Worker einen repräsentativen Zeitdatenlauf starten. Der genaue Logpfad wird im Berechnungsverlauf angezeigt.
Standardablage: %TEMP%\pep4-berechnung\Berechnung-YYYYMMDD-PID.log. Bei Serverausführung ist dies der Temp-Ordner des Worker-Benutzers. Die vorhandene Umgebungsvariable PEP4_DEBUG_LOG_DIR kann die Ablage vorgeben. Anschließend den Schalter wieder ausschalten.
Je Zeitstapel stehen Person-ID, Zeitraum, Version, Einstellungen und Laufzeit im Log. SUMME zeigt Phasen mit Aufrufzahl, Gesamtzeit und längstem Aufruf. SQL-Aufruf.Speichern.* trennt die tatsächlich ausgeführten instrumentierten Speicheraufrufe, insbesondere Arbeitszeiten, Tagespakete, kombinierte Kontenrückgabe, Konten-/Statuspakete und den V2-Abgleich. SQL-SPEICHERN GESAMT summiert diese Aufrufe pro Stapel; fehlgeschlagene Versuche zählen mit. Schnelle Einzelaufrufe werden zusammengefasst, damit nicht für jeden Tag eine Logzeile geschrieben wird.
Die Zähler messen Client-Aufrufe der instrumentierten Speicherwege, keine einzelnen SQL-Statements oder internen Triggeraufrufe. Ladeabfragen und Transaktionsbefehle zählen nicht zu dieser Speichersumme. Geschachtelte Phasenzeiten überschneiden sich und dürfen nicht einfach addiert werden. SQL-Texte und Parameterwerte werden nicht protokolliert; die Stapelidentifikation enthält Person-ID und Datum. Die bisherige Diagnose bleibt in Debug-Builds unabhängig davon aktiv.
Zum Vergleich denselben Personenkreis und Zeitraum mit vergleichbarem offenen Zustand verwenden. Die erzeugte Datei dient der Auswertung beim Support; das Aktivieren allein startet keinen Kundenlauf.
Jeder Lauf besitzt eine Lauf-ID; die Abschnitt-ID [A…] trennt Gesamtlauf, Auswahl und einzelne Stapel. Die lokale Phase Zeitdaten.Gesamt beginnt vor dem Vormerken beziehungsweise Auffüllen und umfasst auch monatliche Teilläufe. Zeitdaten.Auswahl misst den Engine-Aufruf einschließlich Regel-, Grenz- und Planbedarfsprüfung. Bei Worker-Ausführung zuvor separat eingereihte Kommandos gehören nicht zur Engine-Zeit.
Das Log enthält Anzahl von Personen, Zeiträumen und Tagen sowie AuswahlSHA256 für die sortierten kompakten Person-/Datumsbereiche. Gleiche Kennungen bedeuten gleiche ausgewählte Bereiche, nicht identische Stammdaten oder Buchungen. Anfangsauswahl, durch Abhängigkeiten ergänzte Auswahl und Nachlauf sind getrennt ausgewiesen. Konfiguration und Buildkennung werden protokolliert; ERGEBNIS weist Erfolg und Abbruch aus. Die Zahl der ZW.Stapelversuch-Aufrufe zeigt zusätzliche Versuche.
Die Speicheraufrufe stehen sowohl pro Stapel als auch für den Gesamtlauf im Log. Gesamtsumme und enthaltene Stapelsummen dürfen nicht addiert werden. Auch Phasenzeiten überschneiden sich. VollständigBestätigteStapelTage zählt nur vollständig bestätigte Stapel und ersetzt keine Einzelprüfung bereits gespeicherter Tage bei einem Konflikt.
Für einen belastbaren Vorher-/Nachher-Vergleich dieselbe Datenbank mit demselben Eingabestand, dieselbe Aktion, Personenauswahl und Zeitspanne verwenden. Einstellungen wie Konten, Schichtmodus, Stapelgröße und Zusatzleistungen müssen übereinstimmen. Kalt- und Warmläufe getrennt betrachten; ein zweiter Lauf mit bereits abgeschlossenen Tagen oder aktuellen Planergebnissen ist kein gleichwertiger Vergleich. Die Protokollierung bei beiden Versionen gleich einstellen. Erfolgreiche und abgebrochene beziehungsweise unvollständige Läufe getrennt auswerten.
Im Einstellungsfenster bietet Ansicht die Auswahl Nach Rubriken (Vorgabe), Zuletzt geändert und Nach Erstellung. Die zweite Ansicht zeigt die freigegebenen Einstellungen als flache Liste mit den neuesten Einträgen oben. Bezeichnung, Datum und Rubrik stehen an der Einstellung; der Beschreibungsbereich zeigt die Rubrik und den Änderungszeitpunkt ebenfalls. Suche und der Filter für von der Vorgabe abweichende Werte gelten weiter.
Sortiert wird nach dem gespeicherten Änderungszeitpunkt ts, ersatzweise nach tsCreate. Ohne Zeitstempel stehen Einträge am Ende. Neue gespeicherte Schalter werden dadurch ebenfalls berücksichtigt. Eine reine Änderung von Beschreibung oder Programmvorgabe setzt diesen Datenbankzeitstempel nicht automatisch neu. Nach erfolgreichem Speichern werden ausschließlich die Zeitstempel der gespeicherten Einträge nachgeladen, damit die aktuelle Reihenfolge stimmt. Die Umschaltung selbst speichert keine Werte und benötigt keine Datenbankänderung.
Nach Erstellung sortiert ausschließlich nach dem gespeicherten Anlagedatum tsCreate, neueste zuerst. Spätere Wertänderungen beeinflussen diese Reihenfolge nicht. Ohne Anlagedatum steht der Eintrag am Ende. Beide Datumsansichten behalten die vorhandenen Such- und Berechtigungsfilter sowie die Werteditoren bei. Der Beschreibungsbereich zeigt Änderungs- und Anlagedatum.
Bei erfolgreicher, vollständig gemeldeter Zeitdatenverarbeitung schließt sich der Fortschrittsdialog automatisch. Danach erscheint eine Abschlussmeldung mit der Zahl bestätigter Tagesberechnungen, sofern Tagesfortschritt gemeldet wurde. Die Zahl zählt Verarbeitungen; erneute Berechnungen im Nachlauf können denselben Tag nochmals enthalten.
Bei Abbruch bleibt der Dialog mit Abgebrochen geöffnet. Bei einem technischen Fehler, einem negativen Berechnungsergebnis, gesperrten Tagen oder unvollständigem gemeldetem Fortschritt bleibt er mit Unvollständig geöffnet. Der Verlauf kann weiterhin angezeigt werden. Nur erfolgreiche Abschlüsse werden grün dargestellt; unvollständige Ergebnisse rot, Abbruch orange. Nach manuellem Schließen wird ein technischer Fehler wie bisher an den Aufrufer weitergegeben.
Sind Gutschrift aus Planung (CALC_GutschriftAbwesendAusPEP) und Zuschlag aus Planung bei Saldoart 2 (CALC_Saldoart2_ZuschlagAusPlan) beide ausgeschaltet, entfällt beim normalen Laden der Zeitdaten die pauschale SQL-Aktualitätsprüfung der Planergebnisse vollständig. Auch die zugehörige Prüfung der SQL-Voraussetzungen entfällt. Im Log steht je Stapel ZW.Plan: Prüfung übersprungen; beide planabhängigen Funktionen ausgeschaltet.
Maßgeblich sind diese beiden fachlichen Schalter; der allgemeine Planungsmodus und „Benötigte Planwerte automatisch aktualisieren“ schalten diese Abkürzung nicht einzeln frei. Sobald eine fachliche Funktion aktiv ist, bleibt der bisherige Prüfweg erhalten. Explizit angeforderte Pflichtwerte werden ebenfalls weiterhin abgesichert. Ungeprüfte Planergebnisse werden nicht als aktuell behandelt; ihr optionaler Ergebnisvergleich entfällt. Gespeicherte Rahmen, Planpause und PEP-Sollzeit sind davon unberührt.
Die allgemeine Infoanzeige enthält beim Berechnungsdialog einen Eintrag zum Start und einen zum Ende mit Dauer und Abschlussstatus. Laufende Stapel-, Personen- und Fortschrittsmeldungen erscheinen ausschließlich im Dialog und dessen Verlauf. Das Ende wird unmittelbar beim tatsächlichen Abschluss gemeldet, auch wenn der Dialog wegen Fehlern oder Abbruch noch geöffnet bleibt. Die bisherige Fehlerbehandlung und das eingeschaltete Laufzeitprotokoll bleiben erhalten.
Nach der gemeinsamen Prüfung der Zeitraumgrenzen wird die ausgewählte Menge einmal für die Verarbeitung vorbereitet. Danach werden fehlende Arbeitszeit- und Organisationshistorien gemeinsam markiert. SQL fragt anschließend die endgültigen offenen Zeiträume innerhalb genau dieser Auswahl ab. Die Personenauswahl und Lücken bleiben erhalten; Stammdatenfehler teilen einen Zeitraum gegebenenfalls in mehrere verbleibende Bereiche. Andere offene Personen werden nicht einbezogen. Notwendige Buchungsabhängigkeiten bleiben Bestandteil der Auswahl.
Im Hauptlauf und im einmaligen Nachlauf entfallen die bisher je Stapel wiederholten Aufrufe von MarkRecalc, das erneute Offenmarkieren und die Stammdatenfehlerprüfung. Bei ausgeschalteter Eingabekontrolle entfällt der entsprechende SQL-Vorbereitungsaufruf vollständig. Bei eingeschalteter Kontrolle werden weiterhin je Stapel die Eingabestände für die Änderungserkennung geladen. Die Abschlussprüfung bleibt erhalten. Geladen werden weiterhin nur Tagesdaten des aktuellen Stapels; die Gesamtauswahl bleibt eine kompakte Bereichsliste.
Im Laufzeitprotokoll sind Zeitdaten.Auswahl vorbereiten, Zeitdaten.Stammdatenfehler markieren und Zeitdaten.Endauswahl ermitteln mit eigener Laufzeit und Aufrufzahl ausgewiesen. Die bisherige Auswahlvormerkung und Grenzprüfung bleiben separat sichtbar. Endauswahl nach Stammdatenprüfung enthält den Umfang und Auswahlhash nach der Fehlerprüfung. SQL.ZW-Stapel Eingabestaende laden erscheint nur bei aktiver Eingabekontrolle. Die Änderung betrifft den direkten CStatus-Auswahlweg; andere einzelne Direktaufrufe und PEP-Auftragswege behalten ihre bisherige Vorbereitung.
Seit 26.10.2026 verwendet die normale Zeitberechnung wieder den bisherigen Kontenspeicherweg. Bei eingeschalteten Konten werden Tagesergebnis und Arbeitszeit-Updates gespeichert und die vorhandenen Konten dieses Tages gelesen. Der Client vergleicht diese mit den ausgewaehlten Zielwerten. Anschliessend werden Kontenaenderungen und Abschlussstatus gemeinsam geschrieben. Es gibt keinen Umschalter zwischen alter und neuer Speicherung.
Kontenauswahl einschliesslich Bereichsauswahl und expliziter Nullkonten, Sonderbehandlung der Auszahlungskonten mit Endung 01/05 und der Vergleich mit Math.Round(Wert,5) bleiben erhalten. Gespeichert werden ungerundete Werte; gerundet gleiche Bestandswerte behalten ihren Wert und Zeitstempel. Die Statuspruefung verwendet weiterhin den urspruenglichen CStatus-Zeitstempel. Bei ausgeschalteten Konten werden Tagesergebnis und Status ohne Kontenabgleich gespeichert.
Im normalen V1-Lauf mit Konten entstehen wieder ungefaehr drei Speicheraufrufe je Tag: Zeitereignisse/Arbeitszeiten, Tagespaket mit Kontenlesen sowie Konten-/Statusschreiben. Grosse Pakete koennen weiterhin an der bestehenden Parametergrenze aufgeteilt werden. Das Laufzeitprotokoll weist ZW.Arbeitszeit SQL Tagespaket speichern und Konten lesen, ZW.Arbeitszeit SQL Konten und Status schreiben sowie die tatsaechlichen SQL-Aufruf.Speichern.* aus. Gesamtsummen und enthaltene Unterphasen nicht addieren.
Die Rueckstellung betrifft nur die Kontenspeicherung. Einmalige CStatus-Vorbereitung und Stammdatenpruefung, Personenauswahl, Luecken, begrenzte Stapel, Nachlauf, Planbedarfsabkuerzung und Dialog bleiben erhalten. Fuer die Rueckstellung muss cZW neu gebaut werden. Eine Datenbankumstellung ist nicht erforderlich.
Die zuvor versuchte Routine Calc_ZeitTagespaketSpeichern bleibt installiert, wird im normalen Speicherweg aber nicht mehr aufgerufen. Die dafuer vorhandenen SQL-Server-Messphasen erscheinen dort entsprechend nicht mehr. Kundenmessung und begrenzter lokaler A/B-Test zeigten fuer den neuen Weg trotz weniger SQL-Aufrufen keinen Geschwindigkeitsvorteil. Der lokale Test verwendete temporaere Konten, weil Weyh keine Kontenzeilen enthielt, und bewertet wegen Rollback keine echten Tages-Commits. Die Wirkung der Rueckstellung beim Kunden ist mit gleichem Umfang und gleichen Einstellungen erneut zu messen.
Bei Schichtmodus 1 kann die Buchungspaarung eine Rueckwirkung auf den Vortag melden (CalcPrev). Diese Hilfe bleibt insbesondere fuer Einzeltagsberechnungen erhalten. Bei mehreren zusammenhaengenden Tagen darf ein bereits passend verarbeiteter Vortag aber nicht denselben Status nochmals erhalten. Beispielsweise wird eine fehlende Gehenbuchung nicht beim naechsten Tag erneut als identischer Fehler gespeichert.
Der aktuelle Stapel merkt sich die selbst geschriebenen Statusstaende einschliesslich der von SQL zurueckgegebenen Zeitstempel. Notwendige Vortagsstaende ausserhalb der geladenen Tage werden einmal vorab und nur fuer diese Schluessel gelesen. Die neue Routine Calc_SetZeitStatusStand prueft den erwarteten Zeitstempel und den bekannten Status samt Meldung atomar. Nur bei unveraendertem Stand und identischem Ziel entfallen UPDATE und erneutes Zuruecksetzen des Tagesergebnisses. Eine echte Fremdaenderung wird weiterhin mit Konflikt 51213 zurueckgestellt, auch wenn danach derselbe Fehlerstatus sichtbar ist. Fehlende Staende werden nicht blind nachgeladen und akzeptiert.
Die Kontenspeicherung, einmalige Vorbereitung, Personenauswahl, Datumsluecken, Stapelbegrenzung und einmaliger Nachlauf bleiben erhalten. Das Protokoll enthaelt die aggregierten Phasen ZW.Zeitereignisse Vortagsstaende laden, Vortagstatus pruefen und identischen Vortagstatus ausgelassen. Ausgelassene identische Fehler sind kein erneut abgeschlossener Tagesrechenlauf; eine kurze SQL-Pruefung bleibt fuer den Aenderungsschutz notwendig.
Fuer den Einsatz cZW neu bauen und die neue SQL-Routine Calc_SetZeitStatusStand installieren. Es wird keine neue Tabelle, Statusspalte oder Einstellung benoetigt. Die bisherige Routine Calc_SetStatus bleibt fuer andere Aufrufwege erhalten. Die SQL-Installation ist gesondert freizugeben; Kompilieren allein installiert die Routine nicht.