The Up & Away Advisors’ Guide to Implementing and Executing Sap’s Vehicle Management System

actions.

CHAPTER ONE:

WHAT IS THE VEHICLE MANAGEMENT SYSTEM?

The Vehicle Management System (VMS) was developed by SAP as part of the Automotive Industry Solution (IS-Auto) to meet the needs of vehicle importers. While the solution was originally designed with this specific market segment in mind, VMS has been implemented at many different companies, in many different industries, supporting very diverse business processes. VMS is located in the Logistics Execution folder of the Enterprise Core Component (ECC), but is visible only after the Discrete Industries/Mill Products (DIMP) business function group has been activated in the Switch Framework transaction. (Note: VMS is available without DIMP activation in S/4 HANA).

Importer Business Process

In a typical importer scenario, vehicles are produced by an Original Equipment Manufacturer (OEM), who purchases components and assemblies from external suppliers. Finished vehicles are then loaded onto boats, railcars, or truck trailers for delivery to the importer. The vehicles may need to clear customs or move into/out of a Free Trade Zone before the importer can take ownership. Once the vehicles reach the importer compound, they can be prepared for delivery (e.g., cleaning, adding local content, or repairs). The vehicles will then be loaded onto trucks or railcars and transported to a dealer, who will be responsible for the final sale to the customer.

The scenario defined above can be divided into two distinct segments: An Inbound Process to manage all interactions between the importer and the OEM as finished vehicles are brought into the compound; and an Outbound Process to manage interactions between the importer and the dealer as finished vehicles leave the compound and move through the distribution channel. Typically, VMS will be implemented by the importer, who will play a role in both the Inbound and Outbound Processes.

A VMS business process can involve several ECC business partners, with the OEM as the Vendor and the Dealer as a Customer. Purchase orders and sales orders are linked to the vehicle record, along with the inbound and outbound invoices. VMS could also integrate with other business partners, such as Transportation Companies, Customs Brokers, or End Customers, who could send updates that can be captured in the vehicle records.

Manufacturer Business Process

Despite the original scope of its development, VMS can support more than importer business requirements. For example, VMS has been successfully implemented at several OEMs to control the manufacturing business processes. The overall process still begins with the OEM and ends with the sale to the end customer, but the dividing line between Inbound and Outbound Processes shifts. In a manufacturing scenario, VMS will be implemented at the OEM, not the importer. As a result, the Inbound Process will include the manufacturing activities (e.g., Body Shop, Paint Shop, General Assembly) that produce the finished vehicle. Once the vehicle has passed inspection, the Outbound Process will manage the transfer of the vehicle to the Sales Company (or importer). Any dealer-facing activities are not in the scope of this scenario. VMS is able to support such distinct business processes because of two technical objects provided by the solution: The Action Matrix and the vehicle record.

Action Matrix

The Action Matrix defines the individual steps of the business process and the exact sequence in which these steps should be executed. For example, an Action Matrix could be defined so that the goods receipt is posted after the incoming invoice, the sales order created only after the dealer submits a deposit, or the vehicle is prevented from leaving the Free Trade Zone until Customs paperwork is completed, and so forth.

The Action Matrix consists of actions, each representing the individual steps of the business process. SAP delivers over 100 standard VMS actions to support some of the most common business process steps. Many of the VMS actions are tightly integrated with ECC modules, offering the ability to create documents such as purchase orders, sales orders, invoices, material movements, etc. More importantly, SAP allows custom actions t0 be developed and incorporated into the Action Matrix to support unique business requirements.

To control the sequence in which the actions may be executed, the Action Matrix consists of a combination of actions and statuses. An action may only be executed if it is defined in the Action Matrix at the status of the vehicle record being processed. The Action Matrix also defines how the vehicle status will be updated when the action is successfully executed. Based on the matrix definition, the new status could result in a different set of allowed actions. This process would repeat as the vehicle record completes each step in the Action Matrix.

The Action Matrix is configured in the Implementation Guide (IMG). It is possible to change the Action Matrix by adding new actions or deleting existing actions, or to update the combination of action and status. It is also possible to create multiple Action Matrixes to support variations of the business process. For example, the Outbound Process could depend on the distribution channel (e.g., Fleet vs. Retail Sales), or the Inbound Process could depend on whether the vehicle is sourced domestically versus internationally.

Vehicle Record

Every vehicle managed in VMS will have a unique record in the VLCVEHICLE data table. This record can capture attribute values related to each 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 available in this table. The table can also be appended with custom fields, although this will require some ABAP development.

This record makes it possible to track the vehicle throughout its entire lifecycle. Since a vehicle exists as soon as the record is created in the database, it is possible to track the progress of the vehicle before it is produced or arrives in stock, and long after it has been shipped to a customer. The vehicle record is available for search as soon as it has been created, and continues to be available for search long after the vehicle has been shipped, sold, or scrapped. Vehicle data can also be archived or exported to TREX and BW.

The vehicle record can be linked to other data tables to capture additional object specific information, such as configuration (exterior color, interior color, engine, etc.), additional data elements (serial number of installed assemblies, tracking numbers, quality comments), and the ECC documents (sales orders or purchase orders) that were created by the actions that moved the vehicle through the business process.

Where Does VMS Fit?

As the name suggests, the Vehicle Management System is a System to Manage Vehicles. There is a sweet spot of products where this solution fits best, but VMS is not limited to products with wheels. There are some criteria to help determine if VMS will or will not be a suitable solution.

Highly Configurable

Automobiles come in many colors, trim levels, interiors, powertrains, electronics, etc. Given the large number of options, the possible combinations can be astronomically large. VMS can capture the specific options defined for each individual vehicle record.

Bad Choice: While there are many varieties of toilet paper and ballpoint pens, there is usually only a slight variation from the base product.

Highly Configurable, but with Consistent Choices

Given the astronomical number of option combinations, an OEM might build the same vehicle only a few times a year. However, every vehicle is produced on the same line following the same assembly processes. Even if the configuration in each vehicle is different, the dimensions (height, length, and width) are the same, only certain type of engines may be installed, and the overall set of available options is limited by the product design.

Bad Choice: Satellites and elevators are so unique that each unit is tracked through an individual project.

Produced Discretely

A vehicle rolls off an automotive assembly line one at a time and can be uniquely identified and traced with its individual serial number. VMS can capture the VIN and other serialization data for each vehicle.

Bad Choice: Pharmaceuticals, gasoline, and soft drinks are produced in large batches where it’s impossible to distinguish one drop of inventory from another.

Tracked through a Consistent Business Process

Finished vehicles will travel from the factory to the importer to a dealer following a consistent process. While the precise route will depend on the business partners involved, every vehicle will pass through the same stage gates. By updating certain attributes in the vehicle record, VMS can track the current location of each vehicle, where it has been, and where it will be going next.

Bad Choice: Hamburgers can be customized to order, can be individually identified, and are made using a consistent process. However, hamburgers are best eaten where they are produced, and best if eaten right away.

Products that have been successfully managed in VMS include passenger cars, commercial vehicles, motorcycles, school buses, construction equipment, lift trucks, specialty vehicles, tractor-trailers, agricultural equipment, and returnable pallets. The solution could also support aircraft, complex machinery, and serialized electronics.

Make to Stock (MTS) AND Make to Order (MTO)

At a very high level, there are two main types of logistics models. With Make to Stock, projected vehicle inventory is forecasted and produced, and then allocated or sold to dealers. With Make to Order, procurement will only start after receiving a customer requirement for a specific vehicle configuration.

Standard ECC supports both MTS and MTO strategies, but generally a material will only follow one of these scenarios. VMS is unique in that it provides the ability to support both logistics models for the same material, in the same plant code, and at the same time.

Standard Make to Stock

MTS items are not configurable, so a material master must be created for each unique combination of options. The material master usually has a logical naming convention. Since the configuration behind the material is known, these items can be built ahead of time and kept in inventory in anticipation of demand. However, this could require the creation and management of a large number of material masters.

Standard Make to Order

MTO items are configurable, so a single material master could manage all possible option combinations. However, the specific options must be entered when each order is received. Because the exact combination of options can be unique in every order, MTO items cannot be produced ahead of time. The sales order will drive the ordering, receiving, and shipping of vehicle inventory.

VMS Manages Make to Stock and Make to Order

The vehicle record makes it possible for VMS to support both MTS and MTO scenarios with the same material master. The unique combination of options can be captured in the individual vehicle record, even if no ECC document (purchase order or sales order) has been created. The procurement activities can take place before any demand is received (MTS) because the purchase order and goods receipt can be posted against the vehicle record and then matched to a customer demand at a later point. Alternatively, the vehicle and sales order could be created in the first step of the business process (MTO), which would then trigger the procurement activities to meet the customer demand.

