Since we can add some values in which to apply a specific AMC button Like below
Is there a command or text we could use in e.g kitchen template to show those values?
I got values for void, but would like the reason printed out on the kitchen template. By default it just prints void
And that is mainly because it’s just a text written under category of void in the template.
So Id like to it to print the value of void AMC as well.
You can tag order using free tagging or order tag note, tag value = [:CommandValue]
I knew about order tag notes, but I thought maybe there was a specified text like {AMC Value} which we could type in the ticket and it would show the command value, instead of order tag noting.
If that’s the only way, that’s fine, I don’t mind using it, just thought maybe there was an easier method.
I don’t see what you asking is easier method. What if this AMC excute many times with different value? What value would that be? If you did 2 voids, it can’t have 2 values for that {AMC Value}.
It does have [:CommandValue] when it was executed. This is the most accurate way to do it.
EDIT: what your ask is more like using {SETTING:X}. Just pass [:CommandValue] to Update Program Setting
What about passing the command value into the gstatus state value for void?
Update program setting and pulling from there?
Dunno if that is possible… but yeah I’m still learning 
Edit: just noticed that’s what @sukasem said lol
I bump this idea as will be historical and not just a print so you could refer back to reason if needed.
Well then you mess up void that is using GSTATUS. Just make sure you don’t break a flow that might need GSTATUS to be Void
Like I always say it’s best to make new state and not use defaults.
I think rather than break something, I’ll just use a method of ticket noting on ticket template . This isn’t a major thing, I just thought since we have values in amc, we could some how note what value was used on that void which is sent to kitchen print, be nice to know sometimes reasons to void an item(Sometimes critical for chefs in restaurants) . I’ll work on something
You can certainly do that. Using a state is a good idea dont let me scare you from it. I just wanted to make the point that you shouldnt use default states for that… If it was me I would use an order state myself and make it visible on ticket. Being a state means its also reportable and can be used as report expression. Also means you can do other automation with it later.
To be honest I’ve never really created a new state, I only understand how some of the states work, but to actually create one, apply it to what I want to do, is something a little bit scary haha.
I’d probably need an example to give me a bit of confidence to fiddle with it.
Like for this example I originally posted about, what type of state would i be creating? and then how do we pass command values into state value, and assign it to the void thingy.
I wouldn’t even know where to begin for this >,< im such a newbie haha
Its really more simple than it sounds.
Couple ground rules to remember:
States do not have to actually be defined in Settings < States you only do that if you want to add color or make them visible on ticket.
You can create and manage states directly in rules. For example lets say you want to make a state flow for CMD Value. You can use Update Order State action and set variables for State name and State like [:State Name] , [:State].
Then choose which rule event you want to use the state for… in your example it would be the Automation Command Executed event for Void. So put your new action there and for State Name put something like Void Reason and for State put [:CommandValue]. You now have a state called Void Reason and a state that equals the Value of your Command.
Finally if you want non admins to see this state on tickets you go to Settings > States and create a state for each command value like the following screenshot:
Dont worry you wont mess any flows up if you dont mess with default states. So never use Status or any of the other default states UNTIL you are very comfortable with them.
Practice using states if you ever want to really get into some great automation then you need to understand states.
You can also show that state on printed tickets with tag {ORDER STATE:Void Reason} so the line in your printer ticket template might look like this:
<L00>Void Reason: {ORDER STATE:Void Reason}
If you do not care about the state showing on ticket screen and only care about it being printed then you can skip the Settings > State portion. States work in rules and actions regardless if you define them or not, Settings > States is only for visibility on ticket screen or entity screens.
Thank you very much for that explanation. That definitely helps me understand it better. I’ll try it on a demo DB and see how I go. I’m sure it will come handy for other features too
No because default gstatus doesnt use sate value only state itself.
I use state value a few times on my system as a seccond variable on some of my scripts.
Some advanced uses of states means now that you have a void reason state you can build automation around it as well. {ORDER STATE:Void Reason} can be used in constraints for Order Line automations. For example if you wanted to do something to a ticket but only for orders that have an order state of Void Reason = Customer Cancel then you might use a constraint of
{ORDER STATE:Void Reason} Equals Customer Cancel
So now that rule will be constrained to only orders containing that order state.
I am aware of that but its a very bad practice to use default states for custom automation and it should be avoided. It will also lead to confusion for people just learning states. BTW you do realise that it sets GStatus to Void right? So if you use GStatus then it no longer will be Void… So in reports your voids will disapear.
EDIT: Nevermind I just reread your post. You referred to value specifically. Yes that would work as well.
Interesting. Ill check this out once I finish work 