Price Definitions/Lists and Triggers have too many inherent “problems” to work reliably, for the exact reasons you state.
We have Portion Changed Event. You should be able to set in motion the discount automation from that event.
Perhaps by doing something like changing the DiscountType Order State to ND or HP or some other specific value (ie. PC for PortionChanged). Then you capture Order State Updated Event and test for that “PC” value, which then fires time-based-constrained Actions to apply the discount on the price as usual.
That ^ should work, especially if your discounts are a static percentage. Or are you saying that the percentage is different based on the Portion (ie. 10% for large and 5% for small)? Even if that is the case, Product Tags for each Portion should work.
No, HH prices are fixed, not percentage or value discounts.
So @QMcKay if I were using your method without triggers, I would amend to use the Product Tag value as the price instead of it being a discount, it’s more straightforward that way.
But then I have the problem with so many different portion types on different products. Price definitions handles it fine in this respect, but product tags doesn’t. Here is some examples:
SELECT
mi.[Name] as [MenuItem]
,po.[Name] as [Portion]
,[PriceTag]
,[Price]
FROM [MenuItemPrices] pr
JOIN [MenuItemPortions] po on po.[Id]=pr.[MenuItemPortionId]
JOIN [MenuItems] mi on mi.[Id] = po.[MenuItemId]
WHERE 1=1
AND mi.[Name] like 'Wine Red'
AND po.[Name] = 'Bottle'
--AND [PriceTag] IS NULL
AND [PriceTag] = 'HH'
I see, so you mean pull the price into the part of your tutorial where it changes the price?
That sounds like a good solution, thanks. So I am still setting up the system at the moment, and I already added the trigger method and “working” so at least I know I can add all the products and use price definitions, and once I completed all that I will look at changing the HH to use your non-trigger method.
Yeah definitely… however I have an even bigger PITA request regarding HH and VIP discounts from another client. Hopefully gaining experience with this setup I can solve it myself, but it might also be coming your way for a bit of help…
You got me thinking about it using Price Definitions which are great in the way of simple price management when the discount is not static. It is an interesting concept, but we did not have the “tools” in V4 when the setup was developed. Now we do with V5.
I’m going to put something together using JScript/SQL. I think it might be a little too complex for {REPORT SQL DETAILS:} given that not every Product will have HH Price… so we need to account for that and pull the “NULL” PriceTag Price instead. . . . or maybe it isn’t too complex using a couple Program Settings, but I will work it out in JScript first.
I think it would be a good update on your tutorial. Because you handle the value discount right now, but would be good to use price definitions for fixed price, and also add a bit about doing % discounts as well for those that need that. Then it becomes a one place for all.
From a client updating point of view, I really like price definitions and the price list editor, it is very easy to make mass price changes that way and I think it’s a feature that gets forgotten about sometimes due to it’s inability to work with some other features.
Since we are discussing, I will briefly mention the other setup I will have to do in the future, but not related to this one so I don’t want to confuse things! They use VIP with different levels % discount, and HH is based on some items only and those items are 2 for 1, and they use inventory so needs to take into account, so 2 items need to go through on ticket, and then be charged for 1, and 2 need to come off inventory… then the VIP I can’t remember either VIP overrides HH or other way around but that’s the simplest part. I struggle to get my head around all the possibilities and also making sure staff would not be able to add 2 items, get HH discount and then remove one item and either get that one item for free or 50% off depending on how it was setup. And then there is the complexities of multi buy discounts like I saw from other posts where it works ok if you have 2 bought but then gets more complex for 4, 6, 8, etc… fun fun
There is a bit more to it than what follows having to do with checking times and States, but…
These 3 queries to store prices …
PriceREG:
{REPORT SQL DETAILS:SELECT pr.[Price] FROM [MenuItemPrices] pr JOIN [MenuItemPortions] po on po.[Id]=pr.[MenuItemPortionId] JOIN [MenuItems] mi on mi.[Id] = po.[MenuItemId] WHERE mi.[Name] = '{PRODUCT NAME}' AND po.[Name] = '{SETTING:Portion}' AND [PriceTag] IS NULL:F.Price}
PriceHH:
{REPORT SQL DETAILS:SELECT CASE WHEN count(1)>0 THEN isnull(sum([Price]),0) ELSE isnull(sum(0),0) END as [Price] FROM [MenuItemPrices] pr JOIN [MenuItemPortions] po on po.[Id]=pr.[MenuItemPortionId] JOIN [MenuItems] mi on mi.[Id] = po.[MenuItemId] WHERE mi.[Name] = '{PRODUCT NAME}' AND po.[Name] = '{SETTING:Portion}' AND [PriceTag] = 'HH':F.Price}
PriceVIP:
{REPORT SQL DETAILS:SELECT CASE WHEN count(1)>0 THEN isnull(sum([Price]),0) ELSE isnull(sum(0),0) END as [Price] FROM [MenuItemPrices] pr JOIN [MenuItemPortions] po on po.[Id]=pr.[MenuItemPortionId] JOIN [MenuItems] mi on mi.[Id] = po.[MenuItemId] WHERE mi.[Name] = '{PRODUCT NAME}' AND po.[Name] = '{SETTING:Portion}' AND [PriceTag] = 'VIP':F.Price}
I think there may be a simpler way to get those ^ Prices. And I think it would be better to store them as Hidden Order States upon Order Added Event so that they are only queried once.
And then we use Update Order Action to flip the Price definition…
I am going to completely rebuild the Tutorial from the ground up using Price Defs/Lists.
It looks really good. It is actually changing the Price Tag and the Order Price. It also Tags the Order with the Amount of Discount as the Order Tag Note which it derives from subtracting one price from another. The Tag is informational - it has no value - that is, it is not subtracting from or adding to the price …
Sorry to keep jumping in here guys but it seems what you are doing by requiring the user to enter a discount for every item and portion is a lot of work? I used menuitem tags as I did not know better but at least used a % to make it more durable.
@QMcKay would it not be better to just have 3-4 {SETTING:x} vaiables to control a discount % for the level? I know Mark says he used fixed discount (client always right) but for the general population a % would be much easier. Actually in Oz I have not come across a system using fixed amounts…
@pauln I don’t think he is meaning to replace what already exists, he is just saying this is another method that works for what I need and for any others who want to use fixed item prices for HH / VIP. Of course I also agree with you, having a few % discounts is far more easier than all this, however client somehow wants to make their menu complex which is nothing to do with me, I don’t know why their pricing is like that and also in Hong Kong, you’d be surprised about the amount of silly complexities to menus and pricing that goes on for no apparent reason (maybe they want 10 cents more profit or something!)…
@pauln, I won’t abandon what I use now, because for me, it is simpler (I use fixed discount amounts).
I still had to Tag every Product in the “original” method, and using the Price List Editor isn’t really much different.
As @markjw suggests, it is just to show another method. Especially in the case he speaks about, the current method will not work, because the amounts are not fixed nor percentage.
I have it all working now with Price Defs/Lists, using “Pricing Order States” to cut down on the number of queries to DB. Also Tags the Orders with info as shown above, though it isn’t necessary. Will post setup tomorrow.
I thought there might be something like {PRICE:<priceTag>} (ie. {PRICE:HH}) but it does not appear to be the case. There is {PRICE TAG} but that just shows the Price Definition Tag such as HH or VIP1, VIP2, VIP3, etc.
So I stuck with REPORT SQL DETAILS to pull the Price for the Portion, since each Price Tag has individual pricing options for each Product Portion. We could not do this method with V4, but V5 makes it simple …
Umm, again glad I asked as I could see that issue looming. What about [:OrderTagPrice] or there is [:PortionPrice] available from Entity State Change Rule I think? I se if I can find the link again…
[:OrderTagPrice] will not help in this case, because we are not talking about Order Tags; rather Portion Prices … so maybe [:PortionPrice] could be used - I will look into that.
So it seems [:PortionPrice] is only accessable on Portion Changed even, so it won’t help much.
We need to get the Price when:
the Order is added to the Ticket (SQL is needed)
when the Portion changes ([:PortionPrice]could be used)
I am sticking to SQL in both cases, because I just fire the following Automation Command in both of the above scenarios, and since I am subsequently storing all of the queried data as Order States, the SQL only executes once in most cases, or twice in the case of a Portion change…
Hey @QMcKay - now that I have discovered ‘Price Definitions’ I can see the old Custom Tags are obsolete
So far we have 5 pricing levels defs: Price (default); Happy Hour; Staff; Functions; Trade and these do not include VIP Levels yet. Given portions are a feature in our design have you managed to plot any further with this implementation.
I am considering keeping a Price Tag on the Customer which automatically sets Price Definition as well.
