Should we deprecate the InventoryItemVariance entity?

[Jacopo Cappellato]

What about deprecating the InventoryItemVariance entity?
It seems duplicated by the newer InventoryItemDetail entity: we could
use the latter with the following mapping:

InventoryItemVariance.varianceReasonId --> InventoryItemDetail.reasonEnumId

and

InventoryItemVariance.comments --> InventoryItemDetail.description

What do you think?

Jacopo

[Scott Gray]

+1 from me

Scott

On 08/11/2007, Jacopo Cappellato <[hidden email]> wrote:

> What about deprecating the InventoryItemVariance entity?
> It seems duplicated by the newer InventoryItemDetail entity: we could
> use the latter with the following mapping:
>
> InventoryItemVariance.varianceReasonId --> InventoryItemDetail.reasonEnumId
>
> and
>
> InventoryItemVariance.comments --> InventoryItemDetail.description
>
> What do you think?
>
> Jacopo
>
>

[David E Jones]

I think this change is fine. It would throw a little kink in the  
special handling of the financial impact for this sort of thing.  
However we do this we just need to make sure it's very clear that the  
change is due to inventory lost/found/damaged/etc. That would be in  
the reasonEnumId.

My thoughts on the inventory variance going back a ways is that it's  
really weird to have the variance associated with a single inventory  
item. It seems like something related to Product, Facility and perhaps  
FacilityLocation would make more sense. Based on the record for that  
an InventoryItem would generally be created.

In other words I'm saying that instead of having a variance entity  
that points to the InventoryItem entity, the pointing would go in the  
other direction (probably to the InventoryItemDetail entity rather  
than InventoryItem).

I thought I should bring this up before we make any decisions about  
the direction to go, or any changes to make, with InventoryItemVariance.

-David


On Nov 7, 2007, at 7:40 AM, Jacopo Cappellato wrote:

> What about deprecating the InventoryItemVariance entity?
> It seems duplicated by the newer InventoryItemDetail entity: we  
> could use the latter with the following mapping:
>
> InventoryItemVariance.varianceReasonId -->  
> InventoryItemDetail.reasonEnumId
>
> and
>
> InventoryItemVariance.comments --> InventoryItemDetail.description
>
> What do you think?
>
> Jacopo
>

[Jacopo Cappellato]

David E Jones wrote:
>
> I think this change is fine. It would throw a little kink in the special
> handling of the financial impact for this sort of thing. However we do
> this we just need to make sure it's very clear that the change is due to
> inventory lost/found/damaged/etc. That would be in the reasonEnumId.
>

About the financial aspect: what if we always fill the
InventoryItemDetail.reasonEnumId? Not only for manual variances
lost/found etc... but always to categorize the detail ("sales order
shipment issuance", "purchase order shipment receipt", "manufacturing
order..." etc...); then we could use this field to post the accounting
transactions (related to inventory) to the proper account; we could
catch mostly all of the inventory accounting events with one ECA on the
InventoryItemDetail.
Maybe reasonEnumId could become inventoryItemDetailType...
Apart from this aspect: in the meantime, is it ok if I commit a very
simple patch to populate the reasonEnumId and description fields of the
InventoryItemDetail with the values set in the InventoryItemVariance
entity? It will be very very easy to drop (or deprecate) that entity
later (together with the VarianceReason entity?).

> My thoughts on the inventory variance going back a ways is that it's
> really weird to have the variance associated with a single inventory
> item. It seems like something related to Product, Facility and perhaps
> FacilityLocation would make more sense. Based on the record for that an
> InventoryItem would generally be created.
>

I agree: however I'd say that we should also maintain the ability to
define a variance for a specific inventory item (as is now) but I
totally agree with you that it is very common to count items by
location/facility.
The data model is probably correct as is now (even without the
InventoryItemVariance), we just have to implement new screens (and
processes) to find all the inventory items in a given location/facility
that must be adjusted (similar to the reservation routine) to complete a
physical inventory variance. In the data model the end result will be:

PhysicalInventory.physicalInventoryId --> list of InventoryItemDetails

Hmmm... thinking more about this: maybe the meaning of PhysicalInventory
was not that of "a single variance entered by a user for a
product/location/facility" but instead that of "counting all the
products in a facility".
But maybe we could adopt the former concept and add a new field
(parentPhysicalInventoryId?) to group together the variances happening
during an inventory counting.

Jacopo

> In other words I'm saying that instead of having a variance entity that
> points to the InventoryItem entity, the pointing would go in the other
> direction (probably to the InventoryItemDetail entity rather than
> InventoryItem).
>
> I thought I should bring this up before we make any decisions about the
> direction to go, or any changes to make, with InventoryItemVariance.
>
> -David
>
>
> On Nov 7, 2007, at 7:40 AM, Jacopo Cappellato wrote:
>
>> What about deprecating the InventoryItemVariance entity?
>> It seems duplicated by the newer InventoryItemDetail entity: we could
>> use the latter with the following mapping:
>>
>> InventoryItemVariance.varianceReasonId -->
>> InventoryItemDetail.reasonEnumId
>>
>> and
>>
>> InventoryItemVariance.comments --> InventoryItemDetail.description
>>
>> What do you think?
>>
>> Jacopo
>>
>

[Jacopo Cappellato]

I would like to definitely fix this before we implement the GL posting
service for inventory variances.

Here is my attempt (draft) to implement David's notes on this:

1) deprecate InventoryItemVariance and replace it with a new entity:
InventoryVariance with the following fields:
inventoryVarianceId (pk)
varianceReasonId
physicalInventoryId
comments

