Inventory Management - Technical Specification Document

Inventory Management Technical Specification

Table of Contents
Inventory Management Technical Specification.................................................................1
Table of Contents.................................................................................................................2
Overview..............................................................................................................................3
Managing Workflow............................................................................................................3
Database Support.................................................................................................................8
Workflow Stages................................................................................................................14
Reporting............................................................................................................................34

Overview
This document defines the technical implementation of ViaTrade’s Inventory
Management system. For a high-level overview of the Inventory Management system,
please see the presentation Inventory Management Platform Overview.ppt.
Inventory Management is done by applying a workflow model to ViaTrade’s business
processes. In general, ViaTrade’s workflow is broken down into a series of stages (i.e.
Workflow Stages). The Workflow Manager manages the execution of each stage and
any errors that may arise during a stage’s execution. Vehicles are placed into the first
Workflow Stage and then cascade through the system as each Vehicle is processed by the
Inventory Management system.
Here are the Inventory Manager’s Workflow Stages:
1. Acquire Vehicle
2. Decode VIN
3. Select Vehicle for auction
4. Notify inspection company
5. Acquire third-party data
a. Acquire Vehicle history data
6. Build CAR
7. Acquire FIW data
8. Auction Vehicle
9. Manage auction
10. Close auction
This document defines ViaTrade’s Inventory Management system in the following steps:
1. Define the general system used to manage workflow.
2. Define the database support required to manage workflow.
3. Define the specifics of each Workflow Stage.
4. Define the reporting system required to monitor the system’s performance and the
status of Vehicles in the system.
Managing Workflow
Overview
The Workflow Manager is the primary application used to manage workflow. The
Workflow Manager is responsible for the following:
1. Managing the flow of Vehicles through all of the Workflow Stages.
2. Managing the execution of each stage.
3. Dealing with exceptions as they arise.
A Workflow Stage consists of seven primary components:
1. Get Vehicles for the stage.
2. Transform incoming and outgoing data from third-party servers.
3. Send/receive data to/from third-party servers.

4. Perform stage-specific functionality.
5. Update the database.
6. Manage exceptions.
7. Advance Vehicles to the next stage.
Each stage makes different use of each of these components.
Getting Vehicles
Getting Vehicles for a stage is a simple database lookup, using the current Workflow
Stage. A Vehicle that has previously encountered an exception is not selected until all
exceptions are cleared for that vehicle.
If an error occurs while getting Vehicles, then the appropriate database read exception is
generated.
Transforming Data
ViaTrade maintains an internal representation of all its data using a format called
ViaTrade Normalized XML or VNXML. When data is sent to an external server, the
Inventory Management system transforms the data from VNXML to the format agreed
upon by ViaTrade and the relevant partner. When data is received from an external
server, the Inventory Management system transforms the data from the format agreed
upon by ViaTrade and the relevant partner to VNXML.
All incoming and outgoing data requests have a corresponding XSL file that is specific to
the Workflow Stage and any relevant partners. For example, if Vehicle A comes from
Inspection Company X and Vehicle B comes from Inspection Company Y, the system
must be able to transform the incoming and outgoing requests for each inspection
company correctly in order to prevent any errors.
If a transform fails in either direction, then the appropriate incoming or outgoing
transformation exception is generated.
Specific details surrounding the relevant VNXML formats for a stage may be found in
the XML section within Workflow Stages. Within the Application section within
Workflow Stages, the following symbol represents a data transformation:

