marcus/asv-format-validator
1
0
Fork 0
Code Pull Requests Actions Packages Releases Activity
Files
79109594aacccff097ad3257280415ec7197b9e6
asv-format-validator/docs/specs/meilensteine.md

30 KiB
Raw Blame History

Meilensteine

Dokumentversion: v3 Stand: 08.04.2026 Status: verbindliche Meilensteinstruktur für die Implementierung von Version 1 Projekt: ASV-Format-Validator Primärquelle: Spec.docx – Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026 Begleitdokumente: fachliche-anforderungen.md v4, technik-und-architektur.md v5

1. Zweck dieses Dokuments

Dieses Dokument untergliedert die Implementierung des Projekts ASV-Format-Validator in fachlich und technisch sinnvolle Meilensteine für Version 1.

Rangfolge der Dokumente:

  1. Spec.docx ist die normative fachlich-technische Wahrheit. Bei jeder Kollision gilt die Spezifikation.
  2. fachliche-anforderungen.md v4 ist der verbindliche fachliche Soll-Rahmen.
  3. technik-und-architektur.md v5 ist der verbindliche technische Soll-Rahmen.
  4. Dieses Dokument strukturiert lediglich die Umsetzung der oben genannten Grunddokumente in eine sinnvolle Reihenfolge. Es ersetzt sie nicht, reduziert sie nicht und darf ihnen nicht widersprechen.

Dieses Dokument beschreibt keine Arbeitspakete, keine KI-Prompts und keine konkreten Implementierungsschritte, sondern nur die empfohlene Reihenfolge und Abgrenzung der größeren Umsetzungsschritte für Version 1.

2. Leitplanken für die Meilensteinbildung

Für alle Meilensteine gelten verbindlich folgende Grundsätze:

  1. Es geht ausschließlich um Version 1.
  2. Die Zielbasis ist genau eine Spezifikationsversion: Technische Anlage ASV 1.09.
  3. Themen aus Ausblick.md sind nicht Bestandteil dieser Meilensteinplanung.
  4. Jeder Meilenstein muss in einem grünen, stabilen Zwischenstand enden.
  5. Die Architektur wird evolutionär weiterentwickelt, nicht in einem riskanten Komplettumbau.
  6. Fachliche Regeln, technische Parserlogik, Berichtserzeugung und Infrastruktur bleiben klar getrennt.
  7. Bereiche, die laut Anforderungen in V1 nicht belastbar prüfbar sind (V1-N), werden nicht versehentlich als harte Pflichtvalidierung umgesetzt. Bereiche mit Kategorie V1-T werden nur so weit aktiv geprüft, wie es lokal belastbar möglich ist.
  8. Die Trennung zwischen Spec-Urteil und diagnostischer Weiteranalyse ist von Anfang an architektonisch verankert, nicht erst am Ende eingeführt.

3. Überblick über die Meilensteinfolge

Meilenstein Titel Hauptnutzen
M1 Projektfundament, Logging und Ergebnismodell startbare CLI, stabile Grundarchitektur, Logging-Adapter, Befundmodell mit Spec-/Diagnose-Trennung
M2 Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln sauberes Einlesen, ISO-8859-15-Basis, Dateinamensschemata, Partnersicht
M3 EDIFACT-Serviceebene und Transportstruktur belastbare Strukturprüfung für UNA, UNB, UNH, UNT, UNZ inkl. Service-Crosschecks
M4 KKS-Auftragssatz / AUF vollständiger eigener Prüfpfad für Auftragsdateien und KKS-Crosschecks
M5 ASVREC-Kernmodell und feldgenaue Einzelregeln fachlich belastbare Validierung regulärer ASV-Abrechnungen
M6 Beziehungsregeln, Summenlogik und Storno Falllogik, Crosschecks und strukturierte Storno-Behandlung
M7 ASVFEH und Fehlernachrichtenlogik sauber getrennte Validierung von Fehlerdateien und FHL-Segmenten
M8 PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte Prüfung transportnaher bzw. verschlüsselter Eingaben bis zur inneren Nutzlast
M9 Bericht, Diagnose, Produktreife und Release-Härtung final nutzbare V1 mit stabiler Ausgabe, Qualitätssicherung und Dokumentation

4. Detaillierte Meilensteine

M1 – Projektfundament, Logging und Ergebnismodell

Ziel

Es entsteht der tragfähige technische Sockel für die weitere Implementierung, inklusive Logging-Adapter und Befundmodell mit eingebauter Spec-/Diagnose-Trennung. Die eigentliche ASV-Fachvalidierung ist hier noch nicht enthalten. Das Grundgerüst ist so geschnitten, dass alle späteren Meilensteine ohne architektonischen Umbau darauf aufbauen können.

Inhalt

  • Zielstruktur gemäß hexagonaler Architektur innerhalb des bestehenden Maven-Projekts anlegen bzw. schärfen (Paketzuschnitt gemäß technik-und-architektur.md)
  • manuellen Bootstrap mit Constructor Injection herstellen; kein DI-Framework
  • CLI-Grundaufruf mit genau einer Eingabedatei als Positionsargument herstellen
  • internes Ergebnis- und Befundmodell als stabiles Grundgerüst einführen; das Befundmodell unterscheidet von Anfang an:
    • Spec-Urteil (verbindliches Prüfurteil gemäß Spezifikation)
    • diagnostische Weiteranalyse (zusätzliche Befunde, die das Spec-Urteil niemals verändern)
  • Befundarten Fehler / Warnung / Hinweis strukturell im Modell verankern
  • Befund-Metadaten als Felder vorsehen: Artefaktschicht, Prüfstufe, Prüfbereich, Segmenttyp, Segmentindex, Feld-ID, Rohwert, Position, Nachrichtenbezug, optionaler offizieller Fehlercode
  • Logging-Adapter einführen:
    • SLF4J als Fassade
    • Log4j2 als Implementierungs-Bindung
    • konkrete Log4j2-Bindung ausschließlich im Bootstrap und im Logging-Adapter sichtbar
  • Trennung zwischen fachlichem Kern, Infrastruktur, Bericht und Logging von Anfang an sauber festziehen
  • Grundverhalten für Bericht- und Log-Datei im Eingabeverzeichnis etablieren (Berichtdatei .txt, Log-Datei .log, beide UTF-8)
  • Suffix-Logik _v1, _v2, … für Mehrfachläufe auf denselben Dateibasisnamen etablieren
  • Exit-Code-Grundgerüst (0, 1, 2) implementieren
  • Minimalbericht auch für Bedien- oder Zugriffsfehler vorsehen (Exit-Code 2)

Noch nicht Ziel von M1

  • echte EDIFACT-Nachrichtenvalidierung
  • KKS-Feldlogik
  • ASVREC-/ASVFEH-Fachmodell
  • PKCS#7-Verarbeitung
  • inhaltliche Bericht-Gestaltung

Abnahme von M1

  • Anwendung ist als JAR unter Windows mit Java 21 startbar
  • Eingabedatei wird technisch entgegengenommen; falsches oder fehlendes Argument führt zu Exit-Code 2 mit Minimalbericht
  • Bericht- und Log-Datei werden im Eingabeverzeichnis mit korrekter Suffix-Logik erzeugt
  • Log4j2-Bindung ist außerhalb von Bootstrap und Logging-Adapter nicht sichtbar
  • Befundmodell trennt Spec-Urteil und Diagnose strukturell
  • Build und Tests sind grün

M2 – Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln

Ziel

Die Anwendung kann lokale Eingabedateien robust lesen, technisch einordnen und als äußeres Artefakt sauber modellieren. Die globalen fachlichen Rahmenregeln und die Dateinamenskonventionen der Spezifikation sind als harte Prüfregeln umgesetzt.

Inhalt

  • read-only Dateisystemzugriff in einem Infrastruktur-Adapter kapseln
  • Eingaben konsequent mit ISO 8859-15 behandeln; keine Plattform-Default- oder stillschweigende UTF-8-Dekodierung
  • äußeres Artefaktmodell aufbauen:
    • physische Datei
    • Dateiname
    • Extension
    • mutmaßliche Artefaktart
    • erkannte Schichten
  • automatische Dateityperkennung und explizite Benutzervorgabe als gleichrangige Eingänge umsetzen; bei Widerspruch wird die Benutzervorgabe verarbeitet und zusätzlich eine Warnung erzeugt (kein Abbruch allein wegen Widerspruch)
  • Dateinamensschemata gemäß Spezifikation als harte Prüfregeln umsetzen:
    • unverschlüsselt: B<VKNR><Jahr><Quartal><Zähler> (11 Stellen)
    • verschlüsselt: <IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>
    • Auftragsdatei: identischer Basisname wie die zugehörige verschlüsselte Datei, Endung .AUF
  • Übermittlungszähler prüfen: Wertebereich 001–999, 3-stellig numerisch; V1 prüft keine quartalsübergreifende Folgesequenz, markiert diese Grenze aber als bewusste V1-Einschränkung im Bericht
  • globale fachliche Rahmenregeln umsetzen (aus fachliche-anforderungen.md §5.1):
    • ISO 8859-15 als Verfahrens-Zeichensatz, nur darstellbare Zeichen
    • ASV-Dateien werden unkomprimiert übertragen
    • eine Datei pro Kasse, keine kassenübergreifende Bündelung
    • keine erzwungene Sortierreihenfolge der Nachrichten innerhalb einer Datei
  • exakte Partnerdatei-Ableitung für die zugehörige .AUF bzw. die zugehörige Transportdatei herstellen (deterministisch, nicht heuristisch)
  • fehlende oder nicht passende Partnerdatei als Warnung modellieren, nicht als Abbruch

