Yet another urgently needed feature in Financial Manager

A couple of days ago I posted a list of some of the urgently needed features for the Financial Manager system.  Here’s one more urgently needed feature.

It will be recalled that for most customers of the USPTO, there was no problem for which the new Financial Manager system is the solution.  There are really only a small fraction of USPTO customers who ever felt there was a problem that needed fixing, for which FM was the solution.  Basically it is the firms and corporations that don’t want to give all sixteen digits of a credit card number to an employee.  The fear I guess is that the employee, when fired, will go out and purchase some gold coins or something using the credit card number.  FM exists because some small number of firms or corporations asked for a way to conceal twelve of the sixteen digits of the credit card number from most employees, so that only one or two more trusted employees would ever actually see all sixteen digits.

Having observed this, we remind ourselves what system was being used before FM was launched.  It was a system called Financial Profile (FP).  FP worked fine for most USPTO customers.  It wasn’t broken and didn’t need fixing, for most USPTO customers.  When on a Monday morning in April of this year the USPTO launched FM, the USPTO also pulled the plug on FP.  Very abruptly, FP ceased to be available.

One of the most important features of FP was that the customer could log in once a day and could do a simple search with one or two mouse clicks, to generate a report listing all payments that had been made using any or all of the firm’s or corporation’s payment methods.  This permitted close tracking of all spending, whether for client billing purposes or as a way of catching work that had been done and that had not been fully or properly reported in normal workflow.

But then on that fateful Monday in April of this year, FP stopped working.  Customers were expected to use FM instead to generate these reports.

The problem is, FM does not permit the customer to generate a report of all payments made across all payment mechanisms.

Instead the customer is reduced to having to carry out individual searches on each of the customer’s payment methods.  Our firm has a dozen or so payment methods, and this means that each morning, one of our staff people has to carry out a dozen or so searches, each requiring a dozen or so mouse clicks.  Only after these dozen or so searches across each of our payment methods can our staff person move forward with the daily accounting and billing tasks.

With FP, on the other hand, our staff person was able to run a single report across all payment methods.  It took just a minute or so to generate the entire report.

Of course one of the supposed design goals for FM was to start by providing all of the user functions of FP, and then adding additional user functions.  But that design goal was not met.  The report generation across all payment methods got lost somehow.

Another example of an important kind of report that is needed from time to time is a report listing all payments that have been made in a particular case, across all payment methods.  Maybe one fee was paid with the Deposit Account, another fee paid by one credit card, and another fee paid by a different credit card.  In FP it was just a matter of a few mouse clicks to generate a list of all three payments.  In FM, on the other hand, one must individually carry out individual searches in each of the payment methods.  For our firm this means twelve searches, one for each of the dozen or so payment methods in our system.  About 150 mouse clicks instead of three or four mouse clicks.

If the FM system had been appropriately beta-tested, this loss of the important FP functions would surely have gotten noticed much earlier in the FM development process.  Instead, the FM system got formally rolled out for all users without meaningful beta-testing, and the plug got pulled on FP.

More than two months ago, I pointed out to the USPTO the urgent need for the restoration of these report generation functions.  They are still not available in FM.

As one staffer in my office correctly observed, there are fundamental design decisions (perhaps best characterized now as fundamental design mistakes) that help to explain why these reports, so easy to carry out in FP, are not now provided in FM.  In FP, the payment methods were tied to the organization.  So long as an authorized person from the organization was logged in, the authorized person could carry out the generation of a report across all of the organization’s payment methods.

Instead, the database design for FM seems to have nothing tied to the organization itself.  Instead, the database design is apparently built upon a collection of individual databases, one for each of the possible payment mechanisms.

Given these (unfortunate) design choices, it may not be a realistic goal at the present time to do a transaction search across “all payment methods connected my organization”.  But it is within the ability of the USPTO to permit the user to carry out a transaction search across “all payment methods with which I am personally connected”.  And USPTO needs to do so.