salesware dynamic pricing - accesso technology group · dynamic pricing rules are used to set the...

Salesware Dynamic Pricing Version 4.4

accesso 302 Camino de la Placita

Taos, NM 87571

575.751.0633

www.accesso.com

http://www.accesso.com/

Copyright

Copyright 2015 accesso Technology Group, plc. All rights reserved.

NOTICE: All information contained herein is the property of accesso Technology Group, plc. No part of this publication (whether in hardcopy or electronic form) may be reproduced or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of accesso Technology Group, plc. The software, which includes information contained in any databases, described in this document is furnished under a license agreement and may be used or copied only in accordance with the terms of that agreement.

This publication and the information herein is furnished AS IS, is subject to change without notice, and should not be construed as a commitment by accesso Technology Group, plc. accesso Technology Group, plc. assumes no responsibility or liability for any errors or inaccuracies, makes no warranty of any kind (express, implied, or statutory) with respect to this publication, and expressly disclaims any and all warranties of merchantability, fitness for particular purposes, and non-infringement of third party rights.

Dynamic Pricing capability overview.................................................................................................................. 3

Benefits .................................................................................................................................................................. 3

Basic concepts ....................................................................................................................................................... 4

Configuration ........................................................................................................................................................ 7

Rule configuration........................................................................................................................................................... 8

Comments .................................................................................................................................................................................................... 11

Conditions .................................................................................................................................................................................................... 11

Functions ...................................................................................................................................................................................................... 17

Sample program configuration .........................................................................................................................25

Account pricing ............................................................................................................................................................. 25

Salespoint group pricing .............................................................................................................................................. 29

Package pricing ............................................................................................................................................................. 31

Day of week/time of day/date/multi-day pricing........................................................................................................ 35

Using Dynamic Pricing Rules with profit centers ........................................................................................................ 37

Example of use in Dynamic Pricing Rules ............................................................................................................................................ 37

Reprocessing portions of Dynamic Pricing Rules ............................................................................................40

Dynamic Pricing capability based on Specials (Dynamic Specials) ................................................................40

Dynamic Specials configuration................................................................................................................................... 41

SysManager .................................................................................................................................................................................................. 41

SiriusSQL ....................................................................................................................................................................................................... 42

ww.dll............................................................................................................................................................................................................. 42

Reporting.............................................................................................................................................................43

Sample scenarios ................................................................................................................................................44

Dynamic Revenue Recognition capability ........................................................................................................45

Messenger Service notifications .................................................................................................................................. 46

Revenue Moving rules vs. Consignment programs .................................................................................................... 47

Detailed explanations of the two features: ......................................................................................................................................... 47

Automated Revenue Recognition on expired and un-used tickets/passes ...................................................53

Configuration ................................................................................................................................................................ 53

SysManager .................................................................................................................................................................................................. 53

Export Service .............................................................................................................................................................................................. 56

ww.dll............................................................................................................................................................................................................. 57

Reporting ....................................................................................................................................................................... 58

Revenue Recognition Summary Report ............................................................................................................................................... 58

Revenue Recognition Detail Report ...................................................................................................................................................... 58

Revenue Recognition Profit Center Split Report ................................................................................................................................ 59

Dynamic Pricing capability overview

The Dynamic Pricing capability provides a set of configured rules that are used to modify item prices based on various conditions. Dynamic Pricing allows for increased pricing flexibility based on various factors such as the presence of an account, the location of a sale (salespoint group), date and day of week, line item quantities and the presence of specific modifiers. This document describes some of the benefits of Dynamic Pricing capability along with instructions on how to configure Dynamic Pricing Rules, including sample programs.

Benefits

Benefits of Dynamic Pricing capability include:

• Flexibility in pricing structures: Salesware-standard pricing rate schedules include four schedules with five date ranges per schedule. Dynamic Pricing allows the specification of an unlimited number of date ranges.

• Reduced amount of items with account and package pricing: Item prices may be modified based on the presence of an account. This allows for one generic set of items to be configured (the “retail” or “walk-in” rate) and discounted based on the presence of a specific account.

Example: The following tickets are essentially the same. They provide a 1 day ticket to an adult. They vary only due to the price of the item.

• Adult 1 Day – Wholesale $25 • Adult 1 Day – Group $30 • Adult 1 Day – Corporate $27 • Adult 1 Day – Walk-in $35

With Dynamic Pricing capability, these items can be consolidated into a single item, Adult 1 Day, priced at the walk-in rate. The Adult 1 Day item may then, have its price altered based on the sale of the item to a wholesale, group or corporate account.

Package pricing can also help to reduce the amount of items.

Example: The following items are configured for a cafeteria.

• Hamburger $4.00 • Fries $2.00 • Coke $2.00 • Value Meal $6.50

With standard pricing, the Value Meal item has to be configured in order to deal with price variations even though it really represents the sale of a hamburger, fries and Coke. But with Dynamic Pricing capability, the Value Meal item is not necessary because a rule can be configured that alters the price of each part of the meal (package) when sold together as a single item with modifiers.

Pricing updates for many items can be accomplished by editing a single rule.

Once Dynamic Pricing Rules are configured, pricing updates can easily be accomplished by modifying the appropriate rules. All items and accounts that use the updated rule have their associated prices updated.

Example: Thirty items use the ADMISSIONS pricing rule. When the price of admission is increased, just the ADMISSIONS rule needs to be modified in order to update the pricing for the thirty items using the ADMISSIONS rule, as opposed to having to edit the individual price of each of the thirty items.

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.

Example rule: IF(DCI(,,ADULT), SETPRICE(575) IF(COMPARE(SHAREMODSPREV(,,ADULT)+SHAREMODSPREV(,,SENIOR),>=2), PREVENTUSE())) IF(DCI(,,SENIOR), SETPRICE(475) IF(COMPARE(SHAREMODSPREV(,,ADULT)+SHAREMODSPREV(,,SENIOR),>=2), PREVENTUSE())) IF(DCI(,,YOUTH), SETPRICE(375) IF(COMPARE(SHAREMODS(,,ADULT)+SHAREMODS(,,SENIOR)+ SHAREMODSPREV(,,YOUTH),>=4),SETPRICE(25))) IF(DCI(,,CHILD), SETPRICE(235) IF(COMPARE(SHAREMODS(,,ADULT)+SHAREMODS(,,SENIOR)+SHAREMODS(,,YOUTH)+ SHAREMODSPREV(,,CHILD),>=4),SETPRICE(25)))

This rule can be assigned to all modifiers of the main “family” pass package item. In this case, the modifier nicknames are SENIOR, ADULT, YOUTH, and CHILD and all are configured as Create Pass item types. The Family Pass package only allows a total of two ADULT or SENIOR modifiers. If more than two of these modifiers are added, the PREVENTUSE() function is enabled. This rule places the price on the modifier rather than the

main item was created as part of the ability to add modifiers. If four modifiers are added, the subsequent YOUTH/CHILD modifiers are discounted to $25.00. This Rule enabled starting with the 5th pass, prices the mods at $25 both in Sales and in E-Commerce modules.

Note: The use of SHAREMODS and SHAREMODSPREV in order to make sure the least expensive members are discounted first regardless of the order of the modifiers.

Example: Enabling functionality in order that the user must select at least one ADULT or SENIOR modifier using the new HASMODS(D,C,I) condition:

IF(COMPARE(HASMODS(),>0),IF(COMPARE(HASMODS(,,ADULT)+HASMODS(,,SENIOR),1-2),,PREVENTUSE()))

This rule is assigned to the main Family Pass package item. If the item does not have at least one ADULT or SENIOR modifier, then the PREVENTUSE() function kicks in.

Configuration

Dynamic Pricing Rules are configured in SysManager > Activities > Item/Sales Lists > Dynamic Pricing Rules. Existing Dynamic Pricing Rules may be attached to items by selecting the appropriate rule from within the SysManager > Activities > DCIs > New/Edit > Price tab and/or existing rules can be attached to accounts by selecting the Dynamic Pricing Rule from within the SysManager > Activities > Accounts > General Info tab.

There are also two Sales32c.INI settings that can impact the behavior of Dynamic Pricing Rules as they relate to the calculation of the prices upon recall of a sale or reservation:

• ApplyAccountRulesOnRecall• RecalculatePriceOnRecall

Both settings by default are set to TRUE, which means that if they are not present and defined otherwise in the local, group or default .INI salespoint files, Sales assumes a TRUE value for both settings. ApplyAccountRulesOnRecall allows an account to be added to a saved and recalled sale and adjust the price of the items based on any Dynamic Rules associated with the account. In order to prevent the account rules from discounting the items further each time the sale is recalled, RecaculatePriceOnRecall=TRUE is used to “re-set” the price back to the starting point and recalculate all rules associated with that item. For more information, see the Salesware .INI Settings Reference document.

Note: When scanning/redeeming vouchers within the ScanMan or GateKeeper modules, the auto-sold item cannot be priced using Dynamic Pricing Rules (ScanMan and GateKeeper do not support the Dynamic Pricing Rule logic). When ScanMan or GateKeeper modules use SalesEZ application to create the auto-sold ticket, SalesEZ is the one that is actually creating the sale, acting like it was a salespoint. SalesEZ application can do only very basic price calculations because it doesn't have the Dynamic Pricing capability that is built into Sales.

Rule configuration

Dynamic Pricing Rules have conditions which can be TRUE or FALSE. Based on the result of the condition, a function can be used to alter the price of the item. The first part of the function specifies what to do if the condition is TRUE; the second part of the function specifies what to do if the condition is FALSE. If there is no FALSE specification in the function, then nothing is done to alter the price of an item when a condition leads to a FALSE result. Functions may also be used without conditions.

