As some changes can move operative day boundaries (ODBs), there are occasions when jobs would end up spanning ODBs. Where this happens (the most likely case is after changes to shift assignments) those jobs will be de-allocated.

After each sp:EmpUpdateRequest API call, the operative’s jobs are always shuffled. This will have most effect after changes to shift assignments, start & end locations, travel in own time, and efficiency. However, jobs may be shuffled in all other cases because of pre-existing conditions.  For example, if a job has been moved (but not fixed) on the Gantt and remove overlaps was switched off, the shuffling operation after an sp:EmpUpdateRequest API call may shuffle it to close up a gap in the schedule.

If an employee with a van spares allocation is posted to a different or new FRU, the van spares allocation does not take effect in real time. Jobs requiring van spares will not be booked to this employee until the FRU is restarted. The sp:EmpUpdateRequest call will succeed but will return SP_OK_VAN_SPARES_NOT_UPDATED (646).

It is not necessary for the FRU(s) involved in the update to be active (i.e. running). However, if an FRU is not active then some sp:EmpUpdateRequest API functionality is unavailable:

• schedule checks cannot be made in an FRU that is not active (for example, SP_POSTING_WOULD_DEALLOC (247) will not be returned); and
• schedule operations cannot be made in an FRU that is not active (for example, the schedule will not be relaid out to accommodate a shift assignment change - see note above).