Send/Receive Data
Certain Workflow Stages require sending and receiving data from third-party servers.
The details of this functionality are not defined in this specification due to the customized
code that must be generated for each and every third-party server.
If a transmission fails in either direction, then the appropriate incoming or outgoing
transmission exception is generated.
Running Applications
Each Workflow Stage has a customized application or class that performs a set of
functionality specific to that stage. The application details of each Workflow Stage are
defined in the Applications section within Workflow Stages due to the customized code
that must be generated for each and every stage.
Each stage-specific application is responsible for managing the contents of the VNXML
data package during the stage. In addition, each stage-specific application is responsible
for validating the responses from third-party servers (once the response has been
transformed to VNXML). As a result, if any error occurs in the sending or receiving of
data to a third-party server that relates to the specific content of the VNXML data
package (transformed or not), then the appropriate request or response exception is
generated.
Updating the Database
Each stage may have a set of data that it must read or write from the database. The
database details of each Workflow Stage are defined in the Workflow Stages section of
this specification due to the customized data that must be stored for each and every stage.
Each stage is responsible for managing its interaction with the database. If any database-related
error occurs, then the appropriate database read or write exception is generated.
Advancing to the Next Stage
Once all the required actions have been completed in a Workflow Stage and no
exceptions have been generated, the Workflow Manager updates the Vehicle’s Workflow
Stage to the next Workflow Stage. Within the Application section within Workflow
Stages, the following symbol represents the start or finish of a Workflow Stage:
If an error occurs while updating the Vehicles’ status, then the appropriate database read
exception is generated.

Managing Exceptions
The Workflow Manager catches all the exceptions thrown within a stage, logs them to the
database and updates the Vehicles’ status. Usually, the Workflow Manager is processing
many Vehicles at the same time. If one Vehicle encounters an exception, the exception
should be logged to the database, and the Workflow Manager should continue processing
the remaining Vehicles.
The following exceptions may occur at each Workflow Stage:
ExceptionType Description
IncomingTransmissionException An error in receiving the XML data from an
external server.
OutgoingTransmissionException An error in sending the XML data to an external
server.
IncomingTransformationException An error in transforming the incoming XML to
VNXML.
OutgoingTransformationException An error in transforming the outgoing XML to
VNXML.
RequestException An error in the incoming XML data. Possibilities
include missing fields or fields with erroneous data.
ResponseException An error in the outgoing XML data. Possibilities
DatabaseReadException An error occurred reading from the database.
DatabaseWriteException An error occurred writing to the database.
WorkflowClassException An error occurred in one of the
WorkflowManager’s components.
UnknownException An unknown error occurred.
If an error in logging an exception to the database occurs, the Workflow Manager should
then attempt to log the exception to a file, provide additional relevant information in that
file, attempt to email an administrator with the previously logged details and then fail
gracefully.
The section Exceptions within Workflow Stages defines the exceptions supported by
each stage. Within the Application section within Workflow Stages, the following
symbol represents an exception:

Resolving Exceptions
Currently, exceptions must be resolved manually. After a Vehicle’s exception has been
resolved, the Vehicle’s exception should be manually cleared, using an administrative
interface. Then, the Workflow Manager can process the Vehicle correctly.
Workflow Manager
The Workflow Manager is a threaded command and control application. The Workflow
Manager takes the set of Vehicles in a given Workflow Stage and attempts to process
each Vehicle one by one, using the relevant Workflow Stage class. Here is some sample
code demonstrating the process:
public void WorkflowManager( Guid WorkflowStageId ) {
If ( … ) {
…
} else If (WorkflowStageId == WorkflowStageBuildCAR ) Then
Get Vehicles for Build CAR WorkflowStage {
1. Run WorkflowManagerBuildCAR class (see below)..
2. Log any Workflow Exceptions, if they occurred.
3. Advance to the next Workflow Stage, if no Workflow
Exceptions.
}
} else If (WorkflowStageId == WorkflowStageAcquireFIWData ) Then
Get Vehicles for Acquire FIW WorkflowStage {
1. Run WorkflowManagerAcquireFIWData class (see below).
2. Log any Workflow Exceptions, if they occurred.
3. Advance to the next Workflow Stage, if no Workflow
Exceptions.
}
}
…
}
Classes
The following classes are required to support the WorkflowManager:
Class Description
WorkflowManager The primary command and control loop.
AcquireVehicleWorkflowStage Class to control execution of the Acquire
Vehicle stage.
DecodeVINWorkflowStage Class to control execution of the Decode
VIN stage.
SelectVehicleForAuctionWorkflowStage Class to control execution of the
SelectVehicleForAuction stage.
NotifyInspectionCompanyWorkflowStage Class to control execution of the Notify
Inspection Company stage.
AcquireThirdPartyDataWorkflowStage Class to control execution of the Acquire

