From: "David E Jones" <d...@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.
