Accounts Payable Database - Help needed building from new.

[Vassago]

Guys, not everyone is going to agree on how to work with something. It becomes increasingly frustrating for the user asking for help when two senior members argue about it in the middle of the post because chances are they have NO idea what you guys are arguing about or the points you're trying to make because they don't fully understand it yet.

Another strategy to post a reply that you think is better is to just say, "Here's another way to do it that I came up with." This doesn't degrade the help the other provided nor does it say your solution is better. It gives the original poster the chance to choose which way works best for their solution.

We all know there are tons of ways of doing everything and not everything will work for every project. By telling other senior members they are wrong, it's not going to serve anyone.

As for your response, rm.harper. I believe we've been down this path before. As I said before, you are not doing yourself any favors by insulting the very people taking time out of their day to assist you. You are alienating some of the brightest minds this forums has to offer by doing this. You may not see responses to future questions with an attitude like yours. Have a little respect for them. They aren't paid help.

Need I mention that the same members that help here help on most other Access forums?

Good luck!

 

[JLCantara]

Monseigneur Harper should admit that I submit a schema which was quite related to the basic issue. The polemic about composite keys was, I admit, very technical but necessary and DIRECTLY related to your issue. The treatment of payments was also DIRECTLY related to your issue.

I may be a sadbag but I am too polite to tell you what I thing about your post!!!

 

[gemma-the-husky]

I appreciate this is a late response.

from scratch, I would have these tables

suppliers
invoices (include credits within this table)
payments
invoice_payment_allocation. (to match payments against invoices)

invoices and payments have a many to many relationship, so the last table allows a payment to be matched to multiple transactions, and a transaction to be settled using multiple payments.

keys/indexes are a different matter. clearly two suppliers may issue the same invoice number, so a unique key needs to consist of both supplier and transaction ref. maybe even a composite of supplier, transaction date and transaction ref.