Product Module

The product module is where all the product information is stored for each principal in the system. The products are the lowest level of item that can be purchased.

The products module contains the additional information for the products including the default voucher text, default supplier comment text, and reservation request text. There is a lot of meta data about the products are also stored here. The products should be able to be purchased in multiple currencies for the same product.

The products should also store a list of alternates to help staff sell on to other products, if the given product is not available.

Allocation will be managed in blocks, with each block representing a day, and various other meta data is stored. The blocks are only added to the table when there is allocation taken. This should really reduce the data that needs to be stored.

There should be a capability to store a total quantity of a product which is not really date dependent (for example the number of tickets to a sporting event). Having this sort of control means that you should only be able to sell in that product into a quote/booking once and alter the quantity for the number of tickets.

Products can be free sell. Free sell differs from block in that block is a confirmed allocation whereas free sell although can be considered as confirmed, still requires formal confirmation from the Principal . Free sell (like block) has availability dates and block out dates – normally there is no Quantity limit.

Products may carry deposit/payment requirements (may be dependent on deadlines) and may affect the validity of the whole booking/quote. There might be hooks in the rules to handle for this. This is part of the deposit calculations.

The products are connected to variable pricing over date ranges (known as seasons). The variable pricing is where the price changes based on the number of blocks or number of passengers allocated to products increases.

Products are partitioned, so that they are available to all partitions, some or none. The prices should be configured for each partition.

Products can have “module sharing” where the modules can be shared amongst the various different packages and trips. This means that the trips all contribute to a higher loading which affects the purchase price, but not the sell price. The sharing is done based on same day, and same product in different packages.

The pricing model would be able to store prices in multiple currencies. This would allow for hedging of currency and would not revert to “clever” pricing hacks to get nice round numbers for pricing. The fixed pricing would apply to services as well as inclusive package prices.

Of course as a fall-back the system could do currency conversion based on the last known exchange rates.

The system should be able to track tax on purchases made. The tax rules should be different for each of the partitions.

Should be able to copy the rates for products between principals.

Each product should have a way of referencing third party systems. This is a foreign reference to book the products with third party companies. This will be working in conjunction with the Integration module where the coding/rules for the third party system are stored. It's likely each third party system will be a unique integration.

More specifically the products should have the following features:

  • Products will be tied to brochures.
  • Products will have the ability to have default voucher text associated with them.
  • Products will have coupon text (used for vouchers for proof of purchase) associated with them.
  • Products will be able to have content management system style text stored against them.
  • Products are partitioned, so they are available to all partitions, or one or some.
  • Products can have images uploaded and attached them.
  • Purchase tax should be tracked for reporting later.
  • You should be able to store related or alternate products which is associated with the given product.
  • The products costs and sells should be a sliding scale where the prices change depending on the number of passengers or the quantity booked.
  • Products should be able to be shared amongst packages/trips so that the costs can be combined.
  • Should be able to block out dates or un block dates while retaining cost and other details.
  • Need to be able to track the supplier requests that have been sent. There needs to be a mechanism to control whether requests should be sent or not.
  • Products should have commission (need to understand what this is)
  • Product pricing should be able to have child prices with sliding scales.
  • Product pricing should have fixed currency selling so not just relying on currency conversion.
  • Products should have block allocation to manage the product on a day-level.
  • Products should be ale to have other products linked so that if one product is requested, others are also included.
  • You should be able to copy product and all the costing data.
  • Products can be assigned to brochures.
  • Should have information about meals included.
  • Duration should be days/nights and hours and minutes.
  • Should have alerts on products which are presented to users.

Products are put together to make trips or packages. They can also be used for additional products in a booking or quote.

For the availability matrix you should have options of:

  • A Date range for every day.
  • A date range and then days of the week.
  • A Date Range and a days of the week and repeat weeks (so every second Wednesday)
  • Blackout dates based on the same method.

There should be three different costing models:

  • Per Product, regardless of the number of passengers.
  • Per Passenger, regardless of the number of passengers.
  • Sliding Scale, per passenger which varies by the number of passengers.

This should be really clear to make the costing simple to understand.