Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Procurement database

Featured Replies

  • Newbies

Hi,

Complete beginner here, I'm afraid. What I'm trying to do is establish a simple (at least, I think it's pretty simple) procurement database. What I want to do is to be able to 'check in' equipment from the database into a series of discrete locations. In terms of reporting, I'd like the database to be able to give me a breakdown of equipment in each location, a total kit list, and a breakdown by supplier. This way I can make changes to price, location and specification, and it'll be instantly reflected in the PO I give to the supplier. I've been through this process before, using Excel, and it wasn't much fun.

So far I've got several tables. The main one is the equipment table which comprises the bulk of the database. This contains information about the equipment itself, the supplier, the unit cost, etc. After that, each location has its own table, and this contains quantity information and simple calculations to work out the value of the equipment in each location. Further tables create summaries of this information.

What I'm struggling with is adding the equipment into the location tables using relationships. I can make the location tables modify the equipment table, but not vice-versa.

Any ideas gratefully received. I suspect the main concept is flawed, and I'd appreciate any guidance.

Thanks in advance,

Tom

As is usual when there are problems like this, it is likely because you are missing a dedicated table for the "transactions," a table with the EquipmentID and the LocationID, each as foreign keys, a date when the transaction occurred, a price for the transaction,* and any other data specific to this particular transaction (notes, etc.).

Oh, by the way, a separate "table" for each location, if that's what you're doing, is just plain bad relational design. All locations are in a Locations "reference" table.

*Actually there may need to be another table, for Equipment|Location. It sounds like you're saying that each unique Equipment-and-Location combo may have its own price, which could be entered here, then looked up; that could be a lot of records. If any give piece of equipment had one price, then it would just be in Equipment, and you wouldn't need this other "reference" table. We don't really know where the price is supposed to come from, so can't really tell you how to get it.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.