Pricing & Availability

The availability and price of a product is computed at runtime from a combination of the AvailabilityPattern, StartTime & AvailabilityType

The following tables are defined in the entity domain:

• SupplierPriceCategory - ie Adult, Child etc with age limits and separate prices

• Occupancy - We need to know if a booked pax type reduces the availability (ie infants may not)

• SupplierSeason - We need to hold prices for fixed date ranges - start and end date

• ProductStartTime - Defines the possible start times and durations for a product. A ProductAvailabilityPattern may apply to any or all start times

• ProductAvailabilityPattern - Defines an iCal RRule pattern of availability that will return dates and slots. Rules can override each other by adding exclusion dates. Patterns include the Capacity

• ProductAvailabilityType - We need to hold different prices for different ticketTypes or ?? ie Bronze/Silver/Gold or Menu1 / Menu2

• ProductAddition - We need to allow for the addition of one or more options to the Product such as Guide, Pickup, Equipment Hire potentially per AvailabilityType each with a price that may apply per availability or per person

• SupplierTransportGroup - Defines a group of transport locations that may be used for pickup/dropoff - Linked to an ProductAddition by ID

• SupplierTransport - Dealing with pickup and dropoff this is a special case for a ProductAddition. Price may applied per person or per availability

• ProductPrice - The price for the ProductAvailabilityType/SupplierSeason/SupplierPriceCategory

  • VolumeDiscounts (tiered) - We need to hold reduced pricing per larger group sizes

• Modulators - Bokun implement modulators for Duration, Discount and Booking Notice

Pricing terms

Be aware always that any price whether in code or in the DB will also require to have an associated currency and it is never reasonable to default a currency as we could end up basing off 100 GBP when it should be 100 USD.

The booking sites can be executed in a number of currencies but the existing pricing code will deal with all the exchange rates and conversions.

worth understanding that on the heart of the systems we deal with:

• Purchase ... The pricing and currency related to Holibob's purchase of the product from the SUPPLIER

• Base ... The pricing in GBP - it is ALWAYS the case that anything in BASE is GBP

• Sale ... The pricing and currency related to Holibob's sale of the product to the PARTNER

There are multiple prices per each of the above with terms including GROSS and NETT essentially being before or after commissions, discounts etc etc have been applied.

Of note also is the fact that the SALE prices include both the GROSS which is what we expect the CONSUMER to pay (ie the customer of the Partner) and NETT which is what we will "charge" the PARTNER.

BusinessModels further complicate this.

There are essentially three different payment modes:

• ON_ACCOUNT - We will "invoice" the partner generally at the end of the monthly cycle.

• ON_RECORD - We have on record details of the partners corporate debit card and will charge this immediately the booking is confirmed.

• REQUIRED - Use when we are running a white-label booking site on behalf of the PARTNER. We will present a payment dialog directly to the consumer and collet card details. We place a block for the full amount of the consumers card at checkout and then fully charge the same amount on confirmation of the booking usially a few minutes later.

The direction of the partner finance

If we run the booking site and take the consumer payment then we must pay the partner their proportion of the sale - we do this by sending funds to the partner on the month-end cycle.

If the partner ran the site and took the funds directly from the consumer then they owe us our proportion of the sale as so we invoice them for that.

And finally!

There is one further complexity with what are known as SWITCH sources. In this model the PARTNER has a direct commercial relationship with the SUPPLIER are we are simply a technology provided - where this is the case we charge the partner only a transaction fee and the partner and supplier do the rest of the transaction between each other.

It is possible that a single booking (with Shopping cart enabled) can have both switch and non-switch product on the same booking!