Unlike legacy vehicle sharing, ISI Central Vehicle Sharing supports field level modification times for vehicle data. This allows for data changes in different fields to be merged from multiple stores instead of overwriting all vehicle data with a record-level “last in wins” methodology. If one store updates a vehicle’s address and another store updates the vehicle’s phone numbers before getting the address change, both changes will be represented in the ISI Central data.
In the ISI Central database, vehicles can be in one of two states: Deleted or Active. Within a national sharing group there can be only one Active record for any LubeSoft vehicle ID. There can be multiple Deleted records for a Lubesoft vehicle ID. All vehicle records in ISI Central are given a unique ID.
When adding new vehicles at ISI Central the process checks within the national vehicle sharing group for a record with the same vehicle ID. If no match exists a new vehicle record is added and the data is saved. If a match exists, the YMME information of the incoming and existing vehicles is compared. If the YMME information matches, the existing vehicle information is updated with the incoming data. This update process compares the modification time of each field in the vehicle data and updates any fields where the incoming data is newer (see Edit Vehicle). If the YMME information does not match, the system looks for the string “converted” in the mkf1.misc field. This value is set on vehicles that have been processed as part of the third party conversion process. If this value is found then the incoming service history will be merged with the existing ISI Central vehicle. If “converted” is not found then the modification times of the vehicles are compared. If the incoming vehicle is more recent, the existing ISI Central vehicle is deleted and a new record is added for the incoming vehicle. If the incoming vehicle is older, the ISI Central vehicle is associated with the originating store and a deleted record is created for the incoming vehicle.
When processing vehicle edits at ISI Central the process searches the national vehicle sharing group for the vehicle record by its unique_id. If the record is found and it is active, the data is updated. The update compares the incoming modification time stamp with the saved modification time of each field that was updated at the store. Changes are ignored if existing data is newer than an incoming change. If the vehicle record found is deleted then the modification times of the vehicle data are compared. If the incoming change is older than the delete, the data for the deleted record is updated. If the incoming change is newer than the delete, a new vehicle record is created from the incoming data. If the found vehicle record was deleted because of a merge then look up the “merge to” vehicle record(s) until the found record was not merged. If the final found record is active and the YMME data matches the incoming vehicle, the service history of the “merge to” vehicle is updated and any other changes are discarded. If the final found record is active but the YMME data does not match, the original “merge from” vehicle data is updated and remains deleted. If the final found record is deleted and the incoming changes are older than the delete, the deleted vehicle’s data is updated. If the final found record is deleted and the incoming changes are newer than the delete, a new vehicle record will be created from the incoming data.
Each time a new vehicle is created the process follows the same rules as processing an added vehicle from a store. This means the vehicle ID checks are also performed when processing vehicle edits. If the incoming change involved changing the vehicle ID the process checks for an existing record with that ID. If a record is found, the YMME data of the vehicles is compared. If the YMME data matches and the incoming change is newer than the existing data, the service history from the existing vehicle is merged with the incoming vehicle and the incoming vehicle is updated. If the YMME data matches and the incoming change is older, the service history of the incoming vehicle is merged with the existing vehicle and the incoming vehicle is deleted. If the YMME data does not match and the incoming change is newer, the existing vehicle will be deleted, and the incoming vehicle is updated. If the YMME data does not match and the incoming change is older, the incoming vehicle is deleted.
Some fields are processed as a group, where a change to one field results in an update to an entire group of fields. The field groups processed in this manner are listed below:
ADDRESS_FIELD_GROUP = ADDR1, ADDR2, CITY, STATE, ZIP
HOME_PHONE_FIELD_GROUP = AREACODE, PHONE
WORK_PHONE_FIELD_GROUP = AREACODE1, PHONE1
CELL_PHONE_FIELD_GROUP = AREACODE2, PHONE2
OTHER_PHONE_FIELD_GROUP = AREACODE3, PHONE3
When processing incoming vehicle deletes the process searches for the vehicle record by unique_id. If the record is already deleted or merged the delete is ignored. If the vehicle is active the modification times are compared. If the incoming delete is older than the saved last change the delete is ignored. If the delete is newer the vehicle and service history records are marked as deleted.
When processing new or edited service history the process searches for a service history record using the unique service history key. If no record is found and the vehicle is active, a new history record is created. If no record is found and the vehicle is deleted, a new deleted history record is created. If a record is found then the chg_date of the data is compared. If the incoming chg_date is older the update is ignored. If the incoming chg_date is newer and the existing record is active, the record will be updated. If the existing record is deleted, the incoming chg_date is compared to the deleted_at date of the existing record. If the deletion is newer than the change, the deleted record is updated. If the deletion is older, the record is made active again and is updated.
When processing service history deletes the process searches for the service history record by the unique service history key. If the record is found and is active, the chg_date of the data is compared. If the incoming delete is newer, the record is deleted. If the incoming delete is older, the delete is ignored. If the existing record is deleted, the delete is ignored.
When processing a new fleet or club association, a new record is added to associate the fleet or club data to the vehicle and to the fleet or club setup group, which is associated with the store location initiating the change. If the incoming change removes a fleet or club association, only the association for the store location’s fleet or club setup group is removed. If the incoming fleet or club association is for an override fleet or club, then a record is added to associate the vehicle to all fleet or club setup groups that are associated to the store’s National Vehicle Sharing Group. If the incoming change removes an override fleet or club association, all setup sharing group associations are removed. If the incoming change is from an override fleet or club to a non-override fleet or club, then the record for the store’s fleet or club setup group is updated and all other fleet or club setup group records for this vehicle are removed.