508 lines
30 KiB
Markdown
508 lines
30 KiB
Markdown
# 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. |
|