Contact

Industry Leading Blog for Manufacturers

Life will be easier in 6 months ...

In designing a model in Variant Configuration there are a hundred small decisions to make about how to structure the data and logic to make the darn thing work. Do I use tables or dependencies? Do I want a few long dependencies, or many short ones? Should I use a single class, multiple classes, or hierarchal classes? Do I need more than one constraint net?

Unfortunately, the answer to all of these questions is "It depends..."

There are almost always multiple ways to solve problems in SAP VC. You need to choose the right one for the situation. Some are blatantly obvious, for example "I need to set a default value".  Dependencies are the best way to do that. Others are more vague, like "this value is that value plus 2".  Constraint or dependency? Hmmm…

As far as function is concerned, many of the multiple ways are interchangeable. For many tasks, either tables or dependencies will work equally well. Long or short dependencies result in the same answers. In a properly coded model, the answers are always correct, and information flows downstream without issue no matter what choices you made.

The gotcha? Down the road. Which path you should have chosen for ease of maintenance usually shows up after things have been in place and working for a while. Six months later when someone is trying to change the way things work, or add or subtract data, it becomes painfully clear which method would have been easier.

To avoid this pain (or at least minimize it), I suggest designing the solution with future maintenance in mind. You can start by assuming three things for every model:

  1. There will be changes
  2. They will need to be done by someone else
  3. If they are done by you, you will have forgotten what you did and why you did it.

To counter the ramifications of those assumptions, I offer three strategies:

  1. Be consistent
  2. Design to make changes easier
  3. Document your code

Consistency

Always doing something the same way means it's easier to figure out what you did when you come back a year later.

Question: How did you do it?

Answer: You did it the same way you did it yesterday. If it's a complex model, and you had to do something differently, do it "differently the same way" throughout the model.

If you set defaults using a dependency named "PD_(something)_DEFAULT", ALWAYS set your defaults that way. That way, when someone is looking to change a default, they know where to look (yourself included). Don't set defaults sometimes by setting a flag on the value in the CSTIC, and other times using a dependency. When the time comes to figure it out, you'll look in the wrong place and be puzzled.

Use a naming convention for your objects. For example, I use PR for procedures that set values, PD for procedures that set defaults, PC for pre-conditions and so on… This makes it easier to tell what something does. I follow this convention whenever possible. That makes it easier not only within a model, but any time I look at work that I did.

I also tend to use the same name for the material, the class, the config profile, and the constraint net. This may seem confusing when you're learning how each of those different objects interact, but it makes things a lot simpler when you're actually coding and you need to remember what you named the class that goes with this material. If you don't use the same name, use the same convention (CL_(material) for example).

There are lots of other places that consistency makes sense. You'll be able to see them now that you're looking. I try to be consistent not just in a single model, but across all my models. It makes things simpler. And simpler is better.

Design for Change

As I said, no matter what you do to account for today's data and logic, things will change and someone will have to fix them. Engineering will add new options. Marketing will change the way they want to present things. Accounting will want to change what the pricing conditions records are called. If you coded yourself into a corner, you won't be "changing". You'll be "rewriting"; a more complex process. Changing is easier.

As you're writing code, try to think what changes are likely and account for them. If you can think of two ways to do something, do the one that will be easier to change. This is more of a mindset than a case of specific examples. But, you know what goes into the code as you're writing it. You also know what will be necessary to change it. Think through what it would take.

While this is a mindset, there are also specific examples. Tables are a good one. Tables are almost always easier to change than finding the correct reference in the code and changing it there. Tables are easier to understand. And, tables can be changed by more people. Even people who don't understand VC understand tables. If there's a choice between doing something in a table or not, choose the table.

Document Your Code

I've written a lot of documentation that no one has ever read. It’s mostly up on a shelf somewhere in a dusty binder. Don't get me wrong, documentation is an important part of knowledge transfer, and it’s often a necessary deliverable. But, you also need to put it where it will actually be needed and used: inside the code. I'm not talking paragraphs. Just make it clear what you're doing.

