You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Chris Howe (JIRA)" <ji...@apache.org> on 2006/12/24 06:41:21 UTC
[jira] Created: (OFBIZ-562) Generic Item Schema Review
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
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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12460693 ]
David E. Jones commented on OFBIZ-562:
--------------------------------------
Chris, could you describe what it is that the current model can't support?
> 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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "Chris Howe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12460699 ]
Chris Howe commented on OFBIZ-562:
----------------------------------
Rental of items that get shipped and reordered and modularization
> 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
Servicemix + Ofbiz,
Posted by Chandresh Turakhia <ch...@bhartitelesoft.com>.
Dear all
Ofbiz is great but at times team wants some changes for compatilibity with
other projects.I saw some messages in user group regrarding the same.
If some one wants to attempt to integrate Ofbiz by servicemix; what would be
the best way to do it.
ServiceMix 3.0 deserves a lot for sure.
I think minilang holds the key.
Chand
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "Chris Howe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12460722 ]
Chris Howe commented on OFBIZ-562:
----------------------------------
I apologize for the short answer, but we've (you and I) discussed this at length in the past.
It really doesn't support the ability to ship a fixed asset. At least not without further ingraining the accounting component into things that have nothing to do with accounting. And by ingraining it further, makes it even more difficult to modularize the components.
Someone writing automation code for shipping really shouldn't need to consult the accounting code to implement their application (especially if they're not using OFBiz for accounting). Someone wanting to offer product for rent shouldn't need to have actual product available at the time an order is placed. All of these things are naturally available with the current InventoryItem implementation but are not available for rental items (fixed asset) any attempt to implement these features would further blur the distinction between accounting and product application.
The decision for my company to utilize a similar data model as the one attached for this has already been made. For us an ideal situation would be for it to eventually make its way into OFBiz so that we'll have less IT to maintain as well as be able to offer our experiences and feature sets as we tackle them (Which as far as I know is the only reason for anyone to contribute anything to any open source project outside of a hobbyists benefit). If this isn't a direction that the Apache OFBiz community is comfortable with, that's fine. However, if it's all the same, I would appreciate any critique (in way of pitfall warning, failed use case scenarios, omniscient inspiration, etc of using the attached model that anyone has time to offer. Thanks!
> 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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "Chris Howe (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12460721 ]
David E. Jones commented on OFBIZ-562:
--------------------------------------
Thanks for the additional information.
It seems to me the current model supports all of those things just fine.
> 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
[jira] Updated: (OFBIZ-562) Generic Item Schema Review
Posted by "Chris Howe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=all ]
Chris Howe updated OFBIZ-562:
-----------------------------
Attachment: entitymodel.xml
entitymodel.xml
This entity model for the generic Item presents two ideas that i would like feedback from anyone who has time or expertise to offer.
First a mostly complete representation of an Item.
Second the introduction of an approach to seperate denormalized data from normalized entities. There is a lot of benefit of having things like Item.ownerPartyId easily to reference, but this data should be normalized in ItemRole. Separating into an entity ItemDenormRoles with a one to one relationship with ItemRole creates a nice balance as a view entity can be easily created to make this easy to program with.
> 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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "David E. Jones (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (OFBIZ-562) Generic Item Schema Review
Posted by "Chris Howe (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/OFBIZ-562?page=comments#action_12460688 ]
Chris Howe commented on OFBIZ-562:
----------------------------------
Almost forgot,
I would appreciate if anyone who has the time could critique it, both as a potential change in OFBiz as well as a seperate implementation. Our company is using something very similar to this because we regularly rent items that are frequently reordered and the current schema cannot support it.
> 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