IAU270 SAP for Automotive: Vehicle Management System
Coll:96
Material Number: 50126871
The diagram above shows an example of a vehicle distribution chain.
Suppliers deliver components to the OEMs
OEMs assemble the vehicles
The vehicle passes from the OEM to a local sales distributor or an importer
The Importer/Distributor sells the vehicle to its Dealer network
The vehicle finally arrives at the end customer
The Vehicle Management System can be used to manage the flow of vehicles from
OEM to End Customer.
VMS is installed at the Importer or Sales company. They will then purchase vehicles
from the OEM and sell them to their dealer network.
VMS was originally developed as a solution to be used by the Importer/Distributor. For
this class, we will primarily focus on this scenario.
There have been additional developments to expand the solution to match
requirements of other business partners in the distribution chain (i.e. direct sales from
the OEM to dealers)
This slide shows the classic VMS implementation scenario.
The solution is hosted by a Distributor/Import company
Vehicles are purchased from 1 or many OEMs
Vehicles are sold to 1 or many Dealers
Vehicle information is maintained and updated in Distributor/Importer system. The
Distributor/Importer communicates with its business partners through interfaces to
the OEM and Dealer systems.
This slide shows a typical business process handled by the VMS
Procurement Scenario
The Distributor order the vehicle from the OEM
The OEM confirms the order
As the vehicle is assembled, the OEM sends updated status information
The vehicle is received at the Distributor
The OEM sends an invoice for the vehicle
Sales Scenario
The dealer logs in via the web and places an order for the vehicle
The Distributor delivers the vehicle to the Dealer
The Distributor bills the Dealer for the vehicle
The Dealer provides payment
VMS is a database that is used to capture information about all your vehicles.
With this central database, multiple users can log in and carry out your business
process. Here are some of the functions that are made possible:
Vehicle search and Locating: Dealers access the system and look for cars with certain
characteristics. Distributors look at vehicle inventories across their dealer network
Vehicle Configuration: A custom car can be configured to match exact customer
requirements.
Vehicle Administration: Detailed information (Vehicle ID Number, Registration,
Documents) can be added to each vehicle record.
Business Integration: SAP ERP documents (Purchase Order, Invoice) are linked to the
vehicle
Status Tracking: The Dealer or Importer can see the current status of the vehicle and
when it is likely to arrive.
Follow ups: The Importer does Dealer Invoicing and Profitability Analysis after
delivering the vehicle
Central transaction for all business processes (cockpit approach)
Here are the major functionalities available in the VMS. All these functionalities
are found in one transaction, VELO
Function VLC_CALL_SCE
Importing
kmat
hookurl
bapicucfg bapicuins bapicupart bapicuval
Exporting
bapicucfg bapicuins bapicupart bapicuval
rcode
Here is a screen shot of the Vehicle Manager (transaction code VELO) screen.
From this one window, you will be able to perform all vehicle related processes
and functions. To navigate through the various functions, you will click on the tab
screens highlighted above. The function of each tab will be described in detail in
the next few slides.
Click the FIND tab to conduct a vehicle search. First, select the vehicle models
(material master) you wish to look for. You can search mulitple vehicle models at
the same time. Next, enter your search criteria. In addition to configuration
values, you can restrict your search by looking for vehicles with certain SAP ERP
documents, business partners, or status. It is possible to save this criteria in a
user Search Profile. Simply call up the profile and the system will populate all the
fields.
You can also search for individual vehicle records. Enter the Internal Number
(SAP Key Field), the External number, or the Vehicle ID number in the top right
corner.
The system will return a list of all vehicles that meet your search criteria in the
OVERVIEW window. The number of matching vehicles is shown at the top of the
list. To reduce the number of vehicles, you can deselect attributes (click on the
attribute to turn the green light to red).
You can review the data of these vehicles by scolling through the table. You can
also change the table display (hiding fields, sorting, grouping)
Click the DETAIL tab to see more information about individual vehicles. There is a
different set of data under the 5 pushbuttons.
Customer Data – displays information about the Dealer
End-Customer Data – displays information about the Driver
Vehicle Data – shows the status, location, business partners
Configuration – shows the vehicle attributes (color, engine, transmission, etc.)
Vehicle History – shows all actions performed for the vehicle. Some entries also have
links to SAP ERP documents
Actions are used to move the vehicle through the business process. It is possible
to execute an action for multiple vehicles.
Select the vehicles you wish to process, then select the action from the Action Bar
drop down window.
After selecting the action, a subscreen will appear where you can enter further
data. This example shows the action for Create Sales Order. Some of the
information required for this action is Customer, Purchase Order Number, Delivery
Date, and Sales Organization.
Click the Execute Action button. The system will now perform the action, update
the vehicles, and record the vehicle history.
Click the Log button to see details of how the system processed the action.
There is a lot of information that can be stored against each vehicle record. It is
also possible to extend the database with customer fields.
Each vehicle has an internal number. This is the unique key field used in the
VLCVEHICLE table to keep track of all vehicle entries.
Using the example above, 815 is the internal vehicle number. Against this key
field, the user can maintain additional data such as VIN, status, documents,
configuration, and history.
While the system defines the internal number as the key field, Vehicle
Identification Number and External Number are two standard fields in the
VLCVEHCILE table that can be used to track unique vehicle records.
It is important to keep in mind that a vehicle doesn’t have to physically exist to be
tracked in the database. Simply create a new record and the system will generate
a vehicle record with a new unique internal number.
Now the vehicle can be tracked as it moves from planning, through production,
through inbound logistics, through the dealer network (or whatever your business
process may be)
Let’s consider this difference in vehicle visibility between standard SAP ERP and
the VMS.
SAP ERP has been implemented at the distributor. MM is used to issue purchase
orders to the OEM and SD to capture sales orders from the dealers.
Once the OEM receives the PO, the vehicle is put into production. The finished
vehicle is put on a ship and finally arrives at the Distributor.
Despite all these steps, the vehicle only becomes visible in SAP ERP when the
GR is posted (Goods Receipt 101 movement increases physical stock)
The Distributor sends the vehicle to the dealer and posts a goods issue. With this
posting, the vehicle is no longer visible. However, your business process might
include a number of steps that take place after the goods issue.
Bottom line: in the standard SAP ERP scenario, the vehicle is only visible while it
is in the Distributor’s physical inventory.
Let’s now consider the same scenario, this time using VMS.
A vehicle record is created when the Distributor places a Purchase Order. The
vehicle is now visible.
The Dealer searches the database, finds the vehicle and creates a Sales Order.
The vehicle is assembled, exits the factory, and is sent via ship. All these steps
are tracked in the VMS.
The vehicle arrives at the Distributor. Goods Receipt posting increases physical
stock. The Distributor can use VMS to search for all vehicles on its lot.
The vehicle is sent to the Dealer. Goods Issue reduces physical inventory, but the
Distributor can still track the vehicle at the dealer and even to the end customer.
Bottom Line: by creating a vehicle record, the vehicle is visible and traceable
throughout the entire supply chain.
Every SAP ERP user is given a user ID that will contain personalization (favorite
transactions, default data) and authorization (allowed transactions) elements. As
VMS is one transaction in SAP ERP, this user concept is maintained. However,
there are VMS specific elements that must be maintained for each user.
The concept of VMS is to have one database with all vehicle records. While many
different people can access the database, user profiles allows you to control the
specific data they can see and the activities they can perform.
Default settings per user can be maintained via
VMS roles or
Set/Get paramters
The definition of organizational data in the VMS role is used as default settings for
the web access. Set/get parameters (belong to a system user) can be used as
well, they would overwrite the VMS role definition.
VMS roles differ in:
- Organizational Data
- Vehicle Models
- Configuration Profiles
A system user can be assigned to several material roles and several configuration
profile roles: but only one organizational role is allowed (due to unambiguity)
Configuration roles will be discussed in the Make to Order chapter.
Roles are defined in the IMG, and consist of a 4 digit code and description. There is no
setting to specify if a role is to be used as an Organizational role, Material role, or
Configuration role. That determination is made by adding data in transactions under VMS
> Basic Data > VMS Roles
The role must be created in VMS customizing. Note that the only information to
be entered for a role is a description. (There is no flag for Org Role, Material Role
or Configuration Role)
Once the role has been defined, transaction VELORO and VELORM can be used
to assign organizational data and/or material masters.
By assigning this data, the system will determine if the role is an Org Role,
Material Role, or both.
With transaction VELORU, the Org and Material roles are assigned to the End
User.
Note that an user can only be assigned 1 Organization Role! The system will
create an error message when you attempt to assign a second org role. There is
no such restriction for Org Roles.
Roles can be assigned to multiple users. Users can be assigned multiple roles
(though only 1 Org role)
Based on role assignments, each dealer is only able to see
Certain vehicles (based on assigned model vehicles)
Certain end customers (based on which Dealer (customer) created the record in the
system)
(This slide for animation. Please see comments on the next page)
Each step in the business process is modeled in VMS through Actions. By
executing an action, you can update the status, availability, and/or location for
each vehicle.
Some actions can create business documents in SAP ERP, such as Purchase
Orders, Sales Orders, or Equipment Masters
It is possible to develop and use your own actions. This allows you tremendous
flexibility in building your business process.
Actions must be defined as Primary (related to procurement), Secondary (related
to sales), or both. There will be more detailed information about actions in the
chapter on configuration.
What purpose do actions serve? Here are some examples of how actions can be
used to support your business process.
Actions triggered in VMS can create/update documents in SAP ERP.
What purpose do actions serve? Here are some examples of how actions can be
used to support your business process.
VMS is a very flexible tool because it allows you to map YOUR business process.
However you may procure and sell vehicles, it is possible to map your specific
process in the VMS.
The key is to identify each step, and the sequence of each step, in your process.
In the slide above, we can see the 9 steps that are required to bring the vehicle
from OEM to Dealer.
As each step in the business process is carried out, the status of the vehicle is
updated. This change in status is useful as you can:
Search for vehicles at certain stages in the business process
Control the sequence of steps. You will learn that status determines which action can be
performed next.
In addition to updating status, vehicle availability is an additional attribute that can
be updated as you move through the business process.
Vehicle Location can also be updated by executing the business process.
The Action Matrix is essential to model your business process. Let’s use this
example of a primary matrix to see how the matrix is designed.
STATUS is listed in the far left column and the row across the top.
ACTIONS are listed in the middle of the matrix.
Starting with Current Status = Blank, the 2 actions that can be performed are
“Create Vehicle” or “Create Vehicle & PO”
If you select “Create”, status will change to Created. If you select “Create &
Order”, status will change to Ordered.
The New Status is adopted as Current Status. Assume you chose “Create”. The
status is Created, the only action you can perform is “Order”.
Status is now updated to Ordered. The actions you can perform are “Modify
Order” or “Confirm Order”
Continue in this manner through the matrix. The final action you can perform is
“Finish Purchase”.
The current status of the vehicle will determine which action you can perform.
This ensures that you will perform each action in the correct sequence.
In addition to current status, you can also update Availability and Location by
executing actions. You will learn how to define an action matrix in the chapter on
Configuration.
Here you can see an example of how a vehicle record is updated by executing an
action. On the left, you can see the current Primary Status (related to vehicle
procurement) and Secondary Status (related to vehicle sales). You can also see
the Location and Availability.
An action is triggered for this vehicle. The action must be allowed by the action
matrix (depends on current status)
The action is performed. Based on the configuration of the action matrix, the
system can update status and/or availability and/or location.
Note that you can perform an action without updating any of these attributes.
For this example, the system updated Secondary Status (Vehicle Reserved >>>
Vehicle Sold) and Availability (Reserved >>> Sold).
Here is screen shot of a vehicle detail screen. You can see the Availability,
Location, Primary Status and Secondary Status for this vehicle record.
Click on the icon next to the status and the system will display the matrix in a popup window.
The display of this matrix is slightly different from the previous slide. The basic
concept is the same. See if you can follow the business process defined in this
matrix.
Every vehicle will be assigned 2 matrixes: 1 for primary actions and 1 for
secondary actions.
The setup of these matrixes will be covered in more detail in the chapter on
configuration.
It is possible to create multiple action matrixes. Each matrix can be used to
represent different business process.
For example, a vehicle might be produced domestically or imported. The
procurement process would be different in this case.
Another example, a vehicle can be sold to company branches or an independent
franchise. The sales process may be different.
Because it is possible to define multiple primary and secondary matrixes, you
must define rules that tells the system which matrix to select. This setting is made
in transaction VELOS. Fields used in this selection process are shown above.
The more criteria you fill in, the more specific the selection process.
You cannot have duplicate or ambiguous entries. The system must be able
determine which matrix to select.
When you built your action matrix, there was no formal setting to determine if a
matrix is primary or secondary. This determination is made in this table only.
Based on the selection criteria, the system will assign the matrix entered in the
Primary Action Control field as the vehicle’s primary matrix and the matrix entered
in the Secondary Action Control field as the vehicle’s secondary matrix.
Once the matrix is assigned to a vehicle, it is assigned to the vehicle record
forever. You can change the contents of the matrix, but you can not assign a new
matrix to the vehicle.
To use the Vehicle Management System, there are several types of master data
that must be maintained.
Some of this master data is specific to VMS. However, most of this data would
already be maintained during a standard SAP ERP implementation. VMS allows
you a one screen transaction to carry out all activities related to vehicle
procurement and sales in SAP ERP. While the access is from one screen, the
appropriate settings must be maintained in ERP areas such as MM, SD, FI, CO,
PP, etc.
This chapter will focus on three main sets of data:
Material Master: VEHI is the new material type developed for use in VMS
Variant Configuration: Essential for modeling configurable products, this is
identical to standard SAP ERP.
Business Partners: Here you will define the companies and individuals you buy
from and sell to.
A material master must exist for every vehicle type you wish to process in VMS.
There is a new material type specifically developed for the VMS called a VEHI
(short for VEHICLE)
This material type allows you to uniquely configure every vehicle. This is similar to
the material type KMAT.
Unlike a KMAT, you can receive this unique vehicle into stock. Standard SAP
ERP requires that you first have a sales order.
In this manner, you can first order and receive a fully configured car from the
factory, and later sell the vehicle to your dealers.
You can maintain various plant specific views for your VEHI, such as purchasing,
sales, etc. Most of these views would be maintained as you might for any material
type. However, in some views, there are some specific settings that must be
maintained for a VEHI. The next 2 slides will highlight these specific settings.
Basic Data 2: The “Material is Configurable“ flag must be set
Accounting 1: Valuation category must be set to X (automatic batch determination)
Classification: a variant class (type 300) must be assigned to the material.
If the VEHI is a material variant (pre-defined configuration values), you can
populate specific values for the characteristics in this screen view.
Products with a large number of variants have a vast selection of combinations of
individual product features.
As you would expect, complex products are reflected in complex configuration
tasks in sales and production. However, a company that sells or produces
products with variants must perform these configuration tasks quickly and
accurately. With product development and life cycles becoming shorter and
shorter, this is no easy task.
Variant configuration is for manufacturing complex products. The manufacturer is
always having to offer new variants of its products. Often, new variants are
created by modifying existing product designs as you process the order.
The customer determines the features of the product. A customer buying a car, for
example, can choose the features of the car and combine these features as
required.
A configurable material is what we call a product that is produced in multiple
variants. The configurable material covers all possible features of the product, so it
is not a finished product in itself.
In the SAP ERP System, we use characteristics to describe the features of
configurable products.
Classification is used widely throughout SAP ERP. It is possible to classify just
about every type of master data in the system. Different types of master data will
be assigned a specific Class Type. For example:
Vendor master data will be classified using Class Type 10.
Work centers will be organized using Class Type 19.
Material Masters can use several class types. Each Class Type serves a unique
purpose. For example, 001 is used to model standard (i.e. never changing)
attributes for a material.
Variant Configuration requires Class Type 300
Variant Configuration requires Class Type 300. This is the class type we will use
in this class.
In transaction CL02, you can create a class (specify a name and class type)
Once you have created the class, you can maintain information in the tab screens
shown above.
To use this class, you must maintain information in the Basic Data and
Characteristics tab.
Classes can also be arranged in a hierarchy. This allows you to build a product
class hierarchy. The properties and features of the product class are called
characteristics and characteristic values.
The classification system allows you to use characteristics to describe objects,
and to group similar objects in classes – to classify objects, in other words.
Characteristics are used to define the attributes of the variant product. For
example, you might define characteristics for Engine, Exterior Color, and Fuel
System.
You must maintain the Basic Data and Values for each characteristic.
Characteristics are assigned to the Class in the Classification screen. If the
characteristic does not yet exist, the system will allow you to create it directly.
You must specify the characteristic format in the Basic Data screen.
For this class, we will only define CHARACTER (text) data types. You must also
specify the maximum length of each value.
You can specify if the characteristic is required or not. If it is required, the user is
forced to populate a value for this characteristic.
Depending on the Data Type selected, you will next maintain values. Since only
data type CHAR is used for this class, you will define a limited set of Constant
values.
Example:
For characteristic ENGINE, you define values “4V” (4 Valve) and “6V” (6 Valve).
For characteristic COLOR, you define values “F66” (Red), “W67” (Blue), and “F99”
(Green)
You can define if only 1 or multiple values can be selected. For example, you
define a characteristic OPTIONS that allows the user to select several items from
a list of optional accessories.
You must assign the characteristic to the class.
The Variant Class is assigned to the VEHI in the Classification view.
The VEHI will now adopt the characteristics assigned in this class.
You can assign this one class to multiple VEHIs
The features of a product are stored in the SAP ERP System as characteristics.
You define characteristic values for each characteristic, then assign these values
to the configurable material.
You assign the characteristics that describe the configurable product to the class.
You allocate the configurable material to the class, so that you can use the
characteristics of the class to configure the material.
In this example, when a customer orders CAR_A, he can select the Body Type,
Transmission, Engine, etc. he want for his specific car. Another customer can
order CAR_A with a completely different set of values.
The previous example showed a fully configurable car, where the customer can
(and must) specify values for every option.
This example show a partially configurable car. Because some characteristics
already have values assigned, the customer must order the car with these values.
Note that there are some characteristics where the customer can still specify his
choice (for example, Color and Trim)
Note: With a fully configurable car, you only need to maintain ONE material
master. With a partially configurable (or non-configurable where all options are
selected), you will need to maintain MANY material masters.
In variant configuration, a class groups together the characteristics that describe a
configurable material.
In the standard system, you can only use classes that have class type 300 for
variant configuration. You set the indicator to allow configuration for a class type in
Customizing for the classification system.
You must create the configuration profile in order to use the VEHI in VMS.
Here is a view of the Configuration Profile details. Not that it makes a connection
between the Material and the Variant Class (identical to the setting you made in
the material master)
You can also use the configuration profile to assign and maintain object
dependecies. Object Dependencies are used to define how characteristics relate
to each other (example: the allowed values for Interior Color depends on the value
selected for Exterior Color) You will also maintain pricing rules in the
Configuration Profile (example: the customer must pay an additional $500 for the
6V engine)
Object Dependencies will be discussed in more detail in the next few slides.
Variant Configuration is a standard SAP ERP functionality. The steps described in
this chapter are for reference only. If you wish to learn more about this topic,
please sign up for the standard training on Classification and Configuration.
There are many different types of Object Dependencies. Each type is designed to
perform a slightly different function. Object dependencies can be assigned to
many different types of master data, such as BOMs and Routings. The type of
master data restricts the types of Object Dependencies that can be assigned.
This slide show the complete set of master data that must be maintained for
variant configuration.
Characteristics are assigned to a Variant Class
The Variant Class is assigned to a Material Master
The Variant Class and Material Master are linked again in a Configuration Profile
Constraints are assigned to the Configuration Profile (directly or through a
Dependency Net)
Special Characteristics:
In order to enable variant pricing conditions, you must maintain special
characteristics. You can assign any name to these characteristics, but the
contents must match the screen shots above.
For SD pricing, assign Table SDCOM, field VKOND in the Additional Data tab
For MM pricing, assign Table MMCOM, field VKOND in the Additonal Data tab.
The system will format the rest of the fields automatically (i.e. Data type, length of
value)
These new characteristics will be used in a Pricing Proceedure assigned to the
Configuration Profile.
The screen shot at top shows sample coding. (Select condition 5115 when the
value for characteristic Wheels is 5115)
You must then maintain Variant Pricing conditions (Condition type VA00) This is a
standard SD function.
Result: when the user selects Wheels 5115, a surcharge of 344.83 EUR will be
added to the Sales Order.
All master data must be created an maintained in SAP ERP. Once the data is
built, you can now fully configure your VEHI.
This configuration can be done in standard SAP ERP or on-line in the Internet
Pricing Configurator CRM component.
If you you choose to do your configuration inside SAP ERP only, please maintain
the following SET/GET parameter to your user profile: VELO_CU50_ACTIVE =
“X” (Must be Capital X)
If you choose to use the IPC, you must transfer your data from SAP ERP using
the steps defined in the following slide.
Step One: Create a configuration profile. You have already done this step.
Step Two: Create a Knowledge Base. When you create a new profile, the system
will ask you to assign a material. Enter your VEHI in this field.
Step Three: Create a Run Time Object. This will transfer all configuration data for
your VEHI to the IPC.
Your instructor will show you more details about this process, although there may
or may not be an IPC used in this training.
Business Partners are the companies or individuals from which you buy and to
whom you sell goods and services.
All the business partners listed above are used in standard MM or SD. With one
exception.
With VMS, there is a new Business Partner type for End Customer. Since the
VMS is implemented at a central distribution company, the vehicle customer is the
Dealer and not the eventual end user. A new business partner type was created
to capture information about this important individual
For vehicle procurement, the OEM will must have Vendor Master record defined.
A standard info record must also be created that defines the standard purchase
price of the VEHI. (You can define variant MM pricing using the techniques
explained earlier in this chapter)
You can also define a rework/accessorization partner. This will be a subcontractor
who helps prepare the vehicle before delivery to the dealers. You must define a
vendor master record and a subcontracting info record.
For vehicle sales, every dealer must have a customer master record defined in the
system.
The new buiness partner type is the end customer. This can be maintained
directly in the VMS and can be related to a specific dealer. Since the sale is made
to the Dealer, the end customer is not necessarily required to complete the sales
process.
This chapter will address the following topics
The Make to Stock Business Process
Hide and Show – special actions used to prevent certain users from locating vehicles
Category Management - rules to restrict search results for certain users
Reservation – allocating vehicles to dealer
The MTS business process is based on the push principle – OEM pushes cars to
the distributor who pushes cars to the dealer. In this scenario, vehicle
manufacturing comes first. All sales are made from existing inventory.
This is a typical MTS business process flow. Note that the vehicle is
manufactured before a sales order has been received.
The basic flow of the vehicle is OEM > Distributor > Rework (for accessories or
localization) > Dealer
The slide also demonstrates the HIDE/SHOW actions. In this example, the
vehicle is hidden from dealers until after production starts. In this manner, dealers
can only see already built vehicles when they search the VMS database.
The field visibility controls the acess to vehicles. Two values are available for this
field:
„X“ for „visible“ and
„ „ (initial) for invisible.
Action SHOW and action HIDE fill field Visibility VBLT in the vehicle table
VLCVEHICLE with valid values.
Per default the field visibility is initial (means „invisible“).
The usage of this field require definitions in category management or in the Badi
for the search functionality (can be personalized). If neither Category Management
nor the Badi is used, all users can access all vehicles.
This screen shot displays a list of vehicles. Note the 1st column where vehicles
are Visible (action SHOW has been executed) or Invisible (either HIDE has been
executed or SHOW has not yet been executed)
Category Management:
The Vehicle Management System consists of a database that contains information
for ALL vehicles. This database is then accessed by ALL users. Category
Management allows you to restrict the vehicles each user may see.
You have already learned that Material Roles can be used to restrict the vehicles a
user can see. If the VEHI is not assigned to the user, they cannot see any
vehicles created for that VEHI.
Category Management works with the users Organizational Data Role. You can
define rules that restricts which vehicles are visible based on attributes associated
with the vehicle, the user, or both.
The 3 dealers enter the exact same search criteria (done in the foreground).
Category Management further restricts which vehicles each dealer can see (done
in the background). In this example, the search parameters are the same but
Dealer A finds 94 vehicles, Dealer B finds 50 vehicles, and Dealer C only finds 30
vehicles.
This slide shows an example of 3 rules, or categories, that have been maintained.
These rules are assigned to the user via the Organizational Data role.
The user can only find cars that meet the criteria of Rule 1 OR Rule 2 OR Rule 3.
This means the vehicle will be visible if it meets the criteria for AT LEAST ONE of
these rules.
Vehicles that match any one of these rules will be visible.
Vehicles that DO NOT match any of these rules will NOT be visible.
In this example, Rule 2 contains an AND statement. This means the vehicle must
meet BOTH criteria to be visible.
Defining the rule is a pretty straightforward processes. There are 3 standard
tables that each contain many fields. To create a category, simply select the fields
(i.e. Visibility) and the desired condition (i.e. “X”).
The 3 standard tables are VLCVEHICLE (attributes related to the vehicle),
VLCSEARCH_USER (attributes related to the Organizational Role of the User),
and VLCSEARCH_ADD (additional attributes assigned to the vehicle)
Categories are then assigned to the Organizational Role.
Here we can see that 3 categories have been assigned to Organizational Role
DL01.
All users who are assigned this Organizational Role will only see vehicles that
match the criteria defined in category DEALER or AVAIL02 or VISIBILITY
Double click on the category to see its contents. Here we can see the logic
behind category DEALER.
Show all vehicles where Customer for vehicle matches Customer defined in the user’s
Organization Role
To create or maintain a rule, click on the Table Name, the Field Name, and the
Program pushbuttons (on the far right)
When the status light turns green, the syntax of your rule is correct.
Search Areas allows a further refinement of category management. In this
example, there are 3 dealers in different parts of the country. Assume that the
same categories have been assigned to each dealer.
In this example, New York dealer places an order to the OEM in Chicago. The
OEM ships the vehicle to the New York dealer.
The vehicle (111) is now on his lot; Visibility = Visible (X) and Availability =
AVailable.
The Seattle dealer searches the VMS and locates car 111. He asks NY Dealer to
transfer the car from New York to Seattle.
If the transfer is allowed, the vehicle will travel from Chicago to New York to
Seattle. Transportation cost for this vehicle will be extremely high.
Because transportation cost will consume all of the profit, it makes more sense for
the OEM will build a new car (112) and send it to the Seattle dealer.
Search Areas is used to enable this business process; dealers are now only able
to locate vehicle 1) that meet assigned categories and 2) are assigned to their
region. Using search areas, the New York Dealer can only find appropriate
vehicles in region EAST, the Seattle Dealer can only find appropriate vehicles in
Region WEST, and the Houston Dealer can only see appropriate vehicles in
region SOUTH.
The use of Search Areas requires a little more set-up than simple Category
Management.
First, categories must be assigned to a Search Area/Org Role combination.
Previously, categories were assigned without reference to Search Area.
Next, the Vehicle Search Area must be defined in the user’s Organization Role
Finally, the Search Area must be defined for the Vehicle.
Here we can see that 3 categories have been assigned to Organizational Role
DL01 in Search Area EAST.
All users who are assigned this Organizational Role and this Search Area will now
only be able to find vehicles that are assigned to the Search Area AND match the
criteria defined in category DEALER or AVAIL02 or VISIBILITY
Reservation Queue – this feature is used to allocate vehicles to dealers. The
queue allows dealers to “stand in line” for specific car. There is no obligation to
buy the car, but only the dealer “first in line” can order the car. Limited valuation
ensure that this dealer only has a limited time at the front of the line; if he doesn’t
buy the car in time, the next dealer in line receives the privilege to buy.
Reservation queue business process:
The vehicle is reserved for Dealer A (this can be done by the dealer or the distributor)
Dealer B and C line up for the car by creating a Reservation Request.
Only Dealer A can buy the car. The system will block Dealer B or C if they try to order the car.
Reservations are of limited validity. When Dealer A reserves the vehicle, the
reservation is only valid for 3 days.
When Dealer B and C create their reservation requests, the validity of their
request is also 3 days. The to/from date of their request is offset by the end date
of the previous reservation.
A report can be run to automatically update the reservation queue. If Dealer A
fails to order the car in time, the system will automatically update the reservation
for Dealer B.
The 3 day value is defined in the specific action. If your company has a different
reservation policy, simply copy the existing standard action into a Z program and
modify it according to your rules. Action programming will be discussed in a later
chapter.
Reservation Actions:
The 1st dealer will create a reservation (action RSVN)
Then 2nd to Nth dealers will create a reservation request (action RSVM)
Business documents can also be created along with the reservation
Action OFFE creates a quotation. Action IQRY creates an inquiry
The reservation and business document can be created by executing a single
action
Action RSOF creates the reservation (RSVN) and the quotation (OFFE)
Action RSIQ creates the request (RSVM) and the inquiry (IQRY)
There are also standard actions to delete the reservation and business
documents.
If your organization has a different business process, you can substitute these
actions for your own.
Reservation Queue: Details
You have seen the Reservation pushbutton in the Vehicle Data Details screen. If
there are active reservations, the Attachment icon will be seen to its right. Click
the pushbutton and resulting popup window will show you all reservations and
requests for this vehicle.
Note that only the first reservation has status green. This means that the vehicle
can only be bought by this customer. All other customers must wait until their
request becomes valid.
This chapter considers the Make to Order business process. Additional topics
discussed in this chapter are:
Configuration Change profiles: how to freeze characteristics based on the
business process
Interlinking Actions: how to define an action that can perform multiple steps
The Make to Order business process is similar to Make to Stock. The vehicle
flows from OEM to Distributor to Dealer. There is one key difference however.
While Make to Stock operated on the Push Principle, Make to Order is based on
the Pull Principle – the End Customer orders the car from the Dealer who orders
the car from the Distributor who orders the car from the OEM. Without the End
Customer order, the vehicle will not be built.
The difference between Push and Pull can be seen above. In the MTO scenario,
the Dealer Order comes first. In the MTS scenario, it came at the end.
Here is an example of a MTO business process. In this case, Customer Order is
the first step of the process. The remaining steps are similar to the MTS scenario
(Purchase Order create, Production, Receipt, Delivery to Dealer)
In the MTO scenario, the customer orders his dream car, fully configured to his
exact specifications. This is enabled with Variant Configuration.
Sometimes, the customer might want to change these specifications. Using
Variant Configuration screens, he can change the color or engine etc.
Once production starts, it may no longer be feasible for the customer to change
his mind. For example, once the body has been painted, the customer should not
be allowed to change the color.
Configuration Change profiles allow you to define when a specific characteristic
can longer be changed. Also, they can also define when specific characteristics
can be changed.
In the example above, all characteristics can be changed until the OEM confirms
the PO. Then only some changes are allowed. No changes are allowed when the
vehicle is in transit.
Model, chassis + Motor from „3 days before Production“, cannot be changed from
status P050
Add-ons are only possible after VIN assignment
Here is a further example of the effect of Configuration Change Profiles.
Depending on the status of the vehicle, some characteristics are made visible,
hidden, or become display only.
Note: Configuration Change Profiles can only be used with the Internet Pricing
Configurator. Without this component, you cannot restrict dynamic configuration
change.
Defining Configuration Profiles is a two step process.
First, you must define the characteristics that will be affected by the profile. Then
you must define if the characteristic will be hidden or display only.
Second, you must determine when the system will activate the profile. The more
specific the determination, the less often the profile will be active.
Example:
If you only populate Material, then the specified characteristics for all vehicles of that VEHI
will be hidden or display only.
If you populate Material and Availability, then those characteristics are hidden/displayed
when the VEHI has a specific availability
Note that ROLE is selection criteria. This allows you to change characteristic displays based
on users.
Note: Configuration change profiles only work with the IPC. You cannot use
dynamic configuration freeze in standard SAP ERP.
Continuing the previous slide, it is possible to define Configuration Roles. By
assigning these roles to the end user, certain characteristics are hidden or
become display only.
Note: Configuration change profiles only work with the IPC. You cannot use
dynamic configuration freeze in standard SAP ERP.
Interlinked actions combine several actions in a sequence.
The user executes only a single action, while the system performs multiple actions
step by step.
You have already worked with Interlinking actions in this course
ORD2 (Create Vehicle and Purchase Order) is an example of an interlinked Primary
Action
RSOF (Create Reservation and Offer) and RSIQ (Create
Interlinked actions can contain both Primary AND Secondary actions.
In this example, CRCO is built from action CREA and action CUOR. CREA will be
performed first, then CUOR as a second step.
It is possible to link actions from both matrices, primary and secondary. In this
case, the interlinked action has to be maintained in both matrices.
It might be necessary to maintain a unique subscreen (dynpro) to process the
interlinked action.
The subcreen for CRCO is differernt from the subscreen for CREA and for CUOR
Example of Interlinking Action ZCRC – Create Customer Specific Vehicle
The purpose of this action is to distinguish between vehicles created by the
Importer (for planning) and “Customer vehicles” created by the Dealers.
The dealer peforms action ZCRC for selling a customer specific vehicle
When the Dealer executes action ZCRC, the system will
create a vehicle (CREA)
mark the vehicle as a customer vehicle (ZCUD)
and create a sales order (CUOR)
The status change action ZCUD indicates that this is a customer specific vehicle.
Action ZCUD is defined as a primary and secondary action, so the status change
happens for both the primary and secondary status.
The importer can select via the statuses (awaiting PO and/or customer vehicle
created) these vehicles, check and order them.
Example of Interlinking Action ZORD – Purchase Customer Vehicle
The Importer searches for all customer specific vehicles.
Primary and Secondary status equals that set by action ZCUD
The Importer must now order these vehicles from the OEM
When the Importer executes interlinked action ZORD “Purchase Customer
Vehicle”, the system will
create a purchase order (ORD1)
confirm the customer vehicle (ZCOF)
The status change action ZCOF indicates that the Importer has ordered the
customer specific vehicle.
Action ZCOF updates the secondary status of the vehicle to indicate the customer
specific vehicle is accepted and ordered at the OEM. ZCOF is only intersted in the
primary matrix for checking purposes.
Dealer searches for vehicle and if a match found, a sales order is created for the vehicle.
If no match found, then he creates a new vehicle and a sales order.
Dealer searches for certain vehicles and if no suitable match exists, the dealer creates a
sales order for the vehicle configuration. No vehicle is created.
The importer can then search for existing vehicles in his pipe line against the dealer order,
and based on the close fit criteria (can be defined in a BADI) appropriate vehicles can be
selected against the sales order configuration.
The sales order and the vehicle configuration can be compared using a compare function.
If the vehicle is found suitable, then a reservation for the vehicle is created against the sales
order.
This reservation is described as a loose link.
In the next step, the dealer can confirm the reservation, and this will be
a tight link in the VMS.
Late Order Assignment Functions
Ability to create sales order and then assign the order to a vehicle object in VMS.
Create a sales order outside VMS (
On item level, enter
SAP SD, SAP CRM)
material master = vehicle model
quantity = 1
configuration
no batch number
In VMS, search for sales order w/o vehicles (item level)
Search for vehicles that fulfill match criteria
Assign sales order to vehicle.
To build an action matrix, there are 4 elements that you must define. The
elements are Actions, Status, Availability, and Location
Actions and Status are the only mandatory elements in an action matrix. You do
not have to define Availability or Location to create a “complete” action matrix.
You can build a Primary Matrix and a Secondary Matrix. The Primary Matrix will
host Primary Actions (related to procurement) while the Secondary Matrix will host
Secondary Actions (related to sales). These entities usually operate
interdependently of each other (example: Goods Receipt is a primary action,
Goods Issue is a secondary action. You can not perform Goods Issue without first
performing Goods Receipt), although it is possible through interlinking actions to
connect the two.
Once you have built the matrix, you must define how the system will select which
matrix to use.
Actions represent the individual steps in the business process. SAP delivers
many standard actions with the VMS. You will learn how to define additional
actions later in this chapter.
Unlike status, actions are defined as Primary, Secondary, or Both. Only Primary
actions may be assigned to a Primary matrix and vice versa. Actions designated
at both Primary and Secondary must be assigned to both matrixes.
All the Procurement related steps will be listed in the Primary matrix while the
Sales related steps will be listed in the Secondary matrix. This is only a general
guideline: you can define actions as primary or secondary as you like.
Status is 100% configurable. SAP provides an empty table; you may make any
entry you like.
Status is a 4 digit field with a description
You can use a status in a primary matrix, secondary matrix or both.
There is no distinction for which matrix a status may be used in.
The action matrix combines the status and actions. By executing a primary action,
primary status will be updated. Similarly, executing a secondary action will update
the secondary status.
The resulting primary status determines which primary action can be performed
next. The resulting secondary status determines which secondary action can be
performed next.
This slide was seen earlier in this course. It demonstrates the relationship
between action and status in a primary matrix.
Action and Status are the minimum requirements to create an action matrix. The
following slides will show some additional attributes that can be included in the
action matrix configuration.
The action matrix combines the status and actions. By executing a primary action,
primary status will be updated. Similarly, executing a secondary action will update
the secondary status.
The resulting primary status determines which primary action can be performed
next. The resulting secondary status determines which secondary action can be
performed next.
Because a vehicle doesn’t have to physically exist to be tracked in the VMS
database, location is a key field to help identify where in the physical supply chain
the vehicle exists. The location can be updated automatically by executing
actions in the action matrix.
Using the location field, you can see which vehicles are at the OEM, which
vehicles are en route, which vehicles are at Dealer 12.
In this example, when the user performs action Confirm PO, location is updated to
“OEM”. When the user next performs Manufacturing Finished, location is updated
to “At Sea”.
It is also possible to calculate planned delivery date based on the location. In this
example, when the user executes Confirm PO, planned delivery = 45 days from
action execution date. Similarly, planned delivery date = 30 days from
Manufacturing Finished execution date.
With the Location/Planned Delivery date, a dealer can search the VMS and
quickly tell his customer where his vehicle is and when he should expect it.
A vehicle only has 1 location field. It is possible to update location using the
primary or secondary matrix. However, location determination must not be
ambiguous (example: interlinking action where primary and secondary actions
have different locations). If there is an ambiguous selection, the system might not
perform the action.
Availability is similar to location as it can be updated by either a primary or
secondary action.
Availability can be used as a criteria for Category Management.
Like location, there is only one availability field. Selection must not be ambiguous
or the system might not execute the action.
Here is an example of Primary Matrix WSMM. The matrix is built by a number of
entries consisting of an Initial (Old) Status, Action, and Resulting (New) Status.
The first line translates into “When initial status is blank, and action is CRE1 is
executed, resulting status is M005”
The resulting status becomes the initial status (in this example, blank changes to
M005)
The user can now only execute actions where initial status is M005.
The combination of status and action is mandatory. You can also determine
availability and location as needed.
Location and Availability will be updated when the specified action is executed.
Note: the first action in a primary matrix will always create a new vehicle record.
This is because you must make a new entry in the vehicle database before you
can perform any further actions.
In the previous slide, you saw it was possible to define Availability and Location
update by executing a specific action.
This slide shows an example that requires a further level of detail. Here is an
example scenario.
PO is sent to OEM –
–Action is ORD1
–Primary Status, Availability (AV) and Location (OEM) and Delivery (80
days) are updated by the action matrix
For some reason, the Importer cancels this PO
–Action is DORD
–Primary Status, Availability, Location, and Delivery can be updated by
the action matrix
The Importer places a new PO for the vehicle –
–Action is ORD1 – same as original PO
–Primary Status Availability, Location, and Delivery are updated by the
action matrix
–Because of the inconvenience, the OEM will now delivery the vehicle in
100 days
This example shows that even when the same action is executed, the matrix can
determine a distinct value for availability and location.
Once the matrix has been defined, Primary Status and/or Secondary Status
and/or Availability and/or Location will be updated by executing an action.
Sometimes executing an action won’t update any of these fields. Example:
Change PO is used to change configuration but no other updates are made to the
vehicle.
Each vehicle can be assigned two matrixes: primary and secondary.
It is possible to create multiple action matrixes. Each matrix can be used to
represent different business process.
For example, a vehicle might be produced domestically or imported. The
procurement process would be different in this case.
Another example, a vehicle can be sold to company branches or an independent
franchise. The sales process may be different.
Because it is possible to define multiple primary and secondary matrixes, you
must define rules that tells the system which matrix to select. This setting is made
in transaction VELOS. Fields used in this selection process are shown above.
The more criteria you fill in, the more specific the selection process.
You cannot have duplicate or ambiguous entries. The system must be able
determine which matrix to select.
When you built your action matrix, there was no formal setting to determine if a
matrix is primary or secondary. This determination is made in this table only.
Based on the selection criteria, the system will assign the matrix entered in the
Primary Action Control field as the vehicle’s primary matrix and the matrix entered
in the Secondary Action Control field as the vehicle’s secondary matrix.
Once the matrix is assigned to a vehicle, it is assigned to the vehicle record
forever. You can change the contents of the matrix, but you can not assign a new
matrix to the vehicle.
How the system selects a Primary Matrix.
In the FIND tab, select the Vehicle Model (VEHI). From the Action Bar, select an
action that will create a new vehicle record. Click the green check next to the
Action Bar.
To appear in the Action Bar, the action must have been flagged as a CREATE action (more
about this later)
The system automatically switches to the ACTION tab. Enter data into the
subscreen (plant, number of vehicles, etc.) and configure the vehicle. Click the
Execute pushbutton.
The system looks in the VELOS table to determine the appropriate primary matrix.
In this example, it looks for Material (determined in step 1) and Plant (determined
in step 2). The system determines that WSMM should be the primary matrix.
The system reviews WSMM to ensure that the current status (blank) allows the
selected action (CREA) to be executed. In this case, there is a match so the
system 1) creates a new vehicle record, 2) assigns WSMM to the primary matrix,
and 3) updates primary status to M005.
This vehicle will be procured based on the business process defined in matrix
WSMM.
How the system selects a Secondary Matrix.
Steps 2 through 5 are identical to the last slide. There is a slight difference in Step 1.
This is because a vehicle record already exists when you execute your first secondary
action. In the case of primary matrix, you must first create a vehicle record.
You might have noticed that there are some Secondary Actions that can create vehicles
(example CRCO: Create Vehicle and Sales Order). This is actually an interlinking action
that first performs a primary action CREA, then performs secondary action CUOR. Once
again, a vehicle record already exists when you execute your first secondary action.
Select your vehicle record(s) and click the ACTION tab. In the Action Bar, you will find all
actions that are allowed for the vehicle(s). The primary actions are determined by the
primary matrix. The secondary actions that appear are actions from all matrixes that can
be performed when initial status is blank.* Select the secondary action and click the
green check next to the Action Bar.
Enter data into the subscreen (customer, delivery date, etc.) and configure the vehicle (if
desired). Click the Execute pushbutton.
The system looks in the VELOS table to determine the appropriate secondary matrix. In
this example, it looks for Material (determined by vehicle) and Plant (determined by
vehicle). The system determines that WSSD should be the primary matrix.
The system reviews WSSD to ensure that the current status (blank) allows the selected
action (RSOF) to be executed. In this case, there is a match so the system 1) performs
the action, 2) assigns WSSD to the secondary matrix, and 3) updates secondary status to
RS01.
This vehicle will be sold based on the business process defined in matrix WSSD.
* This statement does not apply to actions that are flagged as Create actions. This flag
will be discussed shortly.
Actions are the basic steps used to carry out the business process. Actions are
defined as primary, secondary or both.
To define an action, enter a 4 digit code and a description. Next, specify if the
action is to be Primary, Secondary, or Both (Primary & Secondary).
If the action is an interlinking action (performs multiple actions), define the
sequence of these sub-actions. If an interlinking action performs primary AND
secondary actions, it must be flagged as both primary and secondary.
Not shown: internal action. This flag means this action can only be be executed
by the system.
Menu path: IMG > Logistics Execution > Vehicle Management System > Control
Data > Define Actions
The previous transaction is required to complete the header information. The
details of the action are maintained in separate transaction.
Menu Path: IMG > Logistics Execution > Vehicle Management System >
Enhancements > Define Technical Details for Actions.
Here you can also maintain the description and primary and secondary flags.
This transaction allows you to enter more specific information about the action.
Configuration Pushbutton: Does this action allow you to change the vehicle
configuration?
Create Action: Does this action create a new vehicle record?
–If you select this checkbox, this action will only be available in the
Action Bar when the FIND tab is displayed.
–A create action can only be assigned to a primary action (or an action
flagged as BOTH)
–A create action can only be assigned to a primary action where initial
status equals blank.
Action Program: the functional module to be performed when the Execute pushbutton
is clicked.
Action Screen: the subscreen that appears when you select an action from the Action
Bar.
An action does not need to have an Action Program or Screen assigned to be
complete. This is because actions can be used to simply update primary status or
secondary status (or availability or location).
This screens shows an example of an action where no Action Program or Action
Screen has been defined. Executing this action will simply update vehicle
attributes.
New feature in VMS 4.0 (DIMP 4.7.1)
SAP provides a number of standard fields that capture a tremendous amount of
information about each vehicle.
However, there may be additional information that must be captured to support
your business process.
To support this need, SAP allows you to define these additional fields as either
Attributes or Qualifiers.
There is no rule that defines if a field should be defined as an attribute or a
qualifer. Both can capture additional data about the vehicle.
There are some slight differences you should consider.
Qualifiers can be defined directly in configuration. They are very easy to set up
and maintain.
Attributes are defined via ABAP. The process is not difficult, but require more
work than qualifiers.
Qualifers are free form text.
Attributes have defined field types and field lengths.
Attributes are added to table VLCVEHICLE. Performance could be affected if
many attributes are defined.
Qualifiers are maintained in a related table.
Qualifiers are defined in configuration. The menu path is IMG > Logistics
Execution > Vehicle Management System > Enhancements > Define Additional
Information for Vehicles
Create a new qualifier. You must define a 4 digit code and a description
Assign the qualifier to an action. The sub screen for this action must allow
Qualifiers to be displayed (via ADDDATA_CONTAINER). If the action screen for
your action does not have this screen element, you will not be able to enter
qualifiers.
Define if the qualifier is optional entry, required entry or display only.
When you perform your action, the qualifiers will appear in the portion of the
screen where ADDDATA_CONTAINER is defined. If you enter text in a qualifier,
the attachment icon will appear next to the Additional Data pushbutton on the
Vehicle Data detail screen. Click the pushbutton and the pop-up window with the
qualifiers will appear.
It is possible to use qualifiers as a vehicle search criteria. The necessary fields
are found on the General Vehicle Data subscreen.
Attributes are similar to qualifers but are a little more complex to maintain. A fair
bit of ABAP knowledge is required to do this maintenance, although it is possible
for relative novices to make these settings with a reference document.
Similar to qualifiers, attributes are assigned through actions. Unlike qualifiers, the
attribute must be defined directly in the action program. The next few slides
discuss the process for programing new actions.
The following slides demonstrate the creation of a new action used to define a
new attribute: license plate.
To execute this processes
New attributes will be added to the VLCVEHICLE table
A new function module will be written
A new action ZPLN will be defined in configuration
The new attributes are linked to a Z-structure. This Z-structure is filled into the
appends of
VLCACTDATA – communication structure for building blocks of the action
VLCVEHICLE – vehicle record table
BAPI_VEHICLE_MULTIPLE_CHANGE – enables to use these fields for external
process (e.g., Idoc)
New fields of the vehicle table, which are maintained by action (system user) or
Idoc, are processed by the respective program and new dynpro.
This means for new fields a customer own function group is created (e.g., copy of
VELO15) and necessary includes are inserted in the customer specific program.
Please refer to „development of own VMS actions“ as part of the VMS
documentation in IMG.
Assignment of Attribute to Action is similar to Qualifier process. Transaction is the
same, only the assignment folder is different.
Select the action and enter Attributes. Specify if attributes are ITEM (unique for
each vehicle) or HEAD (same value applied to multiple vehicles). Then specify if
entry is required.
Finally, assign Action to the Matrix.
To make the attribute available for search, it must be added to the search program
and the search screen.
This is a modification but not to worry - SAP fully supports this modification.
Select the Vehicle Model, open the appropriate Search subscreen, and enter
values for the attribute.
Click execute and system will return the correct vehicle.
This slide shows the VMS maintenance that can be performed from a) the Main
SAP Access screen and b) the transactions that are found in the IMG.
This slide shows the VMS maintenance that can be performed from a) the Main
SAP Access screen and b) the transactions that are found in the IMG.
Rework process focuses on installing components upon receipt at
importer/distributor.
Purpose is to install local components for imported cars, and/or accessories
Rework process: Receipt, configure, send for rework, receive back
Master Data must exist in SAP ERP
This process is identical to standard subcontracting.
Step 1: Configure vehicle – specify options to be fitted to car
Step 2: Create Rework Order, Component Explosion
Step 3: Object Dependencies in BOM determine what is selected; Provision
indicator determines if importer needs to provide material
Step 4: Send Vehicle and Materials for rework
Stock Monitoring Report allows quick view of all components required for rework.
Possible to display all vendors in one screen. Possible to select component &
click Post Goods Issue to process goods movement.
Components to be sent to Subcontractors can be seen using transaction ME2O
(O as in Original).
Rework adds Labor and Material cost to vehicle. FI documents reflect this
increased value
Vehicle Configuration can be updated throughout the business process. 4 different sets
of configuration can be maintained for a single vehicle.
One set for the planned vehicle
One set for the Sales Order
One set for the Purchase Order
One set for the Subcontract (Rework) Order
The ultimate configuration of the vehicle is determined by hierarchy.
Subcontract PO has the highest priority, Planned Vehicle has the lowest. Eventually,
configuration maintained in the Subcontract PO will be copied to the Vehicle
Configuration Details.
Planned vehicle configuration is maintained through CREA, CRE1, etc.
Sales Order configuration is maintained through CUOR, etc.
Purchase Order configuration is maintained through ORD1, ORD2, etc.
Subcontract Order configuration is maintained through UORD
There are a number of Change Actions in Standard VMS (CMOD, MORD, etc.) that can
be used to update configuration as well.
It is possible, but not always necessary, to maintain configuration in each transaction.
Configuration values can be copied from planned vehicle configuration into the sales
order and the purchase order, etc.
In the rework demo, configuration values are copied from the Sales Order into the
Subcontract PO. When the vehicle is sent for rework, the Subcontract PO values are
copied into the Planned Vehicle configuration.
The next 2 slides will demonstrate how the Vehicle Configuration is changed by
various actions.
Step 1: CREA (Create Vehicle)
The vehicle configuration must be defined to complete this action. These values are
copied to the Vehicle Details.
Step 2: CUOR (Create Sales Order)
The vehicle configuration is copied into the sales order.
Vehicle configuration is copied into Sales Order configuration
In this example, the Dealer enters new configuration values in the sales order.
These values are then copied into the Vehicle Details
RESULT: Entering new configuration values in the Sales Order changes the
vehicle configuration.
The vehicle configuration is changed to match the sales order.
<Please refer to the previous slide. You will need to compare the two slides to determine how
configuration has changed>
Step 3 ORD1 (Create Purchase Order)
The Distributor places a purchase order for the vehicle to the OEM.
The Vehicle configuration is copied into the Purchase Order
In this example, the Distributor enters new configuration values in the Purchase Order.
The Purchase Order configuration values are then copied into the Vehicle Details
No change is made to configuration in the Sales Order
RESULT: Entering new configuration values in the Purchase Order changes the vehicle
configuration.
The vehicle configuration is changed to match the Purchase order. Sales Order does not match
Purchase Order
Pay attention to values for Engine, Air Conditioning, Exterior Color, Keyless Entry and CD
Step 4 UORD (Send Vehicle for Rework)
The Distributor sends the vehicle out for Rework
The SALES ORDER configuration is copied into the Rework Purchase Order
In this example, the Distributor enters new configuration values in the Rework Purchase Order.
It would also be possible to change configuration values in the Sales Order (CMOD) before creating the
Rework Order.
The configuration values for the Rework Purchase Order are copied into the Vehicle Details
RESULT: The vehicle configuration is changed to match the Rework Purchase Order.
Configuration in the Rework Purchase Order is determined by the Sales Order
Pay attention to values for all characteristics. Compare the values for Step 2 with Step 4
The previous slides demonstrated that configuration values can be updated quite
easily throughout the business process. Configuration Change Profiles is one tool
to establish more control over how these values will be updated.
When connected with the IPC, configuration change profiles allow you to:
Prevent certain users from making any configuration changes whatsoever
Example: dealer is not allowed to change configuration in the sales order
Prevent users from making changes at certain points in the business process
Example: exterior color cannot be changed once Purchase Order is confirmed
Restrict visibility of certain characteristics to certain points in the business process
Example: Local accessories can only be entered once the vehicle arrives
Extra: Configuration Splitting:
This exercise in this chapter creates 2 Purchase Orders for 1 vehicle
A standard PO to the OEM
A subcontract PO to the Reworker
Configuration values are entered in both of these POs.
Some of these configuration values are only required to assemble the vehicle at
the OEM,
Some of these characteristics are only required to add accessories at the reworker.
Values for ALL of these characteristics must be entered in the Sales Order
Through Badi for Configuration Spitting, VMS can take the configuration in the
sales order and:
Send a PO to the OEM, with only characteristics related to vehicle assembly
Send a PO is sent to the reworker, with only characteristics related to rework.
This Badi allocates the characteristics to the appropriate business partner.
1
Thus far, the secondary matrix has been defined to support one way sales: from
the Distributor to the Dealer. There are business scenarios that require multidirection sales.
For this reason, VMS supports a number of reselling scenarios such as transfer
and used vehicle trade in. Some of these examples will be examined in the
following slides.
(For animation only. See next slide)
In the trade in scenario, the customer uses the value in an old car to purchase a
new vehicle. The dealer must now resell this vehicle.
In a central sales scenario, the dealer might sell this vehicle to the Distributor. The
Dealer will create a new vehicle record for the Used Car in the VMS. Next, the
distributor will create a PO to purchase this vehicle from the dealer.
In the trade in scenario, the distributor procures the vehicle from one dealer, then sells it
to another.
There are several actions develop to manage the trade in process. Many of these
actions have been discussed before.
POEU is a new action that will create a Purchase Order for the trade in vehicle.
Actual mapping is done when used vehicle is created with reference to
existing one
Only partial mapping may be defined
Configuration still can be edited manually
PDI = pre delivery inspection
During PDI the vehicle is locally adapted to the specific country requirements
ADDO can be used to attach electronic files to the vehicle
MSSO can be used to send faxes, emails, EDI to business partners
SOCD is used to save customer configuration. If the customer later decides to
purchase the vehicle, this configuration can be retrieved and copied into a new
vehicle record.
BUPA is used to assign an End Customer to a vehicle. End Customers can also
be assigned in the Sales Order actions. End Customer is business partner type
VLC0001 and can be maintained directly in the VMS.
CAMP assigns a Sales Campaign to the vehicle. This can be used as a search
criteria. This could also be used to trigger a pricing condition.
LCTN updates the location of the vehicle. Normally, location is updated through
the business process. This action could be used in exception cases.
STWO can trigger a workflow event for a user. Example: Goods Receipt sends a
notification to the dealer.
CORR is an automatic action used to correct the vehicle status. This action is an
internal action cannot be executed by an end user.
CORR is only triggered through transaction VELOE.
The action is used to change the primary or secondary status. Because the next
allowed action in the matrix is determined by the status, this emergency report allows
you to perform move the vehicle to a different portion of the matrix. This should only
be done in exception cases.
It is defined by law that accruals/reserves
for warranty costs have to be displayed in the balance sheet. US regulations: TREAD,
FIN45
Problems:
Lack of information to match claims against policies.
Lack of information to recover claims from supplier-based components.
High costs related to Return Material Authorizations
Impact: Ineffective warranty recovery from service providers and suppliers Paying
fraudulent or invalid claims.
Solution: Clearly define policies on warranties. Automatic matching of claims against
policies. Cost oriented Return Material Authorizations. Track the suppliers
The warranty process is made up of a large number of small steps (actions),
which are defined in the action profile.
There can be any amount of actions; any way of sorting them is possible.
Each warranty type is assigned to an action profile. This means that you use
action types to control the warranty process.
In automatic processing, the system accesses the action profile automatically.
In manual processing, the action profile defines all possible actions for a
processing status.
SAP delivers some standard actions. You can define further actions within the
customer name space.
A006 and T004 copy IC version to IC version
A011 copies IC version to OC version
A012 copies OC version to OV version
A013 copies IV version to OC version
A014 copies IV version to IV version
A015 copies IC version to OV version
A018 copies IC version to IV version
A019 copies OV version to IV version
A020 copies OV version to OV version
A021 copies OC version to OC version
A040 executes
A041 executes
A042 executes
A043 executes
financial
financial
financial
financial
posting
posting
posting
posting
in the
in the
in the
in the
active IC version
active OC version
active OV version
active IV version
Sometimes the importer and/or the vendor request from the dealer (and possibly
the importer) to return the failing parts for control and/or quality purpose
Pricing of a claim, a claim version, and on item level is done by SAP SD Pricing
functionality. For warranty purposes, additional price condition types are created
by SAP.
Pricing condition types are defined for
Material
Flatrate
Sublet
Condition types are maintained per category, and cover also rebates, and customer
(dealer) specific conditions etc. Detailed information on the warranty functionality will
be provided when the functionality is released to customers.
It is possible to add customer spezific pricing condition types.
VIN is used as iIdentifier for WTY and can be assigned with action SMOD.
GEOB creates a type of intermediate object for a vehicle for which no equipment
exists
GEOB is technically required if you want to assign measuring points or master
warranties to a vehicle without equipment
Vehicle Locating and Ordering
•
search configured vehicles across the entire supply chain – in realtime
•
search vehicles at other dealerships in their region
•
find only the vehicles they are supposed to
•
request and transfer vehicles from other dealerships
•
save the original customer configuration in your system
•
track their vehicles at anytime during the process
•
transfer data in their DMS
Warranty management
•
Create claims, simulate claims (check rules), Check status of claims
•
Recalls management (objects which are part of a recall are listed and a claim could be created
with reference to a recall. From the recall the parts and labour values are copied into the claim)
•
Returnable Parts (claim contains parts that have to be returned, list of parts to be returned, print
return part tag, set status of return part in claim)
•
Track the financial status of the claim
Spare Parts Ordering
• Order creation with ATP check and supsersession
• Integration of external catalogs (via Open Catalog Interface)
• Order tracking (check deliveries and invoices)
Thanks to the clear separation between UI and business logic and the use of
patterns, Web Dynpro significantly reduces development costs.
Easy to adapt/enhance (change of field names, hide fields etc.)
Standard ALV lists are included in floorplan patterns
ALV allows to display/hide/resort colums
Notes: On this slide you should explain the general concept of the Vehicle
Management System.
Integration: Vehicle Procurement as well as Vehicle Sales by using on vehicle
database.
Importer and dealer are working on one system. Dealer access via dealer portal
by simply using a web browser.
Typical business process handled by the VMS:
Procurement Scenario
The Importer/Distributor order the vehicle from the OEM
The OEM confirms the order
As the vehicle is assembled, the OEM sends updated status information
The vehicle is received at the Importer/Distributor
The OEM sends an invoice for the vehicle
Sales Scenario
The dealer logs in via the web and places an order for the vehicle
The Importer/Distributor delivers the vehicle to the Dealer
The Importer/Distributor bills the Dealer for the vehicle
The Dealer provides payment
There is a lot of information that can be stored against each vehicle record. It is
also possible to extend the database with customer fields.
Each vehicle has an internal number. This is the unique key field used in the
VLCVEHICLE table to keep track of all vehicle entries.
Using the example above, 815 is the internal vehicle number. Against this key
field, the user can maintain additional data such as VIN, status, documents,
configuration, and history.
While the system defines the internal number as the key field, Vehicle
Identification Number and External Number are two standard fields in the
VLCVEHCILE table that can be used to track unique vehicle records.
Vehicle transfers are stored in table VLCVTRANSFER
Notes: On this slide you should explain the general concept of the Vehicle
Management System.
Integration: Vehicle Procurement as well as Vehicle Sales by using on vehicle
database.
Importer and dealer are working on one system. Dealer access via dealer portal
by simply using a web browser.
Typical business process handled by the VMS:
Procurement Scenario
The Importer/Distributor order the vehicle from the OEM
The OEM confirms the order
As the vehicle is assembled, the OEM sends updated status information
The vehicle is received at the Importer/Distributor
The OEM sends an invoice for the vehicle
Sales Scenario
The dealer logs in via the web and places an order for the vehicle
The Importer/Distributor delivers the vehicle to the Dealer
The Importer/Distributor bills the Dealer for the vehicle
The Dealer provides payment
Equipment is implemented, serial number can be enhanced
Resubmission:
1. create new claim by copying old (closed) claim
2. Create new version by using resubmission button => In default coding, if an
active IC/OC version is available and the closed flag is not set, the button is
active
The logic can be controlled via BAPI_WARRANTYCLAIM_ADD_VERSION
3. Change existing claim with allowed changes in claim’s current status
In case a check is required if the claim items are covered by the contract, the
standard action
Refer to customizing guide to create an action which assigns the standard function
module
VMS supports processes of a vehicle importer or any kind of intermediary
between the OEM and a dealer.
Many dealer groups also act as importer, being in direct communication with the
OEM and reselling to both endcustomers and independent dealers.
VMS supports processes of a vehicle importer or any kind of intermediary
between the OEM and a dealer.
Many dealer groups also act as importer, being in direct communication with the
OEM and reselling to both endcustomers and independent dealers.
The DBM vehicle technically consists of the VMS vehicle and the iObject.
The VMS vehicle is the leading object in all the business documents.
For creating and processing a vehicle in DBM, the VMS relevant settings are
mandatory. This includes the assignment of
the VMS vehicle model to VMS action controls (Logistics => Logistics Execution =>
VMS => Basic Data => txn VELOS)
Users to VMS roles (VELORM, VELORO, VELORM).
The iObject is used as a concept for extending the vehicle object.
You can decide if the billing is executed in the R/3 system or via CRM Billing.
The scenario Vehicle Management System Integration with CRM focuses on
uploading the vehicle data of business partners and history in the Interaction
Center from VMS. The vehicles can be either company cars or third-party vehicles.
The Interaction Center for Automotive is an enhancement of the SAP CRM
Interaction Center. It has a workspace specifically for the automotive industry. You
can also maintain vehicle data manually.
Tansfer of vehicle data, configuration data and history entries such as relationship
with dealer and end customer to CRM
Event Manager is a component of the SAP Business Suite solution. It is now
possible to track the vehicle through the supply chain.
Example scenario: Vehicle is due to arrive at the importer, but the boat has been
delayed. EM triggers an alert to notify the importer that this vehicle will be arriving
late.
The IDoc ( i.e. Intermediate Document) is the SAP standard interface to link
application systems via messaging. Whereas one system is asumed to be a SAP
ERP system, the second system could be
An SAP ERP system
Third-party application software.
IAU 270 – Vehicle Management System
Lesson 1 Introduction to Vehicle Management System
Let’s start with searching the vehicle. Enter the VMS through the menu path, or via
transaction code VELO.
FIND TAB
1.1. In the Vehicle Model window, select DE_LUX_AUTO. Make sure no other
vehicle models are selected.
1.2. Enter configuration values for several characteristics. Can you enter multiple
configuration values? (i.e. search for 2 colors at the same time?)
_______________________________________________________________
1.3. Click the Find Button. How many vehicles appear in the search result?
_______________________________________________________________
1.4. Click the FIND tab to return to the search function. Now select the
DE_LUX_AUTO and another vehicle model. What happens?
_______________________________________________________________
1.5. Scroll through the search views. Besides configuration, what are some other
attributes you could use for a vehicle search?
_______________________________________________________________
_______________________________________________________________
1.6. Search for DE_LUX_AUTO vehicles that meet all the following parameters:
a) Exterior Color = Red OR Blue OR White
b) Vehicle Identification Number (VIN) has been assigned
c) Availability of vehicles is Available or Planned
How many vehicles did you find?
_______________________________________________________________
1.7. Now that you have entered these search values, you never want to have to
enter them again. Save these values in a new search profile SP##, “Search
Profile ##”. Remember to replace ## with your group number!
1/29
IAU 270 – Vehicle Management System
1.8. Return to the FIND tab and deactivate your search profile. Click the find
button to search for all DE_LUX_AUTO cars in the database (no search
restrictions). How many cars did you find?
_______________________________________________________________
OVERVIEW TAB
2.1. Refine the search result by filtering the parameters. Double click to change
the status icon from GREEN to RED for several values of:
a) Availability
b) Location
c) Primary Status
d) Configuration
How many vehicles are left in the Overview search result? (If there are no vehicles
left in the search result, turn some of the filters back to green)
_______________________________________________________________
2.2. Open the folder for Vehicle Secondary vehicle secondary status category.
Turn all but ONE of the filters red. How many clicks did it take you?
_______________________________________________________________
2.3. Change the filters until you have a reasonable number of vehicles to work
with. (not too few, not too many, about 5-25). Now change the display of the
vehicle details in the Overview tab.
a)
b)
c)
d)
Move Location to the top of the list.
Move Vehicle Identification Number (VIN) to the second position.
Remove 3 fields from the display. (besides Location or Customer)
Sort the vehicles by Location (ascending) and Customer
(descending)
e) Change the display from plain to stripped pattern.
f) Save your display settings so that everyone can access it. The
naming convention should be /DS##. Description should be
Display Setting ## (where ## is your group number!) Do NOT
save your display as User Specific.
2.4. Return to the OVERVIEW screen. Make further changes to the display
settings until it looks just the way you like. Save your changes.
2/29
IAU 270 – Vehicle Management System
DETAIL TAB
3.1. Return to the FIND tab and search for vehicles that are assigned to your
favorite dealership (DEALERXX). Select ALL vehicles and click the
DETAIL tab. Review the details for each vehicle.
Who is the Vendor? ________________
_______________
Who is the Customer?
What is the VIN? _________________
_________
When is the Production Date?
What is the Gross Price? _____________
___________
What is the Primary Status?
If your vehicle is missing some of this data, select a different vehicle and try again.
Simply click a different vehicle from the list –do not return to the Overview.
3.2. Click on the Configuration Pushbutton. List some of the values associated
with this vehicle.
______________________________________________________________
______________________________________________________________
______________________________________________________________
3.3. Click on the Customer Button.
3.4. Click on the End Customer Button.
3.5. Click on the Vehicle History Button
4. How many actions have been performed for the vehicle so far?
______________________________________________________________
5. List some of the actions that have been performed.
______________________________________________________________
6. Which of these actions created ERP business documents?
______________________________________________________________
3/29
IAU 270 – Vehicle Management System
ACTION TAB
4.1. For this step, stay in the DETAIL Tab. Click on the Action Bar Window.
How many actions appear?
_______________________________________________________________
_______________________________________________________________
4.2. Select one vehicle and click on the ACTION Tab. Pull down the Action Bar
Window. What actions can be performed for these vehicles?
_______________________________________________________________
_______________________________________________________________
4.3. Return to the FIND Tab. Search for one vehicle that has been assigned a VIN.
Click the DETAIL Tab. What is the Primary and Secondary status for this
vehicle?
_______________________________________________________________
4.4. Click the ACTION Tab and pull down the Action Bar. What actions appear
for this vehicle? Is there any difference from question 4.2?
_______________________________________________________________
_______________________________________________________________
4.5. Click the FIND tab, and pull down the Action Bar. What actions appear?
_______________________________________________________________
_______________________________________________________________
4/29
IAU 270 – Vehicle Management System
Lesson 2 Introduction to VMS Roles
Roles determine what the user is allowed to see and do in the VMS. Different roles
have been maintained for the Importer and Dealer. In this exercise, you will compare
these roles for differences. These differences will become apparent in later exercises,
when you process the VMS as Importer or Dealer.
1.1 Review the various roles that have been assigned to your user profile. List
the menu path and the transaction code to see this data.
_______________________________________________________________
_______________________________________________________________
1.2 List the various roles that have been assigned to your users. Specify if you
think the role is a material role (M) or an organizational role (O).
IMPORTER
DEALER
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
1.3 Compare the Dealer and Importer organizational roles created for you
group. What differences do you find?
_______________________________________________________________
_______________________________________________________________
1.4 Compare the different material roles assignments for the Dealer and
Importer. Are there any differences? If so, how might this impact the
Dealer and Importer when they use the VMS?
_______________________________________________________________
_______________________________________________________________
End of Exercise Two
5/29
IAU 270 – Vehicle Management System
Lesson 3 Exercise: Master Data Creation
A new vehicle model has been added to your product offering. Before this vehicle
can be managed in the VMS, you must first set up the necessary master data.
1.1 Create a material master for the new material.
Material Master VMS_XX (XX = your group number)
Copy details from the DE_LUX_AUTO
Create (by copying) the following views …
Basic Data 1, 2
Classification – assign variant class USA_LUX_AUTO
Purchasing
Sales 1,2
Accounting 1,2
… in the following organizational areas
Plant M11E
Storage Location A001
Purchase Org M11E
Sales Org M11E
Distribution A1
Division A1
1.2 Create a configuration profile for you new material (CU41)
Assign Variant Class USA_LUX_AUTO
1.3 In case IPC would be connected, you would have to create a Knowledge Base and
a Runtime Object (do not execute this step unless your instructor asks you to)
1.4 Assign VMS_XX to the Model Role, MIMP
1.5 Assign the MM01 primary action profile to VMS_XX (transaction VELOS)
Access VELO and select your new model. Select the Create Vehicle from the Action
dropdown box. Click on the configuration button and enter values. Click Execute.
Review the vehicle in the DETAILS tab.
6/29
IAU 270 – Vehicle Management System
Lesson 4 VMS Business Process – Make to Stock
PART 1
Now that you are familiar with the look and feel of the Vehicle Management System,
it is time to process vehicles. In this unit, you learned that Make to Stock can be used
when the Importer or Dealer want to order vehicles for sale from stock.
For this exercise, you will play the role of IMPORTER.
1.1 Log into the VMS. After reviewing your stock of DE_LUX_AUTO, you decide to
place additional orders to the OEM. Create 1 new vehicle using the following
process:
Sequenc
e
Action
Description
Master Data
1
CREA
Create vehicle
Plant M11E
Qty 1
Prod Date Today
2
ORD1
Create Purchase Order
Document Type NB
Purch. Org M11E
Purch. Group M1E
Vendor OEM_LUX
Record the Vehicle Number (Internal) ________________________________
1.2 Create and order another vehicle using a slightly different process
Sequenc
e
Action
Description
Master Data
1
ORD2
Create vehicle + purchase order
See above
2
MORD
Change purchase order
Optional
Record the Vehicle Number (Internal) ________________________________
1.3 What other actions could you use to create a vehicle?
_______________________________________________________________
1.4 Review the details for each vehicle. Compare Primary Status and Availability.
Are there any differences for each vehicle?
_______________________________________________________________
_______________________________________________________________
7/29
IAU 270 – Vehicle Management System
1.5 Review the History for each Vehicle. Are there any differences?
_______________________________________________________________
_______________________________________________________________
1.6 Continue processing the vehicles. Perform the following actions for both
vehicles at the same time.
Sequenc
e
Action
Description
1
ZPOC
Confirm PO
2
SHOW
Allow Vehicle for Search
3
ZCON
Vehicle in Production
Review the vehicle details and history. What updates have been made?
Pay attention to Primary Status, Availability and Location.
1.7 Time warp! The vehicles have been manufactured and are on their way.
Prepare to receive them into stock. For these next steps, process each
vehicle separately.
Sequenc
e
Action
Description
Master Data
1
INIV
Create incoming invoice
Gross Amt = Amount
Tax = (blank)
Tax procedure V0
2
SMOD
Change vehicle
VIN##01, VIN##02, …
Usage = Customer
Vehicle
3
GORE
Create goods receipt
Storage Location A001
Review the vehicle details and history. What updates have been made?
Pay attention to Primary Status, Availability and Location.
_______________________________________________________________
_______________________________________________________________
8/29
IAU 270 – Vehicle Management System
Up to this point, all business process interactions have been between the Importer and
the OEM. Now that the vehicle is in stock, the remainder of the exercise will focus on
interactions between the Importer and the Dealer.
2.1 Select one of your newly received vehicles and click the Action Tab.
Execute the following Actions to sell the vehicle to the DEALER.
Sequenc
e
Action
Description
Master Data
1
RSVN
Reserve Vehicle
Customer
DEALER##
2
OFFE
Create Offer (quotation)
3
CUOR
Create Sales Order
Optional
Customer
DEALER##
M11E,A1,A1
4
OUIV
Create Billing Document
5
DELI
Create Delivery
6
GOIS
Post Goods Issue
Extra: Review Vehicle Details after RSVN action. What difference do you notice?
_______________________________________________________________
_______________________________________________________________
2.2 Repeat this process for both vehicles. As you complete the actions, review
the vehicle details and history.
2.3 In the Vehicle Details screen, open the Secondary Action Grid. Review
the actions that make up the vehicle sales process
2.4 In this exercise, the End Customer field was not populated. Why? How
could you attach the End Customer to the vehicle?
_______________________________________________________________
_______________________________________________________________
9/29
IAU 270 – Vehicle Management System
End of Make to Stock Sales Exercise
END PART 1
10/29
IAU 270 – Vehicle Management System
Lesson 4 Make to Stock - Category Management Exercise
PART 2
Category management allows you to filter the vehicle database when performing a
search. Unlike the search profile, category management is defined in configuration
and is generally not maintainable by the end users. Categories can be assigned for a
vehicle search area, an organizational role, or a combination of both.
1.1 As IMPORTER, open the VMS and locate all DE_LUX_AUTO cars.
How many vehicles are shown?
_______________________________________________________________
What availability statuses do you find?
_______________________________________________________________
Now log in as the DEALER. For the rest of this exercise, you will switch between
DEALER and IMPORTER. Make sure you are in the correct session!
1.2 [DEALER] Access the VMS and locate all DE_LUX_AUTO cars.
How many vehicles are shown?
_______________________________________________________________
What availability statuses do you find?
_______________________________________________________________
The vehicles the Dealer can see is limited by rules defined in Category Management.
Switch back to the IMPORTER session and open the VMS Configuration menu.
1.3 [IMPORTER] Open the Category Management transaction to create a new rule.
List the menu path and transaction code
_______________________________________________________________
_______________________________________________________________
Use the following data to create your rule:
Rule Name: CM## (Category Management ##)
Table:
VELO:VEHICLE
Field:
Availability
Boolean:
=
Constant:
PL
What does this rule mean in English?
11/29
IAU 270 – Vehicle Management System
_______________________________________________________________
_______________________________________________________________
1.4 Assign this newly created rule to your VMS dealer role, DL##. Leave the
Search Area blank. This assignment takes place on two screens. Ask your
instructor if you have any difficulties.
1.5 As DEALERXX, reload the VELO transaction, and search for all
DE_LUX_AUTO.
How many vehicles are shown?
_______________________________________________________________
What availability statuses do you find?
_______________________________________________________________
End of Make to Stock Category Management Exercise
Extra Credit: Go back to Category Management as Importer and add the rule
“VISIBILITY” to your organisational role.
Condition:
AND
Table:
VELO:VEHICLE
Field:
Visibility
Boolean:
=
Constant:
X
Save your rule. Switch back to the DEALER and search for DE_LUX_AUTO cars.
Is there any result from making this change to your rule?
_______________________________________________________________
_______________________________________________________________
If so, why?
_______________________________________________________________
_______________________________________________________________
END PART 2
12/29
IAU 270 – Vehicle Management System
Lesson 5 VMS Business Process – Make to Order
The previous exercises presented a scenario in which vehicles were sold from stock.
This time, you will conduct the business process for a custom ordered vehicle (Make
to Order). VMS is a flexible enough tool that you can conduct this process using the
same matrix and master data.
DEALER: (Make sure you are in the right session!)
A customer walks into your dealership and requests a specific vehicle. You search
the VMS but cannot find any vehicles that match the customer’s request. You decide
to order a customer specific vehicle from the Importer.
Sequenc
e
Action
Description
Master Data
1
ZCRC
Create vehicle and customer order
Sales Org M11E
Customer
DEALER##
Since you are ordering this car for a specific customer, you need to populate
the End Customer field.
Create a new record for your end customer (the dealer’s customer).
Click on the Manage End Customer push button. Complete the name
and address. Next, click the Control Data tab and complete the data
entry. Save the record.
End Customer number: _______________
Vehicle number: _______________
You have now completed all the actions that will be performed by the Dealer.
Switch to your Importer session.
IMPORTER: (Make sure you are in the right session!)
Review the database for outstanding dealer requirements. Search for all
DE_LUX_AUTO vehicles
o which have been ordered by your favorite dealer
o which have not yet been ordered from the OEM
o which have been assigned an end customer
Once you find the vehicle, begin the procurement process
Sequenc
e
Action
Description
Who does this?
13/29
IAU 270 – Vehicle Management System
1
ZORD
Create order for customer
2
ZPOC
Confirm Purchase Order
3
ZCON
Manufacturing vehicle
Vendor
OEM_LUX
Feel free to review the vehicle details. Click on the Customer pushbutton.
Next click on the End Customer pushbutton.
You can continue to process the vehicle if you would like to. Otherwise you
have completed enough actions for the purpose of this exercise.
End of Make to Order Exercise
14/29
IAU 270 – Vehicle Management System
Lesson 6 Late Order Assignment (Allocation)
In both the Make to Stock and Make to Order scenarios, when you created an ERP
sales order, you first had to select/create a vehicle. In version 4.0, there is a new
functionality that allows you to create the sales document (Order, Inquiry, Quotation)
without reference to a specific vehicle. The assignment between Sales Document and
Vehicle can be done later using the Allocation functionality.
1. Create a Sales Order for DE_LUX_AUTO
Logistics
Sales and Distribution
Sales
Order
Create (TC:
VA01)
Order Type: OR, Sales Org: M11E, Dist Channel: A1, Division: A1
The sales order is from your favorite dealer (DEALER##)
Requested delivery of the vehicle is next month
Configure the vehicle as you please.
Important: Be sure to record the exact configuration!
Order Configuration:
______________________________________________
__________________________________________________________________
_
__________________________________________________________________
_
In the same sales order, order a second DE_LUX_AUTO on another item line.
Configuration for this vehicle should be slightly different from the first item line.
Save the sales order and record the number.
Sales Order Number:
________________
2. In VELO, Create a new DE_LUX_AUTO using action CREA. Vehicle
configuration should match configuration you maintained in the sales order.
Internal Vehicle Number: ________________
3. Click the Assignmnt tab. In the Search for Sales Documents sub-screen, click
the Find with Models button.
4. A list of sales documents should appear. Select the sales order you created in
Step 1. Now click the Find Vehicles button.
5. The vehicle you created in Step 3 should appear in the search result. Select
this vehicle and click the Compare Configuration icon. Is there any difference
in configuration between the sales order and vehicle?
15/29
IAU 270 – Vehicle Management System
6. Select the second sales order line item and click the Compare Configuration
icon. Is there any difference in this result? Do this step only if you created the
second sales order line item.
7. From the Action Pull Down menu, choose action LORS (Create Loose Link).
(Make sure that your sales order and vehicle are selected). Execute the action.
8. Review the Assignment screen. Were there any changes to the sales order or
vehicle line items?
9. Click the Detail tab. Review the Vehicle Data. Review the Reservation Queue
for this vehicle.
10. Check the Vehicle History. Are any documents created ?
11. Return to the Assignmnt tab. After selecting the Sales Order and Vehicle,
choose action TIRS (Create Fixed Link). Execute the action. Review the
Assignmnt and Detail screens.
12. Check the Reservation Queue and the Vehicle History again. Do you note any
changes ?
13. Check the Sales Order you have created at the beginning of this exercise. Can
you identify any differences between the first and the second line item ?
(HINT: you might have to scroll a little…..)
16/29
IAU 270 – Vehicle Management System
Lesson 7
VMS Customizing
PART 1 – Create a Matrix
VMS can be flexibly configured to match your business process. This exercise will
work through some of the key steps needed to develop an action matrix to support the
procurement and sales processes enabled in VMS.
1. Before creating an action matrix, there are certain elements that first need to
be defined. Can you name 4 steps that must take place before creating a
matrix? Which of these steps are optional? Refer to the IMG for help.
_______________________________________________________________
_______________________________________________________________
2. In this exercise, you will use existing statuses, availabilities, locations, and
actions. The focus will be on creating a new primary action matrix for the
vehicle. Assume your company’s business process looks something like this:
1.
2.
3.
4.
5.
6.
Create a vehicle record
Send a purchase order to the OEM
PO confirmation is received from the OEM
OEM sends an invoice for the vehicle
Vehicle arrives at the distributor
The VIN number is recorded for the vehicle
What VMS actions correspond to these business steps?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Now that you have decided on the actions, you must determine their process
flow. Actions must be combined with statuses to determine when they can
17/29
IAU 270 – Vehicle Management System
and cannot be used. Therefore search for appropriate status in the customizing
transaction “Define Vehicle Status”. Complete the following tables to design
the primary action matrix.
Primary Matrix
N Status
O Status
4. Based on this table, create your new primary action matrix in ERP. The
matrix should be called be PM##. (Primary Matrix Group ##)
5. In your matrix, add an action that lets you create and order a vehicle in one
step. What action would you use? What is the resulting status?
_______________________________________________________________
_______________________________________________________________
6. Add availability and location to your matrix. Vehicle should be NOT
AVAILABLE after creation, AVAILABLE after goods receipt. Vehicle
should be located at the MANUFACTURER after create purchase order and
at the IMPORTER after goods receipt.
7. Assign this matrix to procure your VMS_## model. How do you tell the
system to use this matrix for your vehicle? For the time being use SD01 as
your secondary matrix.
_______________________________________________________________
8. Return to VMS and create a new vehicle record of your model VMS_XX.
Record the vehicle number. _______________________
9. Now order the vehicle from the manufacturer. Question for super experienced
senior consultants: Why does this not work ? Hint: check the Log! What do
you have to do to solve the problem ? Feel free to ask your instructor if you
are stuck.
18/29
IAU 270 – Vehicle Management System
__________________________________________________________________
__
__________________________________________________________________
__
10. Once the purchase order is created, confirm the purchase order and initiate the
incoming invoice in your system.
11. Now create a customer order for that vehicle for your favorite dealer
(DEALER##). Check the Log entry that has been created. Do you note
anything ?
__________________________________________________________________
__
Since the vehicle should automatically have a price next time a customer order is
created in VMS, create a condition with type PR00 for your vehicle model
(material master).
Path in Navigation Menu: Logistics
Sales and Distribution
Conditions
Select using condition type
Create
Or simply type in transaction code: vk11
Master Data
12. Now create an invoice for the dealer. Note the invoice number
_____________
13. What happens when you try to deliver the car executing DELI ? Why can you
not create a delivery ?
14. Now that the vehicle has arrived at the importer, create a goods receipt
document by executing action GORE.
End of Action Matrix Exercise
END PART 1
19/29
IAU 270 – Vehicle Management System
VMS Customizing
PART 2 – Create a secondary Matrix
By now you are more familiar with the concept of the matrix. But why do we have
two matrices ? What’s the use of this ? In order to better understand the flexibility of
the matrix concept and how actions are used for building a business process we create
a secondary matrix.
Imagine the following business scenario: the importer may not want to execute the
action DELI (SD delivery) before the vehicle has actually arrived on his site
(represented by action GORE, MM goods receipt).
1. Create your own secondary matrix SM## (Secondary Matrix Group ##) which
covers the following processes. Search for appropriate status in the customizing
transaction “Define Vehicle Status”.
1.
2.
3.
4.
5.
A sale is made to a dealer
The invoice is sent to the dealer
The vehicle leaves the distributor HINT: use action ZGOS
A delivery to the dealer is created
The delivery to the dealer that is created is deleted
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Secondary Matrix
N Status
O Status
2. Check for which matrix or matrices the action DELI is defined:
_______________
20/29
IAU 270 – Vehicle Management System
3. Assign your new secondary matrix to your vehicle model.
4. After recalling transaction velo, execute the following actions:
ORD2 create vehicle + purchase order
CUOR create sales order
ZCOF confirm sales order
ZPOC confirm purchase order
OUIV create billing document
What is your choice of actions when you have selected the vehicle and go to the
action tab ? Check if you create a delivery for this vehicle (DELI). Do not execute the
action!
_______________________________________________________________
5. Now replace the action DELI by the action ZDEL in your secondary matrix. How
do DELI and ZDEL differ ?
_________________________________________________________
6. You have probably noted in question 5 that ZDEL is an action for both primary
and secondary matrices! Therefore you need to enter the action in the primary
matrix as well in order to execute it.
Earlier we have said that we want to make it impossible to create a delivery before
goods receipt, therefore we need to position action ZDEL in the primary matrix in
a status after goods receipt is executed. The action should not change the primary
status and is only a check entry.
Which fields are to be filled in your primary matrix (PM##) to achieve this ?
Old status_______________
New status _______________
Make the required entry in the primary matrix and save your .
7. After recalling velo, do the following process again:
ORD2 create vehicle + purchase order
CUOR create sales order
ZCO2 confirm sales order
ZPOC confirm purchase order
21/29
IAU 270 – Vehicle Management System
OUIV create billing document
Check again if you can create a delivery for this vehicle (ZDEL). What is your choice
of actions now when you have selected the vehicle and go to the action tab ? Compare
your answer with your answer in question 4! Do you notice a difference ?
_______________________________________________________________
8. Which action to you have to execute in order to be able to create a delivery ?
_______________________________________________________________
Execute these actions and create a delivery for this vehicle.
END PART 2
22/29
IAU 270 – Vehicle Management System
VMS Customizing - Vehicle Attributes and Qualifiers
PART 3
If VMS does not provide a required data field, a qualifier can be created to capture
this additional data for a vehicle. Qualifiers are maintained in customizing and
assigned to actions. You will define and assign a qualifier, then record a value in a
vehicle record.
1. Create a Qualifier. What is the menu path?
_______________________________________________________________
_______________________________________________________________
2. Create qualifier QL## (Qualifier Group ##)
Assign the qualifier to action SMOD. Entry should be optional.
Add action SMOD to your primary action matrix, PM##. This action
should be executed after registering the VIN number.
Record the Vehicle Number and the Qualifier Value
______________________________________________________________
3. Click the FIND tab and select the General Vehicle Data search view. Enter
your qualifier (QL##) and the value you just entered for your vehicle.
What vehicle number was returned?
_______________________________________________________________
Extra Credit Qualifier Exercise:
4. Create a new action in the VMS. Action creation requires two separate
configuration transactions:
Create Actions
IMG >VMS>Control Data>Define Actions
Copy Action SMOD. Your action should be Z##A. (Qualifier Action ##)
Define Technical Details for Actions
IMG>VMS>Enhancements>Define Technical Data for Actions
Copy the Program and Screen number from SMOD
5. Allocate your qualifier to this action. Delete the allocation to SMOD.
Define Additional Data for Vehicle
6. Add this action to your Primary Matrix
Determine Action Controls and Action Matrixes
7. Return to VMS and test
End of Qualifier Exercise
END PART 2
23/29
IAU 270 – Vehicle Management System
Lesson 8 VMS Business Process – Rework Processing
Once the Importer receives vehicles from the OEM, additional accessories are added
to meet customer demands and/or local requirements. In this process, the vehicle and
all necessary materials are sent to an external subcontractor. When the subcontractor
has finished, the accessorized vehicle is received back into the Importer’s stock.
1. Open the VMS. Create an Order for a SUPER_AUTO from the OEM.
Sequenc
e
Action
Description
Master Data
1
ORD2
Create vehicle and purchase order
Doc Type NB
Purch. Org M11E
Purch. Group 001
Vendor
OEM_LUX
When you create this vehicle, only
configure the Interior Color, Exterior
Color, Transmission, AC and Engine.
Leave remaining characteristics BLANK.
2
GORE
Create goods receipt
Storage Loc
A001
2. In the vehicle details sub screen, click the Configuration values. What options
have been specified?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
3. Create a sales order for your favorite dealer. Your dealer has requested
additional options be added to the vehicle. Click the configuration button and
enter values for some or all of the remaining characteristics. Record these new
values.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
4. Send the vehicle out to rework. Your subcontractor is Mel’s Autobody
(PREP_##). Record the Purchase Order and Material Document
_______________________________________________________________
5. Open another session for transaction ME2O (O as in Ostrich, not zero). What
additional materials do you need to send to your subcontractor?
______________________________________________________________
24/29
IAU 270 – Vehicle Management System
_______________________________________________________________
In this transaction, select the materials (only components – the vehicle will
be transferred directly in VELO) and post the goods issue. Storage
location is A001. Close the session and return to the VMS.
6. Mel has finished the rework and returned the car. Finish the rework and
receive the vehicle in storage location A001. Record the Material Document
number.
7. Review the vehicle details sub screen. Click on the configuration pushbutton.
What was changed by the rework?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Optional Exercise: For the die hard ERP Fans
Leave the VMS and look at the material document numbers you recorded. For
each document, double click on the associated accounting document. What
was the value of the SUPER_AUTO during:
Goods receipt of the vehicle from the OEM? ______________________________
Goods issue of the vehicle to the subcontractor? ____________________________
Goods receipt of the vehicle from the subcontractor? ________________________
Review the SUPER_AUTO Bill of Material. How many components are
there? How does the system select the correct components to send to Mel?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
End of Rework Exercise
25/29
IAU 270 – Vehicle Management System
Lesson 9 Used Vehicle Sales
Now you want to trade-in a vehicle of your model VMS_XX. You are using a special
vehicle model (USED_MODEL) for the used vehicle process.
For this exercise assign primary matrix MM01 and secondary matrix SD01 to your
model VMS_XX in transaction VELOS.
1. In transaction VELOMCS assign your model VMS_XX to calculation
sheet profile UV01.
2. Map your new model VMS_XX to one of the values of characteristic
NEW_MODEL (check values in CT04) in transaction VELOMMAP.
3. In transaction VELOCM, map the exterior colors of your new vehicle
model to generic colors of the USED_MODEL.
What is the difference of mapping the values globally or on class level
?
Sequenc
e
Action
Description
Master Data
1
ZCRC
Create vehicle and customer order.
DEALERXX this time sells the vehicle to one
of his fleet car customers who wants to tradein the vehicle back after 3 years.
Plant M11E
Customer DEALER##
Sales Area
M11E/A1/A1
2
CSCR
Create a calculation sheet for the vehicle
3
BBDF
Define terms and conditions for which you as
a sales organization plan to buy back the
vehicle
Enter a buy back date
in the future (3 years
from now)
Open the calculation
sheet and enter a
price for condition
ZU00.
Optionally enter a
text.
Now +3 years have passed and the vehicle is brought back by the DEALER who has
start the trade-in process by creating a vehicle record based on USED_MODEL.
26/29
IAU 270 – Vehicle Management System
Sequenc
e
Action
Description
Master Data
1
CRUV
Create a used vehicle, map configuration.
Open the configuration to verify which values
have been mapped automatically.
Plant M11E
Note the internal vehicle number. Why is it
different from the internal number of your new
vehicle model ?
2
POEU
Create a purchase order for the vehicle. Open
Purchasing Org M11E
the calculation sheet and try to modify
condition type ZU00. Why is this not
possible ? Instead of modifying ZU00, enter a
value for ZU01 to adjust the price to the real
value of the vehicle after trade-in. You can
also add a negative value if the real value is
Purch.Group 001
Vendor: Dealer_CPD
(enter the address for
the CPD dealer)
less than the one expected 3 years ago when
the vehicle was sold as new vehicle.
3
GORE
The dealer has delivered the vehicle and in
order to update your accounts, you post
goods receipt.
4
RVAL
After you have brought the vehicle to shape
(rework activities) you want to revaluate the
vehicle.
27/29
Storage Location
A001
IAU 270 – Vehicle Management System
Lesson 10
Integration to Warranty Management
Warranty Claim Processing is a new IS-Automotive functionality. A separate training
course (IAU280) is available to learn how to use this functionality. This exercise will
focus on the VMS actions that can be used to create warranty master data in VELO.
1. Create a new WARRANTYCAR vehicle and maintain the necessary
master data for warranty processing
Sequenc
e
Action
Description
Special Data
1
CREA
Create WARRANTYCAR vehicle
Plant: M11E
Enter values for
Configuration
(only color)
2
SMOD
Change vehicle (assign VIN number)
VIN Number =
VIN (internal
vehicle number)
Select any value
for Vehicle Usage
3
CREQ
Create Equipment
4
WRTY
Assign Master Warranty
Warranty = 31;
Warranty Start =
Today
5
MEAS
Assign Measuring Points
Reference
equipment =
10004221
2. Select the Detail tab and review Vehicle History. Click on the document
icon to view the master data created by action CREQ.
Equipment Number _______________
Equipment Description
____________________________________
Click on the Warranty Tab. Master Warranty #
__________________
Click on the Measuring Points button. What measuring points are
assigned to this equipment?
______________________________________________________
28/29
IAU 270 – Vehicle Management System
3. Return to the Session Manager screen. Use the following menu path to
access Warranty Claim Processing: Logistics
Customer Service
Warranty Claim Processing (x2)
Process Warranty Claim
4. Create a new warranty claim. In this exercise, you will only enter data
in the claim header. Detailed information about warranty will be
presented in IAU280.
1. Claim Type:
Z001 (Precrediting Automatic)
Click the Create icon
2. Ref Date:
(Today)
3. Partner:
DEALERXX
4. Info:
VMS-Warranty Integration Group XX
5. Object Type:
VELO
6. Ext.Obj No:
(Enter the VIN number for your vehicle)
Note: this field is case sensitive! The VIN number you enter here must exactly the
VIN number in your vehicle or the system will not make the link. Simply copy and
paste the VIN from the VMS detail tab, Vehicle Data. .
5. Save your claim. Ignore any warning messages.
Claim Number: ____________________
6. Return to VELO and load your WARRANTYCAR.
The database contains a large number of WARRANTYCAR records,
so make sure your search is very specific.
7. Click on the Warranty tab. Does your claim appear? ____________ .
Double click on the claim number to jump to warranty processing.
8. Imagine you want to modify the claim and want to enter the current
mileage of the vehicle. Therefore fill the measuring data in the claim in tab
Meas. Data/Notific. After that, copy this version by executing action
A008.
What has happens after you have executed action A008 ?
__________________________________________________
What is the new status of the claim ? _____________
Check if any measuring documents in the vehicle’s equipment (via vehicle’s history
in VMS) have been created.
29/29