We have come to the last, and most challenging, installment in the Invoice Approval System saga (if you haven’t already read the other 2, here they are – Invoice Approval System – Part I and Invoice Approval System – Part II: The Web.)
When I build something I like to monitor it for a while just to make sure everything is running smoothly. I did this with the Invoice Approval System and noticed that there were many duplicate invoices being sent around to different people causing all kinds of problems. I was also getting calls from the AP group. I ran a few test invoices through the system and everything was working as expected so I met with AP to discuss the problem. It turns out the very premise the tool was built on was flawed – I designed the system to have one invoice = one approver. In reality, most invoices require multiple approvals and so they were sending the same invoice to more than one person wreaking havoc on the system. It was time for a total re-write of the application!
I started by doing a little analysis of what was happening with the current system. I wanted to see if the same invoice was being sent to more than one person at a time or if they seemed to wait for one approval before sending it out again. There was no clear-cut answer – sometimes they were sent out over the course of a couple days and sometimes it seemed like they waited for an approval. It was time to meet with the team and sort it all out. My first question was whether they were looking for a “shotgun” distribution approach or a sequential one. They thought about it and decided that the shotgun approach was the way to go. I then tried to determine if there was any logic behind the distribution list and the immediate response was “No!” I was hoping to have some logic so that I could lessen the time for the clerk to enter the distribution list and reduce the chances of a person being left out of the process. The biggest question remaining was – what to do when someone rejects an invoice. Obviously the invoice had to be returned to AP and they had to take some action but then what do we do? Was the updated invoice re-distributed to everyone, even to anyone who approved the previous version? Did the update go only to the person who rejected it? Everyone who had yet to act on it? The decision was made to only send the updated invoice to the person who rejected it and then to everyone who had yet to act on it.
I now had enough information to begin building a prototype. By now, I am beginning to have second thoughts about the “shotgun” approach so I put something together quickly; not wanting to spend too much time developing something I was not sure about. It turns out the shotgun approach was a bad idea – it was not too bad unless an invoice was rejected by someone and then it became a nightmare. There was another problem with this approach that we didn’t anticipate and that had to do with the escalation process. There were many times (if not most) an invoice had to be approved by more than one person reporting to the same manager. If we did the shotgun distribution and three people working for the same manager failed to respond, the manager would get three e-mails. I had a feeling this was the best way to get the e-mails ignored after a while. It was settled – the invoice would be distributed “in series” and would only be passed along when it was approved. This simplified for the logic and, therefore, simplified the code and database. By now we had upgraded SQL Server and I took full advantage of the new “FILESTREAM” capabilities. The previous versions relied upon the PDF being on the server and the user opening the physical file to view. I could now store the PDF in the database! The PDF was built “on demand” when the user wanted to view it; no more wasted space on the server.
I finished to application and put it on the production server. I had to keep the older version active until all outstanding invoices were approved but that wasn’t too bad – there weren’t many outstanding invoices at this point. So ends another successful project; the client is happy, the end-users are happy, everyone is happy.
(cue sound of needle being dragged over a record)
WAIT! That’s not really how the story ends! It was in production and everyone was happy except we had a new problem. It seems that I didn’t get the full story of the distribution process and the new system was causing problems. You see, there was one department in the company that needed a different process; the invoice had to go to one person in the department who then decided who needed to approve the invoice. The process still had to be initiated by AP but it had to go to the department, get the list and then be distributed. This required a re-work of the distribution page, a new page for the non-AP user to set the list and code to set everything up. Fortunately, this did not directly affect the existing application. It only took a few days to add this process and get it tested. NOW I am done! Think again…. The group decided they needed an “URGENT APPROVAL” process. This meant the invoice had to be approved by the end of the business day. This only required a check box on the distribution page and some additional code so it wasn’t a big deal. I needed to add a reminder and escalation process for the urgent invoices and so the notice went out hourly until the invoice was approved.
NOW I was done! Yes, I am done. There was a lot more to the application than I have here – there was an administration page, reporting, etc… but I didn’t want this article to become a book. I was quite happy with the final result and am proud of all three versions.
If you would like to know more about this project or have one you would like to discuss, please write to me at email@example.com.