SAP

Here’s a fun fact that I totally forgot about.  Tables can’t use multiple value characteristics.  If you attempt to assign a multiple value characteristics to a variant table, the table will work just fine, until you attempt to assign it to a selection condition, or inside of a an IF statement.  It’s been so long since I ever even thought about doing this that I struggled for over an hour trying to get a simple selection condition to compile.  (see my earlier post on if I’m too old school or not for more details).  So, for that reason, I thought I’d throw these little tidbits out there.

1.  If you need to use a multiple value characteristic inside of a table, be sure to create a single value copy of it to be used as the table key.  This will allow you to set values from a variant table.
2.  You can’t use multiple value characteristics as an assignment into a variant table for a “true or False” type scenario.  When I talk about True or False, I mean you can’t enter a table into an IF statement to see if the combo exists, and you can’t use that table in a selection condition or precondition, which also behave in a true or false fashion.

Now, I’ll only be on my soapbox for a second, but to me, this is just one more clue to keep it simple in the BOMs and routings for your selection conditions.  Let the configuration do all the heavy lifting.  That’s it… I’m done =)

Anyway, thanks for reading.

I realize today might be pretty obvious for a lot of you VC experts out there, but I wanted to talk about Restricting characteristic values.  To me, this is one of the coolest features in variant configuration.  If you are not familiar with the concept, restricting characteristic values gives you the ability to dynamically remove values that are no longer valid because of other selections.

In variant configuration, there are two techniques to accomplish restricting characteristic values.  You can use Preconditions or Constraints.  There are couple things to consider…  One, Preconditions are old technology.  They are typically only recommended as a “last resort”.  In my experience, the only use for preconditions is for multiple value characteristics.

Now, constraints are the best way to handle this in my opinion.  There are some prerequisites to use this.  First of all, the characteristics must be set as Restrictable.  If not, your values won’t dynamically appear/disappear, you’ll just get a red X when things are violated.  Now the first big advantage is that constraints can be set to work differently by product line (or class).

Now the next big thing in a constraint is how to restrict the values.  Now there is the “easy” method that you can manually set the values.  For example:

C.CHAR_1 IN (‘A’,’C’,’F’)  IF C.CHAR_A = 1,
C.CHAR_1 IN (‘X’,’Z’) IF C.CHAR_B = 2

Now, this method works fine, and will restrict the values of CHAR_1.  However, in my humble opinion, the better way to do it is to use a Table.

Table:
Char_A   CHAR_1
1                A
1               C
1               F
2              X
2              Z

Then, in the constraint, you can simple put in the table, and it can restrict things both ways.  Why is this important?  If you plan to push this configuration to your customers, you should never assume that they will answer the questions sequentially.  If you restrict things both ways (and the table is the easiest way), then regardless of what they answer, everything will be consistent.

Anyway, that’s the deal for today.  Hope you find it useful.

On my latest project, I’m not the one setting the design, so I’m going with the flow of what was decided.  One of the point that I’m having a hard time with is the selection conditions being assigned to the bill of material items.  Now my long time friends and colleagues know that I’m hard core of keeping all of the logic out of the bill of material.  I learned a hard lesson of putting too much logic into the BOM selection conditions.  Now, here’s my question to you modeler’s out there.  I managed to crash MRP in 3.0F using a combination of material variants and complex selection conditions.

Now, since that time, I’ve gone to great lengths to avoid anything other than simple assignment logic in my bills of materials.  Now, this does cause me to create a lot of additional characteristics in my configuration.  Granted, all the characteristics are calculated and never seen by the user.  This sets all the logic on the front end.  By the time the back end does anything with it, it’s as simple as pie.  This is the process I’ve lived by for over 15 years of Variant Configuration.

The thing is, that was 3.0F…  15 years ago that this occurred.  I know that SAP has dramatically changed the processes for VC.  The “word” is that as long as you don’t plan to use Characteristic Value Planning or APO.  But being the old VC guy that I am, I have a hard time to believing that.  So my question to all of my readers out there…  where do you stand?  have you put complex BOM logic into your models?  and if so, did you notice any impact on MRP?  I’d love to hear your experiences.

As always, thanks for reading and I look forward to hearing form you.

To all of my Variant Configuration modelers out there, you all understand exactly what I’m talking about.  Your models are only as good as the information you have to work with.  I’ve modeled at quite a few different places, and more times than not, the information is always the bottleneck.  My current assignment is no different.  So it what brings me to my topic of the day, the value of good information for your VC models, and the format that it’s in.

In my travels, I’ve seen the extremes, good and bad.  I’ve seen notebook pages with scribbles, and I’ve seen fancy designed tools just for the documentation of the VC rules.  What I’m here to tell you is that you don’t need anything fancy.  In my experience, an excel spreadsheet with some standard formatting is more than you need.  Fancy tools will just cost you money, and in the long run, cost you time.  Because you still need to move all the information into the fancy tool.  Spend a couple of hours, put together a format you can read.  Work with the modelers and business people.  It’s really that simple.  I’m an engineer, so I like to start with the bill of materials first.  I’m a fan of listing out all the components, and then break down the rules that it takes to select each.  From there, it’s usually pretty easy to break it down and sort it out.

Then go into the sales/marketing rules.   The important thing here is if you can break things into tables or grids.  Remember, don’t make it more complicated than it needs to be.  The more complex, the less likely anyone will update it or enter it properly.

So take me advise, if you’re just starting out, do it simple.  Use excel to build it.  Thanks for reading.

Ok…  so this is a long title, but in short, here’s the situation.  I have a global Multiple Value Characteristic and it allows additional values.  For one particular KMAT that will use this characteristic, I want to have one preset option available + the free text, and exclude everything else.  In the classification, I set only the single value to be shown, but the problem is that it is automatically selected as well, and it shouldn’t be.  Since the characteristic is to allow customers to enter in free text to denote a special, I don’t want anything populated for a value unless the customer actually enters something in there.

Now, thanks to my friends at the CWG, in particular Steve Schneider, they came up with a great trick.  He gave this simple process for the Multiple Value Characteristic, and it works great.

1) Remove the multi value char from the existing class assigned to the KMAT.

2) Create a NEW class containing only the multi value char.

3) Assign the new class as a SUPERIOR class to the existing KMAT class using transaction CL24N

4) While assigning the superior\subordinate class in CL24N, double click on the multi value char and select the single value you want available.

5) Save

6) Go into CU50 and see the results… You should see NO value specified, and when you specify the multi value char, all you should see is the single value and the free text field..

It really was that easy to restrict a global Multiple Value Characteristic, and works like a charm.  Thanks Steve.