In NAV 5.0 there is now standard document approval functionality.
While it is fairly basic in some respects, it is more than adequate for a smallish company to handle purchase and sales approvals.
A request I had with one of my clients was for the document approvers to check and approve the documents on a website as these approvers would have very little reason to access NAV for any other reason.
I opted to deploy the approvals via SharePoint using Employee Portal.
Initially I figured this would be fairly straight forward. All I needed to do was set up a couple of web parts in NAV that displayed the Document approvals data, pre filter it so that only approvals for the user that had logged in would be displayed. Provide a link that would display the associated Purchase document. I'd need an option box adding that allowed the user to select Approve, Reject or Delegate.
All pretty simple stuff really. So off I went, I added the Option field to a table, set up a list web part for the Document Approvals, I also set up a Card part for this table, the logic being I'd display a list of all approvals with minimal information and then the user would access the card part to get more information and to select the approve, reject, delegate options. In the card part I added a save button.
Now came the tricky bit. I needed to update NAV when the user made a selection.
In standard NAV there the only tables that can be updated by Employee Portal are the ones related to the demo web parts, i.e. Customers, Sales Headers and Lines, BOMs and Items. If you want to get anything else back in you have to go and make changes to at least one codeunit. Depending on what you are trying to do you need to work on codeunit's 6822 through 6827. For what I wanted to achieve I had to add extra functions to 6824 - Modify Head Data mgt.
What I had to do was add a new function that deciphered the incoming XML, extract the fields I was interested in and then execute the standard Approve, Reject, Delegate Functions.
This took a while because I used a principle I had used many times before when building new code. That is I build it up in small steps checking I am getting the result I want at each step. With the Employee Portal bits what I failed to realise was that I had to initialise a whole heap of variables that get passed out of the code I was working on so that the webpart updates after my code executes. As I hadn't added this code I kept getting error after error in the portal site. Given that every time you make a change you have to stop and start the NAS so that it gets the new code and you can't access the standard Debugger to see where it is failing this became a fairly long process of insert an error command in the code. Restart the NAS, reload the approval document, save it and see what happened, i.e. did I hit my deliberate error before hitting the piece of code that was failing. Once I found the point where I had the line of code that was giving a problem it was straight forward to resolve, finding that line took me about 4 hours.
Once I understood where in my 'normal' style of development I had gone wrong it took me another couple of hours to get the functions I wanted to work. I did run into 2 other problems with it all.
The first was that when i update the record that the Portal has gotten I am getting a 'Another user has modified this record since it was retrieved from the database' error. I can almost live with that, I am going to attempt to set it up so that the portal resets and doesn't attempt to display the updated record anyway.
The second proved a lot more problematic. After getting the web base approvals set for one company I am in the position where I need to roll it out over several companies for the same client. What I don't want to do is have multiple NAS's running as the client is going to be creating new companies and removing old ones from time to time, so I want to run the Approval functionality cross multi companies. after much thought we decided to make a new approval table that is updated when approvals are created and modified, This table also captures the company name of the NAV company that the approval was raised in. We then use this to drive the Approval Portal.
This gave us a lot of headaches as when something is approved in the Portal it needs to update the correct company in NAV, but some clever coding has gotten round this. There is a fair amount of other multi company functionality required by this customer so I'll do a separate post about some of those challenges once I have them figured out.
