Bookshelf Home | Contents | Index | PDF |
Siebel Field Service Guide > Preventive Maintenance > About Triggers for Preventive Maintenance > Processing Logic for TriggersThe following rules regulate the operation of Preventive Maintenance triggers:
NOTE: The Preventive Maintenance module has no built in constraints to limit multiple triggers. When the trigger processing logic evaluates a trigger occurrence, a new PM action is not generated when there is an existing action for the current date or any date in the future. This behavior prevents triggers from occurring multiple times for the same trigger condition. However, plans with a Time or Date trigger combined with another trigger do run with end dates too far in the future. Time- or Date-triggered service actions in the future might prevent other valid triggers (such as Usage triggers) from occurring, and thus prevent the generation of valid service actions. For example, a plan with Time and Usage triggers might run with an end date 1 year in the future. All the PM actions for the next year are generated by using the Time trigger, and during that time the Usage trigger never occurs, regardless of the actual usage. You can avoid this conflict by scheduling PM actions only a few weeks or a month in advance. Then, in the worst case, the engine runs and schedules a PM action by using the Time trigger even though the asset meets the usage criteria tomorrow. The difference in the time between when the PM action should be scheduled and when the PM action is actually scheduled is, at most, the difference between the end date passed to the engine and the current date (when the engine runs). When a service request template is associated with a PM plan, and a trigger for the plan occurs, service requests and activities are created with date fields automatically populated with values. Table 42 lists the fields from PM triggers: |
Siebel Field Service Guide | Copyright © 2018, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |