Making the purchasing module work for your organisation – Part 1

Like much in Service Desk Express/Magic (SDE), what you get out of the box with the Purchasing Module IS functional but lacks that certain “je ne sais quoi” that makes it really useful. What hopefully follows is a series of posts that will give those new to either SDE or the purchasing module some pointers on how to really get the most out of this module. Specifically, we will cover:

• Business Processes
• Roles/Groups
• Database Customisations
• Form Customisations
• Data
• Business Rules
• and Training

Just to make this a little more challenging we will assume that your organisation does not have Client Services and consequently cannot use the Self-Service part of Purchasing. To be honest, in some respects that is a blessing (in my humble view of course) as it is anything but user-friendly!

Business Processes

Before attempting to use the Purchasing module, it is essential that you understand the business processes surrounding e-Procurement within your organisation in relation to Service Desk Express. As I said earlier, I am assuming that you don’t have Client Services and I want to make the business process complex enough to be real.

The process my ficticious organisation is going to follow is as follows:

1. A user has a need for something and consequently, via Self-Service, telephone, or email, raises a request.
2. That request is routed to the Procurement Team who check if the item is in the inventory catalog.
3. If it isn’t then it needs to be sourced from an appropriate vendor who needs to be added to the system if not already in existence. Once sourced it can be added to the inventory catalog with its appropriate details including Sales Vendor ID.
4. The procurement team will then raise the purchase request with the appropriate line items.
5. Once complete the procurement team will send the request for authorisation from an appropriate manager in the business.
6. If the manager rejects the request we will let the requester know and update the status of the purchase request to rejected. However, if the manager approves the request the status of the purchase request will be updated to approved and sent to the technical team for delivery.
7. What is important here is that the technical team needs to decide if the requested item is already available in stores. If it is then the requested item is deleted from the request leaving any remaining items that need to be procured. A history entry needs to be added for any items that are deleted.
8. The technical team will then send the purchase request to the vendor as a purchase order to deliver the remaining items and allocate any items from stores to the users configuration and delivered to them.
9. Once the items have been delivered the items will be receipted and added to the user’s configuration before being delivered to them.

The above diagram shows a business process up to the point of procurement.

Roles/Groups

As can be seen from the above business process there are three roles/groups that need to be incorporated into the system:

1. Procurement Group: It is important to control the catalog and related areas. As such this group should be the only group that has permissions to Insert/Update/Delete inventory categories, inventory catalog items, and vendors. In my organisation the procurement group is also responsible for raising the purchase requests themselves.
2. The Approver: It is necessary to decide how you want to identify the approvers within your organisation. Generally, these people exist in the clients module of SDE but are identified as having additional powers! For example, it may be that you are simply given the status of approver and in which case there would be a boolean (Yes/No) field in the clients module that identifies these characters. Far too boring for my fictitous organisation – we are going to have a line manager per client and the request needs to go to the line manager of the requester for approval.
3. The Tech Group: Assuming your organisation is such that they would like to re-use equipment as opposed to buying new all the time, you need someone who can assess the inventory against a given request and decide what can be sourced from stock. They then need to remove the purchasing items from the purchase request and assign the inventory item from stock to the requester. Theoretically, this could be your procurement group but I don’t recommend it for two reasons:
   1. If you operate off multiple sites there is no way a central procurement group would know if an asset was, as a result of another request, about to made unavailable. Consequently, a situation could arise where the item was deleted from the purchase request and then not available from stock.
   2. Secondly, one would hope that your technical group have technical skills! As such whilst a client might request a Dell D610 Laptop, a technician might be able to provide an alternative Dell C610 instead that we have in stock.

Database Customisations

There are very few database customisations required to make this work. The main one is to identify the approvers – so we need to add a new foreign key field in the clients module called Seq.Manager that references the clients module. Assuming that anyone following this already has a bunch of clients in the system you wont be able to prevent nulls so I would suggest that you should check “Required if on form” to all the additional fields specified.

Once that foreign key is created we need to create a virtual fields inside it referencing the Client ID, First Name, Last Name, and Email Address of the manager. I suggest you call these fields something like Manager Client ID, Manager First Name etc.

To make life easier we are also then going to add some new virtual fields to the existing Seq.Client foreign key in the purchase requests module. The fields we want to add are the new fields we just added to the client module i.e. Manager Client ID, Manager First Name etc.

An additional field I would suggest, although not necessary is to add a Cost Code field to the purchase request module – perhaps a string of 255 characters. Most organisations I have worked for want to assign costs of purchases to internal codes.

We also need to add an additional field into the vendor module called Vendor Email of type Misc > Email. We will use this, not surprisingly, to hold the Vendor’s email address so that we can send the purchase request directly to them.

Form Customisations

We need to create four new forms (or modify existing ones if you already have them):

1. New Client: A new copy of the client form with our new fields added to them to allow the line manager for each of our clients to be selected.
2. New Purchase Request: A new copy of the purchase request form where we can add our new cost code field and the additional Manager Client ID, Manager First Name etc. if you want. This form is not necessary if you didn’t add the cost code field.
3. New Vendor: A new copy of the vendor form with our new Vendor Email address field added.
4. New Purchasing History: A new copy of the purchasing history form adding the Note field that is included out of the box – all will become apparent later…

Data

In order to make this all work we need to add specific records of data. Don’t worry if you already have similar as you can substitute my values for yours:

1. Purchase Statuses: We want to be able to control the business process and identify where in the process a given request is. To do this we need the following Purchase Statuses:
   1. Open, For Approval, Approved, Rejected, and Ordered. These are the minimum for my fictitious organisation. We will also create Cancelled, Received Part and Received Full for reasons that will become apparent later.
2. Purchasing Actions: A little more complicated, but in order to lead our procurement and tech groups through the process with the minimum of training, these are essential:
   1. Find the existing Open action and update it to show the new status of Open.
   2. Create a new action of For Approval with an old status of Open and a new status of For Approval.
   3. Create a new action of Approved with an old status of For Approval and a new status of Approved.
   4. Create a new action of Rejected with an old status of For Approval and a new status of Rejected.
   5. Create a new action of Ordered with an old status of Approved and a new status of Ordered.
   6. Open the existing action Received Part and update the old status to Ordered and the new status to Received Part.
   7. Open the existing action Received Full and update the new status to Received Full.
   8. Create a new action of Cancelled without an old status and a new status of Cancelled.
   9. Finally, create a new action of Note with no old status and no new status. We are going to use this to log the deleted line items.
3. Support Subjects (Categories): Create a new support subject for Purchase Request. For the purpose of my fictitious organisation the Subject ID will be “PR”.
4. Groups: Create a new Procurement group and a new Tech group. Again these can be whatever work for your organisation.

So that is it for the business processes, groups and roles, database and form customisations, and required data records. In the next part of this series I will cover the remaining bits of business rules and training.

• purchasing module
• Service Desk Express