Variant Configuration – Requirement Types

01NovJune 27, 2016

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 – BOM Class Nodes

31OctJune 27, 2016

Happy Halloween,

I hope you consider this a treat, and not a trick =) Today I wanted to talk a little about using class nodes in a variant bill of material. In the old days, this was using class type 200, however, you are no longer constrained to using just 200, you can use 300 as well. This is a handy method to dynamically add materials to a variant bill of material. I’ll start with the how…

First, create yourself a class type 200 or 300, and be sure on the additional data that you check the following fields.

All of the fields are self explanatory, so I’m not going into a lot of details (please comment if you’d like more info). The really important field is the first check box. This will allow you to add it to the BOM. The remaining fields will set some defaults for your and the additional behavior.

Once you have this class add, you need to make sure that the characteristic is either included in the your parent configuration (and is passed to your bom class node ) or is set using an object dependency at the BOM level.

Once you have this, you just need to attach the materials that can be selected using this class. I prefer transaction CL24N to add the materails, but there are multiple ways to connect the material to the class using the standard classification transactions. The important thing is that each material you enter needs to have the characteristic values set manually in CL24N. This is how the system knows which material to replace the class node with.

Hopefully this all makes sense, because the part of the post I really want to talk about is some things to be aware of when using bill of material class nodes. The first is change management. If you use ECM to control your variant configuration bill of material, this method completely circumvents that process. Using the class nodes, you can link and unlink materials with no ECM record. So you must be aware of the loss of traceability when using this approach. The second topic is that if you commonly obsolete and superscede materials in your bill of materials, finding where the materials are used can be a challenge as well. The where-used for class types works, but if you are using CS15, you must remember to check the Class checkmark. So if whomever is running the where used isn’t familiar that the part is used in VC class nodes, it could be easy to overlook when doing a replacement part. This could lead to inaccurate BOM’s and confusion on the floor. THis segways into the whole phasing out of a component on a bill of material. If for example, you have a component that you will be replacing, but still have 50 pieces in stock that you would like to use up. Managing the class type and when to change to the new component will be very manual and must be done at the right time by someone monitoring the stock. it won’t be as simple as the rest of the boms that will be changed automatically using date shifting the of the ECO.

Now, despite this items, it has some very good features. The first features is the required component. This is especially useful if you have order boms. this is will quickly notify you if the class node failed to find a component (but only if you check the required box, see above). If you use just selection conditions, you won’t get the easy visibility that component didn’t get picked that you were expecting. The second cool feature, again related to order boms, is that you can manually find an item for a class node and replace it. So if there is a component that is close, but normally used, you can manually select it from the list and pull it into your BOM. this can be especially useful if you have multiple options for a single part, and you manage the part by your stock levels. Someone can quickly evaluate which part you in stock, and switch the class node to that part (making your promise date look much better => ).

Well, I hope this was a treat for you… if not, well, I’ll try better for next year,

As always if you need more in depth help, we offer consulting to help you streamline your VC processes,

thanks for reading,

mike

Variant Configuration – Pricing Descriptions of variant conditions using VK30

30OctJune 27, 2016

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

29OctJune 27, 2016

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

26OctJune 27, 2016

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

24OctJune 27, 2016

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

19OctJune 27, 2016

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

15OctJune 27, 2016

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

VC – Moving a product line with ALE

29JunJune 27, 2016

Alright, today I’m switching gears. For those of you that know me, you’ll know that VC is actually my first job in SAP, so I still hold a fondness for everything variant configuration related. I recently helped out a client to move a product line from one system to another, so I thought I’d share it with all of you how we used ALE to accomplish this.

Now let me begin by saying I’m not a basis person, I only know enough to be dangerous. So, in order to initially get ALE up and running, work with your basis team. They need to set the EDI partners, and all of the object types. Some of it may also be trial and error the first time. Simply because SAP provides multiple options for the same object, and some options only work with certain processes. If there’s interest, I can do more homework and go into this on another post. For today, I’m going to assume your ALE connections are properly setup.

Moving all of the VC master data is no small feat. When I first started in 3.0F, there was no ALE, so we actually wrote ABAP to do uploads and downloads to other systems. ALE is much easier and much faster. Like everything in VC, there is a process a certain order to things, so I’m going to run down those right now.

