I was scratching my head to work out why I had some missing ticket numbers in my database, but I think I have finally nailed it down…
Start with a fresh install, new database…
Create a product
Add the product to the menu
Start the work period
Create a ticket for new customer “Steve”
Add an item
Cancel the item
Print the bill
Create a ticket for new customer “Dave”
Add an item
Settle the ticket
The ticket number for Dave will be #2 even though this is the first ticket to be successfully settled. What is even worse is that ticket #1 won’t exist in the database.
The above situation is not actually the exact user flow that is causing the missing tickets in my shop but it does demostrate what is happening. It seems that the Print Bill action is somehow advancing the Ticket Numerator without a ticket ever actually being committed to the database.
Can anyone confirm?
For now I have change some of my rules so the print action is not being fired at a time when this issue could be created.
Ticket number is created when ticket is started…
Ticket ID would not have been used for that first ticket. It isn’t added untill ticket closing/submition for the first time.
Ticket number is not sequential in DB but to the above.
We need both to allow certain functions, ticket number gives a reference available before ticket submition/closing.
Ticket ID is logged to DB and is the key for the tickets table.
This is not an issue, it is expected behaviour.
It has nothing to do with print bill.
The flow you state would still use a ticket number on that first ticket even without print bill.
Hmm… there is a “new” parameter in Execute Print Job Action named Update Ticket Number.
Try setting that to False and see if the behavior continues, or if it causes other “bad” behavior.
If that doesn’t work, put in some constraints, for example…
My system won’t allow printing of a New Ticket that has no Orders. This is because I have a Rule on Order Cancelled which Closes the Ticket if the TICKET TOTAL is 0.
You could probably also constrain the Print Bill Rule to not print if the TICKET TOTAL is 0.
I don’t think so. If I create the ticket, add an item, cancel it and then close it neither a ticket ID or a ticket number is created and the next ticket appears in sequence.
I know the ticket numbers don’t have to appear sequentially in the DB, but there shouldn’t be a situation where a particular ticket number just doesn’t exist at all.
How can it be expected behaviour for a user flow to mean that your ticket numbers are non-sequential. Right now it looks REALLY suspicious to the authorities that I have tickets 122, 123, 125 and 126 but not ticket 124… What was ticket 124… There is no evidence of it ever exisitng in the DB.
Yes, this is the temporary fix I have in place. The logic I actually use in my system is to print of Ticket State Updated (Status=Paid). But the problem was that with the default rules a ticket closed with 0 remaining will be marked as paid even if the ticket total was 0 (call items cancelled). So I fixed this my adding another contraint.
I never realised that these cancelled tickets were being marked as paid and therefore a print job was being run because nothing actually printed (I guess because by that moment the ticket never really existed.
Yep… This seems to fix it. I am worried in case it introduces any other potential issues. Is there any documentation of the background to this feature?
Beyond this “fix” do you think this should remain as an issue? It doesn’t seem right that it is possible for the numerator to advance without a ticket being store with that number in the database.
Ticket number isn’t designed to be sequential and isn’t written to the database, ticket ID however is. When you have two separate tickets for example, when you merge them there can only then be one ticket number as you have merged 2 into 1, this also will look like a number is missing as one of the ticket numbers before the merge is no longer used
I have been printing the ticket numbers on my customer’s receipts because I have been using other ticket types to track other things happening in my business (equipment in and out for example), so I had separate number generators for all of these things.
I guess I should start using ticket IDs, but in terms of the sales tickets I issue to my customers, they will appear to be non sequential.
I disagree. There is no point to the Ticket Number Generator if it isn’t sequential. That is the exact purpose of the Number Generators. And it is written in the DB, of course, in the Tickets Table.
The point about Merging makes sense, and it has always been that way. No real way around it unless you create your own serial numbers upon Status = Paid.
I would need to dig up the post, but suffice it to say, I noticed my Pole Display Print Job was advancing the Ticket Number. There is no reason that should happen, so Emre added that Parameter. By default then, the value would be “True”.
Probably not an issue if that parameter fixes the issue… Merging Tickets will cause skipping too. Well, not really… it causes Empty Tickets, but the Numbers are still there.
So I am confused then…
Ticket number is available from first ticket creation yes?
So on a multi terminal system…
Till A start a ticket - number 1
Till B start a ticket - number 2
Till A cancels all orders and closes.
Till B pays ticket number two and it gets ticket ID 1.
Am I missing something.
Unless the ticket number generator goes back and uses 1 surely that would be expected skip.
Or is the case that actually ticket number 1 should still go to db and get ticket ID but be empty as in merge ticket senario.
I do not think Ticket Number is generated upon Ticket “creation” (Order Added or Entity Selected).
I think it is generated upon other events, like Ticket Close (only if the Ticket is not empty), or as we have seen, executing a Print Job.
The scenario you list supports that theory. If it did not, then both Tills would get the same Number.
Cancelling all Orders and Closing the Ticket does not generate a number (it is not increased). But executing a Print Job when a Ticket is open can generate or increase the number, if that Ticket does not yet have a number.
I do not think Ticket Number is generated upon Ticket “creation” (Order Added or Entity Selected).
I think it is generated upon other events, like Ticket Close (only if the Ticket is not empty), or as we have seen, executing a Print Job.
The scenario you list supports that theory. If it did not, then both Tills would get the same Number.
Cancelling all Orders and Closing the Ticket does not generate a number (it is not increased). But executing a Print Job when a Ticket is open can generate or increase the number, if that Ticket does not yet have a number.
So would a display message with {TICKET NUMBER} not show anything before printing (after creating ticket and adding an order or it would create the number because it had been requested?
I would agree with @QMcKay that it seems silly to have a number generator that can record non-consecutive numbers to the DB. I guess it’s just that it might be a bit surprising that the “Execute Print Job” action can increment the Ticket Number.
What would be the need for “Update Ticket Number” to be set to true? Should we make a feature request to default it to False, it seems like that would probably fix more issues that it would create?
I don’t think anyone really noticed this until recently, so the “Update Ticket Number” parameter on the Execute Print Job Action never used to exist (like the parameter being True).
It just always updated the Ticket Number by default, because it assumed that if a Ticket was open and a Number had not yet been generated, it should generate it at that point so that {TICKET NO} would produce a value in the Template.
It came to light when I noticed I was losing Ticket Numbers, and it was because of my Pole Display. So I Add Order and it fires the Pole Print Job, which generated a Number. But I did not want that, because my Numbers are tracked, and I get them in “blocks” and need to apply for more when I start reaching the end of the “block”. It wasn’t so much that I had “phantom ticket numbers”, it was more to conserve numbers in my block.
Should the parameter be defaulted to “False”? Maybe, but it is a matter of opinion I suppose. It has always been “True”, so that has become expected behavior.
I mean, if the Print Bill Job was defaulted to “False”, and you add orders, then hit Print Bill (which by default prints and then closes the Ticket, saving it to the DB), the print will have no Ticket Number, and the Number in the Tickets Table would also be blank. Not sure that is what most people want.
I think it is probably best to just prevent Printing of an Empty Ticket.
