Work Orders are only generated from top-level PMs. Master PMs (where IsMasterPM is true) can't be used to generate work orders.

When there is a hierarchy underneath a top-level PM, all PMs in the hierarchy generate work orders together. When the hierarchies generate is determined by the earliest date a PM needs to generate in the hierarchy. Non-top-level PMs whose UseFrequency flag is cleared are not used to determine the date of the next work order generation. When a PM Hierarchy generates work orders, the work orders are arranged in a similar hierarchy.

When a PM that has a route generates work orders, one work order is generated for the PM and then sub-work orders are generated for the route stops.

PM Generation has two parameters. The first is a flag telling whether to use frequency criteria. If frequency criteria isn't used, then the PM will generate a work order for the current date/time. Otherwise the PM's frequency criteria is used to determine the date for which to generate the work order. Also, if frequency criteria is used, then the second parameter, Lead Time, specifies how many days in advance to generate work orders for. If the lead time is great enough, multiple work orders may be generated.

Work Order generation can be called on single PMs and Sets of PMs using the method generateWork in either object. See PM.generateWork and PMSet.generateWork. In addition, the PMService.calculateWork method does similar calculations as the generateWork methods, but instead of producing saved work orders it puts the work order generation information into a MboSet for use in projections.


Determining Generation Date using Frequency Criteria

Using frequency criteria, PM will generate work orders when their next generation date falls inside of the total lead time. The total lead time is the sum of the lead time parameter passed to the method and the PM's own LeadTime attribute.

The PM generates a work order for the earliest date determined from the day criteria and meter criterions. The duration calculated from these criterions are added either to the LastStartDate or the LastCompDate based on the value of the UseTargetDate attribute (should be UseTargetStartDate).

The Day Frequency calculation uses the PM attributes Frequency and FreqUnit to determine how much time should accrue between work order generations by specifying the number, Frequency, of units, FreqUnit, which is either Days, Weeks, Months, or Years. If the PM's Frequency attribute is zero then this calculation is ignored. The PM attribute NextDate stores the next due date of the PM based on day frequency. NextDate is updated sometime after a work order is generated.

The meter criterions are only checked when a piece of equipment is specified on the PM. Both meter one and two can be checked. Meter 1 is checked if the PM attribute MeterFrequency is not null and not zero. Similarly, meter 2 is checked if PM.MeterFrequency2 is not null nor zero. How the next work order generation date is calculated depends on whether meter readings have been taken since the last work order was generated for the PM.

Exceptions to Frequency Criteria

Seasonal Dates

The attributes SeasonStartMonth, SeasonStartDay, SeasonEndMonth, and SeasonEndDay define a PM's season. If not null, these attributes define a section of the calendar for which the PM generates work orders. If the PM would normally generate a work order for a day outside of the PM's season, the work order is not generated until the PM's season starts again.

Extended Dates

Extended Dates are used to force a PM to generate a work order for a particular date. The extended date is stored in the PM's ExtDate attribute This only overrides the generation date for the PM, not all PMs in a hierarchy. If a PM in a hierarchy has an extended date and another PM is using frequency criteria, the hierarchy generates work orders for the earlier date, which ever that is.

An extended date ignores seasonal dates.

After the PM generates a work order the PM's ExtDate attribute is cleared. The Next Due Date is calculated from the extended date if the adjust due date (AdjDueDate) attribute is true. Otherwise the NextDueDate is calculated from the previous value of NextDueDate, as if the extended date was not used.


