Developer forum

Hi Adrian,

The issue seems to be bugged by TFS 73716 already exists - nowaday user total loyalty points are not recalculated correctly not to take in account expired transactions. So, waiting for fixing. Thanks for observing.

BR, Oleg QA  

Hi Adrian,

Since the date was changed manually, try to use the following workaround. Set the "/Globalsettings/Ecom/LoyaltyPoints/LastExpirationAddInRun" setting to date in past not early than end of period boundary and perform appropriate ("Redeem expired points") scheduler task. It should fix total points for each users according expiration period set (the folowing logic is now applied - if TransactionDate value less then "LastExpirationAddInRun" value such transaction will be skipped on the next "Redeem expired points" task executing). Next run of the task will update the date correctly. 

BR, Oleg QA

Hi Oleg

Is the TFS 73716 fixed? I'm on 9.7.4 and the redeem add in does not work here either

Thanks
Kim

Hi Nicolai

After upgrading to 9.9.0 I still don't think it works. The AccessUserPointBalance is not correct. The value in "Expiration period (in months)" is in my case 3, but it looks like every row from EcomLoyaltyUserTransaction is added to the calculation.

I looked inside the addin and I'm not sure I understand this part  "x => x.ExpirationDate > lastRun" 

List<UserTransaction> list = transactionManager.GetUserTransactions().Where<UserTransaction>((Func<UserTransaction, bool>) (x => x.ExpirationDate > lastRun && x.ExpirationDate <= systemTime)).OrderBy<UserTransaction, int>((Func<UserTransaction, int>) (x => x.UserId)).ThenBy<UserTransaction, DateTime>((Func<UserTransaction, DateTime>) (x => x.TransactionDate)).ToList<UserTransaction>();

Thanks
Kim

My guess is that it is to avoid expiring points twice. Expiration of points is a transaction, and to avoid that the same expiration transaction is added more than once, this was the solution.

So if you try to clean your transaction table from all expiration records ([LoyaltyUserTransactionRewardId] = -1 and [LoyaltyUserTransactionComment] = "Points expired" and then set the "/Globalsettings/Ecom/LoyaltyPoints/LastExpirationAddInRun" global setting to old days and run the addin, you should get the right balance.

Granted - it is not the best implementation logic around - it is error prone if scheduled tasks have been out of service, moving database between installations or if error occurs during the expiration task is running...

It should be possible to completely change that logic - to just calculate it on the fly and add 'virtual' transactions to users for the expired points and let the point total be a sum of that instead of calculated value. But as you can figure out, this is not a simple change as it will be a problem for existing implementations.

Hi Nicolai

Thanks for the explanation. That's not quite the logic we need, so we'll see if we can make our own.

Thanks
Kim
 

Hi Kim

Ok - feel free to keep us in the loop, we might learn something!

Thanks, Nicolai

I think you will need to keep track of and distinguish between whether the individual transaction has been redeemed by the user or has actually expired before redemption. It will probably require an extension of the table.
 

Hi Kim

I do not think that is needed. There is a setting that defines when points are expiring, and if you know when a transaction is made you should be able to figure out the rest "runtime"

Given these transactions and a expiration of 30 days:

1. Gain 100 points (day 1) *** balance = 100
2. Gain 50 points (day 10) *** balance = 150
3. Spend 60 points (day 15) *** balance = 90
4. Gain 25 points (day 20) *** balance = 115
5. ... Day 30 ... virtual calculation ... you have 100 points that expires - but you spent 60 after the reward date, so 40 will expire. *** balance = 75
6. Gain 10 points (day 35) *** balance = 85
7. Spend 5 points (day 40) *** balance = 80 
8. ... Day 40 ... virtual calculation ... you have 50 points that expires - but you spent 5 after the last virtual expiration date, so 45 will expire. *** balance = 35

Should be possible to make as a relatively simple loop over the transactions and calculate the virtual point expirations. You could create a sorted list of the transactions on load, and as part of that add items on the expected expiration dates of earnings.

Makes sense?

BR Nicolai

Hi Nicolai

Yes and if the virtual calculation at #5 fails and you have "no last virtual expiration date" to use in #8  I guess it would say

8. Day 40 ... virtual calculation ... you have 150 points that expire – but you spent 65 since start, so 85 will expire balance = 35

I'm not 100% sure what you meen by runtime in this context, but we still need the balance in AccessUserPointBalance so we can make a smart search on that like query all users with more then 100 points.

Thanks
Kim

Hi Kim

By runtime I mean to not let the expired point transactions be in the transaction table - or alternatively, delete them and recalculate expiration everytime the total is calculated.