@QMcKay I think I’ve used wrong term. Active / Inactive does not have any significance. When it appears as Active this means discount application procedure executed however there might be no discount available as there is no selected customer or there is no discount configured for product. Maybe clearing that state after Activate Discount is the best solution as active/inactive has no use other than debugging.
1 Like
Thanks for the explanation @emre… I understand now.
I like the way it is displaying with the additional Rule… I like information like this to be present so I know exactly what is going on in a Ticket or Order.
Though I suppose clearing the States when InActive would be just as good… hmm… I’ll think about that, and if I decide to go that way, I’ll post the appropriate Rule Changes.
2 Likes
If you have different portions, you’d better use a percentual discount (instead of a fixed price discount), since you cannot have the D1,D2&D3 tags set separately for different portions.
It should also be possible to change the system a bit so you can choose fixed or percentual discounts in the product tags. For example:
- D1: 10%
–> in theUpdate Discount when order discount becomes activerule you have theUpdate Order Discountaction two times:
– one with a constraint that checks if the last character is a “%”, with the Discount value calculating the discount as a percentage (the last character has to be stripped out first)
– one with a constraint that checks if the last character is NOT a “%”, with the Discount value calculating the discount as a fixed discount
This way you can still use fixed discount amounts, but switch to percentual discounts for products with different portions.
I updated the first post to reflect the latest changes:
- no need for
hard refresh ticketaction - portion change rule
-
Ticket entity changedand no customer selected --> deactivate ticket discount
1 Like
It would be nice if we could have these discounts included in the Discounts account.
I’m not sure how to best approach this though.
I’m thinking maybe this could work: at Payment Processed event, create an account transaction which puts the total discount amount in Discounts account, and also adds it to Sales account.
I’ve tried to access the total discount value with this (but it’s not working, I get 0.00 every time):
[=-1*({ORDER TAG TOTAL:D1}+{ORDER TAG TOTAL:D2}+{ORDER TAG TOTAL:D3})]
It seems like this information is not available at Payment processed event…
EDIT: I forgot to use TN in the expression, I know it should be like this:
[=-1*(TN(‘{ORDER TAG TOTAL:D1}’)+TN(‘{ORDER TAG TOTAL:D2}’)+TN('{ORDER TAG TOTAL:D3}))]
but even just {ORDER TAG TOTAL:D1} or {ORDER TAG TOTAL:D2} or {ORDER TAG TOTAL:D3} show 0.00 in a Show Message action…
In the Order State Updated and Ticket Total Changed events it’s also not available…
EDIT: @Jesse just pointed out to me that D1 is the tag’s value, not it’s name (duh) 
so we just need {ORDER TAG TOTAL:Discount}
1 Like
I’m getting closer to a solution without need for ORDER TAG TOTAL, but I ran into an issue with the Order Untagged event.
It has a variable called [:OrderTagPrice] which always has null as value when it’s triggered after cancelling/voiding an order.
Is this normal behavior @emre? Is there any way we can get the order tag’s price at Order Untagged event?
It also has variables [:OldOrderTagCount] and [:OldOrderTagQuantity], but no variable like [:OldOrderTagPrice].
What I’m doing is this:
When an order is cancelled or voided, I call the Untag Order Action to remove the discount tag.
At Order Untagged event, I want to deduct the order tag’s price from the ticket total discount (a program setting).
But at this time the order tag’s price is not available for some reason. I don’t know if this is something that can be resolved or not…
EDIT: Nevermind, I’m going for the first way to do it with ORDER TAG TOTAL (no need for all this)
Hmm… not sure what I did differently this time, but since I set this up a 2nd time from scratch just now, I find that I need to remove {QUANTITY} from the calculation. My setup is slightly different, as you see here:
[=-1*(TN('{ITEM TAG:D{ENTITY DATA:Customer:VIP Level}}'))]
Also, I’ve added more constraints to 2 current Rules and 2 new Rules to handle Gifting/UnGifting.
Now I need to take a look at how to prevent applying a Discount if we are in Happy Hour (Price Tag HH)!
EDIT: Adding this constraint does the trick.
{PRICE TAG} Not Equals HH
@emre, how do I read the value of the Current Price Definition in use?
Even though the Rule Constraints shown in the above Rules use {PRICE TAG} and that works properly, I cannot for the life of me figure out how to display the Price Tag. Specifically, I was hoping to display it in Application Subtitle, and Popup. I have tried:
{PRICE TAG}
{:PRICETAG}
[:PriceTag]
{:PRICE TAG}
{SETTING:PRICE TAG}
{:CURRENTPRICETAG}
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?