Note: There is no limit to how many lines you can have in a Dynamic Pricing Rule.

Example: IF(DOW(SUN),DISCOUNT(10), DISCOUNT(5)) • IF(DOW(SUN), is the condition that says “if the day of the week is Sunday”. • DISCOUNT(10) is the function that is the result of a TRUE answer to the condition. • DISCOUNT(5) is the function that is the result of a FALSE answer to the condition. • So, if it is Sunday the price is discounted by 10%. If it is not Sunday, the price is discounted by 5%.

Note: Conditions can use AND/OR/NOT.

Example: IF(DOW(SUN) AND TIME(12:30-16:00),DISCOUNT(30)) • IF(DOW(SUN), is the condition that says “if the day of the week is Sunday”. • TIME(12:30-16:00) is another condition that says “if the time is between 12:30 PM and 4:00 PM”. • Because AND is used, the day of the week must be Sunday AND the time must be between 12:30 PM and

4:00 PM for the condition to be TRUE. • DISCOUNT(30)) is the function that is the result of a TRUE answer to the condition. • So, if it is Sunday between 12:30 PM and 4:00 PM, discount the price by 30%; otherwise do nothing

(because there is no specification in the function for a FALSE result nothing is done to the price of the item when the condition is FALSE).

Note: Rules can be referenced in other rules using SUB()

Example: IF(DOW(SUN) AND TIME(12:30-16:00) AND NOT DATE(SUB(HOLIDAY)),DISCOUNT(30)) • IF(DOW(SUN), is the condition that says “if the day of the week is Sunday.” • TIME(12:30-16:00) is another condition that says “if the time is between 12:30 PM and 4:00 PM.” • NOT DATE(SUB(HOLIDAY)) is another condition that says “look at the dates in the HOLIDAY rule

and make sure that today is not one of those dates.” • Because AND is used, the day of the week must be Sunday AND the time must be between 12:30 PM and

4:00 PM and it cannot be a date included in the dates specified in the HOLIDAY rule for the condition to be TRUE.

• DISCOUNT(30)) is the function that is the result of a TRUE answer to the condition. • So, if it is Sunday between 12:30 PM and 4:00 PM and not during one of the HOLIDAY seasons, discount

the price by 30%.

Example: This option would allocate $50 to the LESSONS profit center per Lesson modifier attached with the remaining (up to $5000) going to TICKETS.

The HASMOD condition can take up to four parameters. The first is Department, Category, Item, and then the number of times the mod is present. This example specifies the category name LESSON with incrementing numbers of times that an item in the LESSON category is used as a mod.

IF(HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERSFLAT("LESSONS",50,"TICKETS",5000))) IF(HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERSFLAT("LESSONS",100,"TICKETS",5000))) IF(HASMOD(,LESSON,,3),MACRO2(SETPROFITCENTERSFLAT("LESSONS",150,"TICKETS",5000))) IF(HASMOD(,LESSON,,4),MACRO2(SETPROFITCENTERSFLAT("LESSONS",200,"TICKETS",5000))) IF(HASMOD(,LESSON,,5),MACRO2(SETPROFITCENTERSFLAT("LESSONS",250,"TICKETS",5000)))

This would allocate a one day's worth of revenue to LESSONS per lesson modifier with the remaining going to TICKETS. It is much more complicated because the percentages vary based on the # of days on the ticket. The provided samples are up to 6 days and 6 lesson mods. You would need to do the full 14 or whatever max you have for ticket duration.

