Loyalty System: Discount Per Visit

No I couldn’t haha.
I did manage to find a fix though.
Here is what I did.
I brought back original settle screen.
I made 1 change in my apply discount rule.

I changed “Execute rule if “Matches” to “Matches All”” and now. When a customer with less than 10 is applied, it will go straight to settle screen.
If a customer with more than 10 points is applied, it will go to settle screen, ask the question and if apply is pressed, it applies discount on settle screen!
Thanks for pointing that out

Ok so for now, just need to know how to apply a constraint to discount so that It checks to ensure discount=0 before asking the question.

Tried {CALCULATION NAME} but that didn’t work.
Or is it {DISCOUNT}. Hmm
EDIT: That didn’t work either. Nor did {DISCOUNT AMOUNT} Hmm is there anything else I can try?

Matches and Matches ALL should be the same with those constraints.
Just Matches as far as I understand treats different factors (first part of constraint) as ANDs but similar first part as OR.
Either way, not convinced that is the way to do it.
Surely the way to do it would be to move the entity data constraint from the rule contrants to the ask question action so settle -> show payment screen hapens regardless on automation command and the ask question only happens with the grater than 10 constrint on the action itself?

Ok so in the Ask Question action Constraint field, we would type something like {ENTITY DATA:Customer:Visits} => 10.

I did it like this.
Please let me know if I have done this correctly.

I don’t think It is because now even If I select a customer with 1 point, it still fires the rule when settle button is pressed.
Also what constraint would I use to ensure a specific calculation type is not used before the rule is fired.

E.g. If {CALCULATION NAME} != Loyalty_Discount then fire rule.

Found the issue.
And the constraint works.
Is this what you mean?

It worked when I did {ENTITY DATA:Customer:Visits} > 10. I’m guessing it didn’t like => sign.

Now I need a constraint that handles discount.

I’m wondering if there is a way we can apply 2 constraints in the action.
I’d like the action to also check, if the discount has already been applied and they decide to go back to POS screen and click settle again, it checks if discount is applied, and if so, then just go to settle page.

Found a post that says we can.

Now If I can just know what constraint for discount I could use, I reckon I can make this work!
Then I can move onto removing the points once payment is processed.

So I tried This in the Ask Question Action Constraint "('{ENTITY DATA:Customer:Visits}' > 10) && ('{CALCULATION TOTAL}' = 0)
That didn’t work lol. think I may have done this wrong

I tried {ENTITY DATA:Customer:Visits} >10 && {CALCULATION TOTAL:LoyaltyV1_Discount} = 0
But I think I have some syntax errors. Or maybe that calculation total part is wrong.

Does Calculation Total get it’s value a calculate type called “LoyaltyV1_Discount”? If so, does this mean I have to set that discount button to have a static value or can I pull the value from the discount value in the action parameter?

Not sure on cancelation expression off top of my head, use a show message action to check you get the value you expect.check printer template help ticket section for ideas.

Action constraints are great and you can string together long constriants, as you found double pipe || is or, double && is and. You can also use brackets for sectioning for more complex combinations.

I always struggled with large/smaller.you should do larger than 9 of you want larger or equal to…
Also I would reconmend wrapping the report expression in a [=TN(’. ')] for ensure it’s always a number.

Thanks @JTRTech
I will definitely try that, maybe that will help me fix the syntax issues I feel I have.
My question is, the CALCULATION TOTAL:LoyaltyV1_Discount part. I noticed you used this in one of your rules in the loyalty system you implemented(Around the end) I wanted to know, is that the correct constraint name to use?

I would expect that to return the total value of the calculation.

Ok so I tried this

But it’s still showing the same popup screen when you go back to order screen and press settle again.
Is there an issue with my constraint?

Hehe, the TN should just be arround the { } expression, to make sure it’s a number for the >< comparison
Also your = should be double == well typically, I think single = will work for numbers, believe double == is likely exact match for strings.
Also FYI you can also to != In action constraints.

As said before, use a show message action to make sure that expression is returning the value you expect.

Never tried that feature.

Woot! that did the trick.
I revamped that constraint and It worked.

So the flow is now.
If a customer has 10 points and the settle button is pressed, it will ask if you want to apply discount.
IF you choose yes, go back to order screen and press settle again, it goes straight to the screen without pooping up again.
If you press NO and don’t apply the discount, go back to order screen, press settle again, it asks again.

Ok next, to create a button to show up to remove discount if required on POS screen after discount is applied.
Then finally, the last part is removing the points.

Thanks for all your help by the way.

Ok I seem to have broken something.
When Apply button is there, whether you select it or not, you go to settle, it is meant to increase their Visits by 1.
Now it’s no longer doing that even though I haven’t changed the rule that fires this.
I checked the Show Message to see if it adds the value.

Show message shows the correct result

But when you check the Visits, its still 1 hmm…

Try a static update value and see if it updates?

The entity name/header shows visited rather than visits… Is it definatly the correct field name?

Yep. This is the Entity Type

This it the custom field

Tried This

And that didn’t work either.

I wonder what changed. I’m certain that when I first made this work, it was exactly as it’s showing now. hmm…

EDIT: Cant figure it out. I went over the rule I created to add the point after payment is processed. It matches exactly what I had before. It worked then, I wonder why it won’t work now