ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject Re: Compoinent locatinos was Contributor branch Proposal,
Date Wed, 21 Jul 2010 07:35:46 GMT
From: "David E Jones" <dejc@me.com>
> 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).

Not quite sure about that too, but there is clearly a (maybe indirectly from workeffort through
ROU_TASK) dependence from this demo
data DemoConfigurator.xml, hence from any AGGREGATED Product. I don't say it's bad, only that
it exists.

Jacques

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