no, wait I’m thinking now and yes I sort of get it.
I add a rule which upon login opens a ticket for a staff member if they already have one assigned
Things sort of click sometimes when I’m shown the correct direction
Matt
You should study how the employees are logged in and the rule that handles the login is the rule you want to insert this automation.
So on ticket closed you store the TICKET ID and EMPLOYEE ENTITY in a program setting. When employee logs in it checks the setting and displays that ticket ID. Action constraint used to only fire if the setting is not empty. If setting is empty it just creates a new ticket or goes to tables screen or whatever you want it to do.
3 Likes
This was the next bit of what im working on with having updated “users” to be entities instead like your setup kendash.
i need to re-work the switch user setup as this now doesnt work as it based on users, i dont use the timeclock bit so i stripped those bits out so im just purely using the employee entity bit when logging into the pos.
Main menu login as a generic “cashier” user to enter the nav screen, then they press pos button, enter their password and pos screen is display. I just need to work out 2 things:
-
how to load the open ticket when the employee logs back in which is where i think youre going with Matts question
-
We should now (as using entities as users) being able to fully automate log out/log in. So current employee is mid sale, new employee swipes their staff card which initiates the switch user setup and closes current employees ticket, logs them out (back to nav screen) and auto logs in the new employee that swiped their card to either their open ticket or pos screen if no open ticket
2 Likes
^^ Exactly!
But don’t tell me how to do it all, i need to wrk this out myself…
I can add to the close ticket thats there already to allow the system to store the TICKET ID and EMPLOYEE ENTITY. But would I need to create a new action for this?
Matt
Edit:
Theres a Load Ticket action, which I could add to the user login… presumably State:Active and if my employees were only allowed to open their own tickets surely this’ll only show their tickets?
Edit: No it wouldn’t because they are entities now not employees!
Ill do this I will!
2 Likes
I have a nice way to hybrid switch user and hold ticket although need to refine it.
My systems all user users rather than user entities but the core would be similar.
Rather than the origional method I used from a tutorial on here where the ticket id was saved against the user via a switch user button which offered the possibility of an open ticket not accessible from the POS to be left open and prevent work period close as it was left open tagged with a user on switch user function for a staff member which had finnished work. - Yes it could be found via ticket list but was a loophole I wanted to close.
The hotel setup uses a hybrid of hold ticket and switch user.
The switch user flow puts the ticket on hold and tags the ticket with the employees name.
Currently it adds one to a user_hold setting value so when they log back in it prompts them saying they have x number of tickets on hold and offers options for start new or go to hold list.
I liked this bit as if say someone started ordering but needed to go check something with wife you could switch/hold easily - serve someone else, and come back to it rather than forcing the previous ticket back on the user when they closed/logged out.
I liked this route as the hold list could be made accessible to all users and with a report tag in the button header the button shows the number of hold tickets.
When opening the hold ticket it subtracts one from the users hold setting and they continue as normal.
The refinement I want to make with this is to not use the program setting and use a report tag instead as there is a small glitch in the current setup that when a different user opens the hold ticket it doesnt subtract one from the original user meaning they get the prompt even though no hold tickets are open although currently combated this with a cleanup rule which clears the hold ticket count for each user on work period close.
It is on my list to refine this flow and put together a tutorial as think it works nicely in combining hold and switch user in a way which if wanted doesnt confine the held ticket to that specific user.
The other refinement I want to add is to setup so that is a ticket is left on hold for more than say 5 minutes it will prompt all users or maybe trigger a popup message saying that a ticket has been left in hold list for so long.
2 Likes
Yeah we’ve gone beyond my knowledge of the moment.
Im not looking at just copying an answer, but learning from it if anyone is able to help me with this (and RickH too it seems!)
As I now have the knowledge of Actions, Rules and Automation commands it makes things a little easier for me to understand what I’m doing. The things I cant grasp at the moment are constraints.
Matt
edit:
I may see if there is a way I can do it by playing with this tutorial?
Yea they confused me at the start -
Think of a constraint as “ONLY do this Rule if this constraint is TRUE” so it acts like a kinda “On/Off switch” so becomes powerful when you have 7 Rules in a row but only wish for some of the Rules to work if say the Answer was “Yes” to a prompt OR the calculation “result was greater than 0”.
FYI 
2 Likes
I think I get that bit, but… yeah hah… i will get it completely I’m sure.
Ill just keep reading up on the forum after a few tutorials I’m sure it’ll sink in
Matt
Specifically I was referring to an Action constraint. The reason for using an action constraint is because you would be inserting this automation into a currently working rule that loads Employee entity etc. You would not want to constrain the entire rule just the part that displays ticket. So the action constraint simply checks if program setting has a value or not.
1 Like
Action constraints are even more powerful in being able to breakdown a rule and make little parts different based on factors 
Constraints is defiantly something worth investing some time in getting to grips with, once you do a whole broader range of more complex flows become possible 
Pretty sure that was the tutorial I went from with my first switch user config
1 Like
Keep in mind there may be other routes to achieve this. I am simply just brainstorming based on the fact that your using a system I derived so I understand how it works.
1 Like
my brain hurts, I’m gonna grab a coffee
1 Like
It could actually be simple 2 actions and 2 rules…
1 Like
Im thinking Update Program Setting?
Like above tutorial, but instead of {user name} Use {Entity Types:Employees} ?
Matt
Its the format of action constraints that throw me and i never know of what i use is valid or not, ill need to copy the format from another one
The key point to remember with Action Constraints is this:
All Action Constraints are evaluated at the same time when the Rule fires. They are not evaluated in sequence.
That is, Action Constraints are evaluated “in parallel”, so Actions whos Constraints are True are “short-listed” for execution, while Actions whos Constraints are False are “thrown out”.
This means you cannot set a value in one Action and then try to Constrain the following Action based on the value set by the previous Action. For example, you cannot do this:
Failing to understand the above concept is what throws people for a loop because they do not understand why it is not operating “properly”.
In the above example in fact, if the Program Setting is set to Is Local = True then the value is stored in memory instead of in the database. And in many cases, in-memory Program Settings are “cleared” upon User Login (which is the Event of this Rule), so you can assume with a fair amount of certainty that the value of EmployeeName is in fact BLANK. That means the second Action will be “thrown out” upon entry to the Rule and will never fire, even though the previous Action sets a non-blank value for EmployeeName.
3 Likes
Yes so program setting needs to be set in a different flow.
2 Likes
Will, have a go when I’m back home now.
busy time for me after school, thanks for your help till now though guys. Ill keep you updated on my fails.
Matt
Exactly. We need to break the flow up into separate Rules …
In the 1st Rule (left) …
The second Action is an Execute Automation Command Action which triggers another Event/Rule (right). In this Action we are firing an Automation Command having the name “Print Statement” (AMCname). We are also passing a value of the contents of {SETTING:EmployeeName} as the Command Value (AMCvalue).
In the 2nd Rule (right) …
The first Rule Constraint checks the name of the Automation Command and if it does not match “Print Statement”, then the Rule does not fire.
The 2nd and 3rd Rule Constraints are essentially doing the same thing - they check to see if a value is present in [:CommandValue] (which we passed into this Rule from the 1st Rule), and the other checks to see if a value is present in {SETTING:EmployeeName}. You can use either the 2nd or 3rd Rule Constraint in this case, but you do not need to use both. And actually, you don’t need to use either of them if you Constrain the Action instead …
The AS Print Account Statement Action is also constrained to see if a value is present in {SETTING:EmployeeName}. Alternatively, we could have constrained the Action with this as well:
'[:CommandValue]' != ''
… and so long as we passed a (non-blank) Command Value from the first Rule, it should evaluate to True.
So you have options… it all depends what you are trying to achieve.
Sometimes it is more efficient to Constrain the Rule, while other times it is better to leave the Rule with fewer constraints and then constrain the Actions within the Rule. Of course you can do a combination of both (Rule and Action Constraints), which is very often then case.
1 Like