In VMS, the only difference between a vehicle procured by MTS or MTO is the sequence in which the actions are executed: MTS vehicle records will trigger planning and procurement activities before demand is generated, while MTO vehicle records will capture the demand first. As a result, VMS can support Make to Stock AND Make to Order for the same material, in the same plant, at the same time.

Highlighting Key VMS Capabilities

Having discussed the key concepts behind VMS, here are some of its key capabilities. The examples below are presented from the perspective of the importer and dealer, but these benefits are available when VMS is implemented by different business entities.

Configure New Vehicles

•The importer creates a forecast for 100 vehicles of a particular base model. As the forecast becomes firm, the options can be updated in the vehicle records.

•The dealer makes a specific request for a red sedan with a V6 engine, automatic transmission, leather, and a sports package. Oh, and floor mats.

VMS is tightly integrated with variant configuration to control the combination of options in the vehicle record. VMS can also be integrated with the CRM Internet Pricing and Configuration (IPC) tool, which uses Configuration Change Profiles to dynamically determine who can update the vehicle configuration and if particular elements can be changed (e.g., only dealer options can be updated after the vehicle starts in production).

Search for Vehicles

•The importer wants a total count of sports cars inventory, sorted by inbound, in-house, or dealer inventory.

•The dealer looks for vehicles in the importer inventory that are available for purchase.

It is possible for a user to define search profiles with prepopulated attribute values for commonly executed searches. The search results can also be extracted to Excel for further analysis or reporting.

Allocate Vehicles

•The importer allocates forecasted vehicles to dealers in its network. The dealer can either convert the allocation into a sales order or automatically let the allocation lapse after a defined expiration period.

•The dealer can request a specific vehicle. If the importer approves, the request is converted into an order.

VMS provides the ability to process vehicle allocations in batch mode, although any optimization logic would need to be developed. Sales documents can also be created without any reference to a vehicle object and then assigned in a later batch process to the best matching vehicle.

Manage Logistics Processes

•The importer can 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 track the delivery of the vehicle to the dealer.

•The dealer can check the estimated delivery date for a special-order vehicle in response to a query from their customer.

VMS can make MM material document postings (goods receipt, goods issue, or transfer posting) with reference to plant and storage location, but offers an additional location attribute that can be updated without posting a material document. The values for this vehicle location field can be freely defined in the IMG. Since no MM posting is needed to update this field, the vehicle can be tracked before it arrives in stock (i.e., factory, port, or ship), while in stock (i.e., parking lot A row 53), and after it leaves stock (i.e., truck trailer, rail yard, or dealer).

Other Key Capabilities

•Integration with ECC Documents —Purchase orders, sales order, material movements, invoices, service orders, etc. that were created when executing VMS actions are all linked to the vehicle record. It is possible to search for vehicles using the document number, and it is also possible to access the document directly from the vehicle record.

•Integration with Warranty Claims —Any warranty claims created for the vehicle can be displayed directly from the vehicle record.

•Integration with Electronic Documents —Any electronic file (photos, work instructions, scanned documents, etc.) can be linked to and displayed from the vehicle record. This integration is offered through the Document Management System (DMS, but not to be confused with a Dealer Management System, a more common use of this acronym in the automotive setting).

•Batch Processing —The actions in the business process can be executed in batch mode. Simply create a variant that will select vehicle records based on predefined search criteria and then execute the action with predefined input values. This allows for automation of the business process, with limited to no user involvement required.

•Personalization and Security —VMS uses the assignment of VMS Roles to the user ID to determine which vehicle records a particular user will be able to see and process. This is critical because all vehicle records are stored in a common database.

•Convenience —All VMS functions can be executed from a single cockpit transaction (VELO), so users do not need to memorize multiple transaction codes. Short for VEhicle LOcator, this cockpit makes it possible to a) configure new vehicles, b) search for existing vehicles, and c) execute the steps in the business process.

VMS Integration in ECC

While developed as an Industry Solution, VMS was built in ECC and is integrated with the core modules. Based on the standard VMS actions provided by SAP, this integration is extremely tight in some modules but loose to minimal for others. VMS does allow for custom development to extend the solution as needed.

•Tight Integration: VMS was originally designed to support the business requirements of importers, who needed a solution to manage the inbound procurement and outbound distribution of vehicles. As a result, there is very tight integration with the MM, SD, and FI modules.

