VMS Material

Let us create a material master which is to be used in VMS

Before we start building data though, lets do some calculation to figure out how many materials we need.

Example Suppose a car comes in
4 exterior colors (white, black, red, blue)
2 interior colors (beige, slate)
2 fabrics (cloth, leather)
2 engines (4 valve, 6 valve)
2 transmissions (standard, automatic)
2 wheel sizes (16 inch, 17 inch)
2 wheel materials (steel, chrome)

 (4 x 2 x 2 x 2 x 2 x 2 x 2)

 In SAP, this would be modeled by creating 7 characteristics (with values) and one variant class.
That’s the easy part.  But the tricky part is figuring out how many material masters you need.

Assuming every combination of options is valid, there are exactly 256 unique combinations.
 (4 x 2 x 2 x 2 x 2 x 2 x 2).256 material masters in this example.

Include some more options by adding more characteristics, and the number of combinations
continues to explode.

Let’s take a quick look at some alternatives to creating the material master data file.

At a minimum, all you need is one material in VMS.  This would be the generic CAR, and any
combination of options would be allowed.

At a median, you could create a material for a package set of options.
In this example, this would require 4 material masters.

At a maximum, you could create a material for every allowed combination of options. 
When you create each material, you would specify in the Classification view every characteristic
that the that material called for.   256 material masters in our example.

The first option (1 material) requires the least amount of master data.  One material master, one configuration profile and you are done.  However, the user would need to specify all the
configuration values in every vehicle record

The second option (4 materials) requires a bit more data (one material master and one
configuration profile for every package).  The user would still need to specify some options,
but a few would be pre-defined.

The third option (256 materials) requires the most master data (one material an done configuration
profile for every combination).  The user wouldn’t need to specify any options as everything
would be pre-defined.

Keep in mind you need to maintain existing material masters, or create new ones if new characteristics/values are defined in the system.  This is much easier with fewer materials.

Variant Class

CT04 just creates the characteristics; the assignment to a vehicle requires a few more steps.

Step 1 - Create Variant Class

To make the assignment, the first step is to create a Variant Class.
The class is created, maintained, and displayed in transaction CL02.

To create a new class, enter the class name, define class type 300 (more on that in a bit) and
click the create button.  Enter a description, then click the Characteristics tab and assign any and
all characteristics that will make up the vehicle configuration.

The method of linking characteristics to the master data is the same as above: create a class and
make the assignment through the characteristics tab.  The trick is creating the class: there is
a specific class type defined for the type of master data to be classified.  For variant configuration,
the class type is 300; create the wrong class type, the vehicle record can’t be configured.

Step 2 - Assignment Process

The next step in the assignment process is through the material master.

Through tcode MM02, enter the material, select the Classification view, select class type 300,
and assign the variant class. It’s important to make sure you have selected class type 300
first Class Type 300 only can be used for variant configuration

Step 3 - Create a Configuration Profile

The configuration profile is created in transaction CU41.

Enter the material, specify the profile is for a material, then enter the profile details:
Profile ID (01 is nice), Profile Description (“CAR Profile” seems about right), and
Class Type (300.  Must be 300).

To Summarise

The tcodes needed to make the build the data are:-

1. CT04 (create characteristics)
2. CL02 (create class, assign characteristics)
3. MM02 (assign class to material)
4. CU41 (create configuration profile for material)
5. CU50 is used to test that the configuration looks right

To test the data

Use tcode CU50, Enter the material (CAR) and click the Configuration push button. 
If the data has been set up correctly, the list of characteristics assigned to the class will be
available for entry.  For each characteristic, click the drop down to display the list of possible
values and select the one you want.

This concludes the basic set up required to enable variant configuration.

Options

Let us see today about the Option codes in VMS

We will look at how vehicle record data is built

Step 1 : To figure out what options are needed to define the vehicle

        A. Examples are exterior color, engine, transmission, model, and trim package.
        B. There is no limit to the number of options that could be created to define the vehicle.

