Error or Change? LAN-EUS offpeak

[andersoi]

Normally the first offpeak service is the 0741, however just looking, it's offering both the 0638 and 0513 as offpeak returns? Someone ballsed up or a change?

 

[Tazi Hupefi]

Not valid to arrive at Euston before 09:05 - you'll encounter problems using the ticket - but if it actually allows you to book it, you're entitled to rely on the itinerary provided.

 

[_toommm_]

This is the relevant fare on BRFares:

Look up fares for any train journey in Britain

Full details of all British rail Single, Return & Season tickets and Travelcards. Built-in Season Ticket Calculator.

www.brfares.com

I understand it being valid on the 06:38, as it's valid on trains arriving into London terminals after 09:05. I can't understand it being valid on the 05:13, although if you bought it, it would become de-facto valid on the itinerary as Avanti are saying it is at the time of purchase.

 

[andersoi]

That's what I'm thinking too, it's arrive at EUS before 1005 and depart EUS 0905 which is why it's thrown me... 0741 is my usual and was expecting to have to get the lube out for the more expensive one to travel earlier.

The Forum ticketing site will also sell it to me as an offpeak rtn, but trainline will not show any returns, so something strange is going on...

 

[Snow1964]

Wonder if it is a quirk of database if ticket is bought to Euston (a specific station) or to London Terminals

restriction 3A is not valid into Euston 04:29 to 10:05 and return not departing Euston 04:29 to 09:05

Looks like Friday is excluded from restriction, perhaps Tuesday has been excluded too

 

[andersoi]

good shout - but forum ticketing does the same if I do the destination as EUS

 

[Benjwri]

It looks to me like someone might’ve forgotten to attach any machine readable restrictions to that code…

 

[alex17595]

When you search all the fares on BRfares the restriction code shows up as red. any ideas why?

 

[MrJeeves]

When you search all the fares on BRfares the restriction code shows up as red. any ideas why?

There is no electronic information for it, meaning journey planners have no data to determine whether a journey is permitted with that ticket.

That specific red bit means there is no description for the restriction code, if you compare it to the VZ one above.



== Doublepost prevention - post automatically merged: 11 Jul 2024 ==

This also applies to 9I, which is London to places on WCML.



== Doublepost prevention - post automatically merged: 11 Jul 2024 ==

...and 2R


== Doublepost prevention - post automatically merged: 11 Jul 2024 ==

Seems at least some of the affected restrictions have been updated with new Christmas easements but the ones that aren't affected (e.g., 2C) have last year's easements. Perhaps an error was made during this process?

 

[Adam Williams]

Here's a novel idea: validation in PMS so that it's actually impossible to have records enter a state where a fare on a flow has a restriction code without associated machine-readable data.

The questions shouldn't be about the poor person who managed to cause this mess - Why is it possible for a pricing manager to do this in the first place?

While we're at it:

• Validation to ensure every FTOT is mapped in the reservations system for timetabled, reservable services
• Basic sanity checks to ensure timetabled services don't accidentally get deleted en-masse
• Basic sanity checks to ensure some seats are marked as window seats and some are marked as aisle seats within a carriage (or a written reason is provided as to why not)
• The Retail Control Service that specifies E-Ticketability: missing flows, missing ticket types, missing licensees. Usually entirely unintentionally!

We see this all over the place in the industry, e.g. the easements in the electronic routeing guide that end up having no effect because of human error (specifying a completely wrong route code) or a completely different effect than intended.

There really need to be investments in initiatives that improve data integrity and quality across the board. These should start with electronic logic to actually enforce data integrity.

 

[Mike395]

Here's a novel idea: validation in PMS so that it's actually impossible to have records enter a state where a fare on a flow has a restriction code without associated machine-readable data.

The questions shouldn't be about the poor person who managed to cause this mess - Why is it possible for a pricing manager to do this in the first place?

While we're at it:

• Validation to ensure every FTOT is mapped in the reservations system for timetabled, reservable services
• Basic sanity checks to ensure timetabled services don't accidentally get deleted en-masse
• Basic sanity checks to ensure some seats are marked as window seats and some are marked as aisle seats within a carriage (or a written reason is provided as to why not)
• The Retail Control Service that specifies E-Ticketability: missing flows, missing ticket types, missing licensees. Usually entirely unintentionally!

We see this all over the place in the industry, e.g. the easements in the electronic routeing guide that end up having no effect because of human error (specifying a completely wrong route code) or a completely different effect than intended.

There really need to be investments in initiatives that improve data integrity and quality across the board. These should start with electronic logic to actually enforce data integrity.

Exactly this. At the very least, there should be an automated check that flags major changes to electronic restrictions, details exactly what is being applied and forces an override if someone wants to go ahead with them.

 

[Gaelan]

We see this all over the place in the industry, e.g. the easements in the electronic routeing guide that end up having no effect because of human error (specifying a completely wrong route code) or a completely different effect than intended.

It seems to me there should be something akin to unit tests - a list of journeys that should (and should not be) valid, with new test cases added as part of any change to the routeing guide. This would allow them to verify both that their change causes the intended change in validity, and that it has no unintended side-effects.

 

[yorkie]

Normally the first offpeak service is the 0741, however just looking, it's offering both the 0638 and 0513 as offpeak returns? Someone ballsed up or a change?

View attachment 161583

Book it now, obtain a reservation and itinerary; this is contractually binding.

 

[andersoi]

Book it now, obtain a reservation and itinerary; this is contractually binding.

this is exactly what I've done, thanks all

 

[MrJeeves]

All the restriction data seems to have re-appeared today.

If anyone has bought one (or more!) of these tickets, I would expect some push back from staff during ticket checks.

E-Tickets will be easier to argue as their itinerary is both shown on the ticket and embedded within the barcode.

If anyone does have issues, I'd personally recommend paying the excess fare and claiming it back from TOC customer services afterwards. This is typically the easier way to reduce conflict.