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
AND
I want to either:
1/ Automatically Calculate Service Charge when there are kitchen items on Tickets in payment screen
OR
2/ Enable Cash & CC payment buttons only after Service charge button is clicked for Tickets with kitchen items on payment screen.
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.
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.
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?
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.
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
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.