Package psdi.app.workorder

The work order package includes Mbos related to work order planning, reporting and tracking.

See: Description

Package psdi.app.workorder Description

The work order package includes Mbos related to work order planning, reporting and tracking. A work order can be a summary work order, a child work order or a task. A work order hierarchy can include summary work orders, detailed child work orders and tasks associated with this work. The construction of the work order hierarchies allow for the rolling up of work order costs, redefining the detail work, rescheduling the tasks and providing a quicker way to report actuals up and down a hierarchy. Some Mbos in this package keep track of the progress and cost of the work, and some others used to plan the labor, material, tool and service needed for this work to be done, and some others to record the actual labor, material, tool and service has been used, some others used to report the failure information of the work, and some others describe the Safety procedure that needs to be followed to carry out this work. There are many Mbos in this package, although the record of labor, material, tools, and services charged to a work order reside in other packages.

Package Specification

The Mbos and other objects of this set are listed below grouped by function.

These Mbos are used generally:

  • WO, WOSet -- The main work order Mbo and Set. When you want to create or modify other Mbos of this package you should first get the owning work order and then get the related set. The only exceptions to this rule are the settings Mbos and the Assignment Mbo.
  • WoAncestor -- Work orders may be arranged in hierarchies and this Mbo allows you quickly figure out which work order is related to your work order.
  • WOStatus -- This Mbo records the status changes the WO object goes though. For more information about work order status changes see the WOStatusHandler class. Fetch from a WO through the relation WOSetRemote.WOSTATUS.

Work Plan

These Mbos store information about the work order's work plan. Like a job plan, the work plan lists the labor, material, and tool usage related to the work to perform, only the work plan is specific to this work order. Work plans can be entered by the user or copied from an existing job plan.

  • WPLabor -- Information about labor needed to perform the work. Fetch from a WO through the relation WOSetRemote.WPLABOR.
  • Assignment -- Closely related to WPLabor, assignments allow a work manager to assign specific laborers to tasks defined in WPLabor. Fetch from a WO through the relation WOSetRemote.ASSIGNMENT.
  • WPMaterial -- Information about material and services needed to perform the work. Fetch from a WO through the relation WOSetRemote.WPMATERIAL.
  • WPTool -- Information about tool usage needed to perform the work. Fetch from a WO through the relation WOSetRemote.WPTOOL.
See also the job plan package.
For actual charges against a work order use the following relationships to get the records.
  • WOSetRemote.LABTRANS returns a set of LabTrans
  • WOSetRemote.MATUSETRANS returns a set of MatUseTrans
  • WOSetRemote.TOOLTRANS returns a set of ToolTrans

Safety

There are a large number of safety-related Mbos. They are derived from Mbos in the Safety package (see Safety Package description).

A comment about indexes: You will note that for all of these Mbos (except WoSafetyPlan), the unique index to each Mbo contains wonum and wosafetydatasource. This allows multiple rows to exist for the work order, with different IDs and wosafetydatasource. For example, Hazard in the Safety package is unique by hazardid, but WoHazard is unique by wonum, hazardid, and wosafetydatasource.

Wosafetydatasource can equal one of the following:

  • SP -- Indicates that this row was automatically added when a Safety Plan was specified.
  • WP -- Indicates that this row was automatically added when a Work Plan / Job Plan was specified.
  • WO -- Indicates that this row was explicitly added by the user via work order maintenance.

Following are the safety-related Mbos:

  • WoHazard -- Hazards related to a work order. Similar to Hazard.
  • WoHazardPrec -- HazardPrec links related to a work order. Similar to HazardPrec. A WoHazardPrec mbo and its related WoPrecaution will always have the same value for the Wosafetydatasource attribute.
  • WoPrecaution -- Precautions related to a work order. Similar to Precaution.
  • WoTagOut -- TagOuts related to a work order. Similar to TagOut.
  • WoTagLock -- TagLock links related to a work order. Similar to TagLock.
  • WoLockOut -- LockOuts related to a work order. Similar to LockOut.
  • WoSafetyPlan -- The SafetyPlan related to a work order. There can be only one Safety Plan per work order, thus the key to this Mbo is unique by wonum only. Similar to SafetyPlan.
  • WoSafetyLink -- The SafetyLinks related to a work order. Similar in concept to SafetyLexicon, although the data structure is somewhat different.

    Each WoHazard will have a WoSafetyLink with null tagoutid. If the hazard is tagout-enabled, then this WoSafetyLink will have non-null eqnum or location, specifying the "related" equipment or location. Precaution-enabled and hazardous-material hazards may or may not have a "related" equipment/location; it is not required.

    In addition, each WoTagOut will have a WoSafetyLink with non-null tagoutid and non-null eqnum or location. (If this installation requires tagouts to be related to hazards, then hazardid will also be non-null, else it will be null.) The WoSafetyLink eqnum/location will equal the hazard's "related" eqnum/location, and the WoTagOut eqnum/location will equal the eqnum/location to be tagged out (i.e. these values can differ between these two tables, but will be the same within WoSafetyLink for the same hazard).

    It is not permitted to use the same tagoutid for the same wonum, hazardid, wosafetydatasource, and related eqnum/location, even if the tagout eqnum/location is to be different.

    A WoSafetyLink mbo and its related WoHazard will always have the same value for the Wosafetydatasource attribute.

The following diagram shows the relationship between the various safety-related classes. An attribute name followed by an asterisk (*) cannot be null.

Failure

There are two Mbos for reporting failure information for a work order.

  • FailureRemark -- The remark is descriptive information about the failure. There can be at most one FailureRemark per work order. Fetch from WO through the relation WOSetRemote.FAILUREREMARK.
  • FailureReport -- The report represents a path down a failure hierarchy. Fetch from WO through the relation WOSetRemote.FAILUREREPORT. This MboSet is intimately involved with the work order attributes FailureCode and ProblemCode. See the FailureReport object for more information.

Miscellaneous

These MboSets are not related to any single work order but define how the work order objects work:

  • PriCalc -- This MboSet defines how the CalcPriority attribute is calculated. It describes the formulas and one member of the set is marked as the formula to use. See the method WOService.calculateWorkPriority for additional information.
  • WorkPriority -- This MboSet is used to calculate the value of the RespondBy attribute. It defines how soon a job must be completed based on the priority of the work order. See the method WOService.calculateResponseDate for additional information.
  • WorkType -- This table defines types of work orders. Based on the work order's type, work order applications can take different actions. The work order attribute WorkType is validated against this table.
  • WpEditSetting -- These settings define what is editable based on a work order's status.

The purpose of these Mbos is not well defined:

Other classes included in the WO package are:

  • WOService -- The work order service object has related methods and definitions of criterions and relationships for the MboSets of the work order package.
  • WorkPlanMbo -- Defines a common interface for the work plan tables.
  • WoEditSettings -- Encapsulates the edit settings for a specific status and site. Used so that we can cache these settings.
  • PriorityData -- Encapsulates priority and response time data for a site. Used to cache the data.

Related Documentation


Last updated: Monday, March 18, 2002

Skip navigation links