Third-party Data stage.
AcquireThirdPartyData
VehicleHistoryDataWorkflowStage
Class to control execution of the Acquire
Vehicle History Data stage. This is a sub-stage
of the Acquire Third-party Data
stage.
BuildCARWorkflowStage Class to control execution of the Build
CAR stage.
AcquireFIWDataWorkflowStage Class to control execution of the Acquire
FIW stage.
AuctionVehicleWorkflowStage Class to control execution of the Auction
Vehicle stage.
ManageAuctionWorkflowStage Class to control execution of the Manage
Auction stage.
CloseAuctionWorkflowStage Class to control execution of the Close
Auction stage.
Database Support
Three primary tables support Inventory Management: WorkflowStages, VehicleSources
and Vehicles.
WorkflowStages (along with WorkflowExceptions and
WorkflowExceptionDescriptions) describes the workflow model and tracks any errors
encountered while processing a Vehicle.
VehicleSources relates the source of a vehicle (VehicleSources) to the manufacturer
(ManufacturerSources), inspection company (InspectionSources) and third-party data
suppliers (ThirdPartyDataSources). InspectionSources and ThirdPartyDataSources
describe specific suppliers of external data and point to the transforms required to
normalize their external data to VNXML. ManufacturerSources provide override
capabilities for InspectionSources and ThirdPartyDataSources. It is very likely that
ManufacturerSources will never be used. It is, however, desirable to accommodate this
functionality now rather than later. The specific example of overriding the inspection
company should be implemented in the first version of the Inventory Manager.
The Vehicles table binds VehicleSources, ManufacturerSources and InspectionSources to
a Vehicle. ThirdPartyDataSources are not related to Vehicles (they are only related to
VehicleSources) due to the generic nature of the data acquired through these sources.
The following tables will be created or extended to support ViaTrade’s Inventory
Management system:
Table Description
WorkflowStages Defines the stages in ViaTrade’s workflow. This
table should rarely change.
WorkflowExceptions Defines the exceptions in ViaTrade’s workflow. This

WorkflowExceptionDescriptions Stores the descriptions of the workflow exceptions
that occur during the Inventory Management
process.
VehicleSources Identifies from where ViaTrade sourced the Vehicle.
For example, this could be a bank or leasing
institution. This table should rarely change, until
ViaTrade starts transacting significant volumes of
Vehicles.
ManufacturerSources Identifies the manufacturer of the Vehicle. This table
should change infrequently, until ViaTrade starts
transacting significant volumes of Vehicles.
InspectionSources Identifies the inspector of the Vehicle. This table
should rarely change, until ViaTrade starts
transacting significant volumes of Vehicles.
ThirdPartyDataSources Identifies third-party sources for Vehicle data. This
Vehicles Stores the Vehicles that are flowing through the
Inventory Management system. This table tracks the
work
WorkflowStages
Here is the WorkflowStages table:
Column Type Description
WorkflowStageId Guid Unique identifier for a Workflow Stage.
Name nchar(64) Name of the Workflow Stage.
NextWorkflowStageId Guid WorkflowStageId for the next Workflow
Stage in ViaTrade’s workflow.
The following stored procedures are required:
Stored Procedure Name Description
GetFirstWorkflowStage( ) Get the first Workflow Stage in ViaTrade’s workflow.
GetNextWorkflowStage(
Get the Workflow Stage after the current Workflow
Guid WorkflowStageId
Stage.
)
GetWorkflowStage(
)
Get the Workflow Stage by its WorkflowStageId.
WorkflowExceptions
The WorkflowExceptions table supports the exception types described in the section
Exception Handling. Here is the WorkflowExceptions table:

