The Location package includes MBOs mostly related to operating locations.
See: Description
Interface | Description |
---|---|
LocAncestorRemote |
Remote Interface to the LocAncestor object.
|
LocAncestorSetRemote |
Remote Interface to the set of LocAncestors.
|
LocationMeterRemote |
Remote Interface to the LocationMeter object.
|
LocationMeterSetRemote |
Remote Interface to the set of Meter objects
|
LocationMntSKDRemote |
Remote interface to the LocationMntSKD object.
|
LocationMntSKDSetRemote |
Remote interface to the LocationMntSKDSet object.
|
LocationOpSKDRemote |
Remote interface to the LocationOpSKD object.
|
LocationOpSKDSetRemote |
Remote interface to the LocationOpSKDSet object.
|
LocationRemote |
Remote Interface to the Location object.
|
LocationServiceRemote |
Remote Interface to the LocationService object.
|
LocationSetRemote |
Remote Interface to the set of location.
|
LocationSpecRemote |
Remote Interface to the LocationSpec object.
|
LocationSpecSetRemote |
Remote Interface to the set of LocationSpecs.
|
LocationUserCustRemote |
Remote Interface to the LocationUserCust object.
|
LocationUserCustSetRemote |
Remote Interface to the set of LocationUserCust.
|
LocHierarchyRemote |
Remote Interface to the LocHierarchy object.
|
LocHierarchySetRemote |
Remote Interface to the set of LocHierarchys.
|
LocMeterReadingRemote |
Remote Interface to the LocMeterReading object.
|
LocMeterReadingSetRemote |
Remote Interface to the set of MeterReading objects
|
LocOperRemote |
Remote Interface to the operating location object.
|
LocOperSetRemote |
Remote Interface to the set of locations
Constants for relationships defined in the 'MAXRELATIONSHIP' table are declared here.
|
LocStatusRemote |
Remote Interface to the LocStatus object.
|
LocStatusSetRemote |
Remote Interface to LocStatus set.
|
LocSystemRemote |
Remote Interface to the LocSystem object.
|
LocSystemSetRemote |
Remote Interface to the set of valid location systems.
|
Class | Description |
---|---|
FldAddressSystem |
Logic to validate FSM spec regarding uniqueness and
consistency of address systems. |
FldAssetLocCommCommodityCode | |
FldAssetLocCommCommodityGrp | |
FldCrossSiteLocation |
This class is designed to validate cross site location identifiers.
|
FldLocAncestorLocation |
Functionality for the Location.parent field.(non-persistent field)
|
FldLocation |
This class is designed to validate location identifiers.
|
FldLocationAddressCode | |
FldLocationAddToStoreLoc |
Location.FldLocationAddToStoreLoc initializes the value.
|
FldLocationAddToStoreSiteId |
Non-persistent column for Add Item to Store
|
FldLocationBillToAddressCode | |
FldLocationCalNum |
Functionality for the Location.calnum field.(non-persistent field)
|
FldLocationChildren |
Functionality for the LocOper.Itemnum field.
|
FldLocationCINum |
Behavior of the non-persistent field cinum in the Location object
|
FldLocationClassStructureid |
Behaviour of the classstructure field in the Location object
|
FldLocationExpectedLife |
Attribute handler for LOCATION.EXPECTEDLIFE
|
FldLocationFailureCode |
Functionality for the Location.Failurecode field.(non-persistent field)
|
FldLocationInstallDate |
Attribute handler for Location.InstallDate
|
FldLocationIsDefault |
Functionality for the Locations.ISDEFAULT field.
|
FldLocationIsRepairFacility |
Validate IsRepairFacility field
|
FldLocationItemNum |
Functionality for the LocOper.Itemnum field.
|
FldLocationLocPriority |
Functionality for the Location.LocPriority field.(non-persistent field)
|
FldLocationNewPercent |
Functionality for the Locations.NewPercent field.(non-persistent field)
|
FldLocationParent |
Functionality for the Location.parent field.(non-persistent field)
|
FldLocationServiceAddressCode | |
FldLocationShiftNum |
Common Validation Class for: Location Shiftnum
|
FldLocationSiteID |
Common validation class for: Location.SiteID
The validation checks that the entered value exists in the site table.
|
FldLocationStatus |
Functionality for the Locations.Status field.(non-persistent field)
|
FldLocationUserCustPersonID |
Validation Class for: Personid
|
FldLocationWarrantyExpDate |
Functionality for the Location.Failurecode field.(non-persistent field)
|
FldLocGroupName |
Functionality for the Locations.GroupName field.(non-persistent field)
|
FldLocHierarchyLocation |
Functionality for the LocHierarchy.Parent field.
|
FldLocHierarchyNewParent |
Functionality for the LocHierarchy.Parent field.
|
FldLocHierarchyParent |
Functionality for the LocHierarchy.Parent field.
|
FldLocHierarchySystemId |
Functionality for the LocHierarchy.Systemid field.
|
FldLocLocation |
Functionality for the Locations.Location field.
|
FldLocMeterReadingDelta |
Behaviors of the persistent Delta attribute in the LocMeterReading object.
|
FldLocMeterReadingIsModificationADelta |
Behaviors of the non-persistent IsModificationADelta attribute in
the LocMeterReading object.
|
FldLocOperFailureCode |
Functionality for the LocOper.Failurecode field.
|
FldLocOperItemNum |
Functionality for the LocOper.Itemnum field.
|
FldLocSystemId |
Functionality for the Locations.SystemId field.(non-persistent field)
This obsolete field used to crossover fields but not anymore.
|
FldLocSystemLocation |
Functionality for the LocSystem.location field.(non-persistent field)
|
FldLocSystemNetwork |
Field Validation class for LocSystem.Network field
|
FldLocSystemPrimarySystem |
Field Validation class for LocSystem.PrimarySystem field
|
FldLocType |
Functionality for the Locations.Type field.
|
LocAncestor |
MBO to represent a location's ancestor.
|
LocAncestorSet |
Represents the set of LocAncestors.
|
Location |
MBO to represent Locations.
|
LocationCache | |
LocationCacheImpl | |
LocationInfo | |
LocationMboEventListener |
The mbo event listener for the script.
|
LocationMeter |
MBO to represent a LocationMeter.
|
LocationMeterSet |
Represents the set of LocationMeter objects.
|
LocationMntSKD |
MBO object to represent LocationMntSKD.
|
LocationMntSKDSet |
Represents the set of LocationMntSKD
|
LocationOpSKD |
MBO object to represent LocationOpSKD.
|
LocationOpSKDSet |
Represents the set of LocationOpSKD
|
LocationService | |
LocationSet |
Represents the set of Location.
|
LocationSpec |
MBO to represent an attribute and value of a specifiation for an operating location.
|
LocationSpecSet |
Represents the set of LocationSpecs.
|
LocationStatusHandler | |
LocationUserCust |
MBO object to represent LocationUserCust.
|
LocationUserCustSet |
Represents the set of LocationUserCust.
|
LocHierarchy |
MBO to represent one parent/child relationship in a location hierarchy associated with a system.
|
LocHierarchyCache | |
LocHierarchyCacheImpl | |
LocHierarchyCronTask | |
LocHierarchySet |
Represents the set of LocHierarchys.
|
LocMeterReading |
MBO to represent a LocMeterReading.
|
LocMeterReadingSet |
Represents the set of LocMeterReading objects.
|
LocOper |
MBO to represent attributes associated with operating locations.
|
LocOperSet |
Represents the set of operating locations.
|
LocStatus |
MBO to represent the status of an operating location.
|
LocStatusSet |
Represents the set of LocStatus.
|
LocSystem |
MBO to represent a system.
|
LocSystemSet |
Represents the set of LocSystems.
|
MoutLocationMeterProcess |
Integration point processing class for Location transactions
sent out of Maximo to an external system.
|
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.
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:
LocationService
-- Service class for
the package.
SpecificationMbo Common
Specifications
-- This is an abstract super class for
psdi.app.location.LocationSpec. WO Main Work Order object
– Operaing location can be set for Workorder. Equipment Main Equipment object
--
Operaing location can be set for Equipment.Last updated: Tuesday, Jan 10, 2001