•Loose Integration: Later releases expanded the VMS footprint into the PM and CS modules. However, a number of the standard actions require additional BAdI enhancements before they will work properly. There is tight integration with Warranty Claims Management (found in the CS/PM modules), but this solution must be implemented independently of VMS.

•Minimum Integration: Since importers will purchase and not produce vehicles, there is minimal integration between VMS and the PP module. VMS does allow custom development, so actions that trigger PP functions can be developed and added to the Action Matrix. VMS has been successfully implemented at a number of manufacturing companies.

VMS Integration Beyond ECC

It is possible to expand the solution footprint by integrating VMS with other SAP solution offerings. However, as the focus of this book is VMS functionality available inside ECC, these other solutions will only be mentioned briefly.

•Business Suite: There is standard integration available to support the implementation of business scenarios in Business Suite solutions such as SCEM (Supply Chain Event Manager), CRM (Interaction Center and IPC), BW (Business Information Warehouse), and TREX (Text Retrieval and information EXtraction).

•Portal: SAP also offers access to external users through the Dealer Portal. The Dealer Portal is different from SAP’s Enterprise Portal offering. All users would still need to be assigned an ECC user ID, but would be able to view and process VMS records through a web-based front end. The Dealer Portal is synonymous with a Dealer Communication System.

•Dealer Business Management: A cousin of the Vehicle Management System is Dealer Business Management (DBM), an ERP offering from SAP for automotive Retailers. Before SAP acquired the intellectual property, the solution that eventually became DBM was a custom-developed solution based on IS-Automotive. As a result, VMS and DBM share some development heritage, but are distinct solutions, developed at different points in time, and serve different target markets.

Having discussed the major concepts and capabilities, the next chapter will focus on the preliminary steps that are required to set up a working VMS solution.

CHAPTER TWO:

A CHECKLIST TO GET VMS UP & AWAY

This chapter, highlighting the major steps that must be completed before VMS will be ready for use, is intended for readers who have some experience with VMS but need a quick reference when setting up a new client or just want a refresher. Readers new to VMS can skip this chapter if they like.

This chapter presents these steps in a checklist, with a brief description provided for each step. Detailed explanations will be available in subsequent chapters. It is important to note that this checklist covers the minimum steps needed to create a vehicle record. There are additional settings not included here that are required to execute more complicated business processes. Finally, this checklist only considers steps that are specific to VMS. Any configuration settings or master data made in other modules will not be described.

Checklist of Steps Needed to Create a Vehicle Record

1.1 Activate DIMP_SDUD in Switch Framework

2.1 Define Material Type for Split Valuation

2.2 Define Split Valuation in the Plant Codes

2.3 Define VMS Number Ranges

2.4 Define VMS Roles

2.5 Define Basic Action Matrix

3.1 Create Variant Class

3.2 Create Material Master

3.3 Create Configuration Profile

4.1 Assign Organizational Data to VMS Role

4.2 Assign Material Master to VMS Role

4.3 Assign VMS Role to User

4.4 Assign Matrix to Vehicle Materials

5.1 Create the Vehicle Record

Section 1: —Technical Setup

Step 1.1 Activate DIMP_SDUD in Switch Framework

VMS is only available after the Discrete Industries/Mill Products business function set (DIMP_SDUD) has been activated in the Switch Framework. The Switch Framework is accessed through transaction code SFW5. In addition to DIMP_SDUD, there are other business function sets that contain functionality relevant to VMS (AUTO_DP_1, AUTO_DP_2), but these are only necessary if the Dealer Portal will also be implemented.

It is important to note that there are restrictions on the combination of industry solutions that can be active in the same client. Once a business function set has been activated, it cannot be deactivated. Update for S/4 Hana – this step is not necessary, as VMS is already activated in this version of the software.

Section 2: —IMG Settings

More detailed explanation for the following settings can be found in Chapters Three and Six.

Step 2.1 Define Material Types for Split Valuation

The material type that will be used to create the material masters for vehicle models must be defined for Split Valuation. This can be done in menu path:

SPRO > Logistics – General > Material Master > Basic Settings > Material Types > Define Attributes of Material Types

SAP provides material type VEHI for use in VMS, but almost any material type could be used. Make sure the material type is defined for Quantity and Value Updating in the plant code that will be used to create vehicle records. More details about setting valuation by material type can be found in Chapter Three.

Step 2.2 Define Split Valuation in the Plant Codes

