Happy Hour prices with portions

So I was planning to implement the HH only parts of this setup as in this tutorial

However I see a problem with my specific setup and wanted to get some advice before I started. The menu uses portions, and different types of portion depending on the item (i.e. might be Pint / half pint, or Glass / bottle, small / large, etc.). Product Tags can’t work with portions for the price changing as in the tutorial and it’s going to get too complicated if I start creating multiple product tags to work with each type of portion. I want the system to be easy for the client to use for updating products later on.

Is there any way I can get this to work with price definitions instead? But I did some initial tests and they are not as flexible - I think the only way I can change for a product is to update the whole price list? And, if I add a HH price definition using a Change Price List action, there appears to be no way for me to remove the HH price definition (i.e. go back to the “default” price)?

UPDATE: I wasn’t using the Change Price List rule properly, it needs Department to be passed otherwise it doesn’t work. Anyway still it seems I can only change the price list before items are added to a ticket, if I am in a ticket and change the price list, it doesn’t affect any items if I have added one item already to the ticket.

Thanks :slight_smile:

Ok so it would appear my only way to use portions and have HH with different prices set per portion at HH is to use the “other” method of Triggers. But I was put off that because of the whole problem about having a ticket open when HH comes into effect.

So if I do have to use triggers to start / end HH, I assume I also have to have rules in place to handle checking HH time on application start as well?

Must be getting late for you like me.
So you are not using {PRICE} to calculate the HH Discount right? So wondering if there is a {PRICE} Tag you can use for portions? Umm searching now it may seem {PRICE} may equal Menuitem or Portion…

Ok this might be useful - [:OrderTagPrice] if that is the Portion Price then you can use what I do in my HH & VIP calculations: EDIT: Try {PRICE TAG} as I think instead of OrderTagPrice

HH Calculation

[=-1*TN('{PRICE}')*(TN('{ITEM TAG:HH}')/100)]

Let me know if it works by putting using the OrderTagPrice as I may come up against this as well, thanks.

Note: Q’s original setup does not use {PRICE} percentage so I am storing a % not a fixed deduction so it can be used in all scenarios.

Try read this but get some Panadol! lol

Read this and the next 3 posts:

I got it working on more simple setup with just using Triggers. I haven’t used Triggers before, you do get the problem of if the HH starts and you are in a new ticket, you need to close and reopen to get the HH pricing, but this is the simplest setup I can do at the moment that will support Price Definitions for HH pricing and therefore work fine with Portions.

Have to use one action per department because it appears I can’t leave department blank to have it affect all departments.

I added a Display Popup to show start / end of HH and mention about the open ticket issue.

From what I’ve read on the forum, Triggers will fire on application start if the schedule has been missed. I noticed a slight issue when testing if I set start and end triggers one minute apart and they both fired at the same time when starting the application (i.e. close app, start HH at 21:23, end HH at 21:24, open app at 21:25) it looks like they both fired but the HH price was still active but in reality they will be further apart. I don’t know if there is any issue about how triggers are queued if multiple are missed on application start, other tests of over a minute between them worked fine so hopefully it was just a one off issue.

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:

Carolina cabernet (wine)
Portion - Glass - Price: 54.00 / HH 46.00
Portion - Bottle - Price: 235.00 / HH 198.00

Portion - Pint - Price: 49.00 / HH: 34.00
Portion - Half Pint - Price: 27.00 / HH: 22.00
Portion - Bottle - Price: 45.00 / HH: 33.00

Jack Daniels
Portion - Normal - Price: 58.00 / HH: 49.00

Sparkling Mineral Water
Portion - Small - Price: 40.00 / HH: 35.00
Portion - Large - Price: 60.00 / HH: 55.00

My concerns are both complexity and also having a system that is easy to manage and client to update themselves…

Ok, that is a PITA.

But there is hope. Use JScript, or simply {REPORT SQL DETAILS:} to pull the price for the Portion from the Price Definition/List.

Basic query:

mi.[Name] as [MenuItem]
,po.[Name] as [Portion]
FROM [MenuItemPrices] pr
JOIN [MenuItemPortions] po on po.[Id]=pr.[MenuItemPortionId]
JOIN [MenuItems] mi on mi.[Id] = po.[MenuItemId]
AND mi.[Name] like 'Wine Red'
AND po.[Name] = 'Bottle'
--AND [PriceTag] IS NULL
AND [PriceTag] = 'HH'
1 Like

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. :slight_smile:

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… :wink:

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… :slight_smile: fun fun :stuck_out_tongue:

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 …


{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}


{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}


{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…

1 Like

@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.


Appreciate your comment guys, just shows how varied our market places are and highlights how Samba is good are handling each variation.

Just one last question if we are handling portion pricing without SQL, do we have access to the portion price?

1 Like

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.

Ok see this link:

Not sure if its relevant…?

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…