Eat out to help out

[='{SELECTED ORDERS}'.indexOf('0')] > -1
[='{SELECTED ORDERS}'.indexOf('0')] < 0

This is checking whether {SELECTED ORDERS} contains the 0 character, so if it returns -1, it means the {SELECTED ORDERS} does not contain a 0 character, but this could also be the case if {SELECTED ORDERS} is an empty string - not sure if any scenario would make that be the case, but good to cover that just in case.

Also, if someone selected 10, 20, 30… orders, then this would make it return 1 since it then contains the 0 character at the 2nd position, which would not give the intended results.

Probably a better way of accomplishing this would be to check 0 selected orders:


and to check 1 or more selected orders:


Just thought I’d share this, got this from one of our suppliers who sells other POS software (SamTouch). Thought might be good to see how others are handling this and anything we can learn from it.

SamTouchCovid19Update.pdf (770.8 KB)

If i remember corectly -1 is none selected, 0 is 1 selected order. :-/ was a while ago I did that would need to check back.

indexOf() is a JavaScript (and JScript, as supported by SambaPOS) function, it is to check if a character exists in a string. It will return the position in the string (first character is 0) or will return -1 if the character doesn’t exist.

So you were checking if if selected items is 0, which is fine, but I saying the 2 problems in the way you checked was that if {SELECTED ORDERS} is empty, it will return -1, and if the number contains a 0 (like 10, 20, etc.) it will return 1, i.e. the 2nd position as first position is 0 (JScript / JavaScript uses base of 0 for most counting / position functions)

Sorry, not following.
What I’m looking for is whether or not any orders are selected.
I’m checking if ita -1 or not, -1 being no orders selected so reset ticket on calculation update.
If order selected it does different flow that doesnt reset ticket.
Was a topic a while back where I struggled to explain the issue in that onscreen calculation doesnt reflect the actual discount value set as wasnt refreshing on screen.
Oddity is the issue osnt consistent. Some scenarios it auto refreshes onscreen value, others it didn’t, after allot of trial and error the above worked out so that autoselect wasn’t unselected, and onscreen calculation value was shows corectly at all times.

If i remember corectly selected orders returns a comma seperated list 0,1,2 or something like that and always starts 0 so index of 0 not -1 shows no orders selected. If I remember corectly.
Was a while ago I came up with this qwerky work arround for the refresh issue.

I haven’t tested what it returns. Maybe you check to see if it’s a count or if it’s a comma separated. If conma separates, what you did will not work - so if it does work, then it must be a count.

And what I’m saying about the indexOf is that is a function for checking position of a character in a string. You are checking for “0” which would exist if selected orders was “0” but also if selected orders was “10”. That is where it will fail.

That’s strange if it’s a conma separated list I can’t see why it would start with a 0 because that’s like giving an incorrect value - there is no order with ID = 0…

As I said was a while ago, what you said clicked now, your saying I havnt tested with 10 orders or higher with a 0.


Can someone break this down into a SambaV5 tutorial. I have very little knowledge on how to use this software. It was here when we took the place over.



Have gone back and checked and {SELECTED ORDERS} returns 0,0,0,0,0 where there is a 0 for each order selected.
Quantity of orders doesnt effect, its just a 0 per order line selected.
So index of 0 > -1 would indeed show if there are any orders selected :wink:

1 Like

Report for discounted tickets;

