Use a field or a whole new table? - database

Question

I could really use some insights on choosing between the following two database layouts.
Layout #1 | Layout #2
|
CUSTOMERS | CUSTOMERS
id int pk | id int pk
info char | info char
|
ORDERS | ORDERS
id int pk | id int pk
customerid int fk | customerid int fk
date timedate | date timedate
|
DETAILS | INVOICES
id int pk | id int pk
orderid int fk | orderid int fk
date timedate | date timedate
description char |
amount real | DETAILS
period int | id int pk
| invoiceid int fk
| date timedate
| description char
| amount real
This is a billing application for a small business, a sole proprietor. The first layout has no separate table for invoices, relying instead on the field 'period' in DETAILS for the billing cycle number. The second layout introduces a table specifically for invoices.
Specifically in this application, at what point do you see Layout #1 breaking, or what kind of things will get harder and harder as the amount of data increases? In the case of Layout #2, what does the added flexibility/complexity mean in practical terms? What are the implications for 30-60-90 aging? I'm sure that will be necessary at some point.
More generally, this seems to be a general case of whether you track/control something through a field in a table or a whole new table, yet it's not really a normalization issue, is it? How do you generally make the choice?

Answer 1

Given the previous comments, this is how I would approach it:
CUSTOMERS
id int pk
info char
CASES
id int pk
customerid int fk
dateOpened datetime
dateClosed datetime
status int <- open, closed, final billed, etc.
BillPeriod int <- here is where you determine how often to bill the client.
BillStartDate datetime <- date that billings should start on.
BILLING
billingid int pk
caseid int fk
userid int fk <- id of person who is charging to this case. i.e. the lawyer.
invoicedetailid fk <- nullable, this will make it easier to determine if this particular item has been invoiced or not.
amount money
billdate datetime
billingcode int fk <- associate with some type of billing code table so you know what this is: time, materials, etc.
description char
INVOICES
invoiceid int pk
customerid int FK
invoicedate datetime
amount money <- sum of all invoice details
status int <- paid, unpaid, collection, etc..
discount money <- sum of all invoice details discounts
invoicetotal <- usually amount - discount.
INVOICEDETAILS
invoicedetailid int PK
invoiceid int FK
billingid int FK
discount money <- amount of a discount, if any
===========
In the above you open a "case" and associate it with a customer. On an ongoing basis one or more people apply Billings to the case.
Once the combination of the bill start date and period have elapsed, then the system will create a new Invoice with Details copied from the Billing table. It should do this based on those details that have not already been billed. You should lock the billing record from future changes once it has been invoiced.
You might have to change "BillPeriod" to some other type of field if you need different triggers. For example, period is just one "trigger" to create an invoice.
One might include sending an invoice when you hit a certain dollar amount. This could be configured at the customer or case level. Another option is capping expenditures. For example putting a cap value at the case level which would prevent billings from going over the cap; or at the very least causing an alert to be sent to the relevant parties.

Answer 2

I'm not entirely sure why "period" is attached to the item instead of the order itself. Layout #1 seems to imply that you can have an open "order" that is made up of "details" which might be added and paid for over a period of years. This seems very wrong and should make accounting a nightmare. Layout #2 really isn't much better.
Generally speaking an Order is comprised of a single transaction with a purchase or contract date. That transaction might encompass multiple detail items, but it's still one transaction. It represents a single agreement made at a certain point in time between the buyer and seller. If new items are purchased, a new order is created... With this in mind, neither table structure works.
Regarding Invoices. An order might have one or more invoices attached to it. The goal of invoices is to have payments applied against them. For small transactions there is a one-to-one relationship between invoices and orders.
In larger transactions, you might have multiple invoices that get applied to a single order. For example if you have contracted to make "3 easy payments of $199.99 ..." . In this case you would have 3 invoices for $199.99 each applied to a single order whose total was $599.97; and each due at different time periods.
An Invoice table should then have at minimum the Order Id, Invoice Number, Invoice Date, Invoiced Amount, Date Due, Transaction Id (for credit card), Check Number (obvious), Amount Received and Date Received fields.
If you want to get fancy and support more of the real world, then you would additionally have a Payments table which stored the Invoice Number, Amount Received (or refunded), Date Received, Transaction ID, and Check Number. If you go this route, remove those fields from the Invoice table.
Now, if you need to support recurring charges (for example, internet hosting), then you would have a different table called "Contracts" and "ContractDetails" or something similar. These tables would store the contract details (similar to orders and order details, but includes date start, date end, and recurring period). When the next billing period is hit, then the details would be used to create an order and the appropriate invoices generated..

Answer 3

Since you're doing legal billing, I'd suggest you spend some time looking at the features of Sage Timeslips. Lawyers don't behave like other people; accounting software for lawywers doesn't behave like other accounting software. It's the nature of the business.
They have a 30-day free trial, and you can probably learn a lot from the help files and documentation.
Besides, reverse-engineering database design from the user interface is good practice.