Tell me which chunk of code is easier to understand:

A...

* PD BASE PLUS OPTIONS 1000
$DEL_DEFAULT( $SELF, EL_SHOPHOURS, $SELF.EL_SHOPHOURS )
IF $SELF.EL_SHOPHOURS SPECIFIED AND $SELF.VCVBAPWERKS = '1000',
TABLE POC101( EL_SIZE = $PARENT.EL_SIZE,
EL_SHAPE = $PARENT.EL_SHAPE,
EL_TIME ?= $SELF.EL_SHOPHOURS )
IF $SELF.EL_DESIGN = 'LG' AND $SELF.VCVBAPWERKS = '1000',
TABLE POC102( EL_SIZE = $PARENT.EL_SIZE,
EL_SHAPE = $PARENT.EL_SHAPE,
EL_TIME ?= $SELF.EL_SHOPHOURS )
IF ($SELF.EL_DESIGN NE 'LG' OR NOT $SELF.EL_DESIGN SPECIFIED) AND $SELF.VCVBAPWERKS = '1020',
$SELF.EL_COSTINGHOURS = $SELF.EL_SHOPHOURS IF
$SELF.VCVBAPWERKS = '1000',
$SELF.EL_SHOPHOURS ?= $SELF.EL_SHOPHOURS + 180
IF $SELF.EL_OPTIONRR = 'ROTOROOTER' and
$SELF.VCVBAPWERKS = '1000'.

Or B…

* PD BASE PLUS OPTIONS 1000
* Procedure to lookup base hrs in a table then add for options. Only in plant 1020.
* tjrose 1-10-2013
* modified tjrose 2-14-2013
* Delete default if specified
$DEL_DEFAULT( $SELF, EL_SHOPHOURS, $SELF.EL_SHOPHOURS )
IF $SELF.EL_SHOPHOURS SPECIFIED AND $SELF.VCVBAPWERKS = '1000',
* Lookup time based on Size and Shape
* if LG design use this table
TABLE POC101( EL_SIZE = $PARENT.EL_SIZE,
EL_SHAPE = $PARENT.EL_SHAPE,
EL_TIME ?= $SELF.EL_SHOPHOURS )
IF $SELF.EL_DESIGN = 'LG' AND $SELF.VCVBAPWERKS = '1000',
* if not LG design use the other table
TABLE POC102( EL_SIZE = $PARENT.EL_SIZE,
EL_SHAPE = $PARENT.EL_SHAPE,
EL_TIME ?= $SELF.EL_SHOPHOURS )
IF ($SELF.EL_DESIGN NE 'LG' OR NOT $SELF.EL_DESIGN SPECIFIED) AND $SELF.VCVBAPWERKS = '1020',
* set Costing Hrs to Shop Hours before adders
$SELF.EL_COSTINGHOURS = $SELF.EL_SHOPHOURS IF
$SELF.VCVBAPWERKS = '1000',
* Add 180 if RotoRooter adder is necessary
$SELF.EL_SHOPHOURS ?= $SELF.EL_SHOPHOURS + 180
IF $SELF.EL_OPTIONRR = 'ROTOROOTER' and
$SELF.VCVBAPWERKS = '1000'.

Sure, you know code well enough to figure what was happening without someone telling you, but you have to agree that it is a lot easier to understand the second example on the first read through. It takes just a few seconds to add those lines, but those lines make all the difference when you're looking at code for the first time. Or, when you’re looking for the first time in a while.

These are not big ideas. They’re little ones. Simple ones. Most people are already aware of them. The trick is to remember them when you’re doing things the first time. Be consistent, design for change, and document your code. Life will be easier in six months. I promise.


Stay up to date on the leading industry solutions by subscribing to our blog digest.
What can we help you with?

CONTACT US

(585) 506-4600