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.
The kitchen is a personal set up it shouldnât have been in there.
That set up allows an item to be put on a table number and then be closed. It then prevents the table ticket from showing if you log back in so you can create a new ticket.
If you want to see the ticket you need to go to the table select screen on a stock install.
@GreatShakesBar your rule for user login has an invalid constraint. On user Login SambaPOS is not reading a ticket so your ENTITY NAME:Tables constraint will not work there. You can test this with Show message action in the same event and try putting {ENTITY NAME:Tables}
In fact I recommend using Show Message liberally when designing a flow it can reveal possibilities or reveal mistakes quickly before you get too deep. It is a very good practice and one I use for just about every configuration I do and I am sure @QMcKay does the same. I typically use Show message in almost every rule that I am unsure of when building my systems.
2 Likes
ill have a look when Iâm next there at the clients place, but it all seems to workâŠ
Matt
That constraint is definitely invalid so if it seems to work then you need to evaluate the need for that constraint.
Itâs not matches and will never match, I can see what you have tried to do but would be better ways to do.
It works for your scenario but can see how wouldnât for others.
The idea is, that if a table is selected then it wont open up the waiters ticket with a table selected.
Ill get more details in a tic as Iâm actually at the place where those tills are.
Matt
I would say personally you would be better evaluating if it needs recalling on close rather than open.
Ie the login rule is constrained as to if the setting value is null or not and the setting is set with ticket Iâd depending on if table is set or not or remaining =0
User login will have no idea about entity selection which makes your constraint invalid.
So the idea is this, yet it works⊠perfectly for me although some suggestions added above will probably help at the moment its not broken for meâŠ
Lets have 2 waiters called Bob and Reg, and three customers called One Two and Three
Bob serves One, One orders 2 things and wants to open a table tab. So we stick her order on Table 1 and press âSwitch Userâ.
Reg uses the till and Two orders 3 drinks, meanwhile Bob takes an order from Three whilst Reg is making those drinks, so switches user and takes his order. Three pays and leaves the till. Reg comes over, logs in and finishes his order.
One comes back and pays his tab off, so Reg or Bob can now log in and open their table.
The system I created is set for table numbers 1 to 20 only (as noted in the post) and it will remove the âStaffâ entity if a âTableâ entity is selected.
It will allow bob to open a table, and serve another customer without that table popping up if they log in again.
It works exactly as I need it, the flow works perfectly and its been in place for a week now with no issues.
The reason I needed the staff entity removed when a table entity was selected was so that it could be merged if there was more than 1 member of staff opening tickets.
The problem with OP here I think he never set the table numbers in the rule which I stated needed to be done in the post.
Iâm not being stubborn, honest and I would never say what you guys are saying is incorrect because you all know more than me! But it works lolâŠ
Matt
Looking at the OPâs screenshot his table is âR8â so he needed to set that in his list of tables in the constraints and it would work as its meant to.