IF(DCI(,,1DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",100)))

IF(DCI(,,2DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",50,"TICKETS",50))) IF(DCI(,,2DAY) AND HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERS("LESSONS",100)))

IF(DCI(,,3DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",33.333,"TICKETS",66.667))) IF(DCI(,,3DAY) AND HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERS("LESSONS",66.667,"TICKETS",33.333))) IF(DCI(,,3DAY) AND HASMOD(,LESSON,,3),MACRO2(SETPROFITCENTERS("LESSONS",100)))

IF(DCI(,,4DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",25,"TICKETS",75))) IF(DCI(,,4DAY) AND HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERS("LESSONS",50,"TICKETS",50))) IF(DCI(,,4DAY) AND HASMOD(,LESSON,,3),MACRO2(SETPROFITCENTERS("LESSONS",75,"TICKETS",25))) IF(DCI(,,4DAY) AND HASMOD(,LESSON,,4),MACRO2(SETPROFITCENTERS("LESSONS",100)))

IF(DCI(,,5DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",20,"TICKETS",80))) IF(DCI(,,5DAY) AND HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERS("LESSONS",40,"TICKETS",60))) IF(DCI(,,5DAY) AND HASMOD(,LESSON,,3),MACRO2(SETPROFITCENTERS("LESSONS",60,"TICKETS",40))) IF(DCI(,,5DAY) AND HASMOD(,LESSON,,4),MACRO2(SETPROFITCENTERS("LESSONS",80,"TICKETS",20))) IF(DCI(,,5DAY) AND HASMOD(,LESSON,,5),MACRO2(SETPROFITCENTERS("LESSONS",100)))

IF(DCI(,,6DAY) AND HASMOD(,LESSON,,1),MACRO2(SETPROFITCENTERS("LESSONS",16.667,"TICKETS",83.333))) IF(DCI(,,6DAY) AND HASMOD(,LESSON,,2),MACRO2(SETPROFITCENTERS("LESSONS",33.334,"TICKETS",66.666))) IF(DCI(,,6DAY) AND HASMOD(,LESSON,,3),MACRO2(SETPROFITCENTERS("LESSONS",50,"TICKETS",50))) IF(DCI(,,6DAY) AND HASMOD(,LESSON,,4),MACRO2(SETPROFITCENTERS("LESSONS",66.667,"TICKETS",33.333))) IF(DCI(,,6DAY) AND HASMOD(,LESSON,,5),MACRO2(SETPROFITCENTERS("LESSONS",83.334,"TICKETS",16.333))) IF(DCI(,,6DAY) AND HASMOD(,LESSON,,6),MACRO2(SETPROFITCENTERS("LESSONS",100)))

Comments

You can add comments or notes to Dynamic Pricing Rules by using // (double forward slashes), ; (semicolon) or REM (short for “remark”).

Conditions

The following tables provide a list of conditions and functions that may be used together to configure Dynamic Pricing Rules.

Condition Description

ADM(range) This condition evaluates the number of admissions configured for the item.

Example: When the item has exactly 2 admissions.

ADM(2) = TRUE ADM(2-3) = TRUE ADM(>2) = FALSE

ADVANCE(check) This condition is TRUE if the number of days of the start_date minus today’s date (computer date) meet the specification of the check specified in the single argument. The check can either be just a number (indicating that it must be exactly that many days in advance) or an operator and a number such as >10 which means that it must be at least ten days in advance. Valid operators are >, >=, <, <=. Ranges can also be used, such as 2-5 which means that it must be between 2 and 5 days in advance.

Example: start_date is 7/18/2013, today’s date is 7/13/2013

ADVANCE(5) = TRUE ADVANCE(6) = FALSE ADVANCE(3-5) = TRUE ADVANCE(>=5) = TRUE

AGE(range) Can accept greater than, equal to, less than or a range (just like the QTY condition) based age of the guest attached to the item.

COMPARE(mathematical expression,range)

COMPARE takes two arguments. The first is a mathematical expression that is evaluated using the mathematics parser; the second is a range.


Example: IF(COMPARE(COUNTMODS(,,AD) + COUNTMODS(,,CH),>1),PREVENTUSE(An Adult OR a Child can be selected as a modifier))

This rule can be used to ensure that only one modifier or the other is allowed.

COUNTMODS(dci) HASMOD, ISMOD, SHAREMOD and COUNTMODS all can either take a single argument of thirty characters (a fully defined DCI), or can take up to three arguments which are a department, category and item and work identically to the dci argument.

COUNTMODS returns an integer representing the number of occurrences of the modifier.

Example: COUNTMODS(,,MOD2)*3.25

DATE(range, …) This condition can have any number of dates or date ranges. If the date of the day being calculated matches any of the ranges, then it is TRUE. Individual dates can be used or date ranges (two dates separated by a dash). At least one argument must be supplied, but any number of dates or date ranges can be included.

Example: Calculating on 3/13/2003. DATE(3/13/2003) = TRUE DATE(3/10/2003, 3/11/2003, 3/12/2003, 3/13/2003) = TRUE DATE(3/1/2003-4/1/2003) = TRUE DATE(2/1/2003-3/1/2003, 3/22/2003-6/01/2003) = FALSE

DAYCOUNT( condition, range)

This takes a condition (which can be comprised of any other conditions) and applies it to all the days for the product. The total days that satisfy the condition are compared to the range. If the day being considered doesn't satisfy the range, then this automatically returns FALSE.

Example: DAYCOUNT( DATE(04/01/2003-04/30/2003), 2-3 )

A use of this that mimics the use of the DAYS function is as follows: SETPRICE(60) IF(DAYCOUNT( DATE(04/01/2003-04/30/2003) , 2-3 ) AND DATE(04/01/2003-04/30/2003), DISCOUNT(10) )


This allows complex situations to be handled, such as a check to see if one day is on the weekend and one is during the week during a non-holiday period.

Example: IF( DAYCOUNT( SUB(NON-HOLIDAY) AND DOW(MON-FRI) ),1) AND DAYCOUNT( SUB(NON-HOLIDAY) AND DOW(SAT-SUN) ),1) , DISCOUNT(10) )

DCI(department, category, item)

This condition can be called with one, two or three parameters. If it matches the item sold, it returns TRUE; otherwise, FALSE. Also, if any argument is empty, that comparison is ignored (for example, you can just match on category and ignore the item level).

Example: For LIFTS,JUNIOR, ALLDAY DCI(LIFTS) = TRUE DCI(LIFTS,JUNIOR,ALLDAY) = TRUE DCI(LIFTS,ADULT) = FALSE DCI(,,ALLDAY) = TRUE

DOW(range, …) This condition specifies days of week that are possible matches. Valid abbreviations are (MON TUE WED THU FRI SAT SUN), although more characters can be used. Ranges can be specified using a dash and any number of days-of-week or day-ranges can be specified.

Example: Calculating on a Wednesday.

DOW(MON-FRI) = TRUE DOW(MON,TUE,THU) = FALSE DOW(WED-THU, SAT-SUN) = TRUE

DTSPAN(range) This condition evaluates the time span based on the start and end date/time manually set by the operator when selling an item configured to SysManager > Activities > DCIs > New/Edit > General tab > Calculate specific end time dynamically check box. The value is in number of days.

DTSPAN2(range) This condition evaluates the time span based on the start and end date/time manually set by the operator when selling an item configured to SysManager > Activities > DCIs > New/Edit > General tab > Calculate specific end time dynamically check box. The value is in number of minutes.

GROUP(#) Returns TRUE if this salespoint is a member of the accounting group specified.

HASMOD(DCI,number of occurrences)

HASMOD, ISMOD, SHAREMOD and COUNTMODS all can either take a single argument of thirty characters (a fully defined DCI) or can take up to three


arguments which are a department, category and item and work identically to the dci argument. A fourth argument can be added for number of occurrences.

HASMOD can take 0 arguments and returns TRUE if the item has any modifiers. Otherwise, it returns TRUE if this item has a modifier matching the dci.

A fourth argument can be added for number of occurrences.

Example: HASMOD(,,ADULT,>2)

This rule returns TRUE if an item has more than two modifiers with an item nickname of ADULT. A range such as 2-3 is legal or just a number or >=, etc.

ISMOD(dci,number of occurrences)

HASMOD, ISMOD, SHAREMOD and COUNTMODS all can either take a single argument of thirty characters (a fully defined DCI) or can take up to three arguments which are a department, category and item and work identically to the dci argument. A fourth argument can be added for number of occurrences.

ISMOD can take 0 arguments and returns TRUE if it’s the modifier of any item. Otherwise, it returns TRUE if its parent item matches the dci specified.

ISTYPE(type) Returns TRUE if this particular modifier has attached rental history of the specified type.

OVERDUE() The () returns TRUE if the item's due date is in the past.

Example: IF(STATUS(O) AND NOT OVERDUE(),MACRO(DISPLAY2(Item Found,DateDue=<<datedue>><cr>Code=<<saleinfo->message>> FOP=<<saleinfo->fop>>))) IF(STATUS(O) AND OVERDUE(),MACRO(DISPLAY2(Item Found - OVERDUE,Item is Overdue by <<overduetime>><cr>DateDue=<<datedue>><cr>Code=<<saleinfo->message>> FOP=<<saleinfo- >fop>>))) IF(STATUS(I), MACRO(SELECTITEMFROMLIST("TEST TEST LOCKER ","TEST TEST M1 ")MESSAGE()RENTALCHECKOUT(<<swipe>>))) IF(STATUS(O), MACRO(SELECTITEM("TEST TEST LOCKER ") QUANTITY(-1) RENTALCHECKIN(<<swipe>>))) IF(STATUS(M), MACRO(DISPLAY(Item is in maintenance EquipTag=<<equip_tag>>)))

The only actions allowed are MACRO and MACROCLEAN which launches special commands through the Sales interface.


PHYSLOCATION() This is used for the scanner location (physical location) in a Dynamic Pricing Rule.

Example: IF(PHYSLOCATION(1), MOVEREVENUE(*DEFERRED*, ACTV: CLIMBWALL, 25, 0,ACTIVITIES,ATTRACTION,CLIMBWALL))

QTY(>) QTY(<) QTY(>=) QTY(<=) QTY(=) QTY(X-Y)

Determines the price per item based on the quantity set on the line item.

Example: IF(QTY(2-3), SETPRICE(22.00), IF(QTY(<=5),setprice(33.00),SETPRICE(44.00)))

Qty. Price

1 33.00

2 44.00 (2*22.00)

3 66.00 (3*22.00)

4 132.00 (4*33.00)

5 165.00 (5*33.00)

6 264.00 (6*44.00)

The argument for QTY is like the ADM function.

Example: QTY(>2) QTY(<=2) QTY(2-3) QTY(1)

R_DAYTYPE(daytype) Returns TRUE if the rental day is the daytype specified.

R_PRESENT(type, level)

R_PRESENT(SKI, DEMO) returns TRUE if there is a demo ski in the rental history.

SALESPOINT(name) If the salespoint name matches the argument, returns TRUE. For ww.dll, it works off the DefaultInfo setting.

SHAREMOD(dci, number of occurrences)

HASMOD, ISMOD, SHAREMOD and COUNTMODS all can either take a single argument of thirty characters (a fully defined DCI) or can take up to three arguments which are a department, category and item and work identically to the dci argument. A fourth argument can be added for number of occurrences.


SHAREMOD must have at least one argument and returns TRUE if there is any modifier matching the DCI specified.

SHAREMODSPREV(D,C,I) Counts the number of previous modifiers matching.

STATUS(n) The value “n” is the status to be checked.

Example: IF(STATUS(O) AND NOT OVERDUE(),MACRO(DISPLAY2(Item Found,DateDue=<<datedue>><cr>Code=<<saleinfo->message>> FOP=<<saleinfo->fop>>))) IF(STATUS(O) AND OVERDUE(),MACRO(DISPLAY2(Item Found - OVERDUE,Item is Overdue by <<overduetime>><cr>DateDue=<<datedue>><cr>Code=<<saleinfo->message>> FOP=<<saleinfo- >fop>>))) IF(STATUS(I), MACRO(SELECTITEMFROMLIST("TEST TEST LOCKER ","TEST TEST M1 ")MESSAGE()RENTALCHECKOUT(<<swipe>>))) IF(STATUS(O), MACRO(SELECTITEM("TEST TEST LOCKER ") QUANTITY(-1) RENTALCHECKIN(<<swipe>>))) IF(STATUS(M), MACRO(DISPLAY(Item is in maintenance EquipTag=<<equip_tag>>)))

The only actions allowed are MACRO and MACROCLEAN which launches special commands through the Sales interface.

TIME(time1 – time2) This condition takes a time range, for example, TIME(10:00-12:00). Military time is the easiest although AM and PM work as well.

TSPAN(range) This condition evaluates the configured time span of the item; otherwise, it is identical to ADM.

WEB() Returns TRUE if being processed by ww.dll or by Sales Host utility.

Functions

Function Description

ADDPRICE(amt) amt can be an amount to add to the price or a mathematical expression (identical to the Points4Sale expression) which is evaluated. So, ADDPRICE(COUNTMODS(,,MOD1)*3) adds to the price $3.00 for each MOD1. This evaluation also occurs when using SETPRICE.

Examples of ADDPRICE rule Description IF(HASMOD(,,MOD1), ADDPRICE(1))

Adds $1.00 to the item price if the item has MOD1 as a level 1 modifier.

IF(HASMODN(,,MOD2), ADDPRICE(2))

Adds $2.00 to the item price if the item has MOD2 as a modifier at any level.

IF(HASMOD2(,,AUX1), ADDPRICE(3))

Adds $3.00 to the item price if the item has AUX1 as a level 2 modifier.

IF(HASMODN(,,AUX2), ADDPRICE(4))

Adds $4.00 to the item price if the item has AUX2 as a modifier at any level.

IF(ISMODN(,,MAIN1), ADDPRICE(30))

Adds $30.00 to the price of a modifier at any level below the main item MAIN1.

IF(ISMOD2(,,MAIN2), ADDPRICE(40))

Adds $40.00 to the price of a modifier at the second level below the main item MAIN2.

BONUSCASH(percent, dollar amt, TRUE)

The Bonus Cash Rule is based on this Dynamic Pricing Rule function.

Example: BONUSCASH(10) is 10% of the load amount as bonus cash to the card; BONUSCASH(0,5) adds a flat $5.00 bonus cash to the card.

BONUSLOAD(percent, dollar amt, TRUE)

Dynamic Pricing Rules can now allow a flat dollar amount load of Bonus Cash even when the load amount for the card is zero.

Example: Using a Dynamic Pricing Rule with a % amount for Bonus Cash (BONUSCASH(10)) and with the load amount on the Debitware tab for the item as zero, results in the following:

1. Place following line in the Debitware item:

BONUSLOAD(,10,TRUE)

In Sales, the Bonus Cash amount was $10 and the load amount was zero (the $10 came from the Bonusload macro).


2. Then, take the BONUSLOAD(,10,TRUE) line out of the Sales Action tab. In Sales, the Bonus Cash amount was zero, and the load amount was zero.

3. Change the Dynamic Pricing Rule to be BONUSCASH(,10). In Sales, the load amount was zero and the Bonus Cash amount was $10.

Note: The macro ignores any previous calculations performed through BONUSCASH unless the BONUSLOAD macro includes the TRUE statement.

DISCOUNT(pct, amt) Discounts the price of the product by a percentage and an amount.

DONATIONROUNDUP() Rounds up the sale total to the nearest whole dollar amount. It can take an optional argument to round up to any arbitrary amount.

Example: DONATIONROUNDUP(10) rounds to the nearest $10.00 (if the current sale total is $21.25, the price of the donation item would be set to $8.75 resulting in a sale total of $30.00).

DONATIONROUNDUP(1) is identical to DONATIONROUNDUP() and rounds the sale total to the nearest $1.00 (if the current sale total is $5.88, the price of the donation item would be set to $0.12 resulting in a sale total of $6.00).

The price of the donation item, once it is added to the sales invoice, is adjusted each time something else is added to the sale, so the donation item can be added anywhere in the sale process.

GETEXCHANGEDPASSNO Ensures correct pass or ticket numbers are voided when payment plans have declined payments, particularly when exchanges or refunds have occurred on the tickets or passes.

GETFIELD(fieldname) Used to access any numeric field in the item record.

Example: IF(QTY(>=5),GETFIELD(ADMISSIONS)*1.25, GETFIELD(ADMISSIONS)*2.5)


This rule says to multiply the number found in the items.admissions field for the item being sold by 1.25 if the line item quantity is greater than or equal to 5; otherwise multiply the number found in the items.admissions field by 2.5.

GETPRICE(#) Takes a single argument, from 1 to 42, which gets the price from the item record as set in SysManager. For reference, 1 corresponds to monday_0, 7 to sunday_0, 8 to monday_1 and 42 to sunday_5.

IF(condition, function(s), function(s))

This function takes a condition (see previous table) as the first argument and a function or functions for the second (and possibly the third) argument. If the condition evaluates to TRUE, the function(s) in the second argument are executed. The third argument is optional and can contain functions to evaluate if the condition evaluates to FALSE.

Example: IF(DOW(SUN),DISCOUNT(10), DISCOUNT(5))

If the day of the week is Sunday, then the discount is 10; otherwise the discount is 5.

IGNOREACCTRULE() If used, this function ignores any Dynamic Pricing Rule associated with an account linked to the sale/item when determining the price of an item.

IGNOREADM() Used to bypass the per admission calculation for items configured with admissions greater than one.

Example: IGNOREADM()SETPRICE(100)

This yields a price of 100 regardless of how many admissions an item may have.

IGNOREQTYMULT() This instructs the parser to ignore the implicit multiplication by quantity. IGNOREQTYMULT()SETPRICE(80) would let the item have a price of eighty regardless of quantity. This allows the final price of an item, after quantity is applied, to be more strictly controlled. Also, this causes rounding following the application of a special to be applied to the extension price. For example, the final price after being multiplied by quantity. Modifiers are always added to parent items in the quantity of the parent item.


MACRO MACROCLEAN()

Used to specify actions to perform on the sale of an item. These actions are evaluated only on the first day of the sale of the item and are only performed when the item is added to the sale. The argument is what is to be added to the do_on_sale field for the item.

Example: if(hasmod(,,CANDY),MACRO(SPECIAL("DUMMY ")))

Also available is the function MACROCLEAN, which eliminates any previous do_on_sale commands.

Example: if(hasmod(,,CANDY),MACROCLEAN()MACRO(SPECIAL("DUMMY ")))

To remove a special applied with the MACRO function in a Dynamic Pricing Rule, use one of the following macro commands:

• NOSPECIAL() which removes the special on the currently selected line item.

• NOGLOBALSPECIAL() which removes the global special for the sale

See the Salesware Sales screen action macro Commands document for a list of available macros.

MACRO2 MACROCLEAN2()

Same as MACRO, but if the macro needs to be re-run every time the price is changed (for example, if it depends on modifiers), and then the MACRO2 and MACROCLEAN2 functions must be used.

Example: if(HASMOD(,,CANDY),MACRO2(SPECIAL("DUMMY "))) if(HASMOD(,,CANDY),MACROCLEAN2()MACRO2(SPECIAL ("DUMMY ")))

See the Salesware Sales screen action macro Commands document for a list of available macros.


MACRO2(NOACCOUNT()) Detaches any account from a line item. An auto-sold item is prevented from being put on account by using this as a Dynamic Pricing Rule attached to the item.

MOVEREVENUE(OLD_PR_CTR, NEW_PR_CTR,20, 10, D,C,I, SALESPOINT, OPERATOR)

The Recognize Revenue Rule is configured in SysManager > Activities > Item/Sales Lists > Dynamic Pricing Rules.

The rule must be configured as a rule type of Any or Recognize Revenue Rule to be assigned to a ticket or pass item in the Global Settings tab of the item’s template. With current functionality the rule must follow the following syntax:

MOVEREVENUE( OLD_PR_CTR, NEW_PR_CTR, 20, 10, D,C,I, Salespoint, Operator)

where MOVEREVENUE is the function, OLD_PR_CTR is the deferred profit center, NEW_PR_CTR is the non-deferred profit center, 20 is the percent of the deferred profit center to be moved to the non-deferred and 10 is the flat dollar amount to move from the deferred profit center to the non-deferred profit center. Either percent, flat dollar amount or both can be used in the rule. The value is set to “0” if not used. D,C,I is the department, category and item nickname of the item that is attached to the profit center adjustment in the data, Salespoint is the optional salespoint that is written to the data (scanner location if not specified), Operator is the optional operator (blank if not specified).

The ability to omit the DCI section has been added to the MOVEREVENUE Rule. If omitted, the DCI of the pass item validated is used. This change to the MOVEREVENUE Rule allows for fewer arguments (if DCI is omitted) and enables a more generic rule for similar tickets. For example, all adult, child and senior admission tickets could use a simplified rule such as MOVEREVENUE(Deferred, Admissions, 100,0) while still allowing lots of details regarding why revenue moved from one Profit Center to another on the Profit Center Split Report.

Note: If you want to omit the DCI, you need to omit the entire DCI, not just one portion (i.e., omit the category but not the department).

Examples: • Dept=TRANSPORT, CAT=PUNCHCARDS, Item=10USE


• Scanner Salespoint = SCAN01 • Scanner Operator=DOUG • Amount distributed to Deferred when the Punch Card was

purchased = $250

Previous Functionality MOVEREVENUE(Deferred, Passenger Cards, 10, 0, TRANSPORT, REVENUE, PUNCHUSE, DOCK, PURSER)

This results in a transact record that removes $25 from Deferred, adds $25 to Passenger Cards, uses TRANSPORT REVENUE PUNCHUSE as the DCI, writes DOCK for the salespoint, and writes PURSER for the operator.

New Functionality

MOVEREVENUE(Deferred, Passenger Cards, 10, 0)

This results in a transact record that removes $25 from Deferred, adds $25 to Passenger Cards, uses TRANSPORT PUNCHCARDS 10USE as the DCI, writes SCAN01 for the salespoint, and writes DOUG for the operator.

MOVEREVENUE(Deferred, Passenger Cards, 10, 0,,,,DOCK,PURSER)

This would results in a transact record that removes $25 from Deferred, adds $25 to Passenger Cards, uses TRANSPORT PUNCHCARDS 10USE as the DCI, writes DOCK for the salespoint, and writes PURSER for the operator.

MULT(fac) Multiplies whatever the price of the product is by the factor.

PREVENTUSE(display-text)

Disallows the product from being sold. If display-text is passed, a message box is displayed to the operator.

ROUND() Rounds the price to two decimal places. An argument can be provided for rounding to a certain dollar increment. For example, 1.00 would be rounded to a dollar, 0.25 would be the nearest quarter, etc.


Note: All rounding functions execute at the end of all other calculations. Rounding does not occur at specific intervals based on where the ROUND() function is placed within a rule.

ROUNDUP(),ROUNDDOWN( Both work identically to ROUND except that they round up or down.

Example: Using a price of $2.31

• ROUND(0.25) - Rounds to the nearest quarter ($2.25) • ROUNDUP(0.25) -$ 2.50 • ROUND(1.00) - $2.00 • ROUNDUP(1.00) - $3.00

Saleround() Takes a single, required parameter. SaleRound allows for the rounding of the final price of a sale to the value defined by the required parameter.

Example: Saleround(.05) rounds as follows:

If the sale amount's final cents is 1 or 2 cents, the amount is rounded down to the nearest 10 cents; 3 and 4 cents are rounded up to the nearest 5 cents; 6 and 7 cents rounded down to the nearest 5 cents; and 8 and 9 cents rounded up to the nearest 10 cents.

To employ this new Dynamic Pricing Rule to create a zero dollar item with the SaleRound Rule, apply it to the sale after all items have been entered. With the addition of this pricing rule, it is now possible for Dynamic Pricing Rules to return a negative value.

SETPRICE(price) Changes the price of the item to the argument.

SETBASEPRICE() Takes no arguments. Sets the price as calculated by the “normal” pricing scheme (using schedules and day of week and everything).

Warning: For advanced use only.

SETTAX(num,rate) Sets the tax rate for an item. The type of rate, Tax 1 or Tax 2 and the percentage must be specified.


Example: To set Tax 1 to 3.25%, use the function: SETTAX(1,3.25). This function is useful for removing tax for tax exempt institutions. For example, you can use a rule like this for a tax-exempt account:

IF(DCI(ACTIVITIES,ATTRACTION),DISCOUNT(10))SETTAX(1,0)

SKIPNEXT(function) Finds the occurrence of the function specified and removes it.

Example: SKIPNEXT(IF) IF( DOW(WED) , DISCOUNT(10)SKIPNEXT(IF)) IF( TRUE, DISCOUNT(10) )

SUB(macro-name) Loads another Dynamic Pricing Rule, using the text in the description.

VOIDPAYMENTPLANPASS Used to void payment plan passes.

WEIGHT(PricePerUnit, Units)

Used when an item is priced using a scale. For this rule to function, the SysManager > Activities > DCIs > New/Edit > Price tab > Price Calculated By Weight check box must be unchecked. PricePerUnit is the price that is charged per unit specified by Units. Units can be any unit that appears in the SysManager > Activities > DCIs > New/Edit > Price tab > Unit of Measure dropdown.

Example: WEIGHT(0.25, oz)

For more information, see the Salesware Retail document.

The MACRO functions in the previous table are unique in that they can be used to apply a special to an item in order to alter its price. These are the only functions that can be used to alter the price of an item that results in a discounted amount being recorded in the data. Specials applied in this manner show up on reports such as the Specials Performance Report. Additional points about these macros:

• MACRO() is used in a Dynamic Pricing Rule when the action only takes place immediately upon adding the item to a sale.

• MACRO2() is used when the action is done whenever the status of the item changes (qty., addition of modifiers, date/time, etc.).

• MACROCLEAN() removes any Sales screen action macro command configured on the item’s Sales Actions tab only when first added to the sale.

• MACROCLEAN2() removes any Sales screen action macros command configured on the item’s Sales Action tab and re-fires any time the item is changed (qty., addition of modifiers, date/time, etc.)

• MACRO2(NOACCOUNT() is actually a Sales screen action macro command and thus must be surrounded by the MACRO2() function in order to be applied via a Dynamic Pricing Rule.

• MACRO2(NOACCOUNT()) because this is set as a Dynamic Pricing Rule, the original pricing of the item is not honored when scanned through GateKeeper module. The item is still auto-sold but the amount sent to the auto-scan invoice is $0.00.

Sample program configuration

Dynamic Pricing Rules can be configured in many different ways to accommodate various programs that require specialized pricing structures. The following sections describe how to configure pricing rules using four broad areas of Dynamic Pricing Rule functionality:

1. Account pricing 2. Salespoint group pricing 3. Package pricing

• Using modifiers • Using quantity

4. Day of week/time of day/date/multi-day pricing

Account pricing

Account pricing can be used to offer discounted pricing to various groups and can also help to reduce the number of items that must be configured due to price variances of essentially the same item. For instance, instead of having a list of ticket products for “wholesale,” another for “groups,” another for “lodging properties” and another for “walk-ins,” just one set of items can be configured at the “retail rate” and the applicable discounted pricing can be applied to the items by selling them to an account.

The rule attached to the account can “ignore previous rules” for the item and calculate the price of the item from the original base rate or it can further alter the price of the item based on the outcome of the item’s own rules. Remember – Dynamic Pricing Rules are additive! If the price of the item when sold to the account is discounted in addition to any discounts that may have already been calculated based on the item’s Dynamic Pricing Rule, do not check the SysManager > Activities > Accounts > New/Edit > General Info tab > Ignore Previous Rules check box. If the item’s price is calculated using only the conditions and functions contained in the Dynamic Pricing Rule attached to the account, check the Ignore Previous Rules check box.

Sample rules: • DISCOUNT(5) discounts all items sold to the account by 5%. • IF(DCI(TICKETS), DISCOUNT(5)) only discount items within the TICKETS department when

sold to the account by 5%.

Sample program: The Washington Elementary School gets a School Group discount on tickets. In order to implement this discounted program with the use of Dynamic Pricing Rules, the following is configured in SysManager:

1. A “School Group” Rule is configured that discounts all items in the TICKETS department by 20%: IF(DCI(TICKETS),DISCOUNT(20)).

2. An account is configured for Washington Elementary and the “School Group” Rule is selected from the SysManager > Activities > Accounts > New/Edit > General Info tab > Dynamic Pricing Rule dropdown. This school group discount is offered in addition to the any Dynamic Pricing-based discounts already calculated for normal ticket sales (such as discounts based on high or low seasons or those based on the day of the week, etc.), so the Ignore Previous Rules check box is left un-checked.

3. The Youth Entrance item within the TICKETS department already follows the Regular Price Rule which is a weekday/weekend rule that discounts the base ticket price by 20% for weekdays. The Regular Price Rule used by the Youth Entrance item looks like this:

IF(DOW(SUB(WEEKDAY)),DISCOUNT(20))

The Regular Price Rule is attached to the Youth Item ticket.

Note: The “base rate” of the item can be established within a Dynamic Pricing Rule by using the function SETPRICE or within the item on the Price tab:

4. The end result is that when items within the TICKETS department are sold to the Washington Elementary account, the price is discounted by 20%, which results in a Youth 1 Day Ticket price of $9.60 on a weekday or $12.00 on a weekend.

The price of the Youth 1 Day Ticket is $12.00 on a weekday and $15.00 on a weekend when it is not sold to the Washington Elementary account.

Salespoint group pricing

Salespoint group pricing allows the price of an item to vary based on the location of the sale. For instance, a twelve-ounce soda costs $0.75 at the employee cafeteria, but, that same twelve-ounce soda costs $2.50 at the five-star restaurant.

Salespoint group pricing relies on a condition that uses the number associated with the salespoint group. Salespoint groups are configured within SysManager > Activities > System Lists > Salespoint Groups.

Any function can be used with the GROUP condition (conditions and functions can be combined in almost any manner), but the sample program outlined below demonstrates the use of the specific function, GETPRICE. The GETPRICE function is used to specify which base rate within the item’s Price tab to use. Typically, if configuring the base price for an item within the item’s Price tab, as opposed to setting the base price of an item within a Dynamic Pricing Rule, a single base rate is sufficient. But, multiple base rates can be used. accesso allows up to forty-two base rates to be established per item. When using more than one base rate, the GETPRICE function is used to specify which of the potential forty-two base rates are used.

Samples rules: • IF(GROUP(1),GETPRICE(1)) uses the base price in slot #1 on the item Price tab when the item is

sold at a salespoint included in salespoint group #1 • IF(GROUP(2),GETPRICE(8)) uses the base price in slot #8 on the item Price tab when the item is

sold at a salespoint included in salespoint group #2 • IF(GROUP(3),GETPRICE(15)) uses the base price in slot #15 on the item Price tab when the item is

sold at a salespoint included in salespoint group #3

Sample program: Snowtime, Inc. uses a single SiriusSQL database for three resorts: Liberty, Whitetail and Roundtop. Instead of setting up three entire sets of items for each resort, the resorts share items and use Dynamic Pricing capability to adjust the price of each item based on where the item is sold. To set up this program, these steps were followed:

1. A salespoint group was created for each resort that included all of the salespoints at each resort. 2. Each resort used a specific “row” of base rates on the item Price tab; Liberty would always use the base

prices in slots #1-7, Roundtop would always use the prices in #8-14 and Whitetail would always use the prices in #15-21.

3. A single rule was created that would be used for all items that were shared between the three resorts. Assuming that the Liberty salespoint group was number 1, the Roundtop salespoint group was number 2 and the Whitetail salespoint group was number 3, the rule looked like this:

IF(GROUP(1),GETPRICE(1))

IF(GROUP(2),GETPRICE(8)) IF(GROUP(3),GETPRICE(15))

The result was that a single item, such as a lift ticket, could be shared among all three resorts and be priced according to where the ticket was purchased. Using the following screen capture along with the rule previously specified:

• When an Adult Lift item was sold at a Liberty salespoint (a salespoint included in salespoint group #1), the price of the ticket would be $50 (the base rate in slot #1).

• When an Adult Lift item was sold at a Roundtop salespoint (a salespoint included in salespoint group #2), the price of the ticket would be $47 (the base rate in slot #8).

• When an Adult Lift item was sold at a Whitetail salespoint (a salespoint included in salespoint group #3), the price of the ticket would be $45 (the base rate in slot #15).

Package pricing

Package pricing uses the presence of modifiers to determine the price of the item and/or the price of the item’s modifiers.

Example: • Skis when sold alone costs $350 • Bindings when sold alone costs $150 • When they are all sold together, they total $400

Package pricing can also involve price discounts based on line item quantities.

Example: • Qty. 1-19 Adult Tickets do not get a discount. • Qty. 20-49 Adult Tickets get a 10% discount. • Qty. 50-999 Adult Tickets get a 15% discount.

Note: The quantity functionality is based on the line item quantity only. It is not based on the sum of all quantities in a sale, nor is it based on the sum of the main item and its modifiers.

Sample program: The Henry Ford Museum offers the following products:

• Henry Ford Museum Entrance Adult price $14 • Greenfield Village Entrance Adult price $20 • Ford Rouge Factory Tour Adult price $14

Visitors to the museum may purchase each of these products independently or they may purchase a Fun-Pack that allows the selection of two out of the three options for a discounted rate. The Fun-Pack program was implemented using a combination of modifier functionality and Dynamic Pricing capability. The basic Adult Fun-Pack program implementation is as follows:

1. The following items were configured: • An Adult Henry Ford Museum Entrance. • An Adult Greenfield Village Entrance. • Several Adult Ford Rouge Factory Tours representing the times of the tours.

2. An Adult Fun-Pack item was configured. The price of the Adult Fun-Pack is always total $26. The options listed above were attached to the Adult Fun-Pack item as modifiers and minimum/maximum modifier selection restrictions were enforced:

3. Dynamic Pricing Rules were configured that priced each piece of the package based on the combination of modifiers present in the Fun-Pack. The conditions used were ISMOD(), HASMOD() and SHAREMOD(). These functions can specify a department, category and item within the parenthesis separated by commas. Each rule was attached to the corresponding item.

Adult Henry Ford Museum rule: SETPRICE(14) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-GFV), SETPRICE(10.75)) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-RGE), SETPRICE(13))

Adult Greenfield Village rule: SETPRICE(20) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-HFM), SETPRICE(15.25)) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-RGE), SETPRICE(15.25))

Adult Ford Rouge Factory Tour rule: SETPRICE(14) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-GFV), SETPRICE(10.75)) IF(ISMOD(HFM-FPCKS) AND SHAREMOD(HFM-HFM), SETPRICE(13))

4. The result was that the price of each option is adjusted based on the combination selected for the Fun-Pack.

When sold independently, the price is the regular rate:

Other examples of this type of package pricing:

• Bike Race Entrance that comes with a free T-shirt, otherwise the t-shirt costs $20. • Discounted ski packages when purchasing skis, bindings and boots together. • Value Meal pricing based on the selection of a hamburger, fries and a Coke.

Day of week/time of day/date/multi-day pricing

There are several Dynamic Pricing Rule conditions designed to accommodate pricing based on the valid date of an item and multi-day discounts. While the majority of this type of a pricing can be accommodated by using the standard Salesware rate schedules, there are situations when using Dynamic Pricing Rules to configure these types of programs may be useful such as:

• There are not enough date ranges and/or rate schedules available to accommodate an item’s varying price throughout the year.

• An item’s price is based on the time of day. • An item is given a discount based on an advance purchase of X days. • Multi-day discounts may vary based on whether or not the item is valid during a portion of a peak season. • The benefit of updating multiple item prices by editing a single rule as opposed to editing each item.

Sample programs: 1. A 5% discount is given to all tickets that are not valid on a Saturday or Sunday.

• Possible Rule: IF(DOW(MON-FRI), DISCOUNT(5)) • Result: If any portion of a multi-admission ticket is valid over the weekend, only the non-weekend

portion of the ticket receives the 5% discount.

2. A 10% discount is given to all tickets that are not valid during a holiday season. • Possible Rule: IF(NOT DATE(12/20/2015-01/05/2016),DISCOUNT(10)) • Result: If any portion of a multi-admission ticket is valid during 12/20/2015-01/05/2016, only the

portion of the ticket that does not fall into the date range specified receives a 10% discount.

3. A ticket costs $20 if purchased between 9:00 AM and 11:00 AM, $15 if purchased between 11:01 AM and 1:00 PM, $10 if purchased between 1:01 PM and 3:00 PM and $5 if purchased between 3:01 PM and 5:00 PM. • Possible Rule:

IF(TIME(09:00-11:00),SETPRICE(20)) IF(TIME(11:01-13:00),SETPRICE(15)) IF(TIME(13:01-15:00),SETPRICE(10)) IF(TIME(15:01-17:00),SETPRICE(5))

• Result: The ticket price varies every two hours throughout the day. Tickets such as these would typically not be multi-day (multi-admission) tickets.

4. A multi-day discount of 15% per day is offered on tickets when at least three or more days fall outside of a holiday season. • Possible Rule: IF(DAYCOUNT(NOT DATE(12/20/15-

01/05/2016),>=3),DISCOUNT(15))

• Result: At least three admissions on a multi-admission item need to be valid outside of the 12/20/15-01/05/16 date range. If this condition is met, those days (admissions) that are outside of the specified date range is discounted by 15%.

5. A ticket is discounted by 20% when purchased at least thirty days in advance, 10% when purchased at least fourteen days in advance and no discount is offered when purchased less than fourteen days prior to arrival (less than fourteen days prior to the valid date of the ticket). • Possible Rule:

IF(ADVANCE(>=30),DISCOUNT(20)) IF(ADVANCE(14-29),DISCOUNT(10))

• Result: A ticket added to a sale on 6/3/2015 receives no discount if the start date of the ticket is anywhere between 6/3/15 and 6/16/2015 – it receives a 10% discount if the start date is between 6/17/2015-7/2/2015 – it receives a 20% discount if the start date is 7/3/2015 or beyond.

Using Dynamic Pricing Rules with profit centers

You can use Sales screen action macros to change the profit centers and split of an item sold dynamically. Available macros include:

SETPROFITCENTERS SETPROFITCENTERSPERCENT SETPROFITCENTERSFLAT

For more information on these macros, see the Salesware Sales screen action macro Commands document.

Example of use in Dynamic Pricing Rules

Original Item Configurations:

Item: A 6-pack of Iced Tea

Base price: $4.00

Profit Center is set as 100% to Retail

Group1 = Retail

Group2 = Food Service

Group3 = Admissions

Profit Center 2 = ADMISSIONS

Profit Center 6 = F&B - FOOD

Profit Center 9 = RETAIL

Dynamic Pricing Rules that could be used for this six-pack Iced Tea item:

Rule #1:

• If the item is sold at a POS that belongs to the Retail salespoint group, the price is set to $15 and 100% revenue goes to Retail profit center.

• If the item is sold at a POS that belongs to the Food Service salespoint group, the price is set to $10 and 100% revenue goes to F&B - Food profit center.

• If the item is sold at a POS that belongs to the Admissions salespoint group, the price is set to $5 and 100% revenue goes to Admissions profit center.

The rule can be written as:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERS(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERS(6))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERS(2)))

Or:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERS("RETAIL"))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERS("F&B - FOOD"))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERS("ADMISSIONS")))

