Property | Type | Length | Description | Req? |
---|
Id | string
SS: JobID (string)
| SS: 50 | Caller’s identifier of the job to be booked. It must be unique in the ServiceOptimizer database, unless AllowRebook (below) is True SS Field: jobID | Yes |
WorkType | object |
| Property | Type | Length | Description | Req? |
---|
Name | string SS:JobTypeID (string) | SS: 30 | Must be one of the job types (aka task codes) set up in ServiceOptimizer SS Field: jobType | Yes | Skills | array |
| A list of the extra Skills (skill IDs) needed to do this job, in addition to those specified in ServiceOptimizer for this job’s type. If one or more of the supplied ExtraSkills is already required by the JobType, it will be ignored unless it’s the first ExtraSkill and the ExtraSkillLevel (below) is different from that specified for the JobType. The maximum number of skills that can be supplied is 10 however, only the skillLevel for the first skillID in the list has any meaning other skills are assumed to require no specific level.
Property | Type | Length | Description | Req? |
---|
Id | string SS:SkillID | SS: 30 | SS Field: extraSkills.reqSkills[].skillID | Yes | skillLevel | string SS: integer
|
| Level of the skillID required in the skillID field above. If the first of the skillID (above) specifies a skill which is already required by the JobType, then ExtraSkillLevel will replace the skill level required by the JobType for the first of the skillID. If a skill level is not required, the supplied value for this field should be 1. SS Field: extraSkills.reqSkills[].skillLevel | Yes |
| No |
| Yes |
Location | object |
| Property | Type | Length | Description | Req? |
---|
Address | object |
| This represents the customer's address associated with the job. Property | Type | Length | Description | Req? |
---|
AddrLine1 | string SS: CustAddress (string) | SS: 50 | SS Field: customer.custAddress[0] |
| AddrLine2 | string SS: CustAddress (string) | SS: 50 | SS Field: customer/custAddress[1] |
| City | string SS: CustAddress (string) | SS: 50 | SS Field: customer/custAddress[2] |
| PostalCode | string SS: Postcode (string) | SS: 30 SM: 10 | SS Field: postcode | Yes | Region | string SS: CustAddress (string) | SS: 50 | SS Field: customer/custAddress[3] |
| Latitude | string SS: double |
|
SS Field: latitude |
| Longitude | string SS: double |
|
SS Field: longitude |
|
| Yes | LocationNum | string
| SS: 20 | An identifier for the customer for whom this job is booked. SS Field: customer.custID |
| Name | string SS: CustName (string) | SS: 50 | The name of the customer. SS Field: customer.custName |
| SiteId | string SS: SiteID | SS: 20 | Each job can optionally have a Site Identifier. ServiceOptimizer will attempt to schedule jobs with the same SiteIDs: (a) consecutively, so that there’s zero travel time between them, and (b) with the overhead time (from the Job Type and the supplied ExtraOverhead) removed from all but the first of them. ServiceOptimizer treats the SiteID as an opaque value that it uses only to group jobs together. SS Field: siteID |
| Contacts | array |
| Property | Type | Length | Description |
---|
contactName | string SS:ContactName | SS: 50 | The first name of a person who can be contacted about this job. SS Field: customer.contactName | ContactPoint | array of 2 |
| Property | Type | Length | Description |
---|
Mode | string | SS: See Values | Contains 'Phone' for first element in the array. Contains 'Mobile' for second element in the array. | Value | string | SS: 40 | SS Field: customer.phoneNum[0] for first element in the array and customer.phoneNum[1] for second element in the array. |
|
|
|
| Yes |
vwdlLocationType | string SS: EmpLocType | SS: See Valid Values | When set, indicates that the appointment is virtual, with a dynamic location. The dynamic location to be used for the appointment is based on the assigned employee. Currently, only the EmpLocType value of Home is supported. SS Field: vwdlLocationType SS Valid Values: "Home", "Work", "Depot", "Supplied", "None" | No |
RestrictionRef | string SS: RestrictionRef (string) | SS: 30 | Each job may optionally have a restrictionRef . If specified, it must exist in the ServiceOptimizer database. Jobs with a restrictionRef will not show sensitive information for the job on the Gantt, unless the Gantt user has been given permission to view the full jobs details. SS Field: restrictionRef |
|
Flags | object |
| Property | Type | Description |
---|
AllowRebook | Boolean | Jobs of long duration cannot be rebooked – if this field is true, and the JobID already exists and is a long job, then SP_MULTIJOBID_ALREADY_EXISTS (539) will be returned For all other jobs, if this field has the value SP_True, the call to JobBookRequest will not fail if the JobID already exists in the ServiceOptimizer database. Instead, the existing job is deleted and replaced by this one. If AllowRebook is set and the job doesn’t already exist, the JobBookRequest call continues anyway. SS Field: allowRebook |
| No |
ExtraDuraton | string SS: integer |
| Time (in minutes) required to complete the job in addition to what is defined in ServiceOptimizer for this job type. The maximum value which will be accepted for this field plus ExtraOverhead (below) is specified by the SJEDMax database parameter. The maximum total duration for the job is specified by the SJTDMax database parameter. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: extraDuration | No |
ReqProvider | array |
| Allows for a list of up to 10 reqEmps to be specified. Property | Type | Length | Description | Req? |
---|
Id | string
SS: EmpID
| SS: 25 | Names preferred, mandatory or excluded operatives for this job. SS Field: ListReqEmps.empID | Yes | MPX | string | SS: See Valid Values | - Must do the job (i.e. Mandatory, or M);
- Are Preferred (or P) to do the job; or
- Must not do the job (i.e. Excluded, or X).
Accordingly, the Mandatory, Preferred and Excluded options are referred to simply as MPX. SS Field: ListReqEmps.MPX SS Valid Values: "None", "Preferred", "Mandatory","PreferredOrdered", "MandatoryOrdered", "MandatoryNot","MAX"
| Yes |
| No |
ReqUnit | object |
| Property | Type | Length | Description | Req? |
---|
unitType | string SS: UnitType | SS: See Valid Values | If Mandatory, specifies that the job must only be assigned to an employee in the FRU or DRU supplied in the supplied Unit field (below), i.e. the supplied FRU or DRU is mandatory. Values other than Mandatory are not implemented and will cause SP_REQTYPE_INVALID (74) to be returned. The only supported combinations of this and the next two fields are: (1) Mandatory, Final and an FRU ID, or (2) Mandatory, SPUT_D and an DRU ID. SS Field: reqUnit.unitType SS Valid Values: "FRU", "DRU" | Yes | RUID | string SS: RUID (string) | SS: 8 |
SS Field: reqUnit/RUID | Yes |
| No |
Priority | string SS: integer |
| Used to determine the cost of the job being overdue. The ABS and the optimizer will normally cost the lateness of a high priority (SLA) job higher than a low priority job. This should have the effect of making it less likely that a high priority job will be significantly overdue (late). (Lateness is the amount by which a job’s scheduled start time (or finish time in the case of call-to-fix jobs – see callToFix, below)) exceeds its time. Priority the job should have. If priority isn’t being used, it should be set to 50. Must be set between 1 and 99. SS Field: priority | No |
Importance | string SS: integer |
| Used to try and ensure that the jobs left in the in-tray are the less important ones and that the more important jobs are in the schedule. Must take a value between 0 and 9. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: importance | No |
Booking | object |
| Property | Type | Length | Description | Req? |
---|
BookLocID | string SS: BookLocID (string) | SS: 4 | Unique identifier of the location (or service) from which the job is booked. If at a later time, for example when a job becomes earmarked, ServiceOptimizer needs to send out a message, this location is used to look up (in the ServiceOptimizer database) the address of the service it is sent to. SS Field: bookLoc | No | ContractEarliest | string SS: spDateTime (string) | SS: 16 | The earliest time that the job should be started (ETA). If ContractEarliest is not supplied, then ContractEarliest will be defaulted to <now>. Example: "2023-03-30T14:15" SS Field: contractEarliest | No | ContractLatest | string SS: spDateTime (string) | SS: 16 | The time by which the job should either be started (ETA) or completed, depending on the value of callToFix. Example: "2023-03-30T14:15" SS Field: contractLatest | Yes | Offer | object |
| Property | Type | Length | Description |
---|
GroupID | string SS: GroupID (string) | SS: 30 | Jobs with the same groupID should be allocated in the minimum number of contiguous groups that are needed to meet their Access Hours constraints. Like a siteID, a groupID is treated as an opaque value by ServiceOptimizer. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: groupID |
|
| OpenAccHoursOvrs | object |
| A set of open Access Hours overrides for this job. If overlapping open Access Hours override periods are supplied, the overlaps are silently removed – two overlapping open Access Hours overrides will be merged into one, for example. Similarly, overlapping closed Access Hours overrides periods are also merged. Property | Type | Length | Description | Req? |
---|
OpenType | string SS: OpenHoursOvrType | SS: See Valid Values | If OpenType is Add, then the open overrides are added to the existing Access Hours for the job. If OpenType is Replace, the supplied replace open overrides work in a per-calendar-day manner, i.e. the overrides replace the existing Access Hours time periods that start on the same day that the supplied open overrides start on. So, for example, if a job has two existing Access Hours periods starting on a particular day, and there’s only one replace open override starting on that day, then the end result is to only have one Access Hours time period starting on that day SS Field: openAccHoursOvrs.openType SS Valid Values: "Add", "Replace" | Yes | OpenHours | array of objects |
| Property | Type | Length | Description | Req? |
---|
Start | string SS: spDateTime | SS: 16 | Example: "2023-03-30T14:15" SS Field: openAccHoursOvrs.openHours[].start | Yes | End | string SS: spDateTime | SS: 16 | Example: "2023-03-30T14:15" SS Field: openAccHoursOvrs.openHours[].end
| Yes |
| Yes |
| No | ClosedAccHoursOvrs | object |
| A set of closed Access Hours overrides for this job. Closed overrides are converted into open overrides before being stored. Property | Type | Description | Req? |
---|
ClosedHours | object | Property | Type | Length | Description | Req? |
---|
Start | string SS: spDateTime | SS: 16 | Example: "2023-03-30T14:15" SS Field: closedAccHoursOvrs.closedHours[].start | Yes | End | string SS: spDateTime | SS: 16 | Example: "2023-03-30T14:15" SS Field: closedAccHoursOvrs.closedHours[].end | Yes |
| Yes |
| No | ClosedPubHols | object |
| Property | Type | Length | Description | Req? |
---|
PubHolSets | array of strings SS: array of PubHolSetID (string) | SS: 30 | SS Field: closedPubHols | Yes |
| No | ClosedDates | array of objects |
| A set of closed dates (i.e. closed whole days) for this job. ClosedDates applies only to Service Hours, not to Access Hours. Property | Type | Length | Description | Req? |
---|
Start | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: closedDates.dateRange[].start | Yes | End | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: closedDates.dateRange[].end | Yes |
| No |
| Yes |
ServHoursPreDefPatts | object |
| A set of Service Hours patterns that are pre-defined in ServiceOptimizer.ServHoursPreDefPatts can’t be supplied as well as ServHoursPatts (below). Property | Type | Description | Req? |
---|
ServHoursPreDef | array | Property | Type | Description |
---|
DateRange | object | The date ranges can be ‘open-ended’ in the sense that either the StartDate or the EndDate (or both) may be missing, in which case the Service Hours pattern is assumed to continue ‘for ever’ in the corresponding direction. Property | Type | Length | Description | Req? |
---|
Start | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: servHoursPreDefPatts.servHoursPreDef[].dateRange.start | No | End | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: servHoursPreDefPatts.servHoursPreDef[].dateRange.end | No | ServHoursPattID | string SS: ServHoursPattID | SS: 10 | The same ServHoursPattID must be supplied for each, though the accompanying DateRanges can be different. SS Field: servHoursPreDefPatts.servHoursPreDef[].dateRange.servHoursPattID | Yes |
|
|
|
| No |
ServHoursPatts | array |
| A repeating sequence of Service Hours time periods that each apply to a day of the week. ServHoursPatts can’t be supplied as well as ServHoursPreDefPatts (above). Property | Type | Length | Description | Req? |
---|
DateRange | object |
| The date ranges can be ‘open-ended’ in the sense that either the StartDate or the EndDate (or both) may be missing, in which case the Service Hours pattern is assumed to continue ‘forever’ in the corresponding direction.
Property | Type | Length | Description | Req? |
---|
Start | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: servHoursPatts.servHoursPatt[].dateRange.start | No | End | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: servHoursPatts.servHoursPatt[].dateRange.end | No |
|
| DatesAndTimes | object |
| The actual Service Hours (DayAndTimePeriod and GracePeriod ) for each must be the same, though the DateRanges can be different. Each day of the week (DotW ) has a StartTime and an EndTime is a set of Service Hours patterns supplied just for this job. Property | Type | Length | Description | Req? |
---|
Day | string SS: DayOfTheWeek | SS: See Valid Values | SS Field: servHoursPatts.servHoursPatt[].dayAndTimes.day SS Valid Values: "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun" | Yes | Start | string SS: spTime | SS: 15 | Example: "14:15" SS Field: servHoursPatts.servHoursPatt[].dayAndTimes.start | No | End | string SS: spTime | SS: 15 | Example: "14:15" SS Field: servHoursPatts.servHoursPatt[].dayAndTimes.end | No |
| Yes | GracePeriod | string SS: integer |
|
SS Field: servHoursPatts.servHoursPatt[].gracePeriod | Yes |
| No |
AccHoursPatts | array |
| A set of Access Hours patterns for the job. The actual Access Hours for each pattern must be the same, though the DateRange can be different. Property | Type | Description | Req? |
---|
DateRange | object | The date ranges can be ‘open-ended’ in the sense that either the Start or the End (or both) may be missing, in which case the Access Hours pattern is assumed to continue ‘forever’ in the corresponding direction.
Property | Type | Length | Description | Req? |
---|
Start | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: accHoursPatts.accHoursPatt[].dateRange.start | No | End | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: accHoursPatts.accHoursPatt[].dateRange.end | No |
|
| DayAndTimes | object | Property | Type | Length | Description | Req? |
---|
Day | string SS: DayOfTheWeek | SS: See Valid Values | SS Field: accHoursPatts.accHoursPatt[].daysAndTimes.day SS Valid Values: "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun" | No | Start | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: accHoursPatts.accHoursPatt[].daysAndTimes.start | No | End | string SS: spDate | SS: 8 | Example: "2023-03-30" SS Field: accHoursPatts.accHoursPatt[].daysAndTimes.end | No |
| Yes |
| No |
BookOptions | object |
| Property | Type | Description | Req? |
---|
AllowEmpOT | boolean | The employees’ maximum allowed overtime should be included when making appointment offers. SS Field: AllowEmpOT | No | SpareIgnVanStock | boolean | The spareIgnVanStock option indicates to ServiceOptimizer that vehicle stock should be ignored when generating appointments. Any ReqSpares data supplied as part of the offer request will still be read in by ServiceOptimizer, but SP_SPAREID_INVALID (111) will not be returned if any of the supplied ReqSpares is not in the ServiceOptimizer database. If spareIgnVanStock is set then the SpareForceGo (see ForceOptions) flag will be ignored. SS Field: SpareIgnVanStock | No | FixToEmp | boolean | This option will cause the chosen operative to effectively become mandatory. SS Field: FixToEmp | No | ServAsAccHours | boolean | This option makes the job’s access hours pattern the same as its service hours pattern. (If an access hours pattern is also supplied in an AccHoursPatts structure, SP_ACCHOURS_DUPLICATED (390) will be returned.) SS Field: ServAsAccHours | No | CallToFix | boolean | This option specifies that the job’s ETF will be used instead of its ETA to calculate its lateness (using its Service Hours), and will be used as well as its ETA to determine if it’s outside its access hours. SS Field: CallToFix | No | ReqConfirm | boolean | This option will indicate on the Gantt that this job should be confirmed. SS Field: ReqConfirm | No | NonConsecShift | boolean | Allows the use of non-consecutive shifts (as well as allowing contiguous and consecutive shifts) for splitting long duration jobs SS Field: NonConsecShift | No | ConsecShift | boolean | This option requests the use of consecutive shifts (as well as allowing contiguous shifts) for splitting long duration jobs. SS Field: ConsecShift | No | ContigShift | boolean | This option requests the use of only contiguous shift time splits for long duration jobs. SS Field: ContigShift | No |
| No |
ForceOptions | object |
| Force Options are not available for use in conjunction with Long jobs that are to be split across multiple shifts, an attempt to set this will result in SP_FORCEOPTIONS_INVALID (150). Property | Type | Description | Req? |
---|
InTray | boolean | A ‘catch all’ option to by-pass all constraint checking. The job is not even provisionally allocated to an operative, but remains in an in-tray until it is either manually allocated or another attempt is made to allocate it through the ABS. Both of these operations are done from the Gantt. The job will only be put into the in-tray of one of the FRUs that is mapped to the job’s location (region). Exactly which FRU is undefined, but it won’t be put into an FRU with no posted operatives. If a mandatory FRU is supplied, the job will be booked into that FRU. If a mandatory DRU is supplied, the job will be booked into an FRU in that DRU. If one or more mandatory Employees are supplied, but no mandatory FRU or DRU, the job will be booked into an FRU where one of those Employees has a posting (during the memory horizon) to one of the FRUs mapped to the job’s location. If one or more mandatory Employees are supplied as well as a mandatory FRU, the job will be booked into that FRU as long as at least one of those Employees has a posting to that FRU at some time during the memory horizon. If one or more mandatory Employees are supplied as well as a mandatory DRU, the job will be booked into an FRU in that DRU as long as at least one of those Employees has a posting to that FRU at some time during the memory horizon. SS Field: InTray | No | InTrayWithSkill | boolean | Is another option to by-pass constraint checking, though the job will still only be put into the in-tray of one of the FRUs that is mapped to the job’s location (region). However, a skills check is done when placing the job: If there is one FRU containing an employee with the skills to do the job at some time during the SLA Search Window (see 6.6), even if that employee is not available, then the job will be put into that FRU’s in-tray. If there is more than one FRU, the one with the (numerically) lowest preference factor will be chosen. If there is more than one FRU with the same preference factor, one of them will be chosen, but which one chosen is undefined. If one or more mandatory employees are supplied, they will be stored but otherwise ignored. If a mandatory FRU is supplied it will be ignored (and not stored). If a mandatory DRU is supplied, it will be ignored. SS Field: InTrayWithSkill | No | InTrayAfterAll | boolean | First attempts to allocate the job in the normal way. If this isn’t possible, and neither a mandatory DRU nor a mandatory FRU nor mandatory employees are supplied, the job is booked into an FRU where, during the SLA Search Window, there is at least one employee with the skills to do the job (similar to InTrayWithSkills ). The Gantt can then be used to try to allocate it, either manually or through the ABS again. If a mandatory FRU is supplied in ReqUnitType , UnitType and Unit , then the job will be put into that FRU’s in-tray as long as there is an employee in that FRU with the required skills during the SLA Search Window (though he may not be available). If this is not the case, SP_UNIT_INVALID (28) is returned. If a mandatory DRU is supplied, the job will be put into the in-tray of one of the FRUs in that DRU as long as there is an employee in that FRU with the required skills during the SLA Search Window (though he may not be available). If this is not the case, SP_UNIT_INVALID (28) is returned. If one or more mandatory employees are supplied in ReqEmpType and EmpID , a check will be made that one of them has the skills to do the job (at some time during the SLA Search Window), and the job will be put into the in-tray of the FRU where one of those employees is working. If none of them have the skills, SP_EMP_NOT_SKILLED (75) will be returned. If the employee is working in more than one FRU, the job will be put into the in-tray of the FRU with the (numerically) lowest preference factor. If there is more than one FRU with the same preference factor, then which of those is chosen is undefined. If both a mandatory FRU and one or more mandatory employees are supplied, and the employees aren’t posted to the FRU at any time, the job will be put into the in-tray for the mandatory FRU as long as, during the memory horizon, there is at least one employee with the skills. If both a mandatory DRU and one or more mandatory employees are supplied, and the employees aren’t posted to any of the FRUs in that DRU at any time, the job will be put into the in-tray of one of the FRUs in that DRU as long as, during the memory horizon, there is at least one employee with the skills. In all cases, the job will only ever be booked into an FRU that its location (region) is mapped to. Note: The 3 In-Tray ForceOptions (above) are mutually exclusive. SP_OPTION_COMBINATION_INVALID (159) will be returned if more than 1 of them is set. SS Field: InTrayAfterAll | No | SpareForceGo | boolean | Indicates that a job that requires spares should still be allocated even if all of the required spares are not available. This means that if all the spares are available from vehicle stock they may be used, otherwise they need to be sourced externally. SS Field: SpareForceGo | No | Reassign | boolean | Allows existing jobs to be re-assigned among operatives in an attempt to fit this new job into the schedule. Use of this option will increase response times; this may be controlled by means of the database parameters ABS_reassign_jobs_max , ABS_reassign_options_max , and ABS_reassign_timeout . SS Field: Reassign | No | IgnoreCapacity | boolean | When set to true, the capacity for every day should be treated as though it was 100%, i.e. the capacity check values set for each day should be ignored. SS Field: IgnoreCapacity | No | NoTravel | boolean | Sets the travel time (travel-to) to zero. i.e. Jobs with “NoTravel” are skipped in travel calculations. Travel time to next location will be based on previous location. SS Field: NoTravel | No | NoLocalKnowledge | boolean | Ignores local knowledge checks in candidate searches. SS Field: NoLocalKnowledge | No | IgnoreAvailable | boolean | When set to true, jobs can be offered/booked onto operatives who are not available. Jobs booked with ignoreAvailable are not moved by the optimizer until the operative becomes available. SS Field: IgnoreAvailable | No | IgnoreSkills | boolean | When set to true, jobs can be offered/booked onto operatives who lack the required skills for the job. SS Field: IgnoreSkills | No |
| No |
ReqSpares | array |
| Booking APIs can have up to 5 <reqSpare> structures inside the <reqSpares> structure, each of which contains a SpareID and a quantity. Spares substitutes can be supplied by concatenating up to 5 SpareIDs separated by a semicolon character ('; ') Property | Type | Length | Description | Req? |
---|
spare | string SS: SpareID (string) | SS: 30 |
SS Field: reqSpares.reqSpare[].spare | Yes | qty | string SS: integer |
|
SS Field: reqSpares.reqSpare[].quantity | Yes |
| No |
DeliverySize | string SS: integer |
| Amount of space occupied by equipment that will be removed from the operative’s vehicle as part of this job. SP_VEHICLE_CAPACITY_EXCEEDED (662) will be returned if no single vehicle within the FRU has a vehicle capacity large enough. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: deliverySize | No |
PickupSize | string SS: integer |
| Amount of space occupied by equipment that will be loaded onto the operative’s vehicle as part of this job. SP_VEHICLE_CAPACITY_EXCEEDED (662) will be returned if no single vehicle within the FRU has a vehicle capacity large enough. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: pickupSize | No |
CapacityCategory | string SS: CapacityCategoryName | SS: 20 | Capacity constraints, in the form of a reserved or/and limit level can be defined for each capacityCategory and a check can be done in ApptOfferRequest so that only those offers where none of these constraints would be broken are returned. Where this booking is based on offers from a previous call to OfferAppts, the values supplied in this field in this booking request must be the same as those supplied on the OfferAppts call. SS Field: capacityCategory | No |
Desc | array of strings (max 3) | SS: 500 | Free format text describing the job. SS Field: desc | No |
Desc2 | string | SS: 3500 | Free format text about the job that appears in the “More Notes” window on the Gantt. If it conforms to the XML schema gantt.morenotes.xsd, it will appear in a two column table. SS Field: desc2 | No |