• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Clarification about paying and changing

 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ranchers,

A probably trivial question for you, but I'm not too sure how to understand the paying and changing processes. As far as I understand the PrepareItinerary use case, as soon as your mind is made up on an itinerary, the pay use case is invoked, which would mean that instead of having a shopping cart and proceeding to check out whenever you feel like it, you are immediately taken to the check out (taken from prepare use case, end of Basic Flow: "System sends the priced itinerary to Pay for Itinerary Use Case"). In this case, the itinerary is immediately paid (unless the payment is not authorised). I don't see as an aternative flow the possibility to carry on browsing by deferring the payment time once an itinerary is selected. Am I missing something?

This would imply the following:
- no need for a shopping cart
- when you change itinerary, the change applies to an itinerary that has already been paid. how payments are reconciled? Because it is one thing to delete the segment from the itinerary, but what becomes of the corresponding payment that was debited from the card?

But at the same time, why is not the Pay use case an inclusion of pricing use case (user can invoke it as standonle according to global use case diagram)?

Could somebody please clarify a bit these points? Xavier

Many thanks,
 
Xavier Fabreguettes
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to confirm, I woul rather use a cart to store all pending itienraries and have a cehckout screen or a pay screen where you can pay for everything in your cart. Once payment made, the cart should be emptied. The only problem is that, the way I read the use cases, payment seems to be triggered immediately after an itinerary is prepared. At the same time, the pay use case seems to be available to users directly (not as an inclusion of amother use case).

In addition, how a change is triggered? What do you apply it on? It only makes sense if you have a cart with pending (unpaid) itineraries...
What should happen to bookings once they are paid for? Should they will accessible to users? (will be accessible of course for reporting and maybe if an history page is added to the site). IMO no, but happy to discuss.

Thanks,

Xavier
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic