The Service Management Experts
Menu

VC

Home / SAP / Archive by category "VC" (Page 10)

Variant Configuration – Passing Values between Nested KMATS

In this age, having a model without nested KMATs (multi-level configuration) is a thing of the past.  Because of that, I wanted to do a quick post about transferring values between the different levels of the bill of material structure.  There are 2 methods to accomplish this (at least using the standard ERP functionality).

1.  Procedure:  $SELF.X = $PARENT.X  or $SELF.X = $ROOT.X

2.  Constraint:
Object:
mod1 is_a(300)  mod,
mod2 is_a(300) mod,
Assy is_a(300) mod_component

Condition:
part_of (Assy, mod1, ‘0100’) or
part_of (Assy, mod2, ‘0100’)

Restricitons:
Assy.X = mod1.X,
Assy.X = mod2.X

Inferences:
mod1.X,
mod2.X

This rule is a very generic way to show you how to pass values down to a lower level cstic.  This variation goes one step further and actually checks to make sure that the nested KMAT is a at certain position in the bill of material.  This is not required, but can be very handy if is the same class exists in multiple positions in the BOM.  Notice, we copied down, but you could just as easily copy back up by reversing the restriction.  While not a common practice, the option is still there.

You’ll notice that the first method is far more simple, and will do the trick.  the constraint is more complicated to write, but has more power.  Personally, I’m a constraint kinda guy, so I tend to use that method.  But you need to use what fits your situation best.

Now, whenever you need to transfer characteristics between levels, you NEED to test early on in the process how it behaves in a sales order, planned order, production order and sales order costing.  Many times the behavior that works great in CU50, doesn’t translate the same way in a production order.  You may have assign the constraint/procedure at a different configurable material in order to get the rules to fire in all scenarios.

Happy configuring.

Remember, if there is anything we can do to help, please click the contact us button at the top of this page.

Mike

Variant Configuration – Value Comparison

Now, this topic is related to my last post.  Specifically, when you have a material variant that you need to transfer the stock from a return.  Often there are characteristics that should not be included when you are doing a value comparison of a configuration for a material variant or a serial number.  An example of this is a reference characteristic.

However, there can be other characteristics that are based on a reference characteristic that should also be ignored when you are attaching a serial number or performing type matching.  In order to set any characteristic to be excluded from the check, you can use the following program:

RCU_EXCL_CHARACTERISTICS

Simply enter in the characteristics that should be ignored (You can even make it specific to

just one material)

this is a pretty useful program to determine what should be considered when doing a value comparison, and don’t be surprised if you need to keep running it every time you get a new return for a while.  Just because different cstics will pop up based on what you’re returning.  Either way, this is great for material variants/variant matching, and an absolute requirement for stock transferring.

I encourage you to check it out.

Have fun…

As always, if you are you interested in more help, please contact us and let us know what we can do for you.

Mike

Variant Configuration – Return Configurable Materials

I’ve been a roll with VC for the blogs, so I’m gonna keep going with it (besides, I’ve been pouring all my SM knowledge into the SM E-course).  Today I want to talk about the configuration needed to handle return configurable materials.  I’m also going to talk a little about the processes you’ll need to consider when you decide to accept configurable returns.

First, the easy part.  the configuration is pretty straight forward.  Most of the work is already done for you out of the box.  The item category REC is meant for configurable materials.  The one major change that I encourage is in the item category configuration.  Being a purest, I’ll always encourage you to copy it and make a ZREC, but that’s your call.  The one field that I change is the Special Stock Indicator.  Why you may ask?  If you don’t set this, when you attempt to do your Post Good Receipt on the configurable item if you don’t change this to be E, you won’t get stock back in the system.  Rather, you will get a confirmation of service when you receive this.  Me, I’m a fan of knowing exactly what is coming into my plant.  In addition, I might be able to strip this part down for components, or maybe even resell it.  What this means is that when you receive the item in, it will be sales order stock for your return sales order.

This brings me to the process process portion of the VC return.  Now in order to use this, you will need to do some material movements.  I’m not going into a MIGO lesson here, but you need to know that you must either issue this directly from the sales order ot another sales order, or you might even need to create a material variant and then transfer the stock.  I’ll talk more about the material variant process in another post…  Anyway, returns in VC can be complicated.  Be sure you’re aware of the process cost.  If your product is cheap enough, it could be worth it to leave the settings as they are, and just throw the item away as soon as it arrives.

Anyway, more to come on VC returns, but this will get you started,

Remember, if you need VC or SM help, please contact me and let me know how I can assist you.

Thanks,

Mike

Variant Configuration – Requirement Types

Well, today is a quick lesson that I just relearned.  When you are configuring the sales order/item category for a variant configuration item, one of the big things you have to configure is the requirement types.  Now there are some standard ones, but based on what you need, you’ll probably still tweak.

