Managing many client matter accounts
Professional Service industries such as Legal, Accounting or Architecture, rely on PaperCut’s ability to charge jobs to matter, fund, cost or client codes (in PaperCut terms, we call these shared accounts.
Since 15.3 there have been steady improvements in optimising how PaperCut handles shared account requests. This article is a reasonably high level overview of how to avoid the need to redesign after deployment.
When deploying a large volume of shared accounts, it is important to consider the scalability of the solution before installation.This includes
- Upsize to an RDBMS
- Responsiveness when loading many shared accounts at an MFP (if using PaperCut MF)
- Loading time of shared accounts when using the (optional) Desktop Client software
- Server sizing considerations
Any site with a large number of shared accounts (or users / devices) will see performance gains from using an external database. Using an external database helps future proof an install by providing scalability. For more information please see: Upsizing to an External RDBMS
Install or upgrade to v15.3 or later. This release has optimised the performance at the MFD by loading only the required number of results needed for a request. The 15.3 update leads to considerable improvements in the loading time of a large number of shared accounts. The workflow has been improved to rely on the databases ability to sort and order large collections of data rather than perform these operations in memory.
When using Shared Accounts, the account list is downloaded to the Desktop Client from the PaperCut server if the list on the server is newer than the version the Desktop Client has (i.e., new accounts being added). This download is triggered in response to a print job. If the accounts list is updated on a regular basis, then this could lead to a delay in the client experience proportional to the number of accounts in the system, and increased network traffic during every print request.
While the list is in a compressed format, it can be a beneficial when dealing with 10’s of thousands of Shared Accounts to load this client list from a file shared on the network. The file approach is beneficial if you have a lot of clients on the network, instead of each client calling the database and querying the Shared Account list the call is made once and a file is created with the Shared Account list. You then configure the PaperCut client to watch this file instead of the main PaperCut database. This file can be distributed to remote sites as well to save traffic over a WAN link. This file creation can be scheduled so the account list is updated as often as the customer requires. We discuss the client file in more detail in the manual here: Managing Large Client Account Lists on Distributed Sites The additional benefit of this approach is that the PaperCut clients will import an updated file into the client before a print job is triggered, reducing the wait time for the user.
Inside Info - If the shared file is not available for some reason the client falls back and queries the database directly.
Please note - There is a minor limitation of using the client account file method. When the account selection popup is used, it will display all shared accounts regardless of user permissions. No need to panic, the PaperCut server still enforces the Shared Account security so users can only charge to the accounts they have permission to access.
Any successful deployment will require careful planning. The following documents should put any install off to a good start.
If you have additional questions, then please do not hesitate to get in touch with our support team.
While there is no right or wrong way to setup Shared Accounts a popular method is to use a parent and child structure as per the below screen grab.
Having the name and the code make searching for a Shared Account in a list much easier.
If we send a print job the client will display all Shared Accounts I have access to:
I can then filter this list by using the search box, in this example I searched for 2222 and it returned two sub (child) accounts that contain 2222 in their code. The client will also display the top level (parent) account so you can be sure the correct Shared Account is selected.
Note - If Shared Accounts are imported then the structure is often dictated by the source. Be sure to clean up the source before import.
There is a multitude of options for moving Shared Account lists between PaperCut and other sources. Out of the box (and via the intuitive Admin UI) there are options to import manually a file, as long as it is in a tab delimited format. The Admin UI also allows you to synchronise against a text file or a folder/directory structure; this is useful when a 3rd party application is creating the Shared Accounts you wish to import.
Taking the import a step further it is possible to use options such as SQL Server Integration Services (SSIS). Integrators can write custom SSIS package that takes their accounts lists (be it a CSV file, file structure or any format from any other database system). The SSIS package then calls the PaperCut XML Web Services API to perform checks so it can:
- Import Shared Accounts (often new accounts)
- Delete unneeded Shared Accounts
- Update existing Shared Accounts
At the same time, it is possible to directly query the papercut database to help with this process.
It is possible to achieve this without using SSIS, for example, an .exe file or PowerShell script would give you much the same results. SSIS is a good option as it allows some control over the scheduling of the updates (perhaps they need to be every 15 minutes or only out of hours)
All the tools (API, server commands etc.) available work in a similar fashion. The Web Services option can be more responsive when running in parallel and has the advantage of not needing direct access to the PaperCut server file system
Regardless of the import option used it is vital the source data be in a format that PaperCut understands before it is imported, this may involve some manipulation during export. Other things to be aware of include; No two top level or sub-level (parent / child) accounts for the same top level Shared Account can have the same name. If there is to be a parent / child structure, then this must be explicit in the source data before import.
Pro Tip - Remember to set IP address level security and Authentication tokens when using the XMLWeb Services API.
Our ASC network has written many 3rd party connectors that have taken data from all kinds of places and used it to create usable Shared Account data. Some examples include AD, Exchange, Sage, SQL, Oracle, Access, Excel, PostgreSQL, flat files, AS/400, Web Services . Contact an ASC