Anlage_11.1_RMV-Tarifdaten.pdf

[Seite 1]

RMV-Tarifdaten

Beschreibung der Datenstruktur für die Tarifdatennutzung

Hinweis: Die Spezifikation wird in Kürze um ein ER-Diagramm ergänzt. Eine inhaltliche Ände- Version 4.2.45.003 rung ist damit nicht verbunden – es handelt sich nur um eine nutzerfreundliche Darstellung Datum: 28.08.2025 der datentechnischen Zusammenhänge.

250828-E Anlage_16_V4_2_45_003.docx S. 1 / 88

[Seite 2]

Inhalt

1 Einleitung ........................................................................................................... 5 1.1 Allgemeine Hinweise zur vorliegenden Spezifikation ................................................. 5 1.2 Tarifdaten Format ...................................................................................................... 5 1.3 Übersicht über die Tarifdaten Varianten .................................................................... 5 1.4 Hinweise zu csv-Format, Kodierung und Konventionen bei Dateinamen ................... 5 1.5 Allgemeines / Überblick ............................................................................................. 6 1.6 Tarifgebiete und Tarifmatrix, Hinweise zu Speicherung und Zugriff ........................... 7 1.7 Tarifgebiete und Obertarifgebiete .............................................................................. 8 1.8 Ermittlung der Preisstufe einer Tarifrelation gemäß „Abschneideregel 1.0”................ 9 1.9 Aktualisierung der Tarifdaten ..................................................................................... 9 1.10 Datenumfang ............................................................................................................10 1.11 Kurzstrecken / Fahrtrelationen ..................................................................................10 1.12 Zusammenhang zwischen Sorte, Fahrausweisart und Fahrkartentext ......................10 1.13 Abstufung der Anforderung an die Verkaufsqualität aufgrund unterschiedlicher Kundennachfrage, Vertragsabschluss und Verkaufsregion .......................................10 1.14 Zusammenhang zwischen ÜT-Relationen, Stadtpreisstufen, Sonderstatusstädten und Preisstufen ...............................................................................................................11 1.15 Berechnung von Flächenangeboten .........................................................................12 1.16 Anschlussfahrkarten .................................................................................................12 1.17 Darstellung von Tarifrelationen in Auskunfts- und Verkaufssystemen .......................13 1.18 Nutzung der globalen Haltestellen-ID (DHID) und weiterer DxIDs ............................13 1.19 Angebot zur Kommunikation .....................................................................................13

2. Strukturbeschreibung ..................................................................................... 14 2.1 Tabelle „anschlusspunkt” ..........................................................................................16 2.2 Tabelle „anzeige” ......................................................................................................16 2.3 Tabelle „anzeigetexte” ..............................................................................................18 2.4 Tabelle „bundesland” ................................................................................................19 2.5 Tabelle „equi_tarifgebiet” ..........................................................................................19 2.6 Tabelle „erweiterte_freigabe“ ....................................................................................19 2.7 Tabelle „fahrausweisart“ ...........................................................................................20 2.8 Tabelle „fahrkartentext”.............................................................................................20 2.9 Tabelle „fahrkartentext_zusatz“ ................................................................................21 2.10 Tabelle „fahrtrelation“ ...............................................................................................21 2.11 Tabelle „flaechenrelation“ .........................................................................................22 2.12 Tabelle „freigabe“ .....................................................................................................24 2.13 Tabelle „freigabe_fahrtrelation“ .................................................................................24 2.14 Tabelle „freigabe_tzcode“ .........................................................................................24 2.15 Tabelle „fussweg“ .....................................................................................................25 2.16 Tabelle „gemeinde“ ...................................................................................................25 2.17 Tabelle „haltestelle“ ..................................................................................................25

250828-E Anlage_16_V4_2_45_003.docx S. 2 / 88

[Seite 3]

2.18 Tabelle „hst_2_verkehrsmittelgattung” ......................................................................27 2.19 Tabelle „kalender“ .....................................................................................................27 2.20 Tabelle „koordinaten“ ................................................................................................27 2.21 Tabelle „kundengruppe“ ............................................................................................28 2.22 Tabelle „landkreis“ ....................................................................................................29 2.23 Tabelle „landkreis2rp” ...............................................................................................29 2.24 Tabelle „linie“ ............................................................................................................29 2.25 Tabelle „linien_version“.............................................................................................30 2.26 Tabelle „ortsteil“ ........................................................................................................30 2.27 Tabelle „partner“ .......................................................................................................30 2.28 Tabelle „plz” ..............................................................................................................31 2.29 Tabelle „preisliste“ ....................................................................................................31 2.30 Tabelle „preisstufe“ ...................................................................................................32 2.31 Tabelle „rp” ...............................................................................................................32 2.32 Tabelle „sonderziele” ................................................................................................32 2.33 Tabelle „sorte_2_fahrkartentext“ ...............................................................................33 2.34 Tabelle „sortengruppe“ .............................................................................................33 2.35 Tabelle „sortengruppe_2_sorte” ................................................................................33 2.36 Tabelle „sortengruppe_2_verbund“ ...........................................................................33 2.37 Tabelle „sortenschluessel“ ........................................................................................34 2.38 Tabelle „sortenschluessel_ext" .................................................................................37 2.39 Tabelle „sortenschluessel_gueltig" ...........................................................................38 2.40 Tabelle „strecke" .......................................................................................................39 2.41 Tabelle „tarifgebiet"...................................................................................................40 2.42 Tabelle „tarifgebiet_typ" ............................................................................................40 2.43 Tabelle „tarifgebietsfolge" .........................................................................................41 2.44 Tabelle „tarifmatrix"...................................................................................................41 2.45 Tabelle „uebertragbarkeit“ ........................................................................................43 2.46 Tabelle „unterlinie" ....................................................................................................43 2.47 Tabelle „unterlinie_2_strecke" ..................................................................................43 2.48 Tabelle „verbund" .....................................................................................................44 2.49 Tabelle „verkehrsmittelgattung“ ................................................................................44 2.50 Tabelle „verkehrsmittelgattung_2_gruppe“................................................................44 2.51 Tabelle „verkehrsmittelgattungsgruppe“ ....................................................................45 2.52 Tabelle „version" .......................................................................................................45 2.53 Tabelle „viatext" ........................................................................................................45 2.54 Tabelle „waehrung"...................................................................................................45 2.55 Tabelle „zahlungsmodus“ .........................................................................................46 2.56 Tabelle “z_viatext" ....................................................................................................46 2.57 Struktur der Tabelle “schema.ini" ..............................................................................46 2.58 Tabelle „xxx_sosa_zzz.csv" ......................................................................................47

3 Verkaufs- und Einnahmenmeldungen ........................................................... 50 3.1 Datenlieferung über webbasierte Technologie (EVi) .................................................50 3.2 Lieferwege und spezifische Dateninhalte ..................................................................51 3.3 Einliefervorgang........................................................................................................53

250828-E Anlage_16_V4_2_45_003.docx S. 3 / 88

[Seite 4]

3.4 Tarifdaten, Verkaufsdaten und deren Aktualisierung ................................................53 3.5 Beschreibung der Verkaufsdaten im Detail ...............................................................55 3.6 Kundenfahrtdaten .....................................................................................................63

4. Anhang ............................................................................................................. 70 4.1 Tabellenübersicht .....................................................................................................70 4.2 Maschineller Datenstrukturabgleich - Inhalt der Tabelle „schema.ini“ .......................71 4.3 Abkürzungen und Glossar ........................................................................................73 4.3.1 AGS ............................................................................................................................. 73 4.3.2 CSV ............................................................................................................................. 73 4.3.3 DxID (DHID, DLID, DTID, DFID) ................................................................................. 73 4.3.4 FK ................................................................................................................................ 74 4.3.5 Gebietskörperschaftsstruktur ...................................................................................... 74 4.3.6 GKZ ............................................................................................................................. 74 4.3.7 Grenzhaltestelle / Grenztarifgebiet .............................................................................. 74 4.3.8 PFK .............................................................................................................................. 75 4.3.9 PK ................................................................................................................................ 75 4.3.10 TG / OTG ..................................................................................................................... 75 4.3.11 TRK ............................................................................................................................. 75 4.3.12 ÜT ................................................................................................................................ 75 4.4 Zahlungsart (Stand 03.12.2024) ...............................................................................76 4.5 Verkaufstechnik (Stand 19.03.2024) .........................................................................77 4.6 Details zur Nummerierung von Haltestellen ..............................................................78 4.7 Bildung von Freigaben für Fahrtrelationen ................................................................80 4.8 Änderungsverzeichnis dieses Dokumentes ..............................................................82

250828-E Anlage_16_V4_2_45_003.docx S. 4 / 88

[Seite 5]

1 Einleitung

1.1 Allgemeine Hinweise zur vorliegenden Spezifikation Das vorliegende Dokument beschreibt im ersten Teil die vom RMV ausgelieferten Tarifdaten, im zweiten Teil die Verkaufsdaten, die der RMV als Empfänger erwartet.

1.2 Tarifdaten Format Der RMV-Tarifdatenexport für den Verkauf unterstützt ausnahmslos das csv-Format als Datenstrukturtyp. Daneben existiert noch ein davon abgeleitetes Binärdatenformat für Prüfgeräte („KIM“). Dieses erhalten die Hersteller der zugehörigen Prüfgeräte. Der RMV setzt für die Kontrolle das PKM (Produkt- und Kontrollmodul) ein, das KIM mittlerweile weitgehend ersetzt hat. Es wird erwogen, durch PKM später auch die csv-Daten zu ersetzen. Das csv-Format wurde zeitweise auch als ANSI/ASCII Format bezeichnet. In diesem Dokument wird das Format durchgängig als „csv”-Format bezeichnet (beachte 1.4).

1.3 Übersicht über die Tarifdaten Varianten Es gibt nur noch eine Version der Tarifdatenbank.

1.4 Hinweise zu csv-Format, Kodierung und Konventionen bei Dateinamen Für die csv-Dateien gilt folgende Spezifikation:

Die csv-Dateien enthalten in der ersten Zeile keine Feldnamen. Feldnamen lassen sich über die Struktur der Tabelle “schema.ini" (Abschnitt 2.57) eruieren. Bislang wurden die csv Dateien in ANSI-Kodierung weitergegeben. Die ZIP Datei enthält zur Kenntlichmachung den Namensbestandteil „ISO-8859-1“. Zusätzlich stellt der RMV eine Version in UTF-8 Kodierung (ohne BOM) bereit. Die ZIP Datei enthält zur Kenntlichmachung den Namensbestandteil „UTF-8“. Es werden durchgängig Kleinbuchstaben für den vollständigen Dateinamen verwen- det um auch eine konsistente Nutzung auf Linux Systemen zu erleichtern (Bei Linux Systemen sind die Dateinamen Case-sensitiv d.h. ”bundesland.csv” und ”Bundes- land.csv” sind zwei verschiedene Dateien).

250828-E Anlage_16_V4_2_45_003.docx S. 5 / 88

[Seite 6]

1.5 Allgemeines / Überblick Im nachfolgenden Kapitel 1.6 wird zunächst noch auf die Tarifbildung und die Struktur der Tarifrelationen (Tarifmatrix) näher eingegangen, Kapitel 1.9 ist die Vorschrift zur Datenübernahme. Daran schließt sich das Kapitel an, in dem die Datenstrukturen (Ta- bellen, Datenelemente) detailliert beschrieben werden. Bei allen Ergänzungen und Weiterentwicklungen ist geplant diese stets unter Beibe- haltung der Kompatibilität zur vorliegenden Spezifikation zu entwickeln. Bei diesen Weiterentwicklungen sind 3 Fälle zu unterscheiden: a.) zusätzliche Tabellen: Wenn zusätzliche Tabellen eingeführt werden, dann sind inhaltli- che strukturelle Abhängigkeiten zu beachten. Es ist nicht immer möglich auf die neuen Informationen zu verzichten. Daher müssen innere Abhängigkeiten genau geprüft und beachtet werden. b.) zusätzliche Felder. Wenn Felder an bisher bereits genutzte Tabellen ergänzt werden, dann ist, wie bisher, geplant diese immer hinten anzuhängen, so dass beim Einlesen von csv-Daten nach bisheriger Kenntnis der Feldstruktur die notwendigen Informatio- nen an gleicher Stelle gefunden werden wie bisher. c.) Veränderung von Feldinhalten: Sollte ein Feld nicht mehr genutzt werden, dann ist ge- plant, dass es strukturell weiter (wenn auch leer) geliefert wird, um Einleseroutinen nicht ändern zu müssen. Behandlung von Fehlern beim Import Die Erfahrungen bei der Implementation bei verschiedenen Herstellern haben gezeigt, dass es zu unterschiedlichen Fehlertypen kommen kann: Bspw. kann die Spezifikation zum Zeitpunkt der Softwareerstellung bestimmte Inhalte noch nicht enthalten haben, die heute verwendet werden. Dies kann direkt oder indirekt dazu führen, dass für einzelne Zeilen die referentielle Integrität beim Import nicht ge- wahrt ist. Lösung 1: Das Importverfahren wird regelmäßig nachgepflegt. Lösung 2: Die fraglichen Zeilen werden ignoriert. Fast immer handelt es sich um den Fall, dass diese Informationen nicht für den Verkauf, sondern nur für die Prüfung bzw. die Auskunft benötigt werden. Bei Problemen dieser Art empfehlen wir unbedingt Kontakt zur RMV-Tarifabteilung auf- zunehmen, um zu einer gemeinsamen Einschätzung der Schwere / Problematik zu gelangen. Grundsätzlich sollte die Möglichkeit der Ignorierung solcher Einlesefehler vorgesehen sein, um für den häufigen Fall, dass diese in der konkreten Situation nicht kritisch sind, problemlos ohne Software Anpassungen weiterarbeiten zu können. Referentielle Integrität im strengen Sinn ist wie soeben ausgeführt, bei einigen Datenin- halten nicht immer zwingend gegeben, auch wenn das Datenmodell dies impliziert.

Dies ist insbesondere nicht der Fall zwischen allen Tabellen der Strecken- und Liniendaten einerseits und den ausgelieferten Haltestellen andererseits. Rein formell müssten aus IT-Sicht Letztere bei jedem Auftreten in den Strecken- und Liniendaten zwingend auch als Haltestellendatensatz erscheinen.

Hier überkreuzen sich mehrere Zusammenhänge:

Zunächst: Für den Verkauf und die RMV-relevante Tarifauskunft ohne Fahrplanauskunft sind Strecken- und Liniendaten nicht unmittelbar relevant. Sie wirken indirekt an der Tarifbildung mit. Die tarifrelevanten Ergebnisse finden sich aber in den Tabellen tarifmatrix und tarifgebietsfolge sowie flaechenrelation („nor- maler Tarif“) und fahrtrelation (für Kurzstrecken). Diese Informationen werden für Auskunfts- und Ver- kaufssysteme mit Fahrplanbezug benötigt.

250828-E Anlage_16_V4_2_45_003.docx S. 6 / 88

[Seite 7]

Die Strecken- und Liniendaten werden aus einem Drittsystem (Fahrplandaten) vollständig importiert und im Export ungefiltert exportiert. Enthalten sind somit auch Daten die entweder veraltet, ungenutzt, tarif- lich nicht relevant (bspw. ein- /ausbrechend oder außerhalb des RMV) oder im spezifischen vorliegenden Exportpaket, das gewissen TARIFLICHEN Filterbedingungen unterlag, ansonsten nicht enthalten sind. Es wurde davon abgesehen diese Randbedingungen auch für den Export der Strecken- und Liniendaten anzuwenden, da dies zu einer deutlichen Komplikation ohne tieferen Nutzen geführt hätte. Im Ergebnis wären u.U. einzelne Teilstrecken weggefiltert und somit wiederum die innere Konsistenz der Strecken- und Liniendaten gebrochen worden.

Die exportierten Haltestellendaten unterliegen einer Filterung auf Gültigkeit und Geographie (auch wenn in den Fahrplandaten des Drittsystems eine Linie nach Köln enthalten sein sollte, wird bspw. Köln nicht in den tariflichen Haltestellendaten mit einer RMV-Haltestellen ID exportiert, da für den RMV-Tarif be- deutungslos.) Es kann daher formuliert werden: Die Strecken bezogenen Daten der betroffenen Ta- bellen (strecke, unterlinie_2_strecke, unterlinie, linien_version, linie) sind vollständig importierte ISA-Fremddaten (Fahrplandaten), also keine originären Tarifdaten. Die Strecken- und Liniendaten sind insofern vollständig als sie dort wo sie von den restlichen Tabellen aus referenziert werden, konsistent enthalten sind, es liegt aber umgekehrt keine Vollständigkeit, noch nicht einmal referentielle Integrität in Richtung der genutzten Haltestellen vor. Daher sind die entsprechend „überflüssigen“ Datensätze beim Import einfach zu igno- rieren, insofern überhaupt Strecken- und Liniendaten importiert werden. Ähnliches trifft auf den Zusammenhang zwischen den Tabellen „sortenschlues- sel_gueltig“ und „kalender“ zu. Die „Kennung“ in „kalender“ ist als eine textlich be- schreibende Information über die Gültigkeit aufzufassen – es besteht keine referentielle Integrität im strengen IT-technischen Sinne. Die Gültigkeiten sind nicht für den Verkauf ohen Fahrplanbezug, sondern für die elektronische Auskunft, Verkauf und Prüfung re- levant und daher für offline Verkaufssysteme nicht von Bedeutung. Ein weiteres Beispiel: Nicht alle Fahrtrelationen haben einen Viatext. Diejenigen mit Viatext verweisen auf einen existierenden Datensatz einer anderen Tabelle. In Oracle dürfen Foreign-Key-Beziehungen auch NULL sein. Dies wird hier ausgenutzt und spie- gelt sich in den csv Daten darin, dass es dann in der abhängigen Tabelle keinen refe- renzierten Datensatz gibt. Es sei ausdrücklich darauf hingewiesen, dass die technischen Primärschlüssel keiner- lei inhaltliche Bedeutung haben. Sie dienen rein der Darstellung IT-technischer Bezie- hungen. Technische Primärschlüssel können sich daher auch bei gleichem Inhalt von Tarifversion zu Tarifversion unterscheiden.

1.6 Tarifgebiete und Tarifmatrix, Hinweise zu Speicherung und Zugriff Die Tarifmatrix des RMV ist eine Halbmatrix. Jede einzelne Relation in der Matrix ist als Kombination von Start-Tarifgebiet / Ziel-Tarifgebiet / Über-Tarifgebiet (oder kürzer: „von“ – „nach“ – „über“) abgelegt. (siehe dazu insbesondere wegen via-Texten die Erläuterungen zur Tabelle „“) Das bedeutet, dass ausnahmslos die Tarifrelation von X nach Y über Z in die gleiche Preisstufe fällt wie die Tarifrelation von Y nach X über Z. Dies würde zu zwei bedeu- tungsgleichen Einträgen in der „tarifmatrix“ Tabelle führen bei denen als einziger Un- terschied nur „von“ und „nach“ vertauscht ist. In der Tarifdatenbank ist daher stets nur einer der beiden Datensätze gespeichert und zwar derjenige bei dem der zahlenmäßig kleinere TZ_Code als Von, der größere (oder max. gleich große) als Nach aufgeführt

250828-E Anlage_16_V4_2_45_003.docx S. 7 / 88

[Seite 8]

ist. Der inhaltlich umgekehrte Fall, der in der Praxis natürlich ebenfalls vorkommt, ist nötigenfalls durch Vertauschung von „von“ und „nach“ in der Tabelle zu suchen. Beispiel: Es gibt in der Tarifdatenbank die Relation Von 2500 Nach 5000 Über 5100, nicht jedoch die Tarifrelation Von 5000 Nach 2500 Über 5100. Hierbei ist unbedingt zu beachten, dass sich obige Aussagen auf die TZ-Codes und nicht etwa auf die technischen Primärschlüssel beziehen. Weiterhin sind nicht alle TG-TG-Beziehungen aufgeführt – hierauf wird i. d. R. dann verzichtet, wenn es sich um größere Entfernungen handelt, die in den Bereich des Regionalverkehrs fallen. Erreicht wird dies durch die Zusammenfassung von Tarifge- bieten zu einem Obertarifgebiet (OTG). Was für die Bereitstellung der Tarifdaten und Tarifrelationen gilt, muss dementspre- chend auch für die Preisbildung im Verkauf gelten. Der Algorithmus in den Verkaufs- geräten muss dazu auf Basis der Start- und Zielpunkte die richtige Tarifrelation aus der Menge der Relationen herausfiltern und die dort zugeordnete Preisstufe entnehmen. Ein Verfahren zur hierzu ist unter 1.8 beschrieben.

1.7 Tarifgebiete und Obertarifgebiete Tarifgebiete werden durch einen eindeutigen, 4-stelligen Tarif-Zielcode (TZ_Code) ge- kennzeichnet. Der Kunde kann über diese 4-stellige Ziffernfolge sein Ziel am Verkaufs- gerät auswählen. Wesentlich komfortabler ist jedoch die Auswahl mit Hilfe des Ortsteil- oder Gemeindenamens, wobei die zur Auswahl stehenden Tarifgebiete hinterlegt sind. Tarifgebiete werden zu Obertarifgebieten zusammengefasst. Tarifgebiete werden als TG, Obertarifgebiete als OTG bezeichnet (bitte nicht mit den Ortsteilen = OT verwech- seln). Grundsätzlich sind ausnahmslos alle Tarif-Zielcodes (TZ_Code) vierstellig! Bei dreistellig erscheinenden TZ_Codes ist eine führende „0” zu ergänzen. (Bsp: Der TZ_Code „140” in Tabelle „tarifgebiet“ ist als „0140” zu interpretieren). Zur Unterstützung der Intuition ist in den meisten (!) Fällen der Zielcode des Obertarif- gebiets eine „passende Zehner bzw. Hunderter”-Ziffernfolge die am Ende eine Null trägt (Bsp: „6600” ist der Zielcode des Obertarifgebietes zu den Tarifgebieten „6601”, „6620”, „6626”, „6636” u.a.). Dieses „historische Abschneideverfahren” führt NICHT DURCHGÄNGIG zum korrek- ten Ergebnis und darf daher algorithmisch NICHT verwendet werden. Die einzig korrekte Methode um zum Obertarifgebiet eines Tarifgebiets zu gelangen besteht ausnahmslos darin, den Eintrag im Feld TZ_Code_ATG in Tabelle „tarifgebiet” zu nutzen um das zugehörige Obertarifgebiet zu einem Tarifgebiet zu identifizieren. Das Obertarifgebiet zeichnet sich darüber hinaus durch eine entsprechende Klassifizierung in Tabelle „tarifgebiet_typ” aus. Der Tarifgebietsname ist für die Zeit nach der angestrebten Tarifstrukturreform gedacht, wenn die Tarifgebiete eindeutige Namen bekommen werden. Bis dahin kann ein Tarifgebiet eindeutig nur durch seine Tarifgebietsnummer angesprochen werden! Es ist bis dahin nicht zulässig, im Umgang mit Kunden einen Namen für ein Ta- rifgebiet zu nutzen. Wenn heute schon Tarifgebietsnamen angegeben sind, dienen diese lediglich der internen Unterstützung bei der Identifikation eines Tarifgebiets.

250828-E Anlage_16_V4_2_45_003.docx S. 8 / 88

[Seite 9]

In diesem Zusammenhang sei darauf verwiesen, dass die Tarifdaten mehr Informatio- nen enthalten als für den Druck der Papierfahrkarten bzw. die Datenversorgung der eTickets erforderlich sind. Dies soll allen Nutzern, die teilweise sehr unterschiedliche Anforderungen haben, einen möglichst einfachen Umgang mit den Daten erleichtern. Ausschlaggebend für den Druck der Fahrkarten bzw. die Beschreibung (Be- wertung / „Beschriftung“) der eTickets sind allein die Informationen und Anlei- tungen des RMV-Vertriebs.

1.8 Ermittlung der Preisstufe einer Tarifrelation gemäß „Abschneideregel 1.0” Grundsätzlich erfolgt die Suche nach einer Fahrkarte für einen bestimmten Weg so, dass zunächst die Start- und Zieltarifgebiete eingegeben werden, anschließend die ge- wünschte Fahrkarte gewählt und abschließend unter den angebotenen Über ausge- wählt wird. Bei einer großen Menge an Fahrkarten in einem Auskunfts-/Verkaufssys- tem ist eine Abwandlung zulässig, bei der (nach Start und Zieleingabe) statt der ge- wünschten Fahrkarte die gewünschte Fahrkartengruppe (z. B. Monatskarte) gewählt wird, anschließend das Über und nun erst die genaue Fahrkarte. Jeder andere Such- weg führt zu Fehlern, Umwegen und sonstigen Problemen und ist daher nicht zulässig. Grundlage für die Auswahl der korrekten Tarifrelation sind die Eckdaten der gewählten Verbindung (Start, Ziel, Über). Ausgangsdaten sind dabei – wie oben bereits beschrie- ben – die 4-stelligen Nummern der Tarifgebiete bzw. Obertarifgebiete. Haltestellen und Ortsteile sind Tarifgebieten zugeordnet, womit auch eine Auswahl der Tarifrelation (aus „tarifmatrix”) über andere Eingangsdaten, z. B. Haltestellen möglich wird. Für die Ermittlung einer Preisstufe bzw. eines Preises sind bis zu 4 Zugriffe auf die „tarifmatrix” erforderlich. Hierbei wird sowohl beim Start als auch beim Ziel der Fahrt unterschieden zwischen einem „einfachen” Tarifgebiet (= TG = Tarifgebiet, Grenztarif- gebiet, u. a.) und dem ihm zugeordneten Obertarifgebiet. Diese Zuordnung geschieht für jedes TG in der Tabelle „tarifgebiet”. Obertarifgebiete sind (bislang) sich selbst zu- geordnet. Die Zugriffe erfolgen in nachstehender Reihenfolge:

1. Stufe: Start: TG Ziel: TG
2. Stufe: Start: TG Ziel: OTG
3. Stufe: Start: OTG Ziel: TG
4. Stufe: Start: OTG Ziel: OTG Die Wertigkeit (Obertarifgebiet, sonstiges Tarifgebiet) eines Tarifgebiets geht aus der Tabelle „tarifgebiet” in Verbindung mit „tarifgebiet_typ” hervor. Nur Tarifgebietstypen des Tarifgebietstyps ”A” sind Obertarifgebiete. In jeder der 4 Stufen wird geprüft, ob ein Eintrag zur jeweiligen Relation vorhanden ist. Sobald ein passender Matrixeintrag gefunden wird, steht die anzuwendende Preisstufe fest und die Suche wird beendet. Eine Preisausgabe unterbleibt, wenn kein Matrixein- trag mit den benutzten Tarifgebieten gefunden wird oder eine Relation explizit als „nicht verkaufbar” gekennzeichnet ist. Siehe auch die Anmerkungen zur Tabelle „tarifmatrix”.

1.9 Aktualisierung der Tarifdaten Die Aktualisierung von Tarifdaten (Tarifwechsel) erfolgt durch den vollständigen Aus- tausch der Datenbank-Tabellen.

250828-E Anlage_16_V4_2_45_003.docx S. 9 / 88

[Seite 10]

1.10 Datenumfang Die zukünftige Tarifentwicklung ist durch die widersprüchlichen Anforderungen nach Einfachheit (DeutschlandTicket) und Ergiebigkeit (Finanzierungsproblem) gekenn- zeichnet. Aktuell beträgt der Umfang der Tarifdaten bis zu 100 MB. Prüfgeräte müs- sen bis zu 3, Verkaufsgeräte bis zu 2 Versionen der Tarifdaten halten können. Dazu kommt die Speicherung der entsprechenden Verkäufe bzw. Prüfnachweise. Da die Hard- und Softwareprodukte je nach Entwicklung unterschiedlichen Anforderungen genügen müssen, müssen sich alle Beteiligten auf einen größeren Datenumfang ein- stellen und ihre Technik mit großzügig bemessenem Speicher bzw. entsprechenden Nachrüstungsmöglichkeiten ausrüsten.

