Squashed 'bahn/wissensdatenbank/' content from commit 07a8196e
git-subtree-dir: bahn/wissensdatenbank git-subtree-split: 07a8196e5f9e55d027f90485beb95f4006387669
This commit is contained in:
@@ -0,0 +1,177 @@
|
||||
---
|
||||
domain: "pathos"
|
||||
tool: "pathos"
|
||||
scope: "intern"
|
||||
tags: ["domain:pathos", "tool:pathos", "scope:intern", "pathos", "taf-tap-tsi"]
|
||||
owners: ["einfachbahn@deutschebahn.com"]
|
||||
contact: "einfachbahn@deutschebahn.com"
|
||||
component_type: "page"
|
||||
source: "confluence"
|
||||
source_version: "16"
|
||||
meta_fingerprint: "f8016101b3b52f2d"
|
||||
url: "https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/573777749/Stornierung+durch+Kunde"
|
||||
last_updated: "2026-06-30"
|
||||
review_status: "approved"
|
||||
review_notes: ""
|
||||
content_hash: "7885ce7fb7f2d922"
|
||||
---
|
||||
|
||||
Bearbeitungsstand|
|
||||
---|---
|
||||
Ansprechpartner|
|
||||
Letzte große Aktualisierung|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Technische Abbildung des Verkehrszeitraums
|
||||
|
||||
### Bisherige Logik (vor TTT)
|
||||
|
||||
Bislang war eine Zugtrasse durch einen Verkehrszeitraum sowie einen Verkehrstageschlüssel definiert, der die Tage des Verkehrs innerhalb dieses Zeitraums festlegte.
|
||||
Sollte ein Zug an einzelnen Tagen nicht verkehren, wurde dies nicht durch eine Änderung des Vertrags oder dessen Gültigkeitszeitraums abgebildet. Der Vertrag einschließlich Verkehrszeitraum und Verkehrstageschlüssel blieb unverändert.
|
||||
|
||||
Stattdessen wurde der Zug für diese Tage "ausgelegt": Die Information über das Nicht‑Verkehren an einzelnen Tagen wurde über die NSS mittels Ausfalltagen übertragen (fachlich häufig auch als _Auslegung an der NSS_ bezeichnet). Ausfalltage waren damit ein Abweichungs‑ bzw. Betriebsinstrument, kein strukturelles Planungsmerkmal des Vertrags.
|
||||
|
||||
### Logik mit TTT
|
||||
|
||||
Mit der Einführung von TTT existiert kein übergreifender Verkehrszeitraum mit separat gepflegtem Verkehrstageschlüssel mehr.
|
||||
Stattdessen besitzt der Path (Vertrag):
|
||||
|
||||
* ein Start‑ und Enddatum sowie
|
||||
* einen Kalender, der technisch als Bitleiste umgesetzt ist.
|
||||
|
||||
|
||||
|
||||
Ob ein Zug an einem bestimmten Kalendertag fährt, ergibt sich ausschließlich daraus, ob für diesen Tag eine „1“ in der Bitleiste (Kalender) gesetzt ist.
|
||||
|
||||
Mehrere Paths bzw. Verträge dürfen sich zeitlich überlappen, sofern die in den jeweiligen Kalendern gesetzten Verkehrstage zueinander disjunkt sind (keine Überschneidung gesetzter „1en“). Das bedeutet, dass ein Vertragstag eines Zuges nur in einem Vertrag enthalten sein darf.
|
||||
|
||||
## Zeitliche Teilstornierung
|
||||
|
||||
Es ist möglich eine Trasse über eine Teilstornierung (TOI=33) an allen ihren Verkehrstagen auf einem Teillaufweg zu stornieren. Nähere Informationen befinden sich im Kapitel [5.3.13 Stornierung ](https://www.dbinfrago.com/resource/blob/13705098/414d1181ff1ccb1516e08d53c1e34694/Dokumentationen-der-EVU-Schnittstelle-data.pdf) der Schnittstellendokumentation.
|
||||
|
||||
Den genauen Prozess und die Geschäftsvorfallfolge dazu zeigt Abbildungen 10 in der [Dokumentation der Schnittstelle des Bestellsystems der DB InfraGO AG für EVU-Systeme](https://www.dbinfrago.com/resource/blob/13705098/414d1181ff1ccb1516e08d53c1e34694/Dokumentationen-der-EVU-Schnittstelle-data.pdf).
|
||||
|
||||
Abb. 10 ("Geschäftsvorfallfolgen im Gelegenheitsverkehr – Folgegeschäftsvorfälle und Messages für Stornierungen gebuchter Trassen durch das EVU"):
|
||||
|
||||
[[Bild: https://arija.jaas.service.deutschebahn.com/secure/thumbnail/332990/_thumb_332990.png]](https://arija.jaas.service.deutschebahn.com/secure/attachment/332990/332990_Hauptdokument+Abbildung+10.png "Hauptdokument Abbildung 10.png")
|
||||
|
||||
Der Abfolge aus Abbildung 10 heraus müsste im Anschluss an die Angebotsannahme über die geänderte Trasse durch den Kunden dann
|
||||
|
||||
* zunächst eine PDM TOI=22 MS=1 mit neuer PAID (Buchungsbestätigung für neue Trasse mit reduziertem Laufweg) gesendet werden
|
||||
* danach noch eine PDM mit TOI=22 MS=2 (Information über nicht stornierten Trassenanteil), obwohl es in einem solchen Falle gar keinen nicht-stornierten Trassenanteil gibt. In der Schnittstellenbeschreibung V4.6.2 ist näher definiert, dass bei vollständiger Stornierung der Kalender keine BitmapDays mehr besitzt.
|
||||
|
||||
|
||||
|
||||
Eine Stornierungsbestätigung für die alte Trasse PAID (PDM TOI=22 MS=3 mit alter PAID) erfolgt derzeit nicht, daher ist die auch wie in Abb. 10 ersichtlich nicht aufgeführt.
|
||||
|
||||
|
||||
|
||||
|
||||
In Abbildung 9 wird die Änderungsbestellung dargestellt. Dort ist der Vorgang anders als bei der Teilstornierung. Dort wird an dieser sinngemäß gleichen Stelle zumindest die "Information über nicht stornierten Trassenanteil" übersprungen. An einer verbesserten Kommunikation für diese Fälle wird laut Fabian Sommer auf europäischer Ebene gearbeitet.
|
||||
|
||||
[[Bild: https://arija.jaas.service.deutschebahn.com/secure/thumbnail/332991/_thumb_332991.png]](https://arija.jaas.service.deutschebahn.com/secure/attachment/332991/332991_Hauptdokument+Abbildung+9.png "Hauptdokument Abbildung 9.png")
|
||||
|
||||
|
||||
|
||||
|
||||
### Technische Umsetzung der zeitlichen Teilstornierung und NSS‑Übergabe
|
||||
|
||||
Eine zeitliche Teilstornierung wird im TTT‑Modell dadurch umgesetzt, dass gesetzte Verkehrstage im Kalender entfernt werden (technisch: Bits werden von „1“ auf „0“ gesetzt).
|
||||
|
||||
An die NSS können dabei nur zusammenhängende Zeiträume mit gültigen Verkehrstagen („1en“) übergeben werden. Unterbrechungen im Kalender führen folglich zu getrennten Übergaben mehrerer Zeiträume.
|
||||
|
||||
Das frühere Konzept der Ausfalltage wird in diesem Modell nicht mehr als primäres fachliches Instrument genutzt, da Nicht‑Verkehr vollständig durch kalendarische Gültigkeit abgebildet wird.
|
||||
|
||||
|
||||
|
||||
|
||||
### Technischer Ablauf rämliche (Teil-) Stornierung
|
||||
|
||||
Ziel ist es gemeinsam den Gesamtprozess zu beschreiben, verifizeren und dem Testteam als Guide an die Hand für den E2E-Test zu geben.
|
||||
|
||||
|
||||
|
||||
|
||||
Voraussetzung:
|
||||
|
||||
RuT-K
|
||||
|
||||
* Vertragswirksame Regeltrasse existiert
|
||||
* Auf der Vertragstrasse liegt eine Bautrasse in Arbeit.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
System| Auftragsart| Auftragstyp| Interne Verarbeitung (Ablauf im Teilsystem)| Übergabe an
|
||||
---|---|---|---|---
|
||||
TPN| Stornierung| 8 RS| TPN berechnet ein abgeleitetes Feld AFT_RAEUML_STORNO, das angibt, ob es sich bei einem Typ 8 (oder Typ 10) um eine räumliche Teilstornierung (RS) handelt.Die Logik in der SQL-View lautet: (Quelle: [delivery/oracle/src/main/templates/database/currentChanges.sql · develop · TPN / TPN Codebase · GitLab](https://git.tech.rz.db.de/tpn/tpn-codebase/-/blob/develop/delivery/oracle/src/main/templates/database/currentChanges.sql))CASE WHEN AFT_LEGUNG_BEGINN_BST_ID is not null AND AFT_TYP IN (8, 10) AND tta.TTA_ID is not null THEN 1 ELSE 0END AS AFT_RAEUML_STORNODas bedeutet:TPN prüft bei Typ 8 (und Typ 10), ob das Feld AFT_LEGUNG_BEGINN_BST_ID gefüllt ist (= es gibt eine Start-Betriebsstelle für den zu stornierenden Abschnitt) und ob ein zugehöriger TTA-Eintrag (Trassenteilabschnitt) existiert. Wenn ja → AFT_RAEUML_STORNO = 1 → es ist eine RS (räumliche Teilstornierung).Wenn nein → AFT_RAEUML_STORNO = 0 → es ist eine AEN (Änderung nach Vertragsschluss).Räumliche Teilstornierung wird in TPN als Typ 8 RS Kennzeichnung erkannt und als „Wegfall" behandelt – die Zugnummer bleibt belegt, da der Vertrag weiterhin (mit reduziertem Laufweg) existiert.| Typ 8 aus KK-Eingang automatisch weiterleiten
|
||||
GFD|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
GFD|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
RuT| _kaAeBStornoersatz_|
|
||||
|
|
||||
|
||||
1. Einloggen als Regelzugkonstrukteur
|
||||
2. Serverseitige Verarbeitung der Meldung _kaAeBStornoersatz_(KEIN manuelles Übernehmen der Message möglich)
|
||||
3. Automatisches Ergebnis in RuT-K für
|
||||
1. **Räumliche Stornierung** (Einkürzen des Laufwegs an allen VT UND 1. VT der Trasse liegt noch in der Zukunft)
|
||||
1. Eine neue Trasse entsteht
|
||||
1. mit neuer PathID
|
||||
2. PathIDold auf referenzierte Vertragstrasse
|
||||
3. PathRequest der referenzierten Vertragstrasse
|
||||
4. Status der Trasse ist zurückgeschrieben. => Wie wird Trasse dann vertragswirksam?
|
||||
2. Die referenzierte Trasse
|
||||
1. 1. werden alle Verkehrstage ausgestanzt.
|
||||
2. Nicht zurückgeschrieben an GFD-Z
|
||||
3. Trassenstatus bleibt gleich.
|
||||
3. Der Laufweg der Bautrasse wird nicht angepasst. Die PathIDold wird auf die neu erzeugte Trasse geändert.
|
||||
4. Alle Trassen werden als Update nach FaPS exportiert.
|
||||
2. **Räum-Zeitliche Stornierung** (Einkürzen des Laufwegs an einzelnen VT)
|
||||
1. Eine neue Trasse entsteht für die betroffenen VT
|
||||
1. mit neuer PathID
|
||||
2. PathIDold auf referenzierte Vertragstrasse
|
||||
3. PathRequest der referenzierten Vertragstrasse
|
||||
4. Status der Trasse ist zurückgeschrieben. => Wie wird Trasse dann vertragswirksam?
|
||||
2. Die referenzierte Trasse
|
||||
1. 1. wird an den betroffenen Verkehrstagen ausgestanzt.
|
||||
2. Nicht zurückgeschrieben an GFD-Z
|
||||
3. Trassenstatus bleibt gleich.
|
||||
3. Der Laufweg der Bautrasse wird nicht angepasst. Die PathIDold wird auf die neu erzeugte Trasse geändert. => mit [C2SLS-2244](https://arija.jaas.service.deutschebahn.com/browse/C2SLS-2244) (9.7.2) wird die Bautrasse in zwei Bautrassen aufgeteilt, falls die VT die alte Vertragstrasse sowie die neue Trasse überschneidet
|
||||
4. Alle Trassen werden als Update nach FaPS exportiert.
|
||||
|
||||
|
|
||||
|
||||
GFD|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
||||
TPN|
|
||||
|
|
||||
| Nach Rückkehr des Konstruktionsergebnisses aus RUT-K passiert in TPN:
|
||||
|
||||
* * KK-Postkorb „Abgeschlossen" → Auftrag auf „Geprüft" setzen
|
||||
* Vertriebsauftrag für den laufweg-angepassten Vertrag (gleiche PathID, reduzierter Laufweg)
|
||||
* Bestätigung der RTS geht an pathOS (EVU) raus
|
||||
* Endstatus: Typ 8 und Typ 2 stehen im KK-„Suchen (Trassen)"-Postkorb im Status „Bearbeitet"
|
||||
* Zugnummer bleibt belegt (kein Freigabe, da Vertrag mit reduziertem Laufweg weiterbesteht)
|
||||
|
||||
| EVU
|
||||
|
||||
Quelle:
|
||||
|
||||
sowie Kommentar Stefan Gründling 06.05.2026
|
||||
Reference in New Issue
Block a user