Generated work order details

  1. The work order is created with the usual defaults and an autokeyed wonum.
  2. The PMNum field is copied from the PM to the work order.
  3. The PM's description (including long description) is copied to the generated work order.
  4. The work order's Supervisor attribute is set to the PM's Supervisor.
  5. The downtime required and work is interruptable flags (DownTime and Interruptable) are copied from the PM to the work order.
  6. The PM's Calendar is copied to the work order's Calendar.
  7. The CrewID is copied from the PM to the work order.
  8. The PM's LastStartDate is set to the date to generate the work order for. This date is copied to the work order's TargStartDate attribute
  9. If the PM has an Eqnum or Location value it is copied to the work order's corresponding attribute and the usual validation and actions will occur there.
  10. The GL Account of the generated work order is the GL Account usual for that equipment and location with the PM's GL Account then overlain (WO's GL takes priority).
  11. The PM's WorkType is copied to the WO's WorkType attribute.
  12. Extra fields PMEQ1, PMEQ2, and PMEQ3 are copied to the work order's WOEQ9, WOEQ13, WOEQ14 fields.
  13. Extra fields PM6, PM7, PM8, PM9, PM10 are copied to the work order's WOPM1, WOPM2, WOPM3, WOPM4, WOPM5 fields.
  14. Extra fields PM17 and PM18 are copied to the work order's WOPM6 and WOPM7.
  15. The next job plan will be selected and copied to work order's jpnum. See .... If when the job plan is copied there are WPMaterial records missing storeroom locations, which can happen since the JPMaterial table does not require storerooms, the value from the PM StoreLoc attribute is used to fill in the missing storeroom.
  16. The PM's priority is copied to the work order's WOPriority field unless all following conditions are true:
    1. The MaxVar PMUSEJPPRIORITY is set to yes
    2. The PM has a sequence of job plans
    3. The Job Plan selected for the work order had a priority itself.
    In this case the job plan's priority will remain in the work order's WOPriority field.
  17. The work order's target completion date (TargCompDate) is set to the TargStartDate plus the estimated duration. The work order's EstDur may have been modified by copied job plan.
  18. If this PM is a child of another PM, the PM's WOSequence is copied to the WO's WOSequence. Also the WO created by this PM is made a child of the work order created by the PM parent.
  19. Work Order attributes PMDueDate and PMNextDueDate are set to the original work order generation date and the date of next work order generation of the PM. If there was an extended date on the PM, it's value is copied to the work order's PMExtDate attribute.
  20. The work order's status then changes to match the status specified in PM.WOStatus. See work order's status changes for more details.
  21. The new work order is saved before another is created.
  22. If the PM has sub-PMs, those PMs generate work orders next.
  23. If the PM has a route specified, then work orders are generated for the route stops. See applying a route to a work order.

After Work Order Generation

Attributes related to the extended date, ExtDate and AdjNextDue, are cleared after the work order is generated.

If this PM has a sequence of job plans (JPSeqInUse is true), then the PMCounter attribute is incremented.

The last meter reading (LastMeterReading[2]) and the date of the reading (LastMeterDate[2]) are recorded for both meters are recorded if the PM tracks the meter frequency, i.e. the MeterFrequency[2] attribute is not null nor zero.

If a job plan was copied to the work order, the extra fields JP6 to JP15 crossover to PMJP1 to PMJP10.

Next Date calculation

The PM attribute NextDate holds the date when the next work order should be generated, based on day frequency criteria. If the UseTargetDate (UseTargetStartDate) flag is false, then the NextDate attribute is cleared until the work order generated is completed or cancelled. In this case the PM will generate at most one work order per call to calculateWork. Otherwise NextDate is set to the LastStartDate plus the number of days specified by the frequency attributes Frequence and FreqUnit, unless an extended date was used and the AdjDueDate flag was set. Then NextDate is set to ExtDate plus the frequency days.

To calculate the duration to add, the PM's Frequency is multiplied by the value in FreqUnit. FreqUnit is linked to the synonym valuelist 'FREQUNIT' which has values of DAYS, WEEKS, MONTHS, and YEARS. If the value in FreqUnit is a synonym for 'YEARS' then X = PM.Frequency years are added.

After a work order is generated the PM is updated. If frequency criteria is used, the PM goes through the cycle again, generating work order until the next generation date falls outside of the total lead time.

See Also:
   PM package summary
   Work Order package summary
   Job Plan package summary

Last updated: Monday, June 26, 2000