The ability to Change information is wrapped up by any Action ending in the word Change - ie, ContactChange, VehicleChange, etc. It's important to understand that Changes are "Near Realtime". The PBS ARISTOGOLD product generally operates on a local server in the dealership and so every changes you submit to the Partner Hub are actually messages that are queued for processing. This queue is processed by the dealership server every minute or so.
Here's a sample Change Request for a Contact. The basic process for a Change involves two phases - Selection and Updating. We'll talk about those next.
<ContactChange xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/PBS.PartnerHub.ServiceModel">
<ContactInfo>
<Address>String</Address>
<ApartmentNumber>String</ApartmentNumber>
<BirthDate>0001-01-01T00:00:00</BirthDate>
<BusinessPhone>String</BusinessPhone>
<CellPhone>String</CellPhone>
<City>String</City>
<Code>String</Code>
<ContactName>String</ContactName>
<County>String</County>
<EmailAddress>String</EmailAddress>
<FaxNumber>String</FaxNumber>
<FirstName>String</FirstName>
<HomePhone>String</HomePhone>
<Id>00000000-0000-0000-0000-000000000000</Id>
<IsBusiness>false</IsBusiness>
<IsInactive>false</IsInactive>
<LastName>String</LastName>
<LastUpdate>0001-01-01T00:00:00</LastUpdate>
<MiddleName>String</MiddleName>
<Notes>String</Notes>
<Salutation>String</Salutation>
<SerialNumber>String</SerialNumber>
<State>String</State>
<ZipCode>String</ZipCode>
</ContactInfo>
</ContactChange>
A Change request first needs to determine which object needs to be changed. Essentially we use the Information provided to attempt to match an existing object and if that fails we then add a new object. Each object type has multiple fields we'll try and match and only if all those fields fail will we add a new object.
For example, on our system each Contact has both a Code and and Id. The Code is a User-Friendly Identifier that users will type when searching for customers they often use. The ID is a system generated GUID we use internally to associate customers and invoices, vehicles, deals, etc. When trying to make a selection for a CHange Request we will first attempt to match by ID, and if that doesn't work we will attempt to match by CODE. The different types of matches we will attempt are detailed below.
Contact: Id, Code Vehicle: Id, InvoiceNumber, VIN, StockNumber Deal: Id, DealKey RepairOrder: Id, RepairOrderNumber PartsInvoice: Id, InvoiceNumber
Once we have the object we need to update, we now need to alter data elements. When we look at a Change Request we basically take any data field that HAS a value in it and apply that change to the corresponding object. This means you can either exclude Elements you don't want to update or just leave them empty and either way we'll ignore them when updating the data.
The following Change request will match by CODE and then update the BusinessPhone property only as that's the only element that has been populated.
<ContactChange xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/PBS.PartnerHub.ServiceModel">
<ContactInfo>
<Address></Address>
<ApartmentNumber></ApartmentNumber>
<BirthDate>0001-01-01T00:00:00</BirthDate>
<BusinessPhone>4035551234</BusinessPhone>
<CellPhone></CellPhone>
<City></City>
<Code>12345</Code>
<ContactName>String</ContactName>
<County></County>
<EmailAddress></EmailAddress>
<FaxNumber></FaxNumber>
<FirstName></FirstName>
<HomePhone></HomePhone>
<Id>00000000-0000-0000-0000-000000000000</Id>
<IsBusiness>false</IsBusiness>
<IsInactive>false</IsInactive>
<LastName></LastName>
<LastUpdate>0001-01-01T00:00:00</LastUpdate>
<MiddleName></MiddleName>
<Notes></Notes>
<Salutation></Salutation>
<SerialNumber>2002</SerialNumber>
<State></State>
<ZipCode></ZipCode>
</ContactInfo>
</ContactChange>