Void Orders Printing Blank Ticket

I keep having an issue where after I go back in and void an order it still prints a ticket to the kitchen that is blank… it has all the kitchen order information just no orders on the ticket… below is my printer template… and ill post a picture of the ticket that is being printed.

<T>Kitchen Order
<L>Tbl:{ENTITY NAME:Customer}{ENTITY NAME:Customer Number} Chk:{TICKET NO}
<L>{TICKET TAG:Ticket Type} {TICKET TAG:Ticket Type} {TICKET TAG:Ticket Type}
<L>{TICKET TAG:Ticket Type} {TICKET TAG:Ticket Type} {TICKET TAG:Ticket Type}


-- Format for order tags

-- do not print voided orders

The ticket on the right is the order before it is voided it prints to the kitchen as it should… the ticket to the left is printed after the order has been voided…

You probably messed up the state flow.

hmmm how would i be able to track that down to see what all ive done?.. Is there a report I can generate?

You need to show your rule that fires that print job.

Now show the print job.

Notice anything that seems like it could be causing that?

It all looks right to me. You sure thats the only rule with that print command?

Show your Void rule. Are you changing State when you void?

im pretty sure thats the only rule… for printing… let me search to make sure…

here is the void rule…

This behavior is expected.

How does the Print Job know anything about the State of any of the Orders? It doesn’t.

The Rule is firing the Print Job and it is printing according to the Template.

You will need to Constrain the Printing Action based on some criteria so that it does not fire when the Ticket does not contain any Orders with a Status State of New.

I tried both of these, but they do not seem to be reporting properly, though in theory something like this should work as a Constraint on the Print Action …

[=TN('{ORDER STATE TOTAL:New}')] > 0

EDIT: Those ^ are not helping because the last Action in the Void Rule is setting Order Status State to New - so they are in fact reporting correct values.

So you can edit the Void Rule as such to stop the last Action in the Rule from firing:

Then Constrain the Ticket Closing Rule Print Action with:


1 Like

Ok so QMcKay pointed something out that I missed. By default it normally does print Voided orders to kitchen so the chef knows not to make that order or knows not to send it out. The reason yours is printing blank ticket is because you took the Void Orders print template out of your ticket template.

Thank you @QMcKay for clearing that up I was mistakenly thinking he knew that already and had automated it not to print already and now it was broken. Looks like I was wrong in assuming that.

This is a good example of why it really pays off to study the default flow of how things work extensively so once you do start to modify for your needs you wont run into small issues like this.

This is not printing tickets at all now… i copied the text on the screen but i noticed that the screenshot is different… is there a typo?

Would just removing the action in the void rule to update the order status to new keep it from printing? From my understanding based on the void orders rule… and i may be wrong the update order status in that rule is causing the voided order to be set as new which is causing the ticket to print to the kitchen because it is a new order correct?.. if i remove that would it fix it?

Yes that would probably fix the issue. I believe that action is there specifically so it would trigger the print again so kitchen knows of voids.

Ok I will test that out… it makes sense to me to print the voided orders to the kitchen but the staff just wants to be told and mark it down on the ticket which also kind of makes sense since its the ticket your working off of. Ill give this a shot and see Thanks!

There is a typo your missing a closing ) at the end after the apostrophy ’


Yes, screenshot is correct. Typo has been fixed/edited in my post. It should have been:


Yes it would. But I do not like to, and do not suggest that you remove anything from default Rules. Instead, placing the Constraint 1==2 on that Update Order State Action accomplishes the same thing. It is like “commenting out” a piece of code so that it does not execute. Then 1 day, when you are wondering how or why something is not working as expected, you can see that the Action is still there and remove the Constraint to get it back to “default” behavior.

Exactly correct.

Yup, thanks, corrected.