DB that control order receipt, inventory, shipping info and invoices

[Frederic via AccessMonster.com]

Hello,

I have to create an access database that will be share with 3 departments.
The database need to control the Shoes, handbags and accessories
International orders, it's inventory, shipping info and invoices. Here is
some information that need to be in the database. Your assistance will be
much appreciated.

Phantom Order number
Order number
Order received date
Style Name
Color name
Total quantity received
Quantity by size
Skid number
Units shipped
Units on hand
Container number
Trailer number
Ship to Franchisse name
Ship to address, city, province, state, zip code.
Ship date
Invoice
Invoice date

 

[Duane Hookom]

Quickbooks or Peachtree or other accounting software ...

 

[John W. Vinson]

Hello,

I have to create an access database that will be share with 3 departments.
The database need to control the Shoes, handbags and accessories
International orders, it's inventory, shipping info and invoices. Here is
some information that need to be in the database. Your assistance will be
much appreciated.

Ummmm....

What are you asking from us? A completely worked-out database? Detailed
instructions for constructing one?

We're all unpaid volunteers here, and that goes a long way past what's normal.
If you are having a specific problem designing or normalizing your tables,
please ask a specific question and we'll try to help.

You might want to look at some of the resources and tutorials available:

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

 

[Frederic via AccessMonster.com]

Hello John,

Actually, I want to know how should I set my tables and which are the tables
I should link together?

Thank you for your help!

Hello,

[quoted text clipped - 3 lines]

some information that need to be in the database. Your assistance will be
much appreciated.

Ummmm....

What are you asking from us? A completely worked-out database? Detailed
instructions for constructing one?

We're all unpaid volunteers here, and that goes a long way past what's normal.
If you are having a specific problem designing or normalizing your tables,
please ask a specific question and we'll try to help.

You might want to look at some of the resources and tutorials available:

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

A free tutorial written by Crystal (MS Access MVP):
http://allenbrowne.com/casu-22.html

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials

 

[Fred]

Your item list implies a large amount of additional quesitons and then a
large amount of work.

Everything the other guys said is still applicable. One additional thought:


You might start with the Northwind example that comes in Access and then
customize it to your specifica. Assuming that you aren't trying to have
transactions automatically modify inventory, it's overall structure is along
the lines of what I'm guessing you're looking for.

 

[John W. Vinson]

Hello John,

Actually, I want to know how should I set my tables and which are the tables
I should link together?

Each kind of Entity - real-life person, thing, or event - should have its own
Table. The Tables should be linked logically, as those entities are linked in
the real world. For example, an Item (or Product) is a kind of entity, with
attributes such as Size, Color, Price, etc. A Customer is a different kind of
entity, with attributes like LastName, FirstName, etc; an Address is yet
another kind of entity. One Customer may have one or more Addresses, but (in
this case, I'm guessing) each Address applies to only one Customer.

The design of tables is what normalization is all about, and it depends both
on a good working knowledge of the business model, and of the principles of
relational design. I've posted links to tutorials for the latter, and there
are some good books available - but actually laying out all your tables and
fields for you is more than I'm up for this afternoon!