Using the Item Trigger feature in Status

There are a number of situations where one item is only due after the compliance of another item.  This option is now available in the schedules where a trigger value can be entered in the item beeing triggered.  Together with this feature, we have implemented an option to make items non repeat items.

The configuration of these links can be done from the Status program on Window W1500.

 

Implementation of SharedID

As we have implemented the possibility to move schedules from one data base to another, we can not assume that the ItemID field will be unique once a schedule has been move to another database.  For this reason, we have implemented a SharedID field.  It is important to keep in mind that only one server can allocate SharedID numbers and this must be the parent server.  In a user environment where a server is the only server and there is no expectation to import schedules at a later stage, the server is by default the parent server.  Users can allocate their own SharedID values for each item in a schedule. This can be done from the Schedule Window W1300.  Once SharedID fields are allocated, they will be visible on reports as well as on W1500 where schedules are edited.  Each item in a schedule has a unique ItemID followed by a Shared ID which is unique amongst all servers sharing the same Schedule.  Note the value in brackets, which is the the sharedid allocated, next to the ItemID which is unique to your database.

 

Repeat Items

Users will notice that the latest Status program makes provision for a “Repeat status” on an item.  The default is for all items to be repeat items as that is the way schedules were designed in the past.  There is however situations where an item is due within a specific period and the becomes inactive.  This was previously handled by the “Single” item type, but had the disadvantage that these items always showed with a Due status.

By marking an item as a non-repeat item, the status of the item will change to inactive once it has been complied with and an Install date was given to the item.

Trigger Items

The trigger requirement followed on the repeat item feature.  This is used where an item is activated once a previous or parent item has been complied with.  It is important that the parent item is of the type Non-repeat and must have a SharedID allocated as described above.  Simply move to the child or triggered item and enter the SharedID of the parent item in the trigger field.  You can then select the Trigger button next to the field that will check the validity of the value entered.

 

Calculation

It is important for users to understand how the calculations are done and the status of these fields are activated.  Most of the calculations are based on the presence of an Install Date.  To maintain integrity, this feature can only work automatically in one direction.  Providing am Install date will trigger the child field, but removing an Install date will not always undo the child activity as this might be incorrect.

Non-Repeat Items will automatically become inactive, once an Install date has been entered in the maintenance part of the item (W1600).  If an Install date is removed, no change will be made to the “Active” status of the item as users might want the item to remain inactive. 

A similar pricipal is followed when a child item is triggered by a parent item.  Once the Install date is supplied to the parent item, the triggered item will be made active and the parent compliance data will be carried over to the child or triggered item.  The child will therefore have the same install date, hours, cycles and landings of the parent item.  The information will depend on the type of parent item.  The exeption to this is in the event where the child was already active with  maintenance data at a later date, in which case no change will be made to the child or triggered record.

As before, this will not reverse automatically if the install date is removed from the parent item.  The reason is that there might be valid maintenance information recorded in the child item.  The child item will remain active with the data as recorded before.  Users wil manually have to remove this information from the child or triggered item if it was incorrectly allocated.

When the maintenance is calculated all triggered items without Installation dates will automatically be made inactive.