Category: Blog

If you’ve been doing VC for any length of time, you’re probably very aware of this little trick.  But if you’re new to VC, you might not be aware that you can dynamically control your characteristics.  You can use object dependencies to set a characteristic to invisible, or set it to input or no input.

For me, when I model a product line, I often need to add characteristics that aren’t always available for the user to see or to input.  For this, I will create reference characteristics based on the following table:

Simply create a new characteristic, and on the reference tab enter in the Screen_dep for the table, and one of the fields in the 2nd column as the field.

Now, in your object dependencies, you can simple use your standard logic:

$SELF.INVISIBLE = ‘MY_CSTIC’
IF….

now the only catch to this, MY_CSTIC must be spelled properly.  There is no syntax checking since it’s a literal.  But if you spell it correctly, and if the IF statement is met, MY_CSTIC will be made invisible.

It’s that easy.  Very slick and very powerful.  If you haven’t already, give it a try.

I just realized, it’s been a while since I talked VC.  Thought tonight would be a good time to add something new for those of you who enjoy the variant configuration posts.  Today I wanted to talk about the advantages of using the class hierarchy when you are modeling.  Often you may have multiple products that are all built on the same platform, but each has it’s own flavor.  In this situation, you will find that often a group of characteristics are shared among all of these product lines, and only a subset differ.  This is perfect for the class hierarchy.  To do this, you build a class with all of the “common” characteristics.  Then you create a second (or multiple) classes that contain the characteristics that are unique to the particular product line.  You then use transaction CL24N, enter in the “common” class, and assign the second class to it.  Now that second class contains all of the cstics of the upper level and the lower level.

Now,this sounds like a lot of work, but for maintenance purposes, whenever a new common characteristics needs to be added to all of the product lines, simply add it to the upper level class, it will automatically be added to everything that is below it.  The other huge benefit is that if use constraint nets, you can define the constraint to talk to the “Common class”, and thus you don’t even need to re-write the constraint for the lower level classes 🙂

There is a downside, and this is usually experienced the most in the development phase.  This is the ability to delete cstics from the common class becomes more challenging once they are inherited.  For that, you need to be sure to use transaction: CL6K to delete a cstic from the common class.  Typically, you don’t encounter this once you move the model to production, but often in the development phase you change your mind or find that you picked a characteristic that doesn’t belong or is replaced with something else.

But in my opinion, the upside far outweighs the downside.  Happy Configuring and Thanks for reading.