i don’t see a substantial difference between tags and states
Tags are always on the ticket… States I can define to not show on ticket. Can also use Product Report and End of Day options with States.
There are instances where I wanted it to behave like a background process but the Tag would always be on ticket… I Know it does not have to print this way… but its less clutter when viewing closed ticket.
i See. But what i meant is why have Tags when a state can perform the function of a Tag? A State seems like a more evolved Tag…
Tags are useful for some things that you would not want to define a state for. States should be used for process flows… Tags for just tagging something… like a Date.
Both are effective and both can be read in rules… I just find that using States when applicable vs Ticket Tags seems more natural and allows little more flexibility.
1 Like
@Jesse What i’m trying to do above is when a user presses the Settle Button, to assign the value ‘Full’ to Ticket State: Service if at least one of the orders on the ticket has a Display State of ‘Kitchen’ and that order also does not have a GStatus of ‘Void’…
My main issue is when the users press the Settle Button, I don’t know how to loop through the orders to find the first order with Display State and GStatus that matches the condition . The way this currently work is i have to manually select the appropriate order on the Ticket, if one actually exists, then press the Settle Button twice for ticket to go to payment screen.
How can i loop through the orders when the user presses the Settle Button? @emre is this even possible?
Can you show me the State you created and then show me the action for Update Ticket Service State?
Why don’t you add service calculation as soon as a kitchen item gets added?
@emre i didn’t do it so because Service Charge calculation is based on a script
result = (Ticket.PSum + Ticket.PreSum - Ticket.Tax)*0.08 and cannot toggle at the moment, so cancel or void of Kitchen order then having to reverse the Service Calculation in that event is a problem.
Should you assign it to the Settle button or assign it to payment processed? I would think payment processed… what if they hit settle but change mind and do not pay and want to take an item off.
You could also use Custom Product Tags and assign them to the products that would change state to Bar or Full. Use order added rule and some constraints to define behavior. Maybe make a third state to define ONLY kitchen items on order call it Kitchen… when item with specific custom tag that would change to bar is added it checks if state is Kitchen if it is it changes state to full. if it is not Kitchen it changes state to bar.
Isn’t payment processed after the bill is already calculated and customer has given payment? Remember, the Settle Button is like the payment Screen gate, so in any case the ticket would have to go through this gate ( after any changes are made e.g. void/cancel/adding more orders) before customer pays final tab.
At first i was thinking of assigning the Ticket State Service value when orders are added to Ticket but then i have to deal with all the changes and reverses, where as, on Settle Button, just one single update of Ticket State Service is needed before a bill is finalized
I also though of a long winding way of doing it using a Tag Counter (increment/Decrement)…
Ah forgot this was about service charge… it should be neither settle nor payment processed it should be added before this point and reflected in balance before we hit settle. So lets look at our options…
Above will probably be the best method as it can be used to add it before settle screen and update balance accordingly. When state is updated to a specific state it can add the calculation… this can be handled with Ticket State Updated rule.
So what we need to do now is figure out how to reverse this if specific item is cancelled…
The real problem as i’ve stated previously, is when you have more than one kitchen order, and only one gets canceled or voided. How can you check that there are more kitchen orders or not to decide on reversing/removing the Service charge or not? Thats why i thought of tag counters for kitchen items, that would increment or decrement when Kitchen order is added or removed(canceled/voided) from the ticket.
It would use the custom product tags… we can check them. I will demonstrate…
If you have a display state for kitchen items {ORDER STATE TOTAL:Display=Kitchen} should be greater than zero. I think you can handle it through settle rule.
2 Likes
Which part is not working? You might need a refresh ticket in there after the service charge. Also make sure this Settle rule is listed BEFORE the rule that brings up payment screen.
Ticket State Service does not get assigned value ‘Full’ and rule does not execute the Service charge Script (i.e. no service charge added)
ok ill check.
Its probably because its jumping to payment screen before it can do any of that. You should maybe just add those actions and constraints to your Settle rule you already have. instead of making a second rule for that same button. Just make sure the actions to update state etc are before Display payment Screen.
what would happen to bar order only tickets? would it go to payment screen under this single rule?