This can be a serious issue for some users such as myself since local regulation issue blocks of Ticket Numbers (Invoice Numbers) for use, which are valid only starting at a certain Number and Date and only until a certain Number and Date.
So “wasting” Ticket Numbers is a very bad thing in a case like this, since many/most of those wasted Ticket Numbers contain no Products, which looks odd to tax authorities, and it “eats” your allocated Number block much quicker than it needs to, requiring a request for a new block far ahead of the time that you actually really need it.
The problem is described in more detail in the following posts as we tried to locate the cause, but the short version of this story is the following which will be an issue with Pole Displays as well as the Customer Display that uses the Browser Printer, because both methods use Print Actions:
Below is one of Rules and Actions that is causing the problem … but without Print Ticket = True then the Pole Display just displays the Tags (ie. {TICKET TOTAL}) without any actual values. I guess this is all the more reason I should get rid of the Pole Display and use my GQL Customer Display (it does not use Print Actions), but still, this problem is going to affect a lot of people with Pole Displays configured in this manner.
@emre, I am having a strange problem with one of my DBs. As you know, I have 2 venues we can call JV and HH. The HH DB is ok. The JV DB is the one with the “problem”.
In PMPOS when we add an Order it is not supposed to use a Ticket Number until the Ticket is closed/submitted/saved. And this is working fine in the HH DB, but in the JV DB, it is consuming a Ticker Number as soon as I add an Order. I don’t even submit/close the Ticket, but a Number is consumed. A Number is consumed, but an ID is not generated, and there is no record of the Ticket in the DB.
Do you have any idea what could cause this? I have a feeling it has something to do with the DB itself or some Automation that causes this, because the HH DB behaves properly, while the JV DB does not.
NOTE: this only occurs with the JV DB via PMPOS. It does not appear to happen if I used SambaPOS to do the same thing
EDIT: that is NOT True. Using SambaPOS causes the same issue.
Ok, I will look at the Printing Actions, though there should be nothing different in JV that isn’t in HH. If I can’t find anything, I’ll send a backup.
And yes, HH is Happy Hour, but it is also the initials I use for one of my venues
Ok, that is not true. Using SambaPOS causes the same thing to happen, it just isn’t as obvious because the Ticket Number is not in the Header area, yet.
But if I add Product, cancel it, close, do that again a few times, then add product, select Table and close, then look at the Ticket list, there are Numbers missing, same as in PMPOS.
So this is definitely caused by something in the DB itself, perhaps some Automation config.
I checked every Rule that contains a Print Action but found none that would fire using the sequence described above and in the video, so it must be something else.
Except the Pole Display Rules (PD), LOL (they don’t contain the word “print” in the Rule nor in any Actions within, so I overlooked them.
It is the PD Rules causing this. They are for my Pole Display, which JV has, and HH does not.
They are obviously executing Print actions. Have not narrowed down to which PD Rule exactly, but I un-mapped them all and the problem is gone.
Is there some other way I can keep my Pole Display in operation without it generating Ticket Numbers?
EDIT: Below is one of the culprits … but without Print Ticket = True then the Pole Display just displays the Tags (ie. {TICKET TOTAL}) without any actual values. I guess this is all the more reason I should get rid of the Pole Display and use my GQL Customer Display (it does not use Print Actions), but still, this problem is going to affect a lot of people with Pole Displays configured in this manner.
Make sure your pole display actions are set Print Ticket to False unless it is necessary to have it set to True. So things like banners should be set to False.
EDIT: You beat me to it! However…
I have mine set to True for displaying items also and I don’t experience this behaviour… well, at least I don’t think I do! I had the same problem you mention about ticket numbers incrementing without submitting orders before and I narrowed it down to the customer display print actions. I tweaked a lot of the rules / actions and stopped it happening.
I will double check the steps you mention and see if I can replicate it with my setup or if it works fine.
Ok forget what I said earlier… I also have the same issue. I hadn’t tested that specific issue before and I can replicate it and get the missing ticket numbers.
It is definitely due to the Print Ticket = True but there isn’t any way to print the order to the customer display without setting that True. The issue I was having previously was I was printing some details about the ticket to the customer display, like table number, before any orders were added and this was incrementing the ticket number even if I added no orders to the ticket. That is the issue I solved, but @QMcKay’s issue still exists.
NOTE: You will want to change the Template named “
TIP: The Template named “