SAP

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,

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).

THIS PROGRAM DOES DIRECT TABLE UPDATES AND IS FOR EMERGENCY USE ONLY!!!

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.

SELECT-OPTIONS: s_matnr FOR marc-matnr OBLIGATORY,

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’.

UPDATE marc

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

AND RETURN EXPORTING LIST TO MEMORY.

ENDIF.

 

EXIT.

 

ENDSELECT.

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,