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.reasonEnumIdand InventoryItemVariance.comments --> InventoryItemDetail.description What do you think? Jacopo
smime.p7s
Description: S/MIME cryptographic signature
