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