Switch between users

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()]

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?

Have found a possible solution should someone else end up with the same issue.

1 Like

@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.

2 Likes

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):

GStatus=Gift,Submitted,New
1 Like

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?

Personally, I would not mess with the default Order or Ticket States. Both of the States are of the Order Group called Status. There should be no reason to alter their flow - by default they are set up in such a way so the POS operates properly in a standard manner.

Instead, create a new Order State and use it for your manipulation and state flow. Call it HoldStatus or similar, and create 2 States for Held and NotHeld or similar. Then set and test for the HoldStatus State value in your flows in your Rules.

So when it comes to Printing, or other actions, you can modify the affected Rules to look for this new State in addition to, or in replacement of, any States that currently constrain them.

Looking at the kitchen print job would it make more sense to make a new status of something like KPrint: Sent,NotSent?

You can have unlimited states. I wouldn’t advise going too complex but I always start with a new state if I am implementing something new. This keeps it separate from other things and really makes debugging easier.

Perhaps, though I can’t say for sure what would work best for you. If this is simply a matter of knowing which Orders to Print, then that makes sense. But if you have other possible uses of the HoldStatus State, it might be better to go that way.

You could use both ultimately - that’s what makes SambaPOS so great… you get to design your flow as you see fit.

I use 3 different Order States and 2 Ticket States in my setup. One of each of those State Types are the default Status State, while the others are various States I added to affect supplemental behavior of Orders and Tickets.

Thanks for the advice, it is kitchen printing issues Im trying to ensure are consolidated as sure chef would get angry if he were to get two ordered for the same table some through on two tickets and them ment to be all part of the same order.

I think I got it solved.
I added a KPrint status and have chosen NotOrdered and Ordered and configured the actions to set as appropriate.
Void did throw a snag so had to add Kprint status updates in void and cancel void.

Even managed to work out so that it seems to work as expected :smile:
So if ‘layed away’ it doesnt print but becomes submitted meaning the defult close ticket rule is uneffected. the status is NOTORDERED on adding order.
Kitchen printing is set to only work is the ticket is not ‘on hold’ and in that rule ive set to change the status to ORDERED.
Voids I had to play with a little and ended up adding two KPRINT status updates to void and cancel void which change status as needed - if not ordered (still on a ticket thats on hold) to sets it to a third state on VOID ORDER so that a void doesnt go to the kitchen that a order hasnt already been printed. If it is ORDERED it will revert it to NOTORDERED so that the kitchen will get a void order print.
In cancel void is where I had to play around a little to get straight in my head.
If it is set to VOID ORDER (ie an ticket on hold where no order or void has been sent to kitchen it reverts to NOTORDERED so it will send when table set. If NOTORDERED it reverts back to ORDERED as kitchen already has the original order.
I think the bit which confused me with the cancel void was the action ordering as first time roung i had them in that order which then ment both actions happened if VOID ORDER as first changed it to the staus the second action was looking for,
After switching the order it then works fine as they dont clash with each other.

I don’t think there are any other situations to need to worry about as situation was only to hold off the printing until ticket way finalised and taken off the user hold.
Cancel shouldnt matter as wont have gone anywhere if cancel is available.
Gift will be like any other order.
… Refund I forgot, have made that to set Kprint to REFUND, as kitchen wouldnt need to know in same way as void - would already have been paid to need refund (would probably cause argument - ‘Why did you refund that?’ - sure you know what most chefs are like…

1 Like