Dokumentiert / statisch geprüft: 2026-10-02. Statisch dokumentiert; Nutzerprüfung offen. Keine Schnittstelle ausgeführt.

eProgramm.CStatusFüllen = 1. Aktive feste Registrierung → kein aktiver Delegate (E,P). Registrierung und erreichbare Quellen geprüft; installierte Binärdateien ungeprüft. Active=True, InAutomatik=false, ManuellerAufruf=false, NurAufServer=false. Kennzeichen beschreiben Registrierung/Defaults, nicht eingerichtete Jobs; Run selbst prüft keine Serverbindung.

seegerstefan/pep4desktop, master, Commit f1d82a003b62f2658f06eaa943dc685ab219bdf3. Lokale .DS_Store-/cPep/PEP-Abweichungen nicht vermischt; Fachquellen cSchnittstellen/ZW/Sqlfiles unverändert. Kein Remote-/Installationsabgleich.

Die feste Registrierung hat keinen Delegate, ist nicht manuell oder als regulärer Automatikjob freigegeben. Der aktive ZwWorker2 verarbeitet die Kennung ausdrücklich im ExecuteTask-Zweig. Wenn sein CalcZw-Schalter aktiv ist, legt er intern den Task ###CSTATUS### an.

Worker → cCalcStatus.Auffuellen(Settings, gestern) → Calc_FillCStatus → Calc(CALCMinDate, gestern). Keine Benutzerparameter, Datei oder Gerätekommunikation. CommandTimeout für das Auffüllen ist 0; SQL_TIMEOUT wirkt hier nicht.

Neue CStatus-Zeilen entstehen aus Tage und einer genau einmal gültigen ITZeit-Historie. Der SQL-Defaultwert aus GetEinstellungZw und der bereits geladene VB-Wert CALCMinDate können bei veraltetem Settings-Cache abweichen.

Die anschließenden beiden UPDATEs sind global: Der letzte markiert sämtliche Statuszeilen ab SQL-heute minus zwei Tage, auch künftige oder inaktive. Daher ist „bis gestern auffüllen“ keine vollständige Begrenzung aller Wirkungen dieses Programms. Es folgt die allgemeine Zeitberechnung; deren Varianten, indirekte Felder und Regelquellen sind separat zu lesen.

Keine Gesamttransaktion; Auffüllen kann gespeichert sein, obwohl der Folge-Calc scheitert. Der Calc-Return wird nicht geprüft; sein eigener Fehlerfang kann einen äußeren Erfolg ermöglichen.

Gemeinsames Profil: LEGACY (interne Referenz).

Gemeinsames Profil: CALCENTRY (interne Referenz).

Defaults sind keine Livewerte. Melde-/Datei-/DB-Wirkungen sind nicht atomar.

DB-Rolle PEP4-Anmeldedatenbank, soweit nicht ausdrücklich Aprocon oder Import angegeben. Unqualifizierte Objektschemata nicht als Live-dbo-Vertrag behaupten. INSERT-Defaults/Computed-Spalten sind gesonderte Schemawirkung, kein explizites UPDATE.

Keine Laufzeit-/Live-Schema-/Lieferformat-Abnahme, keine Codekorrektur. Q02 gilt für kundenspezifische Trigger/Constraints/DLLs/Jobs; weitere Grenzen siehe oben und Fragen (interne Referenz). Externe Betriebs-/Schemaabweichungen sind nicht durch die statische Analyse ausgeschlossen.

Block17 ergänzt6001/6002/6003/6004/6005 ausschließlich für direkte Info-/Dialog-/Logmeldungen; keine BASE-Mail/API. Parameter, Auswahl, Return und Fachwirkung jeID.

Block16 ergänzt explizit3031/3032/3041/3042/3060/3500 für die direkten Info-/Logmeldungen. Keine BASE-Vererbung bzw. Mail-/API-Nebenwirkung; Fachdateien/SQL/Returns pro ID prüfen. Keine pauschale Übernahme alter Dateiverträge.

Stand 2026-10-02; statisch geprüft am Commit f1d82a003b62f2658f06eaa943dc685ab219bdf3. Mitglieder ausschließlich durch expliziten Profilverweis: Block 07, IDs 2000, 2001, 2010, 2020, 3020, 3021, 3030, 3040, 3050, 3070.

