I have a server computer with sql 2017 installed as per guide on here and two terminals that I have connected via the local settings to the database (server computer).
So when we run sales on server or any of the 2 terminals the receipts comes out with the following.
Server i.e order number 136
Terminal 1 order number 137 and then it continues but suddenly or randomly prints an order number 137 again. Is there a way to ensure that Sambapos only prints the higher number.
When this 137 appears it prints the correct order but not the number.
are you using the increase function of the program setting action? this has come up as buggy before now, best method is t call the setting and add one in straight update rather than using the built in increase function.
Sorry I am getting confused are you saying that I should skip the reset daily counter and call the update program setting. Would you be so kind to show a mini tutorial.
Over and above that what do you guys use to make those GIF tutorials like Shivan has used on this link :
Think that might be the issue.
The solution recomended elsewhere is for you increase action make a new update setting action,
Setting name ORDERNUMBER
Value [=TN('{SETTING:ORDER NUMBER}')+1]
Type ‘Update’
Then rather than using increase your just updating using existing {SETTING:ORDERNUMBER} + 1
Just wanted to clarify is it a must to create the new action or should I just overwrite the previous increase daily counter. (Or delete it and create a new one)
I hope I understood you correctly and this is what I have done:
said new because action already in use won’t update properly.
Actions work more like templates and are saved into the rule.
You can edit but would need to remove action from rule, save rule, then add it again to refresh the action template.
I have a question does terminal number repeat or duplicate. customer Ticket numbers will increase like normal but suddenly prints a number that was printed already. Is there a way to prevent Server, Terminal 1 and Terminal 2 to prevent printing a ticket number that was already printed?
Ticket number won’t duplicate, ensure correct terminology else will be confusing for everyone.
Your custom ticket tag is repeating. Let’s refer to it as ticket counter.
This is is shown on knolage base, why would I create a new tutorial showing the exact same thing thats already there?
Show your actions and rules… and someone will likly point out your mistake.
As I said before if you edit an action you need to remove from rule, save and readd it for update to apply
I’m suspecting that there is a delay as the terminal takes about 1minute to refresh on the terminal whilst all deliveries cash was already taken on this screen (from the server).
Checked, and it doesn’t, you should use square brackets to make the field available within the rule.then the formula goes in the field of action within the rule.
Your obviously new to samba and mistakes happen. I would sugest you maybe watch a few of my beginner automation tutorials as talk through it to help you understand how the automation system works and how fields etc are used.
Thanks for pointing that out I had it set to false as well. I watched your tutorial and it is very good. So I will now create a virtual environment to play around with this settings as the environment above is a live environment.
before that I was wondering where the box below the constraint comes from but your tutorials has showed me.
I’m guessing this part >
Value [=TN('{SETTING:ORDER NUMBER}')+1]
Type ‘Update’
Then rather than using increase your just updating using existing {SETTING:ORDERNUMBER} + 1
needs to click in my head.
So I get that it works on dependency workflow where actions and rules are related and when one is changed it needs to be updated. Will play with this some more on vmware as I am hoping to sign up as a reseller asap. I had no trouble setting up the daily reset which I found on the forum. It just the last step that is needed so that my client can work smoothly.
No, square brackets with = is a formular type
Square bracket with colon is a way to carry the field to the rule.
Generally you should use that method of you want to use a dynamic value with the expression in the rule rather than the action.
Static values are fine in action but you can obviously carry the field to rule and set any value in rule.
Just a note, when you label the carried field try and always use at least two words with a space. As it is posible to inadvertently trigger rule slecific square bracket values. Took ages to work that one out when discovered it.
Using carried fields is also good for dev and learning as you can just change expressions in rule, if you do in action as said before you have to remove and re add the action to updare it.
