Schnittstelle 5318: KaDeWeZa Abwesenheiten — SAP-Import mit PEP/ZW-Abgleich

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

eProgramm.ImportKaDeWeZaAbwesenheiten = 5318. Aktive feste Registrierung → cSchnittZalarisImportAbwesenheiten.AusführenKaDeWe (E,P). Projekteinschluss der genannten VB-Quellen geprüft (PRJ). Active=True, InAutomatik=true, ManuellerAufruf=true, 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.

PFAD: vorhandener Ordner (Folder); IMP wird angelegt. Dateien *_SAP_PEP4_ANWABW.csv alphabetisch sortieren, alle bis auf die letzte ohne Import archivieren, nur die letzte importieren. Nicht der Dateizeitstempel, sondern der Name entscheidet. Encoding.Default, Semikolon/Trim, erste Zeile stets verworfen. Sieben Positionen: PersonID; externe Kennzeichen-ID; von-yyyyMMdd; von-HH:mm; bis-yyyyMMdd; bis-HH:mm; U=unbezahlt (sonst bezahlt). Mindestens sieben Felder geprüft; Ganztag mit00:00.

Globales Staging-TRUNCATE und INSERT je Zeile, Timeout0. Zeilenfehler werden gemeldet; Lesen läuft weiter. Danach SCHNITT_KADEWEZA_Abwesenheit_Import auch bei Teilfehlern. Transformfehler intern als Stopp gefangen; trotzdem folgen CalcPep() und Calc(CALCMinDate,heute). Die Datei wird nach Rückkehr auch bei internem Fehler archiviert; MoveFile überschreibt ein gleichnamiges IMP-Ziel. Keine Fachtransaktion.

SAP-Eingang → @Import über Kennzeichen.ImportID/ImportZeitAngabe/ImportBezahlt/ImportNurVergangenheit. Person muss bekannt sein; bis>=aktueller Jahresbeginn; Vergangenheitscut=erster Vormonatstag. Nicht mehr gelieferte importfähige Arbeitszeiten (ImportID>0, Gehen>Jahresbeginn) löschen; neue Person/Kommen/Gehen/Kennzeichen-Intervalle mit Kommentar IMP anfügen. Bei SAP-Matches bisherigen Kommentar FROMPEP leeren.

Danach zweimal SCHNITT_KADEWE_Abwesenheit_Export_Alle → SCHNITT_KADEWE_Abwesenheit_Export: Staging wird geleert und aus Pep2 aufgebaut (Export=1, gültige ITORGA, Abteilung>0, Monatsversatz, fest Datum<01.01.2027). Aus dieser PEP-Spiegelung fehlende FROMPEP-Arbeitszeiten löschen und neue anfügen: Korrektur0, Filiale=fnGetFilialID, Changedate=GETDATE, UserID0, KommentarFROMPEP, geloescht bei Kennzeichen11. Zwischen beiden Wiederholungen TRANS_ZwToPep.

TRANS liest Arbeitszeiten/Tage und Kennzeichen.MatchZeToPep[GT]: Ganz-/Teilzeit, Krankheit, KeepPlanung und Zeitgrenzen. Ganze Planungen löschen, Status/Netto ändern oder Pep2-Zeilen anfügen. Teilintervalle über Pep2Loeschen (Randbalken löschen, innen Status2/Netto0) und Pep2Insert (Überlappungen teilen/kürzen/löschen; Datum/Zeit normalisieren; Netto für Kennzeichen.Netto1). PepBerechnet.tsCalc=NULL und tsPepChange=GETDATE aus Recalc.

Import-SP markiert CStatus1 für @Recalc und aktive ITZeit, verwendet jedoch Datum>=ITZeit.bis2 statt⇐. fnGetFilialID: TOP1 ohne ORDER, gültig über von/bis(NULL). PEP-Export-Resultsets werden hier durch ExecuteNonQuery nicht in Dateien geschrieben. Allgemeine Motorausgänge über die vollständigen lokalen Profile PEPCALC/CALCENTRY.

⚠ Snapshot-/Archivregel, globales Staging und breite Löschung nach unvollständigem Import, auffällige bis2-Grenze sowie Calc/Archiv trotz Transformstopp. Rückwärtsprüfung des PEP-Exports kann vor Beginn nicht einfügen (Datum>=DatVon bei Datum=DatVon−1). Liefervertrag und gewünschte Kundenfilter Q19; Motorabdeckung im vollständigen Profil.

Gemeinsames Profil: BASE (interne Referenz).

