VC

Now I apologize, because the title of this post might suggest that you can actually accomplish this feat.  Unfortunately, to the best of my knowledge, you cannot dynamically change plant based on the configuration.  In my experience, this was always a no-no.  Now if anyone has actually gone down the user-exit approach and made it work, I’d be curious to hear it.  In the meantime, here are some approaches to potentially help you… or at least give you some ideas of your own to change plant for a configurable item based on the configuration.

The biggest problem is that you get to choose one plant for each sales organization to be the default.  And even using configuration, it doesn’t matter if something within the configuration can only be done in Plant 0002, but Plant 0001 can do everything else (and should).  That being the case, here’s some approaches/techniques that may help.

1.  Multiple KMAT’s.  This is probably the most common/standard approach to change plant for a configurable item.  You can have one KMAT for each different plant.  You can reuse all of the dependencies, and create new configuration profiles etc.  Now the drawback to this approach is that you have to know in advance which product you want to manufacture.

2.  Use special procurement keys on a sub-KMAT.  Here’s the idea.  Set up your main KMAT A.  In the BOM add 2 SUB-KMATS, X & Y.  X will be the standard produce here in house (whatever plant is listed on the sales order).  Y will be a KMAT with a special procurement key pointing to the other plant.  Then using object dependencies select either X or Y.  I admit, I’m pulling this one out of my ass, so if anyone knows if this does or doesn’t work, let me know.  It sounds promising, but I have my doubts it would actually work =).

3.  Material Determination – this is a handy trick that could be used to make #1 easier for the sales order entry folks.  What you could do is create something “meaningful” to the entry people, that they could type in and it pull up the second KMAT in another plant.  For example it could X – Express, would pull up the KMAT with the least number of options that would be shipped the fastest.

4.  User Exit – you could always go down the path of adding new entry into VCSD_UPDATE for werks and using User-exits, drive the plant change this way.  Like any good SAP consultant, this is always the last resort, but for my current project, this may be the way we have to go.  Based on a little online research, it appears you’d want to use the following:  VCSD_UPDATE and transfer the changed values from the configuration to the sales order:  EXIT_SAPLCEI0_001 (include fields in structure VCSD_UPDATE)  EXIT_SAPFV45S_002 (process changed field values)”

Now, all that being said…  option 2 would be the coolest way to “possibly” do it with standard SAP, but I have a feeling that #4 is only way to accomplish a change plant based on configuration.

Thanks for reading,

Lately, I’ve spent a lot of time working on the front end of my variant configuration models.  In that effort, I’ve been spending a lot of time restricting the restrictable characteristics within my model.  Whenever I focus on the front end, I tend to rely heavily on tables to restrict the characteristics.  While, this method is the best in my opinion, it certainly comes with it’s challenges in the initial setup.  Here’s a few lessons learned in my recent models.

1.  Beware of characteristic values that are restricted through classification.  While your table might be perfect, if you accidentally restricted the wrong the value, your table could give you very unexpected results.

2.  Be careful setting defaults.  Restrictable Characteristics could easily get locked in a loop if you restrict the values using constraints, and then set defaults on the characteristics that “restrict” each other.  Now, what can happen is that defaults get set on cstic A & cstic B.  A & B are used to restrict each other.  When the default gets set for A, and for B, you can only remove one default at a time, so resetting one value still leaves the other locked.  And you end up in a loop.

3.  If you use tables to restrict your values, don’t forget to include ALL the combinations.  Often I forget the values that don’t have an impact, like Without or Not Applicable.  If you don’t include these values in your table, they aren’t available and often end up setting values you didn’t expect.

There’s a couple of pointers when dealing with restrictable characteristics when you are designing the front end.

Thanks for reading,

Today I learned a simple lesson, but frankly, I should’ve known a long time ago, but never ran into this scenario.  In my current assignment, we ran into an issue in testing where an item was sales relevant was showing on the sales BOM, but wasn’t exploding it’s BOM (think of it like a kit).  Naturally, my first instinct is look into the item category and item category assignment.  Everything was on the up and up there.  Finally one of my colleagues tried the Configurable Assemblies Only check box on the configuration profile, and it magically solved our issues.

All this time, I thought that check mark only controlled what BOM VC spit out.  Until today, I never realized that the check box for configurable assemblies only also controlled how the Sales order would explode out components.  Just one more reason to never assume you know how something works, or everything it impacts.  I learned a new lesson today.  Thanks to Pat.  I must admit, I feel dumb for not finding this myself, but even the best of us have things to learn.

Thanks for reading,

Now today’s post is just  simple reminder to keep your variant configuration dependencies simple.  Lately I’ve seen a lot of dependencies that work just fine, but the logic is more complex than needed.  So here’s a couple of pointers I’ve noticed lately that should help to simplify your dependency code.

1.  If you’re using SET_PRICING_FACTOR, and it should be applied if the condition exists (for example, it’s always a factor of 2 or 4 if the condition exist), don’t add any additional logic beyond that.  The pricing factor can only be applied if the condition exists in the configuration.  You don’t need an if statement unless the pricing factor doesn’t always apply to the variant condition.

Before: (psuedo code, sorry)

$SET_PRICING_FACTOR($SELF, VAR_COND_1, 2) IF ….  (same logic that sets VAR_COND_1).
should be:
$SET_PRICING_FACTOR($SELF, VAR_COND_1, 2)

2.  If you set a default, you don’t have to delete that default if you are setting the value for that characteristic.  $DEL_DEFAULT only needs to be used if you want to remove the default and you aren’t explicitly setting the value.

3.  If your if statement has CSTIC = X, you don’t need to add if CSTIC SPECIFIED AND CSTIC = X.  It will be true if the cstic is specified already.

There’s just a few examples of ways to simplify your code and make it easier to read and maybe even improve performance.

Thanks for reading,

An old friend of mine recently emailed me about how to get the Save Temporarily feature to work in a sales order.  It had been a while since I touched that feature of VC, so I had to go back and play with it.  I remember the Save Temporarily being very “touchy”, but today I found out it was even touchier than remembered.

I’m going to keep this short, but if anyone can give me more details on exactly how this works, I’d love to hear it.  What I discovered is that I can’t seem to make the Save Temporarily work, unless the sales order already exists.  So, let me walk you through the steps I used that finally worked.

1.  Create the new sales order.  Be sure to enter everything (including the KMAT you want to populate) and then save.
2.  Go to the sales order/CU50 screen with the configuration you want to copy and open it up.
3.  Use the menu path:  Value Assignment–>Save Temporarily–>Save as
4.  Enter in a name (remember, if you have multiple levels that need to be populated, you must do a save as for each nested KMAT)
4-a.  Not sure if this is needed, but I’ve got in the habit of Value Assignment–>Save Temporarily–>Overview, just to make sure it saved it.
5.  Save the sales order. (if you are copying from a sales order/line item).  I don’t know why this seems to make a difference, but it works.
6.  Go to VA02, go to the configuration of the item you want to configure.  Use the menu:  Value Assignment–>Save Temporarily–>Overview.  Select the one you want to copy.  It should be there.

I couldn’t make this work when i used VA01, so if anyone can speak to that, let me know.  Otherwise, this approach seems to work.  Hope this helps.

Thanks for reading.

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.