VC

Well, I recently ran into a case that I needed to pull this old trick out of the archives.  It had been so long, that I needed to go to the CWG and look around to remember what it was.  It’s transaction CCUNDO. A rather handy transaction when you use VC and engineering change management together.  CCUNDO allows you to remove VC items like object dependencies, classes, characteristics, etc. from a change number.  For those of you familiar with ECM, you probably remember that you can just break the link by going into CC02.  CCUNDO allows you to select the items you need to remove from the change number, and magically, the change number link is gone.

Now, there are 2 major scenarios I use this transaction for.  The first and most common is a mistake.  I typed in the wrong change number when I went to change “X”.

The 2nd is also a mistake, but sometimes it’s a mistake from long ago.  In VC world, inevitably an object will be created without ECM, then later, an ECM gets attached to it.  Normally, this isn’t a huge deal, until you need to do something like add a new characteristic to a variant table, or change the value assignment alternatives to a table. These things can only happen when you lock everywhere the table is used.  And if you use ECM, it has to be locked throughout history.  If you created a dependency or constraint without a change number, but then added ECM later.  There will always be a date period from 00/00/0000 until the first change number was applied that you can never again touch.  Making it impossible to update that table.  Before CCUNDO, the only option was to create a brand new table and change everything over.  While this isn’t the end of the world, it sure is easier to just continue using the original table.  In this case, you use CCUNDO to remove ALL change numbers from the object, thus getting it back to a state of never being under ECM.  Then you can either delete the object and create it with ECM, or just reset it back with the latest change number.

Now one of the biggest things to keep in mind is that I do NOT encourage this to be used in production for anything other than scenario 1.  In scenario 2, you are likely to lose ALL your history on these objects.  Again, not the end of hte world, but having this history is the whole reason you use ECM.

Thanks for reading,

Well, it recently came to my attention that when it comes to testing a model, it might not be obvious to everyone some of the cool tools available within in CU50.  While the seasoned veteran may find this obvious, as you learn VC there are always tricks that can make your life easier.  Today’s post is no exception.  Today we’re going to talk about the configured objects button with in CU50.  I’ll confess, this was a button that I knew little about for some time.  But of late, this has become one of the most useful testing tools when sales orders/production orders are generated.

Now, if you don’t recognize the name of the button, this screenshot should refresh your memory, even if you never knew what the button did :).

Now, this little feature is outstanding.  You can enter in a sales order or production order (material is for material variants, but you don’t need to enter this screen to see those.).  By entering this information into this screen, CU50 will bring in the complete configuration from the document, in this instance the sales order.

As soon as you hit enter, the standard CU50 screen will return, but you now get an extra Copy from: section to show you exactly what you’re copying from.

Once you enter the configuration screen, you can see all the characteristic values populated.  Now, this is especially valuable when dealing with sales relevant and production relevant items in the same BOM.  You also have the ability to see the configured routing.

While you can see bits and pieces by looking at the sales order, you often must see both a sales order and production order to see the entire picture.  CU50 gives you everything, and now you don’t even need to copy each and every value.

Hope you find this valuable and thanks for reading,

I’ve recently run into a strange issue when I ALE constraints with ECM.  I’ve been finding that in some situations, the constraints are properly sent to the target system, the syntax check out, but for some reason, they never fire.  No good explanation of why.  I feel like this happened to me in the past, but I’m guessing I never got a good explanation then either, since I don’t see anything in my notes.

The only work around I’ve found for this issue is to make a simple change (can even just be a comment or a space) and save it in the source system.  Then go back to CUK2 and ALE it again to the target system using the latest change number.

Suddenly, after doing this, the constraint fires again with no issues.  If you’ve seen this issue in the past, and can explain why it happens, please comment.  I’d love to know the underlying issue behind this, so I can at least understand why it happens =)

thanks for reading,

I recently ran into a minor little glitch when I needed to ALE Classes with change numbers.  It’s interesting, because the header of the class behaves differently than you would expect.  For example, if you pull up any class type 200 or 300, there is a valid from date that is automatically defaulted as today’s date.  Now, normally, this makes no difference.  However, when you’re in the midst of transferring models to a new system that is under engineering change management, you could begin using a change number with a date that is effective BEFORE the valid from date of the class.

So, here’s what happens.  Your class has a valid from date of today.  Your ECM has a valid date of yesterday.  When you transfer the classes with ALE, it will move the general tab (description, valid from date, etc.) and it will NOT be under engineering change management.  Now, the ALE will fail at the characteristics because those are under engineering change management AND the class valid from date is set in the future of the ECM date…  follow me so far???

Well, after all of this, there is a simple fix.  In your target/source system, simply change the valid from date of the class you are having issues with.  Remember, to make this change, you don’t need a change number.  You can simply change the date, and reprocess your IDOC’s.  Problem solved.

