# VDV Bardcode field mappings
When requesting a VDV barcode, TapConnect generates barcodes according to the VDV_KA_SPEC_1.9.1 specification. The documents describing this specification can be obtained at e-ticket Deutschland (opens new window).
The field list below is mostly based on Technische Anforderung Deutschlandticket V1.7.pdf
page 15, chapter 4.3
Field | TapConnect contents | Description |
---|---|---|
berBerechtigung_ID (Struktur "Berechtigung_ID") | ||
- Berechtigung_ID | vSAM signing key usage counter plus setting Issuing.barcodeVdvEntitlementNumberOffset See FAQ | BerechtigungsId is the entitlement offset + vSAM Signature Key Usage Counter. Please note that the Berechtigung_ID is unique, but not related to the ticketId or the serviceId we know in TapConnect. |
- Referenz-ORG_ID für KVP | Issuing.barcodeVdvOrgId (vSAM Key OrgId), OrgId of the transport operator | |
- prodProdukt_ID | 0x270f0bb8 (0x270f=9999 dec), (0x0bb8=3000 dec). First part is the product code, and the second part is the PV OrgId See FAQ. Product codes are 9999 for regular D-Ticket, 9998 for job ticket, 9995 for Student/Schüler ticket) | Technische Anforderung Deutschlandticket V1.7.pdf page 5 for the product numbers, and page 15 for the Org_id of the PV: "...ORG_ID des zentralen PV", and KA HD_BOM-Spec_V190.pdf page 104, table 6-103 for the structure. |
- berGueltigkeitsbeginn | Barcode validity start (this is also ticket validity start) | date in dateTimeCompact format, see KA HD_BOM-Spec_V190.pdf page 50, table 6-10 |
- berGueltigkeitsende | Barcode validity end (this can be different from ticket validity end in case of dynamic barcodes) | date in dateTimeCompact format, see KA HD_BOM-Spec_V190.pdf page 50, table 6-10 |
Berechtigung – Statischer Produktspezifischer Teil | ||
Tag "Fahrgast" | See Anlage TLV EFS_V190.pdf, page 9, Tag 0xDB – Fahrgast | |
- efsFahrgastGeschlecht | Hardcoded to 0x00, See FAQ | See Technische Anforderung Deutschlandticket V1.7.pdf page 15, "Gemäß Vorgabe VDV-ETS" |
- efsFahrgastGeburtsdatum | Filled with date of birth if provided, 1970-01-01 otherwise | See Anlage TLV EFS_V190.pdf, page 9, 2.2 Tag 0xDB – Fahrgast |
- efsFahrgastName | Filled with Type 1 anonymized traveler name, empty otherwise See FAQ | See KA HD_BOM-Spec_V190.pdf, 6.7.2 Kürzungsregel für Namen und Vornamen |
Tag "Liste originärer Geltungsbereich" | ||
- Typ-Definition | Hardcoded: 0x0F | See Technische Anforderung Deutschlandticket V1.7.pdf page 15, "Gemäß Vorgabe VDV-ETS", and Anlage TLV EFS_V190.pdf page 18 Tabelle 2-8, Variant D 0x0F |
- Organisation_ID (PV) | Hardcoded: 0x1388 (5000 dec) | See Technische Anforderung Deutschlandticket V1.7.pdf page 15, "Gemäß Vorgabe VDV-ETS" |
- Liste-Flaeche-IDs | Hardcoded: 0x00 0x01 | See Technische Anforderung Deutschlandticket V1.7.pdf page 15, "Gemäß Vorgabe VDV-ETS" |
logTransaktionsOperator_ID | Issuing.barcodeVdvOrgId (vSAM Key OrgId) | |
logTerminal_ID (Struktur "Terminal_ ID") | See KA HD_BOM-Spec_V190.pdf, page 112, table 6-127 | |
- TerminalTyp | Issuing.barcodeVdvTerminalTyp , Usually set to 0x11 (17, Online Ticket Server = barcode auf papier) | See KA HD_BOM-Spec_V190.pdf, page 92, table 6-85 |
- terminalNummer | Issuing.barcodeVdvTerminalId | Configurable per Tenant |
- terminalBetreiber | Hardcoded: 39380, XIMEDES_L2_ORGID See FAQ | |
logTransaktionsZeitpunkt | Validity start or the Date/time of creation of the barcode, whichever is earlier, See FAQ | See KA HD_BOM-Spec_V190.pdf, page 132, table 6-158 |
TransaktionsOrtID (Struktur "Ort_ID") | See KA HD_BOM-Spec_V190.pdf, page 110, table 6-123 | |
- OrtTyp | Hardcoded: 0xc9 (201 dec), Massenpersonalisierer | See KA HD_BOM-Spec_V190.pdf, page 84, table 6-69 |
- OrtNummer | Hardcoded: 0x01 | |
- OrtDomaene_ID | Hardcoded: 0x99d4 (39380 dec), XIMEDES_L2_ORGID See FAQ | |
Transaktion Produktspezifischer Teil | ||
- Tag "Transaktion Produktspezifischer Teil" | Hardcoded 0x8a 0x00, empty TLV, length 0. | See Technische Anforderung Deutschlandticket V1.7.pdf page 15, "Der Transaktion Produktspezifische Teilwird beim TLV EFS nicht benutzt." |
- berProdLog SAMSeqNummer | vSAM signing key Usage counter | See KA HD_BOM-Spec_V190.pdf, page 140, table 6-162 |
- Version MKpv | vSAM KV (1 byte key version) | See KA HD_BOM-Spec_V190.pdf, page 130, table 6-152 |
- SamSequenznummer | vSAM Usage counter (in our case this is the Key Usage Counter, see berProdLog SAMSeqNummer) | See KA HD_BOM-Spec_V190.pdf, page 113, table 6-130 |
- SAM_ID.samNummer | 3 byte vSAM number provided during the ordering process in the ASM-Tool of VDV (opens new window) | As registered with VDV, see KA SAM-Spec_V190.pdf page 205 and KA NM-SPEC_V190.pdf page 199 table 5-12 |
- Füllbytes | Padding with 0x00 bytes to make the total ticket at least 111 bytes long | See KA STB-SPEC_V190.pdf, Tabelle 3-1, page 12 |
Kennung "VDV" | Hardcoded: "VDV" as OctetString | See KA STB-SPEC_V190.pdf, Tabelle 3-1, page 12 |
Version | Hardcoded: 0x19, 0x00 (version 1.9.0.0 of the KA-STB spec) | See KA STB-SPEC_V190.pdf, Tabelle 3-1, page 12, footnote 11: not configurable |
# FAQ
# Why doesn't the Ticket ID match the data element berechtigungNummer
TapConnect is an existing barcode generation solution which generates its own ticketId and serviceId. The VDV berechtigungsNummer is not useful to the traveler. When a customer has questions about a ticket, normally the serviceId is used in communication with our servicedesk. This serviceid can be found in the responses of TapConnect API when creating or getting info about the Ticket, and is shown in the D-Ticket app on the "back" of the barcode.
The berechtigungNummer is built from the SAMSeqNummer plus a configurable offset, which we configure to be 0 by default. Please let us know if your offset needs to be different.
# Why is the PV Org-Id always 3000
According to the information we received in the document "Technische Anforderung Deutschlandticket v1.7", page 6, the organizationsNummer (OrgID) of the Produktverantwortlicher should be 3000:
Aufgrund eines Beschlusses des VDV-Präsidiums wird ein zentraler, technischer PV eingeführt. Das entsprechende zentrale PVS (ZPVS) wird vorläufig von VDV-ETS betrieben und arbeitet mit der ORG_ID 3000 (Level 3) bzw. 35768 (Level 2). Demzufolge ist als PV-Schlüssel (KID 40) der mit der ORG_ID 3000 (Level 3) bzw. 35768 (Level 2) jeweils in der Regel- und Notfallversion zu verwenden. Diese ORG_ID ist in die Produkt_ID einzutragen.
# Why is the logTransaktionsZeitpunkt not the current/date/time?
According to the VDV specification the logTransaktionsZeitpunkt cannot be after berGueltigeitsbeginn. So when your ticket is valid from the first of the month, the logTransaktionsZeitpunkt will also be the first of the month.
Ticket created at : 10.08.2023 10:46 Uhr for a D-Ticket in August
berGueltigkeitsbeginn : 01.08.2023 00:00
logTransaktionsZeitpunkt : 01.08.2023 00:00
# Why is "fahrgastGeschlecht" always "unspecified"
In TapConnect 523 of October 17th we changed the efsFahrgastGeschlecht to "unspecified" (0x00), as specified in "Technische Anforderung Deutschlandticket v1.7"
# Why is tag „Grundlegende Daten“ (0xDA) not in the barcode?
This is optional information currently not in the Ticket. For D-Ticket this seems less relevant. There are currently no plans to add this optional information to the barcode. (it is also not part of the example in the Technische Anforderung D-Ticket)
# Why are the terminalBetrieber and OrtDomaene_ID the Level 2 Ximedes id
The logTerminal_ID.terminalBetrieber and TransaktionsOrtID.OrtDomaene_ID are the Level 2 Ximedes id (39380), since Ximedes is the "operator" of your vSAM. During implementation we discussed this with VDV, and implemented it as follows:
logTerminalID (structure "Terminal ID")
terminalTyp.code = 16 decimal (mobile phone ticket server) or 17 decimal (online ticket server = barcode on paper)
terminalNummer = number is assigned by the SAM server operator
Organisation_ID.organisationsNummer = ORG_ID of the SAM server operator (Level 2)
logTransaktionsOrtID (structure " Ort_ID")
ortTyp.code = 201
ortNummer = number assigned by the SAM server operator
Organisation_ID.organisationsNummer = ORG_ID of the SAM server operator (Level 2)
In case the KVP wants to have this field filled differently, please contact us.
# Why is the efsFahrgastname encoded
The name of the traveler is stored in an anonymized form in the barcode. According to KA HD_BOM-Spec_V190.pdf, 6.7.2 Kürzungsregel für Namen und Vornamen there are two types of anonymization of names. We chose Type 1 (Maskierter und gekürzter Name). There is also a Type 2, which is currently not supported.
An example of Type 1 anonymization:
Firstname : Eva-Maria Alexandra Tanja Manuela
Lastname : Gräfin von Konstantinopolus
Becomes : E1a*@*K0s
Depending on your barcode scanner, this can be shown on screen as E_a K_________s
.