...
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.
The 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:
...