Help needed with Order States to control Ticket State?

Our restaurant is split into 3 areas and they entities (tables) are named U1 - U6, L1 - L7 and T1 -T11. I would like the ability for tables in the U1-U6 and T1 - T11 ranges to settle at the time of ordering but to leave the ticket open to allow for food and drinks to be prepared and served. Tables L1 - L7 have table service and the customer pays at the end. Is this something that I can setup in Sambapos 4 or 5 ?

We currently use a kitchen and Bar display setup using tutorials from here.

any help would be great.

Many Thanks

Yes, you could define the constraint like this to match a range of entities, based on your entity names:

This would match all entities in the U1-U6 and T1 - T11 ranges (or actually any that start with the letter U or T and that are Tables). The important thing is to set the constraint to match entities that Starts with the value instead of Equals.

You can find out ways of doing this in the following topic

1 Like

Thanks for the info! -from what I’ve read , hopefully this should be enough to help me work out how to do this. Many Thanks for your quick response :smiley:

1 Like

have come across one issue so far that I’m struggling with - I’m just trying out the tutorial to enable tickets to be paid but left open until marked as closed. This is working , however once the ticket is paid it also strips the display state which in turn means that orders are not showing on kitchen or bar order screens.

At the moment I have a rule to update display state depending on the product group. which if I don’t settle this works - if I settle then this removes the display state. I’m sure this is something simple I am over looking.

It’s simple. One of your ticket closing rules is doing it. Look at any rule that updates that state.

sorted - thanks :slight_smile: for your guidance! always the simple things that you cant see for looking!

OK Sorry for all of the questions guys, with running the restaurant its been a long time since I’ve had to delve into the mechanics of Samba and have lost my way a little.

I have implemented the changes detailed in the tutorial above and can now take payment on a ticket and still leave the orders in place which is great, I have a ‘close paid table’ button that works as it should. The only thing I would like is to make that button only available under the following conditions.

  1. Payment has been taken
  2. bar orders have been served (or if there were no drink orders)
  3. Kitchen orders have been served ( or if there were no kitchen orders)
  4. Cake Orders have been served ( or if there were no dessert orders )

We currently have orders split up over 3 ticket areas Kitchen, Bar & Cakes.

Know what I need to do but not too sure how I specify it . Whether I need to add the above 4 as constraints to the rule - and if so what is the correct syntax to express this. Or whether I can just map the button to only be visible if the above 4 conditions are met - and again what would the syntax be.

Thank you as ever with all the help - I am currently setting this up on my V5 test machine using a current back up from my live V4 and hopefully switching to V5 in the next week or so.


You will need states to do this.
Also depends on your definition of available in that constrains on the rule would be more powerful than button enable/visible mapping.
Ie with constraints you could define a flow that the button only does something if remaining=0 and constraint per other section.
If you need visable mapping (hiding) of the button you will need to do via automation to set a state which shows/enables the button.
Would need to understand your system and flow regarding kitchen, drink and cake orders to have the slightest chance of offering a suggestion. Obviously if not already your going to need to tell samba when the food/drinks etc are served.

1 Like

I have the kitchen display setup. which when an order is placed. for food would show on the ticket as New, Kitchen or for drinks New,Bar or cakes New,Cakes
Once the order is submitted this changes from New to Submitted we then have a buton on the ticket lister that is clicked once the order is served. This changes it to Served

So that I can understand how to express this in a constraint how would I type this as a constraint?

would this be correct
{Order State Kitchen : Status} = Served

Thanks for your help

That doesnt look right to me.
Whats the states? Kitchen, Bar and Cakes? Status is the default state and usually not recommended to adjust this without knowing exactly what your doing as will effect reports etc as well as default buttons.
If the states are as above the constraint would be;
{ORDER STATE:Kitchen} = Served
However if you are doing a ticket level button order state wont work…
If you wanted to check that all kitchen orders were served at a ticket level automation you would want something like;
{TICKET ORDER COUNT EXP:(OS.Kitchen=Served)} to give a count of all served kitchen orders.
But youll need something to count all kitchen orders… not sure if {TICKET ORDER COUNT EXP:(OS.Kitchen)} would count all Kitchen state orders or if a specific state is needed.
Dont think you can do (OS.Kitchen != Served) as would be easy with count equals 0 but pretty sure != doesnt work in report tag expressions

1 Like

I’m still struggling with this! and not sure what the best way to proceed is. I Need the ticket status to change to ‘complete’ once all items have been served from Kitchen, Bar & Cakes. I assume that I need a rule to do this but am not sure how to go about this.

I know what I want to happen, in ‘my words’ but not sure how I translate this into something that samba can utilise. Once a ticket has become ‘complete’ then the ‘Close Paid ticket’ button will work, if I add this as a constraint to my ‘Close Paid Ticket’ Rule.

How do I tell Samba to mark a ticket as complete once Kitchen, Bar & Cakes are all ‘Served’.
I currently have a automated command button on my 3 ticket lister widgets to mark orders as served. So once all three states have changed to ‘Served’ or have no record (if there was no order for food or drink or cake) I then want to mark the order as ‘Complete’ and I am not sure how to go about this.

I currently only have a couple of hours a week to work on this, that is the reason for me not responding very quickly :slightly_smiling:

#State Names (Groups), States, and State (flow) Control

:warning: Before we start into explanations, we almost always recommend that you do not change, delete, rename, or otherwise alter any of the Default States or the Actions that control the default States in SambaPOS. You are best to leave them as-is until you understand how they work. Even seasoned users still prefer to leave Default State flows untouched, because in most cases, there is no need to change them.

Instead, you should create your own State Names and States, and build your own flow control around your States to achieve your desired result.

There are 2 things that I believe initially confuse people.

  • State Name is not the State itself. Instead, the State Name is more like a variable name or Group that contains or holds the State as a value.
  • Status” is not a State. It is the word used to define some of the State Names, which then contain or hold the actual State.

The following image is from the Wiki document which explains States in detail:

Here is another picture, that shows how they look in SambaPOS State Configuration in Manage > Settings > States:

##State Types

There are only 3 Types of States:

  • Entity States
  • Order States
  • Ticket States

You may define and control multiple State Names and possible States for each of the above Types.

:bulb: You are not required to define a State to be able to control it using Actions. The only reason to define a State is to alter the display format on the screen, such as it’s Color or Font.

##State Name

Think of the State Name as the name of a variable or State Group. The State Name in turn contains or holds the value of the State itself. We use words like the following to define the State Name:

  • Status
  • GStatus
  • TCStatus
  • PrintStatus
  • StaffLevel
  • DiscountType

For each of the State Names (Groups), we can defined multiple States.


The State is the actual value currently assigned to the State Name (Group).

For example, we have the Status State Name (Group). This group is further filtered to Ticket, Entity, or Order, and they can all be controlled individually. The actual value assigned to the Status State Name is the State itself. Examples of States we use are:

  • New Orders
  • Available
  • Bill Requested
  • New
  • Submitted
  • Gift
  • Void
  • PunchIn or PunchOut
  • Loaded or Unloaded
  • ND, HH, or VIP
  • Printed or NotPrinted
  • any alphanumeric value, such as 1, 2, 3, A, B, C, etc

##Controlling States

States are controlled with one of the following Actions:

  • Update Entity State
  • Update Ticket State
  • Update Order State

Here are some examples of the Actions:

Note that the top 2 Actions are controlling a State Name (Group) that has no State definitions. We are allowed to do this, regardless of whether or not a State is defined.

The bottom 2 Actions are controlling State Names (Groups) which do have State definitions. This allows us to also define display formatting such as Color, Font, Bold, Italic, etc.

When we set or assign a State for a State Name (Group), then the State Name contains or holds that State.

For example, if we set the Order Status State (Name) to New, then we can read this value using this Tag:


The value displayed from the Tag above will be New.

By the same token, we can use Tags within Constraints, as follows, where we are testing to see if the Status (State Name) of the Order contains or holds a value (State) equal to New:

'{ORDER STATE:Status}' == 'New'

Here is an example of constraining 2 Actions based on an Order State with a State Name of DiscountType:

In the above screenshot, the State Name (Group) is called DiscountType. We are checking to see if the DiscountType State Name has a State (value) of ‘VIP’ or ‘HH’.

Only 1 of the Actions will fire, depending on the value of DiscountType. Or perhaps neither will fire if DiscountType contains a State other than VIP or HH.

In any case, when talking about States or State Names, we can assign multiple States of State Names to Entities, Tickets, or Orders. So an Order on a Ticket could look like the following:

We know the Ticket has 3 State Names, containing these 3 States:

  • Status (contains New Orders)
  • Staff (contains 0)
  • VIP (contains Active)

This is like saying the following:

  • the State Name (Group or variable) called “Status” contains or holds a value equal to “New Orders”
  • the State Name (Group or variable) called “Staff” contains or holds a value equal to “0”
  • the State Name (Group or variable) called “VIP” contains or holds a value equal to “Active”

Or in programming:

Status = 'New Orders'
Staff = '0'
VIP = 'Active'

Because these are Ticket States, this is a more “accurate” depiction:

{TICKET STATE:Status} = 'New Orders'
{TICKET STATE:Staff} = '0'

