You can store it as a program setting at the moment you switch active price tag.
1 Like
Okie Dokie, will do, thanks!
EDIT: @emre, Not working for me … trying to store {PRICE TAG} in Program Setting…
Here is what I’m trying to do: use Triggers to Activate/Deactivate Happy Hour, but also allow for Manual Activation via Automation Command.
I realize I could hard-code the Program Setting as <blank> or HH based on criteria, but I figured why not use what is available to us already … but hard-coding will suffice…
lol there is no {PRICE TAG} tag 
I meant storing HH Active or HH Inactive values as a setting.
PS: Listed {PRICE TAG} tag useful for reading order’s assigned price tag. That works for orders.
Really? Not to question the Master @emre, but… Are you sure? Because the following works as a Rule Constraint…
Tested …
1 Like
Ah Ha!!! Ok, that makes sense now… it works on the Order-level, but is otherwise not available for use! No worries, good to know!
1 Like
The header section on the tag list will give an idea about listed tag relates to what… I mean this tag is useful to read order properties and it returns assigned price tag to order. It works because you used {PRICE TAG} inside order state changed event. You are not testing active price tag here You are testing order’s price tag so even after you disable happy hour it will still return positive.
As a general rule terminal specific values (not ticket or order related) can be accessed with {:CURRENTXXX} settings. So what you need to search for that case is {:CURRENTPRICETAG} setting but it is not available. What I’ll do to make that setting available to you is just pushing it as a program setting like you do with Update Program Setting. However there is a difference here. CURRENTPRICETAG is not terminal based. It is system wide so handing it manually will be a better choice.
1 Like
I’m wondering why you are using two different features together? I think your solution is awesome however it can be easier to manage if you use either price def.s or discounts for both happy hour and VIP discount implementation. I’m asking it to understand if it is a business requirement or something in SambaPOS forces you to do so…
Yes, Ok, I understand. Thanks for the detailed explanation @emre… I’m sure it will help other people to have a better understanding of Tags and their availability, Terminal Settings, and Program Settings!
Yes. I thought a little detail about that might help someone else.
Basically, in my case, Happy Hour Price Definition gives exactly the same discount value (-10) to all people, not just VIP customers (my “regulars”). Implementing the VIP discount has allowed me to do away with a Menu Category that I had called VIP which contained select products at reduced prices.
During testing, what I realized was that if HH was in effect, the price was discounted by 10 by HH Tag, and again discounted by 10 due to VIP Discounting, resulting in a discount of 20, which is not what I want… so I had to remove VIP Discount if we were in the middle of Happy Hour.
As far as having a Trigger and an Automation Command available to control Price Definitions, I did that because it gives me more concrete control. I’m not sure if my Triggers are not set properly, but I have seen on many occasions that the Trigger gets missed somehow - that is, HH doesn’t get turned on when it should. Maybe you can see something wrong here …
I think we can review the way we’re handling happy hour. Maintaining a system wide (department) setting and updating prices accordingly is a legacy feature coming from V2.
We have Date based comparison features in rules so we can do same thing without using triggers or knowing if hh is active or not. When an order added we can test if current time is inside a specified range and execute update price actions or not. {DATE:XXX} tag will help a lot.
Not a bad idea @emre… just trying to wrap my head around a good way to handle that.
I mean, Price Definitions are a simple and effective way to define pricing for select products via a Tag, so I’m not sure we would want to stray from that, but I’m fairly certain that is not what you’re getting at. Instead, you are talking about foregoing Trigger usage, and performing checks during Order Added to Ticket, correct?
Please remind me, what kind of data can we get from {DATE:XXX}? Can we extract Day of Week?
For example, my Happy Hour runs as follows:
Monday, Tuesday (MT): 1500-1700
Wednesday, Thursday, Friday (WTF): 1600-1900
Saturday, Sunday (SS): none
Then, we want to combine that with checks for VIP Discount, so that we are not applying 2 Discounts at the same time.
EDIT: ok I found {DATE:X} formatting… what a PITA that was to find for some reason (searching for {DATE:X} returns no results whatsoever - must be a Forum thing).
EDIT2: Now that I think of it more, we wouldn’t need Price Definitions at all. Just another Custom Product Tag instead (named HH) … correct?
Yes it is what I’m thinking.
We should change execution rule to Matches All and also decrease weekday check to a single constraint as {DATE:ddd} Matches Mon|Tue.
This is not a general recommendation for everyone but as you’ve already have a product based discount implementation you don’t need price definitions for hh implementation.
PS: I think something conflicts with :X so {DATE X} search returns better results.
PS2: We might not need TN function for {DATE:HHmm} as greater/less comparisons already tries to convert left part to a number. TN is still useful for greater/less comparisons if left part is a formatted number that might have regional decimals or thousand separators.
1 Like
Thanks for that @emre - I didn’t know we could use an OR operator there.
I think you’re correct. I was having trouble getting the Rule to fire, so I thought it might need TN(), but it turned out that it wasn’t working because I needed to use {DATE:ddd} Matches Mon instead of {DATE:ddd} Equals Mon.
That might be a casing issue but Matches will work better as it makes a regex match. That’s why we can use | operator.
@emre, I’m noticing something strange with States. For example, when I update Ticket State to “Active”, a rule fires to update Order State, and the Order State is being set the same as the Ticket State, which I do not want.
In this message, I am displaying:
TS:{TICKET STATE:VIP}
OS:'{ORDER STATE:DiscountType}'
The Ticket State is correct with “Active”, but the Order State is showing the same value - instead it should be displaying HH or VIP…
Is it a bug? Let me test that. Can you PM me a backup?
I figured it out.
In the Actions to update Ticket State and Order State, I was using a variable named [:State], which I assume is Reserved. I’ve changed the action variables to [:TState] and [:OState], respectively, and it is behaving normally now.
1 Like
@emre, any chance we can get access to Order State and/or Order Tag inside Ticket State Changed Event?
I store either VIP or HH inside {ORDER STATE:DiscountType}.
When Ticket Entity is removed or changed (non-VIP), the Ticket State is updated to null or InActive, and it fires Actions to update Order State. I’m trying to prevent the removal of an HH Order State, and/or the replacement of an HH Order State with a VIP Order State.
As I watch the cycling through the past Orders, I realized that neither {ORDER STATE:DiscountType} nor {ORDER TAG:HH Discount} are available in the Ticket State Changed Event.