Preventing misinformed RPIs from issuing PFs wrongly

[Bletchleyite]

In response to a couple of recent threads, an idea:

It's a laudable idea, I admit, but most reports are that even when shown evidence of a ticket's validity the gateline staff refuse to believe it and are adamant that they know better, essentially they stick their fingers in their ears and refuse to listen to anything.

It would seem easy to solve this. The process should be to scan any rejected ticket on a handheld device, and this should do two things:

1. Check the encoded restrictions and give a green OK if it would be valid by those.
2. If not, show a YELLOW (not red) screen stating "verify restriction manually" and show the text of the restriction, with a big green "OK" button and a smaller red "not OK" button. If you tap "not OK", there should then be a list of reasons why not which must be selected from. If you select "not valid at this time according to text", then a big reminder should pop up, requiring acknowledgement, stating "Penalty fare/MG11 NOT applicable; issue an excess to customer at difference in fare".
3. Full details of what was selected and who did it must be written to the e-ticket database in so far as that is capable of taking it.

Doing this should be mandatory for all rejected scans and should be audited. If a gateline rejected a ticket and a followup handheld scan was not completed, the staff on that gateline should have to explain why for each instance.

We need to make it hard for people to be lazy. An example of this being done well is the way you have those NFC devices security guards have to tap with their device as they patrol, so it's audited that they have patrolled.

Such a device would not be at all difficult to implement. I could, given the decoding keys for the AZTEC codes and access to write to the e-ticket database, probably knock it up in an afternoon as an app.

You could go one further and have this device have a printer attached and be the way MG11s and PFs are issued; only if "not valid" and a valid reason was selected would it allow an MG11 or PF to be issued, unless "no ticket held at all" was selected.

 

[Gaelan]

Are hand-held CCST readers a thing? The OP in the previous quote couldn’t have had an eTicket, as their journey included tube travel.

 

[Bletchleyite]

Are hand-held CCST readers a thing? The OP in the previous quote couldn’t have had an eTicket, as their journey included tube travel.

They aren't, but CCST probably has no more than a year or two to live. The problem has existed for years, so solving it when we move to 100% e-tickets* isn't too much to ask. (There was a second post where this had happened involving an e-ticket, anyway).

* Before the "but I pay in bushels of wheat at a tent in a farmer's field for my paper Off Peak Return from Cheddington to Reston via Altnabreac" brigade pipe up, e-tickets will also be sold from TVMs and, if they exist, booking offices, for cash. Many already are; bog roll tickets have a barcode and are verified the same way as e-tickets.

 

[Gaelan]

They aren't, but CCST probably has no more than a year or two to live. The problem has existed for years, so solving it when we move to 100% e-tickets* isn't too much to ask. (There was a second post where this had happened involving an e-ticket, anyway).

* Before the "but I pay in bushels of wheat at a tent in a farmer's field for my paper Off Peak Return from Cheddington to Reston via Altnabreac" brigade pipe up, e-tickets will also be sold from TVMs and, if they exist, booking offices, for cash. Many already are; bog roll tickets have a barcode and are verified the same way as e-tickets.

Fair enough (I don’t entirely agree with you about CCSTs, but that’s been done to death).

Beyond that, it’s a good idea, though I’m surprised this happens with eTickets at all - my impression was that the eTicket validity checking was meant to be much more sophisticated.

 

[Bletchleyite]

Beyond that, it’s a good idea, though I’m surprised this happens with eTickets at all - my impression was that the eTicket validity checking was meant to be much more sophisticated.

