Payment Screen conditional behavior

I want to make my Service Charge Calculate button visible/enabled or functional only when there are kitchen item (vs Bar only items) in the ticket on payment screen


I want to either:

1/ Automatically Calculate Service Charge when there are kitchen items on Tickets in payment screen


2/ Enable Cash & CC payment buttons only after Service charge button is clicked for Tickets with kitchen items on payment screen.

How can i achieve this?

IS your button an automation command button? You can use the mapping of the button and define if it is visible only if specific State is read on the ticket. If you have it set to show on Order Line you can use Order States… if its set to Ticket you can use Ticket States.

Example you can make it only show up if kitchen items are on ticket by putting DStatus=Kitchen in your Visible Column if you are using DStatus to apply the order state. I do not know how or if your assigning Kitchen to your orders.

My Service Charge calculation button is a Calculation selector button with a custom calculation script.

So are you suggesting that the only way i can achieve this is if i reimplement it as an automation command button?

Yes. I do not think Calculation Selectors can check any of that. Unless @emre provides us some way to do that.

1 Like

Ok, i was suspecting this to be the case. And how can i control the enable or disabled state of the payment Type Buttons depending on my Ticket state?

How are you telling an order its in kitchen? Are you putting Kitchen on the Order via updating an order state?

Calculation selectors are useful to select a calculation via button. If you need to add this calculation conditionally you should create a Add Calculation action and execute it when an order with a specific tag or group added.


You could constrain it to look for specific Order State: if its Kitchen for example. Thank you @emre I read his question wrong when I replied at first. I did not read the Automatic portion lol. Sorry if I confused you @Aryanking. What I was telling you is useful for Automation Command buttons however.

@kendash At the moment, i’m just using the order state ‘Display’ and assigning the value ‘Kitchen’ or ‘Bar’ depending on where the order is being processed. However i plan to implement the following ticket state:

Ticket State Name: Service
States = Bar, Full

When a kitchen order gets added to a ticket, the Ticket state Service gets updated to Full.
When a bar order gets added to ticket, the Ticket state Service get updated to Bar only if current Ticket State Service has not been assigned any value yet.

With that flow what would happen if you add kitchen order… and then add a bar order… both on same ticket… would you want the state to be Bar even if Kitchen item is on it?

Bah now I read it lol. So your saying if you have both on ticket you still want it to be Full? This would mean the only tickets with State of Bar would be tickets that have strictly bar items. That makes sense.

Yes. Because Service Charge is applicable only when ticket has kitchen order

Well you can do everything you asked by reading States in the rules as constraints…if you get a question while implementing your states just ask.

1 Like

Only thing is reversing (i.e canceling or voiding) orders will be a bit tricky with multiple kitchen orders on ticket.

Not sure I follow what your getting at. You can also read Order States seperately from Ticket States. Were you planning to not use Order States for Kitchen definition and switch to just Ticket State?

I think I am confused by what you mean.

if i have two kitchen order on ticket, but i want to cancel or void only one
then i would want to update the Ticket state Service to full

if i have one kitchen order on ticket, and at lest one bar order , but i want to cancel or void it
then i would want to update the Ticket state Service to bar

if i have one kitchen order on ticket , and no other order on ticket but i want to cancel or void it
then i would want to update the Ticket state Service to unassigned or empty

Ah ok. That is definitely doable using constraints. Can use Current State: to tell it to look for a current state to decide if it changes it or not. I will let you sort it out if you run into any major road blocks then we can help you work through it.

im just wondering how the system will determine if there is another kitchen order (or a bar order ) on the ticket when i void or cancel another one…

Make it look for those order states… If it finds Kitchen Order state still on ticket… then behavior is x… if it finds another bar order state on ticket then behavior is x. can use DStatus= notice its not DStatus=Kitchen DStatus can be whatever you define it as.

So DStatus= would look for a blank State for DStatus … DStatus=Kitchen would look for Kitchen State of DStatus

hmm… im thinking of using separate ticket states of Kitchen and bar and assigning numbers instead of Full or Bar

Look into using Group Codes with your states… and are you going to actually define them in Settings? I probably would so you can do other cool things like color changes. You can set it to a specific color if its sent to kitchen… and a different color if its sent to bar… Then by looking at your tables you could see if its in kitchen or bar.

That may not be practical for your system im just throwing out ideas.

I have been slowly converting my system away from ticket tags and using states more effectively. It just seems more natural.