Pricing flights and Pricing itineraries

[Jonathan Gerrish]

Hi all,

The prepare usecase returns PRICED flight options which the user chooses, and which are then added to the itinerary.

Then the price itinerary use case "calculates the price of each segment of the selected itinerary and returns the priced itinerary, or calculates the changed segment of the itinerary and returns the additional payment"

So it seems that there is a re-price here (typical for an IBE since prices may change from when the flights were chosen and when they are booked, especially if you can save an itinerary and leave it several days before actually booking it)

Anyway, the alternative usecase seems a little unusual, in that the system has to know which segment has changed and then "returns the additional payment", so it doesn't say, new total or anything like that.

I suppose that pricing the itinerary, could be as simple as summing up the priced flights in the itinerary, without actually performing the pricing/fare logic.

How have others interpreted these requirements?

Cheers, Jon

[shankar sawant]

As per the requirements, after the segment is changed (segment is actually deleted in order to add new one) the prepare Itinerary is executed. So all the steps carried by Prepare Itinerary will be executed.

This includes search, price the whole itinerary again and selecting seats etc.

So IMO, We can safely make assumption that only unpaid itinerary can be modified and price and seat availability will be calculated for all parts of the itinerary again because user has still not confirmed the itinerary and has still not paid for the itinerary. So its like new prepare Itinerary based on the current rates and availability.

Any different thoughts on this?

[Willy George]

Interview with the CEO says "the flat price is per destination, but it does not matter when you purchase the ticket. So the person who purchases the ticket two weeks before the flight will pay the same as the person who walks up right before the flight takes off."

[Jonathan Gerrish]

Yep, pricing never changes over time, so the re-pricing is kind of useless in the business model of FBN. Still, those are the requirements so thats what we have to do.

I also agree with the assumption that when performing price itinerary regardless of whether its on a new itinerary, or a changed itinerary that the re-pricing should be performed on all segments, it makes more logical sense, it just goes against the requirement that "system calculates the changed segment... and returns the aditional payment"

[Andy Malakov]

My two points:

System knows if customer paid and how much, right? Price Itinerary usecase calculates new total for changed itinerary. Delta is "additional payment".

Solution should be extensible. Imagine that one day customer will decide to implement different pricing policy. Ideally system should be designend to minimize impact of such changes.

Thanks,
Andy

[Jonathan Gerrish]

Hi Andy,

Actually, I think I missed something. I was assuming that "Change Itinerary" was working on an existing pre-saved, but UNPAID itinerary (I assumed this because the post-condition is an unpaid itinerary).

But I think this is not true, that the change itinerary starts with a previously paid itinerary, and presumably charges/refunds the differrence.

Can you confirm that this is your understanding also?

You are also right about extensibility, I have made this a consideration of my design.

Thanks, Jonathan.