admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Browse Source
This commit is contained in:
John Cardinal
2022-02-02 00:45:26 +00:00
parent ecf972c090
commit ee4f639b15
1 changed files with 109 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

139
docs/8.0/ayanova/docs/svc-pms.md
View File

@@ -1,68 +1,147 @@
# SVC-PMs Placeholder
# Preventive maintenance orders
![THIS PAGE UNDER CONSTRUCTION](img/underconstruction.svg)
#b4beta (docs can refer to work order here for bulk of text)
A Preventive Maintenance or "PM" order is a scheduleable "template" work order used to automatically generate Service Work orders on a schedule.
### Automatic date calculations
This is useful for implementing a preventive maintenance schedule for your Customers.
(Note: The very first time a Work order is generated from a newly saved PM it will take the exact values as entered by the user on the PM for all dates and transfer those to the first generated Work order. Only after the first Work order has been generated will the PM dates be re-calculated and updated for the **next** time it generates a Work order in the process outlined below.)
The PM is almost identical to a Service Work order but has some additional fields in it's header area used to control the schedule of generating Service Work orders.
All selectable dates on the PM are advanced relatively based on the next service date calculation:
We won't document the identical fields here, only the fields that are different on a PM from a service work order.
Next service date is calculated as the repeat interval selected on PM then if exclude days are set the next service date is checked to ensure it doesn't fall on an excluded day of week. If it does fall on an excluded day then 1 day is added and it's checked against excluded days and this continues until it hits a non excluded day of week.
See the [Work order](svc-workorders.md) documentation page for all other fields and details.
This Next service date calculated has the previous service date subtracted giving the total time span difference between the current generate date and the next generate date.
## Authorization Roles required
That time span is then added to all the current dates (such as scheduled user start date etc) in the PM as well as the Next service date and the PM is saved ready for the next time it will go through the process again.
This form is available to User's with the following [roles](ay-biz-admin-roles.md):
If an date is left empty it will not be affected by this process so for example if you do not want a scheduled user date to be set or modified leave it blank in the PM.
Full access
### Service Date and Excluded days
- Business administration
- Service manager
When a PM is first created it will use the exact service date chosen the **first** time it generates the first workorder regardless of which day it falls on as it's assumed the user specifically wants that particular day for the first Work order generated from that PM. Subsequent generate events will take into account the chosen excluded days.
Read only access
- Business administration - restricted
- Service manager - restricted
- Sales
- Sales - restricted
## How to access Preventive maintenance
P.M. are accessed in the following ways:
- From the `Service` navigation pane `Preventive maintenance` item to open the P.M. [data table](ay-start-form-data-tables.md)
- From any [data table](ay-start-form-data-tables.md) column showing P.M.s such as the [Work order table](svc-workorders.md)
## How Preventive maintenance works
AyaNova server runs a PM generation job every 5 minutes looking for Preventive Maintenance orders which have reached the conditions required to create a [service Work order](svc-workorders.md).
### Conditions required to generate a work order
PM's will be turned into service work orders based on the following conditions:
- PM's previously calculated internal `Generate date` has been reached
- PM is set to Active
- PM's `Stop generating date` has not yet been reached
- The [Customer](customers.md) selected on the PM is set to Active
If all those conditions are met the AyaNova server will generate a new service work order from the corresponding fields in the PM and it will appear in the [Work order table](svc-workorders.md), on the Service managers [schedule form](svc-schedule.md) and any scheduled users will see their scheduled items in their [personal schedule form](home-schedule.md).
### How a work order is generated
When a PM is turned into a work order the server directly copies the corresponding fields from the PM to a new Work order exactly as entered in the PM but some fields require special handling:
#### Date fields
When a work order is generated from a PM the PM is then updated to move all the relevant date fields forward for the _next_ work order generation. In this way the dates all move forward relative to the time period between work order generations ensuring that (for example) a user is scheduled to provide service in the correct current time frame regardless of how old the PM is when it was first created.
The following date fields are automatically adjusted when they are not empty on the PM are:
- Service date
- Work order item Request date
- Scheduled user Start and Stop dates
- Loaner item Out, Due and Returned (if entered) dates
- Labor Start and Stop dates
- Travel Start and Stop dates
- Task Completion date
- Outside service Sent, ETA, Returned dates
#### Wiki
If the PM has a Wiki and the `Copy Wiki` PM field is set to true the Wiki is copied from the PM to the service work order.
#### Attachments
If the PM has attachments and the `Copy Attachments` PM field is set to true the Attachments are copied from the PM to the service work order.
### How a PM is updated after a work order is generated
Once the new Work order is successfully generated the source PM is updated so that it's ready for the _next_ generation.
#### New service date calculated
The first thing that happens is a new Service Date is calculated by taking the current Service Date that was just used and adding to it the duration specified in the `Repeat interval` field set on the PM header. This is not the final date though as the correct day needs to be found by checking the `Exclude days of week` setting in the PM header and if the new service date falls on an excluded day it adds one day to the new service date and checks against the excluded days until it hits a day that is not excluded. _This_ is now the new Service date and is set on the PM.
#### Generate date calculated
PM's have an internal `Generate date` field which is used to determine the time and date that a new service work order is generated. This is separate from the service date and is calculated based on the new service date minus the `Generate beforehand` setting in the PM header. This is how you control how far in advance to make a service work order before service is actually performed and you should consider how much time is required to ensure sufficient inventory, scheduling etc when making this choice.
The generate date is calculated at this point and set in the PM internally.
#### Stop generating date checked
The server checks to see if the new Service date will fall beyond the PM headers `Stop generating date` setting. If so, the PM is automatically de-actived by setting the Active field to false and saving the PM. Generation stops at this point for this PM until it's set back to active and it's dates reconfigured or it simply remains inactive and will not be touched again by the server.
If the stop generating date will not be reached then the server continues to modify the PM to prepare for the next generation:
#### PM dates moved forward
The server calculates the exact time span between the current Service date just used to create a work order and the [new service date](#new-service-date) that was just calculated. This time span is then used to adjust all the PM's [date fields](#date-fields) forward so they all fall on the same relative day and time from each other.
At this point the PM is saved with it's new settings for the next time and generation for the PM is completed.
### Schedule conflicts handling
Normally if the Global setting "Allow schedule conflicts" is set to False then a work order item scheduled user record can not be saved if there is a schedule conflict. In the case of a PM automatically generating a work order however, this could prevent the entire Work order from being generated. For this reason the normal rules are suspended when generating a work order and it will save the scheduled user record even if it conflicts.
Normally if the Global setting [Allow schedule conflicts](adm-global-settings.md#allow-schedule-conflicts) is set to False then a work order item scheduled user record can not be saved if there is a schedule conflict. In the case of a PM automatically generating a work order however, this could prevent the entire Work order from being generated. For this reason the normal rules are suspended when generating a work order and it will save the scheduled user record even if it conflicts.
### Inventory handling
### Insufficient inventory handling
AyaNova removes inventory from stock immediately upon a Work order item Part record being saved and the same is true if the Work order is generated by a PM at the server automatically.
AyaNova removes inventory from stock immediately upon a Work order item Part record being created and saved and the same is true if the Work order is generated by a PM at the server automatically.
During the Work order generation from a PM, inventory levels are checked and if they are found to be insufficient the amount that _is_ in stock is set on the Work order item Part record created (or zero if none are in stock) and a Work order item Part Request is automatically added to the Work order that is being generated with a quantity equal to the needed balance.
For this reason, it's helpful to set the "Generate before" setting on the PM far enough in advance to handle ordering in parts if necessary.
For this reason, it's helpful to set the [Generate before](#generate-before) setting on the PM far enough in advance to handle ordering in parts if necessary.
To avoid this situation entirely, AyaNova provides an Insufficient inventory warning notification which can be subscribed to and will alert the notification subscriber that at that moment in time there is insufficient inventory to fulfill an upcoming PM.
To avoid this situation entirely, AyaNova provides an Insufficient inventory warning [notification event subscription](home-notify-subscriptions.md) which will alert the notification subscriber that at that moment in time there is insufficient inventory to fulfill an upcoming PM.
### Notification subscriptions related to PM
AyaNova has three notifications directly related to PM's available:
### Notification subscriptions related to P.M.s
#### Preventive maintenance stop date
Notification to remind subscriber that the PM has reached it's stop generating date with settable advance notice. Use this as a reminder to review with the Customer and possibly re-activate this PM or adjust as necessary. To reactivate means setting it to Active and choosing a new future stop generating date.
Notification to remind subscriber that the PM has reached it's stop generating date with settable advance notice. Use this as a reminder to review with the Customer and possibly re-activate this PM or adjust as necessary. To reactivate means setting it to Active and choosing a new future stop generating date.
This is a Tag filterable notification so the notification subscription can have tags set so that only PM's with matching tags trigger this notification.
#### Preventive maintenance generation failure
Notification that there was an error or issue of some kind related to generating a work order from a PM. The error message will be provided and if it's unclear what the problem is, there maybe more information available in the AyaNova server operations log. PM's with temporary issues preventing generation of a work order will try again the next time the PM generation job runs at the server which is every 5 minutes. If the same error arises it will not be sent in a notification to the User for another 12 hours in order to prevent flooding the User with identical notifications.
Notification that there was an error or issue of some kind related to generating a work order from a PM. The error message will be provided and if it's unclear what the problem is, there maybe more information available in the AyaNova server operations log. PM's with temporary issues preventing generation of a work order will try again the next time the PM generation job runs at the server which is every 5 minutes. If the same error arises it will not be sent in a notification to the User for another 12 hours in order to prevent flooding the User with identical notifications.
This notification is not filterable by Tag, it will trigger if *any* PM can't generate a work order.
This notification is not filterable by Tag, it will trigger if _any_ PM can't generate a work order.
#### Preventive maintenance insufficient inventory
Notification that there will be insufficient inventory to meet the requirements of the PM Parts.
Notification that there will be insufficient inventory to meet the requirements of the PM Parts.
When a PM's next "Generate date" is found to be within the date range set by the notification subscription's "Notify before event" duration setting the PM will be fetched and a total required quantity calculated for each unique part / warehouse combination for that PM. Then this list will be checked against inventory and any insufficient quantities will be placed into a list of items sent with the notification.
When a PM's next `Generate date` is found to be within the date range set by the notification subscription's "Notify before event" duration setting, the PM will be fetched and a total required quantity calculated for each unique part / warehouse combination for that PM. Then this list will be checked against inventory and any insufficient quantities will be placed into a list of items sent with the notification.
Note that this is the inventory at that moment in time and for some shops depending on part turnover it may be useful to subscribe to this notification more than once, each with varying settings for "Notify before event". Perhaps one set for double the length of time it takes to get parts on average ordered in and a second one at the deadline for ordering parts or even more depending on importance and specific needs of each shop.
Note that this is the inventory at that moment in time and for some shops depending on part turnover it may be useful to subscribe to this notification more than once, each with varying settings for "Notify before event". Perhaps one set for double the length of time it takes to get parts on average ordered in and a second one at the deadline for ordering parts or even more depending on importance and specific needs of each shop.
The notification will *only* be sent if there are not enough parts.
The notification will _only_ be sent if there are not enough parts.
A PM will in any case generate the work order even with insufficient inventory by making Work order item Part Request records for any inventory found to be out of stock at time of generation, however, this may be too late for some scenarios so that is the purpose of this notification.
A PM will in any case generate the work order even with insufficient inventory by making Work order item Part Request records for any inventory found to be out of stock at time of generation, however, this may be too late for some scenarios so this notification exists to avoid that situation.
This notification will be sent once only every 90 days per subscription as it relies on checking against prior notifications sent out and kept not of in a notification delivery log that automatically removes entries older than 90 days. This means if you set the Notify before event duration in the subscription to more than 90 days you may see more than one of these notifications for the same PM but if it's less than 90 days you will receive only one notification.
This notification will be sent once only every 90 days per subscription as it relies on checking against prior notifications sent out and kept note of in a notification delivery log that automatically removes entries older than 90 days. This means if you set the Notify before event duration in the subscription to more than 90 days you may see more than one of these notifications for the same PM but if it's less than 90 days you will receive only one notification.
This is a Tag filterable notification so the notification subscription can have tags set so that only PM's with matching tags are checked for insufficient inventory.
This is a Tag filterable notification so the notification subscription can have tags set so that only PM's with matching tags are checked for insufficient inventory.