Monday, May 25, 2009

Issue: Custom Functionality in Workpapers

Issue: In some cases, users will need (or should have) custom functionality within Word, Excel, or PDF documents to enhance their workflow or reduce required time on the workpaper.

Resolution: Just because documents are stored in Engagement doesn't mean that users can't have custom functionality in the Office suite applications. One great thing about Word and Excel is that Microsoft created them to be open enough for developers to create functionality that does not exist out of the box. (On a side note, some open source office suites provide similar custom functionality options.) Acrobat also has custom functionality options similar to Microsoft products but I will stick to Word and Excel.

There are two main ways to create custom functionality in Word or Excel (or any Microsoft Office application): (1) Macros stored in a file or (2) a custom add-in. A short discussion of each as they relate to Office 2003 is below.

Macros stored in a file

Many users have done this and may not know it. If you have recorded a macro and stored it in the Normal.dot (Word) or Personal.xls (Excel) you have done a simple form of this. Macros can be recorded or written from scratch depending on their complexity. The more complex a macro is, the more "writing" from scratch you'll have to do. Once the macro is finished, it will need to be stored in a special type of file; a template (.dot) for Word and an add-in file (.xla) for Excel. Both types of files are accessible from the "Save as..." option in the File menu from the applicable application. These file should then be saved in the appropriate folders on each users computer so the application knows they're safe to load at startup. A detailed example will be posted later.

A custom add-in

Custom add-ins are developed using an integrated development environment or IDE. Software developers and other advanced programmers use IDEs. Microsoft's Visual Studio is an example. IDEs offer functionality that macros don't enlarging the possibilities of the custom functionality but also may become more complex fairly quickly so be careful. A detailed example will be posted later. Distribution of a custom add-in is fairly easy once some setup is complete.

NOTE: Just about any custom functionality developed for Office 2003 will still work in Office 2007.

General Disclaimer

The articles and comments posted on Unofficial ProSystem fx Engagement Support are the opinions of the posting author. They do not represent the opinions of the authors collectively nor do they represent the opinions of the developers or copywrite owners of the software mentioned.

There is no warranty given or support offered by posting articles or comments. The authors are not liable for any data loss or other catastrophes caused by implementing information contained herein. All readers who chose to implement anything contained herein are responsible to backup their data and ensure it is recoverable.

Wednesday, January 7, 2009

How To: Used Protected Word Documents in Pfx Engagement

Issue: How do I (or my firm) implement protected Word documents within Pfx Engagement?


Background: Some firms may have specialties in niche industries where standard workprograms, such as those published by PPC, are not tailored enough to fill the need for these firms. Some may decide to develop their own workprograms for their engagements. The question has come up, "How do I ensure the workprograms' text doesn't change from the approved content?" One possible solution is to use protected Word documents.

Resolution: Protecting a Word document effectively makes the document a form in which text can be added to fields. Nothing else on the document can be changed. This also means that the integration with Pfx Engagement is broken unless the following steps are performed.

Before proceeding, at least one person will need to install the Protected Files Utility, available on the Pfx Engagement install media.
  1. 1. Create the Word document to be protected.
  2. 2. Add all the fields necessary for the Word document to be completed by a user. Either form fields or VBA fields may be used.
  3. 3. Protect the document (instructions here). Remember the password used to protect the document.
  4. 4. Open the Protected Files Utility.
  5. 5. Navigate to the Word document that was just protected and select "Open".
  6. 6. Type in the password used to protect the Word document.

All Pfx Engagement toolbar functionality now works for the person who just ran the Protected Files Utility. That utility creates a hash file in the C:\Pfx Engagement\WM\ directory* which contains the password and a GUID associated with the password. It also adds the password's GUID to the custom properties of the Word document (right-click, select "Properties", go to the "Custom" tab) so Pfx Engagement knows which password to use to allow the toolbar functionality.

If the same password is going to be used on multiple Word documents (or Excel documents for that matter), the easiest way to "add" the password to a new document is to copy the the custom property from one file to another manually. It is possible to automate the copy process using a VB script (a web search will reveal the code) but it is pretty complicated. It may be overkill if the firm(s) is only updating a few documents on an annual basis.

Also, to allow all Pfx Engagement users the ability to use the toolbar with these protected Word documents, the hash file created by the Protected Files Utility will need to be copied to the C:\Pfx Engagement\WM\ directory* on each users machine which can be performed manually or using a login script developed by your IT folks.