So let’s start at the beginning… where do you configure this?
Txn: SPRO  Sales and Distribution–>Basic Functions–>Availability Check and Transfer of Requirements–>transfer of requirements

In here, the first 3 pieces are what you generally need to be concerned with.  All the real work happens in the define requirements Classes step.  In here, you can define if the order generates a planned order, a production order, a service order, can it take configuration? the screen shot below shows you the full assortment of items you can control.  Ultimately, you will need to use trial and error to fit your business.  the screen shot is for the standard 040, which works for configurable items.  Certain things like the accounting section will need input from your FICO team, but out of the box, this one will work for you.

Now, once you’ve created or modified your requirement, you’ll need to create the requirement class.  I personally think this step is silly, but you have to do it.  I’ll usually name the class the same as the requirement, but do whatever you like.

Now for the last step.  Assign the requirement to your item category.  use the configuration:  Determination of Requirements Types using Transaction.

Use the search to find your VC item category.  In the second column enter in your requirements class.  Now, the last and final piece, put a 1 in the third column.  This is a subtle thing, but it tells configuration to follow the requirements settings in your sales order, not in the material master.  If you don’t put the 1 in there, you could spin your wheels for a while (like I just did) trying to figure out why it’s ignoring your Sd settings.  Anyway, that’s your tip of the day…

As always, I’m learning the hard way so you don’t have to =)

If you’re in need of consulting or SAP Add-in applications, please don’t hesitate to contact us.  We’ll soon be releasing several new VC applications, including a history report.

thanks for reading,

Mike

 

Variant Configuration – Pricing Descriptions of variant conditions using VK30

Just a short one for today =)  here’s a little trick for anyone new to variant configuration pricing.  When you use VA00 (or something similar) for your variant conditions the business sees your cryptic variant condition names.  if you go into transaction VK30, you can give it a a more meaningful name that will show up on the sales orders.  The one drawback is that you cannot have different descriptions by language.  Regardless, this will still allow you to provide a little more meaningful description to your sales order entry group.

Thanks a lot,

Mike

Variant Configuration – Pricing dependency Group

If you’ve been doing VC for a while, you might remember the days when nothing worked without an OSS note, performance was terrible, and it took discipline to build a model that would work for sales and manufacturing.  I remember those days fondly.  Well, pricing was no different.  That’s why I wanted to put this quick tip out there for you.  If you do variant pricing, a way to improve your performance is using the dependency group :  SAP_PRICNG  (no, I didn’t misspell pricing.  ha ha ha).  You simply need to add this into configuration.
SPRO–>Logistics General–>Variant Configuration–>Dependencies–>Define Groups

Once you add this dependency group, be sure to add this to all of your pricing object dependencies.  What this will do is it will only fire the dependency if you call for pricing.  Of course, this will depend on your configuration profile settings as well, but it does give you the opportunity to improve your performance.
Hope you find this useful,

As always, if you need any help in Variant Configuration or you are looking for some great applications to make your SAP life easier, please let me know.

thanks,

Mike

Variant Configuration – CWG – The Group in the know

Since, I recently attended  (and even presented at) the CWG conference in Marco Island, I figured this would be a good time to let you know about the group.  The CWG, or Configurator WorkGroup, is THE group if you do anything with Variant Configuration.  This group focuses on variant configuration, configure to order, engineer to order, and pretty much anything that has to do with being able to dynamically configure a product based on a set of rules.

http://configuration-workgroup.com/

If you’re not part of the CWG, I highly encourage you to get registered.  It’s free, and without a doubt, it has the most complete forum of VC related questions.  If you can’t find an answer here, make a post and it’s likely someone will have an idea that can solve your problem.

About my only complaint with the conference is that it tends to focuses heavily on the IPC (internet pricing and configuration), which is the web based/CRM based version of the variant configurator.  That’s not a bad thing, but there are a lot of us that care about the ERP based engine.  The conference this time around actually was good, because there was nearly a day of ETO/Specials processing in VC.  All of presentations are online from the past 10 years or so.

short story, I encourage you to involved… or check it out if you haven’t been there in a while…

good luck

Variant Configuration – Keep BOM Dependencies Simple

Having just gone to the CWG (configurator workgroup) for the first time in many years, I was reminded of my most famous story.  My friend Barry Scott Walton even told the story in his presentation.  He was nice enough to remove the names, to protect the guilty.  Some of you probably even remember this story…  It’s not the peanut butter piehl story, but perhaps I’ll share that one too someday…  This was the story of how Mike Piehl shut down MRP because I used very complicated BOM dependencies.

