Would anyone know if Excel can be used to track inventory? For example, part
number, description, qty on hand, usage/demand, and to forecast based on
demand when and how much I should order?

Excel is certainly up to the task. However, you're unlikely to
get any specific answers to setting up an inventory system, as
the question is far too broad for a newsgroup post. Start small,
expanding your workbook's functionality piece by piece, and feel
free to ask specific questions here.


--
Cordially,
Chip Pearson
Microsoft MVP - Excel
Pearson Software Consulting, LLC
www.cpearson.com


"mauisun" wrote in message
...
Would anyone know if Excel can be used to track inventory? For
example, part
number, description, qty on hand, usage/demand, and to forecast
based on
demand when and how much I should order?

"mauisun" wrote in message
...
Would anyone know if Excel can be used to track inventory? For example,
part
number, description, qty on hand, usage/demand, and to forecast based on
demand when and how much I should order?

As Chip said, Excel can do this (and almost anything else). But, designing
this type of thing for any purpose will be quite a project. There's a
tendency for inertia to develop once a company has put lots of time into
custom software. So, when you find out you should've used a different kind
of software, you probably will say "Well....this thing's done already - we
don't have time to do it over again, even though we just discovered that our
idea wasn't such a good one".

That was a hint. Before designing anything, you need to think carefully
about how large your data is likely to become. And, what "objects" will you
be tracking? Will you want to expand this to include other "objects"? By
"objects", I mean the products themselves, but later, the word could refer
to the locations in which they're stored, the vendors they come from, spare
parts, customers, invoices, return authorization numbers, etc. Even if you
can't imagine needing to track these other things now, the way you design
the early version can make it a breeze to add things later. Or, you can make
it a living hell. Finally, how the data is organized has a major effect on
what kinds of questions you can ask of the software later. Nothing's more
annoying to have a hard disk full of data, but no information you can query
to help you make business decisions.

These objects exist in relationships to one another. Storing them
incorrectly (in a computer) than result in disaster later, which is why, 40
years ago, two very smart guys invented the relational database, a concept
which can be (pretty much) implemented using Microsoft Access instead of
Excel.

Here's an example of a bad way to store data. My company used to use an
invoicing program made by Nebs, the business form supplier. For every item
bought by a customer one one invoice, it would store this info in one file:

Invoice Number, Date, etc...
Cust Name
Cust Address
Cust City
Cust State
Cust Zip
Cust Phone
(Repeat all the above for their shipping address)
Item UPC
Item Quant
Item Description
Unit Price
Line Total

Besides occupying more disk space than necessary, this had a number of other
problems that would horrify a database designer (or you, if you think about
it). What if there was a problem with an invoice, perhaps an old one, but
the customer had moved since the invoice was sent? The user would look at
the invoice and see the old address & phone number and have to switch to
viewing a separate customer info file, thereby removing the invoice from the
screen. Back & forth....very annoying. This is an oversimplification, but
still accurate.

Belive it or not, you actually CAN do a project like this yourself, or if
the budget allows, with some help from a programmer. If I were you, I'd post
your question in one of the MS Access groups, and get into some discussions
about how to think about and organize your data objects. And, hit the
library, looking for books like this one:

http://search.barnesandnoble.com/boo...01752840&itm=1