Re: Adding a LocationName to FacilityLocation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Adding a LocationName to FacilityLocation

BJ Freeman
Just as side note:
the facility ID is text and can be name as long as it does not exceed 30
characters.
you your Facility ID can be
PhysicalStore
incomingdock
outgoingdock
backroom
the same with the entiy ID for location.
other than that and reading the DataModel books
your Ideas seems feasible.



Bob Morley sent the following on 6/26/2009 8:44 AM:

> I am hoping for some modeling advice -- in our system we have a number of
> predefined locations with-in a particular facility.  For example, we will
> have a PhysicalStore that will contain locations for the storefront,
> backroom, incoming dock, and outgoing dock.  As products are sold they can
> flow from the backroom to the storefront (with a simple stock move).
>
> The trouble is that we do not not make use of the attributes on the facility
> location as it stands now (aisle, row, whatever else is there) and there is
> not a text description that represents the location (or a name :) ).  What
> we wanted to do is add a location name to this entity and then our customers
> could name their locations with-in the facility which helps facilitate stock
> moves, inventory transfers, etc.
>
> The questions:
>
> 1) Is this correctly modeled or should we be using the facility hierarchy?
> 2) If ^Y^ is adding a location name reasonable?
>
> We are doing this as an extension in our hot-deploy for now; but we would
> like to patch it up and ship it back if there is value.

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.

Reply | Threaded
Open this post in threaded view
|

Re: Adding a LocationName to FacilityLocation

Bob Morley
Yep that is a great point wrt to the ID, but what we have been trying to do (as a practice) is never expose the ID in our application and always use a "nice" display name.  The trouble we would run into with the suggestion below is that we have a Company that has five stores and hence (at a minimum) five facilities.  It is very likely (and in fact we would seed it as such) that each facility would get a an incoming, outgoing, backroom, and storefront.

By using the ID for this purpose I force my user to use a unique ID for (very similar purposed) locations (or facilities for that matter).

An interesting point along these lines is that it appears that the IDs for seeded product facilities were done by convention (concatenation of the two character codes for area, aisle, section, level, etc).  You would see where this practice would be potentially fragile, but would also breakdown for a customer that has a number of "cookie cutter" physical stores that have similar area, aisle, etc naming conventions.

BJ Freeman wrote
Just as side note:
the facility ID is text and can be name as long as it does not exceed 30
characters.
you your Facility ID can be
PhysicalStore
incomingdock
outgoingdock
backroom
the same with the entiy ID for location.
other than that and reading the DataModel books
your Ideas seems feasible.



Bob Morley sent the following on 6/26/2009 8:44 AM:
> I am hoping for some modeling advice -- in our system we have a number of
> predefined locations with-in a particular facility.  For example, we will
> have a PhysicalStore that will contain locations for the storefront,
> backroom, incoming dock, and outgoing dock.  As products are sold they can
> flow from the backroom to the storefront (with a simple stock move).
>
> The trouble is that we do not not make use of the attributes on the facility
> location as it stands now (aisle, row, whatever else is there) and there is
> not a text description that represents the location (or a name :) ).  What
> we wanted to do is add a location name to this entity and then our customers
> could name their locations with-in the facility which helps facilitate stock
> moves, inventory transfers, etc.
>
> The questions:
>
> 1) Is this correctly modeled or should we be using the facility hierarchy?
> 2) If ^Y^ is adding a location name reasonable?
>
> We are doing this as an extension in our hot-deploy for now; but we would
> like to patch it up and ship it back if there is value.

--
BJ Freeman
http://www.businessesnetwork.com/automation
http://bjfreeman.elance.com
http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro
Systems Integrator.