Informējam, ka Sistēma pielāgota darbam ar interneta pārlūkprogrammu Internet Explorer (8. un jaunākām versijām) un Mozilla Firefox (3.6 un jaunākām versijām).
Izmantojot citu interneta pārlūkprogrammu, brīdinām, ka Sistēmas funkcionalitāte var tikt traucēta.
NeTEx Part 3 is dedicated to the information related to the determination of fares.
It must be reminded that fare is not tariff: in NeTEx part 3 a fare refers to FARE PRODUCT (see Transmodel) defined by its parameters (access write, validity, etc.), where a tariff refers to the price to be paid to purchase a FARE PRODUCT. Only fixed, schedulesd price will be available in NeTEx. Dynamic price (i.e. yield manage price) and availability are out of scope, as they are a realtime information and not a scheduled information.
Several level of exchange will be foreseen:
1. Exchange information about links (web sites) and places (retailers) where to get fare information and where to buy tickets (no fare description in this use case),
2. Exchange information on fare products parameters, and their rules and restrictions (covering at least but not exclusive TAP-TSI B.1, B.2 and B.3)
3. Supply of a possible, non normative interface (API) to request for the availability and price for a specific journey: the input basically being a passenger journey (using part 1&2 model), and a selected fare product and the answer being the availability for this journey and its price based on the selected product. Price calculation itself is of course out of scope for NeTEx, this API being only an exchange
Reģistrācijas numurs (WIID)
66890
Darbības sfēra
NeTEx Part 3 is dedicated to the information related to the determination of fares.
It must be reminded that fare is not tariff: in NeTEx part 3 a fare refers to FARE PRODUCT (see Transmodel) defined by its parameters (access write, validity, etc.), where a tariff refers to the price to be paid to purchase a FARE PRODUCT. Only fixed, schedulesd price will be available in NeTEx. Dynamic price (i.e. yield manage price) and availability are out of scope, as they are a realtime information and not a scheduled information.
Several level of exchange will be foreseen:
1. Exchange information about links (web sites) and places (retailers) where to get fare information and where to buy tickets (no fare description in this use case),
2. Exchange information on fare products parameters, and their rules and restrictions (covering at least but not exclusive TAP-TSI B.1, B.2 and B.3)
3. Supply of a possible, non normative interface (API) to request for the availability and price for a specific journey: the input basically being a passenger journey (using part 1&2 model), and a selected fare product and the answer being the availability for this journey and its price based on the selected product. Price calculation itself is of course out of scope for NeTEx, this API being only an exchange