Step 2 : To figure out the possible values for each option

       A. Example, the choices for exterior color can be red, blue, green, yellow and black;
                The choice for trim can be LX, EX, and ZX.
                These examples have multiple values for each option. But it’s just as acceptable
                to define a unique option for RED, a unique option for BLUE, so forth and so on.

Step 3 : To create a characteristic for every option through tcode CT04

       A. Every characteristic must have a unique name.
       B. Using Exterior Colour, acceptable names are: EXT_COLOUR, or    
           COLOUR, or 1234AHG, or etc

          To define the data type
      A. Majority of characteristics will be either type CHAR   (character) or NUM (numeric). 
      B. Once the data type is defined, the input parameters need to   be defined.
      C. For CHAR, this is the max length of the value key.
      D. For NUM, this is the max number of integers
            Warning: once the data type is set, it can’t be changed. 

Step 4: To defines the possible values inside the characteristic

       A. It’s the combination of characteristic and value that define the vehicle record
           so that step 1 and 2 are much important. 

       B. If this characteristic (Exterior colour) has multiple values (red, blue, green, etc.),
           then each possible colour would be listed as a unique value

       C. If the characteristic has single value (e.g. COLOUR_RED), then only one colour
            would be listed as a value.

        Entering values in the characteristic

    1. Each line for value has two fields: the key and the   description.
    2. The key must be unique for the characteristic
    3. Its length must be less than or equal to the max length   defined in the header.
    4. For CHAR, the key can be alphanumeric
    5. for NUM, the key must be numeric

 Example : OY6 could be the key for red, A4R could be the key for blue, etc.

 Defining all the option codes is a big chunk of work, but this is only the first of several additional steps needed to build  the master data.

Configurable Products

Let us see why VMS can support highly configurable (CUOBJ) and discrete products (VHCLE).

1. In VLCVEHICLE table, there are two key data fields that make VMS behave like VMS.
    The Internal     Number (VHCLE) and Configuration ID (CUOBJ). 

2. These two fields are the reason why VMS can support highly configurable (CUOBJ),
    discrete products (VHCLE).

3. The first step in any VMS business process is the creation of the vehicle record.Executing
    this action adds a new record to the VLCVEHICLE table. Every record has a unique internal
    number assigned to it, making this a key field for the data table.

A) The Internal Number (VHCLE)

1. The internal number is a counter, increasing by one every time a vehicle record is created. 
    So if the number range starts at 100, the internal number for the first few vehicle records
    created will be 100, 101, 102, and so forth.  Even if a vehicle record is later deleted or
    archived, the counter is never reused.

2. The internal number assigned to the vehicle record will never change.  Most of the other fields
    in the record might be get updated as the vehicle moves along the business process, but the
    internal number is a key field this value is locked in place. 

B) Configuration ID (CUOBJ)

1. CUOBJ is also a counter, and created at the same time as the vehicle record.But the value is
    not the same as the internal number.

2. The CUOBJ points to the exact configuration of the vehicle record.  If a vehicle has a red
    exterior, tan leather interior, V6 engine, automatic transmission, driver’s convenience package,
    California emissions and floor mats, all this information is captured in the CUOBJ linked
    to the vehicle record.  The VLCVEHICLE table itself doesn’t contain the configuration values,
    but through the magic of relational databases, the data can be easily extracted, searched & displayed.

3. So, like the VHCLE, the value in the VHCLE & CUOBJ dat field never gets updated even if
    the vehicle configuration itself changes.

4. CUOBJ data field is also found in purchase order and sales orders tied to the vehicle record.
    When these documents are created, ERP will create a new CUOBJ (it is a counter, after all)
    to store the configuration values in the document.Even if the values are identical,each CUOBJ
    will be unique.  But because the CUOBJs are unique, it is possible to store different
    configuration values in the vehicle record, the purchase order, and/or the sales order. 
    This is important, as a customer might want to order a vehicle with options that aren’t
    installed in the factory.

Use of VMS

1. A central transaction code Tcode VELO - by using this tcode, we can execute

    the following 3 major business process

       a) configure new vehicles
       b) search existing vehicle records
       c) execute the steps in the business process

