Content Comparison

<sp:ApptOfferMultRequest>

<RequestCount>?</RequestCount>

Unsigned int

the total number of individual appointments in the overall job

<MultOptions>

OptSet

A bit field containing the options for this

<AllowEmpOT>?</AllowEmpOT>

<OfferTextEmpID>?</OfferTextEmpID>

<DupUseEmpID>?</DupUseEmpID>

<SpareIgnVanStock>?</SpareIgnVanStock>

<OfferTextCost>?</OfferTextCost>

<OfferBestOnlyPerEmp>?</OfferBestOnlyPerEmp>

 If supplied, then only the best set of offers for each available employee will be returned.  The best offer is the earliest one whose PromType matches the supplied NumReqType.

<RestrictSearch>?</RestrictSearch>

 If supplied, then the search for sets of offers will be biased towards those employees for whom the greater numbers of possible offers were found for the first jobs in the request.

</MultOptions>

<MinPartialMatchCount>?</MinPartialMatchCount>

Unsigned int

MinPartialMatchCount determines whether partial matches are to be returned. If, for example, RequestCount is 4 and MinPartialMatchCount is 2, and a set of 4 offers is not available for a particular employee, then partial offers containing 3 and 2 offers will be returned. In this case 4 offers will still be returned, but the ones where there is no match will be null, i.e. the first field of the SP_ApptOffer, ApptDate, will be an empty string (“”). If RequestCount and MinPartialMatchCount have the same value, no partial matches will be returned

<OfferAppts>

See ApptOfferRequest structure above, apart from:

<promBand>

<timeBandID>?</timeBandID>

TimeBandID

<start>?</start>

The value of Start should be different for each OfferAppt supplied. The first OfferAppt should contain a Start as it would in a call to OfferApptRequest. Subsequent OfferAppt will contain a Start, but should normally specify it in a relative way in either of the following formats:

Relative Whole Day Appointments

+n     Start is interpreted as being exactly n days (operative days) after the Start in the previous OfferAppt (e.g. “+1” means exactly one day after the Start in the previous OfferAppt).

>=n   Start is interpreted as being at least n days after the Start in the previous OfferAppt).

As an example: to get offers for 3 contiguous days from a given () date, the first Start should be that given () date and the second and third Start should both be “+1”.

In both cases, n should be 1 or greater, but not so great that the search isn’t within the memory horizon.

Part Day Appointments

For part day appointments, where the PromSet field is used, for example, to specify a set of half day TimeBands, a relative StartDate will contain a count of a number of TimeBands instead of a number of days, i.e:

+n(TBT)                Start is exactly n TimeBands after (ordered by their start times) the Start in the previous OfferAppt, where TBT is the type of the TimeBands which n is counting, but is on the same day. For example, if, in the ServiceOptimizer database, there is a TimeBand type of “HD” for all half day timebands, then “+1(HD)” means half day (HD) after the Start in the previous OfferAppt, but on the same day (i.e. the first appointment is in the morning, the second in the afternoon).

>=n(TBT)             is similar to the above, except that Start is interpreted as being at least n time bands of type TBT after the Start in the previous OfferAppt, but not necessarily on the same day.

The OfferAppts structure is the same as defined for sp:ApptOfferRequest API method in the Request Appointments SOAP API, but with the following exclusions listed below.

<band></

band>

spDateTime

If End is supplied in the first OfferAppt but not in subsequent ones, those Ends will be defaulted to be the same number of days after their corresponding Start as the first End is after the first Start

The entire band structure of the sp:ApptOfferRequest API method must not be used inside the OfferAppts structure for an sp:ApptOfferMultRequest API method call.

</

OfferAppts>

</OfferAppts><

OfferCount><OfferCount>?</OfferCount>

</sp:ApptOfferMultRequest>