[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12461300 ] Chris Howe commented on OFBIZ-562: ----------------------------------
I appreciate the time you took to comment. I would tend to agree, in general, about balancing the amount of work necessary to redo the model, backwards compatibility (which you didn't mention, but took this into consideration as well) and such versus the amount of be benefit brought about by the change. There's one exception with your comment that I take from a business POV as well as a data model POV with your comment (although our disagreement may simply be semantical): "the accounting component is a lower level component" Financial account (as opposed to managerial accounting, which is what the non accounting components are) is a function of a business that simply documents and reports what has happened. Therefore, it is a very high level function as it needs to sit on top and observe what everything else is doing. I understand your notion about the graph, however most of ofbiz and business for that matter fits hierarchically. Base: Party (who) Location (where)* Item (what) Status (when) *note location is explicitly inside party component with no real use case scenario to separate it as there isn't much argument for one without the other Product - builds on top of Item with some Party Manufacturing - builds on top of either Product or Item (I haven't investigated too far since InventoryItem is considered part of Product) Order - builds on top of Product, Party, and Status Accounting - Builds on top of Order Marketing - builds on top of Product and in regards to successful campaigns, on top of Order as well Humanres - builds on top of Party >From this view and the empirical lack of use of OFBiz accounting (while it's >certainly improving, it's no Quickbooks killer for a small to medium sized >business), the case for removing accounting dependencies is that it removes >the need for future integrated accounting solutions to consider the >interactions with components that it has no need to observe. Even Intuit >makes the distinction that a retail environment, wholesale environment, >manufacturing environment and so on are very differently structured for >accounting. I think it's perhaps naive that OFBiz would think that a single >accounting solution could accommodate all of these very different business. I feel I may have run a tangent to the information given thus far, so let me know if I need to clarify. Again, the only reason why I'd like feedback on Ofbiz inclusion is so as we go along trying to re implement the various functionality, whether we should be do those implementations in a generic manner or if we only consider our use cases. I'm really more interested in potential pitfall advice so that I can design a solution now before getting too deep with this. Aside from Generic Item issue. What are your thoughts on the separation of denormalized fields in the manner of the attachment? Again, thanks for your feedback! > 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
