I have a final process where if a conversion transaction drops the Customer Reward Points below the threshold limit then the command Button “Convert Points” should not be shown.
The button is hidden by the use of “Ticket State:Reward=Accrued”
Ticket Screen References:
Here is the Rule:
Here is the Debug Output:
QUESTION:
The Above rule shown in debug should not fire. Is this a Cache issue? How do I fix this - use Refresh Cache but this seems a work around.
Newbie attempt to help 
, i happen to experience this before, try to enclose the constraint with “()” from the starting to the end.
So the mapped status is Reward=
Your rule screenshot shows two update ticket reward state and rule debug only 1!
You say it shouldn’t fire but can’t see anything in the rule debug to distinguish which one it is?
Action Constraints are checked when the Rule is loaded, so that the Actions are “short-listed”.
If you have an Action that updates a certain value, and then another that checks that value, that action may have already been chosen for execution or not, before the value was updated.
I guess what I am trying to say is: if you update a value, have your next action be an Execute Automation Command action. Then within that Rule, place your subsequent action(s) within it. That way, you can confidently check your constraints. I know it means creating more Rules, but in some cases it is necessary to do it in this way.
Hey JTRTech - just back from a looooong xmas party, phew. Anyway the 2 constraint scenario was adapted from QMcKay use of rules constraints in the VIP Tutorial:
If constraint EQUALS this do this Action
If constraint EQUALS that do that Action
Only 1 constraint should only trigger,so what you see is correct I think.
Hi QMcKay
Yes so what yo are saying is a kinda cache thing right? So instead of creating more rules I might just close the ticket which will force the operator to reload the Customer 
Not an elegant solution but saves a few rules and actions!
@emre would prefer SambaPOS to enforce the constraints as listed because it is just another “querk” to get around.
Just saying, as the fix for “Button Captions” worked a treat!
Sort of, I guess. Suffice it to say, it does not step through the actions 1-by-1, check the constraint, then decide to fire that action or not.
Somewhere along the way, this changed for some reason (quite a long time ago). I know it was not always the case, but only @emre can explain the reasoning, or at least (if I am wrong) the exact way this works when it comes to Action Constraints, and how it decides which Actions to fire, and when.
Hummm, its knowledge like that which has motivated my dedication to SambaPOS. Thanks @QMcKay let us see what emre has to say about it.
I think I understand that but just want to confirm.
When the rule event triggers the rule it loads all the actions BEFORE any are fired?
And it is at this point the constraints are checked?
Actions are fired in sequence though right? Just only actions with valid constraints are loaded by the rule before begining the sequence?
This would be a very helpfull thing to corectly understand as I would have initially thought (by the sounds of is as paulin does) that the constraints were evaluated at the point that action haoppens.
Yes, this is my understanding. For those Actions that do not pass their constraint, they are “thrown out”. For those Actions that do pass their constraint, they are kept and fired, in sequence.
So if you have an Action that modifies a value, followed by another Acton having a constraint that checks that value, the action may not be valid (it may have been thrown out, or has been short-listed to fire anyway with disregard to the constraint since the value has changed).
Yes, they are fired in sequence.
It used to be this way, but that was a long time ago. It changed somewhere in v4. I will see if I can find the post regarding this.
I don’t want to speak too much more on this, because I might be interpreting it somewhat incorrectly. Only @emre can confirm the exact behavior, so we need him to chime in.
I found some posts where this is mentioned…
Especially this one is what I remember, which is likely what you are experiencing in your scenario…
This I think needs clarification, not quite understanding this bit.
Suppose you’ll execute two actions if ticket’s remaining amount is greater than zero. First action pays ticket and second action prints it. If it is already paid third action displays a “already paid” message.
So our actions are
If we process action constraints the one after what it does will be…
That was what SambaPOS was doing in earlier versions. After encountering such cases a lot we decided to process them at once and execute actions that are matching to constraint.
So @pauln you should create an automation command called “Update Ticket Reward State”. Setup a rule for that and execute 3,4,5th. actions in that rule. Finally you need to create “Execute Automation Command” to call Update Ticket Reward State. By doing this you’ll be able access latest state of points.
Let’s say we have a Program Setting named MYVAL.
And let’s assume the current value of MYVAL is 5.
We have a Rule with these Actions…
Action 1:
Constraint: none
Action: Update Program Setting MYVAL to contain the value 1
Action 2:
Constraint: [=TN(‘{SETTING:MYVAL}’)] > 3
Action: Show Message “Myval is greater than 3”
Action 3:
Constraint: [=TN(‘{SETTING:MYVAL}’)] < 3
Action: Show Message “Myval is less than 3”
Action 4:
Constraint: [=TN(‘{SETTING:MYVAL}’)] == 5
Action: Show Message “Myval is equal to 5”
Action 5:
Constraint: none
Action: Show Message “Myval contains: {SETTING:MYVAL}”
Action 1 fires, which updates MYVAL to contain 1
Action 2 fires, showing “Myval is greater than 3” because when the constraint was evaluated, MYVAL contained 5
Action 3 does not fire and does not show a message because when the constraint was evaluated, MYVAL contained 5
Action 4 fires, showing “Myval is equal to 5” because when the constraint was evaluated, MYVAL contained 5
Action 5 fires, showing “Myval contains: 1”, because it has no constraint, and it reads MYVAL after it was updated.
Action 2 fires because it was short-listed when the Action constraints were evaluated. At that time, MYVAL=5, so the action fires, even though we update MYVAL in a preceding action.
Thanks, makes sence, I would have taken that expectation based on the first part of your explanation it was a clarification/example rather than an exception.
Thank you everyone for your input and taking the time to outline proper use of constraints. Happy to split my workflow sequence into 2 pieces to refresh my button status.
Worked like a charm!
For those following the last bit, “Execute Automation Command” means create a new Action and refer that action to execute the new Automation Button Command.
You do know you don’t need a button right?
Oops - should have read Automation Command - thanks & fixed.
