aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes unpaid itinerary Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "unpaid itinerary" Watch "unpaid itinerary" New topic
Author

unpaid itinerary

Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
What do we do with unpaid itineray.
Many airline systems give u the option to reserve unpaid itinerary and have it paid later.
nothing is mentioned about the unpaid itineray.
Can we take the simplest path by making assumptions about whats to be done about unpaid itinerary.
Thanks
Dhiren
Mark Egloff
Ranch Hand

Joined: Dec 30, 2004
Posts: 30
Dhiren

This is something were you have to do an assumption. For myself I am going to do a statment in my documentation that this will be kept in the sessioncontext and only be stored if the pay was successful.

search this forum for this kind of topic, you will see , other did the same decisions.

May be , someone others could tell us their suggestions?

regards
Mark
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
I do not think stating this assumption solves the problem.

How will you address the Credit Card Issue? For example:

(a) If you authorize the Credit Card first and then try to save the itinerary which fails because "seat" is no more available then you will have to void the credit card transaction.

(b) If you store the itinerary and then do the credit card transaction, which does not go thru then you have to roll back the itinerary freeing up the seat.

I feel the architecture/proposed design should address the problem in hand, atleast to some extent.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
(a) If you authorize the Credit Card first and then try to save the itinerary which fails because "seat" is no more available then you will have to void the credit card transaction.

First u can try the reservation of the seat if that seat is already taken u dont even need to do the payment processing..

(b) If you store the itinerary and then do the credit card transaction, which does not go thru then you have to roll back the itinerary freeing up the seat.
I feel the architecture/proposed design should address the problem in hand, atleast to some extent.

Infact ,if unpaid itinerary is stored, then a itinerary may not even be paid for yet it holds up unpaid reserved seats. Most airlines hold your seats for upto a week 2 weeks before actual departure. U may not want to create all this complications and keep it simple. I took the airline path holding on to unpaid reserved seats and leaving the implementer the option to free up those itinerary seats if payment doesnt come in. It is complicated doing the removal impl with architecture objects so I left it for implementation details.
Thanks
Dhiren
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
Dhiren,

What do you think about the following scenario:

What is the main purpose of the Change Itinerary use case ?
(a) Allow the user to make changes to paid itinerary OR
(b) Allow the user to make changes to unpaid itinerary.

If the purpose is to allow the user to make changes to unpaid itinerary, then we do not have a choice. It is implied that unpaid itineraries will be saved in the database. The use case states that user will first select the itinerary and the segment within it.

If the purpose is to allow the user to make changes to paid itinerary, then in our credit card (and FFM) transactions, we need to show somekind of debit/credit transaction posting.

regards,
Deepak
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463

What do you think about the following scenario:
What is the main purpose of the Change Itinerary use case ?
(a) Allow the user to make changes to paid itinerary OR
(b) Allow the user to make changes to unpaid itinerary.


Only unpaid.
In practial applications, unpaid itinerary persists for some time like almost 2 weeks b4 the real flight.like I said b4, only persisting paid itinerary would keep it simple make assumptions for what u would like to implement.


If the purpose is to allow the user to make changes to unpaid itinerary, then we do not have a choice. It is implied that unpaid itineraries will be saved in the database. The use case states that user will first select the itinerary and the segment within it.


User is allowed to make changes as long as he hasnt paid for it and you could put a clause provided the user is remaining in that session. U wouldnt want to persist data for a user who may never pay for the itinerary. That would be a unnecessary overhead for the architecture design to add the cleanup for unpaid itineray. U could add the flexibility in your design for implementors to add it in. u neednt persist the unpaid itinerary but save it to a shopping cart.


If the purpose is to allow the user to make changes to paid itinerary, then in our credit card (and FFM) transactions, we need to show somekind of debit/credit transaction posting.


Also paid itinerary cannot be changed its generally not there in some airline bookings.

Please give your thoughts.

Thanks
Dhiren
Deepak Pant
Ranch Hand

Joined: Feb 13, 2004
Posts: 443
I agree that we should not allow changes to paid itinerary.

But I think we need to provide some provision for saving unpaid itinerary because the "Change Itinerary" use case clearly says that the system presents a list of itineraries, the customer selects the itinerary to change, system returns the selected itinerary, which includes each segment of the itinerary.

To meet this business workflow, there has to be something coming from the database. Correct ?

How can a customer have so many unpaid itineraries in the session?

I think the options are:

(a) Change Itineray use case will allow changes to the current itinerary being prepared.

(b) It will also allow changes to the paid itinerary.

(c) and since unpaid itineraries are not saved in the database so no changes can be done if customer leaves the application before paying for it.
Dhiren Joshi
Ranch Hand

Joined: Dec 09, 2003
Posts: 463
But I think we need to provide some provision for saving unpaid itinerary because the "Change Itinerary" use case clearly says that the system presents a list of itineraries, the customer selects the itinerary to change, system returns the selected itinerary, which includes each segment of the itinerary.

Yeah it can be assumed that its the itineraries created by the customer per session for simplicity. The option can be as implementation details instead of architecting it.


(a) Change Itineray use case will allow changes to the current itinerary being prepared.

Yeah that works.


(b) It will also allow changes to the paid itinerary.


I am not sure about this implementation.



(c) and since unpaid itineraries are not saved in the database so no changes can be done if customer leaves the application before paying for it.


Correct.

But I think we need to provide some provision for saving unpaid itinerary because the "Change Itinerary" use case clearly says that the system presents a list of itineraries, the customer selects the itinerary to change, system returns the selected itinerary, which includes each segment of the itinerary.


So I am confused about the issue where u are concerned about persisting unpaid itinerary to DB.

HTH
Dhiren
Ravi Dhanum
Ranch Hand

Joined: Feb 27, 2005
Posts: 46
All,

Under what situations can an unpaid itinerary exist? Is it only if the payment has failed?

Thanks you.

-Ravi
Josep Andreas
Ranch Hand

Joined: Jan 09, 2005
Posts: 90
Ravi,
It all depends on when you persist the itinerary.
You will have to make a choice whether you want to persist unpaid Itineraries or not.
In the requirements, you will not find a clear answer.
Make an assumption and stick with it.
regards,
J
[ February 28, 2005: Message edited by: Josep Andreas ]
Ravi Dhanum
Ranch Hand

Joined: Feb 27, 2005
Posts: 46
Josef,

I see what you mean, except... Do you know how a customer can select award travel for an unpaid itinerary? Let's say that I decide to save the itinerary after the customer has chosen a seat. The system will still continue by paying for the itinerary. I don't see where there is a break in the flow from the time an itinerary is created until it is paid for. So, the question is:

How can a customer select award travel for an unpaid itinerary?

Thanks again.

-Ravi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: unpaid itinerary