Fulfillment Confirmation and Reopening a Request

Before the request is finally closed, its fulfillment should be approved by the requestor. As this involves interaction with the user which cannot be fully predicted, there is room for several scenarios in the final stages of the requesting process.

Let's consider a request in status 'Fulfilled, to be confirmed'. In this status the request is waiting for user confirmation of the fulfillment. The following scenarios are possible:

The end user (requestor) confirms the fulfillment

The end user (requestor) uses actions 'Confirm Fulfillment' or 'Decline Fulfillment' in a catalog of requests (e.g. catalog 'My Submitted Requests'). Confirming the fulfillment sends the request to status 'Closed, fulfillment Confirmed'. Declining the fulfillment results in status 'Fulfillment declined' and the personnel responsible for request fulfillment has to resolve the situation before the request can be closed.

Alternatively, an email may be sent to the requestor informing about the request having been fulfilled and asking for confirmation (and possibly additional feedback).

If the requestor does not provide any fulfillment confirmation, after a predefined timeout period the request is automatically closed. (It receives status 'Closed, Time-out'.)

Problematic fulfillment - responsible technical personnel must handle closing of the request

Several situations may occur when it is necessary for the responsible technical personnel to handle closing of a request in status 'Fulfilled, to be confirmed':

• The requestor declines the fulfillment
• The requestor disputes the fulfillment of an already closed request (e.g. a request closed automatically by time-out)
• For any other reason the technical personnel closes the request

If the request has been closed but the end user subsequently provides information about the fulfillment not being satisfactory (this corresponds to the second point in the list above), then the technical personnel needs to 'Reopen' the request. Reopening a request sends it to status 'Fulfillment Declined'.

The responsible technical personnel then must communicate the objections and take measures necessary for closing the request. To close the request, the technical personnel uses action 'Close...' and is asked to specify a corresponding closure category:

• Objections Resolved (when the technician has been able to solve the objections)
• Objections Handled Separately (e.g. by creating a new request)
• Seeking External Support (e.g. by referring the end user to the manufacturer support services)

The existing set of closure categories can be customized and new closure categories added. This is done by creating new status extensions for status 'Closed'.

Rules for Reopening a Request

Sometimes it may be necessary to limit the situations when a request can be reopened. This can be achieved by creating an action rule for the 'Request' object type and assigning this rule to the 'Reopen' action.

Create the rule:

1. Open the Rule Customizer in Valuemation Rich Client
2. Call the 'Create' action and assign the new rule to the SRM module.
3. Select the 'Request' object type, provide a suitable name (e.g. 'Request_AllowReopen') and a description. Rule type should be 'Action Object'.
4. Specify rule condition. For instance, the following condition:
   • Attribute = 'datfulfilled'
   • Operator = 'greater'
   • Value = '_1weekAgo()'

   could be used to make sure that the reopen action can only be called for requests which were fulfilled no more than 1 week ago.

Assign the rule to the 'Reopen' action.

1. In a catalog of requests, call context menu action 'Edit Action Assignment to Catalog'.
2. The Action Customizer opens. Locate the 'Reopen' action in the 'Assign Actions to GUI' tab.
3. Go to the 'Object Rule' column and select the previously created ('Request_AllowReopen' in our example) rule.
4. Apply the changes in the Rule Customizer.