About this guide: All of the fields you need to be concerned with are listed below in the screen shots. Every one of the transactions contains the field Logical system. I will refer to that as the Target system. In addition, most screens contain a field for Engineering Change Number. Below, I define these fields. It is up to you determine if you should be populating the ECM field, and you must work with your basis person if you are not sure the correct value to use for the Logical System.

Target System: The SAP system you wish to populate. Please note, your basis person must creating/maintain the ALE system.

Engineering Change Management (ECM): Your VC modeling may or may not include engineering change numbers. I encourage all clients to use ECM due to the high level of maintenance required. In order to transfer most pieces of a VC model with engineering change management using ALE, you must maintain ECM in all systems, including the development system.

Note: For All screens, you can often use the wild card, if you maintained a standard naming convention. in that event, simply enter XYZ* to capture all product line specific data.

Engineering Change Management:

TXN: CC92

For the ECM number you have 2 options depending on your system setup.

Typically, most companies will create the change number in their production system, then move that ECM to other system. In that event, execute CC92 in the production system, and logical system will be the development or QA system. This, by the way, is my recommended way of doing things.

You can also use a Push system, if you wish to have your ECM driven from the test system. Usually, this would require a unique ECM number range specific to VC, but it can be accomplished.

Characteristics

TXN: BD91

Note, if you use preconditions at a characteristic or characteristic value level, some of your characteristics may fail to load. If this occurs, continue loading the classes and object dependencies. After that is completed, reload the failed characteristics.

Classes

TXN: BD92

The following items must exist first:

Characteristics

Variant Table Structures

TXN: CLD3

Please note, this transaction does not allow for ECM because the table structure is not under ECM control.

The following items must exist first:

Characteristics

Variant Table Contents

TXN: CLD4

The following items must exist first:

Characteristics
Table Structures

KMAT Material Masters

TXN: BD10

Message Type: MATMAS

Classification

TXN: BD93

Please note, this data only needs to be moved if you maintained classification at a material level. This is often used with class type 200 functionality, as well as nested KMATs with restricted characteristic values.

The following items must exist first:

Characteristics
Classes
Materials

Variant Functions

TXN: CUFD

Note, this functionality is not always used. Only in the event of an instance where ABAP coding is required. This is discouraged, if possible, since this functionality cannot be easily converted to the IPC.

The following items must exist first:

Characteristics

Object Dependencies

TXN: CLD2

The following items must exist first:

Characteristics

Dependency Nets

TXN: CUK2

Please note, it is not necessary to move individual constraints, moving the constraint net automatically moves all constraints.

The following items must exist first:

Characteristics
Classes

Configuration Profiles

TXN: CLD1

The following items must exist first:

Characteristics
Classes
Object Dependencies
Constraint Nets
KMAT Materials

Bill of Materials

TXN: BD30

Please note, if you have Sales BOMS and Production BOMS, you will need to call this transaction separately for each.

Also, you may have a list of materials BOM’s to move, be sure to enter the change number in every row of the Target System Chng. NO column.

The following items must exist first:

Characteristics
Classes
Object Dependencies
KMAT Materials
Components in the BOM

Interface Design

TXN: CUID

The following items must exist first:

Characteristics
Classes
Configuration Profile
KMAT Materials
Object Dependencies
Constraint Nets

Pricing Condition Records

TXN: VK12

The following items must exist first:

KMAT Materials

Routing/Reference Operation Sets

Program: RCPDIRO1

Program: RCPTRA02

This the one piece that does not use ALE. It actually uses a more simple technology of downloading a file, and then uploading it. You need to make sure the basis person has defined a directory that is valid in both the original and target systems.

Remember, if you use reference operation sets, you must first transfer those. Use Type S. Then execute again using Type N.

The following items must exist first:

Characteristics
Classes
KMAT Materials
Object Dependencies
Work Centers

How to check for errors:

IDOC Status Monitor

TXN: BD87

To monitor the success or failure, log into the target system and execute this transaction.

After executing the transaction you’ll be able to see what failed and what succeeded. If anything failed, you’ll be able see the IDOC log to see exactly what failed and why. (See the next section).

Analyze Application Log

TXN: SLG1

Use this log to understand the errors. Certain errors may require manual changes in the target system. Other errors simply need a piece of data that has not yet been moved. As soon as the missing data is created in the target system, you can re-execute the IDOC in BD87, or you can send it again using the transaction in the original system.