Record keeping in Rails

Ruby on Rails
1

I’m working on building a budgeting tool for myself. I currently use a spreadsheet, but I thought it’d be a good exercise to try to build an app that has a better interface for this. I thought it’d be pretty simple, but I feel I hit a wall when it comes to record keeping.

For example:

In May, a user has a student loan balance of $1000.

After making a monthly payment of $200 in May, the user now has a balance of $800.

Some time passes… It is now June. The user would like to know what his balance was before his monthly payment.

This would appear to me to some basic record keeping, but I feel I don’t know enough to approach this problem. Is anyone able to point me in the right direction? I feel like I’m missing a concept here.

2

I would probably use a table of transactions with fields for date, description and amount. The amount would be positive or negative depending on if it was a credit or debit. The initial balance would be treated as a credit. To find the balance on a given date, you would sort the transactions by date, and sum the amounts within the appropriate date range. So in Rails it would look something like:

class Account
  def balance_on_date(date)
    transactions.order(:date).where(['date <= ?', date]).sum(:amount)
  end
end

On a real system you would probably store the updated balance against each transaction for better performance.

2 Likes
3

Alright, that makes a lot of sense. I like the idea of adding a transactions table. This whole time I was thinking of just adding functionality to the account class, but this makes a heck of a lot more sense.

Thank you!

4

Now you’re thinking with objects!

But seriously, Object oriented design is an art form, and takes some time to realize. Rails is strongly opinionated when it comes to working with objects and doing simple CRUD actions only.

This transaction object is a perfect example of that. Abstracting it a bit further, a Money object would be useful in ForEx, a Person object for User Management / Account users, or even a Vendor object for tracking particular vendors.

Extending those core classes, you could have different types of transactions for Cash, Credit, Checks… or for a business type accounting application, you could have Invoices, Estimates, and Bills.

Good luck!

1 Like