3.3 KiB
3.3 KiB
domain, tool, scope, tags, owners, contact, component_type, source, source_version, meta_fingerprint, url, last_updated, review_status, review_notes, content_hash
| domain | tool | scope | tags | owners | contact | component_type | source | source_version | meta_fingerprint | url | last_updated | review_status | review_notes | content_hash | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| pathos | pathos | intern |
|
|
einfachbahn@deutschebahn.com | page | confluence | 6 | f8016101b3b52f2d | https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/449099781/2025-06-05+Inland-Ausland-Inland | 2026-06-30 | approved | 0a0f0dfbbd471f11 |
| Bearbeitungsstand | |
|---|---|
| Ansprechpartner | |
| Letzte große Aktualisierung |
Teilnehmer
11 complete Felix Mohr Besprechungsorganisator*in Keine 12 incomplete Stefan Gründling Erforderlicher Teilnehmer Mit Vorbehalt 13 complete Bernd Brandes Erforderlicher Teilnehmer Zugesagt 14 complete Basil Zöhrer Erforderlicher Teilnehmer Zugesagt 15 complete Fabian Knöller Erforderlicher Teilnehmer Zugesagt 16 complete Lennart Freitag Erforderlicher Teilnehmer Zugesagt 17 complete Danielle Berg -Extern Erforderlicher Teilnehmer Zugesagt 18 complete Matthias Laube Optionaler Teilnehmer Keine 19 complete Andreas Sebastian Zöllner Optionaler Teilnehmer Zugesagt 20 incomplete Fabian Sommer Optionaler Teilnehmer Keine
Protokoll
GFD-Z/BSV
- NSS braucht Eindeutigkeit bei Zugnummer und Verkehrstag, es käme zu Überschreibungen
- BSV braucht Eindeutigkeit bei Zugnummer und Verkehrstag, sonst grundsätzlich keine Funktionalität
pathOS
- Stückelung gemäß TTT-Logik bereits bei pathOS implementiert, ebenso bei der Umsetzung der EVU
Allgemein
- Widerspricht es der TTT-Logik die Gesamtbestellung mit einer pathID an den Kunden zu geben? → Ja!
- Wie werden Folgeprozesse abgebildet?
Mögliche Lösungen
- Schnittstellenanpassung und der Kunde muss entweder
- es in einem PathRequest mit internationaler Zugnummer bestellen und intern arbeiten wir wie bisher (inklusive Verbot der Nutzung von Reason of Reference 1006/1007)
- es in zwei PathRequest ohne internationale Zugnummer , stattdessen mit zwei unterschiedlichen Zugnummern + Zugnummernwechsel an der Grenze oder beim Fremd-EIU
= es sind zwei separate Bestellungen, deren Zusammenhang nur schwer erkenntlich ist
- Umsetzung mit zwei PathRequest und derselben Zugnummer, wie in der Schnittstelle beschrieben, erfordert
- Anpassung NSS: Pathes mit selber Zugnummer und Verkehrstag zusammenführen (Schneiden&Kleben)
- Anpassung Fplo-Erstellung: TODO: Fachlich klären, ob pro Zug und Verkehrstag (und FBN) nur 1 Fplo existieren darf:
- falls ja: GFD und BSV-Fplo müssen aus mehreren Pathes mit selber Zugnummer und Verkehrstag zusammengeführt werden (Schneiden&Kleben)
- falls nein: es entstehen mehrere Fplo mit selber Zugnummer, Verkehrstag, FBN; GFD vsl. keine Anpassung BSV muss ggf. Anpassungen bzgl. Identifizierung machen
Verworfene Lösungen
- Bestellungen gemäß Sst werden intern zB von TPN zusammengeführt: lohnt sich nicht, da dennoch in RuT-K zwei Trassen entstehen müssen, damit jeweils eine eigene PathID vorhanden ist, wodurch die Kleben&Schneiden-Prozesse s. mögliche Lösung 2. trotzdem benötigt werden; außerdem wie werden Folgeprozesse abgebildet, da jeweils separate "Umbestellungen" erfolgen können?
Fazit
Lösung 1a wird weiter verfolgt