ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David E Jones <d...@me.com>
Subject Re: Compoinent locatinos was Contributor branch Proposal,
Date Wed, 21 Jul 2010 00:39:35 GMT

That is an interesting argument, but complicated to solve. You should be able to disable the
manufacturing manager app without affecting other apps. You should even be able to get rid
of the services, if no other component is calling them (I don't know about that). Getting
rid of the data model is more difficult as there is more chance of dependency, and you'll
have a nice graph of foreign keys to deal with.

In a way it would be nice to remove any part of the data model and have things "gracefully
degrade", but that would require a lot of work, and a lot more clear definition of how entities
are grouped, and possibly the need to change how entities are grouped based on sets of entities
most commonly used in different circumstances. Anyway, there are lots of things people would
like to remove. Sometimes it's accounting, sometimes not just manufacturing but also all types
of WorkEffort (projects, tasks, etc), or perhaps they only want to use warehouse and shipping
management and they don't want to track orders or anything. You could probably come up with
thousands of subsets of the entities that would make good sense to use separately from the
rest.

-David


On Jul 20, 2010, at 6:11 PM, BJ Freeman wrote:

> Matt:
> from a users perspective it would not be any different.
> 
> However from a developers perspective, if the manufacturing is of no use, like in a retail
outlet, then it should be able to be  deactivated with no ill effect to the base applications.
> 
> Matt Warnock sent the following on 7/20/2010 2:47 PM:
>> +1.
>> 
>> Our company sits right at the intersection of two industries,
>> distribution and manufacturing.  We outsource our manufacturing, but we
>> still have to manage it quite a bit, and ordering more product requires
>> printing approved labels, etc.  So in some ways we look more like a
>> distributor/warehouse with a very small number of SKUs, and in others
>> more like a rather simple manufacturing operation.
>> 
>> Silverston does a great job of laying out what both the manufacturing
>> and distribution business models should include.  But I don't need to
>> use most of either one.  At some point (far in the future) we may use
>> more of the manufacturing.  But having the shared data in the entities
>> means I don't need to worry about whether the distribution set will talk
>> properly to the manufacturing set, and whether the database structure
>> that I use now will integrate properly later on as our needs may change.
>> 
>> I probably would not use most of the features of either a distribution
>> or manufacturing special-purpose app in its entirety, but seamless
>> integration of both is critical to me.  That's why David's model of
>> keeping the data structure entities in the core is important, IMHO.
>> 
>> I don't (and probably never will) use time billing, job costing, or POS
>> features at all, but it certainly doesn't bother me that the data
>> structures are defined in the core for those whose models will include
>> those common functions.
>> 
>> Just my 2 cents.
>> 


Mime
View raw message