A service object is a physical asset or piece of equipment that requires maintenance or repair. Service objects can be anything from complex industrial machinery, a building to consumer products, and can be located at a customer site or in a company's own facilities. The service object holds key information about a specific piece of equipment and can be linked to a model, a part and a serial number.
Service object classification can be of two different types, Functional or Serial. The main difference between a functional object and a serial object is that a functional object is seldom moved while serial object move frequently around in the facility, to other object structures, as well as placed into inventory.
Serial objects can also be non-movable type. Non-movable serial objects, such as turbines or any other very large pieces of equipment that are not actually functional objects, but which will be moved seldom from their locations, can also be registered as functional objects. For objects such as these that represent tangible parts, you also can define a part number and a serial number, just like you can for serial objects. However, the object's position in the structure cannot be changed.
Moreover, in a service context, service object classification can also be used to represent basic serial tracking behavior of objects. The serially tracked objects can be defined with the 'Serial object' classification and the objects that are not serially tracked with the 'Functional object' classification. The serialization of the model should be matched with the object classification when attaching a model to the service object, i.e.: Serial Models can be connected to Serial Objects while Non-Serial Models can be connected to Functional Objects.
The model can be added directly to the service object or will be automatically added if a Model-Part connection is established for the selected part. When establishing the connection between the Model and the object, the serialization of the two should match. When a Model is available on a service object, service object will inherit/instantiate service related information which are defined on the model. However, it is not mandatory to add a model on the service object.
When there is no model attached to the part, the part can be added on a service object without matching the serialization of the part and the classification of the object (serialized part can be added to a functional service object and vise versa). However, if there is a model connected to the part, the connection cannot be established if the Model serialization and the service object classification conflicts. Once the connection between the part is established, the model will be added to the object automatically if available.
This tab can be used to enter and view information on the various party types that are connected to the service object. Party is a concept used to summarize all party types with which the object has business relations, for example suppliers and customers. A 'Primary' party record can be defined for each party type. The Customer is used to control whether a request or a contract can be created for the customer.
Skills contain certificates and competencies that a person should have in order to handle the object. Skills can be inherited from models and model families but can also be added for each Service Object.
Some object information, i.e., test points are used for updating measurements. Enter different test points on objects, considered particularly interesting for carrying out measurements. These test points do not necessarily need to be visible parts of an object, e.g., bearings for a pump, or a weld on a tank.
The parameter represents an object's condition such as Temperature, Quantity produced or Operation hours, Oil level, Pressure, etc. The parameter can measure one of two types of values; Accumulated or Limit values. An Accumulated parameter can for example measure operation time or produced quantity. A Limit parameter can be used to measure temperature, oil level, pressure, water flow, etc.
The Testpoints and parameters added on a model will be instantiated on the service object when the object - model connection is established without apart. When a part - object connection is established, the Testpoints and Parameters will be instantiated from the part.
Recurring service programs and scopes that have been defined for the specific Service Object.
The Service Record lists all the work tasks created for the Service Object.
The Costs tab lists all costs reported against service work tasks done for the object, split per Cost Type such as Material, Personnel etc.
The Contracts tab lists all the request contract lines that are related to the specific service object, regardless of contract status.
A manufacturer normally defines a set of recommended spare parts/material that are needed to repair or maintain a specific model/object, along with required quantities. The spares list allows a user to add this recommended list to the application on the Service Object. And the Spares can be Parts registered in the system or No-parts that are not registered in the system. The spares can also be defined on a model and these spares will be inherited to the service objects when the model connection is established.
A summary view of the total number of each part that has been used in services for the selected object, during a selected time frame.
There can be multiple customer warranties applied on an object. The warranties defined on the service object will be used on the request scopes created for the object when the scope is created within the warranty validity period.
Allows an availability to the service object in order to determine when it is possible to allocate resources to carry out work on the object based on actual availability. It is also possible to register availability exceptions against the object. Further, it is also possible to define a set of preferred resources to work on an object, so that these resources are prioritized over other resources. Once, the availabilities and the preferences are defined against an object, this information will inherited to the service request upon registering a fault.
Allows the user to see a log of significant actions performed on the service object since its creation.