WorkflowExceptionId Guid Unique identifier for a workflow exception.
Name nchar(64) Name of the workflow exception.
GetWorkflowException(
Guid WorkflowExceptionId
)
Get the Workflow Exception by its
WorkflowExceptionId.
WorkflowExceptionDescriptions
Here is the WorkflowExceptionDescriptions table:
WorkflowExceptionDescriptionId Guid Unique identifier for a workflow
exception description.
Description nchar(2048)? A description of a specific
workflow exception. The
description should be generated
by the application.
DateLogged Datetime Date and time when the error
occurred.
VehicleId Guid Identifies the Vehicle when the
exception occurred. Can be null.
Resolved bit Determines if the workflow
exception has been resolved or
not.
CreateWorkflowExceptionDescription(
nchar( 2048? ) Description
Guid VehicleSourceId
Guid ManufacturerSourceId
Guid VehicleId
)
Create a workflow exception description.
Creates a Guid for the
WorkflowExceptionDescriptionId. Sets
DateLogged to ‘now’. Sets Resolved to ‘0’.
GetWorkflowExceptionDescription(
Guid WorkflowExceptionDescriptionId
)
Get the specified Workflow Exception
Description.
ResolveWorkflowExceptionDescription(
Guid WorkflowExceptionDescriptionId
)
Resolve the Workflow Exception Description
by setting Resolved to ‘1’.

VehicleSources
Here is the VehicleSources table:
VehicleSourceId Guid Unique identifier for a Vehicle
Source.
Name nchar(128) Name of the company supplying
ViaTrade with Vehicles.
GetVehicleSource(
)
Gets a VehicleSource by its VehicleSourceId.
Note: No create or delete procedures are defined due to the low volume nature of the
current implementation.
ManufacturerSources
Here is the ManufacturerSources table:
ManufacturerSourceId Guid Unique identifier for the
manufacturer of the Vehicle.
Name nchar(128) Name of the manufacturer
source.
VehicleSourceId Guid Identifies the Vehicle Source
for the inspection company.
InspectionOutgoingXSLTransformation nchar(512?) Filename of the XSL file used
to transform the outgoing
inspection requests.
InspectionIncomingXSLTransformation nchar(512?) Filename of the XSL file used
to transform the incoming
inspection results.
Note: If either InspectionOutgoingXSLTransformation or
InspectionIncomingXSLTransformation is not null, then the corresponding non-null
values should be used for transforming the incoming and/or outgoing XML data. It
should be assumed that the same inspection company will be used to inspect the vehicle.
GetManufacturerSource(
Gets a ManufacturerSource by its
ManufacturerSourceId.
)

InspectionSources
Here is the InspectionSources table:
InspectionSourceId Guid Unique identifier for the inspection
company that inspects the Vehicle.
Name nchar(128) Name of the inspection company.
VehicleSourceId Guid Identifies the Vehicle Source for
the inspection company.
OutgoingXSLTransformation nchar(512?) Filename of the XSL file used to
transform the outgoing inspection
requests.
IncomingXSLTransformation nchar(512?) Filename of the XSL file used to
transform the incoming inspection
results.
GetInspectionSource(
Guid InspectionSourceId
)
Gets an InspectionSource by its InspectionSourceId.
ThirdPartyDataSources
Here is the ThirdPartyDataSources table:
ThirdPartyDataSourceId Guid Unique identifier for the inspection
company that inspects the Vehicle.
Name nchar(128) Name of the inspection company.
VehicleSourceId Guid Identifies the Vehicle source for the
inspection company.
OutgoingXSLTransformation nchar(512?) Filename of the XSL file used to
transform the outgoing inspection
requests.
IncomingXSLTransformation nchar(512?) Filename of the XSL file used to
transform the incoming inspection
results.

