Re: Managing the status for non serialized inventory items

Posted by Sumit Pandit-3 on
URL: http://ofbiz.116.s1.nabble.com/Managing-the-status-for-non-serialized-inventory-items-tp193584p193589.html

+1


On Jun 5, 2008, at 12:36 AM, Jacopo Cappellato wrote:

>
> On Jun 4, 2008, at 8:13 PM, David E Jones wrote:
>
>>
>> On Jun 4, 2008, at 8:35 AM, Jacopo Cappellato wrote:
>>
>>> Hi all,
>>>
>>> I would like to add support for the status for non serialized  
>>> inventory items (right now the status is used only for serialized  
>>> items).
>>> The idea is to add a new status item for "Damaged" inventory (and  
>>> maybe "On Hold" for inventory under inspection); the inventory  
>>> items with this status will be excluded by the inventory counting  
>>> algorithm and also by the inventory reservation service.
>>> The main goal is to add the ability to keep into the warehouse non  
>>> serialized inventory items but don't use them in orders etc... (at  
>>> least until they are fixed), but don't just remove them from the  
>>> system (as it happens when you do a manual inventory variance).
>>>
>>> What do you think? Can I go on with this?
>>
>> It's an interesting idea. Right now all damaged/held/etc inventory  
>> is treated per unit, ie as serialized inventory. When returns are  
>> received each item is evaluated individually and tracked that way.
>>
>> If I understand where you are coming from, this becomes a problem  
>> when you receive 1000 damaged widgets and would have to create a  
>> record for each one.
>>
>
> Yes, this is the exactly the scenario I have in mind.
> And maybe another one could be this: I have the suspect that the  
> items in an inventory item could be damaged and I schedule an  
> inspection... in the meantime I want to make sure the items are not  
> reserved for new orders; so I change the status to "On Hold" until  
> the inspection is done.
>
> Thanks,
>
> Jacopo
>
>
>> With that in mind, perhaps this might be a good way to make the  
>> management easier without any data structure change, though there  
>> could be a number of code changes needed.
>>
>> -David
>>
>>
>