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.