Or:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSPERCENT(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSPERCENT(6))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSPERCENT(2)))

Or:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSPERCENT("RETAIL"))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSPERCENT("F&B - FOOD")))

IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSPERCENT("ADMISSIONS")))

Rule #2:

• If the item is sold at a POS that belongs to the Retail salespoint group, the price is set to $15 and 100% revenue goes to Retail profit center.

• If the item is sold at a POS that belongs to the Food Service salespoint group, the price is set to $10 and 50% revenue goes to F&B - Food profit center and 50% revenue goes to Retail profit center.

• If the item is sold at a POS that belongs to the Admissions salespoint group, the price is set to $5 and 50% revenue goes to Admissions profit center and 50% revenue goes to Retail profit center.

The rule can be written as (using SETPROFITCENTERSPERCENT or SETPROFITCENTERS):

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSPERCENT(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSPERCENT(6,50,9,50))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSPERCENT(2,50,9,50)))

Or:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSPERCENT(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSPERCENT("F&B - FOOD",50,"RETAIL",50))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSPERCENT("ADMISSIONS",50,9,50)))

Rule #3:

• If the item is sold at a POS that belongs to the Retail salespoint group, the price is set to $15 and ALL the revenue goes to Retail profit center.

• If the item is sold at a POS that belongs to the Food Service salespoint group, the price is set to $10 and $1 revenue goes to F&B - Food profit center and the rest of the revenue (= $9) goes to Retail profit center.

