3.13.1 - Support Vehicle Assignment for Interest Type "Inventory Vehicles"

General Description of the Feature

This feature deals with an enhancement in the vehicle assignment process. Vehicle Assignment process existing for Configured vehicles has been extended and support Inventory vehicles as well. Before the last step: "Vehicle Delivery" user can assign a new vehicle. There are many validations for the vehicle assignments:

1) VIN received from DMS should exist in the Inventory vehicles. If DMS tries to assign a VIN that doesn’t exist in the DSW – the process should be aborted. The DMS should be informed with the error explanation (API response – The vehicle cannot be assigned to the chosen Lead. Vehicle doesn’t exist in the vehicle inventory).

2) The comparison should be aligned with the dimension level of the vehicle, not the exact 1 to 1 comparison. If the vehicle does exist in the Inventory, but dimension permissions are not in compliance – DMS should be informed about the issue (API response – The vehicle cannot be assigned to the chosen Lead. The vehicle has incompatible dimension permissions)

3) If DocumentId or LineId validations is triggered, the API will return the following error message:“Request parameter DocumentNumber, LineID cannot be null.”

4) If a vehicle internal code is not provided or the specific vehicle does not exist in the XIS_CARS table then, the API will return the following error: “Vehicle with ID {given vehicle Id internal code} is not published".

5) If we do not provide a document entry the API will return the following error: “The document with DocEntry {provided document entry} was not found.”

6) If no VOI is found then the API will return the following error: “The VOI with ActiveDocumentCode { provided document entry } was not found”.

7) If the VOI is found then, we’ll get its interest type and the VOI’s dimension make. Then we validate that the interest type is an inventory interest and if so, that both the VOI’s dimension make and the given vehicle’s dimension make do not represent a USED make. The check for used makes is being done against the setup-key ‘UsedMakeCode’. If the validation won’t pass then the API will return the following error: “Interest type and/or vehicle should not represent a Used Make”

8) If it is the same vehicle, the API will return the following error: “The vehicle in the request is the same as the lead's vehicle.”

9) If no delivery is made (VehicleDeliveryDate = null) then the process can continue. If the vehicle is already delivered (VehicleDeliveryDate = some date) then no assignment can take place and thus, the API will return the following error:
“The vehicle cannot be assigned to the chosen Lead. The lead is already in ‘vehicle delivery’ state. VIN reassignment is possible only if the vehicle is not yet delivered”

10) Based on the dimension exclusion level the table XIS_CARS has we check that the vehicle’s dimensions (DIM_Company, DIM_Branch and DIM_Location) are either empty or, the same dimensions the lead has. And then, regardless of the dimension exclusion level, that the vehicle dimension make is the same as the lead’s dimension make. If either of the above does not pass the validation then the API will return the following error: “The vehicle cannot be assigned to the chosen Lead. The vehicle has incompatible dimensions”

 Wholesale Lead Specific Validations

Based on the document number provided, we’ll try to find the lead (wholesaleLead.U_IDMS_ActiveDocumentCode = document entry provided). If no lead is found then the API will return the following error: “The Multi-Unit Sale lead with { document entry provided } was not found”

After all validations have been passed successfully, the assignment process will begin.

1. Retail
   1. First a check is made on the vehicle to be assigned, if the VIN is empty or not.
      If it is empty then, the API will return ‘success’ but no assignment is made.
      Instead, a notification is sent to the user (lead’s sales person) with the following message:
      “The VIN {VOI’s VIN} was unassigned from the {Lead name}”
   2. If the VIN is not empty, then the VOI is updated with the new vehicle ID and VIN.
      
      
      
   3. If the VOI is updated successfully then
      1. we also update the lead just to get a new update date.
      2. We update all the realized entities with the new vehicle code.
      3. We ‘touch’ lucene vehicles to reset the vehicle counters.
      4. If all the above are done successfully then, we also send a notification to the user (lead’s sales person) with the following message: “New VIN {new car VIN} is assigned for the {lead’s name}”
2. Wholesale

                We update the specific vehicle in the wholesales lead vehicle collection, where the document line ID is the same as the one provided.

Business Benefit

Vehicle assignments are available for lead / opportunity with VOI from configurator or vehicle inventory

Configuration 

Workflow:

External Functions

Store Vehicle Delivery Date” (Code: 8DBD93D43FA28F4, Method: StoreVehicleDeliveryDate):  This external function is responsible to ‘mark’ a lead’s vehicle as ‘delivered’. For the above service to work as it should, it is imperative that the user assign this external function on the lead’s workflow, on the step that the vehicle is actually delivered to the customer. The role of this function is to update the Delivery Date field on the lead. If the vehicle is delivered then no vehicle assignment can be made after that.

Additional Information