This is "big picture" discussion and certainly not cookie cutter, so there are pros and cons on both sides. I take the approach that being the programmer, you have the capability to provide your company or your client's company the capability to not let database theory requirements get in the way of them running their business.
As far as making life easier, you can still do lookups based on aliases and treat them as if they are unique, as they certainly need to be unique for the date (think getProductNameForDate service instead of getPartyNameForDate). The burden should be placed on the programmer to make this seamless, not on the business to adjust to the peculiarities. >From a competitive perspective, the first potential problem with using the automated intelligence productId as the glue to hold together your different product data is the scenario where a competitor comes along, is more successful in gaining the mind share of the sequence of the components for the intelligence productId. Their 2KBL34M37 is the equivalent to your B730HM250, but you carry a different product with ID 2KBL34M37. You're both in the same industry and customers mistakenly order your competitors product Id thinking that you are perhaps a distributor of their product or them of yours. Now no solution can prevent this from happening the first time or even perhaps the tenth time. However once you realize the problem, an intelligent primary key prevents you from taking action without completely overhauling your database and making assumptions about your historical data which is perhaps inaccurate. An alias primary key lets you come out with a "new" product line renaming everything under the sun without changing the underlying product data. Just to provide a real world business story behind this, productId naming conventions happen to be an important consideration with me as I'm in an industry where manufacturers consistently overlap their productIds and brand names don't really get plastered into the heads of the people ordering the product (medical supplies). A hospital could be ordering a "6002" and be meaning to order a diaper or they could be meaning to order a cardiac catheter surgical prep kit or a bone saw. Those three items from the manufacturers perspective are in diverse enough fields to never recognize that there is a conflict with productId. However, down the supply chain a distributor is handling all three and perhaps losing sales for the manufacturer because of their inability to clarify the end customer's needs. You may not need to deal with these considerations (much larger and successful companies have chosen not to). But you should do yourself a favor and take the short amount of time to consider it now and weigh that against what you end up being locked into. It's no skin off my nose if you decide the effort to implement such a convention isn't worth the flexibility gained later ( unless you're a medical supply manufacturer :-) ) Regards, Chris --- Scott Gray <[EMAIL PROTECTED]> wrote: > Personally I can't see the harm myself. I know from > personal experience > that having memorable productId's can dramatically > ease the day to day > the usability of most of systems not just OFBiz. Do > you have any > examples of where a memorable productId would cause > a problem? > > I can see that it may not be suitable for companies > with huge product > ranges or short life cycles, but if your product > range is pretty > constant it can make life much easier. > > Regards > Scott > > Chris Howe wrote: > > While that is one avenue to pursue with your > > productId, and will certainly make things easier > now, > > you may wish to consider the long term > repercussions > > of such a convention. > > > > The productId in OFBiz is largely used as a > surrogate > > key. Adding intelligence to this key, while > supported > > OOTB, really limits your options later for > > discontinuation of products, changing versions of > the > > product, similar named productIds, marketing etc. > If > > instead you allow the productId to have no meaning > and > > push the intelligence onto an alias, or internal > name, > > etc, you maintain your ability to control the > naming > > convention as your client's business changes in > the > > future. There is the trade-off as this is > slightly > > more difficult and not OOTB. > > > > Regards, > > Chris > > --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > > > > > >> Got it. Thanks, life saver! Will explore that and > >> let you know. OFBiz looking better and better! > >> > >> Jonathon > >> > >> Scott Gray wrote: > >> > >>> The Quick Add Variants already auto-generates > ids > >>> > >> you would just need to > >> > >>> alter the code to put the id together in the way > >>> > >> you want. > >> > >>> For auto boms have a look at > >>> > >> ManufacturingExampleData.xml, there is a > >> > >>> similar example at the bottom of the file to > what > >>> > >> you are after. The > >> > >>> screen to play with is the one I incorrectly > >>> > >> mentioned the other day, > >> > >>> Manufacturing -> Bill of Materials -> > >>> > >> Manufacturing Rules. > >> > >>> Regards > >>> Scott > >>> > >>> Jonathon -- Improov wrote: > >>> > >>>> Is there a way to have rule-based > auto-generation > >>>> > >> of BOMs? Maybe this > >> > >>>> has already been done? > >>>> > >>>> In general, I have a virtual product that can > >>>> > >> have thousands of > >> > >>>> variants. I'd like an automated way to generate > >>>> > >> all the possible > >> > >>>> variants. > >>>> > >>>> One aspect I'm gonna be looking at is > rule-based > >>>> > >> auto-generation of > >> > >>>> variants' productId. This shouldn't be > difficult, > >>>> > >> and can easily be > >> > >>>> linked to the QuickAddVariants page (the > >>>> > >> checkboxes in column "All"). > >> > >>>> If someone is already doing this, let me know > so > >>>> > >> we can collaborate? > >> > >>>> The bigger problem I have is the > auto-generation > >>>> > >> of BOMs, the lack > >> > >>>> thereof rather. > >>>> > >>>> Say I have virtual product Bicycle, and > variants > >>>> > >> Bicycle-abcd, where > >> > >>>> abcd are variables. I'd like variable 'a' to be > >>>> > >> the top-most in > >> > >>>> hierarchy and 'd' the last. For example, my > >>>> > >> bicycles could come with > >> > >>>> different frame sizes 1 through 5, which will > >>>> > >> require different BOM > >> > >>>> components Frame1 to Frame5. I'd want all > >>>> > >> variants Bicycle-1bcd to > >> > >>>> have a BOM component of Frame1, Bicycle-2bcd > >>>> > >> Frame2, and so on. > >> > >>>> Even a semi-automated process will be alright > for > >>>> > >> now. > >> > >>>> I'd suggest an enhancement to the > EditProductBom > >>>> > >> screen. Add a > >> > >>>> function to list all variants, search can be > >>>> > >> constrained by selection > >> > >>>> of (standard) features. This function can be > >>>> > >> copied from "Lookup > >> > >>>> Variant Product" somehow. Allow "Copy BOM" to > >>>> > >> apply to a number of > >> > >>>> variants at once. > >>>> > >>>> Any ideas? > >>>> > >>>> Jonathon > >>>> > >>>> > >>> > >> > > > > > > > >
