Good points so I guess it depends on the industry, but knowing an id
versus using a look up everytime you deal your products makes a big
difference to me.
Regards
Scott
Chris Howe wrote:
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
