[ 
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

        

Reply via email to