Skip to end of metadata
Go to start of metadata

Items Requested

The Items Requested table acts as an intermediary table between the Service Request and Configuration Item tables. When users request items as part of a Service Request, they are creating new Item Requested records. These records represent the Items desired and their quantity for a particular request. For more information, review the Service Request section on purchases.

Record Creation

From a Service Request record, a user creates new Item Requested records for each Item desired in the embedded table view. These records are created on the Items / Tasks / Costs / Time tab in the Service Request record.

Clicking "Select Item" in the Items requested table presents the user with the new Item Requested form, which will be filtered based on the selected service to only show CI Types and Subtypes that were defined in the service:

The customer sees a basic form to select the item desired from the items in the Catalog. Power users fulfilling the request will see additional information.

Record Processing

Items requested may require approval prior to anyone acting upon them. If so, the approvals are handled in the related service request, and once approvals are obtained, the status on the linked items requested is changed to Approved and the assigned person of the service request is notified.

They may then look up Configuration Items in stock to see if they can fulfill the request without ordering additional equipment:

The Choose an In Stock Configuration Item section allows the fulfilling power user to select an existing Configuration Item from the CI table. The CIs available for selection are filtered to only in-stock Configuration Items that match the CI Type and CI Subtype and Catalog Item (if relevant) for this Item Requested. The CI fields link the Item Requested to a physical, tracked asset (CI) rather than just the template description (catalog Item). If they find a matching item, they see a button to assign that item to the user who requested it.

When they click the Assign to Requester button, the system sets the Fulfilled with CI fields in the item requested to the selected CI and updates the status to Applied from In Stock CI. It also updates the linked configuration item to change its Ownership value to Assigned to an Internal User, maps the submitter login from the Service request into the User Login field in the CI, and sets the status of the CI to Pending Install.

If no in stock item is found, the technician can order the item and track its progress in the Status field.

When it is necessary to order new items, the responsible person changes the status to Ordered, which sets the Date Ordered field. Available statuses are Pending Approval, Approved, Ordered, Applied from In Stock CI, Received, Installed, and Canceled.

Once the ordered equipment is received, the status should be changed to Received, and at that point, a button becomes available to convert the item requested into a new configuration item.

Actual Price, Total Cost, Tax and Shipping Costs, and Create Configuration Item button.

Clicking the button opens the new configuration item screen, with the details already mapped for the CI Type, CI Subtype, and Catalog Item. The rest of the information can be filled out and saved.

Later, once the configuration item is set to a status of Installed, a rule on the CI table comes back to the source Item Requested and updates its Status to Installed. Once completed, Item Requested records remain unchanged and stay linked to the Service Request. Since the Item Requested records are maintained separately from the Catalog Item records they were linked to, they retain data that might change over time, such as the actual price paid. Thus, even when the catalog items change, the service requests will always show Item data as it was at the time of the request.

Ownership

Item Requested records are owned by the Contact whose Login matches the Creator Login field in the Item Requested. Since Items Requested are not maintained outside of a Service Request, the relevant ownership stems from the submitter of the Service Request record.

  • No labels