Considerations and Limitations: If this sounds like a great solution to your problems, there are a few cautions to consider. First, tickmarks cannot be inserted within text fields. Usually, from what I've seen, they can be added but they replace the text field entirely. Second, spell check does not work within text fields. Third, users cannot copy from protected text. This becomes an issue if staff copy some words from the workprogram steps to use in the response to the step. Forth, inserting multiple workpaper references using the Insert Workpaper Reference tool from the toolbar is not easy. Sometimes workpaper references end up outside the text field which prevents any user, including reviewers, from selecting the workpaper reference to open it.

* This is the directory in which Pfx Engagement is installed if you accept the default. Your installation may be located in a different root directory.

Wednesday, December 24, 2008

How To: Manage binder sizes on the Pfx Engagement Server(s)

Issue: How do I pull a meaningful list of binders from our Central File Room(s) along with their file sizes?

Background: In a Windows environment, a "binder" is represented by a single directory (or folder) on an employee's workstation and on the server. The directory has a unique ID called a GUID. That directory houses all the workpaper files shown to the user through the Binder View within Pfx Engagement. This setup poses stumbling blocks for system (those maintaining the hardward) and application (those administrating the Pfx Engagement) administrators when trying to manage the binders' size on the server hard disk.
  1. 1. GUID: This is an unique identifier used to keep track of the binders in an efficient and effective way which is standard industry practice. While this is great for computers, humans can't easily make heads or tails of it. It will have to translated into something recognizable to humans so that it can be associated with a specific binder in the views within Pfx Engagement.

  2. 2. File Size: This is not as easy as saying, "How big is my Word document?" Since a binder is actually a directory on the hard disk, what is actually being asked is "How much space is being used by this directory?" or "How big is this collection of documents?". Directory size is not displayed by default in Windows Explorer making it difficult to view manually (third party applications are available to add this to Windows Explorer).

  3. 3. Information Accessibility: This is something that may need to be monitored more frequently than annually. As such, creating a list of binders over a certain size should be easier than manually typing the list (basically, running a report).
Resolution: There are two applications that help address these stumbling blocks: ReportBuilder by CCH (go here and login) and Windows XP SP2 Support Tools by Microsoft. Both applications can be installed on the Pfx Engagement administrator(s) computer; there is no need to install them on the server.

Once both applications are installed, peform the following steps to identify binder sizes:
  1. 1. Open a Command Prompt (Start Run Type "command" or "cmd")

  2. 2. Type the following:

    diruse /* /m /, "\\[Pfx engagement server name]\Admin\workpapers\[Central File Room name]" > "[path]\[desired file name].txt"

    For example:

    diruse /* /m /, "\\engagement\Admin\workpapers\Main Office" > "C:\Engagement Reports\BinderSizes-20081227.txt"

  3. 3. Start ReportBuilder (found in C:\Pfx Engagement\WM\Utilities\Report Builder)

  4. 4. Enter the name of the server and press OK

  5. 5. Select "Client/Binders List" from Report on the menu bar

  6. 6. Press "Export to Excel"

  7. 7. Move (cut / insert) the "bid" column to Column A and sort in ascending order

  8. 8. Save the Excel file in the appropriate location

  9. 9. Go to the tab named "Sheet 1"

  10. 10. Import the data in the .txt file created in step 2

  11. 11. Add the column headings ClientID, Client Name, and Binder Name

  12. 12. Add a VLOOKUP for each of the added columns, pulling the date from the "Client Binder List" tab (you may want to remove the VLOOKUP formulas based on how you're going to use the data)
Now you're all set. You now have a list of all the binders on the server including all finalized and unfinalized binders and their respective size on the server. This can help the system and application administrators manage the binder sizes to give the most functionality to the users and not overload the network or server.

Wednesday, October 22, 2008

Error: The finalization process for one or more of the selected binders did not complete successfully.

Issue: While trying to finalize a binder, Pfx Engagement hangs or freezes and has to forced to end. After Pfx Engagement is restarted, the binder in the local file room indicates the binder is finalized but the server shows it in process. The user receives an error stating the following when trying to delete the binder.
CRITICAL ERROR: The finalization process for one or more of the selected binders did not complete successfully. The binder(s) cannot be deleted until this problem is corrected.

Please contact Technical Support for assistance before continuing work on the affected binder(s).
Resolution: Perform a full synchronization by right-clicking on the binder in the local file room and selecting "Synchronize."