SAP Automotive Industry solution VMS: ways to improve

For automotive distributors SAP proposed an Industry solution called Vehicle Management System. Indeed, if your company operates with premium car's sector and daily operations volume is modest, you can use VMS solution almost "from the box". Otherwise you will face lots of limitations.
The article - short example of such limitations, experienced after more than 5- years of VMS - solution using.

VMS high-level limitations

• Now VMS solution has poor connection to standard SAP functionality (transportation, ATP-check, Demand Planning and so on);
• The basic extension of VMS is possible basically through ABAP programming;
• In general, VMS oriented for execution not big portion of operation, basically “step-by-step” manually.

VMS-solution improvement ways

Current VMS solution can be improved to satisfy the needs of big importers:

• Business scenarios of VMS solutions based on standard functionality set are absent (transportation, ATP-check, etc.)
• Demand Planning doesn’t cooperate with VMS-oriented Configurable Material & characteristics.
• Tight &Loose links to SO doesn’t fit to ATP.
• There’s no scenario for Vehicle Passport processing .
• There’re no basic vehicle characteristics in the Material Master (Engine capacity, transmission type, etc.), that can be processed using standard functionality (Pricing, etc.).
• Isolation is not fully realized in VMS-actions. Multiple actions confuses users.
• Two VMS-matrix idea doesn’t work in non “step-by-step” process.
• Single-item & quantity idea requires additional entity for grouping purposes (pricing, confirmations, packing etc.).

 Limitations of VMS-solutions architecture in SAP

• No possibility to process the operations initiated in standard SAP objects (sales order, shipment, etc.).
• Functional modules prepare, execute should be attached to VMS actions through Customizing (like screen setting of the operation in OVELO6).
• Screen fields of input and output of data for operations should be set up in customizing (currently fields should be  added by ABAP programming).
• Every new field, you want to operate with, should be included at least in VLCVEHICLE and VLCHISTORY tables.

 More detailed examples

Multi-Item & Qty PO challenges

• Batch reference in schedule line level (and further confirmation level).
• Pricing update for item with PO history in open items.
• GR/IR reference to specific unique batch. Without such reference it is possible to double GR/IR for same batch.
• Most of PO BAPI-s consider valuation type on the item (not schedule line) level.

Calendar data tracking challenges

 

VMS is supposed to track easily calendar data information, but…

• As usual, those datas are not transparent and calculating on-air.
• You should expend every data you need in VLCVEHICLE & VLCHISTORY table.
• It is hard to predict the all dates, which should be cleaned after cancelation.
• Those dates not easy to use in standard functionality, for example, pricing or document flow.