DWUTKA at marlow.com
DWUTKA at marlow.com
Mon Mar 15 15:41:03 CST 2004
Hmmmm....I'm getting a little confused at the original 'intent'. Let me see if I am thinking this through correctly. Al needs a dozen widgets. So Al becomes the 'requestor'. Frank is the company's 'purchaser', so Frank is the Buyer. Widgets-R-Us is one of the 'Vendors' that Frank can use, to purchase the widgets that Al wants. Is that close? If that's the case, you need to take a look at the people involved. Requestors and Purchasers (in the example above) are people in the same company, so they should have the same information. So I would put them in tblEmployees. I am kind of roughing this around my companies 'PO' system. Technically all employee's can be Requestors, so any table that would need to know who is requesting something would have RequestorID, but that would be the EmployeeID foriegn key. However, only certain employee's would be Buyers, and each buyer (in my case) actually purchases based on the type of the purchase. So I would then have a PurchaseType table, to list the various 'purchase types', and then have a many to many table to link the buyers/purchasers to the types they handle (assuming there is possible overlap in each direction). Vendors on the other hand, could be put into one table. With a VendorID, Point of contact, etc. etc. I would then make a tblPurchaseOrder. Have the Requestor fill that out (So his/her ID would be recorded in the tblPurchaseOrder Record). Have the Requestor fill out the PO, including the Purchase type. Then, the buyer's would be able to 'view' the Purchase Orders that they are linked too through the Many to Many table. Does this make sense, or am I starting to babble....had a long week (My RAID 5 crashed, spent all last week getting my data off of it!) ARG! Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Hollis,Virginia Sent: Saturday, March 13, 2004 6:59 AM To: 'Access Developers discussion and problem solving' Subject: RE: [AccessD] Vendor Table Would this be correct? tbl_VendorMain VendorID ContactID RequestorID BuyerID TypeID DateRequested tbl_Vendor VendorID Vendor info stuff tbl_Type TypeID Type stuff etc. OR Should tbl_Vendor have CustomerID? -----Original Message----- From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com] Sent: Friday, March 12, 2004 10:17 AM To: accessd at databaseadvisors.com Subject: RE: [AccessD] Vendor Table Sounds like a PO system. The PurchaseOrder table would be the 'tie in'. You would have a PO Number, then a buyerID, VendorID, and your items. Depends on how complex you want to make it, you should probably have a PO Line Items table. Drew -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Hollis,Virginia Sent: Friday, March 12, 2004 9:01 AM To: 'accessd at databaseadvisors.com' Subject: [AccessD] Vendor Table I am starting a new database - that seems fairly standard, but it is my first time with this type.... This database is to track vendor information & requests. I know I need a table with vendor information, one for the buyer, & one for contacts. The problem is I can't think of how to tie them all together, especially the buyer & requestor with the vendor. The buyer completes the form with all the vendor information, regular fields - name, address, terms. I guess my question is what do I put in a Main? table to tie all the information together? It is mostly just a form completed by the buyer and sent to another department for entry into the suppliers database. But the 2nd department wants to track the requests (where I come in). Virginia -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com