1.11 Kurzstrecken / Fahrtrelationen Kurzstrecken sind, feiner als Tarifrelationen die zwischen Tarifgebieten gelten, als Fahrtrelationen zwischen Haltestellen definiert. Dazu dienen die Tabellen fahrtrela- tion, freigabe_fahrtrelation und fussweg. Über diese Tabellen (siehe Beschreibungen dort) sind die exakten Fahrwege definiert, die für die jeweilige Kurzstrecke zugelas- sen sind. Im Gegensatz zur tarifmatrix handelt es sich hierbei um eine Vollmatrix, da etwa 20% aller Kurzstrecken keinen entsprechenden Rückweg aufweisen (Einbahn- regelungen, Haltestellen mit unterschiedlichen Namen …).

1.12 Zusammenhang zwischen Sorte, Fahrausweisart und Fahrkartentext Die Sorte in Form eines nummerischen Sortenschlüssels ist die Spezifizierung eines Angebots an den Kunden, das einzeln mit allen Verkäufern und ggf. Subventionsge- bern abrechenbar ist. Dieser Sorte können mehrere Preisstufen und damit auch Preise und Subventionsbeträge zugeordnet werden. Bsp.: Sorte 100, 112 Die Fahrausweisart ist eine Kategorisierung der Sortenschlüssel, die sowohl inner- betrieblich wie auch gegenüber dem Kunden genutzt werden kann. Bsp.: „Monatskarte“ Der Fahrkartentext ist der Text, der auf die Papierfahrkarte gedruckt werden soll. Da die Zahl der druckbaren Zeichen je nach den technischen Möglichkeiten variiert, werden verschiedene Längen angeboten. Zusätzlich enthält die Tabelle fahrkarten- text.csv auch Informationen, die während des Verkaufsprozesses genutzt werden können. Bsp.: „Monatskarte Erw.“ Für die Speicherung auf einem eTicket (Chipkarte) ist ausschließlich der Infotext mit der Länge 40 Zeichen zu nutzen. Aufgrund der technischen Eigenheit des Verkaufs- systems vHGS müssen auch die Fahrkarten, die ausschließlich als eTicket verkauft werden, einen Fahrkartentext erhalten, der außer für die Erkennung durch das eTi- cket-System nie genutzt wird.

1.13 Abstufung der Anforderung an die Verkaufsqualität aufgrund unterschiedli- cher Kundennachfrage, Vertragsabschluss und Verkaufsregion Die in dieser Spezifikation gestellten Anforderungen sind hoch. Um die dadurch ver- ursachten Umstellungskosten bei Hard- und Software zu begrenzen, ist es unter be- stimmten Voraussetzungen zulässig, mit schriftlicher Zustimmung des RMV statt der kompletten Spezifikation den durch Fettschrift definierten Minimalexport zu nutzen. Dabei können weitere manuelle Pflegearbeiten erforderlich sein.

250828-E Anlage_16_V4_2_45_003.docx S. 10 / 88

[Seite 11]

Dieser Minimalexport wurde speziell für die Verkehrsunternehmen in den Übergangs- tarifgebieten konzipiert. In jedem Fall gilt, dass Verkaufsgeräte und Verkaufssoftware, die für Verkehrsverträge oder eigenwirtschaftliche Verkehre innerhalb des RMV vorgesehen sind, müssen diese Spezifikation voll erfüllen und die Fahrkarten nach RMV-Tarif ordnungsgemäß verkau- fen.

1.14 Zusammenhang zwischen ÜT-Relationen, Stadtpreisstufen, Sonderstatusstäd- ten und Preisstufen Datenformalistisch gesehen gibt es nicht ganz triviale Zusammenhänge zwischen Ta- rif- und Fahrtrelationen in die Gebiete der Übergangstarife (ÜT / Nachbarverbünde) hinein. Siehe dazu die Anmerkungen zur Tabelle „sortengruppe_2_verbund“. Die Sor- tengruppen haben über Tarif- oder Fahrtrelation eine nicht zwingend eindeutige Zu- ordnung zum Verbund in denen sie gültig sind. Wegen der Grenztarifgebiete ergibt sich KEINE sichere Aussage, wenn Start-, Ziel-, Via-Tarifgebiete oder Freigaben auf Verbundzugehörigkeit hin untersucht werden. Die einzig sicher handhabbare Regel, die sich aber aus dem Datenmodell so nicht di- rekt ergibt, und daher hier explizit beschrieben ist, lautet wie folgt: Die Zugehörigkeit zu einem ÜT oder einer bestimmten Stadt ist (eindeutig nur) anhand der Preisstufe erkennbar. Umgekehrt ist es aber möglich, dass man bei den Stadtpreisstufen von einem Grenz- tarifgebiet (z. B. am Rand von Frankfurt), das zu einer anderen Gemeinde gehört, zur Preisstufe 11 nach Frankfurt fahren kann. Es gelten dabei folgende Preisstufen-Zuordnungen: 4 = Sonderstatusstädte: Bad Homburg (TG 5101), Fulda (TG 2001), Gießen (TG 1501), Hanau (TG 3001), Marburg (TG 0501, 0540, 0546, 0555, 0558, 0588), Rüsselsheim (TG 3730), Wetzlar (TG 5501, 5530, 5533) 5 = Darmstadt (betrifft nur TG 4001) 7 = Offenbach 10 = Mainz (TG 6511), Wiesbaden (TG 6501, 6505) – TG 6500, wobei es innerhalb des TG 6500 einzelne Bereiche gibt, die in die PS 22 und 31 fallen 11 = Frankfurt

Preisstufen für Übergangstarife zu Nachbarverbünden 2xx = VRM 3xx = RNN xx steht symbolisch 4xx = VGWS für alle realisierten 5xx = VRN Preisstufen im jewei- 6xx = VAB ligen Hunderterbe- 7xx = NVV reich. 8xx = RLK 9xx = NVM

250828-E Anlage_16_V4_2_45_003.docx S. 11 / 88

[Seite 12]

Die Preisstufen treffen eine eindeutige Aussage. Jede Fahrt in ein ÜT fällt in die ent- sprechenden Preisstufen und es gibt umgekehrt keine Fahrten innerhalb des RMV, die in die o. g. Preisstufen fallen (außer den Besonderheiten „Deutschland-Ticket“, „Hessenticket“, „Schülerticket Hessen“, „Seniorenticket Hessen“ und „Landesticket Hessen“ deren Preisstufen aber wiederum in den Übergangstarifen ausgespart sind). D.h. die Preisstufe verweist eindeutig auf den in der Relation beteiligten Verbund. Der Datentyp der Preisstufen ist alphanummerisch bis zu fünfstellig: Die Verkaufsge- räte müssen damit umgehen können. Bis auf Weiteres enthalten die RMV Preisstufen allerdings nur dreistellige, nummerische Werte.

1.15 Berechnung von Flächenangeboten Flächenangebote sind Tickets, die in einem bestimmten Areal immer gültig sind und keinen direkten Bezug zu einem Start-, Ziel- oder Über-Tarifgebiet haben. Dazu zäh- len z.B. das Deutschland-Ticket, das Hessenticket, das Schülerticket Hessen sowie das Seniorenticket Hessen. Die Flächenangebote sind in einer eigenen Tabelle „flae- chenrelation“ gespeichert. Die Tabelle erhält die gleichen Spalten wie die Tabelle „ta- rifmatrix“, wobei Start-, Ziel- und Via-Tarifgebiete als „virtuelle“ Tarifgebiete (ohne Ge- ometrie) dargestellt werden. Dadurch wird erreicht, dass die Relationen der Flächen- angebote in das bekannte Schema passen und somit alle Schnittstellen weiter be- dient werden können. Zwei zusätzliche Spalten mit den Namen „ID_Start_Menge“ und „ID_Ziel_Menge“ definieren zwei Mengen von Tarifgebieten. Eine Tarifanfrage muss mit Start und Ziel jeweils eine Untermenge dieser beiden Mengen sein. Nur für diesen Fall darf diese Fahrkarte beauskunftet und verkauft werden. Unabhängig da- von kann die Freigabe einen größeren Bereich umfassen. Das Attribut „id_freigabe“ definiert wie bisher den Gültigkeitsbereich der Relation. Flächenangebote verfügen somit über keine natürlichen Start-, Ziel- und Via-Tarifgebiete. Diese Werte werden durch virtuelle Tarifgebiete (Typ AV) ersetzt, die in den Verkaufsdatenmeldungen ein- getragen werden müssen. Wenn die Anfrage einen Startort enthält, dann ist hierfür auch die AGS anzugeben. Andernfalls bleibt dieses Feld leer. Bei einer Tarifanfrage müssen jetzt neben den „normalen“ Tarifrelationen stets auch alle Flächenangebote untersucht werden. Befindet sich das Start-Tarifgebiet in der Menge „ID_Start_Menge“ und das Ziel-Tarifgebiete in der Menge „ID_Ziel_Menge“ dann ist die Flächenrelation gültig und muss der Ergebnismenge hinzugefügt werden. Es ist also die Tariflogik zu erweitern, wenn Flächenangebote tarifiert werden sollen.

1.16 Anschlussfahrkarten Anschlussfahrkarten stellen eine eigene Sorte dar. Sie werden wie Einzelfahrkarten nur mit Geltung ab dem Verkaufsort angeboten. Aktuell gibt es zwei gegenläufige Tendenzen. Zum Einen nimmt der RMV eine Änderung derart in Aussicht, dass Anschlussfahrkar- ten ab einem abweichenden Startort angeboten werden sollen. Dies entspricht einem Vorverkauf von Einzelfahrkarten, wobei die Fahrkarte dann aber weiterhin eine ei- gene Bezeichnung und einen eigenen Sortenschlüssel aufweist. D. h. die Verkaufs- geräte müssen zwar technisch „Anschlussfahrkarten“ ab einem anderen Startort ver- kaufen können, dürfen dies aber aktuell bei Anschlusskarten und Einzelfahrkarten nicht. Umgekehrt müssen im Vorverkauf verkaufte Einzelfahrkarten als Anschluss- fahrkarte ausgegeben werden. Dies bedeutet für Geräteneubeschaffungen, dass auch der Startort wählbar sein muss. Zum Anderen ist es eher wahrscheinlich, dass die Anschlusskarte abgeschafft bzw. durch eine neue Logik ersetzt wird.

250828-E Anlage_16_V4_2_45_003.docx S. 12 / 88

[Seite 13]

1.17 Darstellung von Tarifrelationen in Auskunfts- und Verkaufssystemen Für die gleiche Kombination aus Von, Nach und Über kann es mehrere Sortengrup- pen (und damit Fahrkartenarten) geben, die sich durch die Preisstufe und / oder die Freigabe unterscheiden können. Es ist erforderlich, diese Sortengruppen für die Fahrkartenauswahl zunächst gleich darzustellen (also ohne Berücksichtigung unterschiedlicher Preisstufen bzw. Freiga- ben) und in einem Auskunftssystem erst im weiteren Bedienungsverlauf die Unter- schiede darzustellen. Für ein Verkaufssystem kann auf die weiteren Bedienschritte verzichtet werden, weil dort in der Regel die Freigabe gar nicht und statt der Preis- stufe direkt der Preis dargestellt werden. Zudem kann es erforderlich sein, einzelne Sortengruppen nicht einzulesen. Die Tabelle „anzeige“, die für online- und offline-Systeme eine vergleichbare Auswahl und ähnliche Bedienschritte erbringen soll enthält auch alle Sonderziele, die früher auf den Aushängen der Automaten angezeigt wurden.

1.18 Nutzung der globalen Haltestellen-ID (DHID) und weiterer DxIDs Der RMV hat die durchgängige Anreicherung der Haltestelleninformationen mit der bis zu 40 Zeichen langen globalen, alphanummerischen Haltestellen-ID (DHID) zu- sätzlich zur bisher max. 6-stelligen nummerischen RMV_Haltestellennummer vollzo- gen. Näheres dazu kann im Glossar, in den einleitenden Kapiteln und in diesem Do- kument in der Erläuterung zur Tabelle „haltestelle“ nachgelesen werden. Da zu erwarten ist, dass in einer durch elektronische Systeme immer stärker zuneh- menden verbundübergreifenden Vernetzung, auch des Nahverkehrs die Bedeutung dieser parallelen Haltestellen-ID stetig zunimmt, sei angeraten diese in allen betroffe- nen Systemen mitzuführen. Gleiches gilt für die Linien- (DLID), Teillinien- (DTID) und Fahrt-IDs (DFID). Siehe dazu auch das Glossar unter DxID. Ein Wort zur Anpassung bereits bestehender Systeme (wie es in der Praxis wohl meist der Fall sein wird) sei hier angebracht: Insofern, wie im hiesigen Datenmodell durchgängig praktiziert, bei der Nutzung der Tarifdaten auch in den verarbeitenden Systemen Relationalität und Normalisierung konsequent umgesetzt wurden, ist nur an einer einzigen Stelle (Feld 11 statt Feld 2 der Tabelle haltestelle) Datentyp und Feldlänge anzupassen. Falls aber die RMV_Haltestellennummer selbst (und nicht Referenzen und interne IDs) gespeichert wurden, sind Anpassungen an allen relevanten Stellen vorzuneh- men. Die DHID ist für den RMV und die benachbarten Übergangstarifgebiete bis auf mini- male Ausnahmen (neu eingerichtet, kurzfristige Umleitung) konsequent gefüllt.

1.19 Angebot zur Kommunikation Der Tarif des RMV weist einige Besonderheiten auf. Der RMV ermuntert daher alle Hersteller von Auskunfts- und Verkaufssystemen, die seinen Tarif abbilden, sich bei Fragen an die Mitarbeiter des Tarifs zu wenden, um Fragen zu klären. Bei Verkaufs- geräten wird auch angeboten, Exporte im Format 27- und 23-Felder zu testen.

250828-E Anlage_16_V4_2_45_003.docx S. 13 / 88

[Seite 14]

2. Strukturbeschreibung

Sortengruppen Jede Sortengruppe stellt eine Zusammenfassung (Gruppierung) von beliebig vielen Sortenschlüsseln dar. Sortengruppen dienen zur Reduktion der Zahl der Datensätze in der Tarifmatrix. Jede Sortengruppe umfasst mindestens einen Sortenschlüssel. Es können auch Einzel- und Zeitkarten-Sortenschlüssel zu einer Sortengruppe zusam- mengefasst sein. Eine Sortengruppe mit allen Sortenschlüsseln (also alle Einzel- und Zeitkarten) benö- tigt für Relationen, die sich in Einzel- und Zeitkarte nicht unterscheiden nur einen Da- tensatz.

Referenz zwischen Sortengruppe und Tarifmatrix Jede Fahrtvariante in der Tabelle “tarifmatrix“ besteht aus mindestens einem Daten- satz und erhält Bezug zu mindestens einer Sortengruppe. Da jede Sortengruppe aus mindestens einem Sortenschlüssel besteht, ist in der erweiterten Datenstruktur über die Sortenschlüssel eindeutig festgelegt, für welche Sortenschlüssel jede Fahrtvari- ante der Tarifmatrix gültig ist. Eine Fehlinterpretation wird damit ausgeschlossen.

Speicherung der Kurzstrecken-Angebote mit Zuordnung zur Haltestellen-Rela- tion In der Tarifmatrix wird die Information, welches Kurzstreckenangebot bei welcher Fahrtvariante gilt, gespeichert. Diese Information dient heute – Ausnahme Hanau – nur noch der Verkaufsdatenmeldung. In Hanau wird die Fahrkarte ohne Zielangabe als Kurzstrecke verkauft, so dass die Tarifrelation hier auch dem Verkauf dient.

Speicherung regional begrenzt gültiger Fahrkartenangebote mit Zuordnung zu einer oder mehreren Fahrtvarianten Sortengruppen erlauben weiterhin in der Tarifmatrix den Gültigkeitsbereich regional begrenzter Fahrkartenangebote festzulegen. Das bedeutet, jede Fahrtvariante erhält über die Sortengruppe eine Zuordnung der jeweils gültigen Sortenschlüssel. Diese Sortengruppen werden additiv zu den Sortengruppen des Regeltarifs (also des im RMV üblichen Tarifs) angelegt.

Speicherung haltestellenbezogener Kurzstrecken In einer separaten Tabelle sind die Haltestellen-Paare abgelegt, zwischen denen eine Kurzstrecken-Preisstufe gilt. Außerdem wird das jeweils gültige Kurzstrecken-Fahr- kartenangebot durch Sortenschlüssel und Preisstufe spezifiziert. Diese Tabelle kann auch Fahrtvarianten enthalten, die keine Kurzstrecken darstellen, aber auf die gleiche Art und Weise behandelt werden sollen. Aktuell wird von dieser Möglichkeit kein Gebrauch gemacht.

Speicherung der benachbarten Tarifgebiete zu allen Grenztarifgebieten Ein zusätzliches Attribut legt fest, welche Nachbarschaftsbeziehungen tariflich rele- vant sind.

Aufnahme von Grenztarifgebieten in die Freigabe Die Freigabe speichert alle Tarifgebiete, die mit einer Fahrtvariante jeweils befahren werden dürfen. Dies schließt auch die Grenztarifgebiete ein. Damit ist an jedem Punkt eines Fahrwegs die Aussage möglich, ob die Fahrkarte gilt oder nicht.

Speicherung einer Druckpreisstufe Zusätzlich zur Preisstufe wird das Feld „Druckpreisstufe” definiert. Damit soll den Kunden die Vielzahl unserer Preisstufen erspart werden.

250828-E Anlage_16_V4_2_45_003.docx S. 14 / 88

[Seite 15]

Speicherung jedes Viatextes genau einmal In der Datenstruktur ist es möglich, einen Viatext durch mehrere Fahrtvarianten zu re- ferenzieren.

Speicherung zusätzlicher, längerer Erläuterungstexte (Viatexte) Jede Fahrtvariante kann einen zusätzlichen Viatext referenzieren, der aus maximal 255 Zeichen besteht. Hier können nähere Erläuterungstexte (beispielsweise eine Be- schreibung der Fahrtroute) gespeichert werden. Dieser Text ist von Verkaufsgeräten und Auskunftssystemen mit grafischen Displays nutzbar, da hier die Anzeige längerer Texte möglich ist.

Datentypen (siehe ergänzende Hinweise zum csv-Format im Anhang):

Zahlenfelder enthalten kein Tausender-Trennzeichen. Dezimaltrennzeichen – siehe „csv-Format” im Anhang Tarifrechenkern: Der RMV-Tarifrechenkern liest die meisten Tabellen und deren Inhalte ein und verar- beitet diese weiter. Es gibt aus fachlichen und historischen Gründen aber auch Da- ten, die im Rechenkern nicht benötigt werden oder anders dargestellt werden. Alle Tabellenspalten, die im Rechenkern eine spezielle Bedeutung haben, werden im Be- schreibungsfeld markiert. Die Markierungen geben Auskunft über die Art der Abwei- chung:

 A: Im Tarifrechenkern nicht verfügbar. Wenn alle Spalten einer Tabelle mit A gekennzeichnet sind, so wird die komplette Tabelle nicht in den Rechenkern geladen.

 B: Im Tarifrechenkern, aber nicht in den Binärdaten von KIM verfügbar.

 C: Im Tarifrechenkern verfügbar, wird aber bislang nicht ausgewertet.

 D: Hat im Rechenkern ein anderes Format. In diesem Fall gibt es einen entspre- chenden Hinweistext hinter der Tabellendefinition.

250828-E Anlage_16_V4_2_45_003.docx S. 15 / 88

[Seite 16]

2.1 Tabelle „anschlusspunkt” Der RMV beabsichtigte, für den (Vor-)verkauf von Anschlusskarten an Automaten und Bus- druckern eine datentechnische Unterstützung einzurichten. Von der Umsetzung wurde in- zwischen Abstand genommen. Die Beibehaltung in den Daten erfolgt, weil unklar ist, ob das Fehlen dieser Tabelle beim Import in die Hintergrundsoftware der Busdrucker bzw. Automaten zu Fehlern führen würde. Die Daten werden jedoch nicht benötigt.

4.1 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.2 Tabelle „anzeige” Die Tabelle enthält, zusammen mit den Inhalten aus Tabelle „anzeigetexte” die Informati- onen zur Anzeige an Auskunftssystemen bzw. Verkaufsgeräten. Die Anforderungen an die Anzeige und ihre Umsetzung lässt sich wie folgt beschreiben:  Es dürfen nur mit RMV-Tarif vom aktuellen Standort (den ein Verkaufssystem i. d. R. kennt und der als erstes bei einem Auskunftssystem zu wählen ist) aus tarifierbare Ziele angezeigt werden. Dies gilt auch für die Fahrt in Übergangstarifgebiete.  Das gelernte Verhalten, die Tarifgebietsnummer einzugeben, soll weiterhin an- wendbar sein. Es wird jedoch zu Gunsten der Gemeinde-/Ortsteilangabe in den Hintergrund gestellt.  Alle Gemeinden, Ortsteile, Sonderziele und Grenzhaltestellen sowie die Kurzstreckenziele im RMV werden in das Zielverzeichnis aufgenommen. Damit wird erreicht, dass der Kunde innerhalb des Verbundes stets die gleiche Auswahl vorfindet und nicht nur die Ortsteile in der Nähe sieht, also bei einer Fahrt über eine größere Entfernung am Ausgangsort andere Ziele als am Zielort vorfindet (Ausnahme Kurzstrecke).  Alle Kurzstreckenziele, die vom aktuellen Standort aus erreichbar sind, werden dem Kunden angeboten. Der Kunde erhält eine Kurzstreckenfahrkarte, indem er sein Ziel aus diesem Angebot auswählt.

250828-E Anlage_16_V4_2_45_003.docx S. 16 / 88

[Seite 17]

 Haltestellen ohne spezielle tarifliche Bedeutung werden dem Kunden nur in Ausnahmefällen angeboten, also dann, wenn es sich um ein Sonderziel handelt. Damit wird vermieden, dass der Kunde an einem Automaten „Bahnhof“, „Friedhof“, „Schule“ usw. eingibt und der Kaufprozess sich wg. der unüberblickbaren Ergebnismenge verzögert.  Der RMV exportiert eine Liste, die den o. g. Anforderungen genügt. Die An- wendung erfordert, dass der Automat seinen Standort kennt und in der Lage ist, die erreichbaren Ziele auf Grundlage der Tarifdatenbank zu ermitteln und anschließend auch nur diese anzuzeigen. Bei einem Auskunftssystem muss der Kunde zunächst seinen Standort haltestellengenau (dann erhält er auch Auskünfte über die Kurzstrecke) oder tarifgebietsgenau (dann erhält er keine Auskunft über mögliche Kurzstrecken) angeben aus allen tarifierbaren Orten nach RMV-Tarif. Danach greift die analoge Logik wie beim Automaten. Abgekürzte Texte werden individuell für einzelne Namen (Gemeinde, Ortsteil, Sonderziel, Haltestelle) vergeben. Die Kombination von zwei oder drei Namen unter Beachtung der maximalen Gesamtlänge erfolgt im Bildungsprogramm des RMV nach Regeln ohne menschliches Zutun (z. B. wird umso stärker abgekürzt, je genauer die Auswahl wird, weil angenommen wird, dass die Nutzer sich bei einer sehr präzisen Auswahl örtlich ausken- nen). Die einzelnen Abkürzungen selbst sind jedoch durch den RMV vorgegeben. Damit soll einerseits die mögliche Gesamtlänge (von aktuell 30 bzw. 35 Zeichen) genutzt, aber auch nie überschritten werden. Andererseits soll dem Kunden auf allen Vertriebskanälen an allen Standorten die gleiche, ihm vertraute Abkürzung angeboten werden. Der Export ist derzeit auf die technischen Gegebenheiten des DB (30 Zeichen)- bzw. ICA (35 Zeichen)-Automaten abgestimmt. Sofern erforderlich, sind Anpassungen bzw. Erwei- terungen für andere Gerätetypen möglich und frühzeitig beim RMV-Tarif anzufragen.

4.2 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Der Supername ist anzuwenden,

 wenn es sich um eine Gemeinde mit mehreren Ortsteilen handelt. In diesem Fall muss der Kunde einen Ortsteil auswählen. Dies gilt auch dann, wenn die Auswahl aus tariflicher Sicht nicht nötig wäre, weil die ganze Gemeinde in einem einzigen Tarifgebiet liegt. Dieses Vorgehen wurde gewählt, um den Kunden an die stets gleichen Abläufe zu gewöhnen.

250828-E Anlage_16_V4_2_45_003.docx S. 17 / 88

[Seite 18]

 wenn es sich um einen Ortsteil mit mehreren Grenzhaltestellen, Sonderzielen oder Kurzstreckenzielen handelt. Damit wird sichergestellt, dass der Kunde stets die Möglichkeit erhält, ein für ihn tariflich günstiges Ziel zu wählen. Der Untername erfordert stets die vorherige Eingabe eines Supernamens und bildet des- sen Differenzierung. Wenn in einer Zeile der Datei ein Supername erscheint, muss ein Untername hierzu auswählbar sein – umgekehrt gilt, dass man keinen Unternamen direkt ohne vorherige Auswahl eines Supernamens auswählen kann. Der Name hat zwei Funktionen. Er wird dann gefunden, wenn es in einem Datensatz kei- nen Supernamen bzw. Unternamen gibt und er wird dargestellt, wenn ein Ziel in die dyna- mische Hitliste der häufigsten Ziele aufgenommen wird. Insgesamt bedeutet die gewählte Umsetzung für den Kunden, dass er bei einem Ziel (Ge- meinde, Ortsteil) entweder die Gemeinde (als Supernamen) eingibt und dann mittels der Unternamen ihm alle Ortsteile angeboten werden. Oder der Kunde kann den Ortsteil (als Name) eingeben und erhält dann entweder eine Auswahl an möglichen Gemeinden (z. B. beim Ortsteil „Allendorf“) oder die Gemeindezugehörigkeit ist eindeutig und das Tarifge- biet wird unmittelbar gefunden. Falls der Kunde eine Grenzhaltestelle, ein Kurzstreckenziel oder ein Sonderziel kennt, kann er auch dieses eingeben. Sonderziele und Grenzhaltestellen sollen unabhängig vom Standort (wenn überhaupt vom Standort aus tariflich erreichbar) stets gefunden werden, ein Kurzstreckenziel nur dann, wenn dieses vom Standort aus auch tatsächlich per Kurz- streckenfahrkarte erreichbar ist. Damit sind diese Haltestellen auf drei Wegen zu finden – direkt durch Eingabe einer Haltestelle als Name, indirekt durch Eingabe einer Gemeinde als Supername, wonach die Haltestelle neben den Ortsteilen als Untername angeboten wird und indirekt durch Eingabe eines Ortsteils als Supername, wonach die Haltestelle als Untername gefunden wird. Die Kurzstrecke ist nur dadurch zu erwerben, dass der Kunde die Taste „Kurzstrecke“ be- tätigt und dann eine Auswahl aller ab dem Standort zulässigen Kurzstreckenziele erhält. Er muss sich für eine der angebotenen Haltestellen entscheiden (dieses Ziel wird an- schließend auf die Fahrkarte gedruckt). Damit soll erreicht werden, dass der Kunde Si- cherheit beim Kauf der Kurzstrecke erhält und gleichzeitig die Zahl der „Graufahrer“, die über die Gültigkeit der Kurzstrecke hinausfahren, vermindert werden. Die Konsequenz ist, dass die Zulieferung hinsichtlich der Haltestellen und Kurzstreckenfahrtrelationen sicher- gestellt sein muss, sonst fehlt das Kurzstreckenziel und ist auch nicht anders erwerbbar.

2.3 Tabelle „anzeigetexte” Enthält die tatsächlichen Texte auf die aus Tabelle „anzeige“ heraus verwiesen wird. Die Textfelder haben strukturell eine Maximallänge von 99 Zeichen. Faktisch entsprechen die Längen der Textinhalte maximal der Länge, die in der Spalte “maxLaenge” abgelegt ist. So kann jede beliebige Länge bis 99 Zeichen beim Tarif angefordert, berechnet und aus- geliefert werden, ohne Änderungen an der Tarifdatenstruktur vornehmen zu müssen. Es ist vorgesehen, dass mehrere Textlängen parallel bereitgestellt werden. Der Anwender kann sich dann bei derjenigen Textlänge bedienen, die seinen Ansprüchen genügt. Ak- tuell werden Texte der Länge 30 und 35 standardmäßig ausgeliefert. Je vorab erzeugter maximaler Textlänge existiert ein vollständiger Satz von Anzeigetexten. Für ein Vertriebs- gerät mit einer Längenbeschränkung von 35 Zeichen ist also auf die Datensätze zu filtern die einen Eintrag in maxLaenge=35 haben. In dieser gefilterten Auswahl sind also auch die Texte zu finden die im Original bereits eine Länge 30 oder weniger Zeichen enthalten.

