How should I model these simple financial transactions?

Question

I feel like I hit a wall trying to structure what I thought would be a simple database schema for modeling basic financial transactions. I'm hoping some of you with more experience can weigh in and point me in the right direction.

My application has four distinctly different types of leases that customers can purchase. As such, each type of lease has it's own table, and in order to keep referential integrity, each lease table has it's own transactions table.

My original sketch looked like this:

First off, I used a FK reference to Function Types to avoid using signed integers. It makes no sense to have a negative payment, so I figured it would work well for each transaction to have either a debit or credit reference. Does this make sense?

Another thing that was bothering me is that all transactions don't appear to be equal. That is, I feel like the transctions for this application should possibly be grouped into separate tables.

Should transactions such as flat rate fees, variable rate fees, payments, interest and voids all be stuffed into the same table? It seems messy to me, but I'm already stuck with a transactions table for each lease type so splitting those tables up even more is not very appealing.

Just about every transaction type other than payments will be built programmatically, so I can have references in the "Notes" field that specifies which payment a bounced check or void transaction is referencing. Is this good enough or am I thinking about this all wrong?

Thanks!

Answer 1

What's wrong with negative amounts?

It's fine to have a record of transaction types, but if you insist on all amounts being positive, you're up for a world of pain when trying to calculate totals. Simply store payments and other money-coming-in transaction types as positive amounts, and refunds, etc. as negative amounts. This also lets you do things like record a charge-back due to a mistake (e.g., charging the wrong account on the customer's card) as a negative payment, which is different to a refund.

Answer 2

Do different types of leases have different features? If not, then separating them out into separate tables accomplishes nothing, and adds to the complexity of both the database and the programmed application.

Having a single transaction table for all types of leases is almost certainly going to save you trouble later on.

I suggest you take a look at some of the solutions presented in Database Answers. There are lots of financial databases there. You might get a few hints.