Package psdi.app.location

The Location package includes MBOs mostly related to operating locations.

See: Description

Package psdi.app.location Description

The Location package includes MBOs mostly related to operating locations. Operating locations are the locations in which equipment operates, so work orders are typically written either against the location itself or against the equipment in an operating location. Operating locations are most useful when organized into systems, logical hierarchical systems or network systems. In each system, the operating locations are connected to each other as parent-child pattern. With operating locations organized into systems and the locations related to each other, you can quickly find an operating location in the drilldown dialog box, and identify the equipment at that location.  

Package Specification

The MBOs included in the location package are:

  • Location -- The main class and also the owner of other MBOs in the location package when the Location is an operating location, where equipment operates and work orders are performed. An operating location may belong to either a hierarchical or networked system or it may stand alone, not belonging to any system.  Except for the LocAuth class which is used for storeroom locations, the other MBOs in this package are used only for operating locations.  The Location class is used for other purposes in addition to being used as operating.  A Location can be a storeroom, namely the type being STOREROOM.  A storeroom location is used to store inventory items.  It is a location where inventory issues and receipts are tracked.  A location does not need to be physically bound to a place. A location can be used as courier or labor, namely the type being COURIER or LABOR respectively. An item can be issued to or transferred from/to a courier or labor location. As an example, a Federal Express truck or Mr. Wilson may have the item at a given point of time. Although not a physical location, inventory balances for items in a courier or labor location are tracked. There are other location types VENDOR, REPAIR, and SALVAGE.  These are non-inventory locations and are used mainly in the work order/equipment areas. These types of locations can neither be organized into systems nor be set up as parent-child hierarchy.  
  • LocSystem – A location system is an organization of operating locations. There are two types of systems, hierarchical and networked. As its name suggests, a hierarchical system requires its locations be set up strictly as tree-structured hierarchy.  Within a hierarchical system, only one hierarchy of locations is allowed.  A networked system does not follow the same rules as its counterpart does.  Locations in a networked system do not need to be related to each other in a tree-structured manner as long as they are all connected.  Multiple hierarchies in a networked system are also allowed.  A hierarchical system can be made networked.  However, a PRIMARY system is required to be hierarchical and thus it is not allowed to turn it to networked.  Due to the complexity and flexibility that a networked system allows for node connections and hierarchy setups, a networked system cannot become a hierarchical system.
  • LocHierarchy – The LocHierarchy is the main and only table that contains all hierarchy information for operating locations. An operating location often is part of a hierarchy in a given system.  A LocHierarchy object represents the operating location as a node in the hierarchy.  It stores information of the location and its parent. If there is no parent, then this location is a top-level node. If there is a parent, then there will be another LocHierarchy object(parent location) which contains its own relevant location/parent information. Following the location/parent pattern, the locations in the hierarchy are completely connected to each other.  This pattern allows users to either recursively move up to the top-level location or drilldown to the children of any location.  Although a LocHierachy object stores information as simple as location/parent, the system to which it is associated mandates some restrictions on inserts and deletes. If the system is hierarchical, attempting to create a new top-level node in the system will be rejected if there is an existing hierarchy already.  Trying to give a new parent to a child location that is already connected to a parent will be rejected, because the insert would break the rules of the required tree-structured hierarchy. A hierarchical system basically allows no deletes of any nodes from the hierarchy with the exceptions of the bottom and childless locations.  The system needs to be changed to networked before the delete action can be done.  A networked system accepts inserts/deletes with no restrictions as long as the locations in the system stay connected after such transactions. In a networked system, the delete of a location, or more specific, the disconnection of such location is, by default, making this location a top-level node and bringing over its children. As a result, a new hierarchy is formed in the networked system, which has no restrictions to the number of hierarchies.    
  • LocAncestor –  Unlike LocHierarchy which stores only location/parent relationship, the LocAncestor table stores all ancestors, including itself as an ancestor, for a  location in a hierarchy within a system.  As an illustration, if the location is the 3rd level node in the hierarchy, there will be only one LocHierarchy record for the location and its immediate parent.  However, there will be three LocAncestors records to record all the ancestors for the location.  With this difference, while it takes recursive actions to find all parent locations using LocHierarchy, it takes only one single select to find all the ancestors using LocAncestors. While LocHierarchy stores key information of location hierarchies, LocAncestors is most useful for reporting efficiency.  The inserts/deletes of LocAncestors are strictly performed along with the inserts/deletes of LocHierarchy. Manual operations of LocAncestors may put LocAncestors out of sync with LocHierarchy, impacting reporting accuracy.
  • LocStatus –Status of operating locations. Default values are DECOMMISSIONED, OPERATING, PLANNED. Valid statuses are validated against the ValueList table where the value list name is LOCSTAT. The Location status is not the same as the status of a work order where the status represents the state of the work order and the order of the statuses are critical. A location status can be changed from one to another at any given time with no restrictions.  The status column of the LocOper table stores the most current status change of the location.
  • LocOper – LocOper stores only OPERATING type of locations. The inserts/deletes of LocOper occur only with inserts/deletes of operating locations. As the Locations table is used for many other purposes, the LocOper table stores failure code, priority, and calendar information for a typical operating location. It also stores rotating item information, based on which the operating location can inherit from the item’s specifications and be easily identified by the characteristics. The item information also facilitates building Location Hierarchy if the rotating item has an established hierarchical assembly structure.
  • LocationSpec An operating location, identified by a set of classifications, can be easily located through asset catalog search. The LocationSpec table provides specific information as to the attributes and their individual values for the operating location based on a pre-defined set of specification template.
  • LocAuth – User Access privileges to storerooms. This class is the only one in this package that is not for operating locations. It stores information of the user and the storerooms he can use. Therefore, this class is for storeroom locations only. A user cannot issue or receive materials from/to a storeroom if he does not have authorization to use it.  A user cannot insert/update an inventory record if he is not authorized to use the storeroom where the item resides. He can view the inventory record, however.  A user cannot perform any inventory adjustments if he is not authorized to use the storeroom. An interesting rule worth noting is, if there is no entry in the LocAuth table for the user, this means that the user is authorized to use ALL storerooms. Restrictions apply to the user only when there is at least one entry in the LocAuth table. This then will mean that the user is authorized to use only the storerooms listed in the LocAuth table.
  • LocationMeter - Holds the mostly static metadata for a meter that has been associated with a location. There is no limit to the number of meters that can be attached to a location, however, each meter name must be unique for a location within a given business unit. LocationMeters exist to facilitate the entry of Asset meter readings and are not meant for simply entering Location meter readings. This object also contains cumulative meter reading information and the method and multiplier to be used in the calculation of average meter units when a meter reading is recorded. The AverageMeterUnit attribute is non-persistent - the value is calculated and displayed without being stored in the database. Meters can be specified for operating type locations only.
  • LocMeterReading - Records the details of each meter reading of type CONTINUOUS,GAUGE or CHARACTERISTIC for the assets at the Location. Meter readings generally will not be entered for locations that do not have assets associated with them. Subsequently, meter readings entered for a given location will not roll down to child locations. Location meter readings update the location's assets' meter readings for those assets with the same meter that is designated to accept readings from its Location. Once an asset's meter reading is updated, the reading will roll down within the equipment hierarchy. Readings of type CONTINUOUS can be entered as an absolute or delta (that is, change from the previous value) value.

Other classes included in the Location package are:

 

Related Documentation

Last updated: Tuesday, Jan 10, 2001