Inventory reservation/fulfillment and the notion of a salable location

[Bob Morley]

Right now we primarily use Ofbiz to model a b&m store.  Part of doing this means POS driven interaction with the customer and immediate fulfillment as part of order entry.  What this means for us is that the act of choosing particular inventory items and having them selected form the proper facility/location is very important.

In a number of business processes we have the notion of inventory items not being "salable".  This is often based on the physical location of the inventory item (or perhaps even at the facility level).  Here are some examples:

a) Inventory is purchased and has been initially "received" but is not necessarily available to sell at this particular facility.  We model the notion of a "primary store" that does ordering and when a shipment comes in they will group up and inventory transfer to a destination store.  During this business process inventory should be in a location in that facility, but should not be pickable during inventory reservation, etc.

b) Inventory is marked as damaged and needs to have work done on it.  These items often will be fixed on premises but again should not be sold.  You also have the reverse situation where the items are going to be shipped offsite, but right now remain in your facility waiting for shipment.

c) The first party of inventory reconcilation is "inventory counting"; individual locations are counted and variance in items result in those items being moved to a "lost and found" location.  When other locations are done these variances may be resolved form the "lost and found" but ultimately a true reconciliation is performed on the "lost & found".  Naturally "l&f" inventory items can not be sold.

So the million dollar question -- what is the best way to model this.  One approach would be to model these other locations as difference facilities in that product store.  Since we (currently) use a single inventory facility they would not be salable.  While that is an approach my gut tells me it is not necessarily the best approach.

What I was planning on doing is expanding the notion of facilityLocation to have the idea of being "salable" or not.  If memory serves, the current inventory reservation services will go through all "PICKLOC" and "BULK" types when doing reservation.  Initially I had added new types that would not be salable; but I am thinking it might be better to actually have an attribute on the facilityLocation that indicates if you can sell from that location or not.  I guess I could also go with a "NOPICKLOC" or something similar for these other locations ...

Or would it be more correct to use the inventory status and be sure to set this when inventory enters one of these "unsalable" locations?

Am I modeling this completely incorrectly, is there something I missing, does anyone have any advice?

[Jacopo Cappellato-4]

Hi Bob,

another thing you could consider to use (or expand) is the statusId in  
the InventoryItem: there should be already code in place that ignore  
(for reservations etc...) items based on their status.
Then you could implement some user friendly screens (or even business  
processes) to manage the status of the inventory items in a given  
location (or a defaultStatusId for all the items in the location);  
during stock moves you could change status of items to make them ready  
for sales.

Regards,

Jacopo

On Aug 8, 2009, at 8:16 PM, Bob Morley wrote:

>
> Right now we primarily use Ofbiz to model a b&m store.  Part of  
> doing this
> means POS driven interaction with the customer and immediate  
> fulfillment as
> part of order entry.  What this means for us is that the act of  
> choosing
> particular inventory items and having them selected form the proper
> facility/location is very important.
>
> In a number of business processes we have the notion of inventory  
> items not
> being "salable".  This is often based on the physical location of the
> inventory item (or perhaps even at the facility level).  Here are some
> examples:
>
> a) Inventory is purchased and has been initially "received" but is not
> necessarily available to sell at this particular facility.  We model  
> the
> notion of a "primary store" that does ordering and when a shipment  
> comes in
> they will group up and inventory transfer to a destination store.  
> During
> this business process inventory should be in a location in that  
> facility,
> but should not be pickable during inventory reservation, etc.
>
> b) Inventory is marked as damaged and needs to have work done on  
> it.  These
> items often will be fixed on premises but again should not be sold.  
> You
> also have the reverse situation where the items are going to be  
> shipped
> offsite, but right now remain in your facility waiting for shipment.
>
> c) The first party of inventory reconcilation is "inventory counting";
> individual locations are counted and variance in items result in  
> those items
> being moved to a "lost and found" location.  When other locations  
> are done
> these variances may be resolved form the "lost and found" but  
> ultimately a
> true reconciliation is performed on the "lost & found".  Naturally  
> "l&f"
> inventory items can not be sold.
>
> So the million dollar question -- what is the best way to model  
> this.  One
> approach would be to model these other locations as difference  
> facilities in
> that product store.  Since we (currently) use a single inventory  
> facility
> they would not be salable.  While that is an approach my gut tells  
> me it is
> not necessarily the best approach.
>
> What I was planning on doing is expanding the notion of  
> facilityLocation to
> have the idea of being "salable" or not.  If memory serves, the  
> current
> inventory reservation services will go through all "PICKLOC" and  
> "BULK"
> types when doing reservation.  Initially I had added new types that  
> would
> not be salable; but I am thinking it might be better to actually  
> have an
> attribute on the facilityLocation that indicates if you can sell  
> from that
> location or not.  I guess I could also go with a "NOPICKLOC" or  
> something
> similar for these other locations ...
>
> Am I modeling this completely incorrectly, is there something I  
> missing,
> does anyone have any advice?
> --
> View this message in context: http://www.nabble.com/Inventory-reservation-fulfillment-and-the-notion-of-a-salable-location-tp24878041p24878041.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>

