Michael, I'm using a transaction table and a cash receipts table.
That allows me to create a "history" of payments as we often receive more than one payment on each transaction. One thing I am missing is the ability to programmatically handle "overpayments" and "credit balances". We just don't get many and it has not been an issue, although if I were starting from scratch I'd probably build it into the system. James E. Harvey Corresponding Officer/M.I.S. Hanover Shoe Farms, Inc. www.hanoverpa.com [EMAIL PROTECTED] 717-637-8931 fax: 717-637-6766 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MB Software Solutions Sent: Monday, October 30, 2006 8:53 AM To: Profox Subject: Debits/credits database design I've got a couple small projects to do (hopefully) soon and they deal with customers invoices, payments, and adjustments. Asking those of you who've designed systems with these kinds of needs: do you make a table called "transactions" and just keep all of the data there, having a record identifier to show if it's a payment/debit/adjustment? If not, how have you designed tables to handle this data in the past? Apologies if not enough information there....it's a Monday! ;-) It's just discussion at this point, and nothing concrete. Consider this a "theoretical discussion" on design. tia! --Michael -- Michael J. Babcock, MCP MB Software Solutions, LLC http://mbsoftwaresolutions.com http://fabmate.com "Work smarter, not harder, with MBSS custom software solutions!" [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