Noch nicht Ziel von M2

  • tiefe Service-Segment-Validierung
  • KKS-Feldprüfung
  • fachliche Segmentbeziehungen in ASVREC

Abnahme von M2

  • äußere Datei wird robust gelesen, mit ISO 8859-15 dekodiert und klassifiziert
  • Dateinamensschemata werden feldgenau geprüft
  • Übermittlungszähler-Wertebereich wird geprüft und die V1-Einschränkung ist im Bericht kenntlich
  • die vier globalen Rahmenregeln aus §5.1 sind als eigene Regelbausteine umgesetzt
  • Partnerdateien werden deterministisch gesucht, nicht heuristisch geraten
  • Widerspruch zwischen Auto-Erkennung und Benutzervorgabe wird als Warnung erzeugt, ohne Abbruch
  • Build und Tests sind grün

M3 – EDIFACT-Serviceebene und Transportstruktur

Ziel

Die Anwendung kann die EDIFACT-Hüllstruktur zuverlässig parsen und die lokalen Prüfregeln der Stufen 1 und 2 auf Service-Ebene belastbar anwenden.

Inhalt

  • Parsing für UNA, UNB, UNH, UNT, UNZ
  • UNA als optionales Segment behandeln; Fallback auf die ASV-konformen Standardtrennzeichen, wenn UNA fehlt
  • Prüfung der Trennzeichen und ihrer Gültigkeit
  • technische Segmentgrenzen, Nachrichtenhüllen und Nachrichtenanzahl bestimmen
  • Service-Crosschecks umsetzen:
    • physischer Dateiname ↔ UNB_0020 (UNB_0020 ist die Übertragungsreferenz bzw. der Dateiname der Übertragung, nicht die Senderkennung)
    • UNB_0020 ↔ UNZ_0020 (Referenzgleichheit von Übertragungskopf und -ende)
    • UNH_0062 ↔ UNT_0062 je Nachricht (Referenzgleichheit von Nachrichtenkopf und -ende)
    • UNZ_0010 (Nachrichtenzähler) ↔ tatsächliche Anzahl der UNH/UNT-Paare
    • Testindikator UNB 0035: Echtdaten-/Testdaten-Konsistenz mit der E/T-Kennung im physischen Dateinamen; Wert 1 nur für Testübertragungen
  • Konsistenzprüfungen, die den KKS-Auftragssatz voraussetzen (insbesondere die Abstimmung zwischen UNB 0035/Dateiname und KKS-VERFAHREN_KENNUNG), sind nicht Bestandteil von M3 und werden in M4 zusammen mit den KKS-Crosschecks umgesetzt
  • unbekannte oder fremde Segmente nicht vorschnell verwerfen, sondern diagnostisch sichtbar halten
  • Spec-Urteil und diagnostische Weiteranalyse strikt trennen (Befundklassifizierung bereits beim Erzeugen)
  • parse-nahe Sofortprüfungen bleiben auf strukturelle und technische Befunde beschränkt (Lesbarkeit, Zeichensatz, Trennzeichen, grobe Segment- und Feldfehler); fachliche Regeln, feldwertbezogene Plausibilitäten und Bezugskontrollen gehören nicht in den Parser

Noch nicht Ziel von M3

  • KKS-Auftragssatz im Detail
  • fachliche Feldregeln der Nutzdaten
  • Katalog- oder Bestandsprüfungen

Abnahme von M3

  • Service-Segmente werden robust erkannt und geparst (mit und ohne UNA)
  • die in M3 genannten Crosschecks sind umgesetzt und als eigene Regeln nachweisbar
  • typische Stufe-1- und Stufe-2-Strukturfehler können belastbar gemeldet werden
  • Build und Tests sind grün

M4 – KKS-Auftragssatz / AUF

Ziel

Der KKS-Auftragssatz wird als eigenständiger, vollwertiger Prüfgegenstand umgesetzt und nicht als Anhängsel der Nutzdatendatei behandelt. Eine .AUF-Datei kann auch eigenständig (als einzige Eingabedatei pro Lauf) validiert werden.

Inhalt

  • Parser für den festen KKS-Auftragssatz aufbauen
  • vollständige Umsetzung der KKS-Feldregeln gemäß fachliche-anforderungen.md §9. Die nachfolgende Liste ist nicht abschließend, sondern nennt zentrale Anker; maßgeblich ist §9.
  • zentrale Festwerte und Strukturprüfungen:
    • IDENTIFIKATOR = 500000
    • VERSION = 01
    • LÄNGE_AUFTRAG = 00000348
    • SEQUENZ_NR = 000 (keine Teillieferungen)
    • VERFAHREN_KENNUNG: Stelle 20 E/T, Stellen 21–23 ASV, Stelle 24 0
    • VERFAHREN_KENNUNG_SPEZIFIKATION als Kann-Feld: Blank zulässig; wenn belegt, nur aus der definierten Wertemenge (ASVA0 für Abrechnung, ASVF0 für Fehlermeldung)
    • TRANSFER_NUMMER: Wertebereich 001–999
    • DATUM_ERSTELLUNG: 14-stellig JJJJMMTThhmmss, formal prüfen
    • DATEIVERSION = 000000
    • KORREKTUR = 0
    • FEHLER_NUMMER = 000000, FEHLER_MASSNAHME = 000000
    • ZEICHENSATZ = I5 (formaler Anker für die ISO-8859-15-Annahme der gesamten Anwendung)
    • KOMPRIMIERUNG = 00
    • VERSCHLÜSSELUNGSART = 03
    • ELEKTRONISCHE_UNTERSCHRIFT = 03
  • Kommunikationspartner-Felder (ABSENDER_EIGNER, ABSENDER_PHYSIKALISCH, EMPFÄNGER_NUTZER, EMPFÄNGER_PHYSIKALISCH): strukturell und formal auf IK-Format prüfen. Eine inhaltliche Kommunikationspartnerprüfung ist ohne Referenzbestände in V1 nicht belastbar möglich und daher nicht Gegenstand von M4 (V1-T)
  • Kann-Felder des KKS nach Nichtbelegungsregeln prüfen:
    • numerisch → Nullfüllung (HEX 30)
    • alphanumerisch → Blankfüllung (HEX 20)
  • KKS-Crosschecks:
    • TRANSFER_NUMMER ↔ Zähler im physischen Dateinamen
    • Dateinamensbezug (Begriffsklärung):
      • der physische Dateiname der verschlüsselten Übertragungsdatei folgt dem Schema <IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>
      • die zugehörige Auftragsdatei trägt denselben physischen Basisnamen und endet auf .AUF
      • UNB_0020 trägt, sobald die EDIFACT-Schicht vorliegt, die Übertragungsreferenz und entspricht dem Dateinamen der Übertragung
      • die KKS-DATEINAME-Angabe im Auftragssatz entspricht dem unverschlüsselten Dateinamen nach dem Schema B<VKNR><Jahr><Quartal><Zähler>
      • zu prüfen sind: KKS-DATEINAME gegen den aus Schema und Kontext abgeleiteten unverschlüsselten Dateinamen sowie – soweit beide Schichten vorliegen – die Konsistenz zwischen physischem Dateinamen der Übertragung, UNB_0020 und KKS-DATEINAME
    • DATEIGRÖSSE_NUTZDATEN gegen die tatsächliche Bytegröße der unverschlüsselten Nutzdatendatei, soweit die unverschlüsselte Schicht lokal vorliegt
    • DATEIGRÖSSE_ÜBERTRAGUNG gegen die tatsächliche Bytegröße der verschlüsselten Übertragungsdatei
    • Echtdaten-/Testdaten-Konsistenz zwischen Dateiname, KKS-VERFAHREN_KENNUNG und – soweit vorhanden – UNB 0035

Noch nicht Ziel von M4

  • vollständige fachliche ASVREC-Regelvalidierung
  • ASVFEH-Fachlogik
  • PKCS#7-Tiefenprüfung

Abnahme von M4

  • .AUF-Dateien sind eigenständig validierbar
  • die Regeln aus fachliche-anforderungen.md §9 sind umgesetzt
  • KKS-Festwerte und Feldlogik sind belastbar geprüft
  • KKS-Crosschecks funktionieren technisch sauber
  • AUF-bezogene Befunde sind im Ergebnis klar von EDIFACT-Nutzdaten-Befunden getrennt
  • Build und Tests sind grün

M5 – ASVREC-Kernmodell und feldgenaue Einzelregeln

Ziel

Reguläre ASV-Abrechnungsnachrichten (ASVREC) werden fachlich auf Segment- und Feldebene belastbar validierbar, soweit dies lokal ohne Referenzbestände möglich ist.