250828-E Anlage_16_V4_2_45_003.docx S. 18 / 88

[Seite 19]

4.3 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.4 Tabelle „bundesland” Die Tabelle enthält alle Bundesländer im Verbundgebiet. Zur  AGS und der  Gebiets- körperschaftsstruktur siehe entsprechenden Eintrag im Anhang (Glossar).

4.4 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.5 Tabelle „equi_tarifgebiet” Die Tabelle enthält für jedes Grenztarifgebiet (vormals  Grenzhaltestelle) sämtliche an- grenzenden Tarifgebiete zu denen eine EQUI Beziehung besteht. Eine EQUI Beziehung ist vom tariflichen Ergebnis her immer bidirektional (im Sinne einer Äquivalenz). Es exis- tiert aber nur ein Datensatz. Im zweiten Feld (ID_Tarifgebiet) steht immer das Grenztarif- gebiet und im dritten Feld (Equi_ID_Tarifgebiet) steht immer das ans Grenztarifgebiet an- grenzende TG. Tariflich gesehen ist die Aussage dieses Datensatzes, dass das jeweils andere TG tariflich äquivalent zu bewerten ist

250828-E Anlage_16_V4_2_45_003.docx S. 19 / 88

[Seite 20]

4.5 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.6 Tabelle „erweiterte_freigabe“ Die Freigabe der CleverCard während der hessischen Schulferien und an hessischen Fei- ertagen wird in der Tabelle „sortenschluessel_ext“ definiert. Dabei handelt es sich um die Netzfreigabe. Für Tarifrelationen, die eine Freigabe innerhalb der Übergangstarifgebiete aufweisen muss die Netzfreigabe der CleverCard zusätzlich um die freigegebenen Über- gangstarifgebiete erweitert werden. Diese erweiterten Freigaben werden in der Tabelle „erweiterte_freigabe“ definiert. Befindet sich für eine CleverCard und eine Tarifrelation kein Eintrag in dieser Tabelle, dann wird während der Schulferien und während der Feier- tage die Netzfreigabe aus „sortenschluessel_ext“ verwendet. Ansonsten überschreibt diese Tabelle den dortigen Eintrag.

4.6 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.7 Tabelle „fahrausweisart“ Existenztabelle aller Fahrausweisarten (z. B. Einzelfahrkarte). Siehe auch Tabelle „kundengruppe“.

4.7 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 20 / 88

[Seite 21]

2.8 Tabelle „fahrkartentext” Diese Tabelle wird für eine bessere Unterstützung der Vertriebstechnik bereitgestellt. Die Zielsysteme können verschiedene Fahrkartentexte mit unterschiedlicher Länge nutzen. Sortimentsname, Fahrkartentext_50 (Umwidmung: vormals vertrieblicher Text – jetzt nur noch intern zu verwenden) und Fahrkartentext_255 sind interne Bezeichnungen einer Fahrkarte für Tariffachleute und abrechnende Stellen, die alle Eigenschaften, teilweise abgekürzt, darstellen. Sie sind NICHT für die Kommunikation mit dem Kunden gedacht. Fahrkartentext_20, -_25, -_30, -_60 und Infotext_EFS_40 sind in der Kundenkommunika- tion, d. h. für den Aufdruck auf die Fahrkarte bzw. Auskunft, Verkauf oder Prüfung auf elektronischem Weg zu nutzen. Infotext_EFS_40 ist in jedem Fall für das eTicket zu nut- zen. Im Gegensatz zu bisherigen Auslieferungen sind alle Felder stets gefüllt. Es ist Aufgabe des Anwenders, die größtmögliche Länge des Namens auszunutzen.

4.8 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Für eine bessere Unterstützung der Vertriebstechnik wird eine ergänzende Tabelle bereit- gestellt (fahrkartentext_zusatz), die die Bausteine, aus denen sich die Fahrkartentexte zu- sammensetzen samt passenden Abkürzungen enthält. Die Vertriebstechnik erhält ein- zelne Elemente (z. B. für den schrittweisen Kauf am Automaten oder im TicketShop), die sie bedarfsgerecht einsetzen kann.

2.9 Tabelle „fahrkartentext_zusatz“ Existenztabelle der Zusatz-Spezifikationen eines Fahrkartentextes (z. B. „Frankfurt-Pass“, „Lahnau“ oder „AIRLiner“). In den Feldern „Beschreibung“, „Abkuerzung_1“ und „Abkuer- zung_2“ sind genau die auf die Fahrkarten aufzudruckenden Texte enthalten.

250828-E Anlage_16_V4_2_45_003.docx S. 21 / 88

[Seite 22]

4.9 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Das Feld Info_Erfordernis beschreibt, ob der zusätzliche Fahrkartentext eine zwingende Angabe ist, weil dies zur Unterscheidung von Fahrkarten erforderlich ist (Bsp. 1: „Frank- furt-Pass“) oder man diese Angabe zur Information ausdrucken darf, oder aber 3: die An- gabe auf die Fahrkarte nicht aufgedruckt werden soll (Bsp. 3: Lahnau), sondern nur als Information angegeben werden darf.

2.10 Tabelle „fahrtrelation“ Die Tabelle enthält alle Fahrtrelationen. Jede Fahrtrelation ist als Relation zwischen zwei Haltestellen abgelegt. Aktuell werden in der Tabelle nur Kurzstrecken abgelegt. In der Zu- kunft ist es aber vorstellbar, auch allgemeine Fahrtrelationen in dieser Tabelle zu spei- chern, daher die neutrale Bezeichnung. Es gilt hier Richtungsbezug. Das heißt, gibt es von A nach B eine Fahrtrelation, dann gibt es von B nach A nur dann eine Fahrtrelation, wenn dieser Datensatz ebenfalls in der Ta- belle vorhanden ist. Es handelt sich also (im Gegensatz zur Tabelle „tarifmatrix”!) um eine Vollmatrix. Der Eintrag unter ID_ViaText wird nur dann wirksam, wenn er gefüllt ist1. Sonst ist als Via- text der zur Haltestelle ID_Via_Hst zugehörige Haltestellenname zu verwenden. Die Fahrtrelation ist nicht gleichzusetzen mit einem Fahrweg! Eine Fahrtrelation beinhaltet u.U. ein ganzes Bündel erlaubter Fahrwege. Die verknüpfte Tabelle „freigabe_fahrtrelation“ (Details siehe dort) beinhaltet die erlaubte Menge der Teil- fahrtrelationen.

Anmerkung zum Feld "ID_Hst_Via": Die ID "99999" definiert den Sachverhalt, dass keine genaue Via-Haltestelle angegeben werden kann, man aber trotzdem auf eine Besonderheit hinweisen möchte. Entweder, weil es keine Via-Haltestelle gibt oder weil zu viele unterschiedliche Linienwege existie- ren. Die referenzierte Haltestelle liegt als Datensatz in der Tabelle "haltestelle.csv" vor, allerdings besitzt sie keine Koordinaten.

1 GTS-Intern bleibt das Feld ID_ViaText leer – es wird nur dann gefüllt, wenn es sich vom Haltestellenna- men unterscheidet. Beim Export werden dann die Datensätze mit einem leeren Feld ID_Via_Hst mit dem Haltestellennamen der Via-HST gefüllt und die Tabelle ID_ViaText analog.

250828-E Anlage_16_V4_2_45_003.docx S. 22 / 88

[Seite 23]

4.10 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Das ehemals Sortierung genannte Feld (Feld 9) war bislang noch nie gefüllt. Durch die Ersetzung durch das Feld ID_Verkehrsmittelgattungsgruppe mit gleichem Typ bleiben po- tentiell bestehende Importroutinen funktional unverändert bestehen. Zur Reihenfolge von Anzeigen siehe Hinweis zur Tabelle „anzeige“.

2.11 Tabelle „flaechenrelation“ Die Einträge in den Spalten ID_START_MENGE und ID_ZIEL_MENGE referenzieren über „freigabe“ und „freigabe_tzcode“ auf IDs aus der Tabelle „tarifgebiet“. Die Flächenrelation darf nur angezeigt / verkauft werden, wenn die Tarifanfrage im START-TG aus einem so referenzierten (d. h. „erlaubten“) Start-TG UND das ZIEL-TG der Tarifanfrage aus einem so referenzierten (also „erlaubten“) Ziel-TG stammt. Das tarif- lich befahrbare Ergebnis (also die tarifliche Freigabe) ist hingegen durch ID_Freigabe de- finiert. In einem Verkaufssystem führen die Flächenrelationen i. d. R. zu einer besonderen Be- handlung. Busdrucker und Automaten verkaufen üblicherweise keine Jahreskarten, so dass im Regelfall nur das HessenTicket, evtl. noch das Heinerfestticket an einigen Tagen des Jahres auf eine spezielle Taste zu legen sind. Da es sich hier um technisch sehr ein- fache Fahrkarten handelt, ist ein automatisierter Import etwas zu aufwändig. Zu einem noch nicht genau absehbaren Zeitpunkt soll es einige Dutzend derartige Angebote geben, die i. d. R. jedoch regional begrenzt sein werden. Da die genaue Ausgestaltung noch nicht bekannt ist, kann es sinnvoll sein, mit einem automatischen Import zu warten. Eine unternehmensspezifische Implementierung des Verkaufs solcher Angebote sollte, wenn gefordert, immer gewährleistet werden können. Diese muss sich hinsichtlich des Verkaufs nicht zwangsweise aus den gelieferten Tarifdaten speisen. Hingegen ist sicher- zustellen, dass die zu liefernden Verkaufsdatensätze den in den Daten und dieser Spezifi- kation formulierten Anforderungen genügen als ob die Tarifdaten dem Verkauf zugrunde

250828-E Anlage_16_V4_2_45_003.docx S. 23 / 88

[Seite 24]

gelegen hätten. Dies kann u.U. durch ein Hintergrundsystem (HGS) gewährleistet wer- den, zumeist aber werden Informationen wie Standort, Verkaufszeit, Relation, Über, und anderes eine Rolle spielen, die einem HGS entsprechend zur Verfügung gestellt werden müssen.

4.11 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Die Tabelle enthält alle Flächenangebote (siehe 1.15). Hinweis: Die tariflich befahrbare Freigabe ist immer mindestens so groß wie die Menge der Start bzw. der Ziel-TGs. Das Umgekehrte gilt nicht: Wenn Start-TG und Ziel-TG in der tariflichen Freigabe einer flaechenrelation liegen, qualifiziert dies die fragliche flaechenre- lation noch nicht zum Verkauf. (Weitere Hinweise siehe 1.15).

250828-E Anlage_16_V4_2_45_003.docx S. 24 / 88

[Seite 25]

2.12 Tabelle „freigabe“ Existenztabelle, die sämtliche Freigaben enthält, die in der Tabelle „tarifmatrix“ referen- ziert erden.

4.12 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.13 Tabelle „freigabe_fahrtrelation“ Die Tabelle enthält alle Freigaben zu jeder Fahrtrelation (faktisch „Kurzstrecke“), die in der Tabelle „fahrtrelation“ enthalten ist. Die Freigabe einer Fahrtrelation besteht aus einer Menge atomarer (sprichwörtlich: „nicht mehr teilbarer“) Fahrtabschnitte (Teilstrecken ohne Zwischenhalt), was sich darin begründet, dass jede Teilstrecke einer Fahrtrelation eben- falls eine Fahrtrelation sein muss (bei Kurzstrecken ist die Vorgabe sichergestellt). Die Freigabe regelt tariflich, welche Wegelemente zwischen zwei Haltestellen mit einer Kurz- streckenfahrkarte befahren werden dürfen. Durch die Menge der freigegebenen, atoma- ren Fahrtrelationen und deren Start- und Ziel-Haltestellen lässt sich die Gesamtmenge al- ler (erlaubten) Fahrwege einer Fahrtrelation rekonstruieren. Die Freigabe beschreibt je- doch nicht einen einzelnen Fahrweg, sondern versammelt alle Teilstrecken die als Kurz- streckenfahrt genutzt werden dürfen. Obwohl das Datenmodell grundsätzlich auch eine fahrwegscharfe Abbildung erlaubt, werden (zugunsten der Datenmenge) alle Fahrvarian- ten unter einem Eintrag in der Tabelle „fahrtrelation“ zusammengefasst.

4.13 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.14 Tabelle „freigabe_tzcode“ Die Tabelle enthält alle Tarifgebiete zu allen Freigaben, die in der Tabelle „freigabe“ ent- halten sind. Eine Freigabe regelt tariflich, welche Tarifgebiete mit einer bestimmten Fahr- karte auf einer bestimmten Fahrtvariante befahren werden dürfen. In der Freigabe sind auch Grenztarifgebiete aufgeführt.

250828-E Anlage_16_V4_2_45_003.docx S. 25 / 88

[Seite 26]

4.14 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.15 Tabelle „fussweg“ Die Tabelle beinhaltet die zulässigen Fußwege zwischen zwei Haltestellen. Dabei handelt es sich um die Wege, die man zu Fuß unternehmen darf, ohne eine begonnene Kurzstre- ckenfahrt abzubrechen. Fußwege sind (als Datenobjekte) nur an Umstiegspunkten er- laubt, also nicht am Start oder am Ende einer Fahrt. Beispiele: Kurzstrecke mit dem Fahrtverlauf A – B – C – D.

 Die Strecke A–B ist Fußweg: Der Kunde benötigt eine Fahrkarte von B nach D.  Die Strecke C–D ist Fußweg: Der Kunde benötigt eine Fahrkarte von A nach C.

 Die Strecke B–C ist Fußweg: Der Kunde benötigt eine Fahrkarte von A nach D. Die Strecke B–C fehlt in der Freigabe der Kurzstrecke, da dieser Weg Fußweg ist. Er ist stattdessen in dieser Tabelle definiert. Auf diese Weise wird die Freigabe vollstän- dig.

4.15 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.16 Tabelle „gemeinde“ Die Tabelle enthält sämtliche Gemeinden im Verbundgebiet und in den Übergangstarifge- bieten mit Zuordnung zum jeweiligen Landkreis. Es ist zu beachten, dass die Gebietshie- rarchie bundesland-spezifisch organisiert ist und daher oft der Ortsteil hessischer Lesart einer Gemeinde z. B. in Bayern entspricht.

4.16 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 26 / 88

[Seite 27]

Tarifgebiet oder Obertarifgebiet, in dem die meisten Haltestellen der Gemeinde liegen. Er- streckt sich die Gemeinde über mehrere Tarif- FK ID_Calc_Tarifgebiet dbLong gebiete, enthält das Feld das jeweilige Ober- tarifgebiet. Wenn die Haltestellen in mehreren Obertarifgebieten liegen, bleibt das Feld leer. Referenz zur Tabelle „tarifgebiet“.

2.17 Tabelle „haltestelle“ Wie aus den Feldern der Tabelle zu ersehen ist, wird jede Haltestelle einem Tarifgebiet und einem Ortsteil zugeordnet. Der Ortsteil ist wiederum einem Tarifgebiet zugeordnet. Beide Tarifgebietszuordnungen können sich unterscheiden. Dies ist bspw. bei allen Halte- stellen in Grenztarifgebieten der Fall, da Grenztarifgebiete eine eigene Tarifgebietsnum- mer besitzen. Wenn in einem Ortsteil Haltestellen die sich nicht in Grenztarifgebieten be- finden dennoch abweichende Tarifgebietszuordnungen haben, ist dies nur durch eine Aufteilung des Ortsteils in mehrere Tarifgebiete darstellbar. Der Inhalt des Feldes Name_Vertrieb soll für die Darstellung der Haltestelle des Fahrtan- tritts (=Verkaufsort) bei Kurzstrecken, Einzelkarten und Anschlusskarten verwendet wer- den. Dies gilt für den Druck auf Papier wie für das Speichern im Mobiltelefon und später ggf. auch für die Speicherung auf dem eTicket. Der Name ist so gewählt, dass er sowohl für Bahnhöfe im Schienen- und Busverkehr wie auch für reine Busverkehre sinnvoll ist.

4.17 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 27 / 88

[Seite 28]

2.18 Tabelle „hst_2_verkehrsmittelgattung” In dieser Tabelle werden die Verknüpfungen zwischen den Haltestellen und Verkehrsmit- telgattungen gespeichert.

4.18 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.19 Tabelle „kalender“ Die Tabelle führt alle hessischen Feier- und Ferientage sowie Tage mit besonderen Aktio- nen auf, je Tag ein Datensatz. Die Kennung markiert ob es sich um einen Feier-, Ferien- oder einen Aktionstag handelt. Je Tag und Tagestyp wird ein eigener Datensatz gebildet.

4.19 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 28 / 88

[Seite 29]

Zusatzinfo zu ID_Bundesland: Die Datenstruktur ist bereits für zukünftige Erweiterungen vorbereitet. Feiertage und Ferien außerhalb Hessens spielen tariflich aber in absehbarer Zeit keine Rolle. Der Tarifrechenkern liest nur Kalendereinträge von Hessen ein.

2.20 Tabelle „koordinaten“ Die Tabelle enthält Koordinaten für, je nach SRID Typ, international einheitlich definierte referenzierte Projektionen / Koordinatensysteme. Jeder Eintrag entspricht einem Punktkoordinatensatz von bis zu 3 Werten. Gespeichert werden max. drei Koordinatenangaben. Je nach Koordinatentyp und dem dahinterstehen- den Koordinatensystem sind dies bspw. Länge, Breite, Höhe als kartesische Zahlenwerte, oder bspw. im System „Gauß-Krüger Zone 3“ sind in den gleichen 3 Feldern der Rechts- wert, der Hochwert und „NULL“ abgelegt. Da die Werte – je nach Koordinatensystem – negative(!) Werte, hohe ganzzahlige numerische Werte, als auch Gradangaben oder bis auf die 6. Stelle genaue Kommazahlen enthalten können, ist der Datentyp generell für den allgemeineren Fall als Gleitkommazahl (dbDouble) festgelegt. Trotzdem wird speziell für WGS84 aus Gründen der Handhabbarkeit und Abwärtskompa- tibilität ein Faktor von 1.000.000 einberechnet. Die gespeicherten ganzzahligen Werte sind also durch 1 Mio. zu teilen um die originären WGS84 Koordinaten zu erhalten. Die Referenz für einen Datensatz aus der Tabelle „haltestelle“ (zur Zeit die einzige Refe- renz zu „koordinaten“) verweist auf eine Menge von Datensätzen, die sich im SRID Wert unterscheiden. Jeder Eintrag bildet die gleiche Koordinate für die jeweilige Projektion ab. Diese, eigentlich redundante Speicherung ist der nicht trivialen Umrechnung zwischen WGS84 und Gauß-Krüger Koordinaten geschuldet und erlaubt eine einfache Nutzung, je nach den verwendeten Zielsystemen. Über eine entsprechende Filterung kann die Daten- menge dann auf die im Zielsystem eingesetzten Koordinatensysteme / Projektionen redu- ziert werden. Eine Vollständigkeit (Speicherung jeder Koordinate für alle Projektionen) wird allerdings nicht garantiert und ist für den geeigneten Anwendungsfall selbst zu unter- suchen. Eine Lieferung aller Koordinaten in allen Projektionen wird zwar angestrebt aber nicht garantiert. Jedes Objekt kann also mehrfach mit den entsprechend umgerechneten Werten für ver- schiedene Koordinatensysteme abgespeichert sein.

4.20 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 29 / 88

[Seite 30]

Im Fall von WGS84 nimmt Wert1 die geografische Länge und Wert2 die geografische Breite auf. Im Fall von GK3 enthält die Referenz auf Hofheim Bf in Wert1 den Rechtswert, in Wert2 den Hochwert und in Wert3 ebenfalls keinen Wert. Hinweis: Es kann zwischen den GK3 Projektionen 82027 und der häufig als gleichwertig angesehenen Projektion 31467 zu Verschiebungen im Bereich zwischen 100 und 200 Metern kommen. Ähnliches gilt für die WGS84 Projektionen 4326 und 8307.

Beispiel: Für „Hofheim Bf“ (RMV_Hst_ID = „4199“) sind die Koordinaten in der WGS84 Projektion: Östl. Länge = 8,444550 Grad Nördl. Breite = 50,084253 Grad

Die gespeicherten Werte in „koordinaten“ lauten: für den Eintrag mit SRID = 8307 Wert1=8444550 Wert2=50084253 Wert3={leer}

für den Eintrag mit SRID = 82027 Wert1=3460147 Wert2=5549915 Wert3={leer}

2.21 Tabelle „kundengruppe“ Existenztabelle aller existierenden Kundengruppen (z. B. „Erwachsene“). Im Feld „Be- schreibung“ ist genau der auf die Fahrkarten aufzudruckende Text enthalten.

4.21 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.22 Tabelle „landkreis“ Die Tabelle enthält sämtliche Landkreise im Verbundgebiet inkl. ÜT.

250828-E Anlage_16_V4_2_45_003.docx S. 30 / 88

[Seite 31]

4.22 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.23 Tabelle „landkreis2rp” Hierüber wird die Zuordnung eines Landkreises zum Regierungspräsidium bereitgestellt, das den Landkreis enthält.

4.23 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.24 Tabelle „linie“ Diese Tabelle enthält die Gültigkeiten sämtlicher Linien samt ihren verfügbaren Versio- nen. Gültigkeitsbereich und Priorität definieren die Gültigkeit am jeweiligen Tag. Im Export „Standard“ (siehe 1.3) wird die Tabelle immer leer ausgeliefert.

4.24 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.25 Tabelle „linien_version“ Diese Tabelle enthält die Gültigkeiten sämtlicher Linien samt ihren verfügbaren Versio- nen. Gültigkeitsbereich und Priorität definieren die Gültigkeit am jeweiligen Tag. Im Export „Standard“ (siehe 1.3) wird die Tabelle immer leer ausgeliefert.

250828-E Anlage_16_V4_2_45_003.docx S. 31 / 88

[Seite 32]

4.25 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.26 Tabelle „ortsteil“ …führt alle Ortsteile im Verbundgebiet inkl. ÜT mit Zuordnung zu ihrer Gemeinde auf.

4.26 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.27 Tabelle „partner“ Diese Tabelle ersetzt die Tabelle bisherige Tabelle „lno“. Informationen der vorherigen Tabelle „lno“ (LNO = eine Lokale-Nahverkehrs-Organisation (LNO) des RMV) sind voll- ständig in dieser Tabelle enthalten. Hinzu kommen zusätzliche Einträge anderer Partner wie bspw. Verkehrsunternehmen oder Partner jenseits des RMV. Diese Verallgemeine- rung wurde erforderlich, weil Daten (wie bspw. Haltestellen) außerhalb der Grenzen des RMV-Kerngebiets einer besseren Zuordnung und Abgrenzung bedurften. Haltestellen können einem Datensatz dieser Tabelle durch das Feld „ID_Partner“ (inhaltlich äquivalent der ID_LNO der alten Tabelle „lno“) zugeordnet werden, was deren Verantwortungsbe- reich beschreibt. Da auch Haltestellen in Übergangstarifgebieten (ÜTs) Teil der Haltestel- lentabelle sind, kann nun strukturell jede Haltestelle einem Partner zugewiesen werden.

250828-E Anlage_16_V4_2_45_003.docx S. 32 / 88

[Seite 33]

Im RMV Kerngebiet ist dies nahezu ausnahmslos eine LNO. Die Zuordnungen werden sukzessive eingearbeitet.

4.27 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.28 Tabelle „plz” Die Postleitzahlen sind den Tarifgebieten zugeordnet. Auf diese Datei kann bei Bedarf zu- gegriffen werden.

4.28 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Anmerkung: Einem Postleitzahlenbereich können mehrere Tarifgebiete zugeordnet sein. Umgekehrt gilt das Gleiche. Jeder Datensatz enthält genau eine Zuordnung zwischen ei- ner PLZ und einem TG. Geometrisch bedeutet dies, dass jeder Eintrag in „plz“ Flächen- stücke repräsentiert, die je ein TG und ein PLZ-Gebiet gemeinsam haben (Mehrere nicht verbundene Flächenstücke, die Ergebnis der Schnittmenge eines TG und eines PLZ Ge- bietes sind führen aber nur zu einem Eintrag, da es sonst Doppeleintragungen gäbe). Ein Tarifgebiet wird einer PLZ i. d. R. nur dann zugeordnet, wenn sich im Bereich der PLZ eine Haltestelle befindet.

2.29 Tabelle „preisliste“ Diese Tabelle enthält sämtliche Fahrpreise nach der aktuellen Preisliste des RMV mit Zu- ordnung zum Sortenschlüssel. Die Felder „MWST_Satz” und „MWST_Betrag” werden nicht gefüllt. Der Inhalt ist NULL (d. h. kein Inhalt / leer) oder eine 0 (Beides kann in unterschiedlichen Datensätzen einer Datenlieferung gemischt vorkommen).

4.29 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 33 / 88

[Seite 34]

Referenz zur Tabelle „sortenschluessel”

2.30 Tabelle „preisstufe“ Existenztabelle aller Preisstufen.

4.30 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Tarifrechenkern: Die Preisstufe wird im Rechenkern als dbLong definiert.

2.31 Tabelle „rp” Die Ebene „Regierungspräsidium” ist als zusätzliche Hierarchieebene der Gebietskörper- schaftsstruktur zwischen dem Bundesland und den Landkreisen angesiedelt. Die ältere Verknüpfung zwischen Bundesland und Landkreis bleibt weiterhin bestehen. Für die Definition und die Zuordnung sind zwei ergänzende Tabellen verfügbar. In der ersten Tabelle (Datei: „rp.csv“) wird das Regierungspräsidium dem Bundesland zugeord- net.

250828-E Anlage_16_V4_2_45_003.docx S. 34 / 88

[Seite 35]

4.31 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.32 Tabelle „sonderziele” Sonderziele helfen dem Kunden, tarifliche nicht notwendige, aber aus Kundensicht oft ge- wählte Ziele am Automaten zu finden. Die maximale Preisstufe soll die Zahl der angezeig- ten Ziele an einem Automaten begrenzen. Aktuell ist das nicht erforderlich – es gibt nur etwa 50 Sonderziele – es kann aber sinnvoll sein, wenn man weitere Sonderziele anlegt. Hinweis: Der Bezug zu einem Ortsteil oder zu einer Haltestelle ist optional. Hinweis: Es gibt einzelne Sonderziele (z. B. City“, „Innenstadt“, …), die nur in Zusammen- hang mit weiteren Angaben sinnvoll sind. In den Tabellen „anzeige“ bzw. „anzeigetext“ ist dies berücksichtigt.

4.32 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.33 Tabelle „sorte_2_fahrkartentext“ Die Tabelle verknüpft jeden Eintrag der Tabelle „sortenschluessel” mit den ihm zugewie- senen Fahrkartentexten aus der Tabelle „fahrkartentext”.

250828-E Anlage_16_V4_2_45_003.docx S. 35 / 88

[Seite 36]

4.33 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.34 Tabelle „sortengruppe“ Existenztabelle aller Sortengruppen. Eine Sortengruppe fasst mehrere Sortenschlüssel zusammen. Die Sortengruppen werden in der Tabelle „tarifmatrix“ referenziert. Sie stellen den Zusammenhang zwischen Fahrtvariante und Sortenschlüssel her.

4.34 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.35 Tabelle „sortengruppe_2_sorte” Den Sortengruppen werden hierüber Sortenschlüssel zugewiesen.

4.35 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.36 Tabelle „sortengruppe_2_verbund“ Optionale Verknüpfung um zukünftig die Möglichkeit zu erhalten auch richtungsabhängig unterschiedliche Tarife zwischen RMV und Übergangstarifen abzubilden. Fehlt die Ta- belle oder gibt es für die beteiligten Verbünde an einer Tarifrelation keinen Eintrag dann gilt der Standardfall, dass keine tarifliche Richtungsabhängigkeit vorliegt (spiegelbildlicher Tarif). Dies ist aktuell innerhalb des RMV und für alle Übergangstarife der Fall. Gibt es für EINEN in der Tarifrelation betroffenen Verbünde (vulgo „Tarifgebiete“) (Start oder Ziel) einen Eintrag in Tabelle „verbund“ mit dem Verbundtyp = 3, dann ist gemäß der nachfolgend beschriebenen Logik zunächst festzustellen ob es sich um eine ein- oder ausbrechende Relation handelt. Dies führt zur hier gespeicherten Sortengruppe. Ist für die betroffene Richtung die ID_Sortengruppe = 0, dann ist der Verkauf in dieser Richtung nicht erlaubt. Die Tariftypen „TRUE“ und „FALSE“ sind wie folgt zu identifizieren: Da die Tarif- matrix als Halbmatrix gespeichert ist (bei der die Relation, abhängig vom numeri- schen Wert der beteiligten Tarifgebiete, immer „von klein nach groß“ gespeichert ist) kann keine zuverlässige Aussage darüber getroffen werden, ob die darin ge- speicherte Relation die einbrechende oder die ausbrechende Relation darstellt. Da-

250828-E Anlage_16_V4_2_45_003.docx S. 36 / 88

[Seite 37]

her muss der Verbundtyp (Tabelle „verbund") der beteiligten Tarifgebiete zu Hilfe ge- nommen werden. So ergibt sich zuverlässig die Aussage: Wenn der Verbundtyp des Starttarifgebietes gleich „1“, (und der Typ des Ziel-TG = „3“) dann ist in der Tarifmatrix die ausbrechende ÜT-Relation gespeichert, im umgekehrten Fall die einbrechende. Sinnge- mäß wäre dann die in dieser Tabelle gespeicherte Tarifinformation (u.U. invers) auszu- werten und gegebenenfalls nicht anzuwenden. Die Tariftypen sind (prophylaktisch) vorge- sehen um bspw. über darauf bezugnehmende Sortengruppen bestimmte Produkte mit un- terschiedlichen Preistabellen zu versorgen oder auch den Verkauf nur in einer Richtung zu ermöglichen.

4.36 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.37 Tabelle „sortenschluessel“ Die Tabelle enthält alle Sortenschlüssel der im RMV verkauften Fahrkarten. Über die Re- ferenz in die eigene Tabelle mithilfe des Eintrags im Feld „ID_Referenzsorte” kann der zu- gehörige Referenzsortenschlüssel (Feld „Sortenschluessel”) gefunden werden. Jeder Sorte ist auf diese Weise eine Referenzsorte zugewiesen. Die Referenzsorte verweist auf sich selbst. Der Regeltarifbezug und die Verkaufsverpflichtung verdeutlichen den Verkehrsunterneh- men, ob die aktuelle Sorte anstelle einer anderen zu nutzen ist oder ob sie zusätzlich an- zubieten ist. Hinweis zum intuitiven Verständnis der „Referenzsorte“: Spezialausprägungen der per- sönlichen Monatskarten die bspw. nur in einem best. Landkreis bezuschusst an eine be- stimmte Personengruppe abgegeben werden, haben als Referenzsorte die „normale“ Mo- natskarte. Sie stammen gewissermaßen von ihr ab, sind Derivate, Abarten der Refe- renzsorte und damit in den nicht abweichenden Eigenschaften eben gerade mit der Refe- renzsorte gleich (bspw. der zeitlichen Gültigkeit).

4.37 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 37 / 88

[Seite 38]

Enthält, sofern gefüllt, aus dem Quellsystem (GTS) die textlich zusammengefügten Feld- inhalte aus den Feldern „zusätzliche Informa- Zusatz_Info dbText(50) tion“ und „Zahlungsmodus“ wie bspw. „Bahn- card einmalige Barzahlung“. Häufig ist nur ei- nes oder keines der Quellfelder gefüllt

250828-E Anlage_16_V4_2_45_003.docx S. 38 / 88

[Seite 39]

Anmerkungen und Beispiele zum Feld „Berechtigungstyp“:Ein Wert Berechtigungstyp = 0 besagt: Keine der oben angegebenen Eigenschaften liegt vor. Dies ist bspw. bei der Einzelfahrkarte gegeben. Sie ist nicht persönlich, aber auch nicht übertragbar (nur der die Fahrt antretende Kunde darf das Ticket nutzen, es gibt aber auch kein identifizierendes Persönlichkeitsmerkmal). Ein Wert von 32930 (=32768+128+32+2: Bit 16, Bit 8, Bit 6, Bit 2) würde bspw. bei einem Ticket „Zuschlag 1. Klasse persönlich Abo 1x“ für eine persönliche Jahreskarte Folgendes bedeuten: Bit 2 besagt, dass es sich um ein persönliches Ticket handelt – also die Personalien stimmen müssen. Bit 8 besagt: Diese Zuschlagfahrkarte (alleine) berechtigt nicht zum Fahrtantritt. Erst die erfolgreiche Prüfung (Validierung) eines anderen EFS (elektr. Fahrscheins) weist die not- wendige Fahrtberechtigung nach. Das Prüfgerät selbst führt diese Prüfung automatisch durch ODER zeigt an, dass ein solches „Hauptticket“ auf dieser Chipkarte nicht vorliegt. Bit 16 besagt zudem, dass noch ein „Hauptticket“ nötig ist das vorzuzeigen ist, das (als Stammkarte), die eigentliche Fahrtberechtigung enthält. Bit 6 besagt, dass hiermit die 1. Klasse benutzt werden kann. Hintergrund dieser komplex erscheinenden Bit Kombinationen ist ein grundlegend unter- schiedliches Verhalten zwischen den (((eTicket Geräten zur Einstiegskontrolle mit Kom- munikation zum Kunden (die nur rot und grün oder allenfalls noch einen dritten Anzeige- modus kennen) und den Möglichkeiten, welche Prüfern mittels Prüfgeräten zur Verfügung stehen. Diese können bspw. auch auf die Existenz eines FV-Tickets oder einer anderen Berechtigung prüfen (sofern diese nicht bereits beim Kauf vorliegen musste). Die Komplexität solcher Prüfungen ist an einer Einstiegskontrolle nicht durchführbar, ins- besondere wenn noch nicht alle zugrundeliegenden Nachweise elektronisch prüfbar sind. Andererseits soll kein „false positiv“ Signal eine Fahrtberechtigung signalisieren die bspw. in Form eines 1. Klasse Zuschlags alleine faktisch gar nicht vorliegt. Demzufolge führt ein alleiniges Ticket mit gesetztem Bit 8 zu einer Anzeige „rot“ bei der elektronischen Ein- stiegskontrolle: Der Kunde muss das zugehörige Hauptticket vorlegen und prüfen lassen. (Anmerkung: Sind beide Tickets in der gleichen Chipkarte gespeichert wird automatisch vorrangig Letzteres mit „grün“ geprüft.) Im Unterschied zum oben geschilderten Bsp. in dem Bit 8 (nicht alleine validierbar) wirk- sam wird, ist mit Bit 5 der Sachverhalt codiert, dass ein weiterer Nachweis, ein von elekt- ronisch prüfbaren Tickets unabhängiges Dokument vorgelegt werden muss (typisch wäre ein Schüler- oder ein Personalausweis). Da dieses nicht vom Prüfgerät geprüft wer- den kann, hat dieses Bit nur Relevanz für Vorgänge die durch Prüfpersonal durchgeführt werden. Ein Ticket kann „per se“ zwar gültig sein, aber durch Bit 3 (Kind) kann angezeigt werden, dass es eben ein Ticket für ein Kind ist – der Inhaber also als solches zu identifizieren sein sollte. Ein Erwachsener / Jugendlicher der mit einem Kinderticket bei der Einstiegs- kontrolle zunächst „grün“ erhält, kann bei der Fahrscheinkontrolle durch einen Prüfer mit einem Symbol-Hinweis (oder bspw. ein „K“) in der Anzeige des Prüfgerätes als „Fahrkarte ist für diese Person nicht gültig“ identifiziert werden.

250828-E Anlage_16_V4_2_45_003.docx S. 39 / 88

[Seite 40]

Weitere, insbesondere für Hersteller von Prüfgeräten relevante Hinweise im Zusammen- wirken der Prüfanzeigen mit Bit 8 sind in Zusatzdokumenten zu finden, die sich mit der Anzeige auf Prüfgeräten befassen.2

Folgend wird noch einmal in andrer Formulierung auf den Unterschied zwischen Bit 5 und Bit 8 eingegangen:

Das Bit 8 (Wert 128) dient dem KIM-Modul (respektive PKM-Modul) der Gerätesoftware von KA-Terminals zur automatisierten Validierung (Gültigkeitsprüfung) von EFS.

• Bedeutung „nicht_alleine_validierbar“ in KIM bzw. PKM: Dieses EFM-Produkt kann dem KIM-Modul (res- pektive PKM-Modul) nicht als EFS zur automatisierten Validierung zugrunde gelegt werden.

Alle anderen Bits dienen der Anzeige von Informationen am Display der Terminals (mobile Kontrollgeräte, Ein- stiegskontrolle, Infoterminals, etc.).

• Bedeutung Bit 5 (Wert 16) „nicht_alleine_gueltig“: Dieses EFM-Produkt (Sorte) benötigt einen Nachweis zur Fahrtberechtigung. Das Display kann damit bspw. einen „Zettel“ als Symbol aufzeigen. Dies als allgemeine Info oder weiter im Detail erläutert durch: o Bedeutung Bit-Wert 8192 „nicht_alleine_gueltig_FVEK (Fernverkehrs-Ergänzungskarte)“: Dieses EFM-Produkt (Sorte) benötigt eine Fernverkehrs-Zeitkarte der DB o Bedeutung Bit-Wert 16384 „nicht_alleine_gueltig_BahnCard (derzeit noch kein Produkt (Sorte) mit diesem Bit als eTicket RheinMain umgesetzt)“: … o Bedeutung Bit-Wert 32768 „nicht_alleine_gueltig_Stammkarte“: Dieses EFM-Produkt (Sorte) be- nötigt eine Zeitkarte des RMV.

Anmerkungen zum Feld „Drucksortenschluessel“: Es handelt sich hierbei nicht um eine ID sondern um den tatsächlichen Sortenschlüssel, der als Platzhalter in den eTickets enthalten ist (bei der Ausgabe eines eTickets muss der jeder Sorte zugewiesene Drucksortenschlüssel anstelle des Sortenschlüssels in den RMV-EFS für das eTicket RheinMain gespeichert werden). Datensätze die den Drucksor- tenschlüssel selbst repräsentieren, müssen nicht in allen Vertriebskanälen Bestandteil der Tarifdatenlieferung sein. In den Prüfdaten ist er selbstverständlich enthalten. Insofern kann die referentielle Integrität hinsichtlich der Vollständigkeit der im Feld referenzierten Sorten gebrochen sein. Für die Aufgaben des Vertriebs, des Verkaufs und der Auskunft stellt dies aber keine Einschränkung dar. Zur Bedeutung der im neuen Feld „Ticketform_Text“ enthaltenen Inhalte sind ggf. Informatio- nen beim RMV einzuholen.

2.38 Tabelle „sortenschluessel_ext" Die Tabelle definiert abweichende Freigaben für räumlich definierte Zeitkarten, wie z.B. die CleverCard. Die abweichende räumliche Gültigkeit bei der erweiterten CleverCard- Freigabe ist auf die hessischen Schulferien sowie die Feiertage in Hessen beschränkt. Dies wird über die Referenz zur Tabelle sortenschluessel_gueltig dargestellt. Die abwei- chende räumliche Gültigkeit der Sortenfreigabe ist durch die Tabelle „sortenschlues- sel_ext“ bestimmt, die einen Verweis auf einen anderen Eintrag der Tabelle „freigabe“ enthält, als er durch die Tarifrelation definiert ist. Die Tabelle kann nur einen Eintrag je Sortenschlüssel beinhalten. Die Freigabe der CleverCard kann darüber hinaus bei be- stimmten Tarifrelationen durch Einträge in der Tabelle „erweiterte_freigabe“ überschrie- ben werden, und zwar genau dann, wenn es dort einen Eintrag für die entsprechende Ta- rifrelation und den entsprechenden Sortenschlüssel gibt.

4.38 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Schlüssel Feldname Datentyp Beschreibung

2 z.B. „Anzeige eTicket RheinMain am Fahrer-Prueferdisplay“ bei RMV/rms erfragen.

250828-E Anlage_16_V4_2_45_003.docx S. 40 / 88

[Seite 41]

Abstrakter Primärschlüssel PFK ID_Sortenschluessel dbLong Referenz zur Tabelle „sortenschluessel"

2.39 Tabelle „sortenschluessel_gueltig" Die Tabelle regelt einen abweichenden räumlichen oder zeitlichen Gültigkeitsbereich der Sorte, aktuell für das SeniorenTicket Hessen, das HessenTicket und die CleverCard.

4.39 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 41 / 88

[Seite 42]

Zahlenwert der die Uhrzeit des Gültigkeitsendes im Format HHMM repräsentiert. Uhrzeit_bis dbNum(4) Bsp: 2400 für 24:00 Uhr

Aus dem Feld VT_Muster werden neben den Einträgen für Feiertage (11) und Ferien (12) in Hessen alle dreistelligen Werte in der Tabelle „kalender“ definiert. Aus Gründen der Vereinfachung sind die restlichen Definitionen (Wochentage / Immer) intern hart definiert.

2.40 Tabelle „strecke" Diese Tabelle verweist auf alle Strecken die einer Unterlinie zugrunde liegen. Es werden nur solche Strecken exportiert, die vollständig im Bereich der Tarifierung des RMV bzw. eines Übergangstarifes liegen und deren beide Endpunkte eine gültige (und in der expor- tierten Haltestellentabelle vorhandene – siehe Hinweis unter 2.17) Haltestelle sind. Dadurch kann es im Linienverlauf im Einzelfall zu einer Lücke kommen.

4.40 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Zusatzinfo zu Entfernung1 - Entfernung5: Die Angaben verstehen sich in Meter. Alle Entfernungsfelder sind aktuell nicht gefüllt. Entfernung1 ist die seitens der rms (oder eines sonstigen Lieferanten) auf der Karte ge- routete Entfernung auf Straße oder Schiene – mit Lot auf den Haltestellenmast. Entfernung2 ist die seitens der rms (oder eines sonstigen Lieferanten) auf der Karte ge- routete Entfernung auf Straße oder Schiene – ohne Lot auf den Haltestellenmast. Diese

250828-E Anlage_16_V4_2_45_003.docx S. 42 / 88

[Seite 43]

Strecke wird daher für die Kurzstrecken genutzt – es sei denn, es handelt sich um Frank- furt und Offenbach. Entfernung3 ist für die VGF-Linien von Frankfurt – auch nach außen – zugelieferte Entfer- nung, die mittels Messfahrt direkt ermittelte Streckenentfernung.

2.41 Tabelle „tarifgebiet" Die Tabelle enthält alle Tarifgebiete des RMV einschließlich der Übergangstarifgebiete. Nicht alle Einträge dieser Tabelle treten nach außen in Erscheinung. Einige Einträge wer- den aus rein datentechnischen Gründen benötigt. Der Tarifgebietsname ist erst für die Zeit nach der Tarifstrukturreform vorgesehen, wenn die Tarifgebiete eindeutige Namen bekommen werden. Aktuell kann ein Tarifgebiet ein- deutig nur durch seine Tarifgebietsnummer angesprochen werden. Es ist nicht zulässig, im Umgang mit Kunden (bspw. für Tickets) Namen für ein Tarifgebiet zu nutzen! (Heute im Einzelfall doch bereits gespeicherte Tarifgebietsnamen dienen lediglich der in- ternen Unterstützung bei der Identifikation eines Tarifgebiets.)

Felder Link zur: Tabellenübersicht

2.42 Tabelle „tarifgebiet_typ" Existenztabelle zur Klassifizierung der Tarifgebiete.

250828-E Anlage_16_V4_2_45_003.docx S. 43 / 88

[Seite 44]

4.41 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Neben den aufgelisteten Typen von Tarifgebieten können weitere Typen intern definiert sein.

2.43 Tabelle „tarifgebietsfolge" Diese Tabelle führt alle von einer Strecke berührten Tarifgebiete auf.

4.42 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.44 Tabelle „tarifmatrix" Die Tabelle enthält alle Fahrtvarianten zwischen den durch "ID_Tarifgebiet_Start" und "ID_Tarifgebiet_Ziel" repräsentierten Tarifgebieten im gesamten Verbundgebiet inkl. der ÜT mit ihrer jeweiligen Zuordnung zu Sortengruppe und Preisstufe. Es handelt sich um eine Halbmatrix mit: ”TZ_Code des Tarifgebiet_Start" <= "TZ_Code des Tarifgebiet_Ziel" (Vorsicht: NICHT etwa: ID_Tarifgebiet_Start <= ID_Tarifgebiet_Ziel), Es ist zur Verwendung des vierstufigen Suchalgorithmus (Abschneideregel 1.0) zu emp- fehlen, Start und Ziel gemäß diesen Anforderungen aufsteigend zu sortieren. Die Nicht-Verkaufbarkeit einer Relation wird implizit über folgende Kriterien mitgeteilt:  Es gibt keine Tarifrelation von Tarifgebiet_Start nach Tarifgebiet_Ziel.  Das Feld ID_ViaText enthält eine 0. Achtung: Das sichere Kriterium ist NICHT der Text ”nicht verkaufbar” der unter der ID 0 in der Tabelle „viatext“ zu finden ist, sondern die hier eingetragene ID 0 selbst, unab- hängig vom gefundenen Text.  ID_Preisstufe ist leer. Dieses Kriterium ist hinsichtlich der Nichtverkaufbarkeit ein- deutig und ausreichend. Wenn die anderen Kriterien für Nichtverkaufbarkeit auftreten,

3 wird nur für datentechnische Zwecke benötigt (z. B.: für das via ”über 0”)

250828-E Anlage_16_V4_2_45_003.docx S. 44 / 88

[Seite 45]

dann ist dieses Kriterium immer ebenfalls erfüllt. Explizit vorkommende Datensätze mit leerer Preisstufe sind in entsprechenden Verkaufsabläufen u.U. ausdrücklich mit ei- nem entsprechenden Kundendialog auszuwerten.  ID_Freigabe ist leer, enthält also keinen Eintrag. Achtung: Der Umkehrschluss gilt nicht: Ein Eintrag ohne Freigabe kann auch andere Gründe haben. Es gilt aber die Aussage: Alle verkaufbaren echten Relationen verweisen auf eine echte Freigabe. Nur noch zur Abgrenzung tarifierbarer und nicht tarifierbarer Tarifrelationen werden letz- tere in Einzelfällen exportiert, wenn sie zur Unterscheidung verschiedener Wegevarianten benötigt werden (Beispiel 2645 7400 0/2600) – Bezug zur Abschneideregel.

4.43 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Zusatzinfo zu: „Via-Text“ und tarifliches „Über“ Eine Tarifrelation besteht fachlich aus einem Von (referenziert durch ID_Tarifgebiet_Start), Nach (referenziert durch ID_Tarifgebiet_Ziel) und Über (referenziert durch ID_Tarifgebiet_Via), wobei es sich hier um Tarifgebiete oder beim Über auch um Platzhalter (0, 9998, 9999) handeln kann. Achtung: In unterschiedlichen Tarifrelationen können demselben „Über“ (Tarifgebiet) voll- kommen verschiedene Über-Texte zugeordnet werden. Es gibt also keinen eindeutigen Zusammenhang zwischen ID_Tarifgebiet_Via und den in den betroffenen Tarifrelationen

250828-E Anlage_16_V4_2_45_003.docx S. 45 / 88

[Seite 46]

jeweils zugeordneten Über-Texten! Der durch ID_ViaText (oder ID_Z_ViaText) referen- zierte „Über-Text“ wird in der spezifischen Relation so gewählt, dass er den Weg in geeig- neter Weise beschreibt. Auch ist es nicht so, dass ein „Über 0“ immer den Text „ohne Umweg" nach sich zieht. Die Beziehung besteht also nicht zwischen Über und Über-Text, sondern zwischen der Tarifrelation und Über-Text. Zusatzinfo zu: ID_Tarifgebiet_Via Wird hier ein Tarifgebiet des Typs ”KRA” (Keine Räumliche Ausdehnung) referenziert, dann dient dies dazu die Vollständigkeit der Einträge der Matrix zu gewährleisten. Dies ist ein Hinweis, dass bei den referenzierten Tarifgebieten mit den TZ_Codes 9998 und 9999 mehrere Wege zu einem zusammengefasst sind – eine bessere Beschreibung ist dann nicht möglich.

2.45 Tabelle „uebertragbarkeit“ Existenztabelle der Regelungen für die Übertragbarkeit.

4.44 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Das Feld Info_Erfordernis beschreibt, ob die Übertragbarkeit eine zwingende Angabe ist, weil dies zur Unterscheidung von Fahrkarten erforderlich ist (Bsp.: Es gibt persönliche und übertragbare Jahreskarten) oder man diese Angabe zur Information ausgeben kann (Bsp.: Monatskarten des Regeltarifs sind grundsätzlich übertragbar), aber nicht muss.

2.46 Tabelle „unterlinie" Diese Tabelle enthält die Fahrtrichtungen aller Linienversionen.

4.45 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 46 / 88

[Seite 47]

Anmerkung zum Feld Variante: Ein Fahrtverlauf kann mehrere Varianten haben, z.B. kann eine Fahrt am Wochenende zusätzliche Haltestellen anfahren. Es werden alle Vari- anten im System hinterlegt, allerdings ohne Hinweis, zu welchen Bedingungen die einzel- nen Varianten zum Einsatz kommen.

2.47 Tabelle „unterlinie_2_strecke" Diese Tabelle enthält die Streckenabschnitte, die einer Unterlinie zugeordnet sind – so- fern sie vollständig im RMV-Tarifraum oder einem Übergangstarifgebiet liegen und beide Endpunkte gültige Haltestellen darstellen. Dabei ist zu beachten, dass nicht alle Strecken einer Linie exportiert werden, sondern nur die tarifrelevanten Abschnitte. Daraus können im Linienverlauf Lücken entstehen, wenn Abschnitte außerhalb des Tarifierungsbereichs liegen oder Haltestellen nicht als gültig gelten. Zudem ist die Spalte Sequenz_Nr (Reihenfolge der Abschnitte) nicht immer lü- ckenlos durchnummeriert. Wichtig ist zudem, dass das Fehlen einzelner Sequenznummern nicht automatisch be- deutet, dass Streckenteile fehlen. Andere systemseitige Kriterien können ebenfalls dazu führen, dass bestimmte Abschnitte nicht exportiert werden.

4.46 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.48 Tabelle „verbund" Diese Tabelle beinhaltet alle Verbünde, die die vorliegenden Tarifgebiete abdecken. Der Typ „3“ und die damit vorgesehene Möglichkeit einer Tarifabhängigkeit von der Rela- tionsrichtung hat aktuell keine praktische Bedeutung und ist nur vorausschauend definiert. Der Tarifrechenkern kann diese „Verkaufsrichtungsabhängigkeit“ anhand des Typenwer- tes ebenfalls aktuell (noch) nicht auswerten.

4.47 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 47 / 88

[Seite 48]

2.49 Tabelle „verkehrsmittelgattung“ In dieser Tabelle werden alle definierten Verkehrsmittelgattungen gesammelt. Diese kön- nen z.B. wie folgt definiert sein: AST, Bus, Fähre, Fernbus, R-Bahn, S-Bahn, Sonstig (z.B. Seilbahn), Tram, U-Bahn, Zug.

4.48 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.50 Tabelle „verkehrsmittelgattung_2_gruppe“ Den Verkehrsmittelgattungsgruppen werden hierüber Verkehrsmittelgattungen zugewie- sen.

4.49 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.51 Tabelle „verkehrsmittelgattungsgruppe“ Menge von Verkehrsmittelgattungen, um diese für den Einsatz in Tarifrelationen und Flä- chenrelationen zusammenzufassen.

4.50 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.52 Tabelle „version" Die Versionstabelle ist nicht mit anderen Tabellen verknüpft. Die Tabelle speichert, wel- che Matrixversion mit welcher Gültigkeit in der aktuellen Datenbank zu finden ist. Es gibt immer nur einen Datensatz.

250828-E Anlage_16_V4_2_45_003.docx S. 48 / 88

[Seite 49]

4.51 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.53 Tabelle „viatext" Der Viatext liefert eine Kurzbeschreibung der Fahrtvariante, durch die er in der Tarifmatrix referenziert wird. Hier können sowohl Verkehrsmittel als auch Weginformationen abgelegt werden. Jeder unterschiedliche ViaText wird einmal abgelegt.

4.52 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.54 Tabelle „waehrung" Tabelle der unterstützten Währungen (aktuell nur Euro).

4.53 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 49 / 88

[Seite 50]

Bezeichnung dbText(20) Währungs-Bezeichnung (A)

2.55 Tabelle „zahlungsmodus“ Existenztabelle der Regelungen für den Zahlungsmodus.

4.54 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Das Feld Info_Erfordernis beschreibt, ob der Zahlungsmodus eine zwingende Angabe ist, weil dies zur Unterscheidung von Fahrkarten erforderlich ist (Bsp.: Es gibt Jahreskarten per Einmalzahlung, als jährlich oder monatliches Abonnement) oder man diese Angabe zur Information ausgeben kann (Bsp.: Monatskarten des Regeltarifs sind nur per einmali- ger Zahlung zu erwerben), aber nicht muss.

2.56 Tabelle “z_viatext" Zusätzlicher, längerer Viatext. Wird nur von Verkaufsgeräten angezeigt, die in der Lage sind, längere Texte anzuzeigen.

4.55 Felder Link zur: Tabellenüber- sichtTabellenübersicht

2.57 Struktur der Tabelle “schema.ini" Die Tabelle enthält Schema-Informationen zu den einzelnen Tabellen als Zusatzinforma- tion. Es werden in dieser Tabelle keine tariflichen Daten gespeichert, so dass sie formal nicht zu den eigentlichen Tarifdaten gehört. Es handelt sich um eine sogenannte Initiali- sierungsdatei. Dabei wird folgende Syntax verwendet: [Tabellenname] Schlüssel=Wert

Es werden folgende Schlüssel-Wert-Paare aufgeführt:

250828-E Anlage_16_V4_2_45_003.docx S. 50 / 88

[Seite 51]

4.56 Felder Link zur: Tabellenüber- sichtTabellenübersicht

Für jede Spalte wird jeweils der Name der Spalte (in Großbuchstaben) sowie der Daten- typ aufgeführt. Folgende Datentypen sind möglich:

Beispiel: [tarifmatrix.csv] ColNameHeader=False Format=Delimited(;) CharacterSet=ANSI Col1=ID_TARIFMATRIX Integer Col2=ID_TARIFGEBIET_START Integer Col3=ID_TARIFGEBIET_ZIEL Integer Col4=ID_TARIFGEBIET_VIA Integer Col5=ID_SORTENGRUPPE Integer Col6=VAR_NR Integer Col7=ID_VIATEXT Integer Col8=ID_Z_VIATEXT Integer Col9=ID_FREIGABE Integer Col10=ID_PREISSTUFE Integer Col11=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer

250828-E Anlage_16_V4_2_45_003.docx S. 51 / 88

[Seite 52]

2.58 Tabelle „xxx_sosa_zzz.csv" Die Endung wird hier extra erwähnt, weil es auch eine nicht zu verwechselnde Datei sosa_xxx.xml gibt. Letztere enthält das vollständige Sortenkontingent und die vollständi- gen Sorteninformationen. Sie ist daher aus Datenschutzgründen nur für den RMV- internen Gebrauch bestimmt. Die hier betrachteten partnerspezifischen Exporte werden als csv Dateien mit folgendem Namensschema erzeugt: XXX_Sosa_JJJJMMTT-HHMMSS.csv Dabei steht XXX symbolisch als Kennung für den Partner in Grossbuchstaben. Mit JJJJMMTT-HHMMSS wird der Zeitstempel des Exportes im Dateinamen festgehalten. Diese Exporte enthalten einen Extrakt der wichtigsten Sorteneigenschaften der für den Partner relevanten Sorten. Sie werden, getrennt von den allgemeinen Tarifdaten Dateien, die als Paket bereitgestellt werden, nur auf konkrete Vereinbarung hin partnerspezifisch (aus dem System SOSA) bereitgestellt.

4.57 Felder Link zur: Tabellenüber- sichtTabellenübersicht

250828-E Anlage_16_V4_2_45_003.docx S. 52 / 88

[Seite 53]

250828-E Anlage_16_V4_2_45_003.docx S. 53 / 88

[Seite 54]

3 Verkaufs- und Einnahmenmeldungen

Der RMV benötigt Verkaufsdatenmeldungen als Einzelverkaufsdaten (je Verkaufsvorgang ein Datensatz) im 27-Felder-Format.

3.1 Datenlieferung über webbasierte Technologie (EVi) Für die Einlieferung der monatlich zu liefernden Verkaufsdaten wird ein personalisierter Zugang über eine Weboberfläche bereitgestellt, der mit einem aktuellen Web-Browser unter folgender Adresse erreichbar ist. https://einnahmen.rmv.de

Das hierbei eingesetzte verschlüsselnde https-Protokoll sichert dabei die Daten auf dem Übertragungsweg.

Die erforderlichen Zugangsdaten werden auf Anfrage durch den RMV eingerichtet und mitgeteilt (Kontakt unter: evi-meldetool@rmv.de).

Für die Datenlieferung über EVi gilt:

a. Es ist monatlich genau eine Lieferung mit den dann verfügbaren Verkaufsdatensätzen einzuliefern. Die monatliche Lieferung kann in mehreren Dateien, bspw. getrennt nach Linien, eingeliefert werden. Eine Korrektur kann entweder durch eine manuelle Eingabe erfolgen oder durch die Funktion „Stornierung der Datei“. Bei einer Stornierung der Datei wird die komplette Datei von Evi ins Minus gesetzt und somit storniert. Im Anschluss kann die Datei wieder eingelesen werden. Nach dem Abschluss eines Jahres wird aus den bis dahin eingelieferten Verkaufsdaten des entsprechenden Kalenderjahres das jährliche Einnahmentestat erstellt; lediglich Abgrenzungsposten werden ggf. zuvor noch ergänzt.

b. Stornos aus Verkaufsvorgängen und Korrekturen sind als Stornodatensätze zu liefern. Diese können u.U. auch Wirtschaftsperioden überschreiten. Der Stornodatensatz erhält eine andere ID (Feld 1) als der zu stornierende Datensatz.

Bsp: Ein Verkauf A wurde fälschlich mit 1,50 EUR gemeldet anstatt, wie verkauft, mit 1,55 EUR.

Es müssen insgesamt 3 Datensätze geliefert werden.

1.) Mit ID A der Verkauf mit 1,50 EUR (wurde bereits [falsch] gemeldet).

2.) Mit ID B die Stornierung, mit negativer Anzahl (-1) und negativem Preis (Umsatz) (-1,50 EUR).

3.) Mit ID C der korrekte Datensatz mit 1,55 EUR.

c. Insbesondere ist auch im Dezember nur eine Lieferung fällig. Dies gilt auch für die seit 2014 geltende Regelung, bei der Tarifwechsel (Wechsel der Tarifrelationen zum Fahrplanwechsel) und Preiswechsel (am 1.1.) zeitlich auseinanderfallen. Bis zum Tarifwechsel am Sonntag nach dem zweiten Samstag im Dezember sind die Daten also mit der alten Tarifversion zu versehen, danach mit der neuen.

d. Inhaltliche Korrekturen (in Form von Storno und Ergänzungsdatensätzen) können in jeder Folgelieferung enthalten sein, solange der jeweilige Verkaufszeitpunkt in einen noch nicht abgeschlossenen Abrech- nungszeitaum fällt.

e. Es dürfen weder einzelne Verkäufe, noch Korrekturen (Stornos) mehrfach geliefert werden, weder in der gleichen, noch in getrennten Lieferungen.

f. Jeder Datensatz hat eine eindeutige ID (Spalte 1), auch Stornodatensätze und korrigierte Datensätze.

g. Der Dateiname der Lieferung ist wie folgt aufzubauen, insbesondere um eine spätere Identifizierung bei Rückfragen und Klärungen zu erleichtern (zu Inhalten der Felder 2 bis 3 siehe nachfolgenden Abschnitt) und um Lieferungen seitens verschiedener AN mit identischen Dateinamen zu vermeiden. Die eckige Klammer ist NICHT Teil des Dateinamens:

Feld2_Feld3_JJJJ-MM_[Freitext].csv

250828-E Anlage_16_V4_2_45_003.docx S. 54 / 88

[Seite 55]

Für die zur Zeit der Dokumenterstellung bereits bekannten, RMV-seitig zentral geführten elektronischen Systeme – die als virtuelle Linienbündel (VLB) im Feld 4 dargestellt werden – ist nachfolgend der Datei- name davon abweichend wie folgt definiert:

Tabelle 1: Inhalte Feld 4 bei virtuellen Linienbündeln

Für ggf. weitere, zukünftige Systeme wird der RMV sinngemäß Vorgaben mit dem betroffenen Partner vereinbaren. [Freitext] ist optional und nur zu verwenden, wenn er zur notwendigen Unterscheidung von Lieferungen beiträgt, bspw. bei Korrekturlieferungen als laufende Nummer wie bspw. „02“. Es ist zu beachten, dass bei Weglassung des Freitextes der Dateiname vor dem Punkt als letztes Zeichen einen Unterstrich enthält. h. Es werden keine Headerzeilen geliefert. Die erste Zeile einer Lieferung enthält den ersten Datensatz.

i. Die in Tabelle 7 beschriebenen Längen beziehen sich auf die reinen Inhalte der Felder. Bei alphanume- rischen Inhalten werden evt. mitgelieferte, maskierende doppelte Anführungszeichen nicht mitgezählt. Ein alphanumerisches Feld der Länge 2 kann also wie folgt geliefert werden: „00“.

j. Bei numerischen Feldern werden, sofern Nachkommastellen definiert sind, alle Stellen gezählt, inkl. dem Dezimaltrennzeichen. In einem Feld mit der angegebenen Maximallänge von 12,6 können also höchs- tens 19 Zeichen übertragen werden. Max. 12 Ziffern vor dem Komma (ohne Tausendertrennpunkt), das Komma und max. 6 Ziffern nach dem Komma.

k. Im jährlichen Einnahmentestat sind ergänzend zu den in EVi bereits hochgeladenen Daten die Einnah- men aus dem DeutschlandTarifVerbund zu melden. Dies erfolgt in hierfür vorgesehenen Feldern des aus EVi generierten Testatformulars.

l. Fahrtrelationen (= Kurzstrecken ) sind in den Tarifdaten haltestellenbezogen eingepflegt. Sie enthalten also keine direkte Tarifrelation. Dennoch soll bei Von – Nach – Über in den Verkaufsdaten eine Tarifre- lation geliefert werden, die wie folgt zu bilden ist.

Feld 17 / Von: Tarifgebiet der Starthaltestelle Feld 18 / Nach: Tarifgebiet der Zielhaltestelle Feld 19 / Ueber: 0

3.2 Lieferwege und spezifische Dateninhalte

250828-E Anlage_16_V4_2_45_003.docx S. 55 / 88

[Seite 56]

Nur aufgrund der Inhalte der Felder 2 bis 4 jedes Datensatzes ist eine Zuordnung der eingelieferten Daten zur abrechnenden Stelle (Abrechnungskennung), Verkehrs-Service-Vertrag (VSV) bzw. Linienbündel mög- lich. Diese sind somit alleine bestimmend für die sich aus den Daten ergebende Abrechnung zwischen den Partnern. Dabei ist grundsätzlich zwischen regionalem und lokalem Verkehr zu unterscheiden. Die Lieferung der Verkaufsdaten nach dem hier beschriebenen Verkaufsdatenstandard erfolgt bei:

 lokalem Verkehr (VSV zwischen lokaler Nahverkehrsorganisation (LNO) und Auftragnehmer (AN)):

Je Monat seitens des AN an die LNO.

Nach Eingang und Abschließen aller Monatsmeldungen der der LNO zugehörigen AN Freigabe der LNO an den RMV.

 regionalem Verkehr (VSV zwischen RMV und AN):

Je Monat seitens des Auftragnehmers (AN) an den RMV.

Es ist daher unabdingbar, dass die Kennzeichen (Kürzel) in den Feldern 2 bis 4

 eindeutig zwischen den betroffenen Partnern für die Dauer des VSV abgestimmt sind und

 konsequent und korrekt Verwendung finden.

Lieferungen die hinsichtlich der Felder 2 bis 4 Abweichungen zu den Vorgaben enthalten, können nicht an- genommen werden, da in der Folge die darauf basierende automatische Abrechnung scheitern muss. Die monatlichen Lieferungen können in mehreren Dateien, bspw. getrennt nach Linien, eingeliefert werden. Wei- tere Bedingungen zur Trennung der Dateien stehen bei den Anmerkungen zu den Datenfeldern 2 bis 4.

Abb. 1: Lieferweg der Verkaufsdaten bei lokalen, regionalen und gemischten Bündeln

Ausnahme virtuelles Linienbündel

Gemischte Bündel sind gemäß ihrer lokalen und regionalen Anteile, wie oben dargestellt, getrennt zu liefern.

Linien die stückweise als regionale und lokale Linien unter einer Liniennummer laufen, werden ab- schnittsweise betrachtet und hinsichtlich der Meldungswege wie gemischte Bündel behandelt.

250828-E Anlage_16_V4_2_45_003.docx S. 56 / 88

[Seite 57]

Anbieter die ‚per definition’ als regionale Verkehrsunternehmen agieren, sind hinsichtlich all ihrer Li- nien wie regionaler Verkehr zu betrachten.

Die von diesen Unternehmen betriebenen Vorverkaufsstellen und stationären Automaten werden hin- sichtlich ihrer Verkäufe und Einnahmen ebenfalls als rein regionale Verkehre gemeldet.

Tabelle 6.2: Inhalte Feld 2 bis 4 bei Verkaufsdatenmeldungen

Es sind nur Kürzel zu verwenden die dem AN zur Einlieferung der Daten vom RMV zugeteilt wurden. Für elektronische Systeme oder Pilotprojekte wie bspw. HandyTicket, TicketShop o.ä. gelten ggf. abwei- chende Regelungen die der RMV mit den Betreibern im Einzelfall abstimmt. Die aktuell bekannten sind in Tabelle 6.1 abgebildet.

3.3 Einliefervorgang Einlieferungen, auch Einlieferungen mit mehreren Dateien, werden durch EVi entgegengenommen und nach festgelegten Kriterien auf Kompatibilität zu den Vorgaben der 27-Felder-Matrix geprüft. Das gleiche gilt für Dateneingaben, die direkt in der Anwendung erfolgen können.

Nach Prüfung der Einlieferung wird deren Qualität angezeigt:

 Status rot (fataler Fehler): Die Datenlieferung weist graviernde(n) Fehler auf (wie bspw. die oben erwähnten Abweichungen zu den Vorgaben in den Feldern 2 bis 4). Die Datenlieferung ist nicht im- portierbar und wird abgelehnt.

 Status gelb (Warnung): Die Datenlieferung weist geringfügige Fehler auf (z.B. keine oder falsche Starthaltestelle, falsches Tarifgebiet etc.). Die Datenlieferung kann freigegeben und damit als Ein- nahme gemeldet werden. Warnungen sind jedoch ein deutlicher Hinweis, dass der Verkauf Mängel aufweist. Der RMV erwartet; dass die Einlieferer im Zeitablauf dafür sorgen, die Zahl der Warnungen zu reduzieren und ggf. auf Anfrage die dazu eingeleiteten Maßnahmen beschreiben können.

 Status grün: Die Datenlieferung ist fehlerfrei und erfüllt alle Vorgaben der 27-Felder-Matrix. Die Da- tenlieferung kann freigegeben und damit als Einnahme gemeldet werden.

Nach der Prüfung kann eine Liste der fatalen Fehler bzw. Warnungen eingesehen und/oder exportiert werden. Jede Lieferung kann durch den Anwender verworfen werden (bspw. um Fehler zu überarbeiten). Die Liefe- rungen, deren Prüfung ohne fatale Fehler erfolgte, können zur endgültigen Übernahme zusammengestellt und als Zwischenmeldung (Freigabe jederzeit möglich, ohne den Monat abzuschließen) bzw. als abschlie- ßende Monatslieferung freigegeben werden. Korrekturmöglichkeiten bestehen in der Lieferung von Storno- datensätzen in der Lieferung nachfolgender Monate oder in der Stornierung der gesamten Datei. Perioden- übergreifende Stornodatensätze werden akzeptiert.

Die Prüfungen sind vorgefertigt und erfolgen automatisiert. Es ist nicht möglich, alle auftretenden Fehler zu erfassen. Status grün bedeutet also nicht zwingend, dass die Meldung ohne Fehler ist. Umgekehrt ist es im Einzelfall möglich, dass Daten gemäß Status gelb einwandfrei sind. Für die abschließende Beurteilung benö- tigt es menschlichen Sachverstand.

3.4 Tarifdaten, Verkaufsdaten und deren Aktualisierung Die tariflichen Vorgaben werden in Form der jeweils aktuellen Tarifmatrix des RMV vorgegeben.

250828-E Anlage_16_V4_2_45_003.docx S. 57 / 88

[Seite 58]

Die Verkaufsdaten sind gemäß der beigefügten Tabelle unter Einhaltung der Reihenfolge der Felder zu mel- den. Die Reihenfolge der Datensätze ist ohne Belang.

Der Auftragnehmer (AN) sammelt seine Einzelverkaufsdaten aus allen Vertriebswegen und ggf. die seiner Unterauftragnehmer und liefert sie in der unten dargestellten Form. Der AN ist verpflichtet, seine technische Ausstattung und seine Betriebsabläufe hierauf abzustimmen.

Die Verkaufsdaten sind als csv-Datei je Abrechnungspartner (=Abrechnungskennung) mit Semikola als Trennzeichen zu liefern. Jede Zeile enthält genau einen Datensatz. Jeder korrekte Datensatz muss genau 27 Felder, also 26 Semikola enthalten (auch dann, wenn Feldinhalte teilweise leer sein sollten). Die Zeile ist mit CRLF abzuschließen.

Auch dann, wenn sich Verkaufsvorgang und Storno des Verkaufsvorgangs innerhalb der gleichen Datenlie- ferung aufheben, sind beide Verkaufsvorgänge in die Übergabedatei einzustellen. Mit einer Teilstornierung wird ein finanzieller Teil eines Geschäftsvorgangs rückgängig gemacht. Solche Vorgänge müssen gemeldet werden. Der Vorgang der Rückgabe wird durch den Vorgang des Stornos bzw. der Teilstornierung abgedeckt. Auch rein geldmäßige Rückerstattungen sind gleichermaßen zu melden.

250828-E Anlage_16_V4_2_45_003.docx S. 58 / 88

[Seite 59]

3.5 Beschreibung der Verkaufsdaten im Detail Tabelle 2: Datenformat der Verkaufsdaten

• Nicht der NAME sondern die DHID oder die RMV-ID ist zu liefern. Zur globalen Haltestellen-ID siehe Glossar am Ende des Dokuments und Hinweise zum Feld „Starthaltestelle“

250828-E Anlage_16_V4_2_45_003.docx S. 59 / 88

[Seite 60]

Bei negativen Zahlen kommt das Vorzeichen als zusätzlich mögliches Zeichen zur hier angegebenen Feld- länge hinzu. Tausender-Trennpunkte sind hier nur zur besseren Lesbarkeit dargestellt. Geliefert wird eine Zeichenfolge ohne Tausender-Trennzeichen.

Beispiel für eine Verkaufsdatenmeldung (Feldnamen nicht zu liefern – hier kursiv nur zur Erläuterung darge- stellt). Auf Leerzeichen in einem Feld kann verzichtet werden, nicht aber auf das Feldtrennzeichen (Semiko- lon), auch nicht, wie hier zu sehen, auf das Letzte!

ID;Abrechnungskennung;Unternehmen;LokBuendel;Vktech;Anzahl;Wstdat;VkZeit;Ps;Sorte;;Geraet;

Z_art;Umsatz;Subvention;TV;Von;Nach;Ueber;SHst;Linie;Ri;FahrtNr;gueltig_ab;RefKdFaTab;ZHst;AGS

4120000001;LNO XY;BusGMBH;ZV XYZ;11;1;20241213;1415;52;3300;;365;

1;2,00;;43;2000;1800;9999;22075;2;1;154;20241213;;22122;

Beschreibung der einzelnen Felder der Verkaufsdatensätze im Detail:

1 IdentNr

Eine (z.B. fortlaufende) eindeutige Identifikationsnummer des Datensatzes, die vom Verkehrsunternehmen (hier also vom AN) während des gesamten Verkehrsservicevertrages (VSV) für das betroffene Bündel zu dem die Lieferung gehört (siehe Felder 2 bis 4) nur ein einziges Mal zu vergeben ist.

Zusammen mit den Feldern 2 bis 4 ergibt sich eine eindeutige Kennzeichnung des Datensatzes während des gesamten VSV sowohl bei regionalen als auch bei lokalen Lieferungen. Somit darf ein an den RMV überge- bener Datensatz in keiner Folgelieferung erneut übergeben werden. Zu Korrekturen und Stornos siehe dort. IDs müssen nicht fortlaufend sein. Es ist also zulässig, für Lieferungen Blöcke zu bilden und bspw. die ersten beiden Stellen der gelieferten IDs für das zweistellige Kalenderjahr oder die ersten vier Stellen gemäß JJMM für Jahr und Monat der Lieferung zu verwenden. Auch müssen nachfolgende Lieferungen nicht zwingend höhere IDs enthalten als zuvor gelieferte.

2 Abrechnungskennung

Bei einem regionalen Linienbündel bzw. einem regionalen Linienbündelteil ist dies das Kürzel des regionalen Linienbündels, bei einem lokalen Linienbündel bzw. einem lokalen Linienbündelteil ist dies das Kürzel der LNO. Bei Teilnetzen im SPNV ist dies das Kürzel des Teilnetzes. Die Angabe erfolgt gemäß Vorgabe des RMV. Der Inhalt wird dem Partner bekannt gegeben. Es handelt sich im lokalen Fall um die Institution, mit der der RMV den Verkehr abrechnet. In einer Verkaufsdatendatei dürfen nur Datensätze mit der gleichen Abrechnungskennung enthalten sein.

3 Unternehmen

Verkehrsunternehmen, in dessen Namen die Fahrkarte verkauft wurde, Kodierung gemäß Vorgabe des RMV. Falls die Fahrkarte durch einen Subunternehmer verkauft wurde, ist dennoch das beauftragte Verkehrsunter- nehmen anzugeben.

4 Lokales Linienbündel

Für lokale Linienbündel(teile): Kürzel des lokalen Linienbündels. Kodierung gemäß Vorgabe des RMV. Für regionale Linienbündel(teile) bzw. Teilnetze im SPNV bleibt das Feld leer (Ausnahme: virtuelles Bündel)!

5 Verkaufstechnik

Identifikation der genutzten Verkaufstechnik gemäß einer tabellarischen Vorgabe des RMV.

6 Anzahl

Verkaufte Stückzahl von Fahrkarten. Bislang waren nur ganzzahlige Werte zulässig. Das führt dazu, dass bei Teilrückgaben die Stückzahl * Preis nicht dem tatsächlich abgerechneten Wert entspricht. Der RMV wird

250828-E Anlage_16_V4_2_45_003.docx S. 60 / 88

[Seite 61]

daher umstellen auf eine Zahl mit maximal 6 Nachkommastellen, so dass man aus dem Betrag der Rückzah- lung bei Teilrückgaben centgenau den Bruchteil der Fahrkarte ermitteln kann.

Üblicherweise ist bei einzelner Abgabe von Fahrkarten die Anzahl 1, kann jedoch bei Abgabe gleichartiger Fahrkarten wie z. B. beim JobTicket deutlich größer sein. Hier sind auch Stornos bzw. Teilstornierungen als negative Zahl einzutragen. Zwischen dem Minuszeichen und der Zahl ist kein Leerzeichen.

Bislang galt bei Stornos bzw. Teilstornierungen einzelner Fahrkarten, bei denen die Zahl der Fahrkarten nicht bekannt ist, dass bei Teilstornierungen im Feld Anzahl die Zahl 0 einzugeben ist, bei Stornierungen die ne- gative Anzahl. Der RMV stellt zu einem späteren Zeitpunkt auf das Bruchteilsverfahren um. Der Lieferant muss also beide Verfahren beherrschen, damit nach Bekanntgabe des Umstellungszeitpunkts/-zeitraums diese Änderung erfolgen kann.

7 Wertstellungsdatum

Wertstellungsdatum des Verkaufs bzw. der Rücknahme oder der Stornierung der Fahrkarte. Bei Fahrkarten ohne Abonnement entspricht dieses Datum dem Datum des Verkaufs bzw. dem Datum der Rücknahme oder der Stornierung der Fahrkarte. Bei Abonnements (wie bspw. JaKa 12x Abbuchung) entspricht das Wertstel- lungsdatum in der Regel nicht dem Datum des Verkaufs bzw. der Rücknahme, sondern dem Datum der Wertstellung der nach dem eigentlichen Verkauf stattfindenden Abbuchungen des Fahrkartenteilbetrages.

8 Verkaufsuhrzeit

Uhrzeit der Wertstellung des Verkaufs bzw. der Rücknahme der Fahrkarte (auch bei Zeitkarten). Wie oben passend zur Entstehung der Forderung. Beim vHGS handelt es sich um die Uhrzeit der Wertstellung der Zahlung.

9 Preisstufe

Das Feld Preisstufe enthält die Preisstufe einer verkauften Fahrkarte. Sofern keine Preisstufe zuzuordnen ist, muss es mit der Zahl „0“ befüllt werden. Inhalt entspricht dem Feld „Preisstufe“ der Tabelle „preisstufe.csv“.

10 Sortenschlüssel

Der Sortenschlüssel ist eine bis zu sechsstellige Zahl und wird vom RMV wie folgt definiert:

Präzise Fahrkartenart gemäß Datei „sortenschluessel.csv“ in den Tarifdaten, die den Sortenschlüssel defi- niert. Hier ist das Feld „Sortenschluessel“ zu nutzen.

11 Universal

Ohne besondere Vereinbarung zwischen dem RMV und dem jeweiligen Partner bleibt das Feld leer.

Im Falle einer solchen Vereinbarung nimmt dieses Feld bei bestimmten Verkäufen „Key-Value Paare“ auf, die der RMV mit dem jeweiligen Verkäufer für spezifische Zwecke individuell vereinbart.

Dabei ist der zu vereinbarende KEY immer als zusammenhängender String in Großbuchstaben und Ziffern auszuführen, der von einem Doppelpunkt abgeschlossen wird. Unmittelbar daran schließt sich der jeweilige Wert (value) an. Zu den Inhalten führt der RMV eine getrennte Dokumentation, die ggf. anzufordern ist.

Bei mehreren Inhalten wird „#“ als Trennzeichen verwendet. Leerzeichen entfallen. Die Inhalte (d.h. die ein- zelnen „Key-Value Paare“) sind zwingend in alphabetischer Reihenfolge der KEYs darzustellen.

12 Gerätenummer

Die Gerätenummer erfüllt zwei Zwecke:

1. Die Identifizierung der Fehlerquelle bei falsch gemeldeten Daten.

2. Überprüfung der Rentabilität von Verkaufsgeräten.

Bei personalbedienten Verkaufsgeräten ist die Gerätenummer mit der Nummer des Fahrermoduls zu füllen. Falls es keine Fahrermodule gibt, sind die Gerätenummern zu liefern, die je Unternehmen eindeutig für das genutzte Verkaufsgerät sind. Bei Verkäufen an kundenbedienten Verkaufsgeräten ist die Gerätenummer die

250828-E Anlage_16_V4_2_45_003.docx S. 61 / 88

[Seite 62]

Nummer des Verkaufsgeräts. Diese Nummern müssen je Unternehmen eindeutig sein. Bei Verkäufen an einem PC-Arbeitsplatz ist pro Partner und PC-Arbeitsplatz eine eindeutige Nummer zu verwenden.

Zur Versorgung des RMV mit aktualisierten Basisdaten siehe auch „Referenzdaten“ weiter unten.

13 Zahlungsart

Basisangabe zur Zahlungsart gemäß einer vom RMV zur Verfügung gestellten Tabelle. Falls der Betrag mit mehr als einer Zahlungsart bezahlt wurde, ist der Code für „mehrere Zahlungsarten“ zu nutzen und die ein- zelnen Zahlungsarten sind mit den jeweiligen Beträgen als Key-Value-Paare im Feld 11 anzugeben. Zur exakt zu nutzenden Syntax ist die Feld11-Inhalte Liste anzufordern, dass die Key-Value-Paare für Feld 11 detailliert beschreibt.

14 Umsatz

Gesamtumsatz des Fahrkartenverkaufs gemäß RMV-Preisliste (Tarifdaten, Tabelle „preisliste.csv“, Feld „Fahrpreis“) beim Regelpreis, Kundenabgabepreis bei subventionierten Fahrkarten bzw. Preis gemäß ver- traglicher Regelung mit dem Kunden. Es ist immer der Gesamtumsatz anzugeben für alle Karten dieses einen Stornierungs- oder Verkaufsvorgangs.

Bei JobTickets wäre hier z.B. das Produkt aus Anzahl und Einzelpreis pro Monat und Mitarbeiter anzugeben.

Im Feld Umsatz ist auch dann der Geldwert der durch das Unternehmen für den Sortenschlüssel und ggf. die weiteren Differenzierungen verkauften Stückzahlen zu melden, wenn es sich um einen pauschalen Betrag handelt, für den keine Stückzahl vorliegt, wenn also das Feld Anzahl den Inhalt 0 hat.

Bei Jahreskarten, die im Abonnement vertrieben werden, ist der jeweils vom Kunden gezahlte (abgebuchte) Umsatz einzutragen.

Stornos und Teilstornierungen einzelner Fahrkarten sind mit einem negativen Wert einzutragen. Zwischen dem Minuszeichen und der Zahl ist kein Leerzeichen.

Das Feld ist immer mit zwei Nachkommastellen zu liefern, auch wenn diese auf 0 oder 00 enden.

15 Subvention

Bei subventionierten Preisen steht hier der Subventionsbetrag, der den Tarifdaten (Tabelle „preisliste.csv“, Feld „Subvention“) zu entnehmen ist. Dieser ist als positiver Wert zu liefern. Es gelten analog die Bemerkun- gen für Preis.

Bei einem Verkauf gemäß Regelpreis bzw. speziellem Vertrag mit dem Kunden (JobTicket, SemesterTicket, o.a.) ist der Inhalt 0,00.

Das Feld ist immer mit zwei Nachkommastellen zu liefern, auch wenn diese auf 0 oder 00 enden.

16 Tarifversion

Gemäß der beim Verkauf eingesetzten Tarifdaten. Anzugeben ist die Zeichenfolge im ersten Feld („ID_Version“) der Datei „version.csv“.

17 Von

Das Feld „Von“ enthält den Startort (also das Tarifgebiet) des verkauften Fahrausweises wie in der Datei tarifgebiet.csv, Feld „TZ_Code“ dargestellt.

Falls die Kundeneingaben (bei Automatenverkauf) bzw. die Kundenangaben (bei Verkauf durch Personal) von der verkauften Fahrkarte abweicht, ist diese Anfrage zu liefern, nicht die Angaben für die verkaufte Fahr- karte. Wenn der Kunde mit Haltestelle (z. B. beim Handy) anfragt ist das zugehörige Tarifgebiet zu liefern. Bei Verkauf von Einzel- oder Tageskarten über einen Automaten, Busdrucker oder mittels Fahrplan ist also das Startgebiet gemäß der Eingabe des Kunden oder Busfahrers zu liefern.

Undefinierte Startorte führen dazu, dass das Feld leer bleibt.

Für Kurzstrecken ist der Hinweis unter „3 a)l)“ (klein „L“) zu beachten.