2. All of the ERP documents can be executed from tcode VELO
      (purchase order, sales order, invoice, goods  movements, service orders, financial postings,

      production  orders, etc.).

     Or else the user could go to standard transaction codes defined for each  document type

     (e.g. ME21N for purchase orders,  VA01 for sales  orders, CO01 for production orders,

     ad naseum, ad naseum).  User needs to be remember only one tcode VELO and no need

     to remember all others tcodes

3. Using VELO to execute the business process has the added benefit of controlling the

    sequence in which these documents are created. While ERP also requires a logical flow

    of the documents (e.g. can’t post a goods issue before goods receipt), VMS offers even

    tighter control over the sequence of steps in the business process.

4. when the ERP documents are created through VELO, they can all be linked to the

    vehicle record.  This makes is much easier to search for, and review, all the documents

    created for the vehicle, from a single source.

5. Table VLCVEHICLE - a central data table to capture all information for all vehicles

    for all time. Every vehicle managed in VMS has a unique record created in this data table. 

    This table stores every possible attribute (SAP standard and Custom added) that captures

    information about this unique vehicle.  For example, the Vehicle Identification Number (VIN),

    the Manufacturing Plant, the Allocated Dealer, the Gross List Price, the Planned Delivery Date,

    and Current Status are all standard attributes that can be used for search and reporting.

    This table can be linked to other data tables to capture the vehicle configuration

    (exterior color, interior color, engine, etc.), additional data elements (serial number of

    installed assemblies, tracking numbers, quality comments), and the ERP documents created

    as the vehicle progressed through the business process.

   This table also offers an attribute for vehicle location.  This field is independent of a plant or

   storage location and can be freely defined and freely updated.  In ERP, if a vehicle moves

   from one location to another, a material document is required to record this transfer.  In VMS,

   updating the location is just an update, so no material movement is required.  And because these

   locations are freely definable, any value can be maintained so that VMS can accurately track

   the vehicle moves from an external OEM vendor to the port to the to the Pacific Ocean to

   the port to the rail yard to the trailer to the importer lot to the dealer to the end customer.

 

What is VMS

What is VMS

Let us see What is VMS

1. The Vehicle Management System (VMS) is a solution available in SAP ERP.

2. VMS was originally developed to meet the requirements of vehicle importers and national sales  
    companies. For these organizations, highly configurable products are ordered from an OEM
    (or OEMs for multi-brand importers), brought in country, and then sold to the dealer network.

3. VMS was presented as a solution that could

   a) Configure new vehicles (I want a Red Sedan with V6 engine,  automatic transmission, leather,
       and a sports package.  And floor mats)

   b) Search for vehicles (I want to see all Sports Cars in dealer  inventory in the local area)

   c) Manage vehicle centric business processes (I need to place orders  to the OEM, receive
       production updates, track inbound vehicle  shipments, process vehicles through customs,
       inspect and prepare vehicles on the ground, and then sell them to my dealers).

4. The solution was developed with the requirements of importers in mind, it’s no surprise that
    the first customers were … importers of passenger vehicles

5. VMS is extremely flexible and can support the inbound and outbound flows for just about
    any highly configurable, serialized product.

6. VMS is not limited to just for vehicle imports. Other customers use VMS to manage the
    manufacturing, export, and conversion/accessorization of configurable products.

7.  A product could be a candidate for VMS if it has the following attributes:

     It is highly configurable.  Automobiles come in many colors, trim levels, interiors, power trains,
        electronics, etc.  Books or CDs have unique SKUs, where the content is always the same.

    It is configurable, but comparable to similar products.  Because there are so many options to
    choose from, an OEM might only build exactly identical vehicles a couple times a year. 
    Even if there is engineering content, every car still looks like the others.

    It is a discrete product.  Each unit rolls off the production line one at a time and can be
    uniquely identified, usually through a serial number.  Pharmaceuticals, gasoline, and soft drinks
    might be produced in different configurations, but it’s impossible to distinguish one drop
    of inventory from another.

   It needs to be tracked through a defined business process.  As the vehicle goes from the factory
    to the end customer, there are many steps that need to be performed along the way. 
   Users need to be able to see where the vehicles are, where they have been, and where they are
   going.