_API OfferAppsMultRequest Response

Click here to expand...

Web Service			Type	Description	Req?	Val?
`<sp:ApptOfferMultResponse>`
	`<returnCode>?</returnCode>`			This contains the standard return structure.
	`<offers>`			Returned `offers` and `splitOffers` are of the same format as in the `ApptOfferResponse` structure.
		`<latitude>?</latitude>`	`Double`	This parameter is not supported for this API.	N	Y
		`<longitude>?</longitude>`	`Double`	This parameter is not supported for this API.	N	Y
		`<costBreakDownInformation>`		The `costBreakDownInformation` structure is only included in the response when required by the use of the `displayCostBreakdown` parameter in the request.
				See Integration ServiceOptimizer Common API Concepts Schedule Cost Breakdown for details of the `costBreakDownInformation` structure.
		`</costBreakDownInformation>`
	`</offers>`
	`<splitOffers>`

	`</splitOffers>`
`</sp:ApptOfferMultResponse>`

All of the fields to do with dates and times are assumed to use customer local TZ, i.e. local to the region where the job is located.

In the returned SP_ApptOffer structs:

The OfferText field will contain the ID of the RU (as it does now) followed (separated by a single space) by the EmpID of the operative tentatively assigned to this offer. This will allow the SMS to group together those offers which are for the same operative, and use the EmpID as the mandatory technician when subsequently booking appointments.
Offers are effectively grouped into sub-sets each containing RequestCount offers, so the returned value of OfferCount is always a multiple of RequestCount. Each sub-set contains RequestCount appointments for the same employee. Where partial matching has been specified (MinPartialMatchCount < RequestCount), null offers (empty ApptDate) are returned to maintain this. There can be more than one sub-set for the same employee only if OfferBestOnlyPerEmp is not set.
There can, of course, be sets of offers for more than one operative on the same ApptDates.
Where the StartDates in the supplied SP_ApptOffer structs use the relative notation described earlier, those offer sub-sets which cover the least elapsed time will be ranked lowest, i.e. best. Sub-sets with the same appointment dates, but for different operatives will be ranked according to the ranking of each individual offer, which will include a measure of the distance of the job from the operative’s start location.