Results 1 to 3 of 3
  1. #1
    Join Date
    Oct 2006

    Red face Billing design question

    Hello Everybody!

    I am working on a web-based application, which among other things, deals with monthly billing.

    Every customer will have fixed monthly charges, and also (possible) particular charges for that month.
    Of course, I will also need to keep a balance of what the customer ows at any given time.

    I guess my question is:
    1 - How should I save this information into the database? Should I have a record for every charge/credit? How should I save remaining balances, so it is showed in the next bill?
    2 - Should I keep the balance recorded in a field? or should I calculate it on real-time every time?

    I hope you guys undertood what I am asking.
    I certainly appreciate your time.



  2. #2
    Join Date
    Dec 2004
    Madison, WI
    1. Not sure on this. I might need some more info. If you have a good changelog system (which stores changes in your key fields) and are possibly using SQL Server, your life might be easier. Key thing is that you want to track changes so keep that in mind when thinking about your design. Also, think about some of the other accounting programs and how Quicken/Quickbooks work. You may be able to get some good ideas from how they do it. We could get in-depth on this subject and end up with a lot of posts but that's my best advice on this.

    2. Keep the balance as a field in your database! It will make your life much easier no matter what anyone else might tell you on this board in regards to "never store a calculated value" - that's horseshit when it comes to accounting type programs. Trust me - I've been there and done it many, many times.
    Last edited by pkstormy; 10-27-06 at 17:20.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  3. #3
    Join Date
    Jun 2003
    Yes, balances are an exception to the rule. It is simply too inconvenient and inefficient to recalculate them on the fly for what should be static data.
    If it's not practically useful, then it's practically useless.

    blindman "sqlblindman"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts