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.
- If no reading has occurred since the last generated work order, the number of days between work order
generations is calculated by dividing the meter frequency by the meter's average units per day. This
value is added to either the LastStartDate or LastCompDate, based on UseTargetDate (UseTargetStart).
- If a reading has been taken since the last generated
work order, the remainder of the meter frequency after the meter reading is
divided by the average units per day. This value is added to the date the
meter reading was taken.
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
- The work order is created with the usual defaults and an autokeyed wonum.
- The PMNum field is copied from the PM to the work order.
- The PM's description (including long description) is copied to the generated work order.
- The work order's Supervisor attribute is set to the PM's Supervisor.
- The downtime required and work is interruptable flags (DownTime and Interruptable) are copied from
the PM to the work order.
- The PM's Calendar is copied to the work order's Calendar.
- The CrewID is copied from the PM to the work order.
- 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
- 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.
- 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).
- The PM's WorkType is copied to the WO's WorkType attribute.
- Extra fields PMEQ1, PMEQ2, and PMEQ3 are copied to the work order's WOEQ9, WOEQ13, WOEQ14 fields.
- Extra fields PM6, PM7, PM8, PM9, PM10 are copied to the work order's WOPM1, WOPM2, WOPM3, WOPM4,
WOPM5 fields.
- Extra fields PM17 and PM18 are copied to the work order's WOPM6 and WOPM7.
- 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.
- The PM's priority is copied to the work order's WOPriority field unless all following conditions are true:
- The MaxVar PMUSEJPPRIORITY is set to yes
- The PM has a sequence of job plans
- 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.
- 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.
- 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.
- 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.
- The work order's status then changes to match the status specified in PM.WOStatus. See
work order's status changes for more details.
- The new work order is saved before another is created.
- If the PM has sub-PMs, those PMs generate work orders next.
- 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