SAP

Recently, a friend of mine came to me with a question about using a configurable material on a stock transfer order.  Now I’ve never actually tried to do this, so I had to do a little research of my own.  In my experience, the only way to accomplish this was always using a material variant.  I was going through my head, thinking of my past projects and trying to remember if I’ve encountered this before.  The closest I came to is very first job.  But there EVERYTHING was a material variant.  So that didn’t help me =)

However, when I’ve played with this at previous projects, the result always ended up the same.  Anytime you attempt to “stock” a configurable item there are always issues.  The concept of an STO is similar to a purchase order between 2 plants, only you get to skip the sales order.  The problem occurs because there is no linkage between a purchase order and supplying plant (MRP) even though you use special procurement keys.  So even though you might generate demand, you’ll have issues pulling the BOM and Routing because the configuration doesn’t get passed.

So, in general, the only way to accomplish the “stock transfer order” concept using a configurable material is to either 1.  use a material variant 2.  Create a purchase order for the configurable item in the “requesting” plant and a sales order for the same configuration in the manufacturing plant.  Neither of these options are ideal due to the amount of data that must be created on both plants.

I guess that’s the price of VC.  If anyone has a better approach, I’d love to hear it.  This certainly doesn’t seem like the best option.
Thanks for reading,

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.