Bookshelf v7.5: Primary Service Business Components

The primary business components in the Siebel Service Handheld application are Action, Account, Service Request, Order, and Asset.

Action

The primary Business Component in the Service Handheld application is the Action Business Component.

NOTE: The Service Handheld application uses the ActionSHCE business object unlike other Siebel applications that use the Action business object.

Activities are based on the Action Business Component and, therefore, the following views are based on the Action Business Component:

The application is based on activities and all other data relationships are based on the Action object. By default, the activities that are selected for download are determined by a combination of the repository configuration, a QBE, and a PDQ. The QBE is defined to select activities that meet both of the following criteria:

Therefore, the end user sees only his or her open activities—that is, activities that require some action. Generally, the end user does not see activities for other users or activities that do not require action. For example, a field repair activity may be assigned to a field technician, and this activity automatically gets downloaded. There may be instances when you want activities that are assigned to another user to get downloaded. For example, a service center technician makes a follow-up call to the customer related to the activity assigned to the field technician. In order to download the follow-up call activity, you need to make the service center technician and the field technician part of the same team and assign the team to the activity.

This set of user's activities is further reduced by the default PDQs which specify a time frame for the activities:

The activities that are filtered for a user determine which associated accounts, service requests, and orders are downloaded. The association between the remaining business objects is configured in Siebel Tools.

Accounts

The QBEs and PDQs determine which activities are downloaded. In turn, these activities determine the accounts that are downloaded. Only those accounts that are associated with the selected activities are downloaded. Activities are typically children of accounts. Therefore, a reverse relationship must be configured to support the described behavior. This reverse relationship is configured in Siebel Tools at the business object level by linking Account ID on Activity with Account ID on Account.

Service Requests

The downloaded accounts determine which service requests are downloaded. All service requests that are associated with the selected accounts are downloaded. This includes service requests that are associated with the downloaded activities, but it also includes all other service requests associated with the downloaded account. The relationship between accounts and service requests is configured in Siebel Tools at the component level by linking the Account ID on Service Request with the Account ID on Account. The service requests are further restricted by a QBE that selects only service requests that are open or that were closed in the last 30 days.

The following table shows an example of the relationship between activities, accounts, and service requests.


Activity	Account	Service Request
1	A	X
	A	Y
2	A	X
	A	Z
	B

Assume that Activity 1 is downloaded. Activity 1 is associated with one account (Account A) and one service request (Service Request X). Therefore, Activity 1, Account A, and Service Request X are downloaded. However, Account 1 has other service requests associated with it, Service Requests Y and Z, and these service requests are also downloaded.

Activity 2 is not downloaded, although the account (A) and service request (X) associated with Activity 2 is downloaded. Account B, which is not associated with Activity 1, is also excluded. These exclusions illustrate the way in which the Action business component determines which of the other components are selected.

Orders

The downloaded service requests determine which orders are downloaded. Therefore, only those orders associated with the selected service orders are downloaded. The following table shows an example of the relationship between activities, accounts, service requests, and orders.


Activity	Service Request	Order
1	X	L
2	X	M
	Y	N

Service Request X is associated with Activity 1. Any orders associated with Service Request X are downloaded. Therefore, in the example above:

Note that Activity 2 is not selected even though its associated service request (X) and order (M) are selected.

Assets

Accounts determine which assets are downloaded. Therefore those assets that are associated with the selected accounts are extracted. In addition, any assets in the field technician's trunk are downloaded.

No Record PDQs

By default, all records for each screen in the Service application—Activities, Accounts, Contacts, and Service Requests—are downloaded to the device. If the defaults are applied, this would result in an unacceptably large number of records on the device. In the Service application, the relationship between the business components, as defined in Siebel Tools, determines which accounts, contacts, and service requests are selected and downloaded. Therefore, PDQs have been defined so that no account, contact, and service request records are selected for synchronization through the default mechanism. These no-record filters are:

These filters appear, by default, in the Choose drop-down list when end users synchronize their devices. (The exception to this is the PDADef_*No Contacts filter because there is no Contacts screen.) These filters are only applicable during synchronization. The asterisk in the filter name excludes them from the application's Queries drop-down list.