Yes - you understood it correctly. For me the option of tagging seems far more flexible than “order states” or perhaps i haven’t understood “order states” correctly.
When you reopen tickets, you will have to settle payment again… reopening tickets erases payments… I would not do that unles you have to reopen it becuase they changed theyre maind about payment…
G.
You do NOT have to resettle payments. And no reopening a ticket does not erase payment unless you program it too. I have several things I reopen tickets for and I never delete payment nor resettle.
2 Likes
I had to look that… and yes, you are right… We do have two actions, reopen anc cancel payments… i forgot about that… Thanks!!!
G.
We automatically close a ticket if remaining amount is zero and we do that by executing Mark Ticket as Closed action. This is not required if you need to keep your tickets even it fully paid. For example you can skip closing ticket on full payment and close it when it reaches Served state.
You need to carefully design a workflow for your ticket. All tickets have a state and all actions changes state to execute related actions. You can configure the flow as New > Paid > Preparing > Serving > Served and for each step you can configure a an action to advance it to next.
When you create a new Ticket it’s status is New.
You receive a payment and it’s status becomes > Paid.
Paid tickets appears on Kitchen and when cook starts preparing it it becomes > Preparing.
Deliverer receives the order and before leaving he advances ticket to > Serving. The can do it by clicking the ticket and his name and you can assign deliverer to ticket.
When he come back he makes it > Served and at that time ticket closes. Before closing ticket you can ask for complaints, note them or manually update order’s complaint states and close ticket.
This is just an example. You can design it for your own needs.
2 Likes
The problem with this work flow is that the ticket remains susceptible to changes if it is not closed and remains open, meaning i can add or remove items from it. This can be very troublesome if your cashier isn’t trust worthy. Hence, once paid i would want my ticket to be closed. Are there are other ways to edit the ticket once it has been closed?
Paxi you can restrict those actions to states so nothing can be added, removed, etc if its in a specific state.
Here are some examples from my DB Notice some buttons available depending on the State some disapear when it changes state.
First screenshot notice the To Go button on left and Abort Transaction button down by Payment.
Now notice the Open Drawer button has appeared and notice Abort Transaction is not available because there is no ticket yet.
Now notice when State changes to Aborted all payment buttons disapear.
Operational Flow of Above Screenshots:
First. I do not want my employees using Open Drawer during a transaction so I disabled it until a ticket has a State.
Second I only wanted Abort Transaction available when a transaction has started and I do not want it available on a closed ticket... so Its set to only show if state is New Orders.
Finally If a ticket has been Aborted then I only want Close Ticket available because I do not want ANY other actions EVER done against this ticket.
There are A LOT of great functions available with States and planning your ticket flow is virtually limitless if you understand it.
You can do anything you want to closed tickets… but its much better to build a flow around Ticket States to begin with. When you mess with Closed Tickets you run risk of firing multiple rules that are set to run on closing a ticket and it becomes hard to keep up with.
Now that I understand your intentions I would also recommend Ticket States and designing a flow around them. You can disregard what I recommended with closed tickets I do not think it would fit your situation as well as a good Ticket State Flow would.
1 Like
Keep in mind that I chose to completely hide functionality in those examples… You could just use Enabled vs Visible and keep the Buttons but make them not usable during specific states. You can also Lock and Unlock tickets.
Hopefully I was able to demonstrate that you can still achieve what you want by using a good Ticket State flow.
Thanks Kendash - yes this does give me an idea.I’ll study it some more and then pester you for more questions. One question for now:
Are you able to get a time stamp of when an order changes a ticket state and are you able to generate reports around it?
Yes, and Yes. You would have to tag your ticket when state is changed. I have a question for you… why do you want it time stamped when it changes state? Are you wanting to track time it takes for drivers etc?
You can simply use a ticket tag for each state change… and use {DATE} which can be formatted to show any format. You can even use a function to calculate time between stamps and display that difference.
{DATE:M/dd/yyyy h:mm:ss tt} would produce X/xx/xxxx 00:00:00 date/time format EXAMPLE: 9/09/2014 06:40:23 PMyes - and maybe to see how fast the kitchen is working. What’re the choking points etc.
Hi Emre,
I am new here and trying to implement SambaPOS in my new fast food business. The process flow that you mentioned here is exactly what i am planning to implement where customer will make the payment first and kitchen then proceed to prepare the food. Kitchen ready and serve, customer come collect by their queue number issue from SambaPOS, last step counter staff update the ticket status to served.
The issue i am encountering now is i can’t make any changes after the payment made.
Can you advise how to configure SambaPOS so that it will skip the closing ticket process after payment made?
Many Thanks,
Can you explain what your full flow would be after Ticket Closing?
Is it specifically the Kitchen Screen? You want the order to send to Kitchen after Payment and they press Order Ready and it changes it to Ready? What else do you want to do after Payment?
I’ll prepare a simple tutorial to demonstrate how to change such workflow. Might not be the exact answer but it should give the idea.
1 Like
Thanks kendash and Emre for your quick response.
Yes, after the payment (Ticket close), Order will be sent to Kitchen screen and display all the paid tickets (this step i manage to make it work). In theory, once an order is ready, they will select the ticket(s) in the Ticket Lister and press the Order Ready button (a Command button). Order will change status to Order Ready. I am planning to have another small screen (may be a 7"/8" tablet will do) at the Serve Counter facing customer to display the ticket number or queue number (yet to try, still in my mind) for the Order Ready ticket. This screen will have a bar-code reader connected at the serve counter. Customer pass the queue number ticket with bar-code printed (given out together with the receipt earlier) to my staff to exchange for their food. My staff will collect and scan the bar-code printed ticket to change the ticket status from Order Ready to Served and close the ticket. I am not sure if the final automated process for the bar-code scanning and update status is possible to be implemented in SambaPOS, Do you have any insight on this?
If this is not possible then my staff will need to select the ticket in the Ticket Lister and click a Order Served button to complete the process. But this way they will have one more task to do and i will need to prepare another setup with similar queue number screen facing my staff at the serve counter.
I am currently using http://sambapos.org/wiki/doku.php/en/custom_package_delivery_system as the guide for manipulating the ticket status, but i am stuck after the Kitchen screen display the paid tickets. All the Actions/Rules/Commands created after this do not work (no response on the kitchen display screen command button).
This morning, I found this thread discussing about the close ticket then i suspect my issue may be due to the close ticket. Hopefully i can find the answer here, my business is starting mid of next month 
Many Thanks.
Its certainly possible. I currently use a bar-code system for pulling up tickets on my system. Bar-code scanners will input a bar-code as simple text. So look through the various options for entering Text and rules that can interact with it, you might find something you like. Look at Task Type in Settings and Task Type Editor widget in Custom Screen Design Mode… You can assign commands to be executed using the text input as a command value through a Task Type editor widget.
I’ve posted tutorial here. As I’ve said before might not be exact answer but it will give an idea about how you can solve it. Not the only solution but might be useful.
Hi Erme,
Many many thanks for the tutorial, you have save my days.
After spending a day to go through the tutorial and did some hand on testing, I have better understanding with the Action/Rule/Command now. I finally manage to configure the SambaPOS to suite my business process need. The steps in between are not straight forward though but is still manageable with introducing new ticket status to control the flow.
One thing I have noticed here in SambaPOS Rule is there is a limitation in the Custom Constraint List to add more complex constraint rules. So I was only able to add in one additional state in between Paid and Close, if I further update the ticket state again (say Paid --> Ready --> Served), my custom constraints in Ticket Payment Check rule will not work and the rule will always step in and update my Ticket State back to Paid. But I manage to introduce a workaround by moving the Ticket State just one step (Paid --> Ready) and at the same time introduce new Ticket Status (Serve Status from Ready To Serve --> Served) to continue my workflow. Kitchen Display will display ticket from Ticket Status with Paid state and Serve Counter Display will display ticket from Server Status with Ready To Serve state.
Again thanks, I might need to spend another week or more without this tutorial. SambaPOS is really a great software, thanks for creating this wonderful software.
I can proceed to do the printing templates and the barcode scanning now. Thanks Kendash for the tips on bar-code scanning, I think I will do my research on this first before asking more questions.
Thanks everyone. 
@eddie Tickets can have multiple states so you can create an additional workflow for tracking serving status. For example Status can be Paid, Unpaid, Closed and ServiceStatus can be Not Served or Served.
For example you can create a rule for Ticket State Changed event and when ServiceStatus becomes Served you can execute Close Paid Ticket action to close ticket.
You can think it like a TV. It also have multiple states.
Power state can be on, off or standby.
Channel state can be something between 1 to 200.
Volume state can be muted, low, mid, high.
You’ll notice these states have some constraints. For example TV can’t be on and off at the same time. You can’t switch power to stand by state from off state, etc…
These states works individually but they can interact. For example some TV’s are intelligent to adjust sound level automatically. So -in SambaPOS terms- when Channel State Changes, Adjust Sound Volume action executes.
Thinking about how we use devices is a nice way to understand it because this is something we already know and use everyday.
Thanks Erme for the additional note. This make more sense to me now, I know I am in the right direction now. Thanks