There has been much debated discussions about this subject earlier, whether to save or not to save unpaid itinerary. And I have seen people passing with both the options. So I think we can use any of the options, provided we justify it in our document.
Now, I am planning to save unpaid itineraries also. The reason is because of one line ".. system presents a list of itineraries..". As mentioned in previous threads, we can store the itineraries in the session. But it doesn't make much sense to think that the user creates a number of itineraries in one single session, and then goes over and starts changing it. BUT the customer can create itineraries for a period of time (I mean say for the next 6 months), and then get the stored information and change it at a later stage.
The concerns here are : the availablity of seats, price changes and flight schedule changes. But since the change itinerary calls the prepare itinerary again.. it still goes through the whole process again.. and checks for validity.
Are there any other major intricacy in following this approach ??? Your valuable thoughts guys ...
It makes sense in one way to save the itineraries for the session time because a customer can buy several itineraries in one session. for instance, my company bought me several flight tickets for doing a series of profesional trips during a month. So you can imagine the user, preparing several itineraries and then buy all or part of them.
As you said, it does not make more sense from the practical point of view, to build trips and come later on to be informed that the flights have changed and the trip is not available anymore.
as you also said, both approachs are correct. The only thing you have to do is state this and clearly tell why you model this that way.
Giju I also though about this a lot and changed my decision few times. But now i have decided, it does no make sense to save unpaid itineraray. Reasons 1. You save unpaid. Next time user comes to pay, you would again have to check the seat availability. 2. If you are thinking that user would select seat nos , than that option has to be given again. Because seat might be available but not that nos. 3. If you save, till what time it would be valid 4. After validity expires, it has to be cleaned.
Practically, until and unless money comes in.. no seat bookings. You could have, Emirate Airlines does that but then all the business rules come in. Hence keep it simple, no saving unpaid Vinay
Vinays, I have seen the emirates site where it stores unpaid itinerary.
I agree with you guys, and it's also an overkill on the server to save unpaid itineraries.
But my question revolves around the change itinerary... "customer or travel agent searches for an itinerary..... ". From a travel agent's point of view, it's fine because the TA deals with diff customers, hence diff itineraries. But think about from the customer's point of view. do you think the customer creates different itineraries in ONE SINGLE session, then the system searches through it and "...present a list of itineraries.."?. All these should happen in one single session ?. If there wasn't a change itinerary, I would NOT have stores the unpaid itinerary. It would be like a "search-buy-go" scenario.
I think like this :- prepare itinerary happens in one session, and change itinerary happens sometimes later( after a couple of hours/days/months)
And for saving unpaid itineraries, what if the seats are not saved. The basic idea is to search for flights for a particular date and create diff segments. The seats and prices are the only concerns, but change itinerary still calls prepare itinerary.. so the validations can be done there. As Tery mentioned about flight changes.... hm.. then it's going to affect all customers who booked x days/months before.
Think about a scenario..ALL HAPPENING IN ONE SINGLE SESSION :- you are searching for flights to Travel from A-B-C and back, after creating the itinerary, then you realize it should be A-X-C. I would rather use the back button OR may even start the prepare itinerary again... rather than selecting change itinerary from menu (as given in change itinerary use case). And also the requirements mentions about "searching/displaying list of iteneraries".
And for how long to store itineraries... hm..
Well...anyway, I think both options are right provided you correctly justify in the document. So there's no point in arguing it. Thanx for the feedback guys !!!
May be I need a bit more thought to come to a conclusion..