I’m looking for a little help here. My issue is with the Add Ticket feature. In my restaurant, we use the Add Ticket command to enter new seats or customers under on entity. Is there a way to “turn off” the printing of an order in the when you hit Add Ticket in an opened entity? In other words, I would like to print the order only once all of the tickets under an entity are entered. This would make it easier for my kitchen staff as all of the tickets/seats would print at the same time.
I have looked at the Rule and Action pertaining to the Add Ticket automation command but I did not see any thing that would let me turn off the printing action.
I was thinking; Is it possible to add an Action to the Add Ticket automation command/rule that would stop the order from printing until the server presses the Close button?
Think you are not understanding the flow.
It isnt the add ticket which is triggering the print its the fact that the current ticket has to be closed for you to open/create the new ticket.
You would need to do some states work to ‘hold’ the ticket as such and prevent printing.
However I am not sure if you can print a single ticket (order to kitchen) which merges multiple tickets… but would need to check that as never tried.
Know you can specify ticket ids but always presumed this would print each ticket id listed seperatly…
This is the part you need to ask about first as not printing isnt an issue, based on your question it would be printing a single ‘entity’ ticket of multiple tickets.
Think order groups might be more suitable for your needs… grouping orders on a per seat basis on a single ticket rather than ticket per seat.
By default, Kitchen Printing occurs on the Event of Ticket Closing in the Rule named Ticket Closing Rule.
When you use Add Ticket Automation Command, this forces the current Ticket to close, before it Creates a New Ticket. You can stop the Orders from printing by constraining or removing the action that fires the Print Job. Notice I constrained the Action with 1==2, so the Print never fires. The has the same effect as removing that Action altogether…
I did this because I don’t necessarily need to print every time I close a Ticket; instead, I have another button that I use to manually print to the Kitchen.
The Action you see above is a clone of the default Execute Kitchen Orders Print Job, with 1 major difference: it prints Orders no matter what State they currently have …
Thank you for your quick reply. Seems like an interesting way of bypassing this problem.
To answer your question; it does not merge the tickets but rather prints them separately. Which is okay so long as all the orders print at the same time.
I have a couple of questions if you don’t mind.
I have added a second Orders Print Job Action under “Execute Kitchen Orders Print Job” for my drink orders called “Execute Print Drink Orders.” Would the constraint still be 1==2 or is that changed now that there is another Action between Execute Kitchen Orders Print Job and Update Ticket Status? I do not mind if it prints the Drink Orders when Add Ticket is selected so that doesn’t necessarily need to be turned off.
So essentially what you’re saying is that I would turn off the action that prints a ticket when Close is selected. I see you made an Automation Command called Print Order. In that rule pertaining to that Automation Command, could I add an Action to Close Ticket as well? So the Print Order command would not only send the orders from the multiple tickets but also close the entity and bring me back to the Entity Screen. Or would these Actions now contradict each other?
I’m running low on time here and I have to get back to the restaurant so please understand if I don’t replay promptly. But I can’t wait to implement this.
No. This is just a way to disable an Action so that it does not fire. It would b exactly the same as removing the Action from the Rule altogether. It is a “test” …
A==B
does A equal B ? No.
1==2
does 1 equal 2 ? No.
'{SETTING:mySetting}' == 'Hi There'
does mySetting contain the value 'Hi There' ? Perhaps.
'{ORDER STATE:Status}'=='Submitted'
does the Order State named 'Status' contain the value 'Submitted' ? Maybe.
If the Ticket is closed, chances are, all Orders on the Ticket have a Status State of 'Submitted'.
You get the idea. I am simply constraining the Action from ever firing, rather than removing it altogether.
Why would I not just remove it altogether? Well, because I don’t like to remove things from “default” Rules. So instead, I simply constrain them to keep then from executing. This way, I don’t need to remember which Actions used to be there in the past - they are still there, but some may not fire due to such a constraint.
Sure, why not? You can do anything you want. That’s the beauty of the system. How it affects the rest of the default flow, well, I can’t say for sure. You need to try it yourself and see what happens.
But I think this will print each ticket separately. Another idea, you may want to put everything in 1 ticket (easy for kitchen) and use brand new Separator feature to separate each seat (for easy to see what seat are those order) then move orders later.
I always forgot where the state constraint for printing. Never dig it up to Action lol. Then give up, I just make automation to update order state to New for Reprint kitchen order
So I just made the adjustments. I placed a Close Ticket Action on the new rule for my Send/Print automation command. I used the original Execute Kitchen Orders Print Job action because I found I was now able to send the same order mulitple times which isn’t ideal.
One problem is that it will not print the first ticket/seat once I hit my Send/Print button. So it succeeded in not printing to the kitchen when I hit Add Ticket but now only the last Ticket will print.
Any ideas?
I may try to play around with Order Separators once I get the update. I don’t know if the Order Grouping is good for this application because I would think the servers would have to separate the customers bills once they are ready to leave.
Sorry haven’t read the whole post but my first guess based on this sentence would be that your have bypassed the fireing of the print job but the order states are still being updated.
Are you still using the original print job action? What are the order states on the previous tickets your trying to print?
Referring to q’s post - in particular;
This is my first guess based on what you said, some screen shots would help diagnose
My best guess is that the Execute Kitchen Orders Print Job has to be cloned and modified to be directed to print new orders of the whole entity and not just new orders for the open ticket.
I have explored this technique for adding and organizing orders by Seats as if they were courses. My only problem with this is that all seats are still under 1 ticket so my servers would have to manually organize and create a new ticket anyways for each seat so that they would each have their own bill. It seemed counter productive to set it up this way although it makes printing orders to the kitchen much easier and much more organized.
That print action still has status of new.
Have you chances the ticket closing rule then? If you create a ticket it will close the last one, if the closing rule is the same it will mark new orders as submitted.
If you trying to print with that job it’s looking to print new orders but all the previous tickets would have been closed and orders changed to submitted.
If I was doing what you are I would probably setup an extra state flow of say kitchen print = print on new added orders and then use print state to filter the print job and add the action to update print to printed after the print job action has fired.
Then you use Select Order Action to select order state seat no and use Execute Ticket Command action (move orders command) to move that seat to new ticket.
You don’t want 10 tickets in the kitchen for the same table, do you?
@JTRTech Yes, I modified the close ticket rule so it does not have an action to Print orders to the kitchen. But it still has the default “Update Ticket Status” and “Update Order Status” Actions.
I have no idea where to begin with this. Could someone please provide me with screen shot or some direction.
It would be nice to have the orders all come up on the same print ticket in the kitchen but if I have to have 10 different ticket then that is okay too… so long as they aren’t coming out minutes apart.
I do not think the method your using is the best way to solve what your wanting. Let me look at a few things and I might suggest something. Ideally you should keep it on a single ticket but when you print bills it automatically prints separate tickets for entities. I am thinking a state flow for order grouping and we store an entity to each group then a command to auto split the ticket and print based on that entity and order group. I think this might be possible it may take me till later today to provide an example though I have a meeting in about 30 minutes and it may take half the day.
An idea of how we might split the tickets can be found here:
Its not exactly the same thing but we can use some concepts shown.
I would see what kendash comes up with as you dont seem to be grasping what Im saying.
The screenshot for print job you showed shows State of New so it will only print new tickets. If the default closeing rule is changing to submitted even if the flow to print all the tickets was working there would only be New orders on the current open ticket as the closing ticket rule is changing the other tickets for that table to submitted (NOT NEW) so if that is your print job your using it wouldnt work anyway…
As I posted before… did you read and understand q’s post about print job action state setting.
