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
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.
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?
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.
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
{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()]
Have set this up the same exc to use tags rather than entities as in @RickH post.
Problem I have (not sure if its just something ive done) is that the open hold ticket rule allows user login to POS screen while no work period is open?
Any Ideas?
Perhaps a constraint of work period active?
@QMcKay
I wondered if you might be able to advise.
Have just implemented my kitchen printer and actually using it has brought up a small snag.
Having setup switch users settings with default config elsewhere the âlayawayâ/hold of an âopenâ ticket without an entity (using tag âUnassigned: {USERNAME}â to allow logoff) would fire the products ordered so far to kitchen printer which could be half the order.
While it probably wouldnt happen often ie - food order being layed away or logged off half way though ringing in.
Anyway I thought I would try and adjust the close ticket rule to not change orders to submitted while the ticket is tagged with Unassigned tag by setting constraint of TICKETTAG:Unassigned is NULL, which kinda works as the tag is removed once the ticket is paid or put to an entity.
HOWEVER this has led to a different issue that although the order lines stay marked as new while âlayed awayâ they seem to still be being âlockedâ and red like when submitted.
Which then leaves it in limo in regards to cancel/void as void is grayed out and cancel doesnt work - presumably as its locked.
The aim would be to make it so that is the ticket it layed away it remains completly as new and unlocked untill it is finalised and removed from the user ticket hold setup
BUT I cannot find the rule anywhere which is locking the orders.
Any ideas?
Have tried adding an update order action to the âopen held ticketâ rule which looks up the program setting of the ticket id logged for that user but this doesnât seem to work.
The behavior your seeing is because no ticket is actually made until its closed. Once closed it creates and logs the ticket. You will not be able to keep orders as they are when you first enter them but you can use states to manipulate them or use pre order tickets.
Not sure that what youâre asking to do is possible.
While your thoughts about suppressing the Order State change to keep it âNewâ is the correct direction, I donât think we can achieve keeping the Order âunlockedâ. A Ticket is created when it is closed. At that time, the Orders and the Ticket are written to the DB. Because of this, they cannot be changed - that is, you cannot alter the Quantity nor should you be able to Cancel the Order. Instead you must Void it.
I tried marking a Ticket as Pre-Order, but this does not suffice. The Pre-Order option was designed so that you could close a WorkPeriod without paying the Ticket. But it does not relate to Order States, nor Ticket or Order locking behavior.
The buttons for Cancel and Void only become Enabled/Visible with certain States. You can check for those States under the Automation Command Mapping. For example, the Void button is only enabled for:
GStatus=Gift,Submitted
Since you suppressed the Order State change so that it never becomes Submitted, the Void button will not become Enabled. Unless you change the mapping to the following (which I do not recommend):
Thanks, that makes sence, will go about it a different way.
As I have the current close ticket rule to be constrained to if unassigned tag is null
If I add a new close ticket rule constrained to in unassigned in not null
set action order status âNewâ to âHeldâ
And in the current close ticket rule (unassigned is null)
add update order status to change âHeldâ to âSubmittedâ allong side the existing âNewâ to âSubmittedâ to catch all orders and at that point send to kitchen etc?
How does that sound to you?
Would I need to do anything with ticket status in the new unassigned ISNOT NULL rule?