Gemeinsames Profil: PEPCALC (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änzt explizit5314/5315/5316/5317/5318/5319/5323/5324/5325/5326/5327/5328/6000/6006/6007/6008/6009. Alle nutzen BASE-Start/Ende;6001/6002/6003/6004/6005 verwenden LEGACY statt BASE. Fachverträge jeID, keine automatische gemeinsame Kunden-/Dateiwirkung.

Stand: 2026-10-02 · Commit f1d82a003b62f2658f06eaa943dc685ab219bdf3. Gilt ausdrücklich für Block 01: 1012, 1013, 1016, 1017, 1018, 1019, 1079, 1080, 1082, 2016 sowie Block 02: 2011, 2012, 2014, 2015, 2017, 2018, 2019, 2033, 2034, 2041 sowie Block 03: 1057, 1058, 1059, 1060, 2030, 2035, 2040, 2042, 2044 sowie Block 04: 2053, 2054, 1081, 2031, 2052 sowie Block 05: 2045, 2050 sowie Block 06: 3044, Block 08: 1010, 1011, 1015 und Block 10: 1047, 1051 sowie Block 12: 1064. 2024, 1020, 1030, 1048, 1049, 1050, 1052, 1053, 1054, 1061, 1062 und 1063 verwenden diese Basis nicht. 1078 enthält die gleichversionierten Beziehungen weiterhin in seiner Einzelbeschreibung; keine Doppelzählung für 1078. Kein Test-/Deploymentnachweis.

Block 13 ergänzt ausdrücklich 1065,1066,1068,1069,1071,1072,1074: aktive Implementierungen bzw. Hilfsinstanzen erben BASE und rufen Start/Ende auf. Bei 1074 ist AusführungEnde nur bei unbehelligtem Abschluss erreichbar; Ressourcen-/DB-/SP-Fehler können es überspringen. 1067/1070/1073 verwenden direkte LEGACY-Meldungen.

Block14 ergänzt ausdrücklich 1104,1105,1106,1108,1109,1150,1210,1214,1215,1222. Aktive Klassen/Instanzen erben BASE und starten/beenden den Lauf; ungefangene Fehler können das Ende überspringen. Nur gemeinsame Rückmeldung, keine Gesamttransaktion oder erfolgreiche Fachwirkung. 1203 hat keinen BASE-/LEGACY-Pfad.

Block15 ergänzt ausdrücklich 2025/2026/2027/2049 mit erreichbarem Instanz-Start/Ende. Die aktiven Veraltet-Stubs 2028/2029/2032/2046/2047/2048 nutzen trotz Klassenvererbung nur den direkten LEGACY-Meldepfad; keine BASE-Ausführung. 2022 hat keinen Delegate.

Block16 ergänzt ausdrücklich 2051/2055/3043/3512/3513/3520/3521/3522. WebZerf2 nutzt Multi-Start/Ende mit BASE je Teilstufe; IsMultiSchnitt reduziert Dialoge, nicht Mail-/API-Wirkungen. Nach Fehlern können weitere Teilstufen starten. 3011 ohne Delegate;3031/3032/3041/3042/3060/3500 nur LEGACY.

Die ausdrücklich zugeordneten Programmregistrierungen mit ihren Implementierungen erben cSchnitt_Basis und rufen AusführungStart/AusführungEnde auf. Gemeinsam geprüfte Basisklasse/Registrierung; Mail-/Logging-/API-Details aus der dokumentierten Pilotprüfung desselben Commits wiederverwendet. Nicht automatisch auf jede zukünftige Schnittstelle übertragen: Erreichbarkeit, Overrides, Sonderpfade und Quellenstand jeweils prüfen.

Start setzt Status/Protokoll zurück. Fehlerstatus steigt nur (0→1→2). Fehlerfrei() ist True nur bei Status 0. SILENT unterdrückt die Startanzeige und beendet AusführungEnde sofort. MANUELL wird über Schlüsselinzidenz erkannt, unterdrückt direkte Mail und API-sendmail, nicht die API-Meldung selbst. MAILTO leer → MAIL_SCHNITTSTELLETO. Bei nicht lokal gefangener Exception kann der Abschluss ausfallen (besonders 1079/1082); 2016 hat einen getrennten Rückgabe-/Fehlerstatusbefund; 2017 reicht ebenfalls den Instanzstatus nicht als Shared-Rückgabe durch. 1057–1060 besitzen untypisierte Shared-Einstiege ohne Return (Nothing) und übernehmen Modul nicht; Instanz-Abschluss separat betrachten. Die acht Exporte aus Block 02/03 verwenden cSchnittExport mit Start/Ende.

Erfolg: OnSuccess; Fehlerstatus 1: OnSuccess ODER OnError; Stoppstatus 2: OnError. Mail nur nicht MANUELL und nicht SILENT; API wird sonst unabhängig vom sendmail-Schalter aufgerufen. Direkte Mail speichert Body/Outbox in eigener Transaktion (keine Fachimporttransaktion). SendOutbox(5) kann ältere fällige Schnittstellenmails versenden und deren Anhänge lesen; diese Fachpfade erzeugen selbst keine Anhänge. SMTP-Testadresse kann Zieladresse ersetzen. Mail-/API-Ergebnis ist kein verlässlicher Bestandteil von Fehlerfrei().

DB-Rolle Anmeldung; Logging über cInfoTools-Verbindung. Keine Geheimnisse/Livewerte. Indizes verknüpfen jede Mitglieds-ID mit diesen Beziehungen, auch wenn die Details nur einmal stehen.

Logdateien unter ApplicationData/PEP/LogFiles; kontextabhängig Windows-Eventlog. Start/Erfolg InfoLevel 51, Importfehler 102; Schwellen beeinflussen Persistenz. SQL-fnUserId liest tblUser anhand RIGHT(SUSER_NAME(),25). API Send(MELDUNG) nutzt Anmeldungskontext und fest codierten Endpoint; dessen Serverimplementierung fehlt in dieser Quellenbasis (Q01).

Bekannte gemeinsame Befunde aus Pilot: Outbox-Retry bei Status 20 setzt mStatus=-1 ohne WHERE; Retry-CASE ab Status 12 ohne ELSE → NULL. Nicht korrigiert. Keine Kundendaten oder Zugangswerte übertragen.

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.

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.