Indexing Tables in Kofax-Based Environments

We recently had a customer who needed to migrate off of an aging and highly customized Capture/indexing/workflow one-off solution. At the center of many of their form types in this system was a repeatable field collection object that functioned much like how you would expect a .NET DataTable control to function – values could be added horizontally to the current “row”, and at the end of it you could hit enter and a new “row” would be added. As you moved through, you also had the ability to validate the line item as a whole. In other words, nothing too out-of-the-ordinary.

Unfortunately, this stood out as a red flag for both myself and my coworker when we first saw it, since we were migrating the client to Kofax Capture. There’s nothing inherently wrong with Kofax’s flagship product, in fact it is an excellent tool for getting content where it needs to be, often in record time. One thing it doesn’t do well out-of-the-box, however, is table fields. Defining one looks normal enough, but when you actually get the chance to index them, each column ends up being a standard index field. Needless to say, turning the table 90 degrees counter-clockwise and forcing keyers to manually delimit values is not an ideal experience, especially when 99% of your form is tables that need to be indexed. Continue reading

Using C#.NET with the Kofax KTM Validation Module

Introduction

My current project has a requirement to do several Oracle EBS validations and lookups from the Kofax KTM validation window. For example, one requirement is to present the validator with a list of Suppliers. Another is to check for a duplicate invoice number in EBS. I can easily add additional methods as needed.

Kofax KTM provides Win Basic scripting language that can accomplish some of this, but it’s difficult to use compared to modern programming languages. After a little research I discovered it was feasible to create and call methods in a COM object from KTM Win Basic. This meant I could expose a C#.NET dll via COM Interop but have all the power of any version of the .NET framework and Microsoft Visual Studio available to do the heavy lifting.

My C# methods return either arrays or booleans back to KTM where I then use the Win Basic language to present results to the validation user. I can debug my C# code by attaching to the KTM Project Builder exe while running validation tests.

Setting up the C# Class

The first step is to create a project in Visual Studio and set up a class to contain the methods you will call in KTM. The prefered method is to use interfaces in case you need to change the methods without breaking the inferface. Here is an example. Continue reading

Kofax KTM is a Powerhouse Product

Kofax Transformation Module is one very powerful product once you learn some of its secrets.  In this installment I plan to show you two of KTM’s abilities to modify the out of the box functions, Validation Design and Scripting.

Screenshot

Screenshot

The scripting language and class object models of KTM allow you to modify how Extraction works and also how Validation works.  In the case of extraction, out of the box KTM does not recognize negative amounts as in the case of a Credit Memo.  In order to allow KTM to recognize negative amounts requires the use of a script function.  This script is listed in the HELP documentation and is simple to add.  It performs the original function of validating that what was extracted from the invoice is indeed an amount and it also validates the amount if the negative sign is present.  Another example is during extraction, an amount is not considered valid if it consists of just a decimal point followed by 2 digits, such as “.75”.  A lot of invoices are printed in just such a fashion if the amounts are only cents and no dollars are involved.  A script of only one or two lines of code is then used to force KTM to recognize the value by adding a zero in front of the decimal point to form the amount of “0.75”.  In this manner scripts can be used to add additional validation of the extracted values and to modify the extracted values if necessary.  This also applies to field values that are not extracted as we will see in the discussion of Validation. Continue reading