Development Mindset when utilizing ILINX eForms

Those familiar with software development should know the Waterfall software development methodology very well. For those who don’t, it’s basically this:
1. Perform discovery/gather requirements
2. Build out the solution based on the requirements provided
3. Perform User Acceptance Testing (UAT)
4. Correct issues found during testing and resubmit for UAT
5. Repeat steps 3 and 4 as necessary
6. When the solution is accepted, prepare to move it into Production and do so
7. Support as necessary post-Production deployment

As a rule, we try to stay close to this approach when working through customer engagements, and regardless of the product we’re implementing it usually works very well. Continue reading

Exporting Records Using KTM Medical Claims Add-on & Kofax Export Connector

Kofax provides an add-on pack for their Transformation Modules product to handle CMS-1500 (formerly HCFA) and CMS-1450 (alternatively, UB-04) medical claims forms called the KTM Medical Claims Add-on package. Related to this package is the Kofax Export Connector for Medical Claims. This Export Connector allows for the data captured off of said forms to be formatted in the HIPAA-compliant EDI/ASC X12 837 formats (to be exact, 837 Professional for the CMS1500 and 837 Institutional for the UB04).

Continue reading

KTM TDS Model Building

Are you tired of separator sheets?  Tired of wasted paper and countless hours of flipping through pages and inserting a barcode sheet at the start of a new document just to take it out after the batch is scanned or leave it in the batch and have more paper to store?  Why not have the computer do the work for you?  That’s the idea behind the Project Planner module in KTM.  There is a standard separation functionality built into KTM that works very well on structured and semi-structured documents but when you have more complex separation rules the Project Planner component of KTM is what you need.

Continue reading

Kofax KTM Dictionary Gotcha on Dates

In KTM there is a nifty feature to search the entire document for a date field. It will recognize all dates existing on the form and with some other snazzy logic you can find the date you are looking for. If it is nearby the word “recieved”, then you probably have a recieve date. Easy, right?

Okay, sometimes dates get a little more tricky. “3/17/2011“, “3-17-20011” and “MAR 17, 2001” are all valid date strings. Any of those formats could be found on your document. In KTM there is a nifty feature to search for the string “MAR” and replace it with a “3” when searching for dates. You use it in your locator’s regular expression. You can setup your own dictionary of months to look for “March” or “Mar” (or “Marzo” if you need internationalization).

Here’s the gotcha. I recently found text in an OCR’d document like this: “19 NOV2008“. It’s a bit of an odd string. The OCR engine didn’t think there was enough space between the “NOV” and the “2008” to put an actual space character in the ORC’d text. So, I can read it, but KTM can’t. The nifty feature to search for the string “NOV” fails because it is only looking at whole words, those with whitespace on either side. Unfortunately, there is no option in the KTM dictionary setup to change this.

Here’s the fix. Modify the default KTM regular expression from this:

[0-3]?\d§English_Months_Abr§([12]\d{3}|\d{2})

to this:

[0-3]?\d\s*(jan|feb|mar|apr|may|jun|jul|aug|sep|oct|nov|dec)\s*[0-3]?\d

You can now make the space character optional in your regular expression search. You are no longer using the month dictionary, but that’s okay. This logic is only to locate a date, not translate it from a string to a date when found.

Problem solved.

 

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

Kofax KTM for Invoice Processing

KTM for Invoice Processing.

The Kofax Transformation Modules is an excellent addition to the Kofax Capture family when processing invoices. The product is able to “Read” the major invoice values from the invoice image accurately and with confidence. It has the ability to “Learn” where on the invoice image the values are located so its accuracy can be increased over time.

The major invoice values that KTM can read and “Learn” out of the box are:
Invoice Number
Invoice Date
Order Number
Subtotal
Tax
Shipping/Freight
Handling
Total

The accuracy out of the box is very low since the software needs to be “Trained” on sample invoices to learn where the values are located. It does this by layout classification so it can handle different vendor’s invoices and learn to accurately read the values.

In addition, there are lots of options for the builder of the Project to help the extraction of the values. These options include objects like Locators, Formatting, Key Word matching, and Validation. Through a combination of these options, just about any invoice can be read and processed with little user correction required.

However, it takes a lot of work to “tune” the Locators and Key Word matching to get the initial accuracy to as high a rate as possible. This is more an art then a science and therefore requires a person with intimate knowledge of KTM and all it’s abilities. Also, knowledge of basic script programming is required since there are things that cannot be done by KTM otherwise. ImageSource can provide such people that have the knowledge and experience to “tune” KTM to be as accurate as can be done with the current OCR technology.

Chris Hillenburg
Sr. Systems Engineer
ImageSource, Inc.