@{REPORT CALCULATION DETAILS:T.Id:(CT=Eat Out to Help Out #3401):{0},}
[Eat Out to Help Out Summary:2,1,1, 2, 2, 2]
>Date|Ticket No|Covers|Applicable Total|Ticket Total|Discount Total
 {REPORT TICKET DETAILS:T.Date,T.TicketNumber,TT.Covers:T.Id==$1}|{REPORT ORDER DETAILS:O.Total.sum:T.Id==$1 AND (MT.EOHO Discount=Y)}|{REPORT ORDER DETAILS:O.Total.sum:T.Id==$1}|{REPORT CALCULATION DETAILS:C.Amount:T.Id==$1 AND (CT=Eat Out to Help Out #3401)}
>Totals|{REPORT CALCULATION DETAILS:T.Id.count,TT.Covers.sum:(CT=Eat Out to Help Out #3401)}|{REPORT ORDER DETAILS:O.Total.sum:(CA=Eat Out to Help Out #3401) AND (MT.EOHO Discount=Y)}|{REPORT ORDER DETAILS:O.Total.sum:(CA=Eat Out to Help Out #3401)}|{REPORT CALCULATION DETAILS:C.Amount.sum:(CT=Eat Out to Help Out #3401)}


So have rolled out to all our sites.
Final run through;






Report above
Product tags as before
Prompts for covers on order with kitchen course tag set
There are a couple of actions relating to my covers system not directly relevant as extended existing covers suggestion system.


Hi @JTRTech is there sample Database Tools import file for this?


Did create one but it was giving errors, dont think it liked the reusing of the same action over and over. Gave more than one instance reference type error.

Note other discounts should be applied first before EOHO discount is calculated.
If you have other discounts setup you should include these in the calculation.
Hotel has loyalty and staff discounts so I add the {CALCULATION TOTAL:Regulars Food Discount} value (a negative) to the report ticket order total in the constraints and calculation amount fields.
So the doscount is taken from the order total value before calculating the EOHO discount.

Just want to share my implementation of this for anyone looking for a last minute, slightly more straight forward setup.

Worth noting:

  • I have Eat In and Take Away as separate departments and so the automation command and rule are only mapped to Eat In.
  • Ticket Tag ‘Covers’ is required on all Eat In tables and is of type “Numeric” so for the purposes of this, the value is assumed to already be present for calculation.
  • I have not chosen to have the discount be applied automatically - I am fairly sure a customer would quickly point out if they forget to apply it to the bill.
  • I have a product tag on all items that is either Food, Drinks (non alcoholic) or Alcohol. I realise the last two are not mutually exclusive but in this instance it works fairly well in separating items which are eligible.

Transaction Type

Name: EOHO Transaction Type
Source Type: Receivables
Target Type: Discount
Default Source: Receivables
Default Target: EOHO

Calculation Type
Name: Eat Out to Help Out (this name will show on receipt)
Transaction Type: EOHO Transaction Type (as above)
Calculation Method: Fixed amount
Include tax, decrease amount, toggle calculation checked
Sort to be after Discount

Automation Command
Name: EOHO
Button header: Eat Out<br />Help Out
Department: Eat In
Ticket Type: Eat In
Enabled States: NewOrders,Unpaid
Visibility: Ticket&Payment

Name: Calculate EOHO
Action Type: Update Ticket Calculation
Calculation Type: Eat Out to Help Out
[=((TN('{TICKET ORDER TOTAL EXP:(ODI=True) AND ((MT.Type=Food) OR (MT.Type=Drinks))}') * 0.5)>(TN('{TICKET TAG:Covers}') * 10))?(TN('{TICKET TAG:Covers}') * 10):(TN('{TICKET ORDER TOTAL EXP:(ODI=True) AND ((MT.Type=Food) OR (MT.Type=Drinks))}') * 0.5)]

Automation Rule
Name: EOHO button rule
Event Name: Automation Command Executed
Custom Constraints List:
Execute rule if: Matches all
Automation Command Name, Equals, EOHO
{DATE:ddd}, Matches, Mon|Tue|Wed
{DATE:MMM}, Matches, Aug
Department: Eat In
Ticket Type: Eat In

This seems to be working well based on limited testing done earlier this morning but I’m sure there’ll be room for improvement once we see how things go in production.

Similar but just manual application.
Do you not sell alcoholic drinks? Notice your MT.Type=Drinks, alcohol is excluded from offer.
Also, do you ever use the gift option from default setup? Just check your expressions if you do.

Notice your MT.Type=Drinks, alcohol is excluded from offer.

From my last message:

  • I have a product tag on all items that is either Food, Drinks (non alcoholic) or Alcohol. I realise the last two are not mutually exclusive but in this instance it works fairly well in separating items which are eligible.

Also, do you ever use the gift option from default setup? Just check your expressions if you do.

We don’t use Gift (only been running SambaPOS for 2.5 weeks or so) but will do some further testing to see.

1 Like

Fair enough, missed that.
Also you say about sort order but bare in mind your calculating fixed discount direct from orders value so dont think sort order will help with making normal discount apply before EOHO.