That will be because you were trying to set a program setting using the setting value when it should have been increasing the SerialNumber setting value…
If you look in database you will probably find a program setting called 161113
yes I did realize It 
then changed it but my variable names were confusing, now I am making a new action with your variable names.
Now it’s quiet I can think about what I am doing
thanks
Using [:xxx] in actions makes things so much easier.
Although you dont get the dropdown for the values where there is a dropdown like you do in an action it lets you so much clearly see whats happening plus… NO MORE REMOVE, SAVE, ADD and RECREATE the action when you need to tweek the settings
While your doing it also try qs sugestion of normal update rather than increase using the formula to calculate +1
I suggested that a long time ago, early on in this Topic, as one of the first replies … using a [:variable] for all Action Parameters, then set the Action Parameters in the Rule …
And I did it … but only for the action TAG the ticket, i did not know that we could do it also on that “update Program Settings” thing.
It can be done with all actions that have parameters. It’s recommended method. Also allows you to use same action in different rules so you can reduce number of actions needed.
2 Likes
This is second major advantage.
In theory you could just create a generic action for all the actions and never have to go into the actions section again.
I have ‘Generic’ actions for most of my regularly used actions.
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.