I am trying to change my loyalty setup an use the credit as a discount which in theory is what it is and not an actual tender.
I have the discount working and the loyalty credit being removed.
Issue 1 is that the entity balance does not update live on the screen. Not a major issue but staff may not be sure if it has gone through.
Issue 2 which is the most important. It will let me overdraw the account, even though the account types are set to credit. I would like it to behave like account tendering does.
Here is my setup
Here is the loyalty card accounts. Customer had 500 in credit.
It then allowed me to redeem 1000. Can I constrain the calculation type to only allow entity credit or less?
I have the Calculation Method set to Fixed Amount. There is an option for Custom but I can’t see how it works
Or even if I could put something like {ENTITY BALANCE:Loyalty Card} in for the Max Amount in the Calculation Type it would effectively do the same thing.
That depends on your point of view. I don’t consider a GC Purchase to be a Sale. It is exchange of money for a piece of paper, like a Credit Voucher. Yes, we receive money for it (or not) which we need to track for end of day Cashout reconciliation, but it is not really a Sale. The Sale comes later when the GC is Redeemed for actual Products.
I suppose that is a matter of preference, and perhaps legality in your area. It is an interesting idea, because it could effectively skirt the amount of Sales Tax that you would remit.
Yes so when we take payment the money goes into a liability account for later use. When the certificate is redeemed the money moves from liabilities to payments.
If no payment is taken then the liabilities account will be down when the voucher is redeemed
Where can this discrepency be shown in our records?
I think a free gift cert is essentially a discount voucher.
In Ireland we only pay tax on actual money recieved. That is why I am trying to diffrenciate between a paid certificate and a free voucher or loyalty credit. The way it is now I would essentially be overpaying tax on money I never actually received.
Yes or you could use a custom button in the menu if thats where you would prefer the button be.
I always overcomplicate things too when I am trying to work something out. Then a quick post on the forum gives a really simple (obvious) soluition making me feel like an idiot. But thats why outside perspective is always a great tool. Without other users input on this forum, I would probably spend days staring at problems, completly overlooking the solution.
Also on this I think the ticket total should show the total for money or paid credit tendered.
For tax legalities the discount could be applied before or after tax (include tax checkbox on calculation type) depending on your countries laws.
Using round in default setup even if you round 90% of ticket total the tax is calculated from total before discount, which I had to change for my country.
Maybe i am looking at this completely wrong but i cant see the difference between a % discount or round with free vouchers or earned store credit.
And if modifying ticket total is not the way to do it then should round or discounts not be set up as tenders?
Ok, well you need to decide what/how you want to do it.
So the important thing you are trying to figure a way to use the GC as a Discount Calculation (Ticket Level) but constrain it in some way to ensure the GC Account is not overdrawn. I think we might be able to do that - I just need to play around with it to figure out how to implement. I have a couple ideas.
There is Limit function in Payment Processors. Not sure if that helps.
It is really “different” on how that works, but it could be the key to this. Here is a summary based on scraping other posts in other topics …
Set the Calculation Template to “Custom”.
Create a new script and set the Handler as Calculation_[CalculationTemplateName] for example, if your calculation template name is Service it should be Calculation_Service
Code examples:
result = (Ticket.PSum + Ticket.PreSum - Ticket.Tax) * 0.08
result = (round up (Ticket.PSum + Ticket.PreSum + Ticket.Tax) * 20)/20 - (Ticket.PSum + Ticket.PreSum + Ticket.Tax)
Note that the round up function is no longer available in V5 due to the change in the script engine.
PSum is already non discounted amount.
PreSum is pre-tax servicing amount. PreSum is not only discount. It returns total of all services.
AFAIK these are the rules to this, in summary:
Name the Script Handler as: Calculation_<calcTypeName>
assign calculation result to: result
we have only these values to work with:
Ticket.PSum (non discounted amount)
Ticket.PreSum (pre tax servicing amount)
Ticket.Tax (tax amount)
I don’t think we can set that Max Amount property even via the Add Calculation Action, but we may be able to get around that with alternate Automation to store the Balance and set the Fixed Amount based on that.
Well i dont necessarily want to do it just because I think its how it should be done. It just looks like the most logical way to do this to me.
I know sambapos can handle this fine but how can I enter into an accounts package or explain to my accountant thatt this is my sales total but we actually didnt get paid for 20% of it as it was a free gift cert.
I know I could simply subtract the gift cert total from the sales total but a) my tax would be wrong and b) I think it makes more sense to have this done within Samba
This is what I am thinking about … when the GC Entity is selected, we store the Account Balance and apply the Calculation whenever we want.
When we finally do fire the Calc Action (ie. maybe in the Settle Rule), we use 3 identical Actions which are constrained by the GC Account Balance to ensure it does not get overdrawn. I do a similar thing in the GC Tutorial to ensure GC Tender does not overdraw the Account. The Automation then swaps out the GC Entity with a “dummy” Entity named ZZGCDUMMY.
So for the Ticket Entity Changed Rule, we simply store the Balance in a Local Setting, and maybe fire the first GC Calc to ensure that calculation Type has not already been applied.
I show the other GC Calcs in this screenshot as well, but they (all 3) probably should go somewhere else, like in the Settle Rule.
Thank you I will try this when I am at my PC later.
I wont be able to put it in the settle rule because for the loyalty system, every time the enitity is selected they won’t necessarily want to use their credit.
I will just add an AC to the bottom of the payment screen like redeem LC points and apply voucher for the free G.Certs
Is there any way to navigate back to POS screen from payment screen.
The Navigate Module : Pos action does not work.
I just want to make it easier for staff, so when no Loyalty card is selected, It auto switches to POS and they can scan card and settle again? I know it only eliminating clicking the close button but it would be more intuitive for new staff.
I already have a button on the payment screen to redeem loyalty card points.
I have a rule where {ENTITY NAME:Loyalty Card} is NULL to show a message that no card has been selected, please scan card again. I thought it made sense to have it auto switch back to POS screen where they could scan the card.
I also tried the close ticket action but it brings me back to entity search screen.
