Scroll Below
Wednesday, December 10, 2014
Thursday, December 4, 2014
Magic of VMS
Magic of the Vehicle Management System
Today I read one VMS blog which was very interesting to read.The Magic of the Vehicle Management System is the VLCVEHICLE data table (which stores every attribute for every vehicle) and the VELO transaction (through which the vehicle business process is executed and the vehicle records are updated.)
In the VLCVEHICLE table, there are two key data fields that make VMS behave like VMS: the Internal Number (VHCLE) and Configuration ID (CUOBJ). These two fields are the reason why VMS can support highly configurable (CUOBJ), discrete products (VHCLE).
The first step in any VMS business process is the creation of the vehicle record. Executing this action adds a new record to the VLCVEHICLE table. Every record has a unique internal number assigned to it, making this a key field for the data table. (Not the key field, but more on that in the technical chapters that will be posted later on) The internal number is a counter, increasing by one every time a vehicle record is created. So if the number range starts at 10000, the internal number for the first few vehicle records created will be 10000, 10001, 10002, and so forth. Even if a vehicle record is later deleted or archived, the counter is never reused.
The internal number assigned to the vehicle record will never change. Most of the other fields in the record might be updated as the vehicle moves along the business process, but because the internal number is a key field (not the key, but you knew that already) this value is locked in place. One other reason: the vehicle internal number is referenced in other ERP data tables. More on that in later chapters.
The other field in the VLCVEHICLE table we will discuss in this table in the Configuration ID, or CUOBJ. This field is also a counter, and is created at the same time as the vehicle record. This is a different counter however, so the value is not the same as the internal number.
The CUOBJ points to the exact configuration of the vehicle record. If a vehicle has a red exterior, tan leather interior, V6 engine, automatic transmission, driver’s convenience package, California emissions … and floor mats, all this information is captured in the CUOBJ linked to the vehicle record. The VLCVEHICLE table itself doesn’t contain the configuration values, but through the magic of relational databases, the data can be easily extracted, searched, and displayed.
Like the VHCLE, the CUOBJ for the vehicle record is generated when the vehicle record is created. And also like the VHCLE, the value in this data field never gets updated, even if the vehicle configuration itself changes. And except for a remarkable coincidence, these numbers are never the same.
One final note on CUOBJ – this data field is also found in purchase order and sales orders tied to the vehicle record. When these documents are created, ERP will create a new CUOBJ (it is a counter, after all) to store the configuration values in the documents. Even if the values are identical, each CUOBJ will be unique. But because the CUOBJs are unique, it is possible to store different configuration values in the vehicle record, the purchase order, and/or the sales order. This is important, as a customer might want to order a vehicle with options that aren’t installed in the factory.
Source : upawayadvisors
Subscribe to:
Posts (Atom)