Click here to expand...

This API contains the same information (and constraints) as if setting up an operative in ServiceManager. With this in mind, the detailed descriptions of each of the fields is limited in this document.

Web Service					Type	Description	Req?	Val?
`<sp:EmpCreateRequest>`
	`<empID>?</empID>`				`EmpID`
	`<empAttr>`
		`<type>?</type>`				SPET_Employee
		`<name>?</name>`
		`<surname>?</surname>`
		`<jobTitle>?</jobTitle>`
		`<efficiency>?</efficiency>`			`int`	How efficient is the employee? Value is used as a multiplier on the job duration. More efficient engineers will take less time to do the job. Value must be between (inclusive) 10 and 999. Normal value is 100
		`<maxOvertime>?</maxOvertime>`			`int`	What is the maximum amount of planned overtime that can be used for this employee? Values must be between (inclusive) 0 and 999.
		`<informLeadTime>?</informLeadTime>`			`int`	Normally the range of allowed values for InformLeadTime is held in the ServiceOptimizer database (i.e. between (inclusive) sp083.min_value and sp083.max_value where name = “TIL”). If either of these is not in the database, then the supplied value of InformLeadTime must be between 0 and 9999 respectively. If no informLeadTime is set for the employee then the FRU or system level ILT parameter will be used.
		`<earmarkedJobsMax>?</earmarkedJobsMax>`			`int`	The maximum number of jopbs that can be earmarked at any one time for this employee. Mst be between (inclusive) 1 and 99. If no value is set then the system/FRU levels are used.
		`<homePostcode>?</homePostcode>`			`Postcode`
		`<workPostcode>?</workPostcode>`			`Postcode`
		`<TZType>?</TZType>`			`EmpTZType`
		`<workTZ>?</workTZ>`				WorkTZ is a TimeZone of the form ‘Mountain’, ‘Eastern’ ‘Greenwich’. The chosen value must exist in the ServiceOptimizer database.
		`<available>?</available>`			`boolean`	Should the employee be schedulable
		`<defaultStartLoc>`
			`<locType>?</locType>`
			`<postcode>?</postcode>`		`Postcode`
		`</defaultStartLoc>`
		`<defaultEndLoc>`
			`<locType>?</locType>`
			`<postcode>?</postcode>`		`Postcode`
		`</defaultEndLoc>`
		`<defaultLKCLoc>`
			`<locType>?</locType>`
			`<postcode>?</postcode>`		`Postcode`
		`</defaultLKCLoc>`
		`<address1>?</address1>`
		`<address2>?</address2>`
		`<address3>?</address3>`
		`<address4>?</address4>`
		`<phone1>?</phone1>`
		`<phone2>?</phone2>`
		`<pager>?</pager>`
		`<handHeldAdd1>?</handHeldAdd1>`
		`<handHeldAdd2>?</handHeldAdd2>`
		`<currentHandHeld>?</currentHandHeld>`
		`<printer>?</printer>`
		`<vehicleCapacity>?</vehicleCapacity>`
		`<TOTB>?</TOTB>`				must be between (inclusive) 0 and 1440
		`<TOTA>?</TOTA>`				must be between (inclusive) 0 and 1440
		`<showOperativeStatus>?</showOperativeStatus>`
		`<showTravelStatus>?</showTravelStatus>`
		`<freezeTheDayLeadTime>?</freezeTheDayLeadTime>`				both FreezeTheDayLeadTime and FreezeTheDayTimeOfDay should be supplied or both should not be supplied. If only one is supplied, either SP_FDLT_NOT_SUPPLIED (586) or SP_FDT_NOT_SUPPLIED (587) will be returned. In a call of EmpUpdateRequest, both can be supplied or neither can be supplied. Also, only one of them can be supplied as long as the other is already set for this operative.
		`<freezeTheDayTimeOfDay>?</freezeTheDayTimeOfDay>`				SP_TIME_INVALID (29) (29) will be returned if the supplied FreezeTheDayTimeOfDay isn’t between 0000 and 2400.
		`<customKWVs>`				The two Keywords that can be supplied in CustomKWVs are HourlyRate and OvertimeRate
			`<keyword>?</keyword>`
			`<value>?</value>`
		`</customKWVs>`
	`</empAttr>`
	`<postings>`					A posting is an association between an operative and a team (TeamID) which represents the fact that the operative is assigned to that team for a period of time between startDate and endDate. By implication, the operative is also assigned to the FRU containing the IRU containing that team for that time period, and so may be allocated jobs that have been booked into that FRU. Postings can’t overlap in time, but there can be gaps between an operative’s postings when he can’t be assigned any jobs or standard activities.
		`<teamID>?</teamID>`
		`<startDate>?</startDate>`
		`<endDate>?</endDate>`				If the end of a posting isn’t specified, then it’s assumed that the operative is posted to that team ‘for ever’.
	`</postings>`
	`<skills>`					An operative may have any number of skills, each for a particular time period.
		`<skillWithLevel>`
			`<skillID>?</skillID>`		`SkillID`
			`<skillLevel>?</skillLevel>`			Each skill has a level associated with it that represents the level of that skill that the operative possesses. The scheduling process makes sure that that an operative is not assigned a job for which he doesn’t have all of the required skills at the required level or above.
		`</skillWithLevel>`
		`<startDate>?</startDate>`
		`<endDate>?</endDate>`				If the end isn’t specified, then the operative has the skill ‘for ever’.
	`</skills>`
	`<shifts>`					A shift pattern is a repeating sequence of time periods when operatives may have jobs automatically allocated.
		`<shiftPatternID>?</shiftPatternID>`
		`<startDate>?</startDate>`				A shift pattern assignment is a period of days (between startDate and endDate) when an operative is ‘working’ a particular shift pattern.
		`<endDate>?</endDate>`				If endDate isn’t specified, then it’s assumed that the operative will work that shift pattern ‘for ever’.
	`</shifts>`
	`<defaultRangeLKs>`
		`<travelTime>?</travelTime>`				TravelTime must be less than 255
		`<LKValue>?</LKValue>`				All supplied values of LKValue must be between 0 & 10
	`</defaultRangeLKs>`
	`<defaultRegionLKs>`
		`<regionID>?</regionID>`
		`<LKValue>?</LKValue>`				the LKValue must be between 0 & 10
	`</defaultRegionLKs>`
	`<pubHols>?</pubHols>`
	`<workPatt>`					This allowsLocalKnowledgeRanges, Local Knowledge Regions, Local Knowledge Centres, Start Locations and End Locations to be supplied as part of a multi-week repeating work pattern.
		`<syncDate>?</syncDate>`				The syncDate parameter is a date on which the corresponding day of the week of the first week of a multi-week Working Pattern should coincide (not the date on which the Working Pattern starts). For example if the Working Pattern is for 4 weeks starting on a Monday, and the SyncDate is 16^th March 2005 ( a Wednesday), the first Wednesday of the Working Pattern should be on 16^th march 2005. The second Wednesday will therefore be on 23^rd March 2005. The previous Sunday (13^th March 2005) will be for the fourth Sunday in the four week Working Pattern since it starts on a Monday.
		`<workPattDay>`
			`<weekNum>?</weekNum>`
			`<day>?</day>`		`DayOfTheWeek`
			`<rangeLKoption>?</rangeLKoption>`
			`<rangeLK>`
				`<travelTime>?</travelTime>`
				`<LKValue>?</LKValue>`
			`</rangeLK>`
			`<regionLKoption>?</regionLKoption>`
			`<regionLK>`
				`<regionID>?</regionID>`
				`<LKValue>?</LKValue>`
			`</regionLK>`
			`<startLoc>`
				`<locType>?</locType>`
				`<postcode>?</postcode>`	`Postcode`
			`</startLoc>`
			`<endLoc>`
				`<locType>?</locType>`
				`<postcode>?</postcode>`	`Postcode`
			`</endLoc>`
			`<LKCLoc>`
				`<locType>?</locType>`
				`<postcode>?</postcode>`	`Postcode`
			`</LKCLoc>`
		`</workPattDay>`
	`</workPatt>`
	`<options>`
		`<AllowShiftsTooClose>?</AllowShiftsTooClose>`				AllowShiftsTooClose overrides the limit on how close shift patterns are allowed to be
	`</options>`
	`<externalData>`					See 15.6
		`<name>?</name>`
		`<SPESDTType>?</ SPESDTType >`
		`<value>?</value>`
	`</externalData>`
`</sp:EmpCreateRequest>`

Browser not supported