Split Valuation must be active and Valuation Category X must be allowed for the plant code that will create vehicle records. This can be done in menu path:

SPRO > Materials Management > Valuation and Account Assignment > Split Valuation

There are two transactions in this folder: Activate Split Valuation and Configure Split Valuation.

Step 2.3 Define VMS Number Ranges

VMS has several number ranges that must be maintained. This can be done in menu path:

SPRO > Logistics Execution > Vehicle Management System > Number Ranges

Two of the transactions in this folder are mandatory: Determine Number Ranges for Internal Vehicle and Define Number Ranges for Action Control Determination. There is an additional transaction, Define Number Ranges for Configuration Change Profiles, but this is not a required step for vehicle creation.

Step 2.4 Define VMS Roles

At least one VMS Role must be created. This can be done in menu path:

SPRO > Logistics Execution > Vehicle Management System > Define VMS Roles

Step 2.5 Define Basic Action Matrix

An Action Matrix containing action CREA must be created. This can be done in menu path:

SPRO > Logistics Execution > Vehicle Management System > Control Data > Define Action Controls and Define Action Matrices

Section 3. —Master Data Settings

More details for the following settings can be found in Chapter Three.

Step 3.1 Create Variant Class

A variant class (type 300) must be created in transaction CL02. Characteristics must also be assigned to this variant class. Characteristics can be created directly in the class or in transaction CT04.

Step 3.2 Create Material Master

A material master for the vehicle model must be created in transaction MM01, using the material type and the plant code defined in Step 2.1 above. Client-level views that need to be created are Basic Data 1 and 2, and Classification. The minimum plant-level view is Accounting 1. The variant class created in Step 3.1 must be assigned to the material. The valuation type in the Accounting 1 view must be defined as X (based on Step 2.2 above).

Step 3.3 Create Configuration Profile

A configuration profile must be created for the material in transaction CU41.

Section 4. —VMS Role Assignments

More details for the following settings can be found in Chapter Seven.

Step 4.1 Assign Organizational Data to VMS Role

The VMS Role, created in Step 2.4 above, must be defined as an organizational role in transaction VELORO. The menu path is:

SAP Menu > Logistics > Logistics Execution > Vehicle Management System > Basic Data > VMS Roles > Assign Organizational Data

Step 4.2 Assign Material Master to VMS Role

The vehicle model must be assigned to the VMS Role in transaction VELORM. The role was created in Step 2.4 and the model was created in Step 3.2 above. The menu path is:

SAP Menu > Logistics > Logistics Execution > Vehicle Management System > Basic Data > VMS Roles > Assign Vehicle Model

Step 4.3 Assign Material Master to VMS Role

The vehicle role must be assigned to the user in transaction VELORU. The role was created in Step 2.4 above. The menu path is:

SAP Menu > Logistics > Logistics Execution > Vehicle Management System > Basic Data > VMS Roles > Assign User Roles

Step 4.4 Assign Matrix to Vehicle Materials

The Action Matrix created in Step 2.5 above must be assigned as the Primary Action Control for the vehicle model created in Step 3.2 above. A number range for matrix determination must have been defined in Step 2.3 above. The transaction code is VELOS and can be found in the menu path:

SAP Menu > Logistics > Logistics Execution > Vehicle Management System > Basic Data > Define Action Control Determination

Section 5 —Final Steps

Step 5.1 Creating the Vehicle Record

Once all the above settings have been maintained, open transaction VELO. Click on the vehicle model and select action Create Vehicle (Configurable) from the Action Drop Down.

Enter the plant code that equals the Accounting 1 view that the material was maintained in. Enter 1 for number of vehicles. Enter the Production Date if desired, but do not click the Configure pushbutton at this time. Click the Execute Action pushbutton.

If all the previous steps were set up correctly, a new vehicle record will be displayed in the left-hand side of the screen. You are now ready to being processing the vehicle through its business process (which will be defined in the following chapters).

CHAPTER THREE:

INITIAL MASTER DATA CREATION

VMS requires the creation of several master data elements before it is possible to execute a vehicle-centric business process. This chapter will focus on the creation of two foundational master data objects: variant configuration and material masters. Combining these master data objects results in a configurable material, which allows for an astonishing variety of finished products to be produced and sold with only a few material masters defined in the system.

This chapter will examine the master data transactions needed to create a configurable material. More importantly, some different examples of how to model this data will be presented. The sequence of steps to build this data is:

