Utility to update pricemaps

I don't have a utility to do it, but the way I set up our dynamic pricing was to put all the possible pmaps on all the pricetypes in question during initial setup, but only the "original" price has valid dates. The secondary maps have specific dummy dates in the past so I can keep track of them when they're inactive. Then I have a scheduled job that runs nightly that changes the various start and end dates of various pmaps depending on how many tickets have been sold, and by referencing the dummy dates, etc. It's sort of clunky, and depending on your setup there may be an easier method, but so far this has worked for me.

Our intrepid DBA is out on vacation this week,  but he has built us a wonderful gadget that allows us to add price maps on to prices.  It is kind of like season manager, but it does not overwrite existing price maps.  So far we have only ever raised prices by $5 at a time, so I have a couple of price maps for each house that are $5 increases.  When we are ready to raise prices on a show I use the gadget to dictate which performances, and which price types get the new price maps added on.  What is great about using the gadget instead of season manager is that I don't have to worry about what the original price map is (weekend vs. matinee price, etc).

If this is something you might be interested in we can check in with Bob when he returns from vacation to see if he can put it together to share.

Bob gets back in the office next Monday, and I will see if he can put all the code together to share then.

Boann

------------------------------ IMPORTANT NOTICE ------------------------------
This email transmission and any accompanying  attachments contain confidential
information intended only for the use of the individual or entity named above. 
Any dissemination, distribution, copying or  action  taken in  reliance on the 
contents of this email by anyone other than the intended recipient is strictly 
prohibited. If you have received this email in error please immediately delete 
it and notify sender at the above email address. 
------------------------------ IMPORTANT NOTICE ---------------------------

Thanks for the replies. Our price increases are completely random (ok, maybe not random, but unpredictable). We can change prices $3 in some sections and $10 in others, so creating "standard" pricemaps for those increases wouldn't really work for me. I would still love to pass your wonderful DBA's work on to our wonderful DBA to see if it would be a good place for him to start.

My next question is: What is the advantage and/or disadvantage to 1) creating new pricemaps for the incremental price increases and adding them to the original pricemap or 2) creating completely new pricmaps which reflect the full value of the new pricing and expiring the old pricemaps?

Thanks all!

For us the biggest issue in deciding between the two was that certain reports, and the season overview, count "seats" based on "active 'tickets' pmaps" , not actual seats. We didn't want the increase to show up under "other" on Season Overview and we also didn't want the seats double counted. So that's why we went the "end the old pmap, start a completely new one with the new full value" route. But I can see the other side of it where having that money in "other" could be a totally desirable way to segregate the gain, and that would avoid the double coutning issue. So a second (or third or fourth) map that just adds the additional amount could be quite tidy.

We like having the increased amounts in their own price map to see how much additional income we received by raising the prices.  To avoid double counting like Amanda talks about (and that one really threw us for a loop when we first started this) we use a different price map category for the increase amounts.  So the base price of the ticket uses the ticket price category, while the increase amounts uses the ticket price raise category. 

Because of our pricing structure and the number of shows we raise prices for at once, ending one price map and starting a new one using the season manager is rather complex and prone to error, while adding an additional price map onto existing maps is both easier and safer.  If we were only updating one performance at a time, I would be more inclined to go into performance setup directly and make the adjustments there. 

There is no reason you could not create the price raise price map as you need it.  Since we always raise our prices $5 at a time, it is just easier for me to build them all into place at once.

Hi. I'm the guy who built the gadget Boann is talking about. It was coded in Visual Basic and runs on Windows XP, which is the operating system we use here at Portland Center Stage. It may run on Windows 7, but I haven't tested it. For those interested, I've put together a very brief description of the interface (in an MS Word .Doc file) which I will happily email to anyone interested in further information. We have no plans to market this, and thus it would be provided gratis, 'as-is', and technical support would have be very limited. However, if it can help anyone, I'm happy to pass it along. If you have questions or need more information, it would probably be better to talk to me directly rather than clog the forum with technical chat. Try me at 503-445-3726, or email bobt@pcs.org

Best,

Bob Thomas, DBA, Portland Center Stage