Contact

Industry Leading Blog for Manufacturers     

"Nature is pleased with simplicity. And nature is no dummy"

― Isaac Newton

Characteristics are one of the fundamental building blocks of Variant Configuration.  As building blocks they have to interact with all the other objects in the system; classes, materials, tables, and dependencies.  In creating them it’s always best to make them as simple as possible (but no simpler).  This gives them a flexibility that can be exploited throughout the model.  Apologies to Mr. Einstein[1], et.al.

When confronted with the Create Characteristic dialog, there are a lot of decisions to make.  Character or Numeric? How large? Case Sensitive? Restrictable? Required?...  As you make these choices, keep in mind that simpler is better.  While many things can be changed later, a few are more difficult, and a few more cannot ever be changed (without a herculean effort).  Following are some random thoughts on some of those choices:

Data Type – Unless I will need to perform calculations (and not just comparisons) on or against it, I make most characteristics CHAR.  Certainly there are times I need to make them NUM.  All the numbers between 1.11 and 2.25 by 100ths would be hard to do with a CHAR.  But just because a characteristic can be described as a number doesn’t mean it has to be a number, or even that it should be a number.  Sometimes it’s just easier to work with characteristics that are all CHAR. 

When deciding, I keep the following in mind:

  1. I like the ability to use descriptions to convey other data like conditions or UOM.  Descriptions are absent in NUM characteristics.  They’re presented as simple numbers. 
  2. I like the ability to concatenate (build strings). You can’t concatenate a model number that consists of NUM and CHAR characteristics without first converting the NUM ones.   
  3. I also like the ability to mix Units of Measure (since they would be in the description, not in the master data). So, I can offer 1”, 28mm, 3” and 1m in the same characteristic without having to specify UOM. 
  4. Finally, I can overcome the inability to do calculations in code by using temporary characteristics and multiple if-then constructs.   I don’t always use CHAR, but I use it more often than you might think. 

Number of Chars – I am a lazy typist.  I always make this number as little as possible.  And I make the actual values as short as possible.  I would much rather type “TV” than “Tryptich Valve”.  I can always make it bigger in the future.  (Conversely, you can never make it smaller; for NUM or CHAR.)  I try not to be so lazy that I don’t know what I meant 6 months later when I’m reading the code.  I believe there is a happy medium.

I know there are others who always make CHAR characteristics 30 chars long.  Gone are the days when storage was so expensive it made a difference in the costs (remember Y2K?).  Make everything 30 and you’ll never have to change it.  I don’t think it really matters, but I always try to keep things consistent.  Even if I make all CHAR characteristics 30 I would still use values as short as possible.  I think it’s a consistency thing.  Pick one philosophy and stick to it. 

Case Sensitive (CHAR Only) – Remember, this is only the Values that will be case sensitive.  Descriptions are always case sensitive, so users can always see something that makes sense to them.  I never use this unless I absolutely positively have to.  Like when “AX” and Ax” mean something different. In my opinion the code never needs to be case sensitive.   As an aside, I always code SAP in upper case.  In other languages I code in lower or mixed case.  SAP defaults to upper case when values are case insensitive, so all upper case makes sense to me.  In my opinion this case insensitivity also removes the possibility of making case errors in coding.  Especially if you’re consistent in not making characteristics case sensitive.

Unit of Measure (NUM only) – I avoid using this if at all possible.  Sometimes you can’t get around UOM.  For example; the QM module requires UOM for characteristics used in Quality Control.  If that’s the case use a UOM.  But, if a number always refers to the same UOM, and there’s no secondary requirement, there’s no reason to add it.  That will get taken care of in the BOM.  (Line items always have a UOM.)

If a UOM not required, adding one anyway just adds an additional (unnecessary) level of complexity; another place for you or the users to trip up.  If a characteristic has a UOM a user can type in a different UOM and SAP will do the conversion.  Sometimes in a manner that you didn’t anticipate.  To beat my dead horse further into the ground; use also requires that the UOM designation and conversion master data be exactly the same on the development, quality, and production systems (something that is not always the case). 