•Create the characteristics in transaction CT04

•Create the variant class in transaction CL02 and assign the characteristics

•Create the material master in transaction MM01 and assign the class

•Create a configuration profile for the material master in transaction CU41

•Test the configurable material in transaction CU50.

There are other master data elements required by VMS, but these are typically maintained in other ECC modules.

Defining Characteristics

Before creating any master data in the system, it is critical to first analyze the available options. For passenger vehicles, some obvious examples are exterior color, engine, transmission, and trim package. Tire size, wheel size, wheel type, radio type, and windshield wipers, are other possible options that could be selected by the user or automatically populated. Commercial vehicles and engineering equipment have more complex modeling requirements, as they could have dimensional options such as height, length, load capacity, and number of seats and windows.

Once the set of options has been determined, the next step will be to derive the possible values for each option. For example, the vehicle could be available in exterior color red, blue, green, yellow, or black; the possible choices for trim package could be LX, EX, or ZX; the choice of heated seats could be Yes or No; and dimensional options could allow any value between 10 and 50 feet.

Once the options and the possible values have been defined, the final step is to determine how to model the options and their possible values. For example, there are two methods that could be used to model exterior color.

•The first method is to create a characteristic for the option (e.g., EXT_COLOR), and then assign all the possible values for color. (e.g., RED, BLU, or GRN)

•The second method is to create a characteristic for each value (e.g., EXT_COLOR_RED, EXT_COLOR_BLU, etc.) and then assign Yes/No values.

SAP can support either method, but keep in mind that it can be very difficult to adjust the master data once it is in use. Master data should only be created after there is solid agreement in the project team about how it will be modeled.

Creating Characteristics (Transaction CT04)

To create a new characteristic in transaction CT04, click the create icon and enter the characteristic name (up to 30 characters long). It is possible to use a logical naming convention to help identify the option, but there are other fields inside the characteristic (e.g., description) that can provide additional detail.

After entering the characteristic name and description, determine the characteristic data type. For VMS, most characteristics will either be type CHAR (Character) or NUM (Numeric). There are other data types available (e.g., Currency, Date/Time) but these will be used infrequently in VMS, if at all. Be careful—once the characteristic is saved, the data type can no longer be changed.

Next, the maximum length of the characteristic value must be defined (up to 30 characters). This will have a direct impact when entering characteristic values. It is possible to enter values with a length less than or equal to this number, but not longer. It is possible to change the Number of Characters field after saving the characteristic, but the updated value must be equal to or greater than or the length of any defined characteristic values.

There are some variations in the next steps depending on the data type selected. For Character data type, the number of characters will be the maximum length of the value key. For Numeric data type, this will be the maximum number of integers, while a separate field will appear for the maximum number of decimals.

The Character data type also includes the Case Sensitive checkbox, which indicates if the system should differentiate between upper and lower case values. The general recommendation is to leave this unchecked so that all entered data will automatically be converted to upper case.

Finally, the characteristic must be defined as either single-value (only one option can be selected inside each vehicle) or multiple-value (more than one value can be selected inside each vehicle). Most VMS characteristics are typically single-value (e.g., one engine, one exterior color, etc.) but multiple-value characteristics could be used for packages or dealer options.

Enter the possible values for the characteristic by clicking on the Values tab. The values entered must agree with the type and length defined in the header screen. SAP requires that each characteristic value inside the same characteristic must be unique, although it is possible for the same characteristic value to appear in a different characteristic (e.g., Y or N).

If the Additional Values checkbox is selected, it is possible to enter values in the vehicle record that are not explicitly defined in the characteristic. This is especially useful with Numeric characteristics, where the value could be any number within a defined range. For example, the allowed length could be between 10 and 100 feet but the length of each vehicle is unique.

Using exterior color as an example, the value OY6 is defined for red, A4R for blue, etc. A description is not required, but should be added if the meaning of the value key is difficult to interpret. (Everybody knows that OY6 is Red, right?)

The characteristic value description will automatically be captured in the login language, but it is possible to record descriptions in multiple languages. The value key will never change, but English speakers will see the description Red, German speakers will see Rot, Spanish speakers will see Rojo and so forth.

Even though the description is basically free text, SAP also requires that the text string entered for the description must be unique for each value inside the characteristic. Blank descriptions are the only exception to this rule. This rule only applies to values inside the same characteristic in the same language key.