Block 13: Profil für 1067,1070,1073 nur bezüglich direkter cInfoTools-Dialog-/Logmeldungen und ihrer zwei Einstellungen wiederverwendet. Deren Datei-/Rückgabe-/Timeout-/Folgeaufrufverträge stehen ausschließlich in den Einzelbeschreibungen; die nachfolgenden Block-07-PFAD-/Return-Aussagen sind keine pauschale Behauptung für diese drei neuen IDs.

Block14 nutzt LEGACY ausschließlich für direkte Info-/Logpfade von 1100,1101,1102,1103,1200,1207,1208,1209,1223. Keine pauschale Übernahme der nachfolgenden Block07-Datei-/Rückgabeverträge; konkrete Unterschiede stehen je ID. 1203 verwendet nur direkten MsgBox-Fehlerpfad und ist kein Mitglied.

Block15 ergänzt ausdrücklich 1224/1225/1226/1320/1360/1400/1401/2021/2023 sowie die Veraltet-Stubs 2028/2029/2032/2046/2047/2048. Nur direkte Info-/Logpfade; konkrete Datei-/Return-/Timeoutverträge stehen je ID. Die sechs Stubs erben als Klasse zwar BASE, instanziieren aber nichts und rufen deren Start/Ende nicht auf. 2022 hat keinen solchen Pfad.

Die belegten LEGACY-Einstiege rufen cSchnitt_Basis.Start/Ende nicht auf. Die ursprünglichen Block-07-Klassen erben auch nicht von der Basis; für spätere statische Stubs gilt dagegen nur die fehlende Start-/Ende-Ausführung. Deshalb keine BASE-Mail-/API-/Outboxbeziehungen übernehmen. MAILTO wird zwar von cProgramm angelegt, aber hier nicht ausgewertet; ebenso keine fachliche Auswertung von MANUELL oder SILENT. RunWithDialog setzt MANUELL. Dialogunterdrückung kommt aus Settings.Info.SupressDialogs (Clientkonstruktor False, Worker True), kein belegter ZW-Schlüssel.

Die folgenden Datei-/Return-Aussagen gelten für Block 07, nicht pauschal für spätere Profilmitglieder. PFAD ist FileImport, auch bei den Exporten 2001/3021: vorhandene Datei erforderlich, OpenFileDialog statt SaveFileDialog. Der lokale Registrywert PEP3/PFADESCHNITT/<ID> speichert den zuletzt verwendeten Ordner; dies ist keine serverseitige Systemeinstellung. Fehlender PFAD-Schlüssel ergibt False mit Fehlermeldung. Value.ToString bei Nothing liegt vor dem Fach-Try und kann ungefangen abbrechen. Datei-Existenzprüfung und Startmeldung liegen ebenfalls davor.

Meldungen: ShowProgrammStart/ShowProgrammEndeSuccessDialog mit Level 51, ShowProgrammEndeErrorDialog 102, ShowExceptionDialog 105 → ZeigeInfoEvent, ggf. Dialog, Log. Kein Nachweis über externe Event-Abonnentenwirkungen. Dialog kann unterdrückt sein, Logging bleibt separat. Die acht Ausführen-Funktionen außer 2010/3070 haben keinen abschließenden Return und liefern deshalb Boolean False, auch wenn Daten geändert wurden. 2020/3020 und die beiden Exporte haben zusätzlich im Fachhelfer keinen Return; dort wird bereits Success=False und ein Fehlerdialog gewählt. 2000/3030/3040/3050 können Erfolg melden und dennoch False liefern.

Beide gezeigten Settings-Konstruktoren setzen AlwaysToFile=True. Oberhalb LogLevel werden Datei UND DB versucht; bei False nur DB, Datei als Fehlerfallback. Datei unter ApplicationData/PEP/LogFiles/yyyyMMdd_peplog.txt (Append). DB-Fehler werden als False abgefangen, verhindern nicht zwingend den Import. EventLog-Fehler werden geschluckt. Direkte Fachcommands des Block 07 setzen kein Timeout; SQL_TIMEOUT ist in diesen zehn Pfaden nicht gelesen. Keine zusätzliche fachliche ZW-Einstellung nachgewiesen, auch nicht in spCalcUmsatzPlan.

DB-Rolle PEP4-Anmeldedatenbank. Log schreibt über eigene Verbindung; nicht atomar mit Fachoperationen. fnUserId liest minimalen UserID zum rechten 25-Zeichen-Teil von SUSER_NAME(), sonst 0.