GetThirdPartyDataSource(
Guid ThirdPartyDataSourceId
)
Gets a ThirdPartyDataSource by its
ThirdPartyDataSourceId.
Vehicles
Here is the Vehicles table:
VehicleId Guid Unique identifier for a Vehicle.
VehicleSourceId Guid Identifies the Vehicle’s source.
ManufacturerSourceId Guid Identifies the Vehicle’s
manufacturer.
InspectionSourceId Guid Identifies the Vehicle’s inspector.
WorkflowStageId Guid Identifies the Workflow Stage that
the Vehicle is currently in.
WorkflowExceptionId Guid Identifies the Workflow Stage
exception (if any) for the current
Workflow Stage.
WorkflowExceptionDescriptionId Guid Identifies the description of the
Workflow Stage exception (if any).
WorkflowStageAdvancedDate Datetime The time when the Vehicle
advanced to the next Workflow
Stage.
VIN nchar(18) VIN of the Vehicle.
Make Make/manufacturer of the Vehicle.
Model Model of the Vehicle.
YearMade int Year the Vehicle was made.
Trim Trim on the Vehicle.
CreateVehicle(
Guid InspectionSourceId
nchar(18) VIN
nchar(?) Make
nchar(?) Model
int YearMade
nchar(?) Trim
Creates a Vehicle. Creates a Guid for the VehicleId.
Calls GetFirstWorkflowStage( ) and sets
WorkflowStageId. Sets WorkflowExceptionId and
WorkflowExceptionDescriptionId to null.

)
GetVehicle(
Guid VehicleId
)
Get a Vehicle by its VehicleId.
UpdateVehicleWorkflowStage(
Guid VehicleId
)
Updates the Vehicle’s WorkflowStageId. Sets
WorkflowExceptionId and
WorkflowExceptionDescriptionId to null.
UpdateWorkflowException(
Guid VehicleId
Guid WorkflowExceptionId
Guid
WorkflowExceptionDescriptionId
)
Updates the Vehicle’s WorkflowExceptionId and
WorkflowExceptionDescriptionId.
GetVehiclesByWorkflowStageId(
)
Get Vehicles for a specific Workflow Stage.
Workflow Stages
This section defines the technical details of each Workflow Stage and is structured as
follows:
· A brief description of the stage.
· A diagram of the stage’s application/process flow.
· The XML inputs and outputs of the stage.
o The ViaTrade Normalized XML (VNXML) for each input and output.
o A key mapping the VNXML fields to more readable terms.
· The database extensions required by the stage.
· The exceptions thrown by the stage.
Acquire Vehicle
This is the first stage of ViaTrade’s workflow. In this stage, banks and leasing institutions
notify ViaTrade that they have a set of Vehicles that require being evaluated for auction.
Application
The following diagram illustrates how this stage works:

XML
Incoming XML requests are transformed using the following VNXML format.
XML Data Format
The VNXML format for incoming evaluation requests is:
<my:AcV
xmlns:my=http://schemas.microsoft.com/office/infopath/2003/myXSD/2004-07-
21T00:02:32
xml:lang="en-us">
<my:VS
my:VSID="Guid"
my:ISID="int"
/>
<my:AcVVs>
<my:V
VIN="VIN"
/>
</my:AcVVs>
</my:AV>
XML Data Key
Here is the incoming key:
AcV - AcquireVehicle
VS - VehicleSource
VSID - VehicleSourceId
ISID - InspectionSourceId
AcVVs - AcquireVehicleVINs
V - Vehicle
VIN – VIN

Database Extensions
The table CARXMLs is required to store the initial CAR XML template created for the
Vehicle:
VehicleId Guid Unique identifier for a Vehicle.
CARXML ntext Stores the Vehicle’s CAR XML.
CreateCARXML(
Uniqueidentifier VehicleId
nchar(5096?) CARXML
)
Creates a Vehicle’s CARXML entry in the database.
UpdateCARXML(
Guid VehicleId
nchar(5096?) CARXML
)
Updates a Vehicle’s CARXML entry in the database.
DeleteCARXML(
Guid VehicleId
)
Delete a Vehicle’s CARXML entry in the database.
Exceptions
external server.
VNXML.
Decode VIN
In this stage, ViaTrade decodes the VIN of the Vehicle to get data such as the Make,
Model, Year Made and Trim of the Vehicle.
Application

XML
Outgoing and incoming XML requests are transformed using the following VNXML
format.
XML Data Format
The VNXML format for outgoing decode requests is:
<my:VD xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2004-07-
21T00:02:32" xml:lang="en-us">
<my:VDVs>
<my:V
VIN="VIN"
/>
</my:VDVs>
</my:VD>
The VNXML format for incoming decode results is:
<my:VD>
<my:V
VIN="VIN"
>
<my:VD
my:VDV="VIN"
my:VDE="string"
my:VDMa="string"
my:VDMo="string"
my:VDYM="int"
/>
</my:V>
</my:VD>

