Third waitress clocks in.
2 are now working together.
Actions are as JTRTech.
Sorry JTRTech, not helping my problem.
3rd waitress entered (2 working at the same time, different terminal)
my actions/rules:
Yes I know I can try this [=variable+1] also, and I will, however there is no reason the Increase method should not work.
It is not an increase problem, it is a “why don’t action Update Program Setting does not update the DB” problem
Program settings work, used all over the place on many systems.
On that report is the first table the current program setting?
If so how come it shows a lower number than on ticket 1501?
Have you tried the formula method, understand increase should work but if you hadn’t tried and it fixes it would show an issue with increase and answer what the problem is…
Yes - sql report on the PregranSettingValues table[quote=“JTRTech, post:70, topic:15062”]
If so how come it shows a lower number than on ticket 1501?
[/quote]
Because SerialNumber is also a variable of SambaPOS (not only a record in the ProgramSettingValues table).
Both SambaPOS programs running (2 waitresses) have their own separate SerialNumber variable that will still increase and be printed on the ticket.
I am not sure that:
{GLOBAL SETTING:SerialNumber}reads the ProgramSettingValues table out of the database.Update Program SettingwithIsLocal:Falseaction type is 1) reading the value SerialNumber OUT of the database (depends if{GLOBAL SETTING:SerialNumber}is taken out of the databse); 2) increment “+1” ; 3) updating the database right away with the new SerialNumber.
One of the 2 statements must be false.
How can they both have a serial running?
The point of using a global program setting is that they would be using the same variable and you get a increasing number increase when either uses it?
If there was an issue with delayed update I would expect you would not get both instances having a sequential number, ie two tickets on one then third on other would skip duplicates but your duplicates seem to remain sequential.
Rejiging your report showingticket closed date/time if you can, as automation is on final payment that will be most logical way to look at the progressing of the number…
If you want to PM me a backup I will take a look tomorrow if you don’t solve in the mean time.
It’s irritating me now as am not convinced it’s a big/issue and sure there is just a config error we have missed.
1 Like
I am sorry about that … it is just the fact that i am running the system for real and I cannot test as fast as I want
I am also running a restaurant which takes a lot of time, we are open 7 days a week from 6:00 am to 2:00 am.
Except in really special applications, 2 instances of a program do not share common memory space.
So it is impossible that SambaPOS run by Celia and SambaPOS run by Grecia “share” the same variable.
[:SerialNumber] variable on SambaPOS run by Celia
and
[:SerialNumber] variable on SambaPOS run by Grecia
will be incremented independantly.
To share info between the 2 instances of SambaPOS, we could:
- On 1 computer we could use a file store on the HD to store that variable, but what if 2 different “computers”
- Or we can program and open some port to communicate between instances (that’s maybe what message server is doing, I don’t know, never used)
- Or a database
Now as I understand (but it is just a guess) Update Program Setting Action should work like that:
- read {GLOBAL SETTING:SerialNumber} (from DB?)
- Action Type : Increase; value “By 1”
- Put that in [:SerialNumber] variable
- Update SerialNumber record in ProgranSettingValues Table with [:SerialNumber] variable.
But apparently it is not the case.
So now from the really nice post of @QMcKay (below), the syntax (bracketed, not bracketed, server side, …) is important and you reach different element with the same “name” (variables, database values, …) so maybe my syntax is not good but that I cannot check.
I know the post below is about report but honestly I don’t know what I am doing when I write:
SerialNumber
[:SerialNumber]
{:SerialNumber}
{SETTINGS:SerialNumber}
{GLOBAL SETTINGS:SerialNumber}
Now
Ok I think I understand and @QMcKay will be mad on me.
I cannot use the Update Program Setting with increase because it will not read the database value of SerialNumber but just the variable SerialNumber which are different on each “tablet”.
Update Program Setting with increase will only work for 1 terminal used by 1 or more users.
As he mentionned a long text ago, I have to use the current database value {SETTING:SerialNumber}, add 1 to this value, and update the new value to the database.
I am aware about the frustration I did cause, sorry for that.
Finally I understand.
A last one:
Tomorrow I have to correct about 1500 tickets.
Only tomorrow at lunch time I will really know if it works
Ive briefly read your issue so apologies if youve already tried this
Have you tried separating the increase serial number action and the add ticket tag action into different rules. As they are both in the same rule the actions happen at the same time, they do not fire in order so you couldnt be adding the new serial number and then adding that new number as a ticket tag at the same time, the new number wont exist yet so it will use the previous stored number instead causing the duplication
Why not increase your serial number on payment processed, so remove the update ticket tag action from those rules
Then add the update ticket tag action in a before ticket closing rule or ticket closed rule
This will allow the new serial number to be created and stored in one rule so that value can be read in the ticket tag action in the second rule
That is not true. Kendash said the same thing. It simply is not true.
Actions are fired sequentially in a Rule, not at the same time. They are fired one after the other, in the order that they are organized in the Rule.
If the Actions fired at the same, and not in the order in which they are placed, the entire Automation system would break. It would not work.
Action ordering in a Rule is important, because the Actions are fired sequentially.
I think I heard emre say so too IIRC. something like multithread. But I never have problem with it. I always put a lot of actions in the same rule.
Action Constraints are checked simultaneously, and the Actions are short-listed to throw out Actions that fail to meet their Constraint criteria. This is why you can’t set something like a Program Setting in one Action and subsequently check the value of the same Program Setting in a Constraint in the next Action. That does not work.
However, even after short-listing the Actions, they are fired sequentially.
Thats where i got the info from, kendash, as hes always said that its what ive always believed to be true 
Pretty sure I got it from emre once from a project I was working on. I could be wrong though. It’s hard to search that on forum. To clarify I did not mean it’s always that way. I was under impression there are rare times they don’t.
Ive always been under the impression for a rule;
Rule constraints obviously define if the rule triggers on specified event.
Then all action constraints are evaluated and actions short listed before any actions fire.
Then actions are run in sequence.
This often becomes the reason for splitting a rule using an execute automation command action so you can run a few actions then run a few more based on what those actions have done.
I am not sure what happens with execute automation command action if the branch of automation from it happens before the next action in that rule or if it runs in parallel but typical use is to do seperate things or last action to follow on so never had a senario where it was important.
If actions didnt happen in sequence flows like my booking setup would be buggy as it contains a create entity and update entity and if they ran asynchronously the update would not have an entity to update.
1 Like
Another day in Paradise …
not working.
That is the yesterday night tickets, same thing happened, now incremented with @QMcKay [=x+1].
Now I am using {:GLOBAL SETTING blablabla}
I will try with {:SETTING: blablabla}, wait 4 hours for the lunch time (2 waitresses)
If not working I will try {:blablabla}, wait until the night shift (2 waitresses)
However it’d be nice that sombody explains me what are theses syntaxes.
These IsLocal or these GLOBAL …
- do they refer to the programming language? like local to a functions, methods, classes?; global to main?
- or is it a vocabulary specific to SambaPOS? like GLOBAL means “SQL Sored”; local means “not SQL Stored”
I see something like this:
One waitress is working (logged in windows, “her” SambaPOS started) - all good, SerialNumber walks one by one.
The 2nd waitress comes in (logs in windows, starts her instance of SambaPOS), starts to send orders and finally charges her first customer with the current DB SerialNumber, let’s say SerialNumber #10.
During that time the first waitress charges her customers (she has of course more) and SerialNumbers goes up, let’s say:
8
9
10
10 (?)
11
12
13
The second waitress charges her 2nd customer and her SerialNumber will be 11.
Her 3rd customer will be 12; then 13; etc …
So I finally have (2nd waitress in bold)
8
9
10
11
12
13
11
14
12
15
13
– first waitress leaves
14
15
16, etc … till the next shift.
(Note 1: the first row is the SerialNumber today)
(Note 2: don’t look at the name, these are Ticket related, not Payment related and that SerialNumber is setup when Payment is made)
(Note 3: any waitresses -TU- can order for the same table; the one who settles -PU- the table receives the money and print the SerialNumber)
Ive always used {SETTING:xxx}
Question:
@QMcKay : in your exemple, Update is not a variable; Is Local is a variable
in JTRTech exemple, Update is a variable; Is Local is not a variable :
Which one is correct? Both?
It isnt really in mine either, I changed it as at the time you were still using increase.
I usually have two setting actions one for global and one for local.
Both only ‘carry’ the fields (<-- better term than variable) for setting name and value.
I only ever use update (not increase etc) and islocal is set depening on which of the two actions it is Global or Local.
1 Like
No.
Yes.
Local, stored in memory on the Terminal (in the SambaPOS instance memory space):
{LOCAL SETTING:SerialNumber}
Is Local = True
Global, store in the Database:
{GLOBAL SETTING:SerialNumber}
Is Local = False
Could be Local or Global, depending on how the Program Setting was “set”:
{:SerialNumber} // generally refers to a setting that is in-memory (Local)
{SETTING:SerialNumber} // this is a PRINTER TAG that can access a Program Setting, whether it be Local or Global
Both. It is up to you which you use.
The difference is that when you use [:variables] for all Action Parameters, then the Action is FULLY GENERIC, meaning that you can use it in ANY Rule, and supply the Action Parameter Values in the Rule. You could define FULLY GENERIC Actions for every Action Type, and never define another Action again. You would then use the Generic Actions in any Rule, and set the Action Parameter Values in the Rule.
If you choose to hard-code some Action Parameters, (ie. Update Type:Update or Is Local: True), and use [:variables] for other Action Parameters, then the Action is no longer FULLY Generic in that some Parameters are hard-coded, and you cannot change them in the Rule, while the Parameters for which you used a [:variable] can be changed/set in the Rule.
Someone with an RDP setup needs to test this. Unless you have something wrong in your Rules, then it must be the RDP causing this. I am out of ideas.
I’m using RDP, 1 server and 2 tablets. I don’t have issue but I never both tablet settle at the same time. Most of the time I use sever to settle 90% of the bill. Server has cash drawer and credit card terminal so I always use server.