Question

Consider these two use cases.

Say a store gives out store credit for customers. Store credit come from refunds, discounts, overpaying amounts etc…

1. The customer decides how and when to
   use this credit. E.g. Say customer A
   have $50 dollars in store credit and
   he decides to use $25 for invoice A
   and $25 for invoice B… or decides
   to have the store credit sitting
   there against his account for future
   purchases.

2. The customer and store must also
   have a way to look up the total of
   store credit.

What is the easiest and most straight forward way to cater for this in table structure?

I currently have tables:

• Transaction (For journal and reporting purpose)
• Customer
• Credit
• Used Credit

Invoice table will have other associations like invoice lines, receipt, receipt lines etc…

Is this the best way to do this? My concern is primarily regarding ease of reporting and transaction mechanics.

Alternatively I’m considering just saving all credit entry and used credit inside the transaction table.

Updated diagram for clarification and from inputs

Answer 1

Correct me if I’m wrong, but I believe you want something like this.

A Customer has CreditEntrys, and CreditEntrys have UsedCredites. There are also Transactions which include links to corresponding Invoice. And finally, a Transaction has links to many UsedCreditwhich were used during this transaction. If all CreditEntry was used at a time, then there will be one UsedCredit used with this Transaction, and this UsedCredit will correspond to the entire CreditEntry

The database schema would be quite straightforward here – relations through foreign keys. You would probably want to create an additional unique constraint to reflect ONE-TO-ONE relation between Transaction and Invoice

Oh, by the way, that service that you used for diagram creation is cool.