XML Data Key
Here is the outgoing key:
VD - VINDecode
VDVs - VINDecodeVehicles
V - Vehicle
VIN - VIN
VD - VINDecode
V - Vehicle
VIN - VIN
VD - VinDecode
VDV - VinDecodeVIN
VDE - VinDecodeEngine
VDMa - VinDecodeMake
VDMo - VinDecodeModel
VDT - VinDecodeTrim
VDYM - VinDecodeYearMade
Database Extensions
VIN Decoder updates the Vehicle’s CARXML entry in the database. As a result, no
database extensions are required for this stage.
Exceptions
external server.
server.
VNXML.
VNXML.
Select Vehicle for Auction
In this stage, an analyst (from ViaTrade or the bank/leasing institution) selects the
Vehicles to auction.

Application
Database Extensions
Marketplace Intelligence is a separately bundled piece of functionality. Its scope is not
included in this document. In addition, Select Vehicles for Auction does not store any
custom information for a specific Vehicle. As a result, no database extensions are
required for this stage.
Exceptions
Notify Inspection Company
In this stage, ViaTrade notifies the inspection company to inspect the Vehicle and stores
the results of the inspection.
Application

XML
format.
XML Data Format
The VNXML format for outgoing inspection requests is:
<my:NIC
xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2004-07-
21T00:02:32"
xml:lang="en-us"
>
<my:NICVs>
<my:V
my:VIN="VIN"
/>
</my:NICVs>
</my:NIC>
The VNXML format for incoming inspection results is:
<my:NIC
21T00:02:32"
xml:lang="en-us"
>
<my:VS
my:MSID="Guid"
my:ISID="int"
my:VIN="VIN"
/>
<my:V
my:VIN="VIN"

>
<my:DLIs>
<my:LI
my:LIN="string"
>
<my:D>string
<my:/D>
<my:/LI>
<my:/DLIs>
<my:/V>
<my:/NIC>
XML Data Key
NIC - NotifyInspectionCompany
NICVs - NotifyInspectionCompanyVehicles
V - Vehicle
VIN - VIN
NIC - NotifyInspectionCompany
VS - VehicleSource
MSID - ManufacturerSourceId
V - Vehicle
VIN - VIN
DLIs - DamagedLineItems
LI - LineItem
D - Damage
Database Extensions
Notify Inspection Company updates the Vehicle’s CARXML entry in the database. As a
result, no database extensions are required for this stage.
Exceptions
external server.
server.
VNXML.
VNXML.

Acquire Third-party Data
In this stage, ViaTrade acquires authoritative third-party data regarding the Vehicle. This
section describes the generic approach for acquiring third-party data. Specific
applications of third-party data (such as getting the Vehicle’s history) extend this
definition. Please see the section Acquire Vehicle History Data for an example extension
of acquiring third-party data.
Application
XML
format.
XML Data Format
The generic VNXML format for outgoing third-party data requests is:
<my:TPD
21T00:02:32"
xml:lang="en-us"
>
<my:TPDVs>
<my:V
my:VIN="VIN"
/>
</my:TPDVs>
</my:TPD>

The generic VNXML format for incoming third-party data results is:
<my:TPD
21T00:02:32"
xml:lang="en-us"
>
<my:VS
my:VSID="Guid"
my:ISID="int"
my:VIN="VIN"
/>
<my:V
my:VIN="VIN"
>
<my:CustomThirdPartyDataResults>
<my:/CustomThirdPartyDataResults>
<my:/V>
<my:/TPD>
XML Data Key
TPD - ThirdPartyData
TPDVs - ThirdPartyDataVINs
V - Vehicle
VIN - VIN
VS - VehicleSource
V - Vehicle
VIN - VIN
CustomThirdPartyDataResults – CustomThirdPartyDataResults
Database Extensions
Acquire Third-party Data updates the Vehicle’s CARXML entry in the database. As a
result, no database extensions are required for this stage.
Exceptions
external server.
server.
VNXML.
VNXML.

Acquire Vehicle History Data
This stage describes the acquisition of Vehicle history data. It also can be used as an
example for defining subsequent third-party data acquisition applications.
Application
XML
format.
XML Data Format
The VNXML format for outgoing Vehicle history requests is:
<my:TPD
21T00:02:32"
xml:lang="en-us"
>
<my:TPDVs>
<my:V

