can an order state “submitted” be changed to “new order” ?
I was thinking that once I click reopen closed ticket, I could create either an auto action to also changed order from submitted, to new order, in the hopes it enables the cancel button which would remove the order in replacement of another. An alternative to the use of void, which in return I would set to print the new ticket once close is pressed again
You can change states to whatever you want but that defeats the purpose of cancel. Here is the issue… When submitted the Order is written to the DB. Cancel Order will not UNWRITE that. The cancel orders button works BEFORE it is submittted to database and its specifically coded to be used that way it will not interact with the database.
The state of Submitted gives you visual reference that its been written to the database… it will write to the database that order regardless of the state… even if you renamed it to Purple People Eater it will still write the order to the database and cancel order automation will not work.
What you need to do is work with the fact that the ticket is now written in the database and build automation to manipulate that ticket how you need it. So that means if you want to make an order disapear then you need to write automation that will load that ticket, void that order, change any pricing, change any inventory… etc.
So to sum it up you can forget about Cancel Orders working once an order is submitted to database. Instead you need to work out an automation flow to do what you desire.
PS I failed to mention it because I thought it was understood but just in case it is not understood I will explain bellow.
When you first start a ticket before you close it… nothing is written in the database it is strictly held in memory on the program. Cancel Orders is code designed to manipulate this program state it will NOT interact with database. When ticket is closed it then writes that ticket to database at this point Cancel Orders does not work because ticket is now written to database.
We do have automation available to manipulate tickets that are written in the database so this is the route you need to explore. You can create your own state flow around this.
Ah Ok. Thanks for explaining that. That explains a lot 
I’ll try to look at ways to manipulate the data then
Try not to use SQL directly. Everything you need should be available with actions and rule events. You can use States to define an operational flow for it.
That’s fine, another quick question, could we re order the ticket Id?
What happens when a use takes an order, then cancels it, it closes the ticket, and opens a new one, then the ticket UID number increments by 1, so ticket viewer would shown
Ticket 4400 then 4402 next .
It makes it look odd and fishy.
But then again, if I did manage to make something that re orders the ticket UID, it would change the previous tickets ID’s which could cause potential problems if a customer has an issue with an order.
I have a rule which cancels all orders on the ticket if customer changes mind, but every time that button is pressed, the ticket ID goes up by one. My rules doesn’t contain a close ticket action nor create new ticket action. So got me confused
The reason for that is to prevent someone from creating the same ticket with two different peoples orders on two different terminals all on same ticket no.
Think of it as a reserve…its reserving that ticket so terminal 2 cant accidentatlly use it at same time for someone elses order. Now lets multiply terminals lets say you have 6 terminals all taking orders at same time… you have to keep the Ticket No’s progressing forward… not backward.
.[quote=“Shivan, post:5, topic:12743”]
It makes it look odd and fishy.
[/quote]
For accounting purposes you should be using the TICKET ID not TICKET NO
Ticket Id is the unique number when orders are actually written to DB and it is real tickets unlike Ticket No which may not actually contain anything at all if its completely cancelled. If your concerned with people abusing cancel button, then implement ticket logging.
Do you mean Ticket No? Ticket Id and Ticket No are 2 different things.
Yeah I just checked the actual DB of the tickets created, I saw how unique the Ticket UID is compared to ticket number.
Regarding that though, is there a field that connects the ticket number to the ticket UID?
But what your saying makes sense. so all good on that part. Makes me understand how the database works more and how the flow of samba works a bit more.
So I have explained in detail the difference in tickets before submitted and tickets after submitted. Now that I explained that let me dig a little deeper for you so you can understand importance of the flows. This involves techniques to accurately train your staff on the POS.
1st you should not be sending ANYTHING to kitchen or doing any real processes on orders if they have not been submitted and written to the database. If you do then you open yourself up for employees to steel and figure out how it works to take advantage of you. If they know that nothing actually happens until its submitted then you eliminate that.
But if you build real processes around non submitted tickets… you make it real easy for an employee to take advantage of it.
Yes there is every ticket has both Ticket Id and Ticket No assigned in dbo.Tickets both are fields.
So if you query Ticket Number 2 You can view its Ticket ID and if you query Ticket ID 342 you can view its Ticket No.
Is this the reason why the reopening of ticket is BT default not created? But allows the admin to create one of they wanted? And the extra security is the admin pin which is required before actually reopening it?
Well the reason its not by default is because you can mess it up badly if you dont know what your doing. Reopening it means your allowing automation on a ticket that has already went through the flow of your system. So naturally you can see that if you create bad automation on that… you will destroy that tickets integrity.
Remember tickets also have Transactions assigned to them. SambaPOS lets you cut off your own foot if you want too… but its not going to by default 
Yeah I thought so.
Interesting, I think I should start leaning a bit more of SQL queries, and how I can obtain information via SQL scripts . that should help me further understand how to obtain information from tickets, and from there I should be able to understand better how to custom report and check for ticket amendments
You really should study and understand how to use the built in automation before you learn how to manipulate the SQL. Using the automation correctly generally will avoid most major disasters.
I understand what you are thinking though. You want to make it as clear as possible for accounting purposes. Using Ticket ID will help with that. Also creating good logging automation can help as well.
I know I have explained it arleady and I know you understand but I just thought of a good analogy for the Ticket No skipping issue people always get concerned about.
Lets imagine your not using POS and your using paper tickets and taking orders manually.
Lets say you start taking an order on a ticket pad that has #1 at top for Ticket number.
You start writing an order then customer gets up and leaves… you wouldn’t go to the next table and start writing on that same ticket. You would throw it away and start a new one. With POS systems we have a great ability to store data. An advantage is sequential tickets… but those are only good for real tickets… that is where Ticket ID comes in.
So that is why for Accounting Ticket ID is what you go by and not Ticket No. Ticket No is there though for the system to work as I described but it also lets you have another method to find tickets, make changes, view reports etc.
I’m slowly getting the hang of automation.
The basic understandings of creating actions, assigning them to rules where they apply, creating auto command buttons with values and viewable states and intractable states.
There’s definitely a lot that I have to wrap my head around. How to properly use custom constraints, how to create rules within rules, the use mixture of rules and scripts to do things.
Yeah you will eventually hit an AHA! moment and it will all make much more sense. Once you hit that (Looks like your close) you will really start to reap the benefits of why SambaPOS is better than anyother system.
The analogy is great. Makes perfect sense. Thanks for the in depth insight