250828-E Anlage_16_V4_2_45_003.docx S. 62 / 88

[Seite 63]

18 Nach

Das Feld „Nach“ enthält den Zielort (also das Tarifgebiet) des verkauften Fahrausweises wie in der Datei tarifgebiet.csv, Feld „TZ_Code“ dargestellt.

Falls die Kundeneingaben (bei Automatenverkauf) bzw. die Kundenangaben (bei Verkauf durch Personal) von der verkauften Fahrkarte abweicht, ist diese Anfrage zu liefern, nicht die Angaben für die verkaufte Fahr- karte. Wenn der Kunde mit Haltestelle (z. B. beim Handy) anfragt ist das zugehörige Tarifgebiet zu liefern. Bei Verkauf von Einzel- oder Tageskarten über einen Automaten, Busdrucker oder mittels Fahrplan ist also das Zieltarifgebiet gemäß der Eingabe des Kunden oder Busfahrers zu liefern.

Undefinierte Zielorte führen dazu, dass das Feld leer bleibt.

Für Kurzstrecken ist der Hinweis unter „3 a)l)“ (klein „L“) zu beachten.

Hinweis zu „Von“ und „Nach“:

In Abgrenzung zu den Hinweisen in der Tarifdatenspezifikation (Abschnitt 1.6: „Tarifgebiete und Tarifmatrix, Hinweise zu Speicherung und Zugriff“), in der besonderer Wert darauf gelegt wird festzuhalten, dass IN DEN TARIFDATEN (in der Tabelle „tarifmatrix“) der referenzierte Wert des TZ_Code für NACH niemals kleiner ist als der referenzierte Wert des TZ_Code für VON (Stichwort: „Halbmatrix“), ist hingegen bei der Lieferung der Verkaufsdaten darauf zu achten, dass die konkrete Kundenanfrage geliefert wird und NICHT die Werte für VON und NACH (auch nicht in der umgedrehten, aufsteigenden Reihenfolge) die die Tarifmatrix bspw. die angefragte Schnittstelle liefert. D.h. konkret: In den Verkaufsdaten können sehr wohl Datensätze enthalten sein, bei denen das VON größer ist als das NACH, sofern dies die Kundenanfrage widerspiegelt.

Bei HandyTicket-Verkäufen ist die Tarifgebietsnummer einzutragen, die sich aufgrund der Anfrage des Kun- den in der Fahrplanauskunft ergibt.

Nachfolgend ein Beispiel mit einer Abweichung zwischen dem Tarifgebiet der Kundenanfrage und dem Tarif- gebiet im verkauften Ticket:

Kunde fragt in der App nach dem Weg für die Haltestelle in Tarifgebiet 1501 nach 2501, für die keine Tarifrelation existiert (Kundenabfrage). Allerdings liefert das System nach definierter Preisbildungslo- gik in der Datenspezifikation (Abschneideregel) die Tarifrelation 1500 nach 2500 über 0 zur PS 68. Diese wird auf der Fahrkarte gedruckt und verkauft. Einzutragen sind dann von 1501 nach 2501 über 0 PS 68.

Für Kurzstrecken ist der Hinweis unter „3 a)l)“ (klein „L“) zu beachten.

19 Ueber

Das Feld „Ueber“ enthält das für eine Verbindung charakteristische Über-Tarifgebiet des verkauften Fahraus- weises gemäß RMV-Tarifmatrix (Tarifdaten), wie in der Datei tarifgebiet.csv, Feld „TZ_Code“, dargestellt. Es wird ausdrücklich darauf hingewiesen, dass es Tarifrelationen gibt, die für unterschiedliche Sorten bei glei- chen Start- und Ziel-TGs unterschiedliche „Ueber“ aufweisen.

Es sollen die Angaben für die verkaufte Fahrkarte geliefert werden. Anders als beim VON und NACH ist beim UEBER NICHT die Kundenanfrage, sondern der Inhalt der verkauften Fahrkarte zu liefern! Undefinierte Über- Tarifgebiete führen dazu, dass das Feld leer bleibt.

Für Kurzstrecken ist der Hinweis unter „3 a)l)“ (klein „L“) zu beachten.

20 Starthaltestelle

Dieses Feld bezeichnet die Haltestelle, an der die Fahrkarte verkauft wird.

Zur Kennzeichnung der Haltestellen sind IDs zu verwenden, die in der Tabelle „haltestelle.csv“ der Tarifdaten durch den RMV geliefert werden. Diese Tabelle enthält in Feld 2 die gewohnte max. 6-stellige nummerische RMV-Haltestellen Nummer „RMV_ID_Hst_Nr“ und in Feld 11 die bis zu 40-stellige, alphanummerische glo- bale, deutschlandweit eindeutige Haltestellen-ID „DHID“ (siehe Tarifdaten Spezifikation).

250828-E Anlage_16_V4_2_45_003.docx S. 63 / 88

[Seite 64]

Bevorzugt zu liefern ist die DHID, ansonsten die RMV-Haltestellennummer. Eine Lieferung bis zur Haltestel- lenebene ist gewünscht.

Feld 20 der Verkaufsdaten darf nur für Fahrkarten gefüllt werden, deren Verkaufsort eindeutig einer Halte- stelle zugeordnet werden kann.

Falls die Fahrkarte nicht an einer Haltestelle verkauft wird, ist zwingend das Feld AGS (Feld 27) zu füllen.

Bei Verkäufen mittels einer Fahrplanauskunft ist die Starthaltestelle der Kundenanfrage zu nutzen.

Wir begrüßen es ausdrücklich, wenn beide Felder (20 und 27) gefüllt werden, wenn dies inhaltlich möglich ist, wenn z. B. eine Fahrkarte eindeutig einer Haltestelle zuzuordnen ist.

21 Linie

Linie gemäß der öffentlichen Liniennummer für die erste Teilfahrt. Die Linienbezeichnung ist dem veröffent- lichten Fahrplan zu entnehmen. (diese kann auch alphanumerische Inhalte haben wie bspw. „107A“).

Diese Angabe ist in der Regel nur für Einzelkarten und Tageskarten verfügbar, wenn sie im Verkehrsmittel oder über eine Fahrplanauskunft verkauft werden. In diesen Fällen ist zwingend die Linie anzugeben.

Erfolgt die Lieferung nicht nach Linien differenziert, ist der Wert 0 zu verwenden.

Wenn Sie die DFID liefern – siehe Feld 23 – ist in Feld 21 der Wert 0 zu verwenden.

HINWEIS für die Zukunft: Perspektivisch wird dieses Feld für zukünftige, andere Anforderungen Verwen- dung finden. Beachten Sie bereits jetzt die Erweiterung der Feldlänge (siehe Tabelle 2) und planen sie die Anpassung in Ihren Systemen frühestmöglich ein.

22 Richtung

Das Feld wird mit dem Wert 1 gefüllt, wenn die Richtung mit der ersten schriftlichen Beschreibung der Linie im Fahrplanbuch übereinstimmt. Fährt das Transportmittel in der Richtung, die der ersten schriftlichen Be- schreibung entgegengesetzt steht, ist der Wert 2 im Feld einzustellen. Wenn keine sinnvolle Richtungsangabe möglich ist (z. B. bei Schleifenfahrten), kann entweder der Wert 3 eingestellt werden oder der Wert, der sonst für diese Fahrt zur Anwendung kommt. Falls die Fahrtnummer geliefert wird, ist die Angabe der Richtung entbehrlich – das Feld kann in diesem Fall leer bleiben. Wenn dennoch ein Inhalt geliefert wird, muss er den o. g. Richtlinien entsprechen.

HINWEIS für die Zukunft: Perspektivisch wird dieses Feld für zukünftige, andere Anforderungen Verwen- dung finden. Beachten Sie hierzu die Hinweise zum Feld 23.

23 Fahrtnummer

Im Feld Fahrtnummer ist, sofern verfügbar, grundsätzlich die DFID zu liefern. Werden die Verkaufsdaten von einem elektronischen System erzeugt, das Zugriff auf die Online-Fahrplandaten des RMV besitzt so ist die über die Online Schnittstelle zum Verkaufszeitpunkt erhältliche, dem ersten Fahrtabschnitt des verkauften Tickets zugeordnete DFID (siehe Glossar) zu liefern. Wenn diese nicht verfügbar ist, soll stattdessen die DLID/DTID (siehe Glossar) geliefert werden. Wenn auch diese Information nicht verfügbar ist, ist wie bisher die öffentliche (bevorzugt) oder unternehmensinterne Fahrtnummer zu liefern.

Wenn Sie bei Altsystemen die DFID aufgrund der Feldlänge nicht liefern können, ist wie bisher die öffentliche (bevorzugt) oder unternehmensinterne Fahrtnummer zu liefern. Die Fahrtnummer ist die öffentliche oder be- triebsinterne Nummer der einzelnen Fahrt, also einer Haltestellenfolge zu einem bestimmten Zeitpunkt. Wenn der Verkauf einer Fahrkarte einer bestimmten Fahrt zugeordnet werden kann, ist dieses Feld zu liefern.

24 Gueltig_ab

Datum des ersten Gültigkeitstages.

250828-E Anlage_16_V4_2_45_003.docx S. 64 / 88

[Seite 65]

25 Kundenfahrt

Dieses Feld wird gefüllt, wenn die einzelnen Fahrtabschnitte einer Kundenfahrt bekannt (bei Erfassung, z.B. Be-In) oder höchst wahrscheinlich sind (Kunde kauft mittels Fahrplan HandyTicket). Das Feld ist auch dann zu füllen, wenn ein Kunde eine Tageskarte als HandyTicket mittels Fahrplanauskunft kauft. In diesem Fall wird angenommen, dass die beauskunftete Fahrt die erste des Tages mit dieser Tageskarte ist.

Dieses Feld findet immer Verwendung als Teil der Referenz zur „Kundenfahrttabelle“ – siehe Kundenfahrt.

Wenn die Voraussetzung nicht erfüllt ist bleibt das Feld leer (keine „0“). Wenn dieses Feld befüllt werden kann, dann ist zusätzlich auch die Kundenfahrttabelle (23-FDM) zu liefern.

Hinweis: Dieses Feld ist nicht mit den Fahrten bzw. der Fahrtnummer in Feld 23 zu verwechseln! Dort handelt es sich um die Fahrtnummer des Verkehrsmittels des zugrundeliegenden Sollfahrplans.

Die „Kundenfahrttabelle“, auf die in Feld 25 referenziert wird, zeigt die einzelnen Abschnitte einer Kundenreise (also die Fahrt des Kunden einschließlich eventueller Umstiege). Momentan kann diese Tabelle sinnvoll nur bei Käufen über Handy, elektronische Tickets und vernetzte Verkaufs- und Abrechnungssysteme gefüllt wer- den, die den Fahrpreis basierend auf der ermittelten Fahrtroute berechnen. Stichwort: „Be-In / Be-Out“ und vergleichbare elektronische Systeme. Die hierbei teils abweichenden konkreten Befüllungen der Felder 2 bis 4 werden je System zwischen RMV und dem Betreiber / Partner abgestimmt – siehe hierzu auch Hinweise zu Tabelle 1.

26 Zielhaltestelle

Dieses Feld bezeichnet die Haltestelle, die der Kunde beim Verkauf im Verkehrsmittel als Ziel nennt bzw. die der Fahrgast sonst eindeutig, z.B. über eine Fahrplanauskunft, angibt. Das Feld ist daher nur für Kurzstre- cken, Einzelfahrkarten und Tageskarten zu füllen. Wenn das Verkaufsgerät die Daten liefern kann, ist dieses Feld zu füllen.

Hinsichtlich der zu verwendenden ID gelten sinngemäß die Erläuterungen zum Feld 20.

27 AGS (Amtlicher Gemeindeschlüssel)

Mit dem Amtlichen Gemeindeschlüssel (teilweise auch noch als GKZ: ‚Gemeindekennzahl‘ bekannt) wird eine Verkaufsstelle (z. B. Reisebüro, Mobilitätszentrale, sonstige Verkaufsstellen), die nicht an einer Haltestelle liegt, beschrieben.

Es ist die vom RMV mit den Tarifdaten bereitgestellte 11-stellige Schlüsselliste zu verwenden, die zur Refe- renzierung der Ortsteile über den 8-stelligen amtlichen Gemeindeschlüssel (der nur bis zur Gemeindeebene reicht) in der Detailtiefe hinausgeht. Auch für Gemeinden außerhalb Hessens ist die 11-stellige Schlüsselliste zu verwenden, die vom RMV den Partnern in den Tarifdaten zur Verfügung gestellt wird. Die AGS-Nummer ist durch ihre letzten 3 Ziffern (Ortsteil-AGS) dem Ortsteil der Haltestelle in der Datenmeldung zuzuordnen.

Grundsätzlich gilt: Wenn die Starthaltestelle einer Fahrkarte bekannt ist oder der Kartenerwerb an einer phy- sischen Vertriebsstelle erfolgt, ist die AGS zu liefern. Andernfalls bleibt das Feld leer.

Wenn dieses Feld leer bleibt, ist für den Jedermann-Tarif zwingend Feld 20 „Starthaltestelle“ zu füllen.

Für spezielle Fälle gilt:

 JobTicket, FirmenCard, … Firmenstandort = AGS  Semesterticket: Unistandort = AGS  SWKT: Schulstandort = AGS  Landesticket: Arbeitsort des Mitarbeiters = AGS  On-demand: AGS gemäß Liste vom RMV  DeutschlandTicket/HessenPass mobil, Hessenticket, Seniorenticket, CleverCard, Schülerticket mit Erstattung oder im freien Verkauf => AGS leer  Kombiticket: Veranstaltungsort = AGS

250828-E Anlage_16_V4_2_45_003.docx S. 65 / 88

[Seite 66]

Notfahrkarten

Für Notfahrkarten, d. h. Fahrkarten, die bei Ausfall eines elektronischen Verkaufsgerätes von Hand ausge- stellt werden, gilt:

Im Vergleich zu den oben geschilderten Angaben können einzelne Felder entfallen bzw. verändert dargestellt werden. Im Grundsatz gilt dabei, dass zwar Inhalte einzelner Felder wegfallen dürfen, dass aber niemals falsche Angaben gespeichert werden dürfen (z. B. statt des Wertstellungsdatums das Datum der nachträgli- chen Buchung). Eine vollständige Lieferung wird für den Fall erwartet, dass die Notfahrkarten direkt oder später in ein elektronisches Verkaufsgerät / elektronisches Speichersystem eingegeben werden.

Bei den entfallenden bzw. veränderbaren Feldern handelt es sich um:

 Verkaufstechnik (hier muss zwingend der Code für Notfahrkarten erscheinen, auch dann, wenn die Fahrkarten nachträglich in einem elektronischen Verkaufsgerät gebucht werden.)

 Verkaufsuhrzeit (Lieferung gewünscht, falls möglich)

 Universal (Lieferung gewünscht, falls möglich)

 Zahlungsart (Lieferung gewünscht, falls möglich)

 Von (Lieferung gewünscht, falls möglich)

 Nach (Lieferung gewünscht, falls möglich)

 Ueber (Lieferung gewünscht, falls möglich)

 Starthaltestelle (Lieferung gewünscht, falls möglich)

 Richtung (Lieferung gewünscht, falls möglich)

 Fahrtnummer (Lieferung gewünscht, falls möglich)

 Gueltig_ab (Lieferung gewünscht, falls möglich; in jedem Fall ist mindestens der Verkaufsmonat ein- zusetzen)

 Zielhaltestelle (Lieferung gewünscht, falls möglich)

 Amtlicher Gemeindeschlüssel (Lieferung gewünscht, falls möglich)

Alle anderen Felder sind wie oben dargestellt zu liefern.

Aggregierter Inhalt / Summendatensatz

Zusätzlich zu den einzelnen Verkaufsmeldungen empfiehlt der RMV zur eigenen Kontrolle der Verkaufsda- tenmeldung eine zusammengefasste Darstellung ihres Inhaltes mitzuliefern. Diese ist als gesonderter Daten- satz am Ende der Datei anzufügen. Die Nichtlieferung wird nicht beanstandet. Wenn der Summendatensatz enthalten ist, wird er auf die nachfolgenden Kriterien hin geprüft und bei Fehlern wird die Lieferung abgelehnt.

Der Summendatensatz ermöglicht eine zusätzliche Kontrolle der gelieferten Daten durch das liefernde Vor- system.

Der Summendatensatz muss zwingend der letzte Datensatz in der gelieferten Datei sein.

Dabei müssen folgende Felder ausgefüllt werden:

 IdentNr (Der Inhalt dieses Feldes ist die Gesamtzahl aller Datensätze dieser Lieferung, ohne den aggre- gierten Datensatz selbst)

 Abrechnungskennung

 Unternehmen

 Lokales Linienbündel (sofern zu liefern)

 Verkaufstechnik (fest auf "99" gesetzt, so dass dieser Datensatz identifiziert werden kann).

 Anzahl (Gesamtanzahl aller verkauften Fahrkarten abzüglich Stornos, s.u.)

 Umsatz (Summe des Umsatzes aller Fahrkarten unter Berücksichtigung der Stornos, s.u.)

250828-E Anlage_16_V4_2_45_003.docx S. 66 / 88

[Seite 67]

 Subvention (Summe aller Subventionierungen unter Berücksichtigung der Stornos, s.u.)

 Gueltig_ab (Der 1. des Monats für den die Meldung abgegeben wird – es ist nicht schädlich, wenn ein- zelne Fahrkarten früher verkauft wurden, weil z.B. ein Fahrermodul später ausgelesen wurde). Alle an- deren Felder dieses Datensatzes bleiben leer.

Hinweis zu den Spalten „Anzahl“, „Umsatz“ und „Subvention“: Bei der Summenbildung ist NICHT etwa Anzahl mal Preis zu berechnen. Der Summendatensatz enthält für jedes dieser drei Felder (der Spalten) die einfache Summe der Werte aller Einzeldatensätze nur der zugehörigen Spalte, unabhängig vom Inhalt der jeweiligen anderen Spalten. Der Wert im Feld Umsatz ist also nur der aggregierte Inhalt aller Datensätze aus dem Feld Umsatz. Das Gleiche gilt für Anzahl und Subvention.

Referenzdaten

Für Verkaufsgeräte im Bus und an der Haltestelle sind die Gerätenummern (Feld 12) dem RMV zum Datum des jeweiligen Beginns der Gültigkeit (d.h. stets auch dann, wenn sie sich ändern) als vollständige Liste im „.csv“-Format zu melden. Eine vom RMV nicht veränderbare pdf - Datei mit gleichem Inhalt darf beigefügt sein.

Für Handyticket und den TicketShop werden die Gerätenummern vom RMV vorgegeben.

Sofern für die Referenzdaten seitens des RMV Vorgaben vorliegen, sind diese zu übernehmen.

Folgende Formate sind bei der Referenzdatenlieferung einzuhalten:

Gerätenummer:

Für alle verwendeten oder ausrangierten Geräten je ein Datensatz in einer Lieferung mit 3 Feldern.

Feld 1: Gerätenummer (mit den IDs die in Feld 12 der Verkaufsdaten verwendet werden – siehe oben).

Feld 2: Das VU, das das Modul einsetzt (gleiches Kürzel wie in Feld 3 der Verkaufsdaten)

Feld 3: Datum ab dem das Gerät NICHT mehr verwendet wird (Abmeldung) im Format „JJJJMMTT“. Bei leerem Feld wird das Gerät angemeldet oder die Weiterverwendung im Folgezeitraum bestätigt.

3.6 Kundenfahrtdaten Der nachfolgende Abschnitt ist nur zu beachten für Betreiber von Systemen die mit einer besonderen Verein- barung zwischen dem RMV und dem jeweiligen Partner zur Lieferung von Fahrtdaten beauftragt sind. Dies ist verknüpft mit der Befüllung von Feld 25 der Verkaufsdaten. Wie bereits dort beschrieben, spielt der fol- gende Abschnitt (Fahrtdaten) im herkömmlichen Vertrieb bspw. an Automaten oder im Bus keine Rolle und kann daher ignoriert werden.

Es handelt sich dabei um Systeme die für die Preisbildung Informationen über den tatsächlich gefahrenen oder anzunehmenden Weg erfordern oder liefern können, wie dies seit Jahren im Rahmen des Handytickets der Fall ist. In Zukunft gilt diese Anforderung auch für Be-In/Be-Out, den Verkauf von Einzelkarten über Handy aus der Fahrplanauskunft heraus und einen denkbaren Verkauf von Einzelkarten aus der Internetauskunft oder vergleichbare Vorgänge.

Zwischen der 27-Felder-Matrix (Verkaufsdaten) und der nachfolgend definierten 23-Felder-Matrix (Fahrtda- ten) besteht in der Regel eine 1:n-Beziehung. Das bedeutet, dass einem Verkaufsdatensatz n Fahrtdaten- sätze entsprechen, die die einzelnen Teilfahrten beschreiben. Die Fahrtdaten sind jeweils parallel zu den Verkaufsdaten zu liefern. Sie müssen hinsichtlich Ihres Lieferumfangs inhaltlich konsistente Datensätze ent- halten, d. h. die zu einem Verkaufsdatensatz gehörenden Fahrtdatensätze müssen vollständig in der paralle- len Lieferung mit enthalten sein. Die Referenz zwischen den beiden Tabellen wird seitens der Verkaufsdaten über den Eintrag in Feld 25 und seitens der Kundenfahrtdaten über den Eintrag in Feld 1 und Feld 2 herge- stellt. Dabei ist der Eintrag in Feld 1 für alle (die Teilfahrten beschreibenden) Fahrtdatensätze, die logisch zu einem Verkaufsdatensatz gehören, identisch. Der Eintrag in Feld 2 geht für n Datensätze von 1 bis n. Können aus irgendeinem Grund bei einem eigentlich Fahrtdaten liefernden System zwar ein Verkaufsdatensatz aber

250828-E Anlage_16_V4_2_45_003.docx S. 67 / 88

[Seite 68]

keine zugehörigeren Fahrtdatensätze geliefert werden, dann ist in Feld 25 der Verkaufsdaten eine 0 einzu- tragen. Diese technische Regelung entbindet nicht von der Lieferpflicht sondern dient nur der Datenkonsis- tenz.

Sofern bei der Abbildung einer Kundenfahrt mehr als ein Verkaufsdatensatz entsteht (dies ist bspw. der Fall infolge eines, neben dem Hauptfahrschein, getrennt zu verkaufenden 1. Klasse Zuschlags oder eines AST Zuschlags), diese aber inhaltlich zu einem Fahrtvorgang gehören, ist in allen zu dieser Fahrt gehörenden Verkaufsdatensätzen (in der Regel maximal 2) in Feld 25 die gleiche Fahrkarten-ID einzutragen4. Für diese Zuschlagsarten entstehen keine eigenen, die Teilfahrten beschreibenden Fahrtdatensätze, sondern es wer- den bei den korrespondierenden Datensätzen des Hauptfahrscheins die Attribute der Felder 15 und 16 (und bei zukünftigen Anwendungen evt. Feld 17) gesetzt. Dies geschieht aber nur bei den betroffenen Teilfahrten.

Beispiel: Für eine Fahrt, die aus 3 Teilfahrten 1 bis 3 (d. h. 2 Umstiege) besteht, soll gelten:

1: BUS

2: TRAM

3: S-BAHN (infolge des Kundenprofils wird von 1. Klasse Nutzung ausgegangen)

Dann sind zwei Verkaufsdatensätze zu schreiben: Zunächst ein Verkaufsdatensatz für einen Einzelfahrschein für die Gesamtfahrt (bestehend aus den Teilfahrten 1 bis 3). Das Feld 25 erhalte bspw. eine ID ‚4711ABC‘ als Referenz auf die Fahrtdatensätze.

Sodann ist ein zweiter Verkaufsdatensatz zu schreiben für einen 1.Klasse Zuschlag für die 3. Teilfahrt. Hier wird in Feld 25 ebenfalls die ‚4711ABC‘ eingetragen.

Darüber hinaus gibt es für die drei Teilfahrten je einen Fahrtdatensatz zur Beschreibung der jeweiligen Teil- fahrt. Alle drei Datensätze erhalten in Feld 1 die gleiche FAHRKARTEN_ID ‚4711ABC‘. Der erste Datensatz erhält in Feld 2 die Teilfahrt-Nr. ‚1‘ für die erste Teilfahrt, Feld 15 erhält eine ‚0‘. Der zweite Datensatz erhält entsprechend in Feld 2 eine ‚2‘ und in Feld 15 eine ‚0‘. Der dritte Fahrtdatensatz enthält in Feld 2 eine ‚3‘, Feld 15 erhält wegen der hier nutzbaren 1. Klasse eine ‚1‘.

Hinweis: Es soll nicht etwa jeder einzelne Streckenabschnitt von jeder durchfahrenen Haltestelle zu jeder nächsten Haltestelle als eigener Datensatz geliefert werden, sondern für jede Teilfahrt ist von der Einstiegs- bis zur Ausstiegshaltestelle jeweils EIN zusammenfassender Datensatz zu liefern.

Im obigen Beispiel: Die nachfolgenden Buchstaben stehen für Haltestellen:

Der Kunde fährt in Teilfahrt 1 mit dem Bus von A über B und C nach D.

Er steigt in D in die Tram um und setzt seine Fahrt fort von D über E nach F.

Nach einem kleinen Fußweg von F nach G (der in den Daten wegbleibt) steigt er schließlich in G ein und vollendet die Fahrt mit der S-Bahn von G über H und J nach K.

Dann sind drei Datensätze zu liefern (nachfolgend verkürzt, symbolisch dargestellt)

Teilfahrt 1: START_HST: A; ZIEL_HST: D; BUS

Teilfahrt 2: START_HST: D; ZIEL_HST: F; TRAM

Teilfahrt 3: START_HST: G; ZIEL_HST: K; S-BAHN

Hinsichtlich der Felder, die für die Aufnahme von IST Daten vorgesehen sind, ist folgendes Verfahren anzu- wenden: Sofern bei der Zusammenstellung der Datensätze (wie dies bspw. beim MATCHING bei Touch & Travel zwischen dem Bewegungsprofil der „Handydaten“ und der Fahrtdatenlage der Linien erfolgte) für die Teilfahrten Echtzeitdaten zur Anwendung kamen und demzufolge im Quellsystem vorliegen, sind die zur An- wendung gekommenen Echtzeitdaten in den vorgesehenen Feldern mitzuspeichern. Falls keine Echtzeitda- ten sondern nur Prognosedaten vorliegen sind ersatzweise diese sinngemäß zu verwenden [also gemäß der Datenlage die im Moment der Zuordnung vorlag und zur Auswertung kam]. IST Datenfelder sind auch dann

4 Dann besteht zwar keine strenge 1:n Beziehung mehr – über den Sortenschlüssel ist aber der Verkaufsdatensatz zu identifizieren der als Hauptfahrschein gilt und an dem die 1:n Beziehung festgemacht wird.

250828-E Anlage_16_V4_2_45_003.docx S. 68 / 88

[Seite 69]

zu füllen wenn IST und SOLL Informationen identisch sind (d.h. bei Pünktlichkeit der Fahrt). Nur im Falle, dass weder Echtzeitfahrtdaten noch Prognosedaten vorliegen, sind die IST Felder leer zu lassen.

Diese Regelung kann im Einzelfall dazu führen (ungenaue IST Dateninfos / ungenaue Prognosen), dass (im obigen Beispiel) die START_UHRZEIT_IST der Teilfahrt 2 VOR der ZIEL_UHRZEIT_IST der Teilfahrt 1 liegt, was zunächst unmöglich erscheint. Dies wird, der Datenlage der Quellsysteme Rechnung tragend, in Kauf genommen. Diese Verschiebung kann gleichermaßen, aufgrund entsprechender IST Datenlage auch bei den SOLL Daten auftreten (wenn die Verspätung der Teilfahrt 2 so stark ist, dass sie tatsächlich NACH der Teil- fahrt 2 beginnt, obwohl im SOLL vor Teilfahrt 1 liegend).

Die Daten sind parallel und passend zu den Verkaufsdaten, zu liefern. D.h. der Inhalt der Fahrtdatenlieferung enthält die Details zu den Verkäufen in der zugehörigen Verkaufsdatenlieferung.

Der Dateiname spiegelt die Zugehörigkeit der Teilfahrt Datenlieferung zur entsprechenden Verkaufsdatenlie- ferung wieder. (zu deren Benennung siehe dort).

Sinngemäß ist die Teilfahrtdatenlieferung wie folgt zu benennen (LDK-ABC steht hier symbolisch für den mit dem RMV vereinbarten Präfix des jeweiligen Lieferanten):

LDK-ABC_JJJJ-MM_[Freitext_]Teilfahrt.csv

Für die zur Zeit der Dokumenterstellung bereits bekannten, RMV-seitig zentral geführten elektronischen Sys- teme ist nachfolgend der Dateiname davon abweichend definiert. Für ggf. weitere, zukünftige Systeme wird der RMV sinngemäß Vorgaben mit dem betroffenen Partner vereinbaren.

HandyTicket:

HandyTicket_JJJJ-MM_Teilfahrt_[Freitext].csv

IN/OUT:

INOUT_JJJJ-MM_Teilfahrt_[Freitext].csv

DB Navigator:

