Well if no entitty is assigned then the ticket is never closed without settlement, so I should have made this clearer sorry. The problem occurs when an entity is assigned (table number) and the bar person is unable to then serve normal bar drinks while there is an open table - or a closed (but not settled) ticket on their ID.
Guessing you have not sorted the switch user setup to clear the ticket ID or to not remember the ticket if there is a table set…
So are you saying you can close but when you log back in to reopens the ticket?
Yes JTR exactly that. Logging back in under the same user ID just shows the previously closed ticket with no way out. I only installed this today so asssumed the switch user would be implemented in the latest version.
At the end of the day configuration files are user submitted and will not always be completely compatible 100% with other setups, it is hard to make something completely universal sue to the flexibility of Samba.
Will take a look at this file and see whats going on.
If this the ONLY think you have changed?
Hi, Thanks. Thats relevant yes. TBH I added a couple of payment accounts and a very basic automation command to shift cash between 2 accounts, but these 100% won’t be affecting ticket or user related states/entities/etc
EDIT: I see in the last post 1 day ago theres a mention of table numers… ours begin with a letter for the room followed by the table number (e.g. R20 (Restaurant 20) or O20 (Orangery 20)… the tutorial says something about just having 1-20 so maybe this it? I missed it as wasn’t in the main description.
For one this config task is using entities and guessing you dont have entities per staff name so not sure exactly how its even closing the ticket in the first place as you cant set an entity which doesnt exist,
Sorry, @GreatShakesBar but this config doesnt seem right to me;
Clearing the setting before closing…? No constraints
Kitchen print on command… whouldnt this be in ticket closing anyway?
Not sure whats going on here?
This is what will be recalling the ticket EVERY time.
Sure [=TN(’{ENTITY NAME:Tables}’)] on login is never going to match anything.
@JTRTech Not sure on any of the other points but part of the setup for this was to create a matching entity for each staff/username so we should be ok on that (I did do that - if you don’t then I quickly found that the switch user button just won’t do anything). I haven’t looked into the details and may have gone in a bit blind, but after a good bit of testing this tools file seems to work great. We don’t personally do kitchen prints so can’t advise on that either, but definitely we have the user entities bit done 
I have always (well until recently) used a basic ticket tag and program setting setup for switch user.
You will lean allot more building things yourself rather than just importing.
Its the same as many things not only do you lean but its easier to find your own mistakes over finding someone elses…
Except it’s not working great and causing you not to be able to create tickets 
it appears JTR has found configuration mistakes in it that may be causing your problems.
This wouldn’t be needed if can create entity was set to true 
You tag the ticket with the username, the tag allows it to be closed without an entity.
The program setting logs the ticket id.
You just need to put update program settings in the right places
Great shakes by the looks of it was going for a flow where the ticket MUST be paid before you can do next.
If you want to use this setup you will need to change a few things.
Firstly the login rule would want to be something like this;
The close ticket rule would want to look something like this;
Ive not tested, am just working on the fly.
In theory there is no need for the switch user button, its just closing the ticket just like the close button.,…
My preference for basic switch user would still be the tag and setting setup, allot simpler…
I have recently switched to a different flow but am yet to sort a tutorial for that.
@JTRTech Thanks this fixed the table problem… the only issue now is that when using ‘switch user’ button the last ticket isnt displayed by default, so we have to search for it from the tickets menu.
Also (not so important but a bit annoying) the default screen for all users seems to have reverted to the menu rather than the ticket screen for the bar (regardless whether you manually logout or use switch user).
I was working on the fly so wasnt guaranteed 100%
In theory you shouldnt need the switch user button.
No offence to this config file but I would ditch it and start fresh switch user setup.
I will do some screenshots for my trusted tag setup I put on my systems I sell if you want to change setup
That would he ace, thanks JTR. We use iButtons for login so all we want to do is switch user and recall any open pending unpaid orders for each order, preferably.
Think that got all the actions and rules… havnt needed to touch this for a while.
It is from a v4 system so may be some cosmetic differences but process is all the same.
Youll also need to define a ticket tag to allow the closing without entity;
It doesnt want any mapping, just needs creating to allow close.
Its fairly basic in principle,
Tags on ticket creation. (to allow close button to work)
Ticket closing then logs the ticket id or clears the setting depending on if customer or table selected.
It should also remove the tag on closing if one is selected.
There is a loophole where if someone logs out with ticket on their user and finishes work you have to recall that ticket via ticket list and do whatever with before work period close.
Also a second user cannot recall another users ‘held’ ticket.
That is where I expanded my new setup to include. It is based on same basics but uses states and a ticket lister to show all hold tickets for all users so other users can finish anothers hold ticket.
Also I set that up to prompt at login saying you have ticket on hold, contine or open in theory allow a user to have multiple hold tickets or to start a cash sale while leaving the other on hold (say if the customer when to check what option his wife wanted etc, they can serve someone else in the meantime.)
Thanks JTR. Is this the new expanded setup or the original please? The original will do what we need but the expanded sounds epic.
Wouldnt say epic but it still need some tweeking before doing a tutorial.
This is the basic taken pretty much from a tutorial on here.