Home / SAP / Archive by category "VC"

Variant Configuration – My 6th E-Book

It’s hard to imagine that I’ve written 6 books now.  While the formatting portion is getting manageable, I certainly won’t say it comes easy to me.  However, it is very satisfying when I finally finish it and see that people are buying it.

My latest book has gone away from Service Management, and instead goes into my other SAP passion of Variant Configuration.  Yes, SAP Press has a book out about Variant Configuration, and I’m sure it is good.  But what I really wanted to do was put together a book that helps you model.  So this book, like my others, goes into all the nuts and bolts of each different screen and transaction.  But the real value, I think, is that I focus a lot on HOW to build up that model.  In my years of SAP, it’s easy enough to look at google, or do some trial and error.  But there was never a reference that would help me pick the best method…  there is also nothing out there that I’ve found that tells you to expect to model the same product multiple times.  ha ha ha.  If any of you have modeled in VC, you know this is often true.

Anyway, I hope you check it out.  If you do, please let me know what you think.

SAP Variant Configuration: Your Successful Guide to Modeling

Thanks for reading,

Variant Configuration – Characteristic Value Hierarchy

I recently discovered a fun fact with a characteristic.  In all my years, I had never noticed this fun little feature.  Not sure I would use it a lot, but it certainly could have some interesting benefits.  Within the Characteristic value screen, you can add values to a lower level.

Notice the the check mark on A06 under the S column.  Subordinate Values Exist.

If you press:  to see the next level of the hierarchy.

Now you can see the values at the next level down.  You can continue to build multiple levels down, or simply stop here and go back up a level.  

To see the complete hierarchy, press 

This will show you the full hierarchy.

Now, if you want to see this in action, check out the simulator:

I did the drop down for BK_ACCY, and here you can see that you get the option of all the values in the hierarchy.  This can be an interesting way to break up large characteristic value sets.

Thanks for reading,

Variant Config – Limited Numeric Characteristics

I recently “re-discovered” this this when I was trying to build a model that limited the values within a numeric characteristic.  I created a Cstic that had the following values:


It seemed pretty straightforward.  Then I wanted to set the value = 0 if a different cstic was equal to No, and have it be greater than 1, if it was equal to Yes.  Seemed so easy.  I tried all sorts of variations of my code, but even in the trace it would say the inference was scheduled, but it would never do anything 🙁

I finally changed the values to be:



and used the same logic.  Like magic, it did my restrictions.  So it turns out that restricting a range doesn’t work so well, so if you run into a similar issue, break your values into individual pieces.  Now, this isn’t ideal for everything, but if you have integers, this approach can work.

Thanks for reading,

Variant Configuration – S/4 and IPC

I recently found an interesting discovery.  The new platform of SAP S/4 will no longer support the IPC.  I this very interesting as SAP has spent so much time and effort to build this better platform, but currently according to OSS, there is no plan to integrate it.  If any of you out there have heard the plan in the CWG, please let me know.

The concept is that since IPC is java based, and HANA/S/4 have no concept of Java…  so it means that within S/4 you cannot select a configurable material and make it IPC to look nicer.

Would love to hear any input on this, I was certainly disappointed.

Thanks for reading,

Variant Configuration – Fear of Material Variants

It’s interesting to me how much fear and concern exist around material variants.  Perhaps I’ve spent too much time with them, and that’s why I have no fear (much like how a snake charmer isn’t afraid of the snake…  they just have a healthy respect for it 😀 ).  I wanted to chat a bit about what you do and don’t need to worry about when it comes to material variants.  I’ve seen the full spectrum in my career, so like that snake charmer, respect MV’s, don’t fear them

First off, don’t make MV’s for everything.  My very first VC job was back in version 3.0F.  In those days, there was no good solution to handle returns, restocking, etc…  So rather than wait for SAP to fix the issues, we developed the a function within the configurator to create a fully usable MV within a minute or two.  This was the process we used for everything that was configurable.  And it worked fine.  The concept was that if modeled everything correctly, there was no reason it could not be instantly costed and assigned all the relevant master data in the background.  This approached solved all the issues on the sales side of things.  Now, the complications came on the engineering side of things.  Within a year or two, we were in the 100,000’s of MV’s.  This meant that each time something changed, all the MV’s needed to be changed as well.  This might be a simple revision to the part, or might be a full fledged configuration change (which required a refresh of the configuration within every material master).  This process quickly become overwhelming.  Especially when massive changes where required that dealt with ECM and complex date shifting.  YUCK. This taught me to respect MV’s…  but also to appreciate them.

See, even today, returning a VC part isn’t easy, and if you want to return it to stock,  you have to use an MV anyway.  The short story is that you can’t do business without them.  The important thing to realize is to NOT overuse them.

Now, on the flip side, I recently uncounted a client that needed configurable materials on a service order.  SAP didn’t design for this, so you simply get the error you can’t use a configurable material as a component on a service order.  Now, this to me is a perfect use for a simple program to create an MV, handle all the BOM, routing, costing and material master, then drop the material on your order a minute later and go on your merry way.  This was not a high volume service shop that would be generating thousands of MV’s a month, and the configurations were very simple, this was a perfect use for an MV.  You may have read some posts about this a few months back.  In general, there is no good way to handle this.  You can do the purchased part (generate a req back to yourself, make a sales order to add the configurable part and so on), you could create a production order for a dummy part, then add the configurable material onto it’s BOM (creating lots of production variance… probably 100%), or you could use an MV.

My advise, respect the MV and don’t go overboard.  However, don’t be afraid if you need to make a few hundred per year.

Thanks for reading,

Variant Configuration – Disassociate Material Variants

This is a fun little trick, that I will probably never use.  This came from my friend Rama.  If you’re like me, when you create material variants, I’m sure you wondered why you cannot disconnect the materials from the KMAT.  For some reason, this field becomes locked as soon you save the material.  In my normal process, I tell businesses to obsolete the material if they screwed it up, assigned the wrong KMAT or just want it to no longer be connected.  Well, it seems that SAP has come up with a  process to disassociate the material from the KMAT.

OSS Note 941004 – FAQ: Configurable materials and Variants in Configuration
Topic 1.  (so this is the SAP “Approved” method to handle this).


1) Use SE16 to edit the MARC record in the database.  Change the STDPD to the new KMAT and change the CUOBJ to zero.


2) Run the RCU_DEL_CONF_FOR_ARCHMATVAR program to delete the instance from the CBase


3) Edit the material master and maintain the material variant configuration


OF COURSE you must be careful to avoid creating database inconsistencies


ALSO, if there are any existing sales orders for the material variant, then the CUOBJ for those line items must be changed in the database from the old cuobj (of the mv) to the new cuobj (of the mv).  After that, it is necessary to update the pricing for




REPORT zlogic_mv_change_kmat NO STANDARD PAGE HEADING.


* Declare variables

DATA: lt_marc type marc occurs 0 with header line.


s_werks FOR marc-werks.

PARAMETERS:     p_stdpd LIKE marc-stdpd.


* Select material variants to change the KMAT

SELECT * FROM marc into table lt_marc

WHERE matnr IN s_matnr AND werks IN s_werks and stdpd ne space.




WRITE:/ marc-stdpd, marc-cuobj.


IF p_update = ‘x’ OR p_update = ‘X’.


SET stdpd = p_stdpd

cuobj = 0

WHERE matnr = marc-matnr

AND werks = marc-werks.


SUBMIT rcu_del_conf_for_archmatvar

WITH matnum = marc-matnr

WITH testmode = space







Now, for my disclaimer.  While this is a nice trick, I still most likely won’t use this myself.  The process I preach is to disassociate the material number in SAP from any logic, or any reason to worry enough about 1 exact number to go through this hassle.  Make your materials internal only, so they mean nothing to customers, distributors, vendors, etc…  if you do this, you never need to do DB updates to fix things.  Thanks my opinion.

thanks for reading,

Variant Configuration – Class Additional Data

My friend Rama recently asked me a question about the additional data tab on the Class (CL02) screen.  For some classes he could see it, for other he couldn’t.  I was stumped.  Every system I’ve worked in had it available for class type 300.  Well, luckily, he passed on a little tidbit of information that I wanted to pass onto you.

