1 computer running windows 7
5 users (4 waitresses + the server)
Only 1 terminal defined (the default : Server)
Other user has no special terminals defined (Terminal Name : blank) after double check this is NOT TRUE (Terminal Name = Server)
I have this problem ONLY when 2 waitresses are working at the same time.
When only one waitress works, MyNumber are serial without double.
Here is an example, I also check for the 9 days, same behaviour.
one user ok (yelow)
two users double
Some questions:
It looks like they each have their âownâ global variable, Does IsLocal:False work ? Where can I check that setting (SQL?)
The above is not exactly true because when a waitress clocks in, sheâll start with the âcorrectâ number, then will come the issue.
Do I need to setup the message server/client?
Do I have to configure the local settings for each windows user (make different terminal)? I use same printers for everybody.
No they dont have their own value unless you set it to do so.
IsLocal: False works.
You can use SSMS to open Program Setting Table. Or GQL or Show Message to read the number.
Donât think it has something to do with that.
So I think you tag the ticket and the rule not update serial number right away. Make sure right after you tag the serial number and you have action to update it right away.
Theoretically yes, though I rarely ever use the short-form, since I am used to that form being Local rather than Global (throwback to older versions). You can force selection of Local (read fro memory) or Global (read from DB) Program setting with:
I replace with {GLOBAL SETTING:SerialNumber}
Up to now it works ⊠no more double numbers: Numbers in yellow are generated since I have done that change.
Iâll confirm later tonight with more data.
That also means that IsLocal : False does not work or that I understand it bad.
Btw : I did so for a friendâs restaurant 3 years ago, but V4, and I had no issue.
@QMcKay I might need your db skills tomorrow as Iâll have to modify about 1200 ticket tag in the database
IsLocal=False does work. Never had any issues with it in 5 years. Possibly you have an old version of the Action cached in the Rules. Remove the Serial Update from the Rules, save the Rules, add the Actions back in, and Save the Rules.
V4 way a long time ago and much has changed. I suppose it is possible that some optimization is creating a race-condition and the update is not occurring fast enough before the Ticket is Tagged.
##Try this:
Another way to increment a value (and the way I always do it), is like this:
How does this ms sql server works?
Each windows user make some transactional table before updating the database?
It smells rare
Times are the same for the 4 windows users (Lima)
(I cannot test ⊠I have to wait to have real tickets and check them ⊠it takes time)
I print out a report at 14:04
I generate the Serialnumber in PaymentProcessed so at the closing-for-ever time of the ticket, which is the time I can see in the ticket list Op-Cls column
A merged Tickets will leave Tickets with 0.00 balance so you can see them pretty clearly in the Ticket Explorer.
I am wondering if your Rules are not in the correct order for what you are trying to do.
Maybe you need to move the Ticket Tag assignment into another Rule or something. Rule ordering can be important sometimes though.
We have:
Payment Processed
Before Ticket Closing
Ticket Closing
Ticket Closed
We also have an Action for Mark Ticket Closed. This is probably only in a single Default Rule named Ticket Payment Check which is a Before Ticket Closing event.
Looking at Rule Debugger, we can see which event comes before which when a Ticket is fully Paid, and it is the same order as I listed above. You can ignore the Automation Command Executed Rules
Pick out important Rules and Actions ⊠There is a lot more going on in my system during these Events; this is just an example⊠can you see anything strange in your Debugger?
Using a global program setting value as a serial number works very well. I use it in my setup daily without a hitch. The actions work just fine and its not something with MS SQL. It more than likely is something with your rule configuration or actions or combination of the both. It can be anything really. We just need to figure it out.
Using program setting to do what you are attempting to do can be tricky if you have a complex flow with multiple terminals. Remember it is fully dependant on your rule flow and what the event does and how it interacts with the built in hard coded system to prevent duplicate tickets if two different terminals taking orders at same time.
If you are merging tickets⊠you need to account for that with your system that you built. Same thing with any other automation you might be doing.
I may have missed this a long time ago but you are aware that we have {TICKET ID} which is a unique number not the same as {TICKET NO} right? Every ticket is assigned a unique TICKET ID even the voided or merged tickets.
I guess I am using terminals although in the terminal section, it points to SERVER for each windows users, so I donât know if I can do that. Do I have to define a terminal for each windows users, knowing that each windows users will start a separate instance of SambaPOS?
I donât have a clue about that ⊠You see in this country they ask you to print the tickets with a serial number which is obvious for a supermarket but not in a restaurant. For instance this month they come in the restaurant in my street and ask the first number of the day and the last number at the time they come just to see if you are cheating (=not printing bills) I donât know if that {TICKET ID} can help me with that.
In my mind each SambaPOS instance connect to a database and the database does the job (lock the table while update, release the lock, get the next query) that avoid simultaneous update/reading but what happen here is bizarre because it is not even âsimultaneousâ, there are minutes between.
I donât have account, when merged the ticket simply disappears and I can find it in the ticket list.
so TICKET ID is a unique ID assigned to a ticket once it is written to DB. It is unique and will never duplicate and it is created at time ticket is actually submitted. TICKET ID is the best way to track what you are doing. You can just put {TICKET ID} in your ticket template and print the ticket after its closed. Several ways to do that including using a print state. Or you can force it to write ticket to database at a set point to get the TICKET ID with Save Ticket action.
Ticket Id will be fine if you donât need sequential numbering with no skipping. But if you Merge Tickets, then Ticket Ids will go missing for all the merged Tickets, and a new Id will be assigned.
No, Merged Tickets do not trigger Payment Processed.
Manage > Settings > Display > Rule Debugger
I would definitely look at the Debugger. You might have something firing that you are not aware of, or something is out of order.
and much has changed. I suppose it is possible that some optimization is creating a race-condition and the update is not occurring fast enough before the Ticket is Tagged.
