Utility to update pricemaps

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.

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!

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.