Ticket Order Count EXP Constraint

Hi everyone,

I am creating a setup with some extensive happy hours, 2for1 deals etc. I am using order states because I want to report it all later separately from general sales breakdown.

So what I want to achieve is for the SambaPOS to automatically set GIFT item if customers orders 3rd SAME glass of wine.


Case A

1x Pinot Grigio Glass
1x Pinot Grigio Glass
1x Chardonnay Glass

In this case, 3rd glass will not be free

Case B

1x Pinot Grigio Glass
1x Pinot Grigio Glass
1x Pinot Grigio Glass FREE

In this case, 3rd glass will be free

The issue I have here is that I originally set a new order state to each order during this happy hour deal using {PRODUCT NAME}.

But this constraint is not working, it doesnt return anything. I tried to concat() it using scripts but when I call script it just gives me literal string output.


Is there a workaround or a better way to solve this problem?

I would really appreciate any feedback

It seems like the dynamic order state name is an issue. Can you just assign a static order state name such as B2GO, and then assign order status value to True. Then just count orders based on their product name when adding them.

What event were you using that?

How were you planning to do canceled orders etc.

What was the reason you didn’t go with the adjust order price action which is probably ideal in this case no?

Could you give me an example on how that can be assigned and used? What reporting tags can I use to pull that value? I never used values before and dont really understand how they work.

Order Added followed by Execute Automation Command action.


As you can see it works fine with Wine category being constrained but it should actually be just for the same product. Which is what I am trying to achieve.

I didnt do Adjust Order Price action because there is very little documentation on how to actually use it and what parameters can be used, where and how. Ive been to occupied with work to piece together what I can do with it from numerous different threads.

Do you have an example how to to use it to achieve something like this using that action?

This was my 241 burger action

Maybe worth a try as handles cancelations etc which will make a custom setup crazy complex.
Main issue ive had with the adjust order price action is some of my print template tags not displaying expected value.

I would just have a play and see if useable as if can get it working for you would save allot of complexity handling every eventuality.

1 Like

Here’s a super simple example of the report tag that works if you just count based on the item name rather than the state. I think this is a better way to go, then you can set however you want to apply your special pricing. You can really get this done with one action (from a very base level) with a price tag.

This should really be set to gift or discount, I just didn’t want to do the extra work for the example :wink:

If adjusting price and not gifting, then you should do what @JTRTech mentioned with GStatus:

{TICKET ORDER COUNT EXP:(ODI=True) and (MN=[:MenuItemName]) and (OS.GStatus= )}
1 Like

That works exactly how I want it to work! With a quarter size of my previous constraint at that too!


1 Like

But what about cancel or void? :wink:

Or +/- qty, or is x2 added depending on if you have numberpad etc

If nothing else you need to add thinks like GStatus= so void and gift prders arnt counted :wink:

As above this would be in both sences of not counted voided orders and also how to amend previous orders if one of 3 is voided or cancelled etc

Holy rapid-posts Batman. All good points. It definently needs further work.

Ran a quick test and seems to work;


But what I have done few times I have used is to not use event like order added but put my promo automation in an automation command rule that way the automation can easily be triggered from a bunch of different events with execute automation command such as, order added, cancelled voided, etc or possibly just of ticket total changed.
However not sure about your deal since your using order name dynamically rather than a fixed value like a promo state etc and automation command wouldnt have a menu item name to call on.
But if you did so with automation command rule and execure from rules like cancelled, voided, etc you could pass menu item name as the command value and use command value in place of menu item name.

Did you only have one portion for wine by glass?

Not tested yet but think that could work nicely.

Seems to work…


1 Like

As I said though, this action causes some unexpected results on print template in relation to order total and tag values when doing multiple qty on order lines - or at least when I brought the issue up a while back.
Calculates fine, onscreen and accounts are fine, think it is/was a bug just in the print rendering, so check outputs to make sure get what you expect. specificly on multiple qty lines.
Beleive its because it uses a special value in tag json TV rather than TP or something like that, guess value rather than price.

However the built in automation within the action is pretty good and allot easier than trying to catch all eventualities with seperate custom automation.

Haha, I did not think its going to be easy as that, at least I am on the right track now, time to get back on the drawing board and consider different scenarios :smiley:

I used Update Order Gift state action cus I was in testing, I didnt really think of using that one, Ill probably go for a different one unrelated to GStatus but have to see which is easier and doesnt require too many new buttons just to cancel/void etc.

I think Void doesnt work on New items so as long as they are new it should be easy to cancel.
As far as the Submitted go, they will be easy to Void. Even if they are Gift as they belong to same GStatus group, one will replace the other, however, that sets ODI to false so simple (ODI=True) should suffice in the constraint.

They are not using numberpads and quick qty are disabled for Wine categories, so they have to click on products as an agreed method of use. +/- they wont have access to either, well, service staff wont. Alternatively, I could Lock 3rd order that was updated as Gift, or go as far as locking the whole trio.

Bottles are 2 for 1 too but they are a separate product, I separated them at the beginning because I knew I didn’t want to check for portion names as well. However, (MN=[:MenuItemName]) sorts my problem of having to have wine in different group codes.

{TICKET ORDER QUANTITY TOTAL EXP:(ODI=True) and (MN=[:MenuItemName]) and (OS.GStatus= )}

I think I will have to use this one instead, mainly because after you close the ticket it will merge all GIFT & billable products into one line. And ORDER COUNT checks for order lines instead of qty.


From memory if you have tag as not included and not sistributed it won’t merge as tags would have different values.

1 Like