my:VIN="VIN"
/>
</my:TPDVs>
</my:TPD>
The generic VNXML format for incoming Vehicle history results is:
<my:TPD
21T00:02:32"
xml:lang="en-us"
>
<my:VS
my:VSID="Guid"
my:ISID="int"
my:VIN="VIN"
/>
<my:V
my:VIN="VIN"
>
<my:VI>
my:VILVCD="date"
my:VIIL="bool"
--my:VIFE="bool"
my:VIOL="int"
my:VIORA="int"
my:VIOR="int"
--my:VIOHIS="bool"
my:VIHTI="bool"
--my:VITS="bool"
--my:VITEML="bool"
--my:VITD="bool"
--my:VITDT="bool"
--my:VITNAM="bool"
--my:VITOOB="bool"
--my:VITWD="bool"
--my:VIT="bool"
--my:VITR="bool"
<my:/VI>
<my:/V>
<my:/TPD>
XML Data Key
TPDVs - ThirdPartyDataVINs
V - Vehicle
VIN - VIN
VS - VehicleSource
V - Vehicle
VIN - VIN
VI - VehicleIndicators
VILVCD - VehicleIndicatorsLastVINCheckDate
VIIL - VehicleIndicatorsIsLemon
--VIFE - VehicleIndicatorsFailedEmission
VIOL - VehicleIndicatorsOdometerLast

VIORA - VehicleIndicatorsOdometerRollbackAmount
VIOR - VehicleIndicatorsOdometerRollback
--VIOHIS - VehicleIndicatorsOdometerHasIndependentSource
VIHTI - VehicleIndicatorsHasTitleIssue
--VITS - VehicleIndicatorsTitleSalvage
--VITEML - VehicleIndicatorsTitleExceedsMechanicalLimits
--VITD - VehicleIndicatorsTitleDamage
--VITDT - VehicleIndicatorsTitleDuplicateTitle
--VITNAM - VehicleIndicatorsTitleNotActualMiles
--VITOOB - VehicleIndicatorsTitleOtherOdometerBrand
--VITWD - VehicleIndicatorsTitleWaterDamage
--VIT - VehicleIndicatorsTheft
--VITR – VehicleIndicatorsTheftRecovered
Note: Items preceded with ‘--‘ are currently not supported.
Database Extensions
Acquire Vehicle History Data updates the Vehicle’s CARXML entry in the database. As
a result, no database extensions are required for this stage.
Exceptions
external server.
server.
VNXML.
VNXML.
Build CAR
This stage is responsible for generating the CAR and storing the results.
Application

XML
The CAR Builder uses the following VNXML format.
XML Data Format
<my:CR>
<my:LIs>
<my:LI
my:LIN="string"
my:ISI="int"
my:LII="Guid"
my:PG="Guid"
my:SG="Guid"
my:LIO="nt"
>
<my:D>string
</my:D>
<my:S>string
</my:S>
</my:LI>
</my:LIs>
<my:LIGs>
<my:PGs>
<my:PG
my:LIGI="Guid"
my:LIGN="string"
my:LIGO="int"
>
<my:SGs>
<my:SG
my:LIGI="Guid"
my:LIGN="string"
my:LIGO="int"
>
</my:SG>
</my:PG>
</my:PGs>
</my:LIGs>
<my:LIO>
<my:LIOPGs>
<my:LIOPG

my:LIGN="string"
my:LIGO="int"
>
<my:LIOSGs>
<my:LIOSG
my:LIGN="string"
my:LIGO="int"
>
<my:LIOS>string
</my:LIOS>
</my:LIOSG>
</my:LIOSGs>
</my:LIOPG>
</my:LIOPGs>
</my:LIO>
<my:MMs>
<my:MM
my:MMI="Guid"
my:MMXEN="string"
>
</my:MMs>
</my:CR>
XML Data Key
CR - ConditionReport
LIs - LineItems
LI - LineItem
D - Damage
S - Sentence
LIGs - LineItemGroups
PG - Primary Group
SG - SecondaryGroup
LIO - LineItemOverview
LIOPGs - LineItemOverviewPrimaryGroups
LIOSGs - LineItemOverviewSecondaryGroups
MMs - MarketingMessages
MM - MarketingMessage
MMM - MarketingMessageMessage
Database Extensions
Build CAR is a separately bundled piece of functionality. Its scope is not included in this
document. In addition, Build CAR updates the Vehicle’s CARXML entry in the database.
As a result, no database extensions are required for this stage.
Exceptions
Acquire FIW Data
In this stage, ViaTrade looks up and stores financing-, insurance- and warranty-related
information. Currently, this data is not expected to live on third-party servers.

