Adding a LocationName to FacilityLocation

[Bob Morley]

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.

[David E. Jones-2]

This does sound like something that different facilities would handle  
better than facility locations.

A couple of thoughts:

1. usually you don't have a facility or a location for outgoing dock  
and incoming dock as facilities and locations are tracked only after  
receiving inventory and up to the packing point where inventory is  
issued to a shipment

2. one factor that may help decide between using separate facilities  
versus locations in a facility for storefront and backroom is the  
availability for sale in a certain product store; for example the  
storefront may be the facility for an "immediately fulfilled" store  
but not available online, and the backroom may be available online

In general the concept behind a facility is that it is a building, a  
room within a building, a campus of buildings, etc and locations are  
just for tracking within a specific facility... usually within a large  
room in a warehouse. If you're trying to make this as generic and  
flexible as possible, I'd go with the separate facilities.

-David


On Jun 26, 2009, at 9:44 AM, Bob Morley wrote:

>
> 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.
> --
> View this message in context: http://www.nabble.com/Adding-a-LocationName-to-FacilityLocation-tp24222576p24222576.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Jacopo Cappellato-4]

I like the idea of adding a name field to the FacilityLocation.
As regards the best way to model this, I totally agree with what David  
wrote in another message: it mostly depends on the degree of  
flexibility and separation between different areas you want to achieve.

Jacopo

On Jun 26, 2009, at 9:44 AM, Bob Morley wrote:

>
> 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.
> --
> View this message in context: http://www.nabble.com/Adding-a-LocationName-to-FacilityLocation-tp24222576p24222576.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Jacopo Cappellato-4]

On Jun 26, 2009, at 10:02 AM, David E Jones wrote:

>
> 1. usually you don't have a facility or a location for outgoing dock  
> and incoming dock as facilities and locations are tracked only after  
> receiving inventory and up to the packing point where inventory is  
> issued to a shipment

This is a good point; however sometimes there is the need for a  
"staging/incoming" location/facility where items are actually  
received, they are inspected (for quality control) and this could be  
done even a few days after they were received, and then moved to the  
final locations.
Sooner or later it would be nice to implement something like this, and  
a combination of facility/locations/inventory statuses OR facilities/
transfers could be used to model this.

Jacopo

[Bob Morley]

Basically what Jacopo has indicated here is exactly what our requirements were.  When products come in they may have had a "basic receive" completed; but they have not been moved to a salable location.  Moreover, we actually had two stores in place for a PO -- all purchases are funneled through a single store and then inventory transferred to the final destination store.  On the outgoing side, we wanted the ability for staff to "gather up" items into a common "outgoing" location that again was not a primary/pick or bulk location.

Perhaps this can be modeled as multiple facilities, but what we wanted to make sure is that we could leverage the automatic stock move capabilities available through the ProductFacilityLocation entity.  Our line of thinking was that surpassing ProductFacility thresholds would create a requirement that would typically be handled through a PO where surpassing PFL thresholds would automatically recommend stock moves (typically from backroom location to storefront location, but perhaps around different areas of the storefront).

If I am missing something or have made a bad assumption can you let me know?

Jacopo Cappellato-4 wrote

On Jun 26, 2009, at 10:02 AM, David E Jones wrote:

>
> 1. usually you don't have a facility or a location for outgoing dock  
> and incoming dock as facilities and locations are tracked only after  
> receiving inventory and up to the packing point where inventory is  
> issued to a shipment

This is a good point; however sometimes there is the need for a  
"staging/incoming" location/facility where items are actually  
received, they are inspected (for quality control) and this could be  
done even a few days after they were received, and then moved to the  
final locations.
Sooner or later it would be nice to implement something like this, and  
a combination of facility/locations/inventory statuses OR facilities/
transfers could be used to model this.

Jacopo

[David E. Jones-2]

On Jun 26, 2009, at 4:43 PM, Bob Morley wrote:

>
> Basically what Jacopo has indicated here is exactly what our  
> requirements
> were.  When products come in they may have had a "basic receive"  
> completed;
> but they have not been moved to a salable location.  Moreover, we  
> actually
> had two stores in place for a PO -- all purchases are funneled  
> through a
> single store and then inventory transferred to the final destination  
> store.
> On the outgoing side, we wanted the ability for staff to "gather up"  
> items
> into a common "outgoing" location that again was not a primary/pick  
> or bulk
> location.

It does sound like receiving into a temporary/staging facility would  
be the best, and then transferring to a store facility when it is  
ready to sell.

> Perhaps this can be modeled as multiple facilities, but what we  
> wanted to
> make sure is that we could leverage the automatic stock move  
> capabilities
> available through the ProductFacilityLocation entity.  Our line of  
> thinking
> was that surpassing ProductFacility thresholds would create a  
> requirement
> that would typically be handled through a PO where surpassing PFL  
> thresholds
> would automatically recommend stock moves (typically from backroom  
> location
> to storefront location, but perhaps around different areas of the
> storefront).

There is nothing special about the stock move capabilities for the  
facility locations, or nothing special about locations that make them  
especially suited to stock moves. All that is special there is that an  
implementation has been done to handle the specific case of moving  
stock from a bulk location to a pick/primary location. That code may  
or may not be helpful for the inventory movement/transfer that you  
want to do. In fact, if the UI or process are different in any way,  
then the level of effort may be about the same for doing this based on  
facilities versus on locations.

That said, choosing how to model things based on a guess about level  
of effort for implementation is a bad idea. My impression (without  
looking at the desired process and UI in detail) about this situation  
is that what you want is different than the stock move situation and  
so that functionality may not be helpful.

Whatever the case, the key is to define the business process and  
system interactions (based on the business process) that you want for  
this, and then do a gap analysis and build (if needed) to that.

-David

> If I am missing something or have made a bad assumption can you let  
> me know?
>
>
> Jacopo Cappellato-4 wrote:
>>
>>
>> On Jun 26, 2009, at 10:02 AM, David E Jones wrote:
>>
>>>
>>> 1. usually you don't have a facility or a location for outgoing dock
>>> and incoming dock as facilities and locations are tracked only after
>>> receiving inventory and up to the packing point where inventory is
>>> issued to a shipment
>>
>> This is a good point; however sometimes there is the need for a
>> "staging/incoming" location/facility where items are actually
>> received, they are inspected (for quality control) and this could be
>> done even a few days after they were received, and then moved to the
>> final locations.
>> Sooner or later it would be nice to implement something like this,  
>> and
>> a combination of facility/locations/inventory statuses OR facilities/
>> transfers could be used to model this.
>>
>> Jacopo
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Adding-a-LocationName-to-FacilityLocation-tp24222576p24228307.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>