eVouchers expiring

[saxman]

I have a couple eVouchers expiring this month, but I don't have any trips planned in the near future. Obviously I need to book something and always thought I could book something and then later cancel it and that would "renew" the evoucher for another year. But I had an agent on the phone yesterday tell me that I could book something using the voucher for any time, but since it's past a year, I would forfeit those funds if I changed it again. Huh? I didn't think it was right. So I booked a random trip worth $28 using part of the funds, and then immediately canceled it. Turns out I was right. It created a totally new voucher number worth $28, and it said it expired one year from yesterday. But now I'm skeptical. I'm afraid this might be a bug and if I book some random trip worth $300, I won't be able to change it. Then again, I know how some agents are at not know the policies well.

 

[neroden]

You're correct. This has in fact always been the way it worked, but more importantly, this is how the computer system is implemented. If you do it online, it will work this way *consistently*.

 

[Cho Cho Charlie]

Amtrak doesn't keep track that the form of payment was a voucher, and with that, the original date of expiration?

 

[neroden]

Amtrak doesn't keep track that the form of payment was a voucher, and with that, the original date of expiration?

Think how complicated that would be to program.

 

[Devil's Advocate]

I have a couple eVouchers expiring this month, but I don't have any trips planned in the near future. Obviously I need to book something and always thought I could book something and then later cancel it and that would "renew" the evoucher for another year. But I had an agent on the phone yesterday tell me that I could book something using the voucher for any time, but since it's past a year, I would forfeit those funds if I changed it again. Huh? I didn't think it was right. So I booked a random trip worth $28 using part of the funds, and then immediately canceled it. Turns out I was right. It created a totally new voucher number worth $28, and it said it expired one year from yesterday. But now I'm skeptical. I'm afraid this might be a bug and if I book some random trip worth $300, I won't be able to change it. Then again, I know how some agents are at not know the policies well.

I'm not sure that's a true test to be honest. To be absolutely sure I'd probably leave a new ticket overnight in order to ensure any after-hours interfaces and processing tasks have time to record and analyze your changes before cancelling.

Amtrak doesn't keep track that the form of payment was a voucher, and with that, the original date of expiration?

Think how complicated that would be to program.

Why would it be complicated? I realize that Amtrak uses a lot of older code for some of their core systems but I doubt ARROW is being tasked with generating and tracking electronic vouchers. If implemented properly only one relatively modern system should own the issuing and tracking of parent documents and adjusted date fields. These are common concepts in enterprise systems today so it's doubtful they would require much in the way of original code to be implemented. It could even be as simple as assigning some additional fields and properties at the process workflow level before modifying some interfaces and reports to ensure they are aware of the changes. The time and money saved from ensuring every replacement voucher's expiration was tied to the original issue date should be able to pay for the time spent making the changes.

 

[neroden]

Amtrak's policy for years has been "you can go into an office and get your voucher reissued for a new voucher". There was no reason to change it when making e-Vouchers, and it is *way* less complicated to program.

Remember that you can buy a ticket using a combination of an arbitrarily large number of different vouchers and cash. Do you want to track the ticket payment using a gazillion different fields, or just sort it into "refundable" and "non-refundable"? I can betcha what the Amtrak programmers did.

The expirations are really designed to catch people who don't plan to ride Amtrak again, not for people who do intend to ride Amtrak eventually.

 

[Devil's Advocate]

Amtrak's policy for years has been "you can go into an office and get your voucher reissued for a new voucher".

Policies change. Rules change. Interpretations change. Workflows change. Inertia is not a policy.

There was no reason to change it when making e-Vouchers, and it is *way* less complicated to program.

I can think of several reasons to change it.

Resolving undelivered services rather than carrying indefinitely.

Clearing unresolved obligations on a regular and knowable basis.

Improving financial and operational reporting and analysis.

Creating a definable window for financial audits and legal holds.

Remember that you can buy a ticket using a combination of an arbitrarily large number of different vouchers and cash. Do you want to track the ticket payment using a gazillion different fields, or just sort it into "refundable" and "non-refundable"? I can betcha what the Amtrak programmers did.

Creating, tracking, and comparing adjusted expiration dates across multiple child documents is exactly the sort of remedial and repetitive task that computers were designed to make simple and easy. Sometimes available resources and competing network traffic mean such tasks may not always be processed in real time, but they are neither difficult or complicated to identify and implement. Tedious perhaps, but that's life in the IT field.

The expirations are really designed to catch people who don't plan to ride Amtrak again, not for people who do intend to ride Amtrak eventually.

Determining something as vague and unknowable as human intention is precisely the sort of problem that programmers would find exceedingly difficult to isolate and computers would struggle to analyze and process into useful information.

 

[neroden]

You've obviously never done a programming job. If the exceedingly complicated tracking wasn't specificied specifically as a deliverable, the programmers would not implement it.

 

[Devil's Advocate]

You've obviously never done a programming job. If the exceedingly complicated tracking wasn't specificied specifically as a deliverable, the programmers would not implement it.

I never claimed I was a programmer. I simply asked what you thought was so complicated about such a modification. My original inquiry had nothing to do with business policies or identifying customer impact factors or statements of work or project deliverables or scope creep or whatever the next unrelated tangent may be. This isn't intended to be a pissing match between software programmers and technical administrators. It's just a simple question about what you see as the architectural impediments and stumbling blocks.

 

[saxman]

Well I just booked a trip using all the of voucher ($300+) in January that I think I might take. I'll let it sit overnight, but I don't think letting it sit overnight will change anything. The most frustrating thing is that I can no longer access my vouchers on my profile anymore. It's been this way for months. I click display vouchers and it simply says Error: Email address is not correct. I can type in the actual voucher number, which I have to keep track of now. I've talked to Amtrak IT twice and they haven't seemed to fix it either. It's very frustrating.

 

[neroden]

Well, DA, I'll just say that it's a lot more complicated to program something which tracks the origin of multiple "bundles" of money and keeps a separate record for the expiration date of each, than it is to simply program "refundable"/"nonrefundable". Lot more code.

Since I've actually done a lot of programming in my time, you can trust me on this.

If Amtrak execs asked for and paid for the complicated tracking, the programmers would do it. If they didn't ask for it, the programmers wouldn't do it.