LOL did find a solution and was typing before I saw your reply.
Stupidly I did know a tag allows close of a ticket and cant beleive I forgot that.
The tag solution also saves the hastle of remembering to add a staff entity if new employee starts.
Joe
You dont have a solution to stopping the recalling of the last ticket is its not been sebtled or voided do you?
Joe
Hi John,
Can I ask if there is a way to remove the Program Setting TicketID?
Can the tag be automaticly set to username as with entity?
Will it work if tag is open to free text rather than adding all staf to list of tags?
Joe
Sure. Did you look at the setup that I posted above? The rule containing the Constraint for Remaining Amount = 0 is there to overcome this problem, because it blanks out the setting for the user.
John isn’t here - he has been away since June 2014 on vacation and has not returned. 
What do you mean by this? Do you mean erase it entirely from the DB? Yes you could do that. Why, I don’t understand.
Yes to both, I don’t see why not. You don’t actually need to create the Ticket Tags. You can assign them arbitrarily.
isnt the whole point that if you are quickly serving someone can close your ticket so that when you log back in the ticket does appear so you can settle it as you’re still serving the customer? switch user is setup for multiple users using the same terminal so they can all use it to serve at the same time without the orders being “lost”, simply log back in, order appears so customer can pay.
If you want to close ticket and then when you log back in it doesnt open again if you dont need to settle it straight away you can use ticket tags to setup a parked sale system or bar tab, ive just posted how i have this set up. have a look here to see if this would help you
I understand what your saying but as you say I am trying to allow users to switch as only a two till setup.
However with the restaurant using the same till there is the need for table tabs.
With this method if a bill is started, user switched, then back to the first bill which needs to go onto a table this bill will keep being opened everytime that user logs in untill it is cashed off.
- User A logs in and rings few things in while pouring the tables drinks,
- User B jumps on the till while User A is pouring drinks, switches and does a round at the bar.
- User A returns to till, logs in for the started tab to open. rings in a couple more drinks then allocated to entity ‘Table 1’ then logs out.
Other users are unafected.
If User A logs back in it reopens the table ticket ‘Table 1’ - presumably as the System Setting has a record of that ticket ID against their user name.
This ticket continues to load everytime the user logs in untill ‘Table 1’ is either paid and cashed off or voided and closed.
Does that make sence?
What I think needs to hapen - and which ive tried but cant get it to work is;
on step 3 when the entity ‘Table 1’ is set the System Setting of the ticket ID needs to be cleared so next time that user logs in they go to a fresh ticket/to open an entity.
I have tried blanking the user setting with a rule of when entity table is set update system setting to " (blank) but it doesnt see to work.
Let me explain when i mean.
At the moment with this method if a bill is started, user switched, then back to the first bill which needs to go onto a table this bill will keep being opened everytime that user logs in untill it is cashed off.
- User A logs in and rings few things in while pouring the tables drinks,
- User B jumps on the till while User A is pouring drinks, switches and does a round at the bar.
- User A returns to till, logs in for the started tab to open. rings in a couple more drinks then allocated to entity ‘Table 1’ then logs out.
Other users are unafected.
If User A logs back in it reopens the table ticket ‘Table 1’ - presumably as the System Setting has a record of that ticket ID against their user name.
This ticket continues to load everytime the user logs in untill ‘Table 1’ is either paid and cashed off or voided and closed.
Does that make sence?
What I think needs to hapen - and which ive tried but cant get it to work is;
on step 3 when the entity ‘Table 1’ is set the System Setting of the ticket ID needs to be cleared so next time that user logs in they go to a fresh ticket/to open an entity.
yea i understand now, i had the same issue when staff entity assigned then if i wanted to load a customer entity the staff entity would remain and if messed up other rules. You need to add a rule that when the table entity is added the staff entity is removed
@Jesse helped me solve that, but i cant remember if it fully solved my issue, i changed the way my other features worked so i didnt need to remove the staff entity in the end
i think you need 2 rules
- to add table entity
- to remove staff entity when table entity is added
im not sure on the actions though to remove the staff entity
Ok, shouldn’t be a problem. Give me a few to test it out and I’ll post it here…
Change this Rule to add the Action twice, and use Action Constraints …
SU Update Program Setting (1):
Constraint: '{ENTITY NAME:Tables}' != ''
SettingName: {USER NAME}
SettingValue: (blank)
SU Update Program Setting (2):
Constraint: '{ENTITY NAME:Tables}' == ''
SettingName: {USER NAME}
SettingValue: [:TicketId]
The staff entities issue wasnt what what causes the issue.
I have already taken out the staff entities bit and changed to a tag (Unalocated: [:CURENTUSER]) following your replay as this resolves the issue of remembering to setup a new staff entity if new staff start as is an open ended tag which allows the tickeck to be closed is a table entity has not been set.
I have already worked out the actions & rules to remove this ‘unallocated: username’ tag when a entity is selected.
The issue I cannot work out is that once a bill is set to a table entity and closed, when that user logs back in they are taken back to that ticket (already set to a table entity) which if you use autologout means that user cannot do anything other than view that bill as ‘close’ logsout.
What I need to work out is how to clear the entry in the ‘update program setting’ funtion wher the ticket id is put against the user id as curently untill the bill is cashed off or voided the entry for that user remains as that ticket so the ‘open held bill’ rule reopens the opigional ticket now allocated to the table entity.
Does that make sence?
It sounds like it needs a constraint…I’m thinking a constraint if Table Entity assigned.
1 Like
Try what I mentioned above, if you’re using the posted setup. It should work if you setup is similar… look up a few posts.
To add an Action twice, Right-click on the Action Chooser and click Display All Values.
1 Like
Thanks, I will try this tonight.
Can I ask if you could define the meaning of != and == so I can grasp a better understanding rather than just putting it in and not learning?
I presume by the associated values != would be table selected and == no table selected?
These are (in)equality operators:
!= not equal
== equal
Examining the first Action:
SU Update Program Setting (1):
Constraint: '{ENTITY NAME:Tables}' != ''
SettingName: {USER NAME}
SettingValue: (blank)
We look for the existence of a Table Entity assigned to the Ticket ('{ENTITY NAME:Tables}'), and if it is not equal (!=) to blank (''), then fire this action. So if it has a value, then we fire this action to effectively blank out the Ticket Id for the User.
Examining the second Action:
SU Update Program Setting (2):
Constraint: '{ENTITY NAME:Tables}' == ''
SettingName: {USER NAME}
SettingValue: [:TicketId]
We look for the existence of a Table Entity assigned to the Ticket ('{ENTITY NAME:Tables}'), and if it is equal (==) to blank (''), then fire this action. So if it does not have a value, then we fire this action, which sets the Ticket Id for the User.
That did the trick!!
Thank you very much.
Unfortunately I can see a potential loophole,
If in a busy bar a user accidentally logs in on second till before the other is loged out, slim chance but trying to make system fool proof.
Or posibly for ease of access they start the ticket on one till start pouring drinks (doesnt logout) then more drinks are ordered which are located next to another till (more likely) ideally i would like to prevent seccond login or make the other till autologout.
Do you know a way to only allow a user to be logged in once or autologout on the other till is loggin in on another machine?
I don’t have multiple Terminals, so I can’t really study the behavior of this scenario. Short of setting up a test environment, I can’t really comment.
That said, I don’t see any reason that your scenario and workflow couldn’t be made to work. The Automation system in SambaPOS is extremely powerful, and allows you to really take control of your particular way of operating.
Someone with experience with multiple Terminals should be able to chime in on this.
Thanks for your reply,
Is there much documentation regarding the {xxxx} [:xxxxx] functions?
If I could get my head round these I think I might be able to work it all out but at the moment am only able to blindly copy yours and others posts as dont completely understand the workings with these special functions yet.
Joe
LOL, yes that can be confusing.
{THIS:Is A:PrinterTag} {SOIS:This}
{SETTING:ProgramVariable} a special Tag referring to a Program Setting that you can read and set
[:thisIsAvariable]
[:thiscouldalsobeaDefaultParmeterInARule]
[=thisisanexpression()]