Hi Andy,
I think that introducing the Sites is a
logical next step, but you should now
change your table structures.
I've lost a little bit of familiarity with
this, but here's my take on it. We started
with a specific coding problem, more code
is being introduced now, because of the
limitations of the table definitions.
I see a need to identify the specific
entities in this app. It was OK, going
through the logic of packing the truck.
But now we are wanting to incorporate a
group of sites that will participate in
the process.
To avoid generating a lot of code to make
this happen I suggest we look at the tables
involved. If the data is laid out properly
then the status of a site, truck or product
is easy to ascertain with a single query.
The vehicle loading is unique and I see this
as the only place that there is a lot of
coding logic. The history of shipments,
site and product status can all be done with
various queries. Most of the complex coding
has been done.
You have a finite amount of products and they
all require a certain amount of shipping space.
tblProducts:
ProductID
ProductName
ProductDescription
Product"cubes" - Shipping space required
You have several sites that store the product.
tblSites:
SiteID
SiteName
SiteManager
You will ship from one of those sites.
tblShipping:
ShippingID
SiteID
ShipmentNumber
DateShipped
Each product being shipped is on one or more
trucks. This is where most of our earlier
efforts centered, but it kept no history.
tblShippingDetail:
ShippingDetailID
ShippingID
TruckNumber
ProductID
StartRow
EndRow
QuantityShipped
When you receive the product(s), they go to
a particular site:
tblReceiving:
ReceivingID
ReceivingNumber
SiteID
Source
DateReceived
tblReceivingDetail:
ReceivingID
ProductID
QuantityReceived
With the amount of time we've spent here, it'd
sure be nice to envision this as the complete
authority on your shipping environment.
***********************************
As to the last post:
If you table the data right, then when you
want to calculate the OnHand qty (and thus
where to ship from, you should be able to do
TOP 1 SiteID, (receipts - shipping) for any
product.
In code, the worst it would be is the difference
of a couple of DSum calls.
As it is now, you will need a lot of Case and
If -- ElseIf statements from having too many
columns for sites when they really should be rows.
***********************************
Just some thoughts,
Wayne
I think that introducing the Sites is a
logical next step, but you should now
change your table structures.
I've lost a little bit of familiarity with
this, but here's my take on it. We started
with a specific coding problem, more code
is being introduced now, because of the
limitations of the table definitions.
I see a need to identify the specific
entities in this app. It was OK, going
through the logic of packing the truck.
But now we are wanting to incorporate a
group of sites that will participate in
the process.
To avoid generating a lot of code to make
this happen I suggest we look at the tables
involved. If the data is laid out properly
then the status of a site, truck or product
is easy to ascertain with a single query.
The vehicle loading is unique and I see this
as the only place that there is a lot of
coding logic. The history of shipments,
site and product status can all be done with
various queries. Most of the complex coding
has been done.
You have a finite amount of products and they
all require a certain amount of shipping space.
tblProducts:
ProductID
ProductName
ProductDescription
Product"cubes" - Shipping space required
You have several sites that store the product.
tblSites:
SiteID
SiteName
SiteManager
You will ship from one of those sites.
tblShipping:
ShippingID
SiteID
ShipmentNumber
DateShipped
Each product being shipped is on one or more
trucks. This is where most of our earlier
efforts centered, but it kept no history.
tblShippingDetail:
ShippingDetailID
ShippingID
TruckNumber
ProductID
StartRow
EndRow
QuantityShipped
When you receive the product(s), they go to
a particular site:
tblReceiving:
ReceivingID
ReceivingNumber
SiteID
Source
DateReceived
tblReceivingDetail:
ReceivingID
ProductID
QuantityReceived
With the amount of time we've spent here, it'd
sure be nice to envision this as the complete
authority on your shipping environment.
***********************************
As to the last post:
If you table the data right, then when you
want to calculate the OnHand qty (and thus
where to ship from, you should be able to do
TOP 1 SiteID, (receipts - shipping) for any
product.
In code, the worst it would be is the difference
of a couple of DSum calls.
As it is now, you will need a lot of Case and
If -- ElseIf statements from having too many
columns for sites when they really should be rows.
***********************************
Just some thoughts,
Wayne