/
_API OfferAppsMultRequest Definition

_API OfferAppsMultRequest Definition

 Click here to expand...

Web Service

Type

Description

Req?

Val?

<sp:ApptOfferMultRequest>





 

<RequestCount>?</RequestCount>

Unsigned int

The total number of individual appointments in the overall job.

Y


 

<MultOptions>


See the "Offer/Book Options" for the definitions of the permitted MultOptions listed below.


N

 

 


<OfferBestOnlyPerEmp>?</OfferBestOnlyPerEmp>



N

 



<RestrictSearch>?</RestrictSearch>



N



</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

Y



<OfferAppts>


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





<start>






<date>?</date>spDate

The value of the start date should be different for each OfferAppts supplied.

The first OfferAppts should contain a start date as it would in the sp:ApptOfferRequest structure defined in the Request Appointments SOAP API.

However, subsequent OfferAppts will contain a start date which should normally be specified in a relative way in either of the following formats:

Relative Whole Day Appointments

+n

In this format, the start date is interpreted as being exactly n days (operative days) after the start date in the previous OfferAppts.

For example, +1 means exactly one day after the start date in the previous OfferAppts.

>=n

In this format, the start date is interpreted as being at least n days after the start date in the previous OfferAppts.


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

In both of the above cases, n must 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 start date will contain a count of a number of TimeBands instead of a number of days. That is:

+n(TBT)

Here, the start date is exactly n TimeBands after (ordered by their start times) the start date in the previous OfferAppts, 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 one half day (HD) after the start date in the previous OfferAppts, but on the same day (i.e. the first appointment is in the morning, the second in the afternoon).

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




</start>





<end>






<date>?</date>spDate

If the end date is supplied in the first OfferAppts but not in subsequent ones, those end date values will be defaulted to be the same number of days after their corresponding start date as the first end date value is after the first start date value.





</end>



 


<band></band>


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.





<displayCostBreakdown>?</displayCostBreakdown>boolean

If true return the Schedule Cost Breakdown structure details as part of the response. When set to true for at least one OfferApts structure, then the Cost Breakdown structure will be returned for all responses.

However, If either the forceOptions InTray or InTrayWithSkill options are set to true, then the Schedule Cost Breakdown structure will not be returned in the response.

N

 

</OfferAppts>

 




 

<OfferCount>?</OfferCount>

 


N


</sp:ApptOfferMultRequest>





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.

The use of spares has not been validated for the Integration ServiceOptimizer Request Multi-Job Appointments SOAP API.

No special function is provided to book multiple appointments. Instead, the caller should iteratively book the set of offers for one operative returned from a call to ApptOfferMultRequest. The ID of the operative should be supplied as the ‘mandatory tech’ in the EmpID field of the SP_ApptBook struct parameter to each call of ApptBookRequest; the StdExtraDuration field can be set to SPSD_DurationOneDay for ‘all day’ jobs.