Now, there is a valid argument for using UOM when you have dimensions in both US Customary and Metric.  I certainly have used it in these situations.  On the other hand I have also used separate characteristics for US and for Metric.  Often it turns out that the automatic conversion you get with UOM specification doesn’t play well with standardized material sizes.  A ¼” screw is not replaced with a 6.35mm screw.  It’s a 6mm or an 8mm screw.  The complicated dance you have to do to use UOM often outweighs the effort to just use 2 separate characteristics for each dimension.  Especially when the values for the characteristics are limited and discrete. 

Template – this is where you would specify that the characteristic for a Social Security number would have 3 digits, a dash, 2 more digits, another dash, and 4 final digits. (NNN-NN-NNNN)  On its face it looks like valuable functionality. 

I almost never use this.  I don’t use it partially because I so seldom have a discrete, enforceable pattern.  I don’t use it mostly because the whole template concept doesn’t work in IPC.  IPC compatibility is a best practice going forward.  Much better to validate those few characteristics with a distinct pattern in code or against a table.  That method should work in whatever front end the model ends up getting configured in. 

Single/Multiple Values – Size is a single value.  A configuration will only have one size.  Options is a multi-value.  A configuration could have multiple options selected.  Admittedly Single is much more common than Multi.  But Multi certainly has its uses.  Just keep in mind that Multi-value Characteristics behave a little bit differently in constraints and procedures.  Also keep in mind that this aspect of a Characteristic that’s difficult (although possible) to change after you have begun to use it.  My advice here is to just think through the uses (tables, dependencies) and make an intelligent guess (knowing that it ultimately is a guess that you might have to come back and fix.)

Restrictable – Restrictability is the ability to programmatically restrict the values available to a user to a subset of all the values in a characteristic.  This subset would be offered between having all the choices, and making the final selection.  An example would be showing all the animals to choose from, and then programmatically restricting the choice to only those with 2 legs. The user hasn’t made a final choice, but their list of available options has been restricted.   If this box isn’t checked a characteristic is only ever presented as the set of all of the valid options (unselected), or the single one that’s been selected.  No subsets are ever presented.

The use of this functionality is a topic in and of itself.  It affects scalability, table use, and inter-characteristic compatibility.  All I’m going to say here is that making all characteristics restrictable all the time is a bad idea.  The biggest problem is scalability.  Even moderately complex models where all the characteristics are restrictable can become performance problems.  Without getting into the technical details SAP has to maintain a much larger what-if dataset inside the configuration engine during configuration.  Larger datasets lead to decreased performance. 

Certainly there are times when this functionality is valuable and necessary.  Because this aspect of a characteristic is difficult to change after a characteristic has been used, I recommend that you get in the habit of only checking the box of those characteristics that you know need to be restrictable. 

Don’t get me wrong.  I love the functionality making a characteristic restrictable brings.  Combined with tables and constraints it’s a powerful tool in your toolbox.  Use it, but use it intentionally. 

Entry Required – This is where you check if the characteristic is always required.  Note the emphasis on the word “always’.  If it’s sometimes required and sometimes hidden (or not required) you’ll have to use a combination of procedures, pre-conditions, and selection conditions. 

I’ll just end here with a plug for consistency. 

If this is how you make a characteristic unconditionally required, always use this method.  Don’t sometimes check this box and sometimes use a selection condition that’s always true.  Doing the same thing the same way makes understanding and maintaining a model so much easier after you haven’t looked at it for a while.

So, this blog didn’t even cover the whole first screen of the Create Characteristic dialog.  There are still a lot of topics for future posts.  If you take away nothing else, take away the concept that even though there are a number of choices when creating a Characteristic, keeping all characteristics as simple as possible will result in the best and most flexible characteristic set to use in your model.  Coding will be simpler and less error prone.  Maintenance is easier.  And scalability becomes a smaller issue for concern.


Name:
Email:
Subject:
Message:
x


Stay up to date on the leading industry solutions by subscribing to eLogic's digest.
What can we help you with?

- Office Locations -

(585) 506-4600  |  (844) 506-4600