Inhalt

  • kanonisches internes Modell für ASVREC aufbauen
  • Segmentabbildung für die ASVREC-Nutzsegmente gemäß Spezifikation: IFA, DGN, LEA, SAC, GEN, OPA, REA, IVA
  • feldgenaue Regeln gemäß Fachlichen Anforderungen umsetzen, soweit in V1 lokal belastbar
  • Muss-/Kann-Logik und Vorkommensregeln pro Segment und Feld umsetzen
  • formale Prüfungen für Typ, Länge, Format, Schlüsselwerte und Sonderformate umsetzen
  • Versichertennummer-Strukturprüfung (IVA 8.3.1) umsetzen:
    • Stelle 1: Alpha A–Z ohne Umlaute
    • Stellen 2–9: numerisch
    • Stelle 10: Prüfzifferstelle vorhanden (keine algorithmische Prüfziffernvalidierung in V1)
  • zentrale Sonderregeln und Ausnahmen korrekt berücksichtigen – diese dürfen nicht fälschlich als Fehler gemeldet werden:
    • Geburtsdatum im Ersatzverfahren (IVA 8.4.3): im Format JJJJMMTT sind beliebige numerische Werte zulässig, zusätzlich die Platzhalter 00 (unbekannter Tag), 0000 (unbekannter Tag und Monat) und 00000000 (vollständig unbekannt); eine Datumsplausibilisierung in diesem Feld ist unzulässig
    • negative numerische Werte: das führende Minuszeichen zählt nicht zur maximalen Feldlänge
    • Dezimalzeichen , zählt nicht zur maximalen Feldlänge
    • Pseudo-GOP 88999 sowie regionale Pseudo-GOP sind für Sachkosten ohne Sachzusammenhang zulässig
    • GOÄ-Sonderfall: in 3/3.2.1 wird die Pseudo-GOP übertragen, in 3/3.2.5 die zugehörige GOÄ-Ziffer
    • obsolete Muss-Felder 4/4.2.4 und 4/4.2.5: füllpflichtig mit beliebigem Inhalt, aber nicht ausschließlich Leerzeichen; inhaltlich werden diese Felder nicht geprüft
  • Vertretungs-Teamebene 4: Die Spezifikation legt fest, dass bei Teamebene 4 die Teamebene des Vertretenen maßgeblich ist. Eine belastbare Prüfung dieser Regel setzt einen Abgleich mit dem ASV-Verzeichnis voraus und ist in V1 ohne Referenzbestände nicht möglich (V1-N). V1 erzwingt deshalb insbesondere keine Plausibilitäten auf Teamebene 4 und markiert diesen Bereich als bewusst nicht geprüft.
  • ausdrücklich keine referenzbestandsabhängigen Prüfungen erzwingen (V1-N-Bereich: ICD, OPS, IK, BSNR, LANR, Teamnummer inhaltlich)
  • Bereiche mit V1-N im Bericht als „bewusst nicht geprüft" kenntlich machen

Noch nicht Ziel von M5

  • fallübergreifende bzw. komplexe Crosschecks
  • Storno-Sonderstruktur
  • ASVFEH
  • PKCS#7

Abnahme von M5

  • reguläre ASVREC-Nachrichten können segment- und feldgenau validiert werden
  • die genannten Sonderwerte und Ausnahmen werden nicht fälschlich als Fehler behandelt
  • die Versichertennummer-Strukturprüfung ist umgesetzt
  • lokal nicht belastbar prüfbare Bereiche bleiben sauber abgegrenzt und als V1-N markiert
  • das kanonische Modell ist stabil genug für Beziehungsregeln im nächsten Meilenstein
  • Build und Tests sind grün

M6 – Beziehungsregeln, Summenlogik und Storno

Ziel

Die fallinterne Logik von ASV-Abrechnungen wird vollständig genug, um reguläre Rechnungen und Storno-Fälle fachlich konsistent zu beurteilen.

Inhalt

  • segmentübergreifende Crosschecks umsetzen, insbesondere:
    • DGN erforderlich bei regulärer Rechnung (REA 7.2.4 = 0)
    • LEA erforderlich bei regulärer Rechnung
    • Summenprüfung Rechnungsbetrag (REA) gegen LEA und SAC, soweit ohne externe Bestände lokal möglich
    • Überweiserkontext ↔ Diagnoseart (IFA 1.3.1 / DGN 2.2.5)
    • externer und interner Überweiser nicht gleichzeitig (IFA 1.3.1 / 1.3.2)
    • Pflicht-GEN bei bestimmten GOPs
  • Regeln für Pseudo-GOP, GOÄ-Sonderfall und Sachkosten-Sonderkonstellationen umsetzen, soweit lokal belastbar
  • Konsistenzprüfung zur globalen Regel „eine Datei pro Kasse" auf Basis der lokal verfügbaren Kassenbezüge (Andockstelle an die globale Rahmenregel aus M2)
  • Storno als eigene Strukturvariante von ASVREC sauber modellieren:
    • reduzierte Segmentstruktur: nur die in der Spezifikation für Storno vorgesehenen Muss-Segmente und Muss-Felder
    • bei Storno unzulässige Segmente gemäß Spezifikation: DGN, LEA, SAC, GEN, OPA – ihr Vorhandensein ist ein Fehler
    • Rechnungskennzeichen Storno (REA 7.2.4 = 1)
    • Rechnungsbetrag bei Storno REA 7.2.1 = 0,00
    • Bezug auf die ursprüngliche Rechnungsnummer, soweit lokal prüfbar
  • saubere Vermeidung, dass Storno-Pflichten als „normale Rechnungspflichten" missbraucht werden und umgekehrt

