Professional Documents
Culture Documents
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.
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.
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 pop-
up 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 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.
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.
You must maintain the Basic Data and Values for each characteristic.
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.
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.
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.
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)
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.
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)
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.
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.
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.
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.
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.
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.
There are a number of Change Actions in Standard VMS (CMOD, MORD, etc.) that can
be used to update configuration as well.
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
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 multi-
direction 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
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
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
_______________________________________________________________
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.
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.
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.
______________________________________________________________
______________________________________________________________
______________________________________________________________
4. How many actions have been performed for the vehicle so far?
______________________________________________________________
______________________________________________________________
______________________________________________________________
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
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?
_______________________________________________________________
_______________________________________________________________
5/29
IAU 270 – Vehicle Management System
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.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
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.
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:
1.2 Create and order another vehicle using a slightly different process
_______________________________________________________________
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.
1 ZPOC Confirm PO
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.
Tax = (blank)
Tax procedure V0
Usage = Customer
Vehicle
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.
M11E,A1,A1
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
10/29
IAU 270 – Vehicle Management System
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?
_______________________________________________________________
_______________________________________________________________
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?
_______________________________________________________________
_______________________________________________________________
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.
_______________________________________________________________
_______________________________________________________________
Use the following data to create your rule:
Rule Name: CM## (Category Management ##)
Table: VELO:VEHICLE
Field: Availability
Boolean: =
Constant: PL
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?
_______________________________________________________________
_______________________________________________________________
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
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.
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.
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
13/29
IAU 270 – Vehicle Management System
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.
14/29
IAU 270 – Vehicle Management System
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.
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.
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.
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
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:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
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?
_______________________________________________________________
_______________________________________________________________
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).
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 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”.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
Secondary Matrix
N Status
O Status
20/29
IAU 270 – Vehicle Management System
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 ?
Make the required entry in the primary matrix and save your .
21/29
IAU 270 – Vehicle Management System
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 ?
_______________________________________________________________
_______________________________________________________________
END PART 2
22/29
IAU 270 – Vehicle Management System
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.
_______________________________________________________________
Add action SMOD to your primary action matrix, PM##. This action
should be executed after registering the VIN number.
______________________________________________________________
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?
_______________________________________________________________
23/29
IAU 270 – Vehicle Management System
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.
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.
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
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?
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
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:
_______________________________________________________________
_______________________________________________________________
_______________________________________________________________
25/29
IAU 270 – Vehicle Management System
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.
3 BBDF Define terms and conditions for which you as Enter a buy back date
a sales organization plan to buy back the in the future (3 years
vehicle from now)
Optionally enter a
text.
Now +3 years have passed and the vehicle is brought back by the DEALER who has
26/29
IAU 270 – Vehicle Management System
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 Purch.Group 001
3 GORE The dealer has delivered the vehicle and in Storage Location
order to update your accounts, you post A001
goods receipt.
27/29
IAU 270 – Vehicle Management System
2. Select the Detail tab and review Vehicle History. Click on the document
icon to view the master data created by action CREQ.
Equipment Description
____________________________________
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.
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. .
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.
__________________________________________________
Check if any measuring documents in the vehicle’s equipment (via vehicle’s history
in VMS) have been created.
29/29