Custom Simple Loyalty Card Features

In the Action, use this as the parameter for Amount:

[:amount]

Then remove the Action from the Rule, save it, re-open it, and re-add the Action.

Within the Action inside the Rule, you should now see a parameter for amount.

Place the formula inside that parameter:

[=TN('{TICKET TOTAL}') * 5/100]
2 Likes

Yes you need to use variables, actions sometimes dont behave right when running expressions if you dont. Thank you @QMcKay for spotting that.

Hi!

Great, thanks very much Kendesh and QMcKay!

1 Like

Hi,

I just thought I’d add a comment here. If you do use the 5% loyalty points code, don’t use a payment processing rule, use an order update rule. The reason for this is that if you use the payment processed rule and pay half, the customer will receive points and then once they pay the rest, they’ll get more points.

Regards,

Alex

Hi Kendesh, or QMcKay.

Another question, sorry.

If a card has 5.00 and the order is 10.00, and the card is set to credit, is there any way to pay off 5.00 by the sambacard and the rest by cash. i.e. a button that will allow you to use the balance of the card on the bill. Obviously, the operator could just go to the card and see how much is left and then enter the amount manually, but is there an automatic way to do this.

Regards,

Alex

It is possible by using Automation.

I did this very thing with the Gift Certificate setup…

It uses the Entity Account Balance to determine how much of the bill will be paid, without overdrawing the GC Account, leaving the remainder of the bill to be paid by other means of your choice.

You can restrict this behavior by using a loyalty state… if ticket loyalty state is true it will not execute the action… if false it will add the 5%.

Thanks Kendesh,

QMcKay, OK, so in this case, there is already a pay by sambacard button, so would I need to make a new button to use this automation rule?

Yes, exactly.

It looks like this:

That button allows you to pay the bill up to the amount that is available in the GC Account. So in this case, it would pay 100, and leave 200 remaining to be paid. This next shot shows what happens after clicking the button:

Great! I’ll give that a go, sorry to be a pain!

Here is how you would setup the Payment Processed so it does not allow double points.

Setup the same rule as you had before on Payment Processed but add this Custom Constraint:

{STATE:Loyalty} Not Equals True

Then add an Update Ticket State action that uses State Name: Loyalty
State: True

It might look like this.

Remember you would have your Create Account Transaction action in it as well.

So this rule would check if Ticket State Loyalty is anything but true and then execute if it is. If Loyalty is True it wont execute… if executed it sets state to True.

@alex1 its best to use payment processed so its based off amount spent. If you do it on order updated… then if order is cancelled and another order added it wont cancel your points…leading to abuse.


Instead of Ticket Total we could use ProcessedAmount and add points based off amount processed. If you do this then you might not need the constraint. Syntax would be like:

[=TN('[:ProcessedAmount]') * 5/100]

This tells it to do 5% for amount processed instead of ticket total. Meaning it wouldnt matter if you did two payment types and you could ignore the constraint i just told you about.

@alex1 this shows you two possible routes you can take with Payment Processed event. Using the last one is preferred as its the simplest all you would do is change the expression.

Thanks Kendesh, that’s great too!

Morning!

I’m just playing around with the tender code and started by making a very simple new payment button but the issue I’m having is that I click the button, but it only updates the order if I press the cross symbol, does this happen with yours?

Thanks!

Hi QMcKay, one more thing, have you noticed that the system isn’t updating in real time using the custom payment buttons?

i.e. If they use the whole gift card to pay a portion of the balance and click tender gift cert again, it allows the balance to go below zero (even if it is set to credit), because it appears only when the entire order is paid for that the gift/samba card balance is updated properly.

The difference is in the GC Rules for Payment Processed. You should look at those in the Tutorial.

Basically, the Rules check the Balance of the GC, and if it hits zero, the GC Entity is replaced with a “dummy” GC that has no balance, and is named in such a way that it does not pass the constraints in order to be used as payment.

Notice my 2nd screenshot where the GC has been replaced with the dummy Entity called ZZGC2000. Because the name does not start with GC20, the constraint in the GC Tender Rules will not allow processing of the Payment. Besides that, the constraints are also checking the Account Balance of the Entity to ensure it is greater than 0.

Hi!

Thanks, so that works however in this case, as we need to add a percentage of the transaction to the card at the end, this won’t work as the card has been changed to zero.

So I was thinking, could I instead just disable the button itself, I tried to but didn’t have much luck, could you please shed some light on that?

Sorry again for bugging you!

-Alex

Hi,

I worked out the issue above! Essentially, only allow the GC tender to be pressed at the beginning of the transaction, add actions to add points on the tendering rules, and add a ticket closing check that adds points if the card is not the void card!

I would love to hear if you have an alternative method though, I’m sure there is a more elegant method?

Also, any idea about why I have to click the (X) button after tender GC to get it to process?

Regards,

Alex

You are using TENDERED TOTAL in your amount to tender…

Hi Kendesh,

Thanks, this is my current setup:

I know you said to remove tendered, but I tried to remove tendered and it still didn’t work. Do I need to remove tendered from the conditions too?

Instead use {:TENDEREDAMOUNT} so it would simply be {:TENDERED AMOUNT} for the entire expression.

You map it to Payment Screen. {:TENDEREDAMOUNT} reads the amount entered from payment screen

To summarize what I mean:

Change anywhere you have [=TN('{TICKET TOTAL}')-TN('{TENDERED TOTAL}')] to {:TENDEREDAMOUNT}

Your last constraint would change to {:TENDEREDAMOUNT} Equals {TICKET TOTAL} no need to format it with TN.

Additionally:

{:PAYMENTDUEAMOUNT}

Is available as well. You maybe could use that tag.

{:NUMBERPAD} Reads numberpad value.
{:PAYMENTDUEAMOUNT} Reads payment screen payment due amount.
{:TENDEREDAMOUNT} Reads payment screen tendered amount value.