I have noticed on the default sample database, both usages of this action have this field blank.
I noticed if it is set to True, it appears to force creating of a new ticket to the database. I have a customer display setup, and on Ticket Closed I set the display to show an idle banner (“Welcome to …”). I have been wondering for ages as to why my ticket number was incrementing even if I just open and close new tickets without adding any items. However, if I set the Print Ticket on that action to False on that specific action for the banner, it stops the ticket number incrementing unless orders are added to the ticket (i.e. expected behaviour). It therefore appears I need to do more changes to my customer display setup to stop the ticket number incrementing unnecessarily, but first want to understand the true purpose of the Print Ticket parameter to understand if that is causing the undesired behaviour, and what, if any, implications might there be by always setting it False.
I also found leaving the field blank also causes the ticket number to increment, only explicitly setting it to False stops this happening.
For example when you trigger an XCT command you’ll set print ticket to false so it won’t skip printing.
Setting Print Ticket to true forces action to process all parameters try to generate an intended ticket print. When it set to false it skips all ticket related processing stuff and just executes print job.
But then in this case, (I mean my issue here), if I don’t set it, I end up with an empty ticket on database with ticket number incremented. If I set to False, I don’t get the issue with the ticket creation (unless orders are added of course). In both cases - True / False / blank, the job still prints (displays on customer display).
I’ve recently added that to ensure latest ticket number is accessible from expressions.[quote=“markjw, post:6, topic:9820”]
But then in this case, (I mean my issue here), if I don’t set it, I end up with an empty ticket on database with ticket number incremented.
Honestly I didn’t thought it will have such side effect. If I increment that happens, if not scripts broke because it executes at a point ticket number not generated yet… Hmmm.
EDIT: On next update I’ll check if ticket have orders before increasing counter. I hope that won’t break something else
No it’s not recent. I’ve been having problem for quite a while, in V4 as well. I posted about it before and you said it was because I had modified something:
I thought it was related to cancelled tickets but actually just starting a new ticket then closing without doing anything also caused it.
I finally broke down the setup and compared bit by bit against the sample database and found out that it is the writing to customer display that was causing it, and specifically by setting Print Ticket to False was stopping it with this annoying behaviour.
Incrementing ticket number (note: not ticket id) is somewhat annoying - it doesn’t cause any real issue, however I started getting clients ask where is ticket #103 because they see #102 and #104 via the UI. Accountants also query such missing things and think its some fraud going on.
You should direct Accountants to TicketID instead of TicketNO. For accounting purposes TicketID is what they would want. PS: i am following what your saying and I understand what your trying to relay. I tried to answer something earlier and realize I didnt read it all before I responded so I am going to patiently wait this time lol.
The way I have always looked at it is that TicketId is the real Ticket No. Ticket No is mostly for visual reference or to keep things orderly. This is the reason I print out TicketId on my receipts.
Actually I just was really asking to understand Print Ticket parameter. Now I find my setup I can stop that behaviour of incrementing ticket number if I set to False. I am not in office so can’t check customer display, but once I am there I will set all those to False relating to customer display, then hopefully I don’t have this issue anymore and from what you say I doubt it will affect my setup setting to False.
I don’t think you need to make any changes for next update, as like I say, I can fix the problem by setting value to False.
OK. We can say if you execute a print job with print ticket parameter not set to “False” it will increment ticket counter for tickets that don’t already have a ticket number. Checking order count is not a solution as we allow keeping blank tickets open by adding order separators.
Yeah I also thought like that too, which is why I kinda just ignored this “issue” I’ve been having for last 8 months. But always been in back of my mind since I know the sample database didn’t do that. And recently the accountant query, so I thought better dig in and see what I did to cause it!
If people do follow ticket numbers though, it’s never good (from a support perspective which is where I usually am) to have to explain to non-technical users why one is missing.
That’s fine. Makes sense. At least I can stop my own rules from incrementing unnecessarily, anything else that increments for other reasons is fine - like Kendash said ticket id is always the unique id, I also take ticket number as just a display value.
So I guess it’s not an option and for some I have to set Print Ticket to True. I will experiment with limiting some of the print jobs to only when an order exists on a ticket to reduce the ticket increment issue since I don’t think there is any other option.
UPDATE: I’ve kept any actions that don’t use printer tags to Print Ticket = False (actually only the idle banner), the rest have to be Print Ticket = True. Then, for any actions on Ticket Created / Ticket Opened / Ticket Entity Changed events, I have added a constraint to make sure there are orders on the ticket - if not, it doesn’t run and therefore ticket number won’t increment. So this means going in and out of a new ticket won’t increment the ticket number, but of course the moment an order is added and even then cancelled, the ticket number still increments. I can live with this.