Id like for the bar staff to be able to close their transactions, so they can walk to the customer and tell them the total or ask if they would like anything else… or anything else that may be relevant…
Another staff member to log in, do their sale… then the original bar member to log in and their ticket to automatically show.
Is this possible?
I looked at the select ticket method and only letting users to open their own tickets, but as I use users as entities now this isn’t possible. besides, it still never opened the tickets automatically anyway.
It should be possible to store ticket ID in a setting along with employee entity. You could retrieve that when employee entity logs in. We need more info like how do your employees log in?
using your staff clock in system, its not on a live POS. Just the one I’m redoing as the first one I did was using tutorials but as I have a little knowledge now id like to work it around my needs more.
Ok then we could use the same event that captures load entity to also display ticket if one is loaded in a specific setting constrain it if the setting is empty.
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.
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
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!
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.
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?
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”.
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.
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
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.
