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”
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.
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.
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.
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
Pay Ticket if Remaning > 0
Print Ticket if Remaining > 0
Display Message if Remaining = 0
If we process action constraints the one after what it does will be…
It will pay ticket
Skip printing as remaining amount is zero.
Display “already paid” message.
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.