• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

unpaid itinerary

 
Ranch Hand
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

(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
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 446
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 463
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
All,

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

Thanks you.

-Ravi
 
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
machines help you to do more, but experience less. Experience this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic