Pricing - Journey pricing

Journey pricing is a pricing schema used to set special prices for specific O&D’s, that require dynamism using the different parameters that the configuration offers.

When a reservation product is set to use Journey Prices, the system will only look for JP records. No fare tables are used for this pricing method. However, you are required to fill a Proration table, available in the routes page.

The Proration Table is used to properly calculate taxes on connecting trips that might go through provinces or zones with different tax rates.

JP parameters can be fare type, fare classes, product type, ticket selling periods, currency type, advance purchase windows, load factor, amenity group, shift zone, and even same-day round-trip ticket discounts.

• Navigate to admin>pricing

• journey pricing

List Journey prices records.

You can filter records by almost all the fields in the JP chart.

The most commonly used filters are:

General filters

• Product
• Fare class
• Seat class (if the account had)
• Origin
• Destination
• Fare type: Depending on how many fare types you have configured, multiple fare types can be selected.

Price filters

• Regular price: The figure entered in the regular price column of the CSV Bulk Upload template. (This is only used for reference, reporting purposes and is not used to calculate prices)
• Price: The figure entered in the price column of the CSV Bulk Upload template that will be displayed in the trip results.
• Round trip adjustment: Here either a $, %, or $ override figure can be selected over a range of prices.
• Same-day round trip adjustment: Here either a $, %, or $ override figure can be selected over a range of prices.

Currencies

If the account is multicurrency enabled then all of the different available currencies in the account will have a filter options.

Trip filters

• Brands
• Amenity groups
• Schedules: It is possible to select multiple schedules. Schedules can be in the include or exclude column
• Load factor: By range of load factor.
• Tickets per manifest: By range of tickets per manifest.

Travelling, purchase dates

• Earliest travel date: By date and time.
• Latest travel date: By date and time.
• Earliest purchase date: By date and time.
• Latest purchase date: By date and time.
• Advanced purchase: By range of hours.
• Day of the Week: By day(s) of the week.

Loyalty

• Loyalty points to accumulate: By pricing rule over a range of points accumulated.
• Loyalty points for redemption: By pricing rule over a range of points redeemed.

Sales channels/locations

• Shift Zone: All shift zones applied at the station level in the account will appear for selection/deselection.
• Channels: By back-office, agency back-office, websales, and agency websales pricing rules.

Audit, external fields

• External Field 1, 2, or 3: By external field(s) applied to a rule.
• Created from: By the date that the rule was created.
• Created to: Rules created until a particular date.
• Created by: Rules created by a specific user.
• Updated by:Rules updated by a specific user.

Working with the list

Once you click the Apply the filters button, a list of results will show up.

The filters will be hidden to preserve space.

Some buttons are visible to be able to manage the rules.

1. You can add a new rule manually
2. You can download the records using the download button.
3. You can open the filters again using the filters button.
4. You can refresh the results using the refresh button.
5. You can order the rules by weight, ordering the list of rules from highest to lowest.

Rules weighting for pricing

When someone searches for trips, and you’re using Journey Pricing, a price is selected for each trip using the following logic:

1. All journey pricing rules that do not match the trip are filtered out (ie. if a rule applies only to one specific Fare Class, but that Fare Class is not present in the trip result, it will be filtered out).
2. From the rules that remain, only the rules with the highest “weight” are selected.
3. From the rules that remain, only the rules that apply to the appropriate currency are selected. Rules that have the same currency as the trip search are preferred, and if none are available, the system may choose rules that are in your account’s base currency.
4. Finally, if there is more than one rule remaining after all of the previous steps, the rule that was created most recently is selected, and the price from this rule is applied to the trip.
5. The “weight” of a rule is assigned when the rule is first created (via our API or via CSV upload). A very generic rule that does not target any specific Product, Fare Class, Fare etc. will have the lowest possible weight of 0. As the rule becomes more specific, and more parameters are set, the weight of the rule will increase.
6. Each parameter of the rule has a different level of importance that is considered when calculating the weight.
7. In case of multircurrency accounts, rules with lower weight will be filtered out regardless of the currency. It is recommended to make sure the high weight rules are defined in all available currencies, so the expected price is pulled. If a high weight rule is only defined in one currency, then the exchange rate will be used when requesting the price in a different currency.

Journey price version id

Every Journey Pricing rule will have an accompanying Journey price version id.

The version ID is different from the actual JP ID. A ner version ID is generated when an existing JP record is updated using the CSV file.