There are restriction codes (e.g. most of WMT's long distance once) which require manual validation because the text of the code can't be implemented in the data structures provided. Thus there has to be scope for manual validation. E-ticket validation is more involved, but isn't perfect, so we need to provide, and audit the use of, the tools for verifying properly.

 

[Gaelan]

There are restriction codes (e.g. most of WMT's long distance once) which require manual validation because the text of the code can't be implemented in the data structures provided. Thus there has to be scope for manual validation. E-ticket validation is more involved, but isn't perfect, so we need to provide, and audit the use of, the tools for verifying properly.

Yep, no argument there.

 

[LowLevel]

Our e-ticket validation is very dumb, for want of a better word. The user sets the device to "anytime", "off peak" or "super off peak" and anything that doesn't fall within the appropriate category fails the auto check, valid or not. The only way to check the restriction is to look it up manually.

 

[Gaelan]

Our e-ticket validation is very dumb, for want of a better word. The user sets the device to "anytime", "off peak" or "super off peak" and anything that doesn't fall within the appropriate category fails the auto check, valid or not. The only way to check the restriction is to look it up manually.

That's shocking - there's no reason a modern ticket validator shouldn't know what exact train it's on and evaluate the rules with at least the same accuracy as a journey planner.

 

[AlterEgo]

Our e-ticket validation is very dumb, for want of a better word. The user sets the device to "anytime", "off peak" or "super off peak" and anything that doesn't fall within the appropriate category fails the auto check, valid or not. The only way to check the restriction is to look it up manually.

Which, to be fair, is not usually an onerous task, at least for peak and off peak.

 

[Bletchleyite]

That's shocking - there's no reason a modern ticket validator shouldn't know what exact train it's on and evaluate the rules with at least the same accuracy as a journey planner.

Making it do stuff like check routes as a journey planner would might make it a bit slow as it'd need to be done online, but it should certainly be able to evaluate a restriction code in memory.

 

[Gaelan]

Making it do stuff like check routes as a journey planner would might make it a bit slow as it'd need to be done online, but it should certainly be able to evaluate a restriction code in memory.

I don't see why it would? All of the data necessary to evaluate ticket validity (routeing guide, fares database for the restriction codes, timetable or other source of mileages, I think that's it?) is a few hundred MB max and doesn't change more often than nightly.

 

[Haywain]

Would this proposed solution be relying on the published restrictions only, or also using the unpublished electronic restrictions that are needed for journey planners to operate correctly, even thought the latter often impose further restrictions?

 

[Bletchleyite]

Would this proposed solution be relying on the published restrictions only, or also using the unpublished electronic restrictions that are needed for journey planners to operate correctly, even thought the latter often impose further restrictions?

It would use the electronic restrictions, which is why it would never say "not valid" nor use the colour red, but if the electronic restrictions don't match then instead it would display yellow "please check" and the text of the restriction code for viewing.

Though really we should have a programme of sorting out unimplementable restriction codes. They generally only happen because TOCs are lazy, e.g. WMT using one code for all long distance off peaks/super off peaks rather than having one per group of origin stations.

 

[Haywain]

Though really we should have a programme of sorting out unimplementable restriction codes. They generally only happen because TOCs are lazy, e.g. WMT using one code for all long distance off peaks/super off peaks rather than having one per group of origin stations.

This gets closer to the root of the problem. If the ticketing is too complex, then the restrictions are even worse. Many restriction codes are almost incomprehensible and contain apparent conflicts. Without reforming that there is no hope for an IT based solution to be effective.

 

[Bletchleyite]

This gets closer to the root of the problem. If the ticketing is too complex, then the restrictions are even worse. Many restriction codes are almost incomprehensible and contain apparent conflicts. Without reforming that there is no hope for an IT based solution to be effective.

I don't wholly agree with the latter point, because perfection is the enemy of the good. The situation now is unacceptable; a decent IT based option that can give a green if it's definitely OK and shove the restriction text in the RPI's face if it's maybe not would be a major disincentive to being lazy about it.

On the original point, there does need to be a setting on the restriction code database for "ignore changes of train; only apply to the first train boarded" because that would sort out all those WMT ones without the need to have lots. But I bet WMT don't care because they're raking it in by selling higher priced tickets incorrectly.

 

[Haywain]

I don't wholly agree with the latter point, because perfection is the enemy of the good.

I'm not suggesting perfection, just wholesale improvement.

 

[LowLevel]

Which, to be fair, is not usually an onerous task, at least for peak and off peak.

In theory not, though we do have some odd restrictions and you have to use a different app to do so, so you have to check what the ticket type is, direction etc from the interface. I've got a few routes whereby some off peak tickets are valid all day and others just a few stations apart aren't.

 

[AlterEgo]

In theory not, though we do have some odd restrictions and you have to use a different app to do so, so you have to check what the ticket type is, direction etc from the interface. I've got a few routes whereby some off peak tickets are valid all day and others just a few stations apart aren't.

Do you mean the e-ticket interface? I would just look up the restriction code online, it's always nationalrail.co.uk/ (whatever the two character restriction is)

 

[LowLevel]

Do you mean the e-ticket interface? I would just look up the restriction code online, it's always nationalrail.co.uk/ (whatever the two character restriction is)

I use the mobile TIS, it's quicker than trying to go online as the restriction data is all accessible offline and I work in a lot of rural areas.

This fare https://www.brfares.com/!faredetail?orig=NOT&dest=CBG&rte=700&tkt=SSR is a particular favourite to try and catch unwary people out

Note how the published restrictions and unpublished restrictions are rather different.

 

[Gaelan]

Do you mean the e-ticket interface? I would just look up the restriction code online, it's always nationalrail.co.uk/ (whatever the two character restriction is)

Or nre.co.uk/, if you want to save on typing.

 

[py_megapixel]

If a gateline rejected a ticket and a followup handheld scan was not completed, the staff on that gateline should have to explain why for each instance.

Not sure I agree with this bit as staff don't have control over what is being scanned at the gateline. For example, someone might accidentally scan a ticket they've bought in advance for a future date, then when it's rejected, realise their error and scan the correct one, all without the staff even noticing anything is wrong, let alone manually inspecting the ticket.