robertwatkins / bankedbeans Goto Github PK

Having the list of known category fields populate in the app would be helpful

The issue here is one of purpose.

There are two essential purposes for using the app

• maintenance of current accounting updates
• tax prep

Currently, the current year is hard-coded, but for taxes, you may either want this year or last year.

Occasionally, the wrong debit card is used to make a purchase. The purpose of this feature is to allow a simple way to generate the appropriate accounting entries to effectively show a 'virtual transfer' between accounts without removing the original transaction.

Thoughts on Implementation.

UI Changes

• A checkbox is added to each row
• A 'virtual transfer to:' picker is added to the top of the page
• A 'transfer' button is added to the top of the page

Javascript changes

• A function is created to read the ids for each selected checkbox and make a call to a new REST API function to create the 'virtual transfer' entries
• A function is created to read the list of current accounts from a REST API endpoint to generate the 'virtual transfer' picklist

REST API changes

• add a GET endpoint 'metadata/accounts' to return a list of account names
• add a POST endpoint 'virtualtransfer' that takes a list of ids and an account name as input and generates virtual transfer entries.

Open questions

• What if the virtual transfer was to the wrong account?
  --- Maybe initially ensure that an audit log is written locally that contains this request so that it can manually be rolled back.
  --- Maybe in the future, create a new facility to 'rollback' the transfer by transferid. This would mean that the transfers are recorded in a new table and that additional code is written to view and rollback these changes.
• What if the virtual transfer was done twice?
  --- Is it possible to detect this and silently fail on a case-by-case basis? (maybe send back a warning?)

the 'query_result' function likely leaves db connections open. This may cause issues long-term and will need to be addressed.

There is code that extracts the name of the account from the filename.

This is a customization that would be best served initially with configuration of a simple data dictionary of 'from'/'to'

Here is the section of 'process.py' that would perform that mapping. The configuration can also be used to remove the hard-coded list of accounts to transfer between.

        set_source_sql = ""
        import_file_name = file.title().capitalize().upper()
        if import_file_name.startswith("<fix this part>"):
            set_source_sql = "update transactions set source='Personal' where source is NULL;"
        else:
            source = file[:file.find("(")]
            set_source_sql = "update transactions set source='" + source + "' where source is NULL;"

Often tax and salary payments span years and can throw off calculations. This feature would provide a simple way to allow for this to be configured and managed.

Optional Approach to consider

• mark some field in category mapping as annual tracking fields where a subcategory is set that includes the year.
• Set rules to auto-categorize (any tax payments for federal or state in January are associated with the previous year by default and any checks for salary that clear before January 15th are attributed to the previous year's salary expenses.)

Open questions

• How can the annual categorization be managed without having to set up a year sub-category each year?

The main model for accounts are a single personal account as well as multiple business accounts.

To get started with the 'transfer' functionality, I hard-coded the list of accounts, rather than build an api endpoint to retrieve them.

updatememo.js line 7 is required to be manually updated between releases in order to retain the list of accounts.

This ticket would be to

• Create endpoint to return list of accounts
• incorporate that into the 'updatememo.js' script for the transfer functionality

Relying on Javascript to do this would be a complicated endeavor because you have to choose either to wait to render the page until all this metadata is returned, or updating the page once the metadata is returned (meanwhile giving the user an indication that the page is loading).