• If the item is sold at a POS that belongs to the Admissions salespoint group, the price is set to $5 and $1 revenue goes to Admissions profit center and the rest of the revenue (= $4) goes to Retail profit center.

The rule can be written as:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSFLAT(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSFLAT(6,1,9,999))) IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSFLAT(2,1,9,999)))

Or:

IF(GROUP(1),SETPRICE(15.00) MACRO2(SETPROFITCENTERSFLAT(9))) IF(GROUP(2),SETPRICE(10.00) MACRO2(SETPROFITCENTERSFLAT("F&B - FOOD",1,9,999)))

IF(GROUP(3),SETPRICE(5.00) MACRO2(SETPROFITCENTERSFLAT("ADMISSIONS",1,"RETAIL",999)))

Reprocessing portions of Dynamic Pricing Rules

With the Dynamic Pricing tag <AlwaysReprocess></AlwaysReprocess> portions of Dynamic Pricing Rules can be reprocessed even when a sale is recalled at a salespoint with RecalculatePriceOnRecall=FALSE.

Portions of a Dynamic Pricing Rule which are always reprocessed are included in <AlwaysReprocess></AlwaysReprocess> tags.

Example: IF(DOW(SAT-SUN),SETPRICE(100),SETPRICE(80)) <AlwaysReprocess> IF(GROUP(3),MACRO2(SETPROFITCENTERS("DPC3"))) IF(GROUP(4),MACRO2(SETPROFITCENTERS("DPC4"))) </AlwaysReprocess>

