Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Highlights

SecuTix has started a major project in Whymper V2. This project will last during several releases and will continue in 2019. The purpose is to bring major improvements in the definition of the prices and price breakdowns, in particular:

  • Configure prices in an easier way.
  • The price breakdown will be more flexible and available for all kinds of prices.
  • Future pricing features will be available for all kinds of prices (as long as it makes sense from a business point of view) thanks to a uniform way of storing prices within SecuTix.

Whymper V2 features

Developments in Whymper V2 concern the pricing of events and related product families (i.e. competitions and "old" visits, not visit passes) as well as events defined inside an advantage, a calculated price season ticket or a package.

Pricing

Get rid of the rate type when defining the prices of an event. A rate table is now directly assigned to a performance, and not indirectly through the rate type as it was the case in the past. Of course, several performances may share the same rate table, no matter if they belong to the same event or not. It's still possible to define exception prices for a given performance. The concept of rate type isn't used anymore for the price definition but may still be used for other needs, for example to define the performances on sale within a package.

When the operator creates new performances, he may (but doesn't have to) select a rate table to be assigned to the new performances. He can assign (or reassign) a rate table later on from the performances menu.

Gain flexibility while defining the price of a (set of) performances within an advantage or a package. This price is now defined by a fully separated grid. In other words, the rate table defining the price of a product within an advantage or a package isn't a sub-grid anymore of the rate table defining the price of the same product sold alone. This change provides you major benefits:

  • You can easily define the same prices for several events while defining different prices for advantages or packages using these events.
  • You can easily define different prices for several events while defining the same price for advantages or packages using these events.

Concretely, when the operator defines the prices of performances within an advantage or package, he has the choice between:

  • Define new prices for these performances within the advantage or package. These prices will be stored in a rate table that may be reused later as any other rate table.
  • Reuse an existing rate table.

Price breakdown

More to come


  • No labels