Noch nicht Ziel von M6

  • Validierung von ASVFEH
  • PKCS#7-Tiefenprüfung

Abnahme von M6

  • reguläre Rechnungen und Storno-Nachrichten werden sauber unterschieden
  • die in M6 genannten segmentübergreifenden ASVREC-Regeln greifen
  • Summen- und Strukturfehler werden fachlich nachvollziehbar ausgewiesen
  • Storno wird als eigene Variante behandelt; bei Storno unzulässige Segmente werden erkannt
  • Build und Tests sind grün

M7 – ASVFEH und Fehlernachrichtenlogik

Ziel

Fehlernachrichten (ASVFEH) werden als eigener Nachrichtentyp mit eigener Struktur und eigenen Regeln vollständig separat validiert.

Inhalt

  • eigenes kanonisches Modell für ASVFEH einführen
  • beide Strukturvarianten unterstützen:
    • eigenständige Fehlerdatei (typisch Stufe 1): UNB, UNH mit Nachrichtentyp ASVFEH, FHL, UNT, UNZ
    • eingebettete Fehlernachricht mit Originalnutzdaten (typisch Stufen 2–4): UNH, Originalnutzdatensegmente, FHL, UNT
  • FHL-Segmentlogik umsetzen (Spezifikation sieht bis zu 99 Vorkommen vor)
  • Prüfung von Fehlercode, Fehlertext, Referenzen, Storno-/Korrekturkennzeichen und weiteren FHL-Feldern, soweit lokal belastbar
  • Regel abbilden: Kann-Datenelemente im FHL werden zu Muss-Datenelementen, wenn ihre Ermittelbarkeit aus der Fehlersituation belastbar ableitbar ist. V1 setzt dies nur dort als Fehler um, wo diese Ableitbarkeit aus der vorliegenden Datei wirklich gegeben ist.
  • Umgang mit Originalnachricht explizit umsetzen:
    • die mitgelieferte Originalnachricht wird nicht als eigenständiger ASVREC-Validierungsgegenstand behandelt
    • die Abwesenheit der Originalnachricht bei Prüfstufen 2–4 ist kein Fehler, sondern höchstens ein Hinweis, da die Originalnutzdaten laut Spezifikation nicht lesbar oder nicht syntaxkonform übertragbar gewesen sein dürfen
    • die Verfahrensregel „eine Fehlernachricht darf nicht mit einer Fehlernachricht beantwortet werden" wird nicht als Validierungsregel umgesetzt, da sie an einer einzelnen isoliert übergebenen Datei nicht prüfbar ist (V1-N)
  • Vorrang spezifischer offizieller Fehlercodes vor Sammelcodes (xx999, 3A998, 4A998) berücksichtigen

Noch nicht Ziel von M7

  • PKCS#7-Tiefenprüfung
  • finale Berichtsveredelung

Abnahme von M7

  • ASVFEH ist sauber von ASVREC getrennt
  • beide ASVFEH-Strukturvarianten werden korrekt erkannt
  • FHL-Segmente sind feldgenau modelliert und strukturell für bis zu 99 Vorkommen unterstützt
  • das Fehlen der Originalnachricht bei Stufen 2–4 erzeugt keinen harten Fehler
  • offizielle Fehlercodebezüge können belastbar an Befunde angehängt werden; Sammelcodes werden nur genutzt, wenn kein spezifischerer offizieller Code einschlägig ist
  • Build und Tests sind grün

M8 – PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte

Ziel

Die Anwendung kann verschlüsselte bzw. transportnahe Artefakte technisch verarbeiten und – soweit Material nutzbar bereitgestellt wurde – bis zur inneren Nutzlast durchsteigen. Die Tiefenprüfung nutzt die bereits in M3–M7 gebaute Validierungskette erneut; es entsteht keine zweite, parallele Validierungslogik.

Inhalt

  • Krypto-Adapter hinter stabilen Ports einführen; Krypto-Verarbeitung erfolgt innerhalb der Java-Anwendung, keine externen Tools oder Binaries
  • explizite CLI-Übergabe von Schlüssel- und Passwortmaterial anbinden (konkrete Optionsnamen in der README dokumentiert)
  • Basisprüfung verschlüsselter Artefakte auch ohne nutzbares Material ermöglichen
  • Fallback-Verhalten sauber umsetzen: Warnung statt Totalabbruch, wenn Material technisch nicht nutzbar ist
  • nach erfolgreicher Entschlüsselung automatisch bis zur inneren fachlichen Schicht weiterarbeiten, indem die bereits bestehende Validierungskette aus M3–M7 auf die entschlüsselte Nutzlast angewendet wird
  • Mindestalgorithmusprüfungen gemäß technischem Soll-Rahmen modellieren, insbesondere:
    • PKCS#7 als Containerformat
    • AES-256-CBC als Session Key
    • RSA 4096 Bit als Interchange Key
    • SHA256withRSAandMGF1 / PSS
    • RSA-Exponent Fermat-4 (2^16 + 1)
  • Nicht-PSS-Altverfahren müssen in V1 nicht aktiv unterstützt werden, dürfen aber als erkannte Abweichung gemeldet werden
  • Abweichungen sauber als technische Befunde modellieren
  • Krypto-Integration bleibt sauber von Domain und Application entkoppelt; Krypto-Typen sind außerhalb des Krypto-Adapters und des Bootstrap nicht sichtbar

Noch nicht Ziel von M8

  • zusätzliche Transportkanäle
  • E-Mail- oder Serverintegration
  • Mehrdateimodus

Abnahme von M8

  • verschlüsselte Artefakte sind technisch analysierbar
  • mit gültigem Material ist Tiefenprüfung bis zur Nutzlast möglich; das Ergebnis ist konsistent zu dem, was eine Direktvalidierung der unverschlüsselten Datei liefern würde
  • ohne nutzbares Material erfolgt nachvollziehbare Basisprüfung mit Warnung, kein Totalabbruch
  • Krypto-Integration ist entkoppelt
  • Build und Tests sind grün

M9 – Bericht, Diagnose, Produktreife und Release-Härtung

Ziel

Die bis dahin umgesetzte Funktionalität wird zu einer sauberen, benutzbaren und abnahmereifen Version 1 zusammengeführt.

Inhalt

  • finalen hierarchischen Bericht stabilisieren:
    • Datei
    • Schichten
    • Nachrichten/Fälle
    • Befunde
  • strukturierte Bestandsinformationen in den Bericht aufnehmen: erkannter Dateityp, erkannte Schichten, Anzahl Nachrichten/Fälle, relevante Kopfdaten, Übermittlungszähler, spec-konformes Prüfurteil, zusätzliche diagnostische Auffälligkeiten
  • klare Trennung zwischen Spec-Urteil und diagnostischer Weiteranalyse final durchziehen (architektonisch seit M1 vorhanden, hier nur in der Darstellung konsolidiert)
  • Befunde mit Metadaten und – soweit eindeutig – offiziellen Fehlercodes anreichern; Vorrangregel für Sammelcodes einhalten
  • Konsolenausgabe und Berichtdatei fachlich gleichziehen
  • technisches Logging sauber vom Bericht trennen
  • README und Nutzungsdokumentation vervollständigen, inklusive CLI-Optionsnamen und der PKCS#7-Materialübergabe
  • umfangreiche End-to-End-Testartefakte ergänzen: Parser-, KKS-, ASVFEH- und Storno-Fälle mit synthetischen, anonymisierten Testdaten
  • letzte Robustheits- und Randfalllücken schließen

Quality-Gates für Version 1 (verbindlich)

  • Build grün
  • alle Tests grün
  • Coverage gesamtprojektweit ≥ 85 %
  • PIT-Mutation-Score gesamtprojektweit ≥ 70 %
  • differenzierte Zielschwellen gemäß technik-und-architektur.md:
Bereich Coverage Mutation
domain ≥ 95 % ≥ 85 %
application ≥ 90 % ≥ 80 %
adapter.out.* ≥ 90 % ≥ 75 %
adapter.in.cli ≥ 80 % ≥ 60 %
bootstrap ausgenommen ausgenommen
  • Abweichungen von den Schwellwerten sind nur mit dokumentierter Begründung zulässig

Noch nicht Ziel von M9

  • GUI
  • Batch-Verarbeitung
  • Mehrversionssupport
  • Referenzdatenbestände
  • spätere Erweiterungen aus Ausblick.md

Abnahme von M9

  • Version 1 ist fachlich und technisch in sich geschlossen nutzbar
  • Bericht und Logging sind stabil, verständlich und sauber getrennt
  • Spec-Urteil wird nie durch Diagnose „grün gerechnet"
  • alle Quality-Gates sind erreicht oder bewusst dokumentiert abgewichen
  • das Projekt ist bereit für nachgelagerte Feinschnitte in Arbeitspakete

5. Empfohlene Umsetzungslogik für die spätere Arbeitspaketbildung