If an item with this rule is recalled, and RecalculatePriceOnRecall=FALSE, the saved price is used as the base price and the portion of the rule between the <AlwaysReprocess> tags is treated as the full Dynamic Pricing Rule for this item. Because they could potentially be in sub-rules, the tags may be nested and there may be multiple <AlwaysReprocess> sections in a single rule. In the case of nested tags, the inner tags are ignored. In the case of multiple <AlwaysReprocess> sections, the different sections are concatenated to create the new rule. These tags only affect the behavior of Sales if RecalculatePriceOnRecall=FALSE and When Recalling Saved Sales Retain Line Item Prices As Saved is checked in SysManager > Preferences > Miscellaneous > Sales and only when recalling Sales. The specific reason this was added was so that Dynamic Profit Center Rules are recalculated on recall and so that Dynamic Profit Centers use the finalization location instead of the save location in their calculations.

Dynamic Pricing capability based on Specials (Dynamic Specials)

Dynamic Pricing Rules have the ability to attach to a Special and calculate the discounts applied by the Special. This allows more flexibility because it permits Dynamic Specials to be applied to regularly priced items. It also allows configuration of item Dynamic Pricing Rules to avoid long blocks of IF(SPECIAL(COUPON1), …)IF(SPECIAL(COUPON2), …). Finally, it makes a clear distinction for reporting purposes between static Specials and Dynamic Specials.

• A set of Items and Specials that mirror each other are configured. For example, if there is a Special named 300 there is also an Item named 300.

• Each Item that mirrors a Special has a Nickname or User Defined Fields (UDF) that matches the characters encoded in the barcode for the various coupon promotions.

Example: Barcoded vouchers are distributed to the public for Special 300. The barcode contains the characters 300. The corresponding Item’s Nickname needs to be 300 or the UDF on the General tab needs to be 300.