The following example characteristics will be used for the introductory demos.

•CAR_EXT; Exterior Color; 0Y6 (Red), A4R (Blue), X37 (Black), P3A (Green), 3H0 (White)

•CAR_INT; Interior Color; 111 (Tan), 322 (Grey), 833 (Charcoal)

•CAR_TRIM; Trim Level; LX (LX), EX (EX), ZX (ZX)

•CAR_ENG; Engine; 100 (4 valve), 200 (6 valve), 300 (Turbo)

•CAR_TRAN; Transmission; A01 (Manual), B22 (Automatic)

Defining Variant Classes

While characteristics will describe the options in the configurable material, they are never directly assigned to the material master. This assignment requires the creation of another piece of master data—the variant class. Characteristics are assigned to the class, and the class is then assigned to the material.

Classes and characteristics have a many-to-many relationship. A class may contain many characteristics, and a characteristic may be assigned to many classes. Classes and materials can have a many-to-many relationship. Many classes may be assigned to the same material, and the same class may be assigned to many materials. The material will contain all of the characteristics that are assigned to any of its assigned classes. A characteristic will only appear once, even if it is found in several of the classes assigned to the material.

While there is tremendous flexibility in the creation and assignment of these master data objects, there are some restrictions to be aware of when designing the master data model.

First, SAP has a technical limitation that only allows a maximum of 999 characteristics to safely be assigned to a single class. It is possible to assign more than 1,000 characteristics to a class, but this could result in occasional short dumps. A configurable material can still contain thousands and thousands of characteristics, but multiple variant classes (each containing less than 1,000 characteristics) would need to be created and assigned to the material master. While it is possible to assign multiple classes to a material, but there are some VMS specific limitations that will be discussed in Chapter Forty-One.

Second, once the configurable material is in use, it can be difficult to impossible to make changes to the assigned classes and characteristics. It might be necessary to recreate the material master data if wholesale changes are required in the variant configuration master data.

Creating Variant Classes (Transaction CL02)

Classes are created, maintained, and displayed in transaction CL02. Characteristics created in transaction CT04 can be assigned to the variant class, but it is also possible to create additional characteristics directly inside the CL02 transaction. Class name and class type are required fields when creating a class. This is because Classification is a cross-application solution that can support nearly every type of SAP master data (Vendors, Customers, Work Centers, BOMs, Equipment, etc.) SAP uses a different class type for each type of master data to be classified. For variant configuration, the class type is 300.

To create a new variant class, enter the class name and class type 300, and then click the create icon. Enter a description, then click the CHAR tab and assign any and all characteristics that will make up the vehicle configuration.

The characteristics created in the previous section can be entered in this screen. Once the characteristics are assigned, save the class. This completes the initial master data creation for variant configuration. Variant class CAR_CLASS will be used for the introductory demos.

Configurable Material Master

The material master is a critical master data element not only for VMS, but also for every ECC module. It is not possible to create a vehicle record until the material master has been properly defined. There is an extremely tight relationship between the vehicle record and the material master.

Similar to the other master data elements discussed in this chapter, there should be considerable examination of the business requirements before any material masters are created. However, this detailed modeling discussion will be delayed until Chapter Four. This chapter will only explain how to create a material master for use in VMS.

Creating a Material Master (Transaction MM01)

MM01 is the standard transaction to create a material master. Required fields are the material name (either a logical external number or an internal counter), an industry type (not critical for this discussion), and a material type (very critical for this discussion).

SAP developed a new material type specifically for VMS: VEHI (Vehicle Configurable). It is not mandatory to use this material type, as almost any material type will work in VMS provided the underlying IMG settings are defined correctly.

If a different material type will be used in the VMS implementation, it is critical that the following attributes are defined:

•The material type must support variant configuration. For VEHI, the checkbox Material is Configurable is preselected and greyed out in the Basic Data 2 view. It is possible to use other material types that are not by default configurable (i.e., FERT or HALB), but this checkbox must be made available so that it can selected in the material master.

•The material type must allow quantity and valuation updates in the plant code defined for VMS. It is possible to determine if the IMG settings have been maintained correctly in the Accounting 1 view: the settings are complete if the field Valuation Category is selectable and the valuation type X (automatic batch) is available for selection.

If X cannot be selected as a Valuation Category in the Accounting 1 view, review that the following settings have been made in the IMG.

1. The material type must be defined for Split Valuation in the appropriate plant codes. This can be done in the