[Bob Morley]

Yes I think I posed that original one in haste.  When I started doing the work yesterday for it I quickly realized that it would make much more sense to leverage the statusId on an inventory item.  So what I ended up doing was extending the facility entity to have a defaultLocationSeqId.

This change I did in our own hot-deploy because I was unsure if it is something that has community appeal.  From memory I believe most of the Ofbiz screens would ask for a location using a lookup field (and would accept blank).  In our UI we are more apt to use a dropdown for locations with-in a facility so the default lends itself nicely to pre-populating the dropdown (blank is allowed).

Do you think it makes sense to extend Facility in this way?  If so I can replace my entity-extend with a modification to Facility and make the minor change to the add/edit form and provide the patch.  Naturally, its value would not be used anywhere initially ... Do you think there is value in doing this?

Jacopo Cappellato-4 wrote

Hi Bob,

another thing you could consider to use (or expand) is the statusId in  
the InventoryItem: there should be already code in place that ignore  
(for reservations etc...) items based on their status.
Then you could implement some user friendly screens (or even business  
processes) to manage the status of the inventory items in a given  
location (or a defaultStatusId for all the items in the location);  
during stock moves you could change status of items to make them ready  
for sales.

Regards,

Jacopo

[David E. Jones-2]

If I understand right we are talking about an inventory item that is  
split into multiple locations. For that it sounds like we need more  
than one inventory item, perhaps one normal item and one with a new  
inventory item type that would be a sub-item to the main one (which  
could point to a BoM type sub-product, or just have a description of  
the part that is in there).

-David


On Aug 9, 2009, at 9:18 PM, Bob Morley wrote:

>
> Yes I think I posed that original one in haste.  When I started  
> doing the
> work yesterday for it I quickly realized that it would make much  
> more sense
> to leverage the statusId on an inventory item.  So what I ended up  
> doing was
> extending the facility entity to have a defaultLocationSeqId.
>
> This change I did in our own hot-deploy because I was unsure if it is
> something that has community appeal.  From memory I believe most of  
> the
> Ofbiz screens would ask for a location using a lookup field (and would
> accept blank).  In our UI we are more apt to use a dropdown for  
> locations
> with-in a facility so the default lends itself nicely to pre-
> populating the
> dropdown (blank is allowed).
>
> Do you think it makes sense to extend Facility in this way?  If so I  
> can
> replace my entity-extend with a modification to Facility and make  
> the minor
> change to the add/edit form and provide the patch.  Naturally, its  
> value
> would not be used anywhere initially ... Do you think there is value  
> in
> doing this?
>
>
> Jacopo Cappellato-4 wrote:
>>
>> Hi Bob,
>>
>> another thing you could consider to use (or expand) is the statusId  
>> in
>> the InventoryItem: there should be already code in place that ignore
>> (for reservations etc...) items based on their status.
>> Then you could implement some user friendly screens (or even business
>> processes) to manage the status of the inventory items in a given
>> location (or a defaultStatusId for all the items in the location);
>> during stock moves you could change status of items to make them  
>> ready
>> for sales.
>>
>> Regards,
>>
>> Jacopo
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Inventory-reservation-fulfillment-and-the-notion-of-a-salable-location-tp24878041p24893785.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>