[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12461297 ] David E. Jones commented on OFBIZ-562: --------------------------------------
Well, I hope I'm not repeating myself too much. I was hoping others would express an opinion on this discussion, but oh well. The first and most important distinction I want to make is that the OFBiz data model, services, and even user interface elements are NOT hierarchical in nature, they are more of a "graph" because that is how business processes and data are in the real world. Things simply don't fall nicely into a single hierarchical classification scheme. The trouble is that as soon as we try to draw lines we have to prioritize some aspects of a thing over other sometimes just as valid aspects of that same thing. This is the case with the "FixedAsset". It is in accounting not because it belongs in and only in the accounting component, but rather because the accounting component is a lower level component and it somewhat makes sense there. In other words, there is nothing sacred about it being there and no problem with things in the product component depending on things in the accounting component. So yes, if we want more managed shipment of FixedAssets then the Shipment code in the product component and the facility webapp would just refer to the FixedAsset stuff in the accounting component. There is both precedent and consistent direction in this and I see no problem with. I DO however see a big problem with re-doing the data model underlying with the FixedAsset and related entities and the InventoryItem and related entities. I still don't see enough of a problem with the current model to justify such a major undertaking in not really just modeling, but more to the point all of the code that depends on these things... This is why I'd like others opinions, ie aside from you and me. My opinion is that all of the things you have mentioned can be implemented quite nicely on the current data model with perhaps a small extension here and there, and that redoing this model and the resulting work it would cause would not be justified by the things it might make easier... > Generic Item Schema Review > -------------------------- > > Key: OFBIZ-562 > URL: http://issues.apache.org/jira/browse/OFBIZ-562 > Project: OFBiz (The Open for Business Project) > Issue Type: Wish > Components: product > Reporter: Chris Howe > Priority: Minor > Attachments: entitymodel.xml > > > The current data model treats inventory item and fixed asset as if they have > nothing in common. And because there is nothing generic binding the physical > item they have even been separated into the notion that the fixed asset > physical item is dependent on accounting and the physical inventory item is > dependent on product. There is a bit of confusion because of the naming of > the entities. > Of course fixed asset is an accounting term, however I believe the accounting > data model has overstepped it's role on the physical item. Applications that > have to do with accounting should have no concern on whether the fixed asset > was moved from storage area A to facility B, as long as ownership hasn't > changed. Likewise accounting shouldn't be concerned on when the last time > the item classified as a fixed asset was washed or serviced (however it > should be concerned with the charges for those washings and services) In > business these departments that take care of these things are different. The > dock workers care about what isle the item is stored at; the maintenance > department cares about the servicing of the equipment; the bean counter is > only concerned about the depreciation of the item and the receipts. > Because the physical item classified as the fixed asset is an accounting data > schema, the product entity depends on accounting. This should not be. > Because the physical item is in the accounting schema, manufacturing is now > dependent on accounting. This also, should not be. This model prevents > Apache OFBiz from supporting the rental of items as well as modularization. > Both are features that would greatly enhance the value of Apache OFBiz. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
