A service object is a representation of an object that is sold to a customer. Information which are important to offer services to the customers and managing service requests can be set up against service objects.
Service object serialization specifies if the object is serially tracked and it can be serialized or non-serialized. The serialization of the model should be matched when attaching a model to the service object. The serialization of the object and model should also match if a part that has a part - model connection needs to be attached to the object.
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 without a part, service object will inherit/show 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 object (serialized part can be added to a non serial 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 serialization conflicts. Once the connection between the part is established, the model will be added to the object automatically if available. And when there is a part connected, the service attributes will be inherited to the object from the part instead of the model.
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.
Skills contain certificates and competencies that a person should have in order to handle the object. Apart from the inherited ones, skills can be added directly at the service object level as well.
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 to be operated on the service object can be defined.
Service record lists all the work tasks that were created for the service object.
Costs encapsulate all costs that were reported against the service work tasks done for the object such as material, resources etc.
Shows a list of all the request contract lines that are applicable on the selected service object.
The manufacturer defines a set of recommended spare material/parts that will be needed for the model along with required quantities. The spares list allows the user to add this recommended list to the application as information on the model and is inherited to parts and service objects when the model connection is established. However, spares cannot be added directly on the object.
A summary view of the total number of each part that was used in services for the selected object during a selected time frame.
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.