Re: Managing the status for non serialized inventory items
Posted by
Ashish Vijaywargiya on
Jun 06, 2008; 3:34pm
URL: http://ofbiz.116.s1.nabble.com/Managing-the-status-for-non-serialized-inventory-items-tp193584p193590.html
+1.
On Thu, Jun 5, 2008 at 12:10 AM, Sumit Pandit <
[hidden email]>
wrote:
> +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
>>>
>>>
>>>
>>
>