Thanks for reading,

Recently, I was reminded of one of the biggest downfalls of using class type 200 within a VC BOM.  The is the inability to track the changes using ECM.  This got me to thinking about the differences between the approaches of Class Type 200 vs. Phantom KMATs.  While both methods cwill ultimately get you to the same place, there are very obvious differences between the 2 methods.  In general, both approaches are very valuable, but each has pros and cons.  So let’s talk a little about the differences…

Let me define what I mean by a phantom KMAT.  This is simply another KMAT that sits on the top level BOM.  So this turns into nested KMAT’s, but often there is no configuration that occurs on the phantom level.  It is more of a BOM grouping, with pass through values (if could be configured, but for our purposes today, consider it just a group of parts).  You simply create a KMAT, say Hard Drive, that contains all of the possible hard drives you wish to use.  Then you add the selection condition to each component, set the Material master of the HARD DRIVE KMAT to be a phantom and you’re ready to go.

The first major difference is the change management aspects.  Because of the way the class type 200 works, you can’t add or change materials using Engineering Change Management.  For many organizations, this can be a show stopper.  The convenience of not creating selection conditions for each material, but simply adding characteristic values can be tempting…  but if your organization needs to do a lot of obsolete and supersceding of components, class type 200’s can be a major obstacle.  Now the Phantom KMAT will not have this issue.  But, the price is creating a selection condition for each material on the BOM, and also using a constraint to pass the values from the parent to the child KMAT.  You may also need to create a class for each Phantom KMAT that only holds the characteristics needed for those components, or you could reuse the entire class.  Either way, it can be more overhead.

Reuse of the items.  This is the place that both methods work great at.  Now, one of my favorite things to do is create generic KMAT’s that can be used across multiple product lines.  In my first VC job, we did a lot cables with 35 or more different connectors that can be used.  Well, since the same components were often used across multiple product lines, I could create a single phantom KMAT and use it on multiple top level KMAT’s.  the Obvious value is maintaining changes in one spot.  the hardest part of this method is thinking far enough ahead to make it useful.  Now you can do the same thing with class type 200’s as well.  So both methods are great for this.

A single component vs. as many as you need.  Now another obvious drawback to class type 200’s is the limitation of only being able to select a single part number.  If you had multiple part numbers, you would need multiple classes to select all the components.  Within a phantom KMAT, depending on your selection conditions, you could select as many as you need.

So far, everything seems in favor of the phantom KMAT, but here’s one that is big benefit to the class type 200.  If you work in an environment where parts change often, new options are constantly added, or perhaps you engineer as you need something…  well, the class type 200 can be set to required.  this means that your sales order will show as incomplete if the class doesn’t find a material.  Phantom KMAT’s don’t have an easy way to accomplish the same thing.

Now there are other pro’s and con’s, but in my experience, these are the 4 biggest features to keep in mind.  I’d love to hear your comments.  Thanks for reading,

Today, I’m going to talk a little bit about the “theory” of variant configuration.  I use the term loosely, because, well, everyone has their own theory.  I guess that’s why it isn’t a law 🙂  One of the struggles I encounter over and over again is clients that want to use the variant configurator to handle 100% of the options for a product.  Without a doubt, the first place I learned VC was still one of the most solid implementations I’ve ever seen.  But ever there, the line would occasionally get blurred.

Let me walk you through what I mean.  Whenever I walk into a VC project, I go in with the expectation of being able to handle 80% of the product options.  Some places more, some less, but it all depends on the complexity.  For example, let’s just say you have an option that is order twice a year, but it works like everything else.  It’s just a simple option, no complex logic, so in my mind, it’s a no brainer, add it and probably never sell it, but life isn’t any harder from a maintenance perspective.

Now, we take the flip side.  We have an option that gets order let’s just say 12 times a year.  But this option has a lot of extra rules built around when it can be picked, what it can be used with, complicated BOM components dependent on multiple things.  Well, now what do you say?  if it’s me, I try to push back saying it should be a special.  What’s a special Mike???  Well, very simple.  It’s a standard part number in the system, you can even copy the BOM rules from VC to get everything else right.  But you keep that stuff out of the VC.  “But why?  VC can handle it?”

While that statement is technically true, VC can handle most anything.  What becomes the defining factor is the increased logic that all the simple things now have to work around, along with the time to “decipher” what is happening every time a new option gets added, or something simple changes.  That costs time, money, and even processing speed.  For a “possible” 12 orders, that just as easily could have become standard part numbers.

Now everyone will take their own stance on this, and everyone is probably right…  for their scenario.  I’m just telling you from my standpoint, specials should be special…  standards should be VC 🙂

Thanks for reading,