Application
XML
Acquire FIW Data uses the following VNXML format.
XML Data Format
<my:FIWD
21T00:02:32"
xml:lang="en-us"
>
<my:FIWDVs>
<my:V
my:VIN="VIN"
/>
<my:FinanceInsuranceWarrantyData>
<my:/FinanceInsuranceWarrantyData>
</my:FIWDVs>
</my:FIWD>
XML Data Key
FIWD - FinanceInsuranceWarrantyData
FIWDVs - FinanceInsuranceWarrantyDataVINs
V - Vehicle
VIN - VIN
FinanceInsuranceWarrantyData - FinanceInsuranceWarrantyData
Note: FinanceInsuranceWarrantyData has not yet been determined.

Database Extensions
Acquire FIW Data updates the Vehicle’s CARXML entry in the database. As a result, no
database extensions are required for this stage.
Exceptions
Auction Vehicle
In this stage, ViaTrade submits the Vehicle for auction, using one of ViaTrade’s auction
partners.
Application
XML
format.
XML Data Format
The VNXML format for outgoing auction requests is:
<my:AuV
21T00:02:32"
xml:lang="en-us"
>
<my:V

my:VIN="VIN"
>
<my:CustomAuctionData>
<my:/CustomAuctionData>
<my:/V>
<my:/AuV>
The VNXML format for incoming auction results is:
<my:AuV
21T00:02:32"
xml:lang="en-us"
>
<my:V
my:VIN="VIN"
>
<my:/V>
<my:/AuV>
XML Data Key
AuV - AuctionVehicle
V - Vehicle
VIN - VIN
CustomAuctionData- CustomAuctionData
Note: CustomAuctionData has not been determined yet.
AuV - AuctionVehicle
V - Vehicle
VIN - VIN
Database Extensions
No database extensions are required for this stage.
Exceptions
external server.
server.
VNXML.
VNXML.

Manage Auction
In this stage, a sales person representing ViaTrade manages the auction of the Vehicle.
Application
Database Extensions
Exceptions
All Exceptions are handled by the third-party auction servers.
Close Auction
In this stage, ViaTrade closes all auctions that have finished. This is the last step in
ViaTrade’s workflow.
Application

XML
format.
XML Data Format
The VNXML format for outgoing auction requests is:
<my:CA
21T00:02:32"
xml:lang="en-us"
>
<my:V
my:VIN="VIN"
>
<my:/V>
<my:/CA>
The VNXML format for incoming auction results is:
<my:CA
21T00:02:32"
xml:lang="en-us"
>
<my:V
my:VIN="VIN"
>
<my:/V>
<my:/CA>
XML Data Key

CA - CloseAuction
V - Vehicle
VIN - VIN
CA - CloseAuction
V - Vehicle
VIN - VIN
Database Extensions
Exceptions
external server.
server.
VNXML.
VNXML.
Reporting
The following reports are required by the Inventory Management system:
Report Description
Status Report Describes the number of Vehicles in each Workflow Stage.
Divides the number of Vehicles between those with and without
exceptions.
Workflow Exception
Report
Describes the exceptions that are occurring in each Workflow
Stage.
Average Vehicle
time in Workflow
Stage
Describes the average amount of time each Vehicle spends in
each Workflow Stage.

Longest time in
stage
Describes the Vehicles with the longest times in each Workflow
Stage.
???

Inventory Management - Technical Specification Document

Recommended

Recommended

More Related Content

Similar to Inventory Management - Technical Specification Document

Similar to Inventory Management - Technical Specification Document (20)

More from Gregory Weiss

More from Gregory Weiss (20)

Recently uploaded

Recently uploaded (19)

Inventory Management - Technical Specification Document