Stand: 02.10.2026; Commit f1d82a003b62f2658f06eaa943dc685ab219bdf3. Lokaler aktiver Folgegraph statisch dokumentiert. Mitgliedschaft ausschließlich über expliziten Calc/CalcDirekt-Aufruf in Einzelbeschreibungen; kein automatischer Provisionslauf und kein automatischer PEP-Calc. Nutzerprüfung offen.

Calc(CALCMinDate,heute) wählt CALC_USESCHICHT: <2 V1, sonst V2. V1 ignoriert die übergebenen Datumsgrenzen und verarbeitet offene CStatus-Listen ab Mindestdatum. V2 verwendet GetDirekt mit Grenzen, markiert fehlenden Stamm aber zuvor global über CALC_FehlerStammMarkieren(−1,NULL,NULL). CalcDirekt verwendet Person/Intervall; V1 IncludeInactive umgeht Mindestdatum/Aktivfilter in Ereignisliste, nicht sämtliche Folgestammbedingungen.

V1: Calc_GetZe/Calc_GetZeDirekt/Force → GetCalcZeitereignisse → Zeitpaarung → SaveAz/SaveAzSchicht → Calc_SetStatus. Tagespaarung ergänzt fehlende Randzeiten gemäß Auto-Kommen/Gehen und teilt Mitternacht; Schicht nimmt Vortag/Folgetag und kann Vorstatus neu setzen. Filialpause zusätzlich durch RMPause und Öffnung. GetCalcZeitereignisse begrenzt Ereignisse auf Datum < morgen, auch wenn das Aufrufintervall weiter reicht.

V2: GetListCalc_V2 → Calc_GetDirekt/GetCalcStamm → Ereignispaare und Calc_SaveAz → Calc_GetAzSchicht_V2 → CalcAZ. Liste wird an Personengrenze geblockt; Direktlauf führt nur seinen geladenen Block aus. Gleicher Zeitstempel/Kennzeichen/Filiale erzeugt A-Paarung; ungültige Paare werden entfernt/als Fehler behandelt. Der Filialwechsel-Neustart im V2-Zweig ist auskommentiert, nicht gleichwertig mit V1. Calc_SaveAz matched vorhandene Zeilen und fügt nur bei fehlendem Match ein; kein Update des Matches. Neue Identity wird nicht in @ID zurückgegeben; übrig gebliebene alte IDs werden entfernt.

Tagesberechnung: Calc_GetAzCalcListe/GetCalcStamm bzw. GetDirekt + Arbeitszeit-/Lohn-/Modellladen → CalcAZ → UpdateAz (dbo.Nettozeit), Calc_SaveBz und Calc_SetStatus. SaveBz aktualisiert Person/Datum, legt fehlende Tage an, löscht bei >1 Treffern den Mehrfachbestand und fügt neu ein. Fehler: Calc_ResetBz setzt eine ältere Teilmenge zurück; Sollzeit2/SollzeitC, BewertetZeit/Zusatzleistung, GutschriftUrlaub/Krank/Auszahlung, Unterbrechung/KUG bleiben dabei nicht vollständig synchron zurückgesetzt.

Konten: CALC_USEKONTEN; V1 ClearKonten/SaveKonten, V2 Calc_GetSavedKonten + Insert/Update/Delete. V1 setzt Wert0 statt zu löschen und schützt Art>=100 mod1/5. V2 vergleicht auf fünf Nachkommastellen, entfernt übrige ungeschützte Altzeilen; leere Maske lässt Altbestand. ResetBz schützt dagegen mod2/5 und setzt ts nicht neu. Die Masken unterscheiden sich, nicht pauschal „alle Konten ersetzt“.

Zusatzleistung nur V1: Calc_Zusatzleistung_add/max aus Zusatzleistung×ArtikelLohn; V2 ruft sie nicht auf. Periodenabschluss optional: Calc_PeriodenAbschluss_AlleMa → Calc_PeriodenAbschluss. V2 nutzt Person−1 auch bei Direktlauf. Abschluss löscht zugehörige Kennzeichen ab offenem Minimum ohne Manuell-/Ursprungsschutz, korrigiert Tages-/Saldo-/Abschlusswerte und fügt Korrekturarbeitszeiten ein. Art1 Saldoausbuchung+geklemmter Übertrag am Folgetag; Art2 Differenz am Tag; Art3 am Folgetag; Art4 Monats-Soll15%-Verfall abzüglich vorheriger Minusstunden; Art5 positives Saldo auf0; Art4/5/6 zusätzliche Quartalskappe nur vor2026. Quartals-UPDATE/INSERT läuft auch bei Verfall0, weil das IF nur die Wertzuweisung umfasst. Abschlussfehler kann nachfolgende Tage sperren, sofern TROTZ_FEHLER=False. Kein Gesamtrollback. CleanStatus setzt Zukunftsstatus global0, ts unverändert.

Stamm-UDF Calc_GetCalcStamm hat eine abweichende Positionsreihenfolge zwischen deklarierter Ergebnistabelle und SELECT (u.a. RMRahmenID); Datenzuordnung muss im isolierten Nutzertest geprüft werden. DATEFIRST/Wochenjahr und gültige Vertrags-/Modellintervalle sind Teil des Rechenvertrags.

CalcAZ trennt Ganztag/Korrektur/Anwesenheit, berücksichtigt Deaktivierungs-/Kollisionskennzeichen und wählt gültiges RM/RMAZPlan. Reihenfolge: Anwesenheit → Rundung → Wegezeit → Öffnungs-/PEP-Rahmen → Pausen/Maximalstunden → Zuschläge → Ist/Lohn → Soll/Ganztaggutschrift/Korrektur → Kontingent/KUG → Tages-/Kontensummen. Auskommentierte CalcJS-, Netto1/2-Altpipeline und nicht aufgerufene GUI-/Speicherfunktionen sind keine aktiven Folgeketten.

Soll-/Ganztagbasis je Regelart: Null, WAZ/Arbeitstage, Plan, MAZ-Kalenderbasis, individuelle Sollzeit oder Rollsystem; Vertragsübersteuerung geht vor RM. Kennzeichen liefern Netto-/Bruttofaktoren, Saldo-/Lohnfaktoren, Urlaub/Krank/Abtragung, Rahmen-/Pause-/Kollision-/Kontensteuerung. Bereichart2 aktiviert Kostenstellenübersteuerung. Tagesarten, individuelle/Filialkalender, Plan und Rand-/Samstagshistorie verändern passende Regeln. Es wird nicht jede geladene Regel bei jedem Tag angewandt. Der Feldindex trennt Metadaten-Lesen von fachlichem Schreiben.

ReMo wird im Serverkontext bei geändertem RMUpdate.Datum geladen; Client kann vorhandenen Cache verwenden. Ladefelder sind unten als SELECT ausgewiesen, auch reine Bezeichnung/GUI-Metadaten. Keine pauschale Schreibwirkung des gesamten SELECT*. Befund im Loader: TagBeginn wird erst aus RMCalc.TagBeginn, danach erneut aus TagEnde gesetzt; TagEnde bleibt im geladenen Objekt auf Default. SQL-V2-Stammliste lädt TagBeginn/Ende separat. Keine automatische Korrektur.

Kontingent: optional KontingentAbtragen(QuelleZ für Ist/P für Planung) bucht alten Verbrauch zurück, wählt Anspruch nach Gültigkeit/Priorität und fügt UrlaubsAbtragung ein. Keine Gesamttransaktion/Reservierung. QuelleP bestimmt Typ aus TOP1 Pep2 ohne Ordnung. Bei geändertem Verbrauch werden alte Art/GültigVon nicht vor erfolgloser neuer Auswahl geleert; dadurch kann ein nicht mehr passender alter Anspruch erneut benutzt werden. VirtuellesKontingent ist ein gesonderter Simulationspfad (kontingent.xml), kein regulärer DB-Schreibvertrag dieser Schnittstellen.

Motoren fangen Fehler intern. Rückgabe/BASE-Erfolg eines aufrufenden Imports beweist keinen fehlerfreien Motorlauf. Keine Transaktion über Datei, Buchung, Status, Berechnung, Konten und Abschluss. Wiederholung kann fremde offene Personentage bearbeiten; vorherige Teilwrites bleiben nach Fehler stehen. Quellenstand ist statisch, keine Live-Schema-/Binär-/Job-/Laufzeitabnahme (Q02). Q11 ist für den hier ausdrücklich aufgelösten lokalen Motorgraph geschlossen; fehlende externe Server-/Liefer-/Betriebsquellen bleiben gesondert offen.

Siehe auch: Übersicht der Schnittstellen. Keine Ausführung oder Codekorrektur.