Aus dieser Meilensteinstruktur ergibt sich für die spätere Arbeitspaketbildung folgende sinnvolle Logik:

  1. Zuerst immer den tragfähigen Unterbau herstellen – inklusive Logging und Befundmodell mit Spec-/Diagnose-Trennung.
  2. Danach die äußere technische Struktur, die globalen Rahmenregeln und den KKS-Auftragssatz stabilisieren.
  3. Erst dann die fachliche Tiefe von ASVREC aufbauen.
  4. Storno und ASVFEH nicht vermischen, sondern als eigene Prüfdimensionen schneiden.
  5. PKCS#7 erst aufsetzen, wenn die innere Nutzlastvalidierung bereits stabil steht; die bestehende Kette wird wiederverwendet.
  6. Produktreife, Bericht, Doku und Qualitäts-Härtung am Ende konsolidieren.

6. Definition of Done über alle Meilensteine hinweg

Ein Meilenstein gilt nur dann als sinnvoll abgeschlossen, wenn mindestens die folgenden Punkte erfüllt sind:

  • der Stand ist fachlich und technisch konsistent zu den Grunddokumenten
  • Build und zugehörige Tests sind grün
  • der Meilenstein erzeugt keinen architektonischen Widerspruch zu den Grunddokumenten
  • nicht prüfbare V1-N- und nur teilprüfbare V1-T-Bereiche wurden nicht versehentlich als harte Pflichtprüfung umgesetzt
  • keine Elemente aus späteren Ausbaustufen wurden unbemerkt in Version 1 hineingezogen
  • die im jeweiligen Meilenstein genannten Abnahmekriterien sind erfüllt
  • der Stand ist stabil genug, um daraus anschließend Arbeitspakete abzuleiten

Die finalen Quality-Gates für Version 1 (Coverage, Mutation, Zielschwellen pro Paket) gelten am Ende von M9. Zwischenmeilensteine müssen lediglich grün sein, nicht die finalen Schwellwerte vorwegnehmen.

7. Zusammenfassung

Die Implementierung von Version 1 sollte nicht entlang technischer Zufälle, sondern entlang einer klaren fachlich-technischen Reifung erfolgen:

  • zuerst Grundgerüst, Logging und Befundmodell mit Spec-/Diagnose-Trennung,
  • dann Artefaktschicht, Dateinamen und globale Rahmenregeln,
  • dann Service- und KKS-Ebene,
  • danach ASVREC mit Beziehungslogik und Storno,
  • anschließend ASVFEH,
  • danach PKCS#7-Tiefenprüfung unter Wiederverwendung der bestehenden Kette,
  • und zum Schluss Bericht, Qualität und Release-Härtung.

Damit entsteht eine Meilensteinfolge, die klein genug für kontrollierte Weiterentwicklung bleibt, aber groß genug ist, um daraus später präzise und in sich geschlossene Arbeitspakete abzuleiten.

8. Dokumenthistorie

Version Wesentliche Änderungen
v1 Erstfassung mit Meilensteinfolge M1–M9
v2 Logging-Adapter und Spec-/Diagnose-Trennung als Fundament in M1 verankert; Dateinamensschemata und globale Rahmenregeln in M2 ergänzt; Service-Crosschecks in M3 vollständiger; KKS-Regelsatz in M4 erweitert und eigenständige .AUF-Validierbarkeit klargestellt; Sonderregeln in M5 ergänzt; Umgang mit Originalnachricht in M7 präzisiert; Wiederverwendung der Validierungskette in M8 explizit; Quality-Gates in M9 mit Zahlen.
v3 Zweck entschärft und Rangfolge der Grunddokumente klargestellt (Spec.docx als Wahrheit; meilensteine.md strukturiert lediglich). M3: Crosscheck physischer Dateiname ↔ UNB_0020 korrekt als Übertragungsreferenz benannt (nicht „Senderkennung"); Vorgriff auf KKS-VERFAHREN_KENNUNG aus M3 entfernt und nach M4 verschoben. M4: Dateinamensbezug (physischer Dateiname, UNB_0020, KKS-DATEINAME, .AUF-Basisname) sauber begrifflich getrennt; unscharfe „bzw."-Formulierung ersetzt. M5: regionale Pseudo-GOP neben 88999 ausdrücklich aufgenommen; Vertretungs-Teamebene 4 als V1-N gekennzeichnet statt als aktive Prüfung; NAD-Hinweis entfernt. Gesamtes Dokument: in v2 eingeführte Zwischen-Quality-Gates (Coverage/Mutation pro Meilenstein) entfernt, da nicht aus den Grunddokumenten folgend; finale Gates bleiben in M9 erhalten. V1-T-Sprachregelung in den Leitplanken präzisiert. Kleinere sprachliche Glättungen.
View Git Blame Copy Permalink