Well done @QMcKay.
I was just about to sit down and finish this off
You can consolidate a few Actions by entering more Action data within the Rules, and using GCStatus will overcome multiple entities being selected on a Ticket.
What you have done is why we try to encourage people to learn how Rules & Actions work. As everyone will end up with their own customised version of SambaPOS, it can get hard to provide generic solutions that will work for everyone. But to understand the concepts and then apply these to your own setup means that your embracing the power of SambaPOS and your producing a system that is tailored to your business - something that no other POS system can claim.
Great implementation @QMcKay. Really good job. I remember the day @JohnS decided to push SambaPOS limits forward. I still canāt believe the point we reachedā¦
No SambaPOS is not awesome. Youāre awesomeā¦ Iām proud awesome people trusted SambaPOS and used it as a part of their businesses.
I have run into an issue while testing different scenarios. It has to do with the order in which different Payment Types are Tendered, and is specifically related to my GC Balance button.
For example, customer orders product with Total of 200.
A GC is selected - it has a value of 100.
If I tender the GC first, everything works fine: GCBalance=0, TicketBalance=100, which I can Settle by Cash.
However, if I tender some cash first like 150, leaving Ticket Balance at 50, then I click my GC Balance button, it subtracts 200 from 100, putting the GCAccount into a positive Balance of 100 (it also marks the GCEntity as redeemed, and sets GCEntity GCBalance to -100).
I believe the root of the issue is use of {TICKET TOTAL} instead of {BALANCE}, though Iām finding that {BALANCE} may not always report the correct value (shown on the Payment Screen in red).
You will need three rules for when the GC Balance Automation Command button is pressed.
1ā¦ GC Balance less than Ticket Total. Pay using GC Balance
2ā¦ GC Balance equals Ticket Total. Pay using GC Balance
3ā¦ GC balance greater than Ticket Total. Pay using Ticket Total amount
Iām trying to get around the problem of what is stored and when. I came up with the idea of trying to store the Entity Balance in a Program Setting.
So Iām working on a Rule for event Entity Selected. [:EntityName] seems to work ok, but none of these have values: {NAME}, {ENTITY NAME}, {ENTITY NAME:Gift Certificate}, {ENTITY BALANCE:Gift Certificate}, {ENTITY DATA:Gift Certificate:GCBalance} ā¦ not sure why that is, but whatever.
@emre or @JohnS, I see there is [:EntityCustomData]. What is the correct syntax for retrieving GCBalance custom data from the Entity? (i.e. [:EntityCustomData:GCBalance] ?)
If I simply use [:EntityCustomData], I get this:
[{"NAME":"GCBalance","Value":"100"}]
So the information is there, I just donāt know how to access itā¦
Right, except, as in my prior post, both {ENTITY BALANCE:Gift Certificate} and {ENTITY DATA:Gift Certificate:GCBalance} are not available (empty) in the Entity Selected event, which I find strangeā¦
I donāt see an Entity Changed event in the picklist in Rules. EDIT: ok, yes, Ticket Entity Changed, hold onā¦
Hereās some more informationā¦
If I Select Gift Certificate (Entity) and use a Message to display info, all of the previously-mentioned values are empty/unavailable.
If I then click Change Gift Certificate, and even if I select the same previously-selected GC Entity, suddenly the Message has access to the values (i.e. {ENTITY DATA:Gift Certificate:GCBalance} contains the value 100).
Weirdness.
EDIT 2: ok, YES! Ticket Entity Changed gives me a value for {ENTITY DATA:Gift Certificate:GCBalance} (100) and {ENTITY BALANCE:Gift Certificate} gives me a value (-100)ā¦
I give up. I can use the āGC Balanceā button carefully, but I canāt make this foolproof. Iāve removed the āGC Balanceā button from my Payment screen. Perhaps in the future weāll find a way to do this as features are added.
The rest of the implementation of the GC Sales & Redemption Tutorial still stands strong though!
EDIT: I now have this working, please see updated post:
Iāve continued to work on this setup, and have since learned a few new tricksā¦ Iāve solved some problems, and reduced the number of Rules required by using different values, such as [:ProcessedAmount], [:RemainingAmount], and [:TenderedAmount], instead of {TICKET TOTAL}, {TENDERED TOTAL}, etc.
I will post the new setup (the old setup is buggy) when Iām confident I canāt trick the system into being overdrawn. I have a good feeling about it again now - just needed some time away to reflect and ponder.
I think I have it beat! One small question before I put together the setup to post here:
In the Rules, within calling an action (see screenshot), can we use operators to test for more than 1 condition? For example: AND, OR, or &&, ||. Is this possible?
([:RemainingAmount]<=0) AND ([:ChangeAmount]<=0)
([:RemainingAmount]<=0) OR ([:ChangeAmount]<=0)
Perhaps in the future weāll find a way to do this as features are added.
