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