We also know the Order has 5 States assigned, but we are unable to determine the State Name (Group) from the image. Because I set these Order States using Actions, I can tell you what they are - the State Name is enclosed in (brackets) after the State:

  • New (Status)
  • BNotPrinted (KDStatus)
  • T2 (TaxTemplate)
  • 0 (Staff)
  • VIP (DiscountType)

So if we wanted to test the values (States) held in these State Names, so we could use them as constraints, we would do it like this:

'{ORDER STATE:Status}' == 'New'
'{ORDER STATE:KDStatus}' == 'BNotPrinted'
'{ORDER STATE:TaxTemplate}' == 'T2'
'{ORDER STATE:Staff}' == '0'
'{ORDER STATE:DiscountType}' == 'VIP'

The following image attempts to show the linkage between State Names, States, and the Actions that control them. It might cause more confusion for some, but this is essentially the way it ties together:

One thing to note in the above image is that there really is in fact 2 “GiftStates defined. But 1 State belongs to Status, while the other belongs to GStatus. This is perfectly acceptable, since the 2 “Gift” States belong to different State Names.

And again, remember…

:bulb: You are not required to define a State to be able to control it using Actions. The only reason to define a State is to alter the display format on the screen, such as it’s Color or Font.

This is why we often do not see any Ticket State Types defined in the State list. We have no control over the Color or Font used to display Tickets, so there is no need to define States for Tickets. But we can still control and test Ticket States to control flow. In fact, there are a few Ticket States that are used by default (via Actions), which are assigned to or stored by the Ticket “StatusState Name (Group). They are: New, New Orders, Unpaid, Locked, Paid, and IsClosed.

On the other hand, we can change the way Entities appear. By default, Customer or Table Entities change color from white (Available) to orange (New Orders) to maroon (Bill Requested).

We can also control the way Orders appear. By default, New is white, Submitted is grey, Gifts are blue, and Voids are red, .


Thanks for this - I will have another couple of hours to play around tomorrow. But from briefly skipping through the above @QMcKay this has helped me understand how things work much better. WELL DONE and THANK YOU for putting things in simple terms. The whole state status thing was confusing me … but this makes it much easier to understand. A job well done :slight_smile: smiley:

Ok I am now reaching the point of despair :slight_smile:

what I want to achieve to me sounds simple - yet I am at a loss and still perplexed a little.

here is the scenario (sorry if I’m repeating what I have put above)

  1. an order is added to a ticket as per image

    I Click Close , which then updates the Order State to submitted and Order Display state to either ‘Kitchen, Bar or Cakes’

These then display on the relevant Order screens at either the Bar or Kitchen, Once the order leaves the kitchen or bar we assume that the item is now served and click on the Kitchen order ready button.

This then updates the Order State to Served and the Ticket Serving State to ‘Part Served’

What I would like to happen is for once all Order Display States = Served then the Ticket Serving state changes to ‘Served’
Then I can use the ticket state of ‘Served’ to change other behaviours.

I am not sure how I go about creating a rule that checks the ‘Order display state’ of each item on a ticket to then automate the ‘Ticket Serving State’

I hoped that the following rule would work - but it didn’t :slight_smile: any help would be great

You will need to cycle through all the Orders and check the State of each of them.

In order to do this, you will need some type of way to trigger the cycle. The VIP/HH Tutorial uses a mechanism to accomplish this. The problem you are having now is you don’t know which Order was updated, nor whether all Orders have been updated to Served. Hmm…

What if I were to create 3 separate state names of kitchen, bar and cake that then each have their own served state ?( If that makes sense ) would that help?

Well I went ahed and tried it - but as ever I have hit a stumbling block.

I have created actions and rules that now apply an Order State of Kitchen , Bar and Cakes.
When I add a new order the State is set to NewK NewB & NewC and this all works. If I add an order the state is displayed.

I created a rule to update this to Delivered once the itm is served and this works too. I now am still struggling with the next part of making the Ticket ‘Serving’ State change once Kitchen, Bar and Cakes States = Delivered
The rule pictured below changes the Ticket Serving State to ‘Delivered’ as soon as I add any item!! which is baffling me :slight_smile: maybe I should take up playing golf instead!

I was hoping by using ‘not equals’ this would trigger when the state had changed to ‘Delivered’ or if there was no State at all (ie. if the order didn’t contain any food, cakes, or drinks)

You still have to loop through orders. Your wanting it to execute a TICKET event based on SPECIFIC order States. The ONLY way to do that is if you loop through and check each order’s State.

You make that sound nice and simple :slight_smile: any pointers on how I go about doing this ? Any topics I can read ?

What other actions do you want to perform when ticket state is served?

At the moment all I need it for is to enable the ‘close paid ticket’ only once all orders have been served from all areas. To avoid premature closing of tables