Stephen Russell wrote:
Why combine Items with consumption of them?
What I plan to do is simply add a field with a foreign key linking the
inventory item to the sale details (name, date, etc.) I've already been
doing this with a key linking the inventory item to the purchase order,
and the purchase invoice. What makes this easier is that each row in my
inventory table represents a single item.
Inventory: defines the item, has a key to reference said item
OrderLinenItems : defines consumption of all items, and references
InventoryID to get description of item.
PurchaseItems: Defines restocking of items using same InventoryID to get
description of item.
Correct on all points.
Should you place the quantity Onhand in the inventory table or do you just
show the difference between all purchased - all sold?
To obtain Q's, I found it always works best to calculate. My clients
have always had an uncanny way of aborting processes mid-stream, which
mucked up the Inventory Q's! I actually began admiring their
(destructive) work...
I know it gets fun when an order has been placed but not shipped. Isn't
that why we make the mediocre money?
Inventory allocation has never been easy. True that. I just tell people
"when it's gone it's really gone. until then, it's only a plan."
Thanks for the insights!
Mike
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