This was back when I worked for ADC Telecommunications and there was a mad scramble to get all of our CTO product lines converted onto to SAP before the dreaded Y2K.  Well, I was frantically working on product lines, and of course pushing the envelope, because no one ever said not to.  ha ha ha.  It all started on Wed.  I still remember grumblings of MRP being really slow, and wondering if I had done anything.  At the time, I couldn’t think of anything I did…  thursday came, the same issues were still occurring.  Then Friday, it became critical.  MRP hadn’t finished in 3 days, and no one seemed to know why.  After lots of digging, working with planning, IT, and even calling SAP’s platinum hotline, we narrowed down the issue.  We had created about 30 material variants and added a forecast to them.  In a normal world, this wouldn’t have been an issue.  But in my design, I used every tool I could in the BOM to make things work.  Well, my design was spot on.  The problem, which Barry later explained to me, was that MRP doesn’t read complex dependencies in the Bill of Material well.  And when I had a bunch of material variants, all with these complex rules, and then it read them over and over and over (because of the forecast)…  well, let’s just say, I become famous.

As soon as Barry explained the MRP issue (which in my defense was never documented anywhere in SAP), I quickly found a work around to get me by until I could rework all of the selection conditions.  I moved my variant table to a database table.  Now, I do not recommend this approach because you lose the tracability, but we had to do something quickly, and this gave us back the performance to get MRP running again (and still forecast those 30 parts).

The work took significantly longer, because I pulled all of the complex logic out of the selection condition, and moved it to the configuration profile.  This meant more characteristics at the top level, but the trade-off was well worth it.

To this day, I encourage all of my clients to keep it REALLY simple in the BOM.  SAP has done better in adapting MRP to handle variant configuration rules better.  But, in my opinion, you want the configuration profile to do all of the heavy lifting anyway, so this approach won’t steer you wrong.

Anway, learn from my experience…  Keep your BOM rules simple…  don’t add tables, don’t do complicated calculations…  just do simple assignments.  You’ll thank me later =)

Mike

Variant Configuration – ETO CWG Tips

Here’s some quick ETO tips I got at the CWG that I didn’t want to forget.

If you are dealing with an engineering special or ETO configuration, you could use output determination to send an email to a group of engineers.  The drawback to this approach is that you need to know it’s a special in advance.  Much more difficult to use if it might be std or might be special.

In addition, the functions starting with CAVC allow you to build your own order bom workbench.  If you wanted to build your own CU51 or OEWB, you could use the functions to design your own transaction.

 

Remember, if you need more in depth VC help, please contact us,

Thanks,

Mike

Variant Configuration Availability Checking – What you might not realize

I’ve been doing Variant Configuration for the majority of my “professional” career.  I learned something in a recent project that I somehow missed up until now.  Sales Order Availability checking for Make-To-Order items has some major limitations.  Let me start by explaining the setup and what we ran into in a recent client of mine when we attempted to use Variant Configuration Availability Checking.

We were creating a reasonably complex VC model and placing it into the sale order.  We were generating an Assemble-To-Order production order directly from the sales order (skipped the planned order step).  Now to further complicate things, we were also using collective orders inside of the VC bill of material structure.  None of these things by them self were that far out there, but it was the first time I’d ever done all of them together.

SAP provides a program, SDV03V10 as an availability checking program.  I found this through some OSS notes and eventually started playing with it.  The functionality worked alright, so we went live with it.  What we quickly discovered after go-live is that orders just weren’t being pulled into early dates.  It quickly became apparent that the MTO availability program ran one line item at a time.  During unit testing, not problem, but suddenly there were many VC line items on the same sales order (or possibly even standard items).  Well, the availability programs don’t exactly play well with eachother.  Below are the conditions we discovered.

  • The standard V_v2 will not pick up any MTO items.  It automatically excludes them from the program selection.  So now this program will only work on standard items.
  • The SDV03V10 program  only executes one sales order line item.
  • Sales order are often complete delivery

This “perfect storm” cause nothing to be rescheduled automatically.  If you are not picking up the pattern, don’t feel bad, it took 3 of us to finally pull this all together.  So, here’s an example:

Sales order 1 has the following items: The original promise dates are shown first.
10           STD1      qty: 1                     Date: 12/12/2012
20           MTO1    qty:1                      Date:12/12/2012

The sales order is complete delivery.
Now there are some inventory changes that make the availability of item 10 to be 11/15/2012 and item 20: 11/20/2012.
if you run V_V2, it will run against the order, but because it is complete delivery and there is an MTO item, it can’t reschedule it earlier than 12/12/2012.  Now if you run the SDV03V10 (or any variation of this), the exact same thing will happen.  This will leave you in a loop where nothing reschedules unless you go into the order and run a ATP check of all items.

After finding this, I decided that JaveLLin Solutions, LLC should design a new program that will mimic the complete ATP check.  If you think this is something you could use, please contact me.

Thanks for reading,

Mike