DB Navigator_JJJJ-MM_Teilfahrt_[Freitext].csv

Die eckige Klammer ist NICHT Teil des Dateinamens:

[Freitext] ist optional und nur zu verwenden, wenn er zur notwendigen Unterscheidung von Lieferungen bei- trägt, bspw. bei Korrekturlieferungen als Zähler wie bspw. „02“. Hierbei ist die gleiche Freitext Ergänzung zu wählen wie bei einer als Korrektur gelieferten 27-Felder Lieferung um die Zusammengehörigkeit der Korrek- turlieferungen erkennbar zu machen.

Es ist zu beachten, dass beim Dateinamen der zentralen Systeme bei Weglassung des Freitextes der Dateiname vor dem Punkt als letztes Zeichen einen Unterstrich enthält.

Beispiel: Für eine Lieferung der DB Regio AG mit allen Datensätzen des Februar 2023

DBREGIO_2023-02_Teilfahrt.csv

Es sind in jedem Datensatz 23 Felder (also 22 Semikola) zu liefern.

Hinweise zu IN/OUT

Im Rahmen des Projektes IN/OUT werden Tickets im Nachgang zum Erwerb im Kundensinn durch Zusam- menfassung optimiert. Dabei gilt, dass alle Teilfahrten in die 23-FDM aufgenommen werden müssen. Irgend- welche zwischendrin gebildeten Einzel- oder Tageskarten, die letztlich nicht mit dem Kunden abgerechnet werden, erscheinen weder in der 27- noch in der 23-FDM. Die Teilfahrten der 23-FDM müssen den Fahrkarten der 27-FDM zugeordnet werden, die dem Kunden in Rechnung gestellt werden.

250828-E Anlage_16_V4_2_45_003.docx S. 69 / 88

[Seite 70]

Tabelle 3: Datenformat Meldung der Kundenfahrtdaten zu den Verkaufsdaten (23-Felder-Matrix)

250828-E Anlage_16_V4_2_45_003.docx S. 70 / 88

[Seite 71]

Beschreibung der einzelnen Felder der Kundenfahrtdatensätze im Detail:

1 KUNDENFAHRT_ID

Die alphanumerische ID, die im Feld 25 (Kundenfahrt) der Verkaufsdatenmeldung eingetragen ist. Damit werden alle Fahrten zu einer Fahrkarte identifizierbar. Eine Fahrt ist in diesem Sinn die Anwesenheit eines Kunden (inkl. berechtigter Begleiter) in einem Verkehrsmittel mit gleicher Fahrplanfahrtnummer (Feld 14) – ohne Umsteigen. Wenn die Fahrplanfahrtnummer während der Anwesenheit des Fahrgastes wechselt, handelt es sich um zwei Fahrten = zwei Datensätze. Neben den Zeichen 0..9 sind nur die Zeichen A..Z (nur groß) zugelassen – keine Sonderzeichen oder Umlaute. Zur Eindeutigkeit siehe Hinweise zu Feld 21.

2 TEILFAHRT_NR

Lückenlose Nummerierung der einzelnen Fahrten zu einer Fahrkarte, beginnend bei 1 in zeitlich aufstei- gender Reihenfolge gemäß der Fahrtabfolge.

3 STARTHALTESTELLE

Diejenige Haltestelle, an der der Kunde das Verkehrsmittel betritt bzw. die er bei einem Verkauf über Fahr- plan als Starthaltestelle gewählt hat. Für den Fall, dass die Fahrplanfahrtnummer während der Fahrt wech- selt, handelt es sich für den zweiten Datensatz um die Haltestelle, bei der die Fahrplanfahrtnummer ge- wechselt hat. Bei Verkauf über einen Fahrplan ist die Starthaltestelle der Auskunft einzutragen. Es ist die DHID zu verwenden.

4 START_DATUM_SOLL

Das Datum5, an dem die Fahrt lt. Fahrplan beginnen soll. Wird in der Regel mit dem „Start-Datum Ist“ identisch sein – Unterschiede sind nur bei Fahrten kurz vor bzw. kurz nach Mitternacht zu erwarten.

5 START_UHRZEIT_SOLL

Die Uhrzeit6, zu der die Fahrt lt. Fahrplan beginnen soll.

6 START_DATUM_IST

Das Datum7, an dem die Fahrt lt. der Information über den Ist-Fahrplan tatsächlich begonnen hat. Wenn diese Information für die Preisberechnung nicht vorliegt, bleibt das Feld leer (kein Inhalt, NULL).

7 START_UHRZEIT_IST

Die Uhrzeit8, zu der die Fahrt lt. der Information über den Ist-Fahrplan tatsächlich begonnen hat. Wenn diese Information für die Preisberechnung nicht vorliegt, bleibt das Feld leer (kein Inhalt, NULL)

8 ZIELHALTESTELLE

Diejenige Haltestelle, an der der Kunde das Verkehrsmittel verlässt bzw. die letzte Haltestelle bei einem Verkauf über Fahrplan. Für den Fall, dass die Fahrplanfahrtnummer (Feld 14) während der Fahrt wechselt, handelt es sich für den ersten Datensatz um die Haltestelle, bei der die Fahrplanfahrtnummer gewechselt hat. Bei Verkauf über einen Fahrplan ist die Zielhaltestelle gemäß Auskunft einzutragen. Es ist die DHID zu verwenden.

9 ZIEL_DATUM_SOLL

Das Datum9, an dem die Fahrt lt. Fahrplan enden soll. Wird in der Regel mit dem Start-Datum Ist identisch sein – Unterschiede sind nur bei Fahrten kurz vor bzw. kurz nach Mitternacht zu erwarten.

5 Bei den Datum- und Uhrzeit Angaben (Felder 4 bis 7 und 9 bis 12) ist die gesetzliche, örtlich geltende kalendarische Angabe zu verwenden. Es gilt nicht die Zählung nach Betriebstag. Abweichungen sind mit dem AG abzustimmen. 6 Siehe Fußnote 6 7 Siehe Fußnote 6 8 Siehe Fußnote 6 9 Siehe Fußnote 6 250828-E Anlage_16_V4_2_45_003.docx S. 71 / 88

[Seite 72]

10 ZIEL_UHRZEIT_SOLL

Die Uhrzeit10, zu der die Fahrt lt. Fahrplan enden soll.

11 ZIEL_DATUM_IST

Das Datum11, an dem die Fahrt lt. der Information über den Ist-Fahrplan tatsächlich beendet war. Wenn diese Information für die Preisberechnung nicht vorliegt, bleibt das Feld leer (kein Inhalt, NULL).

12 ZIEL_UHRZEIT_IST

Die Uhrzeit12, zu der die Fahrt lt. der Information über den Ist-Fahrplan tatsächlich beendet war. Wenn diese Information für die Wegeermittlung bzw. Preisberechnung nicht vorliegt, bleibt das Feld leer (kein Inhalt, NULL).

13 UNIVERSAL_KDF

Feld 13 ist (siehe Hinweise zu Feld 14) für zukünftige Verwendung frei geworden und wird entsprechend in „UNIVERSAL_KDF“ umbenannt. Inhalte können vom RMV für einzelne Lieferanten und Systeme bilate- ral vorgegeben werden. (KDF steht für „Kundenfahrt“)

14 DLID_DTID_DFID (Um der sprachlichen Verständlichkeit willen im Dokument „Fahrplanfahrtnummer“ genannt)

Hinweis: Die Fahrplanfahrtnummer (DLID_DTID_DFID) ist nicht zu verwechseln mit der individuellen Fahrt (Feld 1) oder Teilfahrt (Feld 2) des Kunden die im gesamten Datensatz repräsentiert wird, also einer Hal- testellenfolge zu einem bestimmten Zeitpunkt.

Als Standard ist die DFID (deutschlandweit eindeutige Fahrtbezeichnung) gemäß VDV Schrift zu verwen- den.

Abweichend davon kann der RMV eine andere zu verwendende Bezeichnung, bspw. die Fahrplanfahrt- nummer als betriebsinterne Nummer der einzelnen Fahrplanfahrt also einer Haltestellenfolge zu einem bestimmten Zeitpunkt (z. B. die Zugnummer im SPNV, die Busfahrtnummer im BPNV) vorgeben.

Da die 23-FDM sinnvoll nur in Zusammenhang mit einem elektronischen Online-System erzeugt werden kann das Zugriff auf die Online-Fahrplandaten besitzt, ist die über die Online Schnittstelle zum Verkaufs- zeitpunkt erhältliche, dem JEWEILIGEN Fahrtabschnitt (pro Datensatz) des verkauften Tickets zugeord- nete DFID (siehe Glossar) zu liefern, sofern diese bereits in den Fahrplandaten verfügbar ist.

Wo technisch realisierbar ist bei Abweichungen bspw. infolge Ersatzverkehren die dem realen Fahrweg möglichst nahekommende DFID auf Basis von ITCS oder Datendrehscheiben oder anderen verfügbaren Datenquellen (BE IN / BE OUT Systeme und dergleichen) zu liefern.

Wo keine DFID geliefert werden kann ist als Rückfallebene nur die DLID/DTID (siehe Glossar) zu liefern.

Da Letztere als Teilstring in der DFID enthalten ist, ist die Lieferung der Linie in Feld 13 somit überflüssig geworden.

Wenn diese Information für die Wegeermittlung bzw. Preisberechnung nicht vorliegt, bleibt das Feld leer (kein Inhalt, NULL).

Beachten Sie die zur Aufnahme der DxID Inhalte notwendige Erweiterung der Feldlänge (siehe Tabelle)

15 FIRST_CLASS

Wenn die Fahrtberechtigung zu einer Nutzung der ersten Klasse berechtigte, oder, falls feststellbar (bspw. BE IN / BE OUT, HandyTicket-Verkäufe) in der 1. Klasse durchgeführt wurde, ist eine 1 einzutragen – sonst eine 0.

10 Siehe Fußnote 6 11 Siehe Fußnote 6 12 Siehe Fußnote 6 250828-E Anlage_16_V4_2_45_003.docx S. 72 / 88

[Seite 73]

16 AST

Wenn die Fahrt in einem AST, ALT oder sonstigen on-demand Fahrzeug des Bedarfsverkehrs unternom- men wurde, ist eine 1 einzutragen – sonst eine 0.

17 SERVICE

Für dieses Feld werden Kürzel gemäß einer Tabelle des RMV definiert werden. Diese sollen besondere kostenpflichtige oder speziell abzurechnende Angebote, wie z. B. den AIRliner, kennzeichnen. Es ist jedoch auch möglich, hier Fahrten, die wg. massiver Verkehrsstörungen nicht abgerechnet werden sollen, ent- sprechend zu kennzeichnen. Das Feld ist noch nicht im Einsatz und bleibt leer.

18 TARIFGEWICHTUNG

Leer.

19 START_AGS

Es ist die AGS-Nummer entsprechend dem Ort der Starthaltestelle der Teilfahrt aus der RMV-AGS-Liste zu nehmen.

20 ZIEL_AGS

Es ist die AGS-Nummer entsprechend dem Ort der Zielhaltestelle der Teilfahrt aus der RMV-AGS-Liste zu nehmen.

21 REF_2_TICKET

Aus Gründen der Abwärtskompatibilität wird es über den Inhalt dieses Feldes ermöglicht eine 1:m Referenz zwischen den o.g. Verkaufsdaten (27-Felder) und den Kundenfahrtdaten (23-Felder) herzustellen, auch bei verteilter Datenspeicherung.

Als Inhalt dieses Feldes ist dazu für jeden Datensatz ein String, wie folgt zusammengesetzt, zu speichern:

Aus dem zugehörigen Verkaufsdatensatz (der 27-Felder)

Feld 1: max. 12 Zeichen, gefolgt vom Trennzeichen „%“

Feld 2: max. 7 Zeichen, gefolgt vom Trennzeichen „%“

Feld 3: max. 7 Zeichen, gefolgt vom Trennzeichen „%“

Feld 4: max. 7 Zeichen, gefolgt vom Trennzeichen „%“

Feld 7: Immer = 8 Zeichen

Insgesamt max. 45 Zeichen. Sind die Inhalte der einzelnen Felder kürzer verkürzt sich der zu speichernde String entsprechend. Falls es innerhalb der Felder der Verkaufsdatentabelle Leerzeichen geben sollte sind diese zu übernehmen (bspw. bei einer Kennung „LNO WI“ ist der String (aus Feld 2) sechs Zeichen lang). Die Trennzeichen sind auf jeden Fall zu speichern, selbst wenn es zwischen 2 Trennzeichen keinen Inhalt gäbe.

Auf diese Weise ist über die Felder 1,2,3,4,7 und 25 der Verkaufsdaten eine 1:m Referenz zu jedem Da- tensatz der zugehörigen Kundenfahrtdaten über die Felder 21 und 1 ergänzt um Feld 2 auch über Ver- kehrsserviceverträge, Vertragswechsel etc. hinweg möglich.

Die Felder 22 und 23: RESERVE_2 und RESERVE_3 bleiben zunächst leer.

250828-E Anlage_16_V4_2_45_003.docx S. 73 / 88

[Seite 74]

5. Anhang

5.1 Tabellenübersicht Tabellenübersicht der Datenstruktur: (Der Anhang „.csv” am Dateinamen ist nachfol- gend aus Übersichtsgründen im Allgemeinen weggelassen)

250828-E Anlage_16_V4_2_45_003.docx S. 74 / 88

[Seite 75]

ID_Verkehrsmittelgattung

5.2 Maschineller Datenstrukturabgleich - Inhalt der Tabelle „schema.ini“ Die nachfolgend in voller Länge abgebildete schema.ini kann (copy/paste) aus die- sem Dokument kopiert werden und zur Qualitätssicherung eingesetzt werden. Sie wiederholt (siehe Abschnitt 2.57) die Strukturen aller beteiligten Tabellen und stellt somit eine maschinell auswertbare Basis bspw. für implementierte Import-Daten- strukturen zur Verfügung. Die Datei wird daneben in jedem ausgelieferten Export mit- geliefert und kann somit auf Identität zu der der Implementierung zugrundeliegenden Spezifikationsversion herangezogen werden. Abweichungen können damit in der Im- portroutine bereits auf struktureller Ebene abgefangen werden. Da die Tabelle nur zu „copy/paste“ Zwecken enthalten ist wurde zur Platzersparnis eine sehr kleine Schrift gewählt.

[anschlusspunkt.csv] Col8=FAHRKARTENTEXT_60 Char Width 60 Col4=ZEIT Integer ColNameHeader=False Col9=FAHRKARTENTEXT_255 Char Width 255 Col5=ENTFERNUNG Integer Format=Delimited(;) Col10=ID_ZUSATZTEXT_1 Integer [gemeinde.csv] CharacterSet=ANSI Col11=ID_ZUSATZTEXT_2 Integer ColNameHeader=False Col1=ID_ANSCHLUSSPUNKT Integer Col12=ID_UEBERTRAGBARKEIT Integer Format=Delimited(;) Col2=ID_TARIFGEBIET_FAHRT Integer Col13=ID_ZAHLUNGSMODUS Integer CharacterSet=ANSI Col3=ID_FREIGABE_ZEITKARTE Integer [fahrkartentext_zusatz.csv] Col1=ID_GEMEINDE Integer Col4=ID_TARIFGEBIET_ANSCHLUSS Integer ColNameHeader=False Col2=ID_LANDKREIS Integer Col5=NAME Char Width 35 Format=Delimited(;) Col3=ID_CALC_TARIFGEBIET Integer [anzeige.csv] CharacterSet=ANSI Col4=ID_GEMEINDE_AGS Char Width 3 ColNameHeader=False Col1=ID_FAHRKARTENTEXT_ZUSATZ Integer Col5=GEMEINDE_NAME Char Width 25 Format=Delimited(;) Col2=BESCHREIBUNG Char Width 50 Col6=ANZ_EINWOHNER Integer CharacterSet=ANSI Col3=ABKUERZUNG_1 Char Width 20 [haltestelle.csv] Col1=ID_ANZEIGE Integer Col4=ABKUERZUNG_2 Char Width 10 ColNameHeader=False Col2=ID_ANZEIGETEXTE Integer Col5=INFO_ERFORDERNIS Integer Format=Delimited(;) Col3=WERTIGKEIT Integer [fahrtrelation.csv] CharacterSet=ANSI Col4=ID_TARIFGEBIET Integer ColNameHeader=False Col1=ID_HST Integer Col5=ID_HST_ZIEL Integer Format=Delimited(;) Col2=RMV_HALTESTELLENNUMMER Integer Col6=ID_GEMEINDE Integer CharacterSet=ANSI Col3=ID_ORTSTEIL Integer Col7=ID_ORTSTEIL Integer Col1=ID_FAHRTRELATION Integer Col4=HALTESTELLE_NAME Char Width 30 [anzeigetext.csv] Col2=ID_HST_START Integer Col5=ID_TARIFGEBIET Integer ColNameHeader=False Col3=ID_HST_ZIEL Integer Col6=IST_BAHNHOF Bit Format=Delimited(;) Col4=ID_PREISSTUFE Integer Col7=ID_KOORDINATENSATZ Integer CharacterSet=ANSI Col5=ID_SORTENGRUPPE Integer Col8=GUELTIG_AB Date Col1=ID_ANZEIGETEXTE Integer Col6=ID_HST_VIA Integer Col9=GUELTIG_BIS Date Col2=MAXLAENGE Integer Col7=ID_VIATEXT Integer Col10=NAME_FAHRPLAN Char Width 60 Col3=NAME Char Width 99 Col8=ID_Z_VIATEXT Integer Col11=DHID Char Width 40 Col4=SUPERNAME Char Width 99 Col9=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer Col12=IBNR Char Width 12 Col5=UNTERNAME Char Width 99 [flaechenrelation.csv] Col13=ID_PARTNER Integer [bundesland.csv] ColNameHeader=False Col14=NAME_VERTRIEB Char Width 30 ColNameHeader=False Format=Delimited(;) [hst_2_verkehrsmittelgattung.csv] Format=Delimited(;) CharacterSet=ANSI ColNameHeader=False CharacterSet=ANSI Col1=ID_FLAECHENRELATION Integer Format=Delimited(;) Col1=ID_BUNDESLAND Integer Col2=ID_TARIFGEBIET_START Integer CharacterSet=ANSI Col2=ID_BUNDESLAND_AGS Char Width 2 Col3=ID_TARIFGEBIET_ZIEL Integer Col1=ID_HST Integer Col3=BUNDESLAND_NAME Char Width 25 Col4=ID_TARIFGEBIET_VIA Integer Col2=ID_VERKEHRSMITTELGATTUNG Integer [equi_tarifgebiet.csv] Col5=ID_SORTENGRUPPE Integer [kalender.csv] ColNameHeader=False Col6=ID_FREIGABE Integer ColNameHeader=False Format=Delimited(;) Col7=ID_PREISSTUFE Integer Format=Delimited(;) CharacterSet=ANSI Col8=ID_START_MENGE Integer CharacterSet=ANSI Col1=ID_EQUI_TARIFGEBIET Integer Col9=ID_ZIEL_MENGE Integer Col1=DATUM Date Col2=ID_TARIFGEBIET Integer Col10=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer Col2=ID_BUNDESLAND Integer Col3=EQUI_ID_TARIFGEBIET Integer Col11=BGLBG_BESONDERHEIT Char Width 32 Col3=KENNUNG Integer Col4=IST_TARIFLICH_RELEVANT Bit [freigabe.csv] [koordinaten.csv] [erweiterte_freigabe.csv] ColNameHeader=False ColNameHeader=False ColNameHeader=False Format=Delimited(;) Format=Delimited(;) Format=Delimited(;) CharacterSet=ANSI CharacterSet=ANSI CharacterSet=ANSI Col1=ID_FREIGABE Integer Col1=ID_KOORDINATENSATZ Integer Col1=ID_TARIFMATRIX Integer Col2=BESCHREIBUNG Char Width 50 Col2=SRID Integer Col2=ID_SORTENSCHLUESSEL Integer [freigabe_fahrtrelation.csv] Col3=WERT1 Float Col3=ID_FREIGABE Integer ColNameHeader=False Col4=WERT2 Float [fahrausweisart.csv] Format=Delimited(;) Col5=WERT3 Float ColNameHeader=False CharacterSet=ANSI [kundengruppe.csv] Format=Delimited(;) Col1=ID_FAHRTRELATION Integer ColNameHeader=False CharacterSet=ANSI Col2=ID_TEILFAHRTRELATION Integer Format=Delimited(;) Col1=ID_FAHRAUSWEISART Integer [freigabe_tzcode.csv] CharacterSet=ANSI Col2=BESCHREIBUNG_KURZ Char Width 50 ColNameHeader=False Col1=ID_KUNDENGRUPPE Integer Col3=BESCHREIBUNG_LANG Char Width 100 Format=Delimited(;) Col2=BESCHREIBUNG Char Width 50 Col4=ABKUERZUNG Char Width 20 CharacterSet=ANSI Col3=ABKUERZUNG_1 Char Width 20 [fahrkartentext.csv] Col1=ID_FREIGABE_TZCODE Integer Col4=ABKUERZUNG_2 Char Width 13 ColNameHeader=False Col2=ID_FREIGABE Integer Col5=ABKUERZUNG_3 Char Width 8 Format=Delimited(;) Col3=ID_TARIFGEBIET Integer [landkreis.csv] CharacterSet=ANSI Col4=SEQ_NR Integer ColNameHeader=False Col1=ID_FAHRKARTENTEXT Integer [fussweg.csv] Format=Delimited(;) Col2=SORTIMENTSNAME Char Width 100 ColNameHeader=False CharacterSet=ANSI Col3=FAHRKARTENTEXT_50 Char Width 50 Format=Delimited(;) Col1=ID_LANDKREIS Integer Col4=FAHRKARTENTEXT_30 Char Width 30 CharacterSet=ANSI Col2=ID_BUNDESLAND Integer Col5=FAHRKARTENTEXT_25 Char Width 25 Col1=ID_FUSSWEG Integer Col3=ID_LANDKREIS_AGS Char Width 3 Col6=INFOTEXT_EFS_40 Char Width 40 Col2=ID_HST_START Integer Col4=LANDKREIS_NAME Char Width 25 Col7=FAHRKARTENTEXT_20 Char Width 20 Col3=ID_HST_ZIEL Integer [landkreis2rp.csv]

250828-E Anlage_16_V4_2_45_003.docx S. 75 / 88

[Seite 76]

ColNameHeader=False CharacterSet=ANSI Col3=ID_TARIFGEBIET_ZIEL Integer Format=Delimited(;) Col1=ID_SORTENGRUPPE Integer Col4=ID_TARIFGEBIET_VIA Integer CharacterSet=ANSI Col2=ID_SORTENSCHLUESSEL Integer Col5=ID_SORTENGRUPPE Integer Col1=ID_LANDKREIS Integer [sortengruppe_2_verbund.csv] Col6=VAR_NR Integer Col2=ID_REGIERUNGSPRAESIDIUM Integer ColNameHeader=False Col7=ID_VIATEXT Integer [linie.csv] Format=Delimited(;) Col8=ID_Z_VIATEXT Integer ColNameHeader=False CharacterSet=ANSI Col9=ID_FREIGABE Integer Format=Delimited(;) Col1=ID_SORTENGRUPPE Integer Col10=ID_PREISSTUFE Integer CharacterSet=ANSI Col2=ID_VERBUND Integer Col11=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer Col1=ID_LINIE Integer Col3=TARIFTYP Bit [uebertragbarkeit.csv] Col2=LINIENNUMMER Char Width 8 [sortenschluessel.csv] ColNameHeader=False Col3=VERKEHRSMITTELKUERZEL Char Width 8 ColNameHeader=False Format=Delimited(;) Col4=ID_VERKEHRSMITTELGATTUNG Integer Format=Delimited(;) CharacterSet=ANSI Col5=DLID_DTID Char Width 100 CharacterSet=ANSI Col1=ID_UEBERTRAGBARKEIT Integer [linien_version.csv] Col1=ID_SORTENSCHLUESSEL Integer Col2=BESCHREIBUNG Char Width 20 ColNameHeader=False Col2=SORTENSCHLUESSEL Integer Col3=ABKUERZUNG Char Width 4 Format=Delimited(;) Col3=ID_FAHRAUSWEISART Integer Col4=INFO_ERFORDERNIS Bit CharacterSet=ANSI Col4=ID_KUNDENGRUPPE Integer [unterlinie.csv] Col1=ID_LINIENVERSION Integer Col5=EIGENSCHAFT Integer ColNameHeader=False Col2=ID_LINIE Integer Col6=IST_ZEITKARTE Bit Format=Delimited(;) Col3=PRIORITAET Integer Col7=ZUSATZ_INFO Char Width 50 CharacterSet=ANSI Col4=GUELTIG_AB Date Col8=ANSCHLUSSKARTENPREISSTUFE Integer Col1=ID_UNTERLINIE Integer Col5=GUELTIG_BIS Date Col9=ID_REFERENZSORTE Integer Col2=ID_LINIENVERSION Integer Col6=LINIENNAME_PUB Char Width 255 Col10=BERECHTIGUNGSTYP Integer Col3=RICHTUNG Char Width 1 Col7=FLAG_LOKAL Bit Col11=PRODUKTNUMMER Integer Col4=VARIANTE Integer [ortsteil.csv] Col12=TICKETFORM Integer [unterlinie_2_strecke.csv] ColNameHeader=False Col13=DRUCKSORTENSCHLUESSEL Integer ColNameHeader=False Format=Delimited(;) Col14=TICKETFORM_TEXT Char Width 30 Format=Delimited(;) CharacterSet=ANSI Col15=REGELTARIFBEZUG Integer CharacterSet=ANSI Col1=ID_ORTSTEIL Integer Col16=VERKAUFSVERPFLICHTUNG_1 Integer Col1=ID_UNTERLINIE Integer Col2=ID_GEMEINDE Integer Col17=VERKAUFSVERPFLICHTUNG_2 Char Width 255 Col2=SEQUENZ_NR Integer Col3=ID_HAUPT_TARIFGEBIET Integer Col18=ID_UEBERTRAGBARKEIT Integer Col3=ID_STRECKE Integer Col4=ID_CALC_TARIFGEBIET Integer [sortenschluessel_ext.csv] [verbund.csv] Col5=ID_ORTSTEIL_AGS Char Width 3 ColNameHeader=False ColNameHeader=False Col6=ORTSTEIL_NAME Char Width 25 Format=Delimited(;) Format=Delimited(;) Col7=ANZ_EINWOHNER Integer CharacterSet=ANSI CharacterSet=ANSI [partner.csv] Col1=ID_SORTENSCHLUESSEL Integer Col1=ID_VERBUND Integer ColNameHeader=False Col2=MODUS_ABWEICHENDE_SORTENFREIGABE Bit Col2=NAME Char Width 20 Format=Delimited(;) Col3=ID_SORTENFREIGABE Integer Col3=TYP Char Width 1 CharacterSet=ANSI [sortenschluessel_gueltig.csv] [verkehrsmittelgattung.csv] Col1=ID_PARTNER Integer ColNameHeader=False ColNameHeader=False Col2=NAME Char Width 10 Format=Delimited(;) Format=Delimited(;) Col3=ABRECHNUNGS_ID Integer CharacterSet=ANSI CharacterSet=ANSI Col4=ABRECHNUNGSKUERZEL Char Width 7 Col1=ID_SORTENSCHLUESSEL Integer Col1=ID_VERKEHRSMITTELGATTUNG Integer Col5=PARTNER_TYP Char Width 8 Col2=MODUS Integer Col2=NAME Char Width 8 [plz.csv] Col3=SEQ_NR Integer [verkehrsmittelgattungsgruppe.csv] ColNameHeader=False Col4=VT_MUSTER Integer ColNameHeader=False Format=Delimited(;) Col5=UHRZEIT_VON Integer Format=Delimited(;) CharacterSet=ANSI Col6=UHRZEIT_BIS Integer CharacterSet=ANSI Col1=PLZ Char Width 50 [sorte_2_fahrkartentext.csv] Col1=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer Col2=ID_TARIFGEBIET Integer ColNameHeader=False Col2=BEMERKUNG Char Width 20 [preisliste.csv] Format=Delimited(;) [verkehrsmittelgattung_2_gruppe.csv] ColNameHeader=False CharacterSet=ANSI ColNameHeader=False Format=Delimited(;) Col1=ID_SORTENSCHLUESSEL Integer Format=Delimited(;) CharacterSet=ANSI Col2=ID_FAHRKARTENTEXT Integer CharacterSet=ANSI Col1=ID_PREISLISTE Integer [strecke.csv] Col1=ID_VERKEHRSMITTELGATTUNGSGRUPPE Integer Col2=ID_SORTENSCHLUESSEL Integer ColNameHeader=False Col2=ID_VERKEHRSMITTELGATTUNG Integer Col3=ID_PREISSTUFE Integer Format=Delimited(;) [version.csv] Col4=GUELTIG_VON Date CharacterSet=ANSI ColNameHeader=False Col5=GUELTIG_BIS Date Col1=ID_STRECKE Integer Format=Delimited(;) Col6=FAHRPREIS Float Col2=ID_HST_START Integer CharacterSet=ANSI Col7=ID_WAEHRUNG Integer Col3=ID_HST_ZIEL Integer Col1=ID_VERSION Char Width 50 Col8=MWST_SATZ_F Float Col4=NAME Char Width 255 Col2=VERSIONSNAME Char Width 50 Col9=MWST_BETRAG_F Float Col5=ENTFERNUNG1 Integer Col3=VERSIONSINFO Char Width 255 Col10=SUBVENTION Float Col6=ENTFERNUNG2 Integer Col4=GUELTIG_AB Date Col11=MWST_SATZ_S Float Col7=ENTFERNUNG3 Integer Col5=GUELTIG_BIS Date Col12=MWST_BETRAG_S Float Col8=ENTFERNUNG4 Integer Col6=QUELLDOKUMENT Char Width 50 Col13=BEMERKUNGEN Char Width 50 Col9=ENTFERNUNG5 Integer Col7=QUELLSYSTEM_VERSNR Char Width 20 [preisstufe.csv] Col10=KOORDINATENFOLGE Char Width 32000 Col8=SYSTEM Char Width 10 ColNameHeader=False [tarifgebiet.csv] Col9=SPEZIFIKATION Char Width 20 Format=Delimited(;) ColNameHeader=False Col10=ISA_ARCHIV Char Width 255 CharacterSet=ANSI Format=Delimited(;) [viatext.csv] Col1=ID_PREISSTUFE Integer CharacterSet=ANSI ColNameHeader=False Col2=PREISSTUFE Char Width 5 Col1=ID_TARIFGEBIET Integer Format=Delimited(;) Col3=DRUCK_PREISSTUFE Char Width 2 Col2=TZ_CODE Integer CharacterSet=ANSI Col4=SORTIERUNG Integer Col3=ID_TARIFGEBIET_TYP Integer Col1=ID_VIATEXT Integer [rp.csv] Col4=TZ_CODE_ATG Integer Col2=VIATEXT_TEXT Char Width 20 ColNameHeader=False Col5=NAME Char Width 50 [waehrung.csv] Format=Delimited(;) Col6=ABKUERZUNG_1 Char Width 30 ColNameHeader=False CharacterSet=ANSI Col7=ABKUERZUNG_2 Char Width 20 Format=Delimited(;) Col1=ID_REGIERUNGSPRAESIDIUM Integer Col8=ANZEIGENAME Char Width 30 CharacterSet=ANSI Col2=ID_BUNDESLAND Integer Col9=DRUCKNAME Char Width 30 Col1=ID_WAEHRUNG Integer Col3=ID_REGIERUNGSPRAESIDIUM_AGS Char Width 1 Col10=ID_VERBUND Integer Col2=WAEHRUNGS_CODE Char Width 3 Col4=REGIERUNGSPRAESIDIUM_NAME Char Width 20 [tarifgebietsfolge.csv] Col3=WAEHRUNGS_CODE_ID Integer [sonderziele.csv] ColNameHeader=False Col4=BEZEICHNUNG Char Width 20 ColNameHeader=False Format=Delimited(;) [zahlungsmodus.csv] Format=Delimited(;) CharacterSet=ANSI ColNameHeader=False CharacterSet=ANSI Col1=ID_STRECKE Integer Format=Delimited(;) Col1=ID_SONDERZIEL Integer Col2=ID_TARIFGEBIET Integer CharacterSet=ANSI Col2=ID_TARIFGEBIET Integer Col3=SEQ_NR Integer Col1=ID_ZAHLUNGSMODUS Integer Col3=ID_ORTSTEIL Integer [tarifgebiet_typ.csv] Col2=BESCHREIBUNG Char Width 30 Col4=ID_HALTESTELLE Integer ColNameHeader=False Col3=ABKUERZUNG Char Width 10 Col5=SONDERZIEL_NAME Char Width 25 Format=Delimited(;) Col4=INFO_ERFORDERNIS Bit Col6=ID_PREISSTUFE Integer CharacterSet=ANSI [z_viatext.csv] [sortengruppe.csv] Col1=ID_TARIFGEBIET_TYP Integer ColNameHeader=False ColNameHeader=False Col2=TARIFGEBIET_TYP Integer Format=Delimited(;) Format=Delimited(;) Col3=TYP_NAME Char Width 10 CharacterSet=ANSI CharacterSet=ANSI Col4=BESCHREIBUNG Char Width 255 Col1=ID_Z_VIATEXT Integer Col1=ID_SORTENGRUPPE Integer [tarifmatrix.csv] Col2=Z_VIATEXT_TEXT Char Width 255 Col2=BESCHREIBUNG Char Width 100 ColNameHeader=False Col3=SORTENGRUPPE Integer Format=Delimited(;) [sortengruppe_2_sorte.csv] CharacterSet=ANSI ColNameHeader=False Col1=ID_TARIFMATRIX Integer Format=Delimited(;) Col2=ID_TARIFGEBIET_START Integer

