Basic concepts
There are a few basic concepts that that need to be reviewed in order to understand how Dynamic Pricing capability works. These basic concepts can also be used to evaluate whether or not Dynamic Pricing is used for specific programs.
1. Dynamic Pricing capability is generally used to alter the initial price of items. The initial price of an item may then be discounted further if an operator applies a special to the item during a sale. Think of Dynamic Pricing as an extension of an item’s Price configuration tab in SysManager.
Example:
Standard Salesware weekend/weekday pricing specifies that the price of an item is $30 on Saturday or Sunday and $25 on Monday, Tuesday, Wednesday, Thursday or Friday. In all reports, the $25 weekday price is not considered “discounted” from the higher weekend price; it is simply the price of the item on that day. The same concept holds true for Dynamic Pricing capability. Dynamic Pricing Rules are used to set the initial price of the item, which can then be discounted further by applying a special to the item at the time of sale.
There is one exception to this in that a Dynamic Pricing Rule can be configured to automatically apply a special to an item. In this situation, the application of a Dynamic Pricing Rule to an item results in a discount amount being recorded in the data based on the special applied to the item (the same actions that take place whenever a special is applied to an item – either manually by an operator or in some automated fashion.)
2. Calculations are done per admission (see
Note below for an exception) and are front-loaded. The total price of an item that uses Dynamic Pricing capability is obtained by applying the rule to the item per admission and front-loading those admissions based on the start date of the item. The result of each admission calculation is summed to produce the total item price. If an item contains
0 admissions, the rule is applied only once to calculate the total cost of the item.
Example:
A two out-of-three day ticket is configured with two admissions. The rule applied to the item specifies that from April 1 through May 26 the daily price of a ticket is $20. Starting May 27 through September 5, the daily price of a ticket is $25. The price of a 2-day ticket sold on May 26 is calculated by applying the rule twice to the item – once for the date of 5/26 and a second time for the date of 5/27 (two admissions that are front-loaded even though the ticket is technically valid for two days anytime between 5/26 and 5/28). The total price of the ticket is produced by adding the per admission results together.
Day One (first admission)
Date=5/26 Resulting price=$20
Day Two (second admission)
Date=5/27 Resulting price=$25
Total price of the ticket is $45
Note: The “per admission” calculation can be turned off by using the IGNOREADM() function. When this function is present within a Dynamic Pricing Rule, the calculations are only performed once regardless of the number of admissions configured for an item.
3. Rules are additive – the price resulting from the previous rule is used as the starting point for the next rule.
Example:
The two out-of-three day ticket described above is sold to a group account. The group account is configured with a rule that offers a 20% discount from April 1 through May 26 and a 10% discount from May 27 through September fifth. When the two out-of-three day ticket is sold on May 26 to the group account, the resulting price is $38.50.
Day One (first admission)
Date= 5/26
Ticket rule results in a $20 price.
Group account rule discounts the $20 price by 20% resulting in a price of $16.00.
Day Two (second admission)
Date= 5/27
Ticket rule results in a $25 price.
Group account rule discounts the $25 price by 10% resulting in a price of $22.50.
The total price of the item is $38.50
4. Dynamic pricing logic allows for the creation of a pass packages where the price of the package is computed based on the mixture of members. Items and modifiers are now displayed in red if they aren't valid or if the PREVENTUSE() Dynamic Pricing Rule has been applied. The condition SHAREMOD now only refers to modifiers other than one's self. (So, if the item MAIN has a modifier MOD1, the condition SHAREMOD(,,MOD1) is false until another MOD1 is added.)
Rules:
• HASMODS(D,C,I) - is equivalent in functionality to COUNTMODS.
It returns a numeric value for functions that do mathematics (i.e., COMPARE)
• SHAREMODS(D,C,I) - counts the number of other modifiers matching.
• SHAREMODSPREV(D,C,I) - counts the number of previous modifiers matching.
These changes allow for a pass option where the price is computed depending on the mixture of members.