Well I guess the phrase is actually “it’s now gone live” but that just doesn’t invoke the same emotional response. We have a business process that is now partially running in SharePoint. Even better, the right portion is running in SharePoint and the stuff that shouldn’t be in SharePoint is running somewhere else.
The business process is “payables” – something everybody has to do but something most people do differently than we do. See, we’re small, we don’t have a lot of vendors, we don’t have a complicated (no you can’t have that) procurement process and we don’t have a receiving dock. We buy things. We hire contractors. We incur professional fees. We refund premium on occasion and we reimburse people for things. We do this a bunch of ways. We have Concur (shudder and cue the foreboding music) which I actually kinda like. We do ACH transactions. We do wire transfers and we write checks. We also periodically reimburse people for small purchases with something called cash. I’m sure some of the younger readers are Googling that term.
The payables process, in addition to resulting in many financial outcomes, begins with a variety of financial transactions. Eventually, we will lasso all of these transactions and pull them into the same ring, but we decided to start with Check-Requests and checks. The process is pretty simple. We buy something from a vendor. They send us an invoice. We send them a check. In between step 2 and 3, someone studies the invoice, makes sure it’s legitimate, prepares a check request and then somebody else approves that request. That whole process, the stuff between step 2 and 3, is now done in SharePoint. Below are some of the cool things we (remember ‘we’ now means ‘they’ and stands for the shy people on my team) were able to include:
- Maintaining a list of vendors that are automatically checked to make sure they aren’t on the US Treasury’s list of bad guys, and then approved by someone in authority in accounting.
- Create a check request for an invoice(s) from an approved vendor.
- Attach the image(s) of the receipt(s) to that check request.
- Allocate the amount of that/those invoice(s) across multiple departments or multiple accounts within a department. For example, I buy a server, but some portion of the invoice is for the warranty.
- Route the check request to one or more people for approval.
- Do all the little checks and balances like making sure that the total of the allocations equal the total of the request.
- Approve individual check requests for payment.
- Allow the approvers to send the request back to the previous person to correct an error.
The tools used to make this happen include:
- SharePoint external lists and the ability to impersonate users when working with them
- InfoPath forms
- Custom lists and views
- Data View Web Parts to put the forms, lists and view on a single interactive page.
- SharePoint Designer workflows to respond to the various activities a user did and to validate the transaction while it is in process
- HarePoint’s Workflow Extensions to do some of the tricky stuff that SharePoint Designer doesn’t seem to do, like execute SQL Statements or use Regular Expressions to evaluate a sting.
- Nintex Workflow’s “for each” capability to cycle through each Paid request in an external list to update our detailed custom list with the payment details.
- All the various widget to widget connections you can establish in SharePoint Designer to get web parts to respond to other web parts.
We decided to use InfoPath instead of other techniques because we wanted a more functional form with less code buried behind it. I’m not sure that we saved on the coding effort, but I like the mix we are left with. We are trying to stay very close to the level where we can establish the action we want by “configuring” parts instead of writing code. It’s a fine-line kind of balancing act, but it works for us.
This just in, yes I know that Microsoft has put InfoPath on the short-line track to obscurity, but it will be around for a while and I feel that we risk very little by using it the way we do.
The reason I said that the right stuff is and isn’t running in SharePoint is central to our use case for having SharePoint and it is something that I think people often overlook – SharePoint runs in a browser. By building the front-end of this application in SharePoint, I can let people who are traveling submit invoices to be paid, approve payment requests and manage their budgets without having to write any web stuff. Also, since we have that Mass360 browser I talked about, I can approve payments on my iPad without a VPN connection.
The stuff that’s not running in SharePoint are those back-room accounting processes that nobody sees and everyone is content just knowing that they get done. Nothing to see here, move along.