2) add the field inventoryVarianceId to the InventoryItemDetail entity

3) implement a new service createInventoryVariance that thakes as input
the following fields:
productId (mandatory)
availableToPromiseDiff (optional)
quantityOnHandVar (optional)
facilityId (mandatory)
locationSeqId (optional)
inventoryItemId (optional)

where facilityId, locationSeqId and inventoryItemId are used to select
the InventoryItems that will be considered for the variance; if we
specify the inventoryItemId then the service will work in the same way
the createPhysicalInventoryAndVariance is working now

What do you think?

Jacopo


David E Jones wrote:

>
> I think this change is fine. It would throw a little kink in the special
> handling of the financial impact for this sort of thing. However we do
> this we just need to make sure it's very clear that the change is due to
> inventory lost/found/damaged/etc. That would be in the reasonEnumId.
>
> My thoughts on the inventory variance going back a ways is that it's
> really weird to have the variance associated with a single inventory
> item. It seems like something related to Product, Facility and perhaps
> FacilityLocation would make more sense. Based on the record for that an
> InventoryItem would generally be created.
>
> In other words I'm saying that instead of having a variance entity that
> points to the InventoryItem entity, the pointing would go in the other
> direction (probably to the InventoryItemDetail entity rather than
> InventoryItem).
>
> I thought I should bring this up before we make any decisions about the
> direction to go, or any changes to make, with InventoryItemVariance.
>
> -David
>
>
> On Nov 7, 2007, at 7:40 AM, Jacopo Cappellato wrote:
>
>> What about deprecating the InventoryItemVariance entity?
>> It seems duplicated by the newer InventoryItemDetail entity: we could
>> use the latter with the following mapping:
>>
>> InventoryItemVariance.varianceReasonId -->
>> InventoryItemDetail.reasonEnumId
>>
>> and
>>
>> InventoryItemVariance.comments --> InventoryItemDetail.description
>>
>> What do you think?
>>
>> Jacopo
>>
>

[Jacopo Cappellato]

Please ignore ma previous message in this thread (for now)... it's not
as urgent as I thought because I've already found a good solution for
the GL posting routine.
We will discuss the best way to go at later point.

Jacopo

Jacopo Cappellato wrote:

> I would like to definitely fix this before we implement the GL posting
> service for inventory variances.
>
> Here is my attempt (draft) to implement David's notes on this:
>
> 1) deprecate InventoryItemVariance and replace it with a new entity:
> InventoryVariance with the following fields:
> inventoryVarianceId (pk)
> varianceReasonId
> physicalInventoryId
> comments
>
> 2) add the field inventoryVarianceId to the InventoryItemDetail entity
>
> 3) implement a new service createInventoryVariance that thakes as input
> the following fields:
> productId (mandatory)
> availableToPromiseDiff (optional)
> quantityOnHandVar (optional)
> facilityId (mandatory)
> locationSeqId (optional)
> inventoryItemId (optional)
>
> where facilityId, locationSeqId and inventoryItemId are used to select
> the InventoryItems that will be considered for the variance; if we
> specify the inventoryItemId then the service will work in the same way
> the createPhysicalInventoryAndVariance is working now
>
> What do you think?
>
> Jacopo
>
>
> David E Jones wrote:
>>
>> I think this change is fine. It would throw a little kink in the
>> special handling of the financial impact for this sort of thing.
>> However we do this we just need to make sure it's very clear that the
>> change is due to inventory lost/found/damaged/etc. That would be in
>> the reasonEnumId.
>>
>> My thoughts on the inventory variance going back a ways is that it's
>> really weird to have the variance associated with a single inventory
>> item. It seems like something related to Product, Facility and perhaps
>> FacilityLocation would make more sense. Based on the record for that
>> an InventoryItem would generally be created.
>>
>> In other words I'm saying that instead of having a variance entity
>> that points to the InventoryItem entity, the pointing would go in the
>> other direction (probably to the InventoryItemDetail entity rather
>> than InventoryItem).
>>
>> I thought I should bring this up before we make any decisions about
>> the direction to go, or any changes to make, with InventoryItemVariance.
>>
>> -David
>>
>>
>> On Nov 7, 2007, at 7:40 AM, Jacopo Cappellato wrote:
>>
>>> What about deprecating the InventoryItemVariance entity?
>>> It seems duplicated by the newer InventoryItemDetail entity: we could
>>> use the latter with the following mapping:
>>>
>>> InventoryItemVariance.varianceReasonId -->
>>> InventoryItemDetail.reasonEnumId
>>>
>>> and
>>>
>>> InventoryItemVariance.comments --> InventoryItemDetail.description
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>
>
>