There are a few different locations in which one can find the Journey price version id.

• Ticket details page
• Tickets report

Examples of Journey Pricing rules

Use Case Example

Add and configure prices according to need.

The following examples will be based on the configuration shown in the image above

One-way

Go to the section “Price” to add an amount established.

When purchasing a one-way ticket, the system will take the price entered in the column “Price” in the configuration box for each O&D

Roundtrip

Go to the section “Roundtrip adjustment” to add an amount established to be added or subtracted from the "Price" column.

Always remember to add a "-" when adding an amount to be subtracted from the price; and a "+" or just the amount when you want to add.

• (in the example, we have added amounts that will be subtracted from the original price)

1. Trip A to B has a roundtrip adjustment amount, but trip B to A doesn't. Just trip A to B has an adjustment on the price.
2. Trip B to A has a roundtrip adjustment amount, but trip A to B doesn't. Just trip B to A has an adjustment on the price.
3. Both trips A to B and B to A have a roundtrip adjustment amount. Both trips have adjustments to their prices.

• If there is no “Roundtrip adjustments” configured, it will just take the price from the “Price” column.
• If there is no “Roundtrip adjustment” configured on any of the trips, but there is a “SAME DAY Roundtrip adjustment”, “SAME DAY Roundtrip adjustment” won’t affect the final price.

Same Day Roundtrip

If the return trip is going to be on the same day, it is also possible to add a special price.

Go to the section “SAME DAY Roundtrip adjustment” to add an amount established to be added or subtracted from the "Price" column.

Always remember to add a "-" when adding an amount to be subtracted from the price; and a "+" or just the amount when you want to add.

• (in the example, we have added amounts that will be subtracted from the original price)

1. Trip A to B has a same-day roundtrip adjustment amount, but trip B to A doesn't. Just trip A to B has an adjustment on the price.
2. Trip B to A has a same-day roundtrip adjustment amount, but trip A to B doesn't. Just trip B to A has an adjustment on the price.
3. Both trips A to B and B to A have a same-day roundtrip adjustment amount. Both trips have adjustments to their prices.

• If there is no “SAME DAY roundtrip adjustments” configured, it will just take the price from the “Price” column.
• If there is no “SAME DAY Roundtrip adjustments” configured on any of the trips, but there are “Roundtrip adjustments”, regardless of whether the trips are on the same day, the adjustments will be applied.

There might be also cases where Rountrip and Same day rountrip prices can be combined:

1. Trip A to B has a same-day roundtrip adjustment amoun, and trip B to A has a roundtrip adjustment amount configured. Both adjustments were made in the corresponding trip.
2. Trip A to B has a roundtrip adjustment amount, and trip B to A has a same-day roundtrip adjustment amount configured. Both adjustments were made in the corresponding trip

• If there is no “SAME DAY Roundtrip adjustments” configured on any of the trips, but there are “Roundtrip adjustments”, regardless of whether the trips are on the same day, the adjustments will be applied.

Rountrip price from product line configuration:

• If there is also any adjustment on the “Roundtrip” price from the Product line configuration, it will be applied to the final price in the sales flow in all scenarios listed above:

Open Return

When purchasing an Open return ticket (already configured and linked to the reservation product), the system will take the price entered in the column"Open return price” in the configuration box.

1. Trip A to B has an open return price, and trip B to A has another one. When using the open return feature, the return trip will take the trip A to B open return price.
2. Trip B to A has an open return price, and trip A to B doesn’t. When using the open return feature, the return trip will take the trip B to A open return price.
3. Trip A to B has an open return price, and trip B to A doesn’t. When using the open return feature, the return trip will take the trip A to B open return price.

If the JP record for the reservation part does not has an openReturnPrice, we will load the JP record that matches the O & D for the return and we will check if that record has an openReturnPrice. If it does we will use that price (without applying any fare type discount in this case). If there are several JP records where the O & D match, then the lowest price will be used.

If we can't find any record with the openReturnPrice. The purchase can't be completed.

Tickets per manifest

This parameter limits the amount of tickets you can purchase per manifest. The use case for which this was designed is to limit the amount of tickets on different sales channels. For example, you can set up a different JP rule to limit 3 tickets for a certain Fare Type and then assign this fare type to agencies, so that most of your tickets can be sold thorugh your internal points of sales.

It is not recommended to use this parameter to set up different pricing in the same channel, as this does not affect weight, and you may face unexpected behaviors.