Preparing Your Data for Import – New Event Schedules

There are three fields available on the import template which function as ways to uniquely identify each event schedule being created from the template. Only one field is required to import a new event schedule, although additional fields can be completed if desired.

• ID: This field is not required for creating new schedules; new schedules imported into L2L will automatically be assigned an integer value for this identifier by the system.
• External ID: This field is not required for creating new schedules; it can be used to label new schedules being imported with any existing codification for those activities in other external systems (i.e. a preventive maintenance records system). This field will remain empty if the import template for new schedules does not specify a value.
• Description: This field is required for creating new schedules; this field functions as the unique identifier for the subject event schedule(s) being created through the import tool. This information will also appear in the Description of the dispatches launched by the schedule.
• Comments: This field is not required for creating new schedules; it can be used to include additional information describing the activity occurring as part of each event. This information will also appear in the Description of the dispatches launched by the event schedule.

When completing the template, a single event schedule can include multiple rows if multiple pieces of equipment are assigned to the same schedule. It is important in these cases to ensure that each row associated with the same schedule has the exact same information entered in the above fields, if information is entered, to avoid creating multiple schedules.

Example

There are several fields that are used to characterize the subject event schedule’s appearance within the Scheduler module, its applicability to machines (assets), and resources required to complete the work.

• Active: This field is required for creating new schedules; it indicates whether the corresponding schedule is relevant to the associated equipment and should be presently launching dispatches according to the event schedule. This field will likely be TRUE (active) for all new imported event schedules.
• Inactivated: This field is not required for creating new schedules, but can be completed if the event schedule’s corresponding “Active” response is FALSE. It indicates the date the schedule was made inactive. (If your import happens to include currently inactive schedules, this could be revised to match the date of import. While this is not likely, it's good to be aware that this is an option.) 
• Schedule Category Code: This field is not required for creating new schedules; it indicates which Scheduled Event Category the subject schedule should be associated with if used, and will prompt the schedule to appear if the Scheduled Event list is filtered by category type. The information in this field must exactly match the “code” of the desired scheduled event “category” (Scheduler > Categories > Category Detail).

Each event schedule corresponds to a sequence of dispatches that will eventually be launched to drive execution of the target activities. There are several fields on the event schedule import template that specify details about these dispatches.

• Dispatch Type: This field is required for creating new schedules; it indicates what type of dispatch should be launched to drive completion of the work for the scheduled activity. The information in this field must exactly match the “code” of the desired dispatch type (Setup > Dispatch Type > Dispatch Type Detail).
• Trade: This field is required for creating new schedules; it indicates what trade is requested in the launched dispatch to complete the work for the scheduled activity. The information in this field must exactly match the “code” of the desired trade (Setup > Trade > Trade Detail).
• Resource: This field is not required for creating new schedules; it may be used to specify which resource(s) may complete the work on the launched dispatch. These resources are added to the “Assigned Resources” field of the dispatch and included in the dispatch Description. This information must be entered as a comma-delimited list of Usernames only (Setup > Users > Edit Users). Some sites use badge numbers for Usernames rather than first and last names. This is a critical distinction and will save you a great deal of time and headaches. 
• Machine: This field is required for creating new schedules; it indicates which machine (asset) the schedule is applied to. If an event schedule is to be applied to multiple machines, each machine for that schedule will be contained in a separate row in the event schedule template. The information in this field must exactly match the “code” of the desired machine (Setup > Machines > Machine Detail).
• Is Tooling: This field is not required for creating new schedules but must be used if it is to be applied to a tooling asset. This field will be TRUE for any row in the event schedule import template where the subject event schedule must be applied to tooling.
• Tooling: This field is not required for new schedules but must be used if the corresponding “Is Tooling” answer is TRUE; it is used to indicate which tooling asset(s) is associated to the subject event schedule. The information in this field must be entered as a comma-delimited list of tooling codes which must exactly match the “code” of the desired machine (Setup > Tooling > Tooling Detail).
• Estimated Hours: This field is required for creating new schedules; it indicates the estimated time in hours required to complete the work associated with the schedule event. Values for this field should be numeric.

Timing is the most critical aspect of creating a schedule. Therefore, multiple fields are used to dictate when dispatches are created and by when the associated work must be complete. 

• Schedule Type: This field is required for creating new schedules; it indicates how the interval between events created from the schedule will be determined. Possible types are Fixed Interval, where the next event due date is based on a fixed time difference from the previous event due date; Floating Interval, where the next event due date is based on a fixed time difference from the previous event completion date; or a One Time Event. Values for this field should be numeric per the template response key.
• Interval Type: This field is required for new schedules; it designates the basis for event launch frequency by the schedule. Available Interval Types are Days, Hours, Cycles, Weekly, Monthly, Daily, and Yearly. Cycle-based intervals are the only interval type that is not specifically timebound, wherein cycles can represent processing cycles, hours in operation, or any other possibly non-continuous measure. Values for this field should be numeric per the template response key.
• Day: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is MONTHLY or YEARLY. This indicates, for intervals going forward, whether future alternate event due dates should be calculated to match the Day of Week of the initial event, such as the third Thursday, or the Day of Month of the original event, such as the 25^th. Values for this field should be numeric per the template response key.
• Do Event Shadowing: This field is not required for new schedules; it indicates whether the subject event schedule will manage multiple event schedules with overlapping intervals via a single schedule. This field will be TRUE if the subject event schedule is to include event shadowing. (For more information about Event Shadowing, please refer to the article by the same name on this site.) 
• Occurrence Intervals: This field is required for new schedules; it designates the frequency at which events will be launched from the subject schedule. If the subject schedule includes event scheduling, to incorporate multiple event types under one schedule, the frequencies can be listed with each interval evaluated against the minimum interval. Values for this field should be numeric.
• Exclude Weekends: This field is not required for new schedules; it indicates, when the Interval Type is specified as Daily, Hours, or Cycles, to exclude Saturday and Sunday: whether the subject event schedule should launch events on the subject days of the week. This field should be TRUE if Saturday and Sunday should be excluded or FALSE if they should be included. As a note, the weekend days are still counted in the interval period but events will be launched on the next soonest weekday if falling on a weekend day.

The most critical parts of the event schedules are the dates associated to each event and machine. There are three primary dates for each machine on a schedule, as well as two alternate settings that help specify the timing of events from the scheduler.

• Next Launch: This field is required for new schedules; it indicates the future date when the next dispatch, or event, for a particular machine on a schedule should be launched to the Main Dispatch Screen and therefore be available for resources to work on. This field must be completed as a date and time in the future when the event will be created and must be formatted as YYYY-MM-DD HH:MM.
• Note: If you add the launch date in the past, it will immediately launch when loaded. Make sure this is a date and time in the FUTURE. 
• Scheduled Date: This field is required for new schedules; it indicates the future date when the physical work for the dispatch, or event, for a particular machine on a schedule is expected to be worked on by one or more resources. This field must be completed as a date and time in the future when the event will be created, and must be formatted as YYYY-MM-DD HH:MM.
• Due Date: This field is required for new schedules; it indicates the future date when the next dispatch, or event, for a particular machine on a schedule should be launched to the Main Dispatch Screen and therefore be available for resources to work on. This field must be completed as a date and time in the future when the event will be created, and must be formatted as YYYY-MM-DD HH:MM.
• Launchprior: This field is not required for new schedules; it is used as an alternate means from the event date “Next Launch” column to indicate how far in advance of the next due date to launch the event dispatch for schedules using units of Cycles, Hours, or Dates. Values for this field should be numeric and represent the number of units that the event should be launched prior to the event next due date.
• Launchprior Types: This field is not required for new schedules but must be used if the corresponding “Launchprior” field is completed; it indicates what Interval Type, either Cycles, Hours, or Dates, the value in the “Launchprior” field correlates to. Values for this field should be numeric per the template response key.
• Bring Current By Launch: This field is not required for new schedules; it indicates whether the subsequent event should be automatically launched if the preceding event was completed past due and past the due date of the subsequent event, or whether it should not be launched until the next upcoming launch date. This field must be completed as TRUE or FALSE, with TRUE indicating not to automatically launch the subsequent event.

If using the Interval Type of “Daily”, there are several additional pieces on information to complete regarding which days of the week on which to launch events. 

• Sunday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Sunday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Sunday.
• Monday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Monday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Monday.
• Tuesday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Tuesday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Tuesday.
• Wednesday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Wednesday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Wednesday.
• Thursday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Thursday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Thursday.
• Friday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Friday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Friday.
• Saturday: This field is not required for new schedules but must be used if the corresponding “Interval Type” answer is DAILY; it indicates whether dispatches for the corresponding event schedule will be launched every Friday. This field must be completed as TRUE or FALSE, with TRUE indicating a launch every Friday.

Historical information for a previous event executed on the subject machine(s) of a schedule being created can be included at the time of the event creation through completion of up to four additional fields on the event schedule import template: 

• Machine Last Launched: This field is not required for new schedules; it indicates historically the last date an event for the subject machine requiring the subject work was launched. This field must be formatted as YYYY-MM-DD HH:MM.
• Machine Last Completed: This field is not required for new schedules; it indicates historically the last date an event for the subject machine requiring the subject work was completed. This field must be formatted as YYYY-MM-DD HH:MM.
• Machine Last Cycle Completed: This field is required for new schedules; it indicates historically the number of cycles completed by the machine at the time the import is used to create the associated event schedule. This field must be entered as a numeric value with 0 equating to none or unknown.
• Machine Occurrence Count: This field is required for new Cycle Based Schedules; it indicates, for cycle-based schedules, the number of historical events executed against the subject machine. This field must be entered as a numeric value with 0 equating to none and a value 1 being required for the initial cycle-based schedule; any number greater than 1 entered into the field will be multiplied by the Occurrence Interval to calculate the next due cycle.

Work activities for scheduled events often require adherence to and completion of associated documentation. Several fields on the event schedule import template may be completed to connect documentation to a particular schedule or occurrence interval of a schedule.

• Document Link: This field is not required for new schedules; it indicates the URL at which a document within L2L for an event schedule or occurrence interval on a schedule can be found.
• Document Category Code: This field is not required for new schedules; it indicates the document category assigned to the associated document specified by the “Document Link” field within L2L. The information in this field must exactly match the “code” of the corresponding document category (Standard Work/Documents > Categories > Document Category Detail).
• Document External ID: This field is required for new schedules; it indicates the External ID associated with the document within L2L for an event schedule or occurrence interval on a schedule. The information in this field must exactly match the External ID of the corresponding document (Standard Work/Documents > All Documents > Document Detail).

Suspending a schedule is used to temporarily prevent a schedule from launching events against one or more machines assigned to that schedule. An example use case would be if one or more pieces of equipment were temporarily out of service. Once the cause of the suspension has concluded, the schedule can be resumed per machine assigned or for all assigned machines.

• Suspended: This field is required for creating new schedules; it indicates whether the corresponding schedule is currently suspended. This field will likely be FALSE (not suspended) for all new imported event schedules.
• Suspended On: This field is not required for new schedules but must be completed if the “Suspended” field response is TRUE; it indicates the date and time at which the schedule was suspended. This field must be formatted as YYYY-MM-DD HH:MM.
• Suspended By: This field is not required for creating new schedules; it may be used to specify who suspended the schedule if the corresponding “Suspended” field is TRUE. This information must be entered as a comma-delimited list of usernames only (Setup > Users > Edit Users).
• Machine Suspended: This field is required for new schedules; it indicates whether for a specific machine on a schedule, if the schedule applies to more than one machine, launching of new events is currently suspended. This field will likely be FALSE (not suspended) for all new imported event schedules.
• Machine Suspended On: This field is not required for new schedules but must be completed is the “Suspended” field is TRUE; it indicates the date and time at which the event schedule for the specific machine on a schedule was suspended This field must be formatted as YYYY-MM-DD HH:MM.