in SPRO, go to Cross-Application Components–>Classification System–>Classes–>Maintain Object Types and Class Types.

Once you get in there select MARA, then double click on Class types.

Highlight class type 300 and go into the details.


Once you get in, you should see this screen.  If you want the additional data tab in your class, make sure that Class node is checked.

thanks for reading,

Variant Configuration – ETO and STO

Well, an old friend of mine recently pinged me with a question.  The idea was how do I get my bill of material in the producing plant, if my ordering plant is in another company code.  So plant A orders the configurable product, and plant B builds it.  Plant A & B are in different company codes so you an STO is needed.  The problem is that out of the box, the order BOM for the product exists in the ordering plant.  But since it’s Engineer to Order, the BOM really needs to exist in the producing plant.

Luckily, my buddy Rama happened to have the answer for me.  It turns out, there are a couple of OSS notes that take care of this.

494500 & 691267 will tell CU51 (order bom maintenace) to look at the special procurement key and create the BOM, rather than in the ordering plant.

in addition, here’s a good link that has a lot of VC OSS tricks 🙂

SAP Notes

Thanks for reading,

Service Management – Configurable Leading Service Orders

Well, after I learned about how cool it was to combine service management and variant configuration, I did some posts a while ago, talking about exactly how it worked.  If you missed those, check them out here.  Well, there was still one gap that I couldn’t get to work.  I tend to use service with a “leading service material”, while the alternative is a “leading serviceable material”.  Well, it turns out that only leading serviceable materials can work out of the box with VC.  I worked with OSS for a couple weeks on this…  only to have it get kicked high enough up the chain to tell me “works as designed”.  However, they were nice enough to give me the standard user-exit that can be used to make it work.  So I thought I”d share that with you today.

Generally, please be aware that in a Standard repair process with
leading serviceable material, the configuration data, i.e. CUOBJ, is
only copied from the main item to the returns sub item. This is
controlled via the following coding:

* for RMA return subitem (leading serviceable material) fill cuobj from * main item and fix the configuration (like in normal copy process)
if vbap-vkgru eq vkgru_rep_retoure and
vbak-vbklt eq vbklt_repa_auft.
vbap-cuobj = hvbap-cuobj.
perform configuration_fix(sapfv45s).

If you want the CUOBJ also to be copied to other sub items in the
repair order, you would have to implement a modification in

if vbak-vbklt eq vbklt_repa_auft.
if vbap-vkgru eq vkgru_rep_gutschrift or
vbap-vkgru eq vkgru_rep_austauschteil or
vbap-vkgru eq vkgru_rep_auslieferung.
vbap-cuobj = hvbap-cuobj.
perform configuration_fix(sapfv45s).

The constants for the item classifications are defined as follows
vkgru_rep_retoure       LIKE vbap-vkgru VALUE ‘101’,
vkgru_rep_reparatur     LIKE vbap-vkgru VALUE ‘102’,
vkgru_rep_auslieferung  LIKE vbap-vkgru VALUE ‘103’,
vkgru_rep_leihgeraetbes LIKE vbap-vkgru VALUE ‘104’,
vkgru_rep_leihgeraetabh LIKE vbap-vkgru VALUE ‘105’,
vkgru_rep_austauschteil LIKE vbap-vkgru VALUE ‘106’,
vkgru_rep_verschrottung LIKE vbap-vkgru VALUE ‘107’,
vkgru_rep_gutschrift    LIKE vbap-vkgru VALUE ‘108’,
vkgru_rep_lastschrift   LIKE vbap-vkgru VALUE ‘109’,
so if you want the configuration to be copied into sub items of types
other the returns/101, you would need to adjust the userexit code

Hope this might be helpful to you.  I’ll actually be fully documenting the configuration of this process (and I’ll include this code again) in my upcoming E-book on configuring service management.  It’s been a beast writing this book, so when it comes out, I’ll be pretty excited.  If you’re interested in a copy, let me know 🙂

Thanks for reading,