Here is our setup:
We use the Android client on Lenovo tablets (5 of these). There is one Cashier computer where the message server is running. All works amazing and we are saving a lot of time. However…
Recently we have noticed that when we wish to settle a printed ticket, we can’t find it on the POS screen. It is however in the ticket list, so when I click on show details it indicates “PAID”, but it shows NO ORDER ITEMS. I have attached a screenshot of this behavior.
The Second Issue is that the ticket numbers between the Android Client and the POS Desktop computer is different. See the second two screenshots attached below.
Did you create the ticket from the Android client? Can you view the blank ticket in the Android client?
I do not use the Android client myself, but one possibility could be the original ticket is created and saved, but then when the ordered items are added from the Android client, they are not being saved to the ticket.
I am inclined to believe that possibly the Android client is showing the Ticket ID instead of the Ticket Number. The Ticket ID is internal and will be different, and should not be shown here. You can confirm this by checking the database using SSMS (SQL Server Management Studio) - the “Tickets” table will show you all your tickets and you can see the Id and Ticket Number columns.
If this is the case, then I consider that is a bug in the Android client. Make sure you are using the most recent version v1.1.18.
Thank you for your response. The answer is yes, the android device creates the ticket, and it has contents of the order, because we printed the bill from the android client as well (the one you see in the top post). So I doubt strongly it is the android client.
You are probably right about the ticket number versus ticket ID, makes sense to me too.
No I cannot view it as it has been “settled” even though I know we did not settle it. I can only view it in the Tickets section on the Desktop version in the history.
Because the Android client is using GraphQL to communicate with SambaPOS, and also things like printing from it is handled separately from the main SambaPOS program, I am thinking that something is going wrong in the Android client which might actually be managing to print the ticket yet not saving properly.
Maybe if you look at your database on SSMS, look at what happens when you close ticket from Android, then when you Print Bill from Android. How does the ticket change? Are orders being added to the ticket?
I feel the ticket is never actually being updated after the initial create ticket event. You can do things out with the normal logic when using GraphQL as the normal rules don’t get triggered in SambaPOS, therefore it is very possible you are getting a ticket printed that was never saved.
Can you please double check you are using the latest version of the Android client v1.1.18 and at least v5.1.62 of SambaPOS.
Also, is this happening with every ticket, or only some?
Or his automation is marking tickets as paid when Bill is printed. The android client is using terminal tickets not the create ticket method. This means his automation is what is marking them as paid.
Not entirely true, it creates a terminal and as such the sambapos automation handles what happens to the tickets, its the same as just ringing it up on another terminal. In this case the terminal is in message server and is virtual instead of a machine but if it’s marking tickets as paid then something in his automation is doing that
But they do in this case because it’s registering a terminal. It is not using create ticket method it is using create terminal ticket after it registers a terminal.
When you use the Gql to register a terminal and use the terminal Gql it does use the rules and actions, this was a change Emre made quite a while ago and is what the android app is based on.
Gloria food was not using terminal functions it was using direct create ticket etc.
It is only happening to some tickets, not all of them. Here is what happens in the restaurant:
Waiter takes tablet and logs on.
The order is taken table-side
Once waiter presses close on the tablet, the ticket is created and printed to the kitchen
The customer requests bill, and the Waiter selects Print Bill action, which prints at the cashier including all ordered items as per the previous screenshots
The customers wants to pay at the cashier, but the ticket is not available on SambaPOS unless you go and find it under Tickets. But when you open it there and press display Ticket, it is empty and has status = PAID
We only have this on SOME tickets not all of them.
Sounds like someone is cashing it out…I mean your automation you showed looks correct. I can not think of why print bill would mark it paid. Show your Before Ticket CLosing rule. Based on your explanation the tablets and android app are working fine. Your issue is when you use Print Bill automation command. Since its not doing it on all tickets it really sounds suspicious like an employee might be cashing it out.
This was our suspicion as well, however, it is difficult to prove, mostly because none of our waiters have access to settle a bill (receive payment) or void any items. They can only Print a bill, and when they need to settle a bill, the customer is requested to pay inside at the cashier.
Today I observed my staff, and I noticed that bills can be printed more than once from the Android client which could be part of the risk.
I am using the Standard Print Bill rule. I wish to take more control over the bill printing process on the devices, should I use the constraint field to add something like Status=Unpaid?
How do I prevent bills from being printed more than once?
On Android app you won’t be able to do much. They need to code that into its settings. @tayfun something you should do is make Android app follow Rules for locked ticket status
Okay thank you. I will for now remove the Print Bill option, it will drastically impact on my time, but I really need to figure out what is going on with these blank Paid tickets?!?! So I will investigate further and hopefully have some helpful feedback.
Thing is it should read locked ticket but it doesn’t. States should work though. Just modify the print bill rule to also set a locked state. And use constraint to check for it.