• On the Sales Actions tab of the 300 Item, SELECTITEM("DDDDDDDDDDCCCCCCCCCCIIIIIIIIII") macros are entered to add all admission items to the sale along with QUANTITY(0). The last macro configured is SELECTIVESPECIAL ("NICKNAME"). For example, SELECTIVESPECIAL("300 ").

Note: This is NOT the standard %%C1 coupon scanning option, but instead a multikey lookup function to add an item to a sale; and that item executes several macros.

Dynamic Specials configuration

• Implement the SPECIAL and SPECIALUDF conditions. TRACKSPECIAL no longer exists and the other rules support those functionalities.

• Dynamic Pricing function APPLYSPECIAL(<name>) was created which adds the specified Special or replace the existing Special with the new one. The rule makes sure that <name> is a real Special in the database (and item rules do not modify the discount amounts of Specials, this just applies the Special which is then calculated as defined in the Special configuration. This applied Special is not required to be linked to the item by the speclink table.

• Dynamic Pricing functions SETSPECIAL(<pct>,<amount>) and SETSPECIALPRICE(<finalprice>) change the special to act as a Type 1 or Type 2 special with the corresponding settings.

• Sales and ww.dll are responsible for calculating/re-calculating Dynamic Specials whenever they are attached to an item, similarly to Dynamic Pricing capability.

• Dynamic Pricing Rule Edit form offers a new value of Dynamic Special Rule as a new type of rule. • Specials Edit form offers a new Dynamic Rule type of special, which allows the user to choose the

previously configured Dynamic Special Rule records.

SysManager

• Support was added for spec_type=3 (Dynamic Special) to the Special configuration form. This allows the user to select any Dynamic Pricing Rule with dp_rules.rule_type=4 from the database to attach to this item. Because Items and Special Rules are not interchangeable (i.e., a Special Rule makes no sense on an item and an Item Rule makes no sense on a special) the user is not allowed to select rules of type Any (rule_type=0).

• dp_rules.rule_type=4 (Dynamic Special Rule) was added to the Dynamic Pricing Rule configuration form.

• Disallowed items from selecting rules with rule_type=4 for their dp_rule, Points4Sale Rule or Rental Rule and disallow accounts from selecting these rules for the account rule (i.e., no form that displays a list of dp_rules in SysManager displays rules with rule_type=4 except for the Special form).

SiriusSQL

Changes to the SiriusSQL database were made, which include the following:

• Specials table: New field called dp_rule_id was added and a new description 3=Dynamic Special was added to the spec_type column.

• Dp_rules table: New description 4=Specials Rule was added to rule_type column.

ww.dll

Support was added to ww.dll for Dynamic Special Rules. These rules can be assigned to a special and processed using all the conditions of the Dynamic Pricing interface (DOW, TSPAN, etc.). There are currently only a few value actions.

SETSPECIAL(<pct>,<amount>) and SETSPECIALPRICE(<finalprice>).

Example: IF(DOW(FRI),SETSPECIAL(50),SETSPECIAL(10)) IF(DOW(SAT), SETSPECIALPRICE(2.00))

This would be 10% off, 50% off on Fridays and a set price of $2.00 on Saturdays.

There are also two new conditions added:

SPECIAL(<name>) SPECIALUDF(<udf>)

The condition SPECIAL() returns true if a special is applied. If it has a name listed, it is only true if that special is applied (e.g., SPECIAL(DYNAMO) ) SPECIALUDF is true if the user defined field matches the argument.

Note: The Dynamic Specials calculate once for a line item (and not per day like Dynamic Pricing Rules).

Reporting

There is one report specific to Dynamic Pricing capability: ReportManager > Reports > Performance Reports > Dynamic Pricing Rules. This report can be run several different ways based on Item Rule vs. Account Rule and DCI grouping v. DP Rule grouping.

Sample report output:

Note: The Discounts column is used only if a special was applied to an item either manually by the operator or in some automated way (by using the MACRO or MACRO2 functions within a Dynamic Pricing Rule or a macro within the Sales Actions tab for the item).

Sample scenarios

The following are some typical applications of Dynamic Pricing Rules:

1. Corporate accounts receive 20% off of food items and 30% off of admission items. 2. The employee cafeteria sells the daily special for $3.00, but the guest cafeteria sells the same daily special

for $6.00. 3. A water park sells a logo T-shirt for $0 when a guest purchases a full-week admission product, otherwise

the logo T-shirt costs $19.99. 4. To celebrate a museum’s fiftieth anniversary, all admissions sales cost the same as they did on opening

day fifty years ago; which was twenty-five cents. This promotion is only good for the exact anniversary date.

5. Group tickets are discounted by 10% for quantities of 20-29, 12% with purchases of 30-49 and 15% with purchases of fifty or more.

6. A 10% multi-day discount is given to guests who purchase three, four or five day tickets. But in order to qualify for this discount, none of the days can be during the Fourth of July weekend (July 1 - July 4).

7. A food and beverage manager wants to set up a value meal. The meal always costs $7.50. The options that are available in the meal are a chicken sandwich (normal price $5.00), hamburger (normal price $4.00) or a

veggie wrap (normal price $4.00); fries or a small salad (both normally cost $3.00); and the choice of a medium soda (normal price $2.00) or medium bottled water (normal price $1.75).

8. A one-day ticket offers a huge discount if purchased for the last operating hour of the day. Normal price is $50, but if purchased for just the last hour the price is $5.

9. With an adult ticket purchase, a child ticket is free. Otherwise, the child ticket costs $5.00 10. Groups receive a 25% discount on group lessons, but only when the same lesson is taken at the same time

by at least fifteen or more people. 11. Use with Points4Sale capability. See Salesware User Guide for Beginning Users. 12. Use with multiple quantity auto sales (passes). See the Salesware Memberships and Passes document.

Dynamic Revenue Recognition capability

Revenue can be allocated at the time a ticket/pass product is scanned. Revenue associated with tickets/passes that are sold for future use can now be placed in a Deferred Revenue profit center and at the time the ticket/pass is scanned/validated through ScanMan or GateKeeper modules the revenue is moved from the Deferred Revenue profit center to the proper non-deferred profit center associated with the Recognize Revenue Rule attached to the ticket/pass product.

The Recognize Revenue Rule is configured in SysManager > Activities > Item/Sales Lists > Dynamic Pricing Rules. The rule must be configured as a rule type of Any or Recognize Revenue Rule to be assigned to a ticket or pass item in the Global Settings tab of the item's template. With current functionality the rule must follow the paradigm:

MOVEREVENUE( OLD_PR_CTR, NEW_PR_CTR, 20, 10, D,C,I, Salespoint, Operator)

Where MOVEREVENUE is the function, OLD_PR_CTR is the deferred profit center. NEW_PR_CTR is the non-deferred profit center. 20 is the percent of the deferred profit center to be moved to the non- deferred. 10 is the flat dollar amount to move from the deferred profit center to the non-deferred profit center. Either percent, flat dollar amount or both can be used in the rule. The value is set to 0 if not used. D,C,I is the department, category and item nickname of the item that is attached to the profit center adjustment in the data, salespoint is the optional salespoint that is written to the data(scanner location if not specified), Operator is the optional operator (blank if not specified).

When a ticket or pass is scanned that has a Recognize Revenue Rule, SalesEZ application passes off the rule in a RecognizeRevenue call to siriusutil.dll. The .dll makes the call to the data writing the information to a new transact record. The .dll then responds to SalesEZ application that the call was made. The new record in transact contains the adjustment to the deferred profit center and the non-deferred profit center sold to the item specified in the DCI setting, salespoint and operator as configured.

ValidatePass and ValidateCard call the new RecognizeRevenue function in SiriusUtils.DLL if the template for a validated pass or card is configured with a Revenue Recognition Rule in the Global Settings tab of the validation template.

In SysManager > Activities > Item/Sales Lists > Dynamic Pricing Rules there is a new dropdown, Rule Type, for specifying the type of rule. The types are:

• Dynamic Pricing Rule • Points4Sale Rule • Revenue Recognition Rule • Any

In SysManager > Item Edit > Actions > Action Specifics > Global Settings there is a new dropdown, Revenue Recognition Rule, for assigning a rule from the Dynamic Pricing Rule list that is assigned a rule type of Any or Revenue Recognition Rule.

In SysManager > Item Edit > Pricing > Dynamic Pricing choosing the Dynamic Pricing Rule dropdown displays rules of type Any or Dynamic Pricing Rule.

In SysManager > Item Edit > Restrictions the Points4Sale Rule dropdown displays rules of type Any or Points4Sale Rule.

In SysManager > Accounts > Account Edit > General tab the Dynamic Pricing Rule dropdown displays any rule of type Any or Dynamic Pricing Rule.

Note: When configuring validation to process revenue recognition, accesso recommends that you thoroughly test and confirm that Revenue Recognition is functioning properly. accesso Siriusware Technical Support will charge a fee to recover missing revenue on validations.

Messenger Service notifications

In order to receive notifications for failed revenue recognition, you can utilize Messenger Service application. Within SysManager, navigate to Activities > System Lists > Notifications. Add a new notification for 1320 - Revenue Recognition Upon Validation - Failed from the dropdown. Set the staff person and the method for notification. You can also set up notifications for reprocessed revenue recognition.

Revenue Moving rules vs. Consignment programs

IF(DCI(,,VOUCHERADT),MOVEREVENUE(*DEFERRED*, ADMISSIONS, 100, 0,CONSIGNMT,REDEMPTION,REDEEMADT))

IF(DCI(,,VOUCHERCHD),MOVEREVENUE(*DEFERRED*, ADMISSIONS, 100, 0,CONSIGNMT,REDEMPTION,REDEEMCHD))

IF(DCI(,,VOUCHERSNR),MOVEREVENUE(*DEFERRED*, ADMISSIONS, 100, 0,CONSIGNMT,REDEMPTION,REDEEMSNR))

Detailed explanations of the two features: Revenue Rules exist in order to move money from one profit center to another when a ticket is scanned. If there is no revenue to move, then the rules do not get triggered (for example, comp tickets). The most common use of Revenue Rules is to allocate revenue to a Deferred profit center when sold and later when the ticket is used, move it to another profit center.

Example: 5000 1-day tickets are heavily discounted at a trade show, let’s say $5.00 each. The client doesn’t want to recognize $25,000 worth of revenue the day that the tickets were produced in Salesware module because most likely, that happened during their off season. So instead, the client uses revenue moving rules to move 100% of the revenue ($5 per ticket) from Deferred to Ticket Revenue when the tickets are scanned.

Consignment Programs involve selling a bunch of tickets or vouchers to an account for bulk distribution to a partner, and then recording the redemption of those bulk vouchers back to the same account once they are used. The client may price the vouchers at $0 and the redemptions at the consignment rate or the vouchers at the consignment rate and the redemptions at $0 or they may put a price on both items and just ‘ignore’ one profit center in order to not double-count revenue. Where/when to recognize the revenue in a consignment program is a tricky decision and is the responsibility of the client’s accounting department.

Because Revenue Rules and Consignment both have a two-part process, the initial sale and the redemption and they both deal with revenue, it is easy to start thinking that Revenue Moving and Consignment can be used in conjunction to deal with the consignment issue of selling vouchers that cost $$ and recording redemptions that also cost $$, without doubling up revenue. Unfortunately, this is not true.

Revenue Rules only move money from one profit center to another using a DCI specified in the rule to record the move. Revenue Rules do not interact with consignment programs to perform auto-sales to accounts and cannot set the price of the auto-sold ticket. So, as tempting as it is to want to use revenue moving and consignment together, it just doesn’t work that way. In the future it may be possible to create an enhancement to make the two features more compatible with each other, but for now you must decide on using one or the other.

To enable the two features to work together, please see the following instructions. 1. Set up your Consignment vouchers to cost $$ and associate the Revenue Moving Rule with the voucher

access template (example rule is attached for reference).

2. Make your redemption items cost $0.

3. Set up the normal consignment account that includes an auto-scan invoice.

4. Sell the vouchers to the appropriate account:

5. Note the profit center for the voucher sales:

When the tickets are scanned to do the auto-sale back to the account (using the %A function in Sales in this example), note that the price of the redemption item is still $0. It does NOT get set to the “move” amount specified in the Revenue Rule for that particular access number:

Note: The revenue is moved according to the rule:

However, the account history always reflects the $0 redemption amount. You never see the original voucher amount go down and the redemption amount go up on the account itself. You can still use the account to know how many vouchers were originally sold, and then redeemed, but you lose the ability to know how much revenue the redemptions are worth per account. Also, you may have to specify a 0-admission DCI in the Revenue Rule and a 1-admission DCI for the auto-sale (or vice versa) in order to prevent double counting admissions at the time of redemption.

Automated Revenue Recognition on expired and un-used tickets/passes

At times visitors purchase tickets and do not actually visit the site by the expiration of the item or they do not attend at all. Previously un-used and expired tickets did not move to recognized revenue and therefore could not be properly accounted, despite actual revenue being actualized. In order to automate the process of recognizing revenue in these circumstances and enhancement was created to push this revenue and actualize these amounts.

Configuration

SysManager

The following changes have been made to SysManager in support of the Automated Revenue Recognition on Expired and Unused Tickets/Passes enhancement:

• Profit Center edit dialog: added Deferred Revenue check box. Used for reporting purposes on Revenue Recognition Report on expired access and pass records.

• Dynamic Pricing Rules Edit dialog: added option Rules to process on an expired access/pass records text field to use when processing Revenue Recognition on expired access and guest pass records.

Note: This option applies only on Revenue Recognition Rule types.

Note: In order to use the new automated revenue recognition on expired tickets, the Revenue Rule also needs to be populated for validation scans, even if the client does not intend to use that section of the Dynamic Pricing Rule Edit form.

• Data Maintenance: added new option to Reprocess Failed Revenue Recognition On Expired Access or Guest Passes. This option is used to mark access or guest passes for reprocessing by Export Service application that failed Revenue Recognition. This is used once a problem is corrected or to “retire” expired or unused records so they are not reprocessed and no longer appear on the list.

Export Service

The Export Service application has been enhanced to allow it to recognize revenue for access tickets/guest passes that have expired. The following must be performed in order for this enhancement to work properly:

• The ww.dll must be installed on the same computer as Export Service application • The following section and settings must be added to the ExportService.INI file

[ExpiredRevenueMove]MinDays=0MaxDays=60Operator=EXPORTSalespoint=EXP01UseExpirationDateForTransaction=TRUENumRecordsToProcessAtATime=100DefaultMoveExpiredRevenueRule=MOVEREVENUE(DEFERRED,RECOGNIZED,100,0,,,)

• MinDays/MaxDays - the range, in days, to search for expired tickets. The default value for MinDays is 0 and MaxDays is 30. These can take floating point values, i.e., the user can set this to a floating point value such as 0.1 which equates to 2.4 hours.

• Operator - the operator to use to populate the tables when recognizing revenue on expired tickets/passes. The value set here is only used if the MOVEREVENUE Rule for expired records does not already contain an operator. A valid operator needs to be defined in either the MOVEREVENUE Rule or in the ExportService.INI file or the revenue moving transaction fails.

• Salespoint - the salespoint that is used to populate the tables when recognizing revenue on expired tickets/passes. The value set here is only used if the MOVEREVENUE Rule for expired records does not already contain a salespoint. A valid salespoint needs to be defined in either the MOVEREVENUE Rule or in the ExportService.INI file or the revenue moving transaction fails. If no salespoint is defined in either place, the computer name, truncated to six characters, is used instead which causes the transaction to fail because the computer name is not a valid salespoint.

• UseExpirationDateForTranstion - uses the expiration date of the ticket or pass as the date for recognizing the expired revenue if it is set to TRUE. If set to FALSE, then the current date/time is used. This setting defaults to FALSE.

• NumRecordsToProcessAtATime - used to limit the number of records that are processed at a time. Initially, Export Service application checks the server for records to process at approximately ten second intervals and attempts to process the number of records designated with this setting. If records are found to process, Export Service processes the records and continue checking and processing records at approximately one second intervals until all records are processed. After processing is complete, Export Service returns to checking the server at approximately ten second intervals. This setting defaults to 1000. This setting can also be used to disable this feature by setting the value to 0.

• DefaultMoveExpiredRevenueRule - the Revenue Moving Rule to use on expired tickets/passes if the ticket/pass item does not have a rule defined for recognizing revenue on expired records.

Additional tasks performed by Export Service application • Export Service writes a 1322 entry into the sp_log table when it fails during any part of the revenue

recognition transaction on an expired ticket/pass. • Export Service also writes a 124 activity type into the gst_actv or acc_actv table when it fails trying

to process revenue on an expired ticket/pass. • Export Service write a 125 activity type into the gst_actv or acc_actv table if it successfully

processes an expired ticket/pass but the ticket/pass does not have any remaining revenue to be moved.

ww.dll

The ww.dll has been enhanced to support Automated Revenue Recognition on expired and unused tickets/passes as follows:

Two new parameters have been added to the recognizerevenue function • macrotouse - allows the caller to define the macro to use to recognize revenue. If this is not entered, it

use the rules column in the dp_rules table (original behavior). • info_type - allows the user to specify the info_type number when it inserts a new entry into the

tr_info table. If this is not specified, then a 31 is used (original behavior).

Example: <func>recognizerevenue</func> <table>access</table> <passno>2926007000</passno> <macrotouse>MOVEREVENUE(*DEFERRED*, EXPIRERECOGNIZE, 100, 0, TICKETS,MOVEREVENU,EXPADJTIX, EXPRT1, MIKEG)</macrotouse> <info_type>32</info_type> <operator>EXPORT</operator> <salespoint>EXPRT1</salespoint>

The recognizerevenue function now fails if any of the parameters are not valid, i.e., move from profit center, move to profit center, salespoint name, operator name, and DCI.

Reporting

Three new reports have been created for Revenue Recognition activity, Revenue Recognition Summary, Revenue Recognition Detail, and Revenue Recognition Profit Center Split.

Revenue Recognition Summary Report

This report summarizes information related to Revenue Recognition products, including revenue earned and deferred in the original sale, revenue recognized via scanning, expiration and returned revenue activity and the total uses and calculated deferred revenue remaining. Report can be filtered by Date Sold, Processed or Expired, by the selling and/or processing salespoint, by the Pass DCI and by Pass #.

Revenue Recognition Detail Report

This report offers detail down to the Profit Center split for all transactions related to Revenue Recognition items, whether the original sale, revenue moved via scanning, revenue moved via expiration or any possible return or exchange. Filterable by date pass was sold, date the revenue activity took place, by ticket/pass DCI, by selling salespoint/group, by revenue activity salespoint/group and/or by pass# directly.

Revenue Recognition Profit Center Split Report

This summarizes Profit Center splits by DCI or by Ticket/Pass # for Revenue Recognition items, whether from the original sale, revenue moved via scanning, revenue moved via expiration or any possible return or exchange. Filterable by date ticket/pass was sold, date the revenue activity took place, by ticket/pass DCI, by selling

salesware dynamic pricing - accesso technology group · dynamic pricing rules are used to set the...

Documents