250828-E Anlage_16_V4_2_45_003.docx S. 76 / 88

[Seite 77]

5.3 Abkürzungen und Glossar

5.3.1 AGS Amtlicher Gemeindeschlüssel. siehe  Gebietskörperschaftsstruktur

5.3.2 CSV Abkürzung für ”comma separated values”. Es handelt sich um ein ASCII- Dateiformat, bei dem die Felder variable Längen besitzen und die Felder durch ein Feldtrennzeichen abgetrennt werden. Anders als der Name nahelegt muss dieses Trennzeichen nicht zwangsweise ein Komma sein und ist es faktisch im deutschen Sprachraum in den seltensten Fällen. Aufgrund der vom angelsächsi- schen abweichenden Trennzeichen für Tausendertrennung, Dezimalstellen usw. hat sich hier das Semikolon als Trennzeichen durchgesetzt. Aus historischen Gründen bleibt es für das (platzsparende) Datenformat mit variabler Feldlänge aber bei dem Oberbegriff ”csv-Format”, unabhängig vom faktisch verwendeten Trennzeichen, das natürlich niemals als Element der Daten selbst vorkommen darf. Daher findet man auch Datenformate mit in ”Alltagsdaten” selten vorkom- menden Trennzeichen wie bspw. ”$” oder ”#” o. ä. Da die Daten als Zeichenfolge ausgegeben werden kann es naturgemäß keine anderen nativen Datentypen wie bspw. BOOLEAN, INTEGER oder Fließkomma- zahlen einer bestimmten Genauigkeit geben. Wenn in den obigen Datentypen diese angegeben sind, dann ist damit zum Ausdruck gebracht, dass die fragliche Zeichenkette als solch ein Datentyp zu interpretieren ist. Faktisch ist und bleibt es eine Zeichenkette. Zur Kodierung siehe Abschnitt 1.4.

5.3.3 DxID (DHID, DLID, DTID, DFID) DHID: Deutschlandweit eindeutige Haltestellen-ID DLID: Deutschlandweit eindeutige Linien-ID DTID: Deutschlandweit eindeutige Teillinien-ID DFID: Deutschlandweit eindeutige Fahrt-ID Dies sind hierarchisch aufgebaute IDs die in den VDV Schriften 432 & 433 beschrieben sind. Die Trennung der Hierarchieebenen erfolgt durch Dop- pelpunkt. Dabei wird die DLID aus organisatorischen Gründen immer als Kombination aus DLID und DTID und somit als DLID_DTID ausgegeben um bspw. versch. Liefe- ranten für die gleichen Linien in der Datenorganisation unterscheiden zu können. Die DTID enthält immer im vorderen Teil die DLID, stellt also nur eine Verfeine- rung der DLID dar – insofern dies notwendig ist. Anderenfalls ist die DTID inhalt- lich identisch zur DLID. Allerdings endet die DTID in diesem Fall mit einem Dop- pelpunkt. Damit wird kenntlich gemacht, dass es sich formal um eine DTID han- delt. Der RMV exportiert daher (linie.csv) immer nur die DLID_DTID „Kombina- tion“ (formal eine DTID), bspw.: „de:rmv:00000496:005“ Die DLID hierzu lautet: „de:rmv:00000496“ Falls es keine inhaltliche DTID „Ergänzung“ gibt (bspw. nur ein Lieferant, Unter- scheidung nicht nötig) wäre im obigen Bsp…

250828-E Anlage_16_V4_2_45_003.docx S. 77 / 88

[Seite 78]

… die DTID = de:rmv:00000496: … die DLID = de:rmv:00000496 Weiterhin wird auf die VDV Schriften verwiesen.

5.3.4 FK Abkürzung für ”Foreign Key”, englisches Fachwort für Fremdschlüssel. Ein Fremdschlüssel ist ein Feld einer Tabelle, das eine Referenz auf den Primär- schlüssel einer anderen Tabelle enthält. Mit Hilfe von Primär- und Fremdschlüs- seln wird definiert, welche Datensätze der Tabellen miteinander verknüpft wer- den können. Eine Tabelle, die einen Fremdschlüssel enthält, wird als Detailta- belle bezeichnet, in Bezug auf die korrespondierende Tabelle, die den zugehöri- gen Primärschlüssel enthält. Das Fremdschlüsselfeld der Detailtabelle darf nur Werte enthalten, die im Pri- märschlüsselfeld der in Beziehung stehenden Tabelle vorhanden sind. Das Fremdschlüsselfeld darf einen Wert des Primärschlüsselfelds mehrfach (= in mehreren Datensätzen der Detailtabelle) enthalten. Man spricht von einer 1:n- Beziehung.

5.3.5 Gebietskörperschaftsstruktur Die Gebietskörperschaften Bundesland, Regierungspräsidium, Landkreis, Ge- meinde, Ortsteil sind hierarchisch strukturiert. Dies wird im amtlichen Gemeinde- schlüssel AGS (vormals GKZ = Gemeindekennziffer) dargestellt, dessen Stellen jeweils die genannten Inhalte als Zahlenstruktur wiedergeben. Die Bundesländer nehmen die Gliederung z. T. unterschiedlich vor und damit herrschen auf Ge- meinde- und Ortsteilebene in den angrenzenden Bundesländern für die  ÜTs keine ”hessischen Verhältnisse”. Der AGS hat für Gemeinden / Städte üblicher- weise 8 Stellen, in Hessen bzw. beim RMV werden für die Ortsteile 11 Stellen verwendet.

5.3.6 GKZ Veraltete Bezeichnung für den  AGS Wo nötig wurden die Feldnamen die vormals ein ‚GKZ‘ im Namen hatten, auf die aktuelle Situation angepasst und auf ‚AGS‘-xxx geändert.

5.3.7 Grenzhaltestelle / Grenztarifgebiet Grenztarifgebiete (früherer Name auch: Grenzhaltestellen) erlauben es dem Kunden bei Fahrt in die angrenzenden Tarifgebiete den jeweils günstigsten Tarif zu erhalten so als gehöre die Haltestelle immer zu dem für seine Fahrtrichtung wünschenswerten Tarifgebiet. Da das tarifbildende Grundelement im RMV Ta- rifsystem immer ein Tarifgebiet und damit eine Fläche ist, kann dieses Ziel aus datentechnischen Gründen nur erreicht werden, indem die entsprechende Halte- stelle als mathematisches Punktobjekt datentechnisch Inhalt eines Grenztarifge- bietes wird. Der Begriff Grenzhaltestelle ist damit nicht mehr üblich und genau genommen nicht korrekt. Zur Abbildung der tariflichen Identität zum je benach- barten Tarifgebiet wird eine EQUI Beziehung zwischen den erwünschten Tarifge- bieten eingeführt (Tabelle „equi_tarifgebiet”). Eine Fahrt „auf der Grenzlinie” wird damit zur Fahrt innerhalb des Grenztarifgebiets.

250828-E Anlage_16_V4_2_45_003.docx S. 78 / 88

[Seite 79]

5.3.8 PFK Abkürzung für „Primary Foreign Key”, englisches Fachwort, bezeichnet Primär- schlüssel ( PK) einer Tabelle, die ihrerseits Fremdschlüssel einer anderen Ta- belle sind.

5.3.9 PK Abkürzung für „Primary Key”, englisches Fachwort für Primärschlüssel. Ein Feld einer Datenbank-Tabelle, das jeden Datensatz der Tabelle eindeutig identifiziert. Somit ist jeder Wert im Primärschlüsselfeld eindeutig; er darf in der Tabelle nur in einem Datensatz benutzt werden. Der Primärschlüssel ist fast immer ein rein technisch gefüllter Wert ohne inhaltliche Bedeutung. Dies verdeutlicht z. B. die Tabelle haltestelle.csv (siehe dort) in der der technische Schlüssel NICHT iden- tisch ist zu der ebenfalls eindeutigen Haltestellennummer des RMV die wiederum in der Kommunikation eine identifizierende Rolle spielt. Die Inhalte des PK- Feldes bleiben, bezogen auf einen konkreten Datensatz, hier z. B. eine konkrete Haltestelle, über verschiedene Auslieferungen (= Tarifwechsel) der Tarifdaten- bank hinweg, NICHT gleich – die RMV-Haltestellennummer jedoch unbedingt.

5.3.10 TG / OTG TG steht als Abkürzung für TarifGebiet. OTG steht als Abkürzung für OberTarifGebiet.

5.3.11 TRK TRK steht als Abkürzung für den TarifRechenKern. Im TRK ist die „korrekte RMV-Tariflogik“, die auf den Daten operiert (so wie in diesem Dokument be- schrieben) implementiert. Der TRK ist für diverse Plattformen entwickelt. Durch Einbindung des TRK muss die Tariflogik nicht mehr nachgebildet werden, son- dern gemäß der Funktionsweise von Schnittstellen genügen Anfragen an den TRK mit einer überschaubaren Anzahl relevanter Parameter um ein tariflich kor- rektes Ergebnis zu erhalten. Falls Bedarf oder Interesse an der Integration des TRK in ihre Anwendung besteht treten Sie bitte mit tarifwechsel@RMV.de in Kontakt.

5.3.12 ÜT Übergangstarif(gebiet): Teilbereich eines an den RMV angrenzenden Verkehrs- verbundes mit dem tarifliche Vereinbarung bestehen, die die Fahrt mit einem ein- zigen Fahrschein zu einem Ziel des ÜT (oder umgekehrt) ermöglichen. Häufig sind nicht alle Angebote (Sortenschlüssel) in den ÜT realisiert (unter Umständen haben sie dort keine Entsprechung oder sind abweichend definiert), so dass beim Verkauf meist gesonderte Bestimmungen zu beachten sind. Bislang gilt für alle ÜTs: Symmetrischer Verkauf zum gleichen Tarif unabhängig von der Fahrt- richtung (ein- / ausbrechend).

250828-E Anlage_16_V4_2_45_003.docx S. 79 / 88

[Seite 80]

5.4 Zahlungsart (Stand 03.12.2024) Für die Verkaufsdatenmeldung ist die Zahlungsart mit zu liefern. Da es aufgrund vieler Innovationen in diesem Bereich zu dauernden Änderungen kommt, ist der Datenliefe- rant gehalten, regelmäßig die Aktualität der genutzten Codes zu prüfen.

250828-E Anlage_16_V4_2_45_003.docx S. 80 / 88

[Seite 81]

5.5 Verkaufstechnik (Stand 19.03.2024) Für die Verkaufsdatenmeldung ist die Verkaufstechnik mit zu liefern. Da es aufgrund vieler Innovationen in diesem Bereich zu dauernden Änderungen kommt, ist der Da- tenlieferant gehalten, regelmäßig die Aktualität der genutzten Codes zu prüfen.

250828-E Anlage_16_V4_2_45_003.docx S. 81 / 88

[Seite 82]

5.6 Details zur Nummerierung von Haltestellen Informationen zu Feld 2 und Feld 11: Die „DHID“ (Feld 11) hat die bislang im Tarifbereich maximal 6-stellige, numerische Haltestellennummer (Feld 2: Bezeichnung „RMV_Haltestellennummer“ ) durchgängig ergänzt. Diese globale Haltestellen-ID ist bevorzugt zu nutzen, da sie für jede Halte- stelle eine weltweit eindeutige ID darstellt. Dies verspricht insbesondere im Über- gangstarif-Bereich (ÜT) eine Harmonisierung bislang unterschiedlicher IDs. Dort kommen bislang für die gleiche Haltestelle mehrere, von unterschiedlichen Verkehrs- unternehmen und Aufgabenträgern jeweils unabhängig vergebene IDs zum Einsatz. Der Übergang zur DHID ermöglicht ohne Zuordnungstabellen auszukommen, da auch umgekehrt, jede HST nur durch eine einzige ID gekennzeichnet wird. Dazu ist es notwendig, dass diese ID durch einen lokal zuständiger Aufgabenträger (nach vorgegebenem Schema) vergeben wird und diese von allen bedienenden Unterneh- men und Systemen (mindestens in den Schnittstellen und beim Datenaustausch) ge- nutzt wird. Auf absehbare Zeit werden beide Felder (2 und 11) gefüllt. Feld Nr. 11 ist strukturell für die Ausgabe dieser (für den RMV) bis zu max. 40 Zeichen langen al- phanumerischen(!!) ID angepasst. Gespeichert wird die DHID nur bis zur Ebene 3 (Haltestelle). Die detaillierteren Strukturebenen „Bereiche“, „Maste“ und „Haltestellen- positionen“ werden auch mit der neuen ID in den Tarifdaten weiterhin nicht gespei- chert. Wenn auch zunächst RMV-seitig noch die gewohnte max. 6-stellige numerische RMV-Haltestellennummer – vielfach noch bekannt als „DIVA- oder infopool-Nr." – in Feld 2 verwendet wird, sind alle Systeme für die zusätzliche Verarbeitung des länge- ren, alphanumerischen Datentyps aus Feld 11 vorzubereiten. Der RMV wird bekannt- geben, wann gänzlich auf die Nutzung der globalen Haltestellen-ID umzustellen ist. Das Verfahren der parallelen Lieferung beider kennzeichnender IDs erlaubt die kon- sequente Anpassung nutzender Systeme in einem Übergangszeitraum auf die neue ID. Hinweis zur 6-Stelligkeit von Inhalten in Feld 2: In der aktuellen praktischen Verwendung haben Haltestellen im Gebiet der Über- gangstarifgebiete 6-stellige Werte. Alle Haltestellen des RMV-Kerngebietes verwen- den weiterhin max. 5-stellige IDs. Die Datenlieferung der Übergangstarifgebiete er- folgt nach folgender Systematik: Alle Bushalte des VAB unter deren eigener (max. 5-stelligen) ID + 900.000, so dass alle VAB-Bushalte 6-stellig sind und an der führenden „9“ erkennbar sind. Es gilt auch umgekehrt: Alle sechsstelligen IDs mit führender „9“ sind ausschließlich VAB-Bushalte. Des Weiteren sind alle Schienenhalte im Gebiet des VAB unter Modifikation der origi- nären 7-stelligen DB-IBNR aufgenommen. Durch Entfernung der zweiten Stelle (die deutschlandweit stets = „0“ ist) sind diese nun ebenfalls 6-stellig und aktuell an ihrer führenden „8“ zu erkennen (Beachten Sie den Hinweis weiter unten). Im VAB ist – im Gegensatz zum RMV-Kerngebiet – jeder Bushalt an einer Schienen- station unter einer eigenen Nummer repräsentiert. Verdeutlichung am Beispiel:

RMV_Haltestellennummer Ab FPLW 2020/21 Info (IBNR der DB)

250828-E Anlage_16_V4_2_45_003.docx S. 82 / 88

[Seite 83]

Der RMV hat Anpassungen mit ähnlicher Vorgehensweise für weitere ÜTs vorge- nommen. Die Haltestellennummern der Tarifdaten sind nur für ÜTs 6-stellig. Die nachfolgenden Aussagen hinsichtlich der HAFAS Nummer gelten streng nur für Verkehrsverträge die unter der Regie des RMV stehen. Ein- und ausbrechende Ver- kehre die nicht unter der Regie des RMV stehen verwenden u.U. abweichende HAFAS Präfixe und Haltestellen IDs. Für die inzwischen angepassten ÜTs gelten folgende Zusammenhänge Die restlichen 5 Stellen entsprechen den HST-IDs des jeweiligen Verbundes NNNNN

• Aktuell gibt es nur eine einzige, vom RMV betriebene Buslinie in den NVM. Es erfolgt keine flächendeckende Tarifierung ein- zelner Gebiete. Wenn sich dies ändert, wird das HAFAS-Präfix des NVM genutzt werden. Hinweis 1: Da VRN und RNN einen gemeinsamen Datenpool verwenden kann es hier zu keinen Dopplungen kommen, daher kann der gleiche HAFAS Präfix verwen- det werden. Hinweis 2: Der HAFAS Präfix sind die ersten 2 Ziffern der Haltestellen-IDs die in der elektronischen Fahrplanauskunft des RMV auftreten. Danach folgen auf 5 Stellen aufgefüllt die max. 5-stelligen (!) IDs die sich durch Entfernung der ersten Ziffer der HST-ID ergibt, sofern diese 6-stellig ist (und somit eindeutig zu einem Übergangsta- rifgebiet gehört). Beispiele: 1.) Der o.g. Hauptbahnhof Aschaffenburg Schiene hat die Hst-ID 800010 In der Fahrplanauskunft wird die erste der sechs Stellen entfernt und durch 92 ersetzt. Die HAFAS ID ist also 9200010 2.) Der o.g. Hauptbahnhof Aschaffenburg Bus hat die HST-ID 905100 In der Fahrplanauskunft wird die erste der sechs Stellen entfernt und durch 92 ersetzt. Die HAFAS ID ist also 9205100 3.) Ingelheim Bahnhof (Schiene und Bus) hat die ID 608192, also RNN In der Fahrplanauskunft wird die erste der sechs Stellen entfernt und durch 93 ersetzt. Die HAFAS ID ist also 9308192 4.) Hofheim Bahnhof (Schiene und Bus) hat die ID 4199, nicht 6-stellig; also RMV Kerngebiet. In der Fahrplanauskunft wird KEINE Stelle entfernt. Der Präfix ist „30“. Die

250828-E Anlage_16_V4_2_45_003.docx S. 83 / 88

[Seite 84]

HAFAS ID ist also 3004199. 5.) Frankenberg (Eder) hat die HST-ID 205326 (NVV). In der Fahrplanauskunft wird die erste der sechs Stellen entfernt und durch 22 ersetzt. Die HAFAS ID ist also 2205326.

Infolge der in den Verbünden unterschiedlich gehandhabten Datenhaltung an Bahn- höfen mit gemeinsamer oder getrennten IDs für Schiene und Bus kann über die Re- gionalität einer Station mit führender „8“ keine sichere Aussage gemacht werden. Bahnstationen im Bereich des NVV haben an erster Stelle eine 2, im RNN eine 6 und im VRN eine 4. Es wird empfohlen, wo immer möglich in eigenen Systemen neben der Hst-ID die eindeutigen DHIDs (globale ID) mit zu führen. Weitere Informationen zum Thema „globale Haltestellen-ID“ sind in Anlage 17 (Da- tenhandbuch des RMV) im Glossar und den einleitenden Kapiteln zu finden.

5.7 Bildung von Freigaben für Fahrtrelationen Nachfolgendes Beispiel 1 verdeutlicht den Sachverhalt. Wir betrachten zwei Fahrtrelationen: 1a) Die Fahrtrelation von A nach E. 1b) Die Fahrtrelation von B nach E. Es soll im Folgenden deutlich werden, dass für die Kurzstrecke A – E (4711) der Weg A – B – D – C – E nicht erlaubt ist. Hingegen sei für die Kurzstrecke B – E der Weg B – D – C – E noch kurz genug, also Kurzstrecke.

Für jede der beiden obigen Fahrtrelationen gibt es einen Eintrag in der Tabelle „fahrtrelation“. Zu jedem Eintrag gibt es eine Menge von atomaren Kurzstrecken die in der Freigabetabelle referenziert sind. Bsp.1a: Es sollen als Kurzstrecke zwischen A und E folgende Fahrwege erlaubt sein: A – B – D – E (orange-grün) sowie A – B – C – E (orange-blau). Hingegen sollen folgende Fahrwege nicht als Kurzstrecke gelten: A – E (gestrichelte), A – B – D – C – E oder A – B – C – D – E (also über rot) Dies wird dargestellt durch EINEN Datensatz in der Tabelle „fahrtrelation“ bei dem A als Start und E als Ziel fungiert. (In der symbolischen Beispieltabelle unten als „4711“ eingetragen).

250828-E Anlage_16_V4_2_45_003.docx S. 84 / 88

[Seite 85]

Als Via könnte einerseits B agieren, was den Kunden aber möglicherweise im Unkla- ren über die Fahrtvarianten über C und D lässt. Da es nur eine Via-Haltestelle im Da- tensatz geben kann, kann als fiktives Via die ID_HST_Via = 99999 genutzt werden, um über den begleitenden VIA_TEXT eine aussagekräftige Information beizustellen (bspw. „alternativ über C oder D“). Die Freigabe referenziert nun die atomaren Datensätze {A – B, B – C, C – E, B – D, D – E }, hingegen nicht die (für diesen Fall) unerlaubte Strecke D – C oder C – D. Bsp. 1b: Hier ist hingegen der „rote Umweg“ erlaubt. Die beiden (gerichteten!) atoma- ren Fahrtrelationen C – D und D – C sind daher zusätzlich referenziert.

fahrtrelation freigabe_fahrtrelation

:

:

Atomare Fahrtrelationen zur Verdeutlichung fett markiert

Im folgenden Beispiel 2 wird verdeutlicht, dass durch die datensparende Speiche- rung aller Fahrtvarianten einer Fahrtrelation in einem Datensatz eine geringe Un- schärfe eingekauft wird. Diese ist in der Praxis aber kaum bedeutsam. Der nachfol- gend aufgezeigte Effekt wird durch die Filterung der theoretisch möglichen Fahrwege aufgrund der Fahrweg-optimierenden Logik innerhalb der Fahrplanauskunft dem Grunde nach aufgehoben und auf diese Weise minimiert. Es soll im Folgenden deutlich werden, dass für die Kurzstrecke A – F (4711) der un- erwünschte, eigentlich zu lange Weg A – B – C – E – F mit der aktuellen speichermi- nierenden Datenhaltung nicht ausgeschlossen werden kann. Jede der beteiligten Teilstrecken ist (im Gegensatz zu Bsp. 1) in irgendeiner Fahrtvariante erlaubt. Da die Daten aktuell keine fahrwegscharfe Darstellung enthalten, ist somit auch der zu lange Weg erlaubt. Hingegen wird i. allg. die Fahrplanauskunft diese Fahrtvarianten auf entsprechenden Endgeräten gar nicht anbieten.

250828-E Anlage_16_V4_2_45_003.docx S. 85 / 88

[Seite 86]

fahrtrelation freigabe_fahrtrelation

:

:

4711 A F

Atomare Fahrtrelationen zur Verdeutlichung fett markiert

Der gestrichelte Fahrweg AC wäre durch eine abweichende ID_Fahrtrelation von 0817 prinzipiell zu unterscheiden. Diese Fälle werden in der Datenhaltung allerdings bewusst zusammengeführt, so dass die Restriktion „Je Fahrtrelation nur ein Datensatz“ eingehal- ten wird. Hinweis: Zwischen den Teilfahrten können Lücken auftreten, wenn zwischen zwei Halte- stellen ein Fußweg liegt. Diese sind in der Tabelle „fussweg“ definiert.

5.8 Änderungsverzeichnis dieses Dokumentes

250828-E Anlage_16_V4_2_45_003.docx S. 86 / 88

[Seite 87]

250828-E Anlage_16_V4_2_45_003.docx S. 87 / 88

[Seite 88]

250828-E Anlage_16_V4_2_45_003.docx S. 88 / 88