Schnittstelle 6003: Neu berechnen (PEP) — markieren und PEP berechnen

Dokumentiert / statisch geprüft: 2026-10-02. Statisch dokumentiert einschließlich der nachgearbeiteten lokalen Folgeketten; Nutzerprüfung offen. Keine Schnittstelle ausgeführt.

eProgramm.CalcPep = 6003. Aktive feste Registrierung → cProgramme.CalcPep (E,P). Projekteinschluss der genannten VB-Quellen geprüft (PRJ). Active=True, InAutomatik=true, 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.

DATUM (Datum, registriert ohne Default). Bei vorhandenem Schlüssel: erst IsDate, sonst IsNumeric → heute + Wert Tage; ungültig False mit Fehlerdialog. Bei fehlendem Schlüssel Datum=01.01.2000. Nicht der BASE-Datumsmusterparser: m/j/w-Muster aus anderen Programmen gelten nicht. Direkte Info-/Dialogmeldungen, keine BASE-Mail/API. Kein File.

UPDATE PepBerechnet.tsCalc=NULL für Datum>=gewähltemDatum und Datum>=CALCMinDate. Timeout SQL_TIMEOUT. SQL-Exception → False. Danach CalcPep(Nothing,Datum,Nothing), unabhängig von gewählten Personen (kein Parameter). Netto-SP bekommt Datum direkt, Lade-SP begrenzt mindestens aufCALCMinDate. True mit Erfolgsmeldung nach Aufruf.

Markiert vorhandene Planberechnungszeilen und berechnet anschließend Pep2.Netto/PepBerechnet-Werte über PEPCALC. Motor-/Lade-/Kontingentgraph im vollständigen PEPCALC-Profil. Kein CStatus-ZW-UPDATE oder allgemeiner ZW-Calc aus dem Programmnamen ableiten.

⚠ Rückgabe CalcPep(False) nicht geprüft; Erfolgsmeldung/True trotz internem Fehler möglich. DATUM-Nothing im registrierten Schlüssel ist nicht der dokumentierte fehlender-Schlüssel-Fallback. Nutzerprüfung offen.

Gemeinsames Profil: LEGACY (interne Referenz).

Gemeinsames Profil: PEPCALC (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; nur explizite CalcPep-Aufrufe der Einzelbeschreibungen. CALC_USESCHICHT ist hier kein Dispatcher für V1/V2.

CalcPep → PepCalcNettoPerson(Person/DatVon/DatBis) → PepBerechnungLaden → PepPersonenLaden(Funktion3). PepBerechnetCachenPerson nutzt Funktion2 als separaten Cachehelfer. DatVon beim Berechnungsladen mindestens CALCMinDate; parameterlos Person−1, DatBisNULL, ForceFalse. Netto-SP verwendet zunächst unverändert übergebene Grenzen. Ladekommando Timeout0, Planladen600; SQL_TIMEOUT gilt ausgewählten Kommandos, nicht pauschal allem.

PepCalcNettoPerson schreibt Pep2.Netto als Tagesbruchteil FLOAT(Gehen−Kommen)×Kennzeichen.Netto×ITZeit.NettoFaktor. NULL<>neuer Wert ist nicht wahr; vorhandenes NULL-Netto wird dort nicht ersetzt. Join auf gültiges ITPEP/ITZeit und offene/ältere PepBerechnet.tsCalc/tsPepChange. Keine automatische tsPepChange-Aktualisierung durch diesen Netto-UPDATE.

Funktion2 ergänzt fehlende Cachetage im Personen-/Eintritt-/StartPEP-/Austritt-/Tagefenster bei gültigen aktiven Verträgen. Funktion3 alle Personen setzt ungeeignete alte/offene Cachetage teils GLOBAL ohne Datumsgrenzen zurück; personbezogener Zweig hat andere Datums-/ITPEP-Bedingungen. TOP10000 offene/ältere/Force-Zeilen; Änderungen von RMAZPlan/RMCalc/ITZeit/ITStunden/ITORGA/Kalender/Tagesarten/Jahres-/Wochenplan werden über tsCache2 verglichen. tsCache2 ist gemäß Updates0487/0602 Computed aus tsCache; keine fälschlich behauptete zweite unaktualisierte Markerspalte.

Cachebasis: Verträge und RM-Übersteuerung, Tages-/Filialkalender, MAZ/WAZ, RMAZPlan/DATEFIRST, individuelle Wochen-/Zeitfenster-/Soll-/Jahres-/Rollpläne. Sollart0–6/9–12 und Saldoart2 haben unterschiedliche Grundlagen; Jahresverschiebung wird verteilt, Feiertags-/Ganztaggutschrift berechnet. CALC_MAZ_SOLLZEITSTART verschiebt Monatsbasis; Monat−1/Monat+1 kann am Jahresrand0/13 ergeben. Sollart3 prüft Jahresarbeitstage, teilt jedoch durch Monatsarbeitstage. Funktion1 (GUI-PEP-Saldenlisten, auflaufender Urlaub etc.) ist NICHT Bestandteil dieser CalcPep-Kette; dortige GUI_PEP_SALDOART-Wirkungen sind nicht übernommen.

PepPlanLaden liefert drei Resultsets: Tagesbalken mit Gruppe/Filiale/Tagesart, vorheriger Samstagszuschlag, UrlaubIDVortag. CalcAZ im PEP-Modus → SpeichernPepClassic UPDATE bestehender PepBerechnet-Zeilen, kein dortiger INSERT. Ohne Pep2 kann SQL vorher Feiertagsbrutto oder0 setzen. QuelleP-Kontingentbuchung optional; kein BerechnetKonten-Speicherpfad und kein ZW-Periodenabschluss allein durch CalcPep.

Blockwiederholung bis keine Zeilen. ForceTrue beim globalen Einstieg kann dieselben weiterhin ausgewählten Zeilen erneut laden; nicht als sicher endender Job konfigurieren. CalcPepSub fängt Fehler intern; äußeres True kann einzelne fehlerhafte Personentage überdecken. SQL-Nachfolgetag-Erkennung für UrlaubIDNextNextDay prüft die Balkenzahl des Folgetags statt des zweiten Folgetags; die Kennzeichenwahl prüft dort nicht UseUrlaubID.

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.