Standing Data
Contents
Standing Data
Standing data is permanent reference data that is used by the system to determine operation and behaviour of various aspects of the software. It provides known reference and control over user selections and choices, ensuring consistent data entry. Initial planning and then entry of standing data during the initial stages can improve system efficiency.
Generally speaking most standing data will commonly use a code and description field, as well as some other more specific fields relating to individual functions.
The code field is a short unique identifier; it is ‘free text’ meaning you can enter any valid characters into it. The code is used to reference the item in the system.
The description is also ‘free text’ and is much longer, this is where the actual text is defined, and what is commonly displayed by the system when the data is used.
For example in work order types;
Code Description
BREAK Breakdown repair.
Standing data and system configuration are system administrative functions and part of the administration menu option which is only available through a user account with the administrative menu group.
Before the Agility system can be used to create Equipment and Work orders, it is necessary to define the System Standing Data.
System
Calendars
Different calendar scenarios can be set up detailing, for example, monthly, quarterly or yearly calendars. The calendar is required when completing Work Orders where there elements of costing information (i.e. Labour Hours / Rates, Materials, Other Costs). A calendar is made up of periods that detail an end date and optionally working days and hours. It is advisable to have only one calendar in the system and to add new periods when required. If a calendar period does not exist when completing Work Orders with attached costs then completion cannot take place.
Accessed from Standing Data >> System >> Calendars
Periods
Click on the magnifying glass icon to the left of an existing definition to view the calendar detail this will provide a scan view of all the periods configured against the selected calendar.
To create a new period within the existing calendar, click change on the screen above.
Then choose add.
Period End Date
Select from Calendar option can be chosen
Description
This is a free text field used to describe the period.
Year Number
The Year for which the calendar is valid
Period Number
This depends on how the year is to be split and indicates the order of the period within the year.
For example;
If the year 2010 was split quarterly typical entries would be;
Period End Date
1 31/03/2010
2 30/06/2010
3 30/09/2010
4 31/12/2010
It is also possible to indicate the hours of work for each day in the week during the defined period. This information is used when calculating, in conjunction with Priority Codes, the due date of a work order.
''''Calendar exceptions
Each calendar can have a number of exceptions defined for which different working hours can be specified. When such a calendar is linked with the priority record, the exceptions information will be taken into account when the Work order due date is calculated by the system according to the selected priority.
To add a new exception to the calendar, click new row button in the Exceptions grid whilst in period change mode:
Then click the view icon;
Enter the date for the day you want to exclude.
A start and end time can also be specified for the excluded day.
A description field is also available which can be used to store details about the exception, for example ‘Public Holiday’.
If the start and end time values are left as null, the system will interpret them in the following way;
Not Available from: will be recognised as 00:00
Not Available to: will be recognised as 23:59
Mail Logs
Standing Data >> System >> Mail Logs
When the agility system sends a mail notification for the following items it is recorded in the mail log.
- Work Orders
- Purchase Orders
- Notifications
The mail is recorded whether the mail is sent successfully or not. The email log can be accessed and viewed using the mail log scan form.
Then each individual mail detail can be examined by clicking the detail icon within the grid.
Field Definitions;
Subject
The mail subject
Created
The date the email was created
Body
The body content of the email message
Status
Resultant status of the message
Sender
The user within agility that sent the message
Recipient, CCRecipient, BCCRecipient
The email address of the recipients of the mail
Result Log
Details about message delivery whether the message was sent successfully or not.
Mail Log Retention
The log retention period is determined by a system parameter located under the FastNet parameters called ‘DaysToStoreEmailsLog’. This needs to be populated with an integer value in days.
See system parameters in the system configuring chapter for more information on system parameters.
Checklists
Standing Data >> System >> Checklists
Checklists are a means of capturing specific controlled data. They are used on work orders both with agility and on mobile applications. They provide a method of presenting the user with a series of pre-defined questions or checklist items which the user completes as part of the work flow. For example these could be used to record that certain safety procedures had been carried out on a specific task or to capture data on visual inspections or equipment checks that are not defined meter readings. For more information on implementation and usage please refer to the ‘Job Types’ and ‘Work Orders’ topics.
Checklists can be attached to work order types, which automatically attach associated checklists to the work order. Or alternatively checklists can be added to the work order directly from within the ‘checklists tab’ on the work order detail form. One, more or no checklists can be attached to a work order.
The check lists available for selection to work orders and work order types are pre-defined as standing data.
Each check lists is made up from a header definition which describes and identifies the checklist and items.
Checklist Header
When ‘checklists’ is initially opened the user is presented with a scan form listing all the currently defined list header information.
[[image:|602x88px]]
The header fields are defined as follows;
Code
This is a unique code to identify this checklist. It is a free text field but the code entered must be unique.
Description
Long free text description field providing a detailed description of the item.
Type
This is a category for identifying the type of checklist, i.e. ‘Inspection’, ‘H & S Checks’. It is currently a free text value.
Mandatory
A yes/no field to determine if the checklist must be completed by the user before the work order can be completed.
Last Changed By
The last date that the checklist was changed, if now changes have been made this will be the creation date of the list
Changed By
The user login under which the list was changed or created if no subsequent changes have been made
From this for a new list can be created by clicking the ‘Add New’ option on the menu bar or an existing list can be viewed / edited by clicking the drill down icon on the required list.
Both options will open the list detail form. A blank form will be presented in the event that ‘add’ is selected.
[[image:|602x208px]]
Above: Checklist form in detail mode.
The detail form shows the header values as shown in the scan plus some additional header information relating to the operational rules.
Complete before job status
This is the highest status within Agility which a work order with this checklist attached can reach before the checklist must be completed. The values are taken from standard work order status values.
Complete before job status (PDA)
This is the highest status on the mobile device which a work order with this checklist attached can reach before the checklist must be completed. The values are taken from standard work order status values.
Deploy to Mobile Device
If the checklist is to be sent to the mobile device with the work order this option must be enabled.
Checksum Error Message
This is the error message that will be displayed on the form if the checklist responses do not meet any specified checksum criteria. These are explained in list items below.
''''Checklist Items
A checklist can be made up of one or more items. Each of the items can be defined as a ‘checkbox’, a pre-defined drop down list of options or a text box which can be formatted in several ways which are detailed below. Any one or more of the checklists can be made mandatory which means this item has to be completed, filled in, before the checklist can be marked as complete. In addition to the mandatory condition certain types of item can be configured with a checksum value. This value enables checking that items using numeric values are filled in with values in a desired range.
The items on a list are initially displayed in the scan form on each list.
The list item can be added, edited or viewed in the scan or in detail mode by click in the detail icon on each item.
List Items Fields;
Line
This is a line number used to order the items on the list. When creating new lines this is automatically populated but can be overridden.
Label
This is the actual text or prompt of the checklist item, or the question. For example, ‘Was the power supply disconnected?’ It is a free long text value and is what will be presented on the checklist that is attached to the work order.
Control Type
The control type denotes the type of control that is presented to the user.
Check Box
A check box that is used to indicate a logical condition i.e. yes / no or true / false
Combo Box
This provides a drop down list that the user can select predefined answers from. This should be used where consistent data, especially if used for later analysis and reporting, needs to be recorded. For example where the condition of an item needs to be captured a list with the options, ‘Poor’, ’Fair’, ’Good’ and ’Excellent’ could be used. This eliminates potential variations in the captured data.
When the combo box option is selected an additional value is made available in detail mode in which to create the list of items.
[[image:|602x55px]]
Each item in the combo box list is defined as a pair, comprising of a code and a description. The description is displayed in the drop down list. The code is used as an identifier and is also the value written to the attached work order checklist. The list is built up from pairs that are comma separated.
For example:
Poor - Replace,Poor,Fair - Consider Replacing,Fair,Good - No Action Req'd,Good
No text qualifier is required.
Text Box
This provides a text box that the user can freely enter data into. The text box can however be formatted in a specific way to control the type of data that is captured. When text box is selected a new value is made available in detail mode to select the format.
[[image:|532x126px]]
String
String values are general purpose free text fields where the user can enter any characters. This could be used to capture a free text description. I.e. ‘The terminals are corroded”. When string is selected additional values are displayed on the detail form optionally allowing a minimum and maximum number of characters to be specified for the text value.
Int
Integer values. These are used for entering whole numbers. I.e. 1
Decimal
These values are used for enter numbers that have a decimal value. I.e. 1.11
Currency
This formats the text box for entry of monetary values
Interval
This formats the text box allowing entry of a time measurement in minutes.
Date*
Formats the text box for date entry
DateTime*
Formats the text box for entry of a date and a time
*Note both date and date time types will present a calendar selector on the value.
Mandatory
This flag denotes if the list item must be completed. A checklist attached to a work order will only reach a status of completed if all mandatory fields on the checklist have been completed.
Checksum Control
The checksum function provides a way of validating where items are counted into categories do equal an entered total value.
The checksum works by taking the sum of all the values marked as checksum element and subtracting from this all value that are marked as checksum total. If the result is zero then the checksum will pass.
The following statement has to be true where for the checksum not to fail.
Attachements
This field is designed to attach images for each result row.
So if a checklist had 2 checksum elements and 1 checksum total. Then the statement would be;
Or as shown in the below example;
The number of power connectors used plus the number of power connectors unused minus the total number of power connectors must equal 0. If the checksum does not equal zero then one of the values must be in error.
[[image:|602x99px]]
Only certain text boxes with numeric formatting can be assigned a checksum control. These are Int, Decimal, Currency and Interval. When a text box with this type of formatting is selected an additional value appears in the detail form allowing a checksum control type to be selected. There are three options available.
No Checksum
This means that the value is not included in the checksum calculation.
Checksum Element
Denotes the value as a check sum element
Checksum Total
Denotes the value as a checksum total
If values are entered into a list that is using checksum values, if the checksum does not equal zero a checksum error will be displayed and the user will not be able to continue processing of the checklist form until the checksum is resolved.
Equipment
Equipment is where standing data relating to plant and asset is defined within the system. It is also where specific run time conditions, meter types and which equipment has reading points is also defined.
Contract Groups
This file contains organisational “Groups” into which equipment can be placed. They can then be used when creating “Contracts” to quickly add a number of Assets at one go, when a work order is raised against any equipment that is part of a contract group then the contract is then identified on the Work Order.
Accessed from Standing Data >>Equipment >> Contract Groups
To create a contact group enter an identity code (short name) and then a description (the name you want to give to the group)
Contract groups can also be used as organisational units to organise like items of equipment together, for example ‘Air Conditioning Units’ these can provide a means of selecting items for reporting and analysis.
Meter Types
This is where different meter types are defined which are used by equipment reading points. Meters type can be defined to represent different types of indicator, e.g. temperature gauges, milometer, voltmeter, ammeter, counters etc.
This area is where the different types of meters you use are defined; it is not used for specifying the location of individual devices. These are set up in equipment reading points.
Accessed from Standing Data >>Equipment >> Meter Types
The scan forms shows all the meter types that have already been configured to add a new meter click on the ‘add new’ button on the menu.
Code
This is a unique code to identify this Meter Type. It is a free text field but the code entered must be unique.
Unit of Measure
Here is specified the unit of measure for the indicator, e.g. miles, degrees centigrade, rpm, volts, amps. The unit of measure used does have to be defined in the system under units of measure. This field does support type ahead. Units of measure are configured under inventory standing data.
Description
Free text description of the Meter Type.
Meter Type
The meter type value indicates the type of value being recorded and is used in the generation of runtime based PPM work orders.
Runtime types
This type is used where the meter has constantly increasing or decreasing readings for example a milometer or a number of copies produced on a photo copier. This is used to assist with generation of scheduled predictive runtime maintenance using runtime projection methods.
Condition type
This is where the meter does operate by consistently increasing or decreasing and scheduled maintenance needs to occur when the meter reaches certain reading. For example a temperature or pressure gauge or volt meter.
Direction
This is only applicable to run time meter types. This indicates if the direction of the meter, whether it increases or decreases. By default all runtime meters are set to increase.
Examples;
A photocopier where the unit needs to be serviced each 10,000 copies would be an increasing type.
A machine where a component has a limited number of uses and once the uses reaches or approaches zero it needs to be replaced would be a decreasing type.
Reading Points
Reading points are where equipment items are defined as having a reading point or meter. This reading point is then used to allow recording of date and time stamped readings against the equipment item.
(Additional information on reading points; Standing Data - Meters, Equipment – Equipment Reading points)
The reading points scan grid returns a list of all equipment items that have associated reading points. Viewing the detail form for a reading point shows the details of the reading point and two additional tabs, one showing a history of recorded readings the other showing any associated run time control records.
A new reading point can be added by clicking the ‘add reading point’ option. The following data is stored for a reading point.
Asset
Equipment, the Reading Point is being defined against.
Meter Type
Select the meter type from the list of defined Meter Types (see Standing Data: Equipment -> Meter Types for more information about Meter Types)
Description
Free text description of the Reading Point
Roll Over
This is the maximum value of counter (minimum in the case of a decrementing meter type). This value is optional.
Total
This is the total value reading point. This value should be entered at the creation of a reading point. By default Total Value will be initiated with "0".
Control Records (Run time PPM)
Each reading point can have associated control records. This is accessed from the control record tab on the reading point details form.
The control record contains all attributes for the generation of PPM jobs based upon usage and is used as the reference point for generation. It also contains a log of jobs generated as well as a log of usage.
Multiple control records can be held against each reading point allowing the generation of PPM jobs on different cycles.
The form also contains functionality allowing a reading point to be changed whilst maintain the run time history.
Reading Point Box
Equipment Code
The equipment code of the equipment the reading point is associated with
Meter Type
The type of meter, (see Standing Data: Equipment -> Meter Types for more information about Meter Types)
Reading point
This is the name of the reading point.
Unit of measure
This is the unit of measure for the meter, taken from the meter definition.
Description Box
Comments
Free text field for adding additional information about the reading point.
Active
Check box determining if this particular control record is active. If the control record is not active then PPM’s will not be generated from this control record.
Usage Based Box
Last Trigger Date
Last Date/time at which a PPM was generated from this control record
Next Trigger Date
Next Date/time at which a PPM will be generated based upon usage.
Life Time
This figure represents the overall life time of the equipment to which this reading point has been associated.
For example;
Using a car and gearbox scenario;
If we have 2 cars, one has done 20000 miles and the other 30000 miles. We also have a brand new gear box. We fit the gear box to one car and do 10,000 miles in the car, the gear box is then swapped to the other car. The car containing the gearbox has done 30000 miles but the life time reading of the gear box would still only be 10000. So the PPM to service the gearbox would still be based upon the gear box usage and not the car containing it.
Last trigger value
This is the value at which the last PPM job was triggered
Next Trigger value
This is the value at which the next PPM job will be generated
Interval
This is the factor that determines when a job is triggered. The figure represents the cycle in the unit of measure at which to generate a job.
So for example if we have an interval of 100, every time the usage reaches or exceeds intervals of 100 a job will be generated.
Forecast Daily Average
This figure represents a calculated average value of the amount of usage for each day.
Forecast Average Days Cycle
This figure represents the value in number of days, based upon usage, at which the interval will be hit and a job triggered.
For example if the interval was set to 100 and usage was 100 per day then this value would be 1.
Change Reading Point
The change reading box allows a reading point to be changed for a different one but still maintain the run time history for the equipment item to which the reading point has been associated.
Equipment Code
The equipment code to which the reading point is to be associated
New Reading Point
The new reading point to be associated with the equipment item
Last Reading of Current Reading Point
This is the last reading taken of the existing reading point prior to it being removed from the equipment item.
Current Reading of New Reading point
This is the reading of the new reading point taken when the item was attached to the equipment item but prior to any usage.
Change Date
This is the date at which the change took place so that new readings are taken from this date onwards.
To change the reading point click the ‘Change Reading Point’ Option in the toolbar, following details being entered.
Two logs are maintained at the bottom of the form, and these are displayed as grids.
Usage
The usage grid shows usage by show the period between the pervious and current reading point and the reading value.
From Date
This is the will be the date the last reading was taken. (or the previous ‘to date’)
To Date
This is the date the reading was taken and forms the ‘from date’ of the next reading.
Usage Value
This is the meter reading that was entered on the ‘To Date’ and represents the usage for the period ‘From Date > ‘To date’
Meter Point
The name of the reading point
Logs
This displays a time and date stamped activity log of this particular control record in reference to the PPM. Showing when the PPM was triggered, when run time values were re-calculated and changes to the control record.
Asset Statuses
Accessed from Standing Data >>Equipment >> Asset Status
Asset Statuses are used to identify the current status of an asset. Asset status can be set manually or set by a work order.
Manually;
In first case a user sets the status during the asset creation process, initially this could easily be ‘In Use’ or ‘Active’
By work order;
The status of the asset can be updated if a work order is generated against it, i.e. if a repair work order is generated then the asset should be at a status of ‘under repair’.
The status of the asset can be updated automatically using rules that are defined within asset status translations, covered in the next topic.
For example if an asset status translation rule is found for where the work order job type is ‘repair’ and the work order job status is ‘open’, if a new ‘repair’ type work order is created against an asset then the status of the asset will be automatically updated to whatever is defined in the translation, which could be ‘needs repair’.
In order to create an asset status a code and description are required, the icon and escalation level are optional.
Code Unique short identifying code
Description Text which will be displayed for this status (i.e. ‘Under Repair’)
Asset Status Translations
Accessed from Standing Data >>Equipment >> Asset Status Translations
Asset Status Translations table provides certain defined transitions between type and status of work order and asset status.
Work Orders
Various elements of standing data are required for the generation of work orders. This is a core element of the system and intuitive planning and design in the creation and structure of these standing data elements can provide better analysis, reporting and easier operation.
Work Order Type Codes
Accessed from Standing Data >>Work Orders >> Work Order Type Codes
This standing data file provides a standard classification for all the different types of work that can be undertaken providing a method of organising work orders, filtering options as well as providing several aspects of analysis and driving reports and KPI’s.
For example, breakdown, maintenance, scheduled move etc.
Each work order that is generated in the system requires a work order type.
A basic set of work order types should be configured during initial set up, to which more can be added over time as need dictates. Existing descriptions can also be changed although you should note that changing the description here will change the description on every work order and report where that description has been used.
To add a new work order type, click the ‘add new’ button.
Code
This is a unique code to identify this Work Order Type. The field is free text.
Description
This is a free text field to describe the Work Order Type.
Breakdown
Check the box to indicate that a work order with this Work Order Type will be treated as a breakdown. If this is the case, then downtime will be accumulated to the equipment item on Work orders of this Work Order Type.
Is Repair
The repair flag is used only when Repairable Spares module is utilised. When checked, special flow for repair process will be enforced on the work order.
Print Format
This field has been included for future use and is not currently utilised.
Typical Work Order Types might be;
|
Code |
Description |
|
PPM |
Planned Preventative Maintenance |
|
BREAK |
Breakdown Repair (urgent) |
|
REPAIR |
Repair |
|
RFW |
Request for Work (user requested work) |
Icon
This will assign an Icon to the Work Order Type. If there is an icon assigned to the Work Order type record, it will be used on the Scheduler screen for graphical representation of the Job Type.
Checklists
Checklists are a means of capturing specific controlled data. Multiple check lists can be added to a work order type. The adding of checklists is optional. Checklists are pre-defined within standing data. For more information on defining checklists please refer to the Checklists topic in the Standing Data Chapter. Any checklists that are added to a work order type will be automatically attached to any work that is raised using that work order type.
Checklists can be added when creating a new work order type or added to existing work order types using the change function. To add a checklist, click the ‘New Row’ button on the checklist grid on the detail form of the work order type.
[[image:|602x162px]]
This will create a new row in the grid, from the drop down list of available pre-defined checklists, select the required item. Repeat this process until all required checklists have been added.
[[image:|396x158px]]
To remove a checklist from a work order type, click the delete icon adjacent to the required checklist.
Work Order Status Codes
Accessed from Standing Data >> Work Orders >> Work Order Status Codes
Work Order Statuses are used to identify the current status of a Work order. The same list of statuses is also used to record the current status of individual tasks within a work order.
The work order status can also be used in conjunction with a job status to create an asset translation status, which can automatically update the status of an asset; this is covered in the ‘Asset Status’ and ‘Asset Status Translations’ topics.
Click on Add New to create a new Work Order Status;
Code
This is a unique code to identify this Status Code. The field is free text.
Description
This is a free text field to describe the Status.
Typical Statuses might be:
|
Code |
Description |
|
CANCEL |
Cancelled |
|
COMP |
Completed |
|
OPEN |
Open |
|
RFW |
Request for work |
Escalation level
It is used to decide which schedule task status should be assigned to task status and which task status will be assigned to work order status.
Status Type
The status type field is used to indicate whether the given status is available when the new Work Order is created or whether it can only be assigned from other W/O status according to the ‘Follow-on status’ flow.
'Email Settings Tab
The email settings tab contains all the configuration options required for setting up an email alert to be sent when the Work Order enters the specified status. In order for this to be used the email notification setting must be activated in the system parameters.
E-Mail Notification
This field should be checked if emails are to be generated when work orders are set to this status.
The email recipient addresses are determined from the email address stored against the corresponding record in the system.
- Equipment
- This will use the email address from the email tab on an equipment records
- Work Order
- This will use the email address from the email tab on a work order which is located under the advanced tab
- Site
- Caller
- This is the email address contained within a helpdesk request
E-Mail Subject
This is the subject heading of the e-mail notification. This can be simply fixed text or more usefully can be made up of text and a merged field from the work order for example the work order number;
"A new WO Request..."+woJob.JobCode
''''E-Mail Body
This is the body text of the e-mail notification. The message is usually comprises of a number of text items combined with merged data from the work order record.
"<html>
<head>
</head>
<body>
<h2 align=center style='text-align:center'>New Job Information</h2>
New job with code " + woJob.JobCode + " has been opened. <br>
<a href ='"+FormURL("AGWODetwoJob",#DocumentID) + "'> Click this link to see the details.</a>
</body>
</html>"
Follow-on Statuses
Once the status code has been set up, follow-on statuses can be added.
Follow-on codes are used to specify the statuses that must follow the status being defined.
In the example below; if the work order has a status of open, the option in the drop down box on change of status on the work order will show Cancelled and Completed.
This allows a controlled work flow to be implemented.
Priority Codes
Accessed from >> Standing Data >> Work Orders >> Priority Codes
This standing data file is used for defining the priorities which will be allocated to a work order. The details of the Priority are the used by the system when calculating the Due Dates of Work Orders, as well as facilitating ‘grace’ time.
Creating a new priority code
Code
This is a unique code to identify this Priority Code. The field is free text.
Description
This is a free text field to describe the priority.
Due Time
The due time will be used in calculating the Due Date and Time on the work order. The due date and time is calculated by adding the specified time onto the start date and time specified on the work order.
The due time is specified hours and minutes.
It is also possible to enter the due time in months by checking the ‘Enter Due Time in months’ box.
Grace Period
The Grace Period is used when reporting on overdue work orders. The grace period, if specified, does not affect the due date of a work order.
An example of grace period usage;
A work order is raised on January 10th with a priority of 1 Month. This would give a calculated due date of February 10th. The Priority of 1 Month has a Grace Period of 2 days. If the Work Order remained “uncompleted” it would not be classed as Overdue until February 13th.
By default the Grace Period can be added in hours and minutes.
Calendar
Calculation of the job due date can be done on the basis of a 24/7 working week or based on a specific calendar. When the calendar is filled in on the priority record, this will be used in the due date calculation, which will take into account calendar working hours for each day of the week (see Calendars for details) and calendar exceptions, which can include company-specific holidays.
An example of Calendar usage could be:-
A Priority code has a due time of 6 hours and uses a Calendar that indicates working hours are 09.00 to 17.00, 5 days a week (Mon – Fri).
If a Work Order is raised at 14.00 on Monday with the 6 hour priority code it would be unacceptable to calculate the Due Date & Time as 20.00 on the same day as the maintenance operation stops at 17.00.
By using the Calendar function the due date on the Work Order would actually be calculated as 12.00 on Tuesday (i.e. 3 hours from 14.00 on Monday & 3 hours from 09.00 on Tuesday).
Manual Entry of Start/Due dates
If this option is checked the start date and due date can be manually overridden on the work order by the user.
Advanced KPI Parameters
The KPI parameters are used to enable the monitoring of response times using work order scan forms of defined KPI charts.
The parameters allow a threshold time in minutes to be specified which can be used to make the system display a warning, on a scan form or chart; that for example the deadline due date and time is approaching. The system work order scans “Completion Target RAG Scan” and “Response Target RAG scan” show this. The column sort on these grids also allows the grid to be ordered so that all tasks showing concern appear at the top.
Three thresholds can be specified;
[[image:|602x88px]]
Response Target
This is the number of minutes within which the work order has to be responded to. This figure is used to calculate the ‘Response Target Date’ on a work order based upon the following calculation.
Response Threshold
This is a number of minutes prior to the where you would want to be warned that the target is approaching. This figure is used to calculate the ‘Response Warning Date’ on a work order based upon the following calculation.
Completion Threshold
This is a number of time in minutes prior to the work order due date/time when you would want to be warned that the work order is approaching the due date/time. This figure is used to calculate the ‘Completion Warning Date’ on a work order based upon the following calculation.
Task Type Codes
Accessed from Standing Data >> Work Orders >> Task Type Codes
A work order is constructed from one or more tasks. A Work Order has to have at least one task and this standing data file provides a standard classification for all the different types of work that can be undertaken against the task and allocates a unique code to each.
This code is used to;
Analyse the amount of Work in each category that has been performed on an item of equipment.
A Task Type differs from Work order Types, as the nature of jobs performed at Task will not necessarily be the same.
Code
This is a unique code to identify this Task Type. The field is free text.
Description
This is a free text field to describe the task type
Icon
Allows an icon to be associated with the task type
Typical Task Types might be:
|
Code |
Description |
|
REPAIR |
Repair |
|
SERV |
Service |
Fault Groups
Accessed from Standing Data >> Work Orders >> Fault Groups
Fault Groups, and their subdivisions Fault Codes are a method of analysing the reasons for Equipment Breakdowns.
Faults Groups are used to group together Fault Codes of a particular type (i.e. Electrical, Mechanical, Operator Error etc)
Fault analysis is facilitated by the setting up a structure of fault groups with underlying fault codes and associated fault types.
There should be a record for each of type of fault commonly encountered, with a unique code for each symptom, fault, and cause or fix method. This formalises the reporting of these faults and allows for subsequent analysis of fault frequency and fault distribution.
A fault group is simply made up from an identifying code and description under which then individual fault codes are added.
For example a typical fault group may be ‘electrical’, under which fault codes such as ‘blown fuse’, ‘broken lead’ or ‘loose wire’ for example could be added.
Code
This is a unique code reference for the Fault Group.
Description
This is used to describe the Fault Group.
Fault Codes
Accessed from Standing Data >> Work Orders >> Fault Codes
Fault codes are used to provide a more detailed description of a fault. They are assigned to a fault group for organisational and reporting and analysis purposes.
A fault code can also be allocated a type e.g. a ‘symptom’, a ‘fault’, a ‘cause’ or just a ‘general’ code.
A dictionary list, which can be added to, is used for these types which will help to maintain consistency for reporting purposes.
Fault Group
This is the Fault Group to which the new Fault Code will belong. This is a drop-down list populated from the Fault Groups added in standing data. The Fault Group is a mandatory field and must be selected from the drop-down list.
Code
This is a unique code reference for the Fault. This is also a mandatory field and must be typed in.
Description
This is a free text field used to describe the Fault.
Type
Choose from the drop-down list to define the type of fault: cause, symptom or general.
Fault Code Structure
Accessed from Standing Data >> Work Orders >> Fault Code Structure
This tree view provides a hierarchical structure view of the fault groups with underlying fault codes and the fault types with underlying fault code instances where the type is used.
This aids easy location of items when maintaining fault codes in the system
Labour
Labour is where all the aspects of labour resources are defined for use with work orders.
Each labour resource in the system requires a craft, a rate and a shift pattern in order to determine which labour resources can be allocated to ‘what’ and ‘when’ and how much it will cost. Crafts and shift patterns have to be defined before they can be added to labour resources.
Craft Codes
Accessed from Standing Data >>Labour >> Craft Codes
A craft code record is a method of defining a particular resource skill within the system.
Click on Add New to create a new Craft Code.
Code
This is a unique code reference for the craft.
Description
This is used to describe the actual craft or skill.
Typical Craft Codes might include:
|
Code |
Description |
|
Elec |
Electrical Engineer |
|
Mech |
Mechanical Engineer |
|
AC |
AC Service Engineer |
|
Gas |
Gas Engineer |
Labour Rates
Accessed from Standing Data >> Labour >> Labour Rates
This file is used to store current and future hourly labour cost rates for all classes of labour relevant to Maintenance. Different categories / types of labour rates can be set up e.g. permanent staff, agency staff or for different crafts. For each Pay Rate code, you can store a start date and up to 12 rates of pay, 6 travel rates and 6 lost time rates. These could be used to define rates for standard, overtime, and bank holiday rates etc.
A labour rate is a header record that is made up of a code and a description under which numerous rates are added.
The description (labels) of each of these rates is contained in the ‘Pay Rates’ dictionary file.
Click on Add New to create a new Labour Rate.
Code
This is a unique code reference for the Labour Rate
Description
This is a description of the Labour Rate.
Several individual rates can then be defined. This allows both historic and future labour rates to be stored.
Click on ‘Add’ within the labour Rates grid to add the labour rate details.
Start Date
The date from which these rates are to apply. Rates are valid until the date in a subsequent record for the same Pay Rate number is reached.
Labour Rates
Up to 12 hourly rates can be entered, expressed to three decimals places of the system currency. The systems administrator can define the description for these rates in the ‘PayRates’ dictionary file.
Travel Rates
Up to 6 hourly rates can be entered, expressed to three decimals places of the system currency. The systems administrator can define the description for these rates in the ‘TravelRates’ dictionary file.
Lost Time Rates
Up to 6 hourly rates can be entered, expressed to three decimals places of the system currency. The systems administrator can define the description for these rates in the ‘LostTimeRates’ dictionary file.
These rates are utilised in task completion when allocating time to the task. The Labour, Travel and Lost Time costs will be calculated automatically if rates have been set up for them.
Shift Patterns
Accessed from Standing Data >> Labour >> Shift Patterns
Each Shift Pattern contains a header which defines the description and duration of the shift pattern and then a series of lines that specifies the start day within the shift and the number of days that the line covers. Time bands are then set up against the shift lines detailing the hours worked. A different pay rate can be attached to the shift time bands.
Click on Add New to create a new Shift Header:
Name
This is the unique short name for the shift pattern.
Description
This is the description of the shift pattern.
Duration
This is the duration of the span of the shift in days (i.e. if the Shift Pattern is a standard 5 day week then the duration will be 7)
Multiple Shift Pattern Lines can be added to a Shift Header. Click on Add within the Shift Pattern Lines Grid to add a new shift pattern line:
Start Day
This number represents the start day within the week of the shift pattern line. A value 1 through 7 should be entered (Monday = 1, Sunday = 7)
Line Duration
The Line Duration represents the number of days that this shift pattern line runs.
To add Time Bands to the Shift Pattern Line, click on Add within the Time Bands grid:
Start Time
This is used to store the start time of the shift. This is in 24 hour format and defaults to the current time.
End Time
This is used to store the end time of the shift. This is in 24 hour format and defaults to the current time.
Description
This is the description of the time band.
Labour Rate
This is a drop-down list of the Labour Cost Rates defined in the system.
Sample Shift Pattern
To following example will illustrate the use of Shift Patterns within Agility.
A 3 Weekly shift
|
Week1 |
Mon – Fri |
9am – 5.30pm |
7.30 hour working day |
|
Week1 |
Saturday morning |
8am – 12.00pm |
4.00 hour working day |
|
Week2 |
Mon – Fri |
5pm – 01.30am |
7.30 hour working day |
|
Week3 |
Tues – Sat |
01.00am – 9.30am |
7.30 hour working day |
Labour Rate Header duration 21 days
|
Shift Line |
Start Day |
Duration |
Start Shift |
End Shift |
Description |
Pay Rate |
|
1 |
1 |
5 |
9am |
12pm |
Morning |
|
|
|
|
|
1.01pm |
3pm |
Afternoon |
|
|
|
|
|
3.16pm |
5.30pm |
Late afternoon |
|
|
|
|
|
|
|
|
|
|
2 |
6 |
1 |
8am |
12.00pm |
Sat morning |
|
|
3 |
8 |
5 |
5pm |
01.30am |
|
|
|
4 |
16 |
5 |
01.00am |
9.30am |
|
|
Create the Labour Rate Header:
Click on Add within the Shift Pattern Lines grid to start entering the lines.
Click on Add within the Time Bands grid to enter the times of this shift line.
Add as many time bands as are required.
One shift line has now been added.
Add further shift lines to complete the shift pattern.
The 3 weekly shift pattern as described is now available and configured within the system.
Absence Types
Accessed from Standing Data >> Absence Types
Absence types provide consistency in the recording of absences of employees. By specifying types of absence into fixed items analysis can then be made of employee absence.
Select Add New to create another Absence Type record;
Description
This is the description of the Absence Type (e.g. Holiday or Annual Leave). This field is free text.
Holiday
This should be checked if the absence type is a holiday or booked annual leave.
Authorised
This should be checked if the absence type is authorised. For instance, a holiday or training is usually an authorised absence.
Sickness
This should be checked if the absence type is due to sickness.
Inventory
Units of Measure
Accessed from Standing Data >> Inventory >> Units of Measure
Stock is ordered in a variety of units, such as Kilograms, per metre or per millimetre.
Click Add New to add a Unit of Measure
UOM Type
Choose from the dropdown of options recorded in the Dictionary File UOMType. Options may be i). Meter readings, ii). Stock System etc.
Code
The Code is free text but must be unique and populated.
Description
The Description allows a meaningful description of the Unit of Measure to be entered.
Number of decimal digits
The Number of decimal digits field specifies how many decimal places is allowed for the defined unit of measure. Currently it’s used only when the automatic purchase order is created based on replenishment data. When manual movements are created, the number of decimal places in the quantity field is not controlled by this parameter
Unit of Measure Conversion
A generic mechanism specifying different unit of measure purchase order conversion.
The conversion rules are utilising the existing unit of measure table and unit of measure conversion table.
System parameter will control whether this mechanism is enabled or not.
If Automatic unit of measure creation disabled then purchase order form will function as follow:
Available units of measure and defined conversion are available in a drop-down list. When the unit of measure is selected, system will search for the supplier price with unit of measure matching the unit of measure specified on the line. If the record is found, the price from the supplier price record will be used. If the supplier price record is not found, Last Price from the Inventory Master Record will be used and recalculated according to the selected currency and unit of measure.
If Automatic unit of measure creation enabled then unit of measure and conversion rule will be automatically creates when the size of pack is entered on the screen. The first routine will checks for the existence of the unit with prefixed by ‘pack’ or value defined in PrefixOfUOMConversionCode system parameter with the pack size appended, e.g. for the pack of 125 items, system will search for unit of measure with code ‘pack125’. If the record is found then this unit will be used on the purchase order line. If the record cannot be found, system will create a new unit of measure record with the appropriate code. New conversion record will also be created specifying how the new uom is converted to the master unit of measure.
Transaction Types
Several types of Transaction may be performed against inventory items.
Accessed from Standing Data >> Inventory >> Transaction Types
Click on Add New to add a new Transaction Type.
Transaction Code
The Transaction Code is free text and is a unique identifier for the Transaction Type. This must be populated.
Description
The Description field is free text. This is a meaningful name for the Transaction Type.
Transaction Sign
The Transaction Sign denotes the impact of this Transaction type upon stock.
A value of -1 will have a negative effect on the stock level, such as a Stock Issue.
A value of 1 will have a positive effect on the stock level, such as a Goods Receipt.
Applicable to Bin Type
The Applicable to Bin Type means that transaction type can be only for this bin type
Next Transaction
The Next Transaction field records the Transaction Type, if any, that should follow this Transaction Type. Click on the help icon to open the Transaction Type Help Scan form. This will allow the selection of the Next Transaction Type. (If the selected Next Transaction also has a Next Transaction defined, this second Next Transaction will not be generated during save.
It is possible to specify mandatory fields within the Inventory Movement form that are required for individual Transaction Types. This can be defined within the Transaction Fields within the Transaction types detail form:
Click Add to add a new Transaction field.
Field Name
The Field Name should contain the database field that should be populated within the Movement record for that particular Transaction. Validation is made only for those fields which are defined in the Inventory Movement Header or Inventory Line Movement template.
An example of how Transaction Fields can be used is with ‘Goods Return’:
In the example above, the fields SupplierId and PartPrice need to be entered within the Inventory movement form in order to enter a Goods Return.
Each time an Inventory Movement is performed, an ‘Inventory Movement Document’ is created, containing a unique Document Number record. The format of this reference code can be defined within Sequence Definitions. Please refer to the section Transaction Type Sequence Definitions for details of how to define the Document Number for Inventory Movements. Special meaning have two fields: Quantity and UOMQty. If transaction has defined Quantity or UOMQty as mandatory field, then system will not allow to process transaction when value of Quantity or UOMQty is less or equal zero.
Purchase Order Statuses
Several types of Transaction may be performed against inventory items.
Accessed from Standing Data >> Inventory >> Purchase Order Statuses
Click on Add New to add a new Purchase Order Status.
Purchase Status Code
The Purchase Status Code is free text and is a unique identifier for the Purchase Order Status. This must be populated.
Description
The Description field is free text. This is a meaningful description for the status.
Email Notification in use
The ”Email Notification in use” check box denotes if Email notifications will be generated whenever a Purchase order is changed to this status
It is possible to allow an email to be resent where a purchase order status is at ‘sent’, by changing the purchase order status to ‘sent’ again using the ‘follow on method’.
If a purchase order has been sent more than once then any automatically generated report which is created during the send process will then contain on the document header ‘Purchase order has been amended”.
The email body (in purchase order sent status) will also have the pre-defined phrase ‘Purchase order has been amended” added.
Email Subject
The Email Subject is the subject header of e-mails generated at when a Purchase Order reaches this status.
Email Content
The Email Content field contains the body of the e-mail notification.
Email recipient noted on PO Header
This check box is used to indicate that e-mails are to be sent to the e-mail address specified in the Purchase Order header.
Email Supplier
This check box is used to indicate that e-mails are to be sent to the e-mail address specified against the supplier for the Purchase Order.
Email User
This check box is used to indicate that e-mails are to be sent to the e-mail address defined against the user record
Allow Good Receipt if P/O at this Status.
Tick to allow Goods to be received against P/Os at this status.
P/O changes allowed at this Status
Tick to allow Goods to be received against P/Os at this status.
Status Workflow priority Level
Used to escalate status in purchase order
Attach Report to E-mail.
When e-mail is in use you can attach a report to the email. For example, if the email notification is to the Supplier then when the P/O is “sent” the actual P/O document could be attached to the email message.
Purchase Order Status Flow
Purchase Oder Status Flow tab
A Status Flow can be created by adding statuses within the Purchase Order Status Flow grid. This will specify what status the Purchase Order can be changed to from the status that is being defined.
Purchase Order Delivery Address
Several delivery addresses for Purchase Orders can be specified within the Agility application.
Accessed from Standing Data >> Inventory >> Purchase Order Delivery Addresses
Click on Add New to add a new Purchase Order Delivery Address.
Delivery Point
The Delivery Point is free text and is a unique identifier for the Purchase Order Delivery Address. This must be populated.
Default Address for Supplier
The Default Address for Supplier flag is used to signify that this is the default delivery address for Purchase Orders. When creating a new Purchase Order.
Notes
The notes field is used to record any comments concerning the delivery address.
Currency
Definition of used currencies and exchange rates can be specified within Agility system.
Accessed from Standing Data >> Inventory >>Currency
Click on Add, to add new definition of currency or click on detail icon to add new exchange rate.
Create new currency definition:
Code
The Code is free text and is a unique identifier for the Currency. This must be populated.
Description
The Description is free text and describes the Currency.
Value/Price Decimal
These fields describe how many decimal places should be displayed in value and price fields.
These fields describe what sign should be used to separate decimals or group of digits (thousand etc.). Values displayed in these combo box fields can be defined in system dictionaries: Currency Decimal Symbols and
Currency Digits Groups Separator
They can be accessed from:
Standing Data >> Dictionary Files >> Single Dictionary
.
Symbol
The Symbol is graphical sign used for defined currency ($ - US dollar).
Currency Symbol on Left
This logical value determines on which side of displayed value will be appear currency symbol.
Exchange Rates
Adding a new exchange rate;
Click New Row on grid Exchange Rates in Currency Detail form.
Activate Date
The date from this Exchange Rate is valid. I will be valid until record Exchange Rate with greater date will be created.
Convert
This is formula which describes when value in native currency equals value in just displayed currency.
Kits
Particularly when carrying out Planned Work, there may be the requirement to always have a number of spare parts available just in case.
Kits of these parts can be set up on the system.
Accessed from Standing Data >> Inventory >> Kit of Parts
To create new Kit the user has to select “Add New” from menu:
Code
Free text to code for the Kit
Last Changed
This field stores date when Kit was last changed. This is a system maintained field.
Description
A free text field describing the Kit
Stores Tab
Stores where Available
This grid shows code of Store where this Kit is stocked.
Dictionary Files
Dictionaries are used within Agility to populate combo boxes (drop down lists) which enforce consistent data entry.
Single Dictionary
The Single Dictionary is used for system default lists such as Lost Time Codes and Travel Codes and also used for defining any customised list, to contain a code and a description, which is required as a source for a lookup on a data entry field.
Accessed from Standing Data >> Dictionary Files >> Single Dictionary
Click on Add New to create a new Single Dictionary:
The first task when creating a new Single Dictionary list is to define the Dictionary Header (as shown in the example above).
Sort Order
It is used to define order in e.g. drop-down boxes
Item Code
This is the short name for the single dictionary. The field is free text, although the value must be unique.
Item Description
This is the free text description of the single dictionary.
There are two methods available to enter dictionary items into the dictionary list.
1) Select Add within the Dictionary Items grid to enter a list item.
Sort Order
Define order in drop-down boxes or other list elements
Code
This is the code of the dictionary list item. Although this is free text, the value must be unique.
Description
This field stores the description of the dictionary item. This is the value which will be displayed in combo boxes.
Click OK to add to the list. This will take you back to the grid.
2) Click on New Row within the Dictionary Items grid. A blank line is created on the grid. Double click on the field within the grid to input the dictionary item.
Continue adding list items in either of these formats until all are entered.
Multi Dictionary
The multi level dictionary can simulate a tree structure and has as many levels as required. It is used for customised lists that want the ability to drill down. They can be used to automatically populate drop down lists with only those relevant options being displayed. On selection of the first field the second field is populated with related values, on selection of the second field the third field is populated with the values set up against the second field and so on.
Accessed from Standing Data >> Dictionary Files >> Multi Dictionary
Click on Add New to create a new multi dictionary:
The first task when creating a new Multi Dictionary list is to define the Dictionary Header (as shown in the example above).
Code
This is the short name for the multi dictionary. The field is free text, although the value must be unique.
Description
This is the free text description of the multi dictionary.
To add the next level click Add within the Next Level grid.
1) Select Add on the Next Level grid to enter the top level.
Add a code and description of the level. Both are free text.
Click OK to return to the previous level or click on Add or New Row to add another level.
All items to be input at this level can be entered from this grid. To add a list below one of these options, click on the magnifying glass to go into the detail of that item.
The next level can be entered as previously by clicking on Add or New Row on the Next Level grid.
This can be repeated to have several options at different levels.
Example Multi-Dictionary Definition
In this example, we will create a multi dictionary file storing Inventory Category.
The first task is to create the Dictionary Header:
Click on Add to add a sub level:
Click on Add to add a sub level (Bread Cutters). Enter the details for the Breed Cutters:
Click on Add to add a sub menu.
Click on ‘ok’, which will return you to the ‘Bread Cutters’, but show ‘MegaCutter 2000’ as a sub level.
Click on ok again to return to the ‘Blades’ level. Repeat the above steps to add ‘Cake Cutters’:
Click on ok to return to the Leeds level and ok again to close the multi-dictionary. We will now have the following structure:
Inventory Category
Blades
Bread Cutters
Mega Cutter 2000
Cake Cutters
