Engagements, Files and Images must contain files, and so when creating objects of these types, users must specify a file. The file specified will be copied to the OpenEngagement DMS and stored on the file system in a directory within the OpenEngagement DMS installation. When uploading using the Go-Between, the local copy will be deleted once it confirms the upload was successful. This is preferable since firms generally do not wish to have multiple copies of files. This leads to versioning issues, multiple copies being edited by different staff and so on. However, it is not possible to automatically delete the local copy when uploading using a web browser. For this reason, users are encouraged to use the Go-Between or Quick Upload where possible, or to manually delete the local copy once uploaded. It is advisable to have backup copies, but preferable to have these in one central, maintained location.

Files of any type may be uploaded to Engagement or File objects. Usually users will upload Working Papers client files or PDF versions of these to Engagement objects and other file types will be uploaded to File objects, but this is not necessary. Engagement objects will not accept non-compressed Working Papers client files; this is the one file type that is not permitted in Engagement objects. Anywhere within this documentation where we refer to Working Papers client files, this refers specifically to compressed client files.

For all types of Document, including Page and Link, users may hit Cancel while creating the object, and the object will not be created.

Users can only upload files to Engagements if they have the Engagement signed out. This prevents having two or more people trying to simultaneously upload to an Engagement. As well, if a user has set an Engagement read-only, it is not possible to sign that Engagement out.

All document items have View, Edit, Properties and Local Roles tabs. Only the View tab will appear if the Document is not signed out by the current user.

The View tab will show: which user last accessed the document and when, which user last modified the document and when, the name, type and size of the enclosed file if any, the period end, the roles the current user has on this item, and which Reviewers have and have not completed their reviews. In addition, Engagement objects that contain Working Papers client files will display some information regarding the client file: the Engagement Type, Created By, Last Accessed By, and the latest version of Working Papers in which the file was opened. This last field is useful, as it will effectively display for users which versions of Working Papers the client file can and can not be opened in, and which versions will require the client file be rolled forward. This information is extracted from the client file each time it is uploaded, whether uploading through a web browser, Quick Upload, or Go-Between. If using the Go-Between, the client file must be loaded into Working Papers, and so, in this case, the client file will be rolled up that version of Working Papers. Users who do not wish to roll their client files up should use a web browser or Quick Upload to upload these files.

The period end is also extracted from the client file. As with the other fields, this can only be extracted from client files from version 2004.1 or later. With client files that have not been rolled up to Working Papers 2004.1 or later, it is not possible to extract this information.

Since period end is a required field for Engagements (though it is optional for other Document types), it must be filled in for client files that are prior to Working Papers 2004.1. If the client file has been loaded in Working Papers 2004.1 or later, the period end will be extracted from the client file and there is no need to enter a period end; any period end entered will be overridden by the value parsed from the client file.

As well, where users upload files other than Working Papers client files to Engagements, a Period End must be specified. This applies only to the initial creation. Once a period end is specified it does not need to be specified again for subsequent uploads.

The OpenEngagement DMS saves the last period end specified for a Document, so when creating new Document objects, this date may be used as the initial default value for the period end.

When uploading a Working Papers client file, the title of the Engagement will be taken from the client name specified in the client file, if available. Otherwise the title will be taken from the name of the compressed client file. If another file type is uploaded to the Engagement, the name of the file will be used for the Engagement title. It is possible to have two Engagements in the same section with the same title. This means, if users upload files with different names to Engagements, or they change the client names within client files, the Engagement title may change. However, the Engagement id will not change, and any links to the Engagement will still be valid.

It is possible on Windows to specify file properties for files on the file system, which may be viewed by right-clicking on files in the Windows Explorer. Working Papers takes advantage of this and specifies a number of file properties for its client files. When files are uploaded to the DMS and downloaded from the DMS, these properties are preserved.

It is possible to run out of disk space when uploading to the DMS. When this occurs, a warning message will be presented. Users should then remove some content if possible, or provide greater disk space.

When uploading a Working Papers client file to a new Engagement, or to an Engagement that does not currently have a Working Papers client file (i.e., it has a PDF file or some other file type), the OpenEngagement DMS does not check the GUID; if there is a GUID, the DMS simply extracts the GUID from the client file, and stores it in the DMS's Engagement object. But, when users upload a client file to an Engagement object that already has a client file, the OpenEngagement DMS then checks if the GUIDs match. It will not allow uploading a client file if the GUIDs do not match. That is, the OpenEngagement DMS will not allow users to overwrite one client file with another, but will allow users to overwrite one client file with another version of the same client file.

Working Papers client files from version 2004.00 and later have GUIDs that uniquely identify them. The GUIDs may be viewed by right-clicking on a compressed client file and viewing the custom file properties. They're a string of letters and numbers, such as adc5716a-e26b-4764-b99fd94a54b2. Where Engagements contain client files prior to Working Papers 2004.00, it is not possible to check the GUIDs. In this case, whenever another file is uploaded to the the Engagement, a warning message is presenting asking the user to confirm they wish to overwrite the file contained in the Engagement object. It is possible for the file in the Engagement to not have a GUID and a file later being uploaded to have a GUID, and for these to actually be the same client file. For example, it is possible that the first version of the client file was opened in a version of Working Papers prior to 2004.00, then the file was rolled up to Working Papers 2004.00 or later, so was given a GUID, and this is what is being subsequently uploaded to the Engagement.

Once an Engagement contains a Working Papers client file with a GUID, it is not possible to upload another client file unless it has the same GUID.

OpenEngagement DMS also uses the GUIDs associated with CaseWare client files to check that the same client file is not uploaded to more than one location within the DMS.

When an Engagement contains a Working Papers client file, there is a controlled system for downloading the file. When an Engagement contains another file type, downloading works equivalently to downloading files from File objects: the files are downloaded by clicking on the link on the View tab, and files may only be downloaded as editable. With Working Papers client files, however, the process is more involved, and provides greater security to users.

The view permission covers downloading any files within the Engagement. If the Engagement contains a file, whether it is a PDF, Working Papers client file, or other type of file, a user can view or download the file if and only if they have view permissions for the Engagement. This means, if a user has permission to view an Engagement, and the Engagement contains a Working Papers client file, they can always download a read-only copy of that file, though they may or may not be able to download an editable copy. If the Engagement contains any other file type, they will be able to download that file. As well, users can download the enclosed file even if it is signed out by another user or set read-only.

Where Engagements contain a Working Papers client file, if users have permission to edit the Engagement, it is not signed out and is not read-only, then the user may sign it out and download an editable copy. It is not possible to download an editable copy without signing it out. Once signed out though, the user who signed it out may perform additional downloads of editable and read-only copies.

Where engagements contain a Working Papers client file, there will be certain actions available under the Actions menu. If the current user has the engagement signed out, and it contains a Working Papers client file, the available actions will be: Sign In, Undo Sign Out, Download, and Download Read-only Copy. If the current user has the Engagement signed out, and it contains a non-Working Papers file, the available actions will be: Download, Sign In and Undo Sign Out. Selecting download will launch your web browser's standard download dialog.

If an engagement is signed out, no other user gets the download action, even Site Managers or Engagement Managers.

Where an Engagement contains a CaseWare client file, selecting Download and Download Read-only will both launch Working Papers, which will launch the Go-Between to download the client file from the DMS.

The files contained in File and Image objects are always available to download to any users who have permission to view the objects, whether the File/Image is signed out or not, and whether it is set read-only or not. Signing out and setting Documents read-only only prevents other users from uploading or editing metadata. To download an enclosed file in a File item, use the Download option in the Actions menu. To download an image from an Image object, the user must right-click on it. Clicking the link will take you to a page where you see the image full-size.

It is possible to place Working Papers client files in File objects, though this is not advised. Using the Engagement type provides greater control when working with client files.

Though it is possible to download files from File objects at any time, it is recommended that any user, who intends to modify the file and later upload it, sign it out. This prevents other users from editing the document at the same time. For example, a File object may contain a Word file. User Alice and Bob may both have permission to view and edit the File. Alice may download the Word file and begin modifying it, but not sign it out within the DMS. Later, Bob may also do this. Then Alice signs out the File and uploads her modified version of the Word document in, at the same time signing the File back in. Then Bob does the same thing, wiping out Alice's work. It is preferable, therefore, to sign out the File within the DMS as soon as you download if you intend to later upload the modified file.

If the current user has a Document signed out, the available actions are: Download, Download Readonly Copy, Sign In and Undo Sign Out, though Download does not apply to Page or Link items, and Download Readonly Copy applies only to Engagement objects.

Page objects are generally edited using the FCK editor, a WYSIWYG editor quite similar to Microsoft Word. This is not necessary, however, and users may enter plain text or HTML code if they wish.

It is not possible to upload files to File or Image objects unless the current user has the file signed out.

Where File objects contain file types such as Word or Excel, it is possible to launch the appropriate application to view the contained file. However, users should not edit these files; the changes will not be saved to the copy within the DMS.

The OpenEngagement DMS provides a Sign-in/Sign-Out mechanism similar to that within Working Papers. It is possible, therefore, for users to do DMS-level sign-outs and Working Papers-level sign outs. The two are different concepts, but are analogous. Generally, firms using OpenEngagement will use DMS-level signouts and firms not using OpenEngagement will use Working Papers-level signouts. It is possible, though rarely necessary, to use both types of signout. Throughout this documentation, any mention of sign-in/sign-out, unless it specifies otherwise, refers to the DMS-level sign-in/sign-out.

With a large Engagement, the preparation and review are often done in parallel. For example, the cash section may be ready for review while the accounts receivable section is still being prepared. In order for these tasks to be performed in parallel, users should utilize Working Papers-level check-outs. Future versions of the OpenEngagement DMS will allow multiple simultaneous sign-outs and check-outs, but this is not possible at present. Instead the DMS provides a simpler and more controlled interface. The OpenEngagement DMS deals with the engagement as a whole; at any time, one user may sign out the engagement.  At that time, others may view it, but not modify it. It is possible for the user to sign it out and download it to a network location, where users may do Working Papers-level sign-outs and check-outs.

Only the person who signed out an Engagement may sign it back in, or an Engagement Manager, Site Manager or Manager. Though these other users may have the ability to sign engagements back in, they generally should not. This functionality is provided to cover where staff are unable to sign in the documents themselves, such as after a change in employment status with the firm.

When Documents are signed-out, other users can not edit the Documents; they can not upload files to them, change their description, change their period end or anything of this nature. Some user may, though, be able to change the workflow state.

Engagement Managers, Site Managers and Managers are able to sign-out Documents when they are in the Reviewed and Completed states, but in these states, Preparers and Reviewers are not able to. In all states, up to the Archived state, some users are assumed to be working on the engagement, and so there should be some set of one or more users with permission to sign out the Document.

Once a user has a Document signed-out, it is possible to sign it in, or to undo the sign-out. In the case of Page and Link objects, there is no difference. With Engagement, File and Image objects, however, selecting Sign In, will take users to the Edit tab where they can upload the file.

When users upload files to Documents, they have the option of keeping the Document signed-out. This may be used when users partially complete their work, and wish to post it to the DMS so that those other users with viewing permissions on the Document may view an up-to-date copy, or to backup their work.

The OpenEngagement DMS provides a mechanism to set Documents read-only. This will effectively halt all work on the Document until the read-only status is removed. Documents set as read-only may be viewed and enclosed files may be downloaded (in the case of Working Papers client files within Engagement objects, only a read-only copy of the client file may be downloaded), but no user may edit the Document, modify its keywords, assign local roles, change it's state, sign out the Document, or in any other way modify the Document.

Documents cannot be set read-only if another user has them signed-out. When a user has a Document signed-out, they may be working on an enclosed file outside of the DMS, which the DMS can not prevent. Since the OpenEngagement DMS cannot prevent this, it can not allow signed-out Documents to be set as read-only. Therefore, Documents can not be read-only and signed-out at the same time.

Only the user that set a Document read-only, Site Managers, Engagement Managers, and Managers can unset it as read-only.

There is a tool in the OpenEngagement configuration to unset the read-only status of all Documents set by a given user. This tool will also undo the sign-outs of all Documents for that user.

It is possible to copy content within an OpenEngagement DMS site and to move content from one location to another. The latter is done through the cut and paste actions. Cut and paste are available only to perform move operations, so it is not possible to paste an item into multiple locations. This is to protect the integrity of the content of the DMS. As the operations are intended for move operations, they work similar to cut and paste in Windows Explorer, and not as in Microsoft Word. That is, when a user performs a cut, the item will not actually be cut until the user also subsequently performs a paste.

Users may move objects such as Areas, Entities and Sections, which contain other objects, thereby effectively moving many objects at the same time.

Copy and Cut operations may be performed by selecting one or more items in the Entities or Documents tabs or by selecting the current item using the menu items available in the Actions menu. Where multiple items are selected, the user may have permission to copy or move some and not others of these. In order to perform a move operation, users must have both permission to cut in the source location, and permission to paste in the target location.

While any content type may be copied, Engagements with CaseWare client files may not be. This is to ensure the integrity of the site. In order to maintain this, Sections, Entities and Area which contain Engagements with CaseWare client files may not be copied.

The permissions required to perform copy, cut and paste operations are identical; if a user has permission to perform any of these, they may also perform the other two in that location.

The permissions to do this vary depending on the object type, and are listed here below.

Areas
Only Managers and Site Managers may perform a copy/cut/paste of Areas. Users must  have one of these roles in both the source and target locations.

Entities
Only Managers, Site Managers and Entity Managers may perform a copy/cut/paste of Entities. Users must  have one of these roles in both the source & target locations. The operations do not check the state of the Entity, any sub-Entities or items within the Entity. That is, it is not relevant if the Entities are Active or Inactive or what state any Documents within the Entity are in.

Sections
Only Managers, Site Managers and Entity Managers may perform a copy/cut/paste of Sections. Users must  have one of these roles in both the source & target locations. The operations do not check the state of the items within the Section.

Documents
Only Managers, Site Managers and Engagement Managers may perform a copy/cut/paste of Documents. Users must  have one of these roles in both the source & target locations. The operations do not check the state of the Document. Users cannot cut read-only documents.

Any object in the OpenEngagement DMS may be renamed. This may be done for most content types by editing the Title in the Edit tab. As well, users with sufficient permissions may view the Documents tab for Area, Entity or Sections, and see a Rename button below the table. From this tab, users may rename multiple objects at the same time.

Renaming Engagement, Image and File objects is permitted, but the title will be reset the next time a file is uploaded to the item. Since these object types take their titles from the name of the enclosed file (or, in the case of Working Papers client files within Engagement objects, the name of the client, if available), this will over-ride the renaming performed by users in this manner.