donnie / airstrip Goto Github PK

As of now one can only create recurring payments but cannot stop them.

One needs to add the till_date to a recurring payment so that it does not get included in calculating charge.

Simple way: Rename /recur to /start and add /stop which can just show a list of recurring payments and update the end date.

Depending upon where the money is coming from, we can assume the currency and value to be debited.

Depending on the destination account we could similarly credit the account, and then adjust the cost of transaction as well in a separate transaction.

The currency valuation could be taken from ECB Exchange Rate API.

As of now predictions are simple multiples of estimated savings per month based on current incomes and expenses. However, it does not depend on the actual savings made per month, not does this represent the potential growth in the savings per month in the coming years.

The idea here is to plot a line of best fit on the existing data of savings made per month, so as to have a better prediction of future potential.

It would be nice to get a report of costs month wise, exactly like the way savings work.

With increased requirements for privacy, we could host it even on a raspberry pi.

The easiest way to implement would be to use full stack open source messaging apps and run the server on a Pi. Or even the same server which currently hosts the app.

We could use the message app as the UI.

Ideally recurring payments do not only have start or stop dates, but they also have a frequency.
As of now the frequency is assumed to be monthly, but ideally it can be bimonthly or quarterly and so on and so forth.

Step 1:
Ideate how to reorganise the model in such a way that recurring payments are not confusing with this issue in mind.

Two ideas for doing backups:

1. Save daily backups to a specific safe space, could be S3, could be Backblaze B2 or even on the host server.
2. Respond with a dump file on Telegram when requested like so /get-dump

This is very important as backups are currently manually taken in an unreliable fashion.

If I return something and get cash back, I need to enter it as a separate entry in through /record

This can be done away with if we start marking payments as refunds.

/refund
This can show a list of payments with next and previous buttons

/refund 774
We can simply send the id of the transaction like so.

This will create a new entry automatically reverting the payment.

Instead of just printing the credited account name in the /view, it would be very useful to also mention the debited account.

For e.g.:
N26 -> Transport: €11.50

We can also use currency symbols instead of the ISO 4217 codes.

Here the scope is set from 2023-11-01 00:00:00 onwards which will not take into account transactions made exactly at 2023-11-01

During creation of an account, the liquid field is not set, and there exist no possibility to set it through the bot.
Therefore the amounts are not correctly calculated during differentiating between liquid assets and total assets.

Add question: Is this asset liquid?
Answer: Yes/ No

Accounts already have a currency column.

1. Ask question during creation with multi choice buttons and acceptance of free text.
2. During recording a transaction get live rate and do calculation accordingly
3. Predictions may happen at current exchange rates.