Post Ticket Close Tagging Options


I’m planning on using SambaPos as a base for all my future business operations. Having considered my various requirements, i propose that you consider adding a way to tag, single out/classify Tickets that have been closed. Perhaps that function can be different then the normal tagging function. It would allow me to do stuff, which i think is hard to do with the current setup:

So for example:

  1. Once orders have been closed I realized that . I want to be able to manually tag each order closed which i may suspect of having used fish from that supplier, and tag them with a particular marker, so that i can generate reports around those orders - and later track down the customers via (customer name/phone). Suppose that there are multiple fish dishes and there is no way to specify from within the system which menu items used ingredients from this supplier.

  2. It would help with the delivery setup as well. In my flow, an order is closed and money received as soon as the rider gives the money to us (he is issued a float at the start of the shift) and not when he eventually comes back with the customers money. Closing the order as is and ensuring the cash transaction is completed and secured is more important in a fast food environment rather than ensuring that the time logs are located. Hence, if for a closed ticket i can tag it when the rider leaves and comes back, from another location, without going into the ticket settle screen is extremely useful.

  3. Once the rider is back, I receive feedback from multiple customers that they got the wrong order, i want to be able to classify/Post TicketClose tag these orders Ticket ID’s so that the customers and these Ticket ID’s can be called up in reports.

I can think of numerous other sceanarios as well where the feature can be extremely useful. Perhaps other s may back me up on this :smile:

I can think of several ways to achieve this. You can design a question, your answer would be how the ticket is tagged and when you press the button it reopens, tags, and closes automatically so you never have to resettle or see payment screen. Visually all you would see is button pressed and tag appear on order and it would stay closed.

Or you can simply use a variable that requires input to write the tag manually allowing virtually anything to be put on the tag.

If this is somewhat like what you are describing then I may be able to help you design it. You can do anything to closed tickets you want… help me better understand EXACTLY in more detail how you see it operating and I can help you design it.

Ticket Tags store value… and that value can be pulled via reports… so Ticket Tags would be the natural approach to this.

To sum all of that up… it is already possible to do what your asking we just need to work out a design.Matter of fact, tagging closed orders is great for reporting reasons because you have access to more data after ticket is already closed. Example: Ticket ID does not produce a real # until ticket is closed…

Okay this is one of the things that i’m trying to achieve. Based on this, once i have the times and the rider name for each order i can generate customized reports. This page is showing only closed orders. Now each column here is representing different information which is supposed to be added and become another Post - Ticket - Closing tag.

In here, Riders are entities which can be created in the entities part.

The Screen displays all orders, in the current workperiod which haven’t been delivered (i’ve left the first order, order 80 open as an exception to show). It can be refreshed. Any order that is closed automatically comes on this screen.

The buttons on this screen are:

  1. Drop down for Rider Name. It is automatically enabled for all orders as soon as they’re closed.
  2. Rider Leaving, enabled for those orders for which the rider is selected.
  3. Rider Back for those orders for which the rider has left.

WIth the Post Ticket Closing option enabled i can also track If any customer has complained (if their order was late etc)

The screen your attempting to make… this is what you want doing the tagging on the tickets? This is not the reports screen you were talking about? You have several elements going at once I am slightly confused.

The ability to tag closed orders is already in SambaPOS. You can do anything you want to a closed ticket. I can help you design a system to tag closed tickets with whatever data you want to tag, and you can pull that data up in reports…
But this screen you mentioned has me slightly confused. It sounds interesting but in the form your describing it would not be possible yet.

I can help you create a screen to interact with tickets even using Entities(Riders). It sounds like you might need to incorporate several widget types and overlap some into an entity selection type system.

What do you mean by Post Ticket Closing option I want to clear what I think you mean by this. You simply mean tagging tickets after they are closed?

I just wanted to make sure that you are aware that you can reopen closed tickets and do anything to them you want? This includes tagging them and closing them again.

I think I understand now. You are wanting a custom Delivery Setup similar to the ones in tutorials now,but you want it interacting with closed tickets instead of open tickets…

You can do this now. It will take some clever work with rules, reopening tickets, tagging, calling those tags, etc but it is possible. Will also require you to understand how to use States to your advantage. States make handling closed ticket operations A LOT easier without risk of messing up the ticket or other tickets.

Matter of fact States has become one of my favorite methods for maneuvering tickets and tagging and calling those tags.

1 Like

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…


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.


I had to look that… and yes, you are right… We do have two actions, reopen anc cancel payments… i forgot about that… Thanks!!!


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.


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 PM

yes - 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