htmfilho / minimily Goto Github PK

Sub-account is the possibility of subdividing an account in several smaller accounts for better budget planning.

When an account has sub-accounts:

• credits are registered in an account and the amount is proportionally distributed in the sub-accounts
• debits are registered in the sub-accounts, not in the account anymore, though the account may have old debit transactions still appearing
• every credit and debit transaction impacts the account and sub-accounts balance

Allow the user, after authenticated, to change her personal data.

The limit of credit of a category is the minimal amount of money its transactions can register in a given period of time. The limit of debit is the maximum amount of money its transactions can register in a given period of time. They are stored in the same field, but the meaning changes according to the type of category (debit or credit).

The limit of the category is compared with the sum of its registered transactions:

• Daily
• Weekly
• Monthly
• Quarterly
• Annually

Changes of the limit amount are conserved historically according to its period of time. For example, if the limit is annual and it was defined for 2018 then any change for 2019 are saved as a separated record and it doesn't replace the value defined for 2018, preserving it indefinitely. If the limit didn't change from a period to another, then the most recent limit is considered.

A different limit can be defined per currency in use. For example, if all accounts are configured in Canadian dollars only, then the limits can only be defined in Canadian dollars. If at least one account is configured in a different currency, like American dollars, then the limits can be defined for Canadian dollars and American dollars separately.

From anywhere in the application, the user should be able to navigate between the top functionalities through the top menu.

Allow defining the date of the transaction or transfer for a day in the past. The user may want to create the transaction afterwards if they don't have time. The user may want to save all the receipts and type it into the system once a week.

In case there is a leak of passwords, implement a feature to:

• invalidate all passwords
• invite users, by email and by a message in the sign in page, to reset their passwords.

Avoid showing technical terms in error messages when the application is in production. Register errors in the log instead.

Associate transfers via transaction ids, instead of account id. So, when deleting a transfer transaction, make sure the other transaction is also delete.

I input a new transaction with a comma in the Amount (e.g. 157,11) and I get the error:
HTTP ERROR: 500 Problem accessing /accounts/10/transactions/add. Reason: java.lang.NumberFormatException

Transactions are registered but sometimes the entire amount or part of it is returned to the other party. Support this event in the application gives more meaning to the transactions, improving traceability.

To solve this problem, we need to change the transaction table adapting existing columns and adding extra ones, but being careful to keep the data consistent. The current table structure solves a similar problem, the transfer of money between accounts, but the existing column is very specific to transfer. It can be redesigned to be more generic.

Create columns:

• linked_transaction (foreign key to transaction)
• link_type [TRANSFER, REFUND]

Migrate existing data:

• Given the list of transactions with account_transfer not null, order by amount and date_transaction. Related transfer transactions will be grouped in pairs.
• For every iteration, get two records at the same time and exchange their ids using the new column linked_transaction.
• Change the link_type of these transactions to TRANSFER
• Remove column account_transfer from the table transaction

My bank only shows me a bunch of log data about the transactions in my account. It doesn't help me to make decisions about my expenses, savings and investments. I need some sort of analysis of these data to see what is hidden behind the numbers.

Fortunately, my bank offers an online service to export my transactions in a csv format. This issue intends to develop the algorithm to read and import this specific file and the user interface to upload the file.

A csv file is imported. Then a second attempt to import the same file may not insert duplicated data in the database. An algorithm must be written to make sure that the database doesn't have duplicities.

Add a button in the good's page to sell the good for a given price and register the amount as a credit transaction in an account.

The categories are hierarchically organized to qualify and organize transactions into meaningful topics. New and existing transactions can be optionally classified under one category per transaction. The transaction record shows its category and the category record shows all related transactions organized by accounts.

The Total Income is the sum of all credit transactions in all accounts of the user, or the family, during a period of time.

To calculate the total income, the function requires the family and the period of time. For each member of the family, get the list of accounts. For each account, get the list of credit transactions that are not originated from a transfer. return the sum of the amounts.

• Add fields to register when a good was acquired and how long is its warranty
• calculate the last day the good is covered by the warranty
• upload the document used to enforce the warranty and make it available in the "Documents" module. Inform where it is stored so you can find it easily when needed.

In the edition of a document, allow changing the folder to any of the existing folders and move the document in the storage as well.

As a user, I want to see some visual notification after I click on "Save and New" in the transaction form, indicating that the previous transaction was successfully saved.

Allow the user to change her password.

• The form requests the user's email address
• The system checks if the email address corresponds to an address known by the application. If it doesn't correspond, inform the user the address is unknown and suggest her to create a new account.
• If it corresponds, send an email to the user, with an automatic generated code to be informed in a page where the user will gain the right to change his password.
• The form to change the password, requests the new password and to confirm it by typing it twice. Then, redirect the user to the login page, so she can try to login with the new password.
• Send an email to the user to confirm the password was changed.

The 404 code is shown in a non-standard page.

Some operations should be automated to save user's time. For that, we need to integrate a scheduler to run code at a certain date and time.

Allow the user to create a family and make her data available for all or part of the family.

Standing instructions are rules to automatically generate transactions according to recurring payments and receivables. This ways, most of the work of recording transactions is actually automatically done by the application, reducing the effort of the user.

Depends on #23

Frequency

• Annually: Once a year in a specific date of the year.
• Semi-Annually: Twice a year.
• Three-Annually: Three times a year.
• Quarterly: Four times a year.
• Bi-Monthly: Every two months.
• Monthly: Every month.
• Semi-Monthly (12 * 2): Event falls on the same two days of each month. For instance, make payments on the 1st and 15th of each month, or on the 15th and 30th of the month; therefore, there will be a total of 24 payments during the year (twice per month times 12 months).
• Bi-Weekly (52 / 2): Event happen every two weeks. For instance, choose a set day, such as Thursday or Friday, and issue payment every other week on that day. With a bi-weekly payment schedule, 26 payments are issued during a standard year (52 weeks divided by two). In this case, two months out of the year produce three paychecks.
• Weekly: Every week.

Calculate the Next Payment Date

Given:

• start date
• stop date
• frequency
• list of holidays
• optional previous payment date

we can calculate the next payment date. When the previous payment date is not informed then the next payment day is the same as the start date. The next payment date is between the start date or the previous payment date and the stop date. If the calculated next payment date falls in the weekend or in a holiday then it is recalculated to the next working day.

The following table shows how the frequency is used in the calculation of the next payment date.

We already mentioned the case when the next payment date falls in a weekend or in a holiday. An extra special case is when the day of the month is not valid for some of the months, like February 30th or June 31th.

Based on the history of transactions, which represents the spending habits of a user/family, predict for how long the money available can support the consumption pattern. The output should be the number of days left until running out of money.

The algorithm should ignore user's income transactions in all predictions, so it always considers the worse case scenario, which is when all incomes stop suddenly.

It is also important to consider seasonality because we spend more in some months and less in others. For example: we may spend more in August with school supplies and less in September when the routine gets back to normal. More in December because of Christmas and less in January. Etc.

Give additional ways to add goods instead of relying only on the Goods section. After the addition, the navigation should direct the user back to the collection or the location.