Need help with loan expiration algorithm

Question

So I'm stuck. I am working on an expiring credit system. Like credit cards, but not entirely accurate. By the way, I'm sorry about the book, but I needed to add enough details to help get the whole picture.

I need a system in which the user accumulates loans to perform actions. But they can also spend these loans on activities. Loans expire in 30 days if they are not used. I seem to be stuck with how to accurately calculate this in a batch that will work every night. Any ideas in any language would be greatly appreciated, as I seem to be stuck on one minor detail that I cannot get around. The following is sample data:

7/1: +5 - user registration
7/2: +5 - the user interacts with the system
7/2: -3 - user shopping activity
7/3: +5 - the user interacts with the system

So, at the moment the user received 15 credits and spent 3. Leaving him a total of 12 credits. (At least I got basic math: P)

I must add that we are currently playing with the idea of ​​creating two fields: the last processed, then processed. Thus, these values ​​at this time suggested that this is a new sign:

Last processed date: 7/1
Next process date: 8/1

So now 8/1 appears. The party starts and looks at all loans that are older than 30 days. Which at this moment is 5.

Here he begins to become fuzzy.

Then the system should look at all the loans that have been spent in the last 30 days to find out if they are using any loans. Because they should expire only if they have not been used. Thus, there are 3. Therefore, I then subtract 2 credits to the user, because this is the difference in credits earned over 30 days and what was spent. So, I will finish the game and set the dates accordingly the next day. Now, believing that they have not spent anymore, I start calculating for loans earned over 30 years, which is 5, and the remaining loans - again 3. But I obviously do not want to consider 3 loans that I counted yesterday. What is a good approach to not include these 3 loans again for consideration.

This is where I am stuck.

We are thinking of recording a debit entry for expired loans so that we can track them, but with difficulty seeing how I can use it in this calculation.

If you read this far, thanks. Even if you make some effort in return, I will at least give you a vote for the effort.

EDIT:
Ok @Greg mentioned something that I forgot to contact. The idea is to put a flag on the considered loans. A valid point, but not one that may work due to the following scenario:

Let's say that on a certain day the user spends 10 credits. But the expired loans that the package considers only accumulate up to 5. Well, he must still have 5 more loans so that they do not expire, because he spent more than one term. Thus, the flag will not work, because we would have missed these 5 additional credits. Hope this makes sense?

Answer 1

Assuming you run this batch on a daily basis, you may have a table that keeps track of all the loans received and the loans they used (negative loans).

At the beginning of next month, your task is simply to find out which of the loans received on the first day was not spent during the month.

The number of loans received on the first day - loans that they spent the whole last month. If the number is positive, they have some loans that have expired. So just add an entry to the negative credit table. This will result in zero unused loans.

The next day, repeat the process, seeing how many loans they earned on the second day, minus the amount of all loans they earned in the last month, taking into account the record with negative loans that you created for the previous day.

Answer 2

I would not try to process the data in your opinion. Instead, you should keep track of how many credits a user has and when they expire. This way you keep track of which loans were used to complete the purchase, rather than trying to complete all this later.

So, when a user subscribes, they have:

5 credits expiring on 8/1 

After interacting with the system the next day:

 5 credits expiring on 8/1 5 credits expiring on 8/2 

After the purchase, something:

 2 credits expiring on 8/1 5 credits expiring on 8/2 

And so on.

Answer 3

For each user of the system, store an array that stores information about the number of loans available to the user for the next 30 days in a row

For example, data for some users might look like this:

 8 | 7 | | 6 | | | | 5 | | | | | | | | | | | 4 | | | | | | | | | | | | | | | | | 3 | | | | | | | | | | | | | | | | | | | | | | | | 2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ^ ^ ^ | \_ | today tomorrow in 15 days 

Each time the user earns some loans, you increase the amount for all days according to the number of credits earned. For example, if a user receives 2 credits, the table is changed as follows. This is like raising the whole chart.

 10 | 9 | | 8 | | | | 7 | | | | | | | | | | | 6 | | | | | | | | | | | | | | | | | 5 | | | | | | | | | | | | | | | | | | | | | | | | 4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ^ ^ ^ | \_ | today tomorrow in 15 days 

If the user has x loans today and spends loans on them, you reduce the number of loans available to him to x - y, for each day he has more than x - y. For several days he has no more than xy, the amount remains unchanged. This is how to cut the top of the chart. For example, if a user spends 3 credits, the schedule changes to

 7 | | | | | | | | | | | 6 | | | | | | | | | | | | | | | | | 5 | | | | | | | | | | | | | | | | | | | | | | | | 4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ^ ^ ^ | \_ | today tomorrow in 15 days 

Every day you move the chart to the left to simulate expiring loans. Tomorrow the user will have the following amounts

 7 | | | | | | | | | | 6 | | | | | | | | | | | | | | | | 5 | | | | | | | | | | | | | | | | | | | | | | | 4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ^ ^ ^ | \_ | today tomorrow in 15 days 

Answer 4

How to add a flag to expenses? If the flag is not set, you can include these costs in the package, if necessary. If you use expenses to compensate for expiration, set the flag. Next time you will ignore these costs because the flag is set.

Answer 5

Use a debit entry to record normal expenses. When a monthly batch job is completed, he can calculate a total debit that is less than or equal to expiring loans. If the loans expire, simply insert the appropriate debit entry (corresponding == to cancel the excess in the application). This way, any “running general” code that only analyzes loans and debit will achieve the same balance as your batch code.

Answer 6

One approach to this problem is to store only transactions, not balance. Then you always calculate the balance in real time when necessary. Here is the data:

 Date : Amount : Expiries 7/1 : +5 : 7/31 7/2 : +5 : 8/1 7/2 : -3 : never 7/3 : +5 : 8/2 

A balance at any time is simply the sum of all transactions that have not yet expired. There is no need to start batch processes.

Answer 7

Regarding the answer of the Julians (I cannot comment yet), I am dealing with the same problem, and the Julians approach will not work, because this will lead to the account being able to go negatively.

If the user has not used the service for one month, by 8/4 the balance in the account will be -3, and one action with a value of 5 will result in the balance being 2, not 5, as follows.