In the first part of this series I discussed the business processes, roles/groups, database and form customisations, and addition data required to enable the purchasing module to really work for my fictitious organisation. In this post I am going to continue the series to cover the business rules and training required to technology enable my business process and minimize the amount of manual intervention.
Business Rules
In order to write these business rules we are going to walk through the process described in the earlier post – at this stage I need to express a great deal of thanks to Nashco Solutions who have developed a very cool “Business Rules Print Preview” that gives you a very simple and effective view of your business rules, and who have let me trial this addon free of charge. Using this tool I can provide you (my readers – I am assuming there is more than 1!) with a printable version of each of the business rules involved.
The first business rule we need is the one that takes a ticket (incident) and assigns it to the Procurement Team if the Subject ID = “PR”.
Purchase Request – Ticket Logged
Conditions
when an Incident
Create
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {CUR,Subject ID} | NotEqual | {TR,Subject ID} | And |
| {TR,Subject ID} | Equals | PR | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Update | Incident | Incident (ITIL) |
| Field Name | Value |
|---|---|
| Incident # | {TR,Incident #} |
| Group Name | PROCUREMENT |
Not very exciting but it does the job. If you enable the Subject ID to be available from Self-Service then the rule will work automatically from there as well. You might want to add the Purchase Request tab to your Incident form (if you haven’t already) such that when Procurement receive this ticket they can just click the Purchase Request tab and right-click to create the purchase request – that way they are linked too.
OK – so Procurement do their thing of creating the Purchase Request and adding the appropriate line items. Once they are happy they are ready to get the request approved (or rejected for that matter) by the client’s line manager, they create a new Purchasing History > Add Action of type For Approval. This kicks off the second business rule:
Purchase Request – Request Approval
Conditions
when a Purchase Requests
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {CUR,Status ID} | NotEqual | {TR,Status ID} | And |
| {TR,Status ID} | Equals | FOR APPROVAL | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | Purchase Request # {TR,Req #} requires your approval decision |
| Body | <HTML> <HEAD> <TITLE>Service Desk Express – Purchase Request Approval</TITLE> </HEAD> <BODY> <P>Dear {TR,Manager First Name} {TR,Manager Last Name},</P> <P>{TR,First Name} {TR,Last Name} has asked the Procurement Team to raise a purchase request (# {TR,Req #}) for the following items:</P> <TABLE BORDER=”0″ WIDTH=”75%”> <TR> <TD COLSPAN=”4″ STYLE=”font-weight: bold; color: white; background-color: #3366ff; font-variant: small-caps”>Line Items</TD> </TR> {MATH, (SELECT “_SMDBA_”.”GET_PR_LINE_ITEMS_HTML”({TR,Req #}))} </TABLE> <P><STRONG><EM>Description</EM></STRONG>: {TR,Description}<BR /><STRONG><EM>Needed by</EM></STRONG>: {TR,Date Required By}</P> <P>Please click the appropriate link below to either approve or reject this request:</P> <P>Approve: <A href=”mailto:sde@14j.co.uk?Subject=[{TR,Req #}] Purchase Request Decision=*APPROVED*”>Click here to approve this request</A><BR />Reject: <A href=”mailto:sde@14j.co.uk?Subject=[{TR,Req #}] Purchase Request Decision=*REJECTED*”>Click here to reject this request</A></P> <P>Many thanks,</P> <P>Procurement Team.</P> </BODY> </HTML> |
| Notification Module Descr | SMTP Email |
| Client ID | {TR,Manager Client ID} |
The business rule sends the line manager an email containing the details he/she needs (including the line items) and provides two links at the bottom of the email that allow them to either Approve or Reject the request.
Now, as you can see from the Body, this business rule makes use of a SQL Server User-Defined Function that does not come with Service Desk Express. To use this function see a previous post – Purchase Request Line Items in Email, and you will need the HTML version of the function (Function GET_PR_LINE_ITEMS_HTML).
So, the line manager clicks the appropriate link which will open a new email (preformatted as required) for them to make their decision. Whatever they write in the body of the email will be recorded with the decision. This leads us nicely onto our next business rule.
Purchase Request – Decision Made
Conditions
when a Mail Listen
Create occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {TR,Subject} | Contains | Purchase Request Decision | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Create | Purchase History | New Purchasing History |
| Field Name | Value |
|---|---|
| Note | {TR,Message} |
| Date Performed | {DATE} {TIME} |
| SeqPR | {EXTRACT,[],{TR,Subject}} |
| Description | Purchase request {EXTRACT,**,{TR,Subject}} by {DB,Clients,First Name,”EMail Address” = ‘{TR,AddrFrom}’} {DB,Clients,Last Name,”EMail Address” = ‘{TR,AddrFrom}’} |
| Purchasing Action ID | {EXTRACT,**,{TR,Subject}} |
| Login ID | MAGIC |
Action 2
| Method | Module | Form |
|---|---|---|
| Update | Purchase Requests | New Purchase Requests |
| Field Name | Value |
|---|---|
| Req # | {EXTRACT,[],{TR,Subject}} |
| Status ID | {EXTRACT,**,{TR,Subject}} |
Action 3
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | Purchase Request # {EXTRACT,[],{TR,Subject}} has been {EXTRACT,**,{TR,Subject}} |
| Body | {DB,Clients,First Name,”EMail Address” = ‘{TR,AddrFrom}’} {DB,Clients,Last Name,”EMail Address” = ‘{TR,AddrFrom}’} {EXTRACT,**,{TR,Subject}} your purchase request (# {EXTRACT,[],{TR,Subject}}) at {DATE} {TIME}.The decision he/she gave for this was: {TR,Message} |
| Notification Module Descr | SMTP Email |
| Client ID | {DB,Purchase Requests,Client ID,”Req #” = {EXTRACT,[],{TR,Subject}} } |
This is a slightly more busy and, for that matter, exciting business rule. The business rule does three things:
- Creates a Purchase History record, linked to the Purchase Request, showing what decision was made, by whom, and when. It also includes the body of the email as a potential reason as to why the decision was made.
- Updates the Purchase Request record, setting the status to be whatever the decision was.
- Sends an email notification to the requester, advising them of the decision made by the approver and whatever was in the body of the email as a reason.
Following on from that we have our fourth business rule which kicks in, only if the decision was APPROVED.
Purchase Request – Forwarded To Tech Group
Conditions
when a Purchase Requests
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {TR,Status ID} | NotEqual | {CUR,Status ID} | And |
| {DB,Purchase Requests,Status ID,”Req #” = {TR,Req #}} | Equal | APPROVED | And |
| {DB,Purchase Requests,Group Code,”Req #” = {TR,Req #}} | NotEqual | TECH_SUPPORT | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Update | Purchase Requests | New Purchase Requests |
| Field Name | Value |
|---|---|
| Req # | {TR,Req #} |
| Group Name | TECH_SUPPORT |
Action 2
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | Purchase request # {TR,Req #} has been forward to your group |
| Body | Purchase request # {TR,Req #} has been forward to your group. Please check the line items against current stock levels. Please delete any line items that can be provided from stock after the appropriate inventory item has been assigned to the user’s configuration. If the remaining line items are to be provided by different vendors please select Actions > Split Purchase Request By Vendor (H) from the actions menu on the Purchase Request.Finally, create a Purchasing Action of ORDERED against each Purchase Request (one for each vendor) which will forward the request to the appropriate vendor.Thank you.Procurement Team |
| Notification Module Descr | SMTP Email |
| Group Name | TECH_SUPPORT |
OK, so we are almost there. Our Technical Team have decided what items can be delivered from within stock without the need to re-order and have deleted those Purchasing Items from the Purchase Request. It is important however, at least in my ficticious organisation, that those deletions are recorded somewhere from an audit perspective. Roll-on our fifth business rule:
Purchase Request – Deleted Item
Conditions
when a Purchasing Items
Delete occurs withNo other conditionsActionsAction 1
| Method | Module | Form |
|---|---|---|
| Create | Purchase History | New Purchasing History |
| Field Name | Value |
|---|---|
| Note | A purchasing line item was deleted by {MAGICUSER}:Part #: {CUR,Part #} Description: {CUR,Description} Qty Ord: {CUR,Qty Ord} Unit Price: {CUR,Unit Price} Amount: {CUR,Amount} |
| Date Performed | {DATE} {TIME} |
| SeqPR | {CUR,ReqN} |
| Description | A purchasing item was deleted |
| Purchasing Action ID | NOTE |
| Login ID | {MAGICUSER} |
Ok, so the final bit of functionality we need is to be able to forward the purchase request to the vendor, as a purchase order. I guess at this stage it makes sense to state the obvious here – this post is a demo of the art of the possible. I am not suggesting that what I am sending to the vendor in my example is a well thought through purchase order. That said, hopefully, it should be very easy to see how the examples could be adapted to include the necessary information that your vendors/organisation require e.g. delivery address etc.
So, once the technical team add the purchasing history action of ORDERED to the purchase request, the system will automatically send the request as a purchase order to the vendor for delivery.
Purchase Request – Forward To Vendor
Conditions
when a Purchase Requests
Update occurs with
| Expression 1 | Comparison Operator | Expression 2 | Logical Operator |
|---|---|---|---|
| {TR,Status ID} | NotEqual | {CUR,Status ID} | And |
| {TR,Status ID} | Equal | ORDERED | None |
Actions
Action 1
| Method | Module | Form |
|---|---|---|
| Create | Notifications | Notifications |
| Field Name | Value |
|---|---|
| Subject | New Purchase Order # {TR,Req #} |
| Body | <HTML> <HEAD> <TITLE>Service Desk Express – Vendor Purchase Order</TITLE> </HEAD> <BODY> <P><STRONG><EM>Purchase Order #</EM></STRONG>: {TR,Req #}<BR /><STRONG><EM>Client</EM></STRONG>: {TR,First Name} {TR,Last Name}<BR /><STRONG><EM>Date Ordered</EM></STRONG>: {Date} {Time}</P> <P>Please supply the following items:</P> <TABLE BORDER=”1″ WIDTH=”75%”> <TR> <TD COLSPAN=”4″ STYLE=”font-weight: bold; color: white; background-color: #3366ff; font-variant: small-caps”>Line Items</TD> </TR> {MATH, (SELECT “_SMDBA_”.”GET_PR_LINE_ITEMS_HTML”({TR,Req #}))} </TABLE> <P>Many thanks,</P> <P>Procurement Team.</P> </BODY> </HTML> |
| Notification Module Descr | SMTP Email |
| Address | {DB,Vendors,Vendor Email,”Sequence” = {TR,SeqVendor}} |
So that is it for the business rules.
Training
Service Desk Express (like many other applications) is one of those applications that once you really know how to use it, seems really user-friendly – you just kind of learn to love to the little qwerks (either that or I have become a very sad person). Having said that, for those people who don’t know it and love it, in many ways it is not intuitive. The Purchasing Module is one of those areas that really needs to be trained. Making the likes of the Status ID field read only can be an excellent idea, but only if you have explained how Purchasing Actions work.
Anyway, I would suggest that your end-users (clients), including your approvers, probably don’t need much (if any) training. They already know how to ask for things!
Your Service Desk staff need to understand that by creating/updating an incident to a Subject ID of “PR” will cause a business process to take effect – you might even create a standard description for the Subject ID that provides the service desk team a template of information the procurement team will need.
Your Procurement Team need a whole bunch of training – the need to own the purchasing module! They need to understand how the Inventory Categories link to the Inventory Catalog etc. etc. Don’t skimp here. This team needs to be your biggest fan!
The Technical Team (in my example) will need a lot of loving! The last thing they want to be doing is creating purchase histories. They need to buy into why they are important in this process – one possible selling point is that they are acting as the gatekeepers of the network – no-one gets to buy stuff for the network without it going through them. This also means that users will ultimately get a better service as the technical team will be able to suggest compatible items etc.
Summary
So that is it – I hope it has proved helpful. Many people don’t realise the benefits of utilising the purchasing module when it comes to service delivery. Incorporated well, it can provide your organisation with a wealth of management information that can assist quality decision making. Clearly there is a whole bunch more stuff that we could do and indeed, stuff that we could do differently.
As always, comments are thoroughly encouraged – positive or negative.
JOATIT 