Ask the Expert: EMC Captiva 7.1 Further Enhances Intelligent Enterprise Capture Capabilities

This discussion is now open for questions. We look forward to a lively and informative event.

Best regards,

Roberto

Hello,

eInput currently supports Internet Explorer 9 only.

Current IE version is 11. This renders eInput practically useless for serious business, and pictures Captiva as almost obsolete platfrom (at least for Web scanning). When will this be addressed?

Best regards,

Stipe Sumic

Hello,

in IndexPlus I have used FilterBatchList event handler to filter list of available batches based on certain conditions. How can this be accomplished using Captiva Desktop?

Here is the scenario why I need this:

I have two Captiva Desktop steps in capture process. First step is "Indexing" and second step is "Control". I have group of operators that can't be divided into separate groups or departments (explicit requirement from customer is that "everyone-can-do-everything").

I need to prevent user that has performed "Indexing" from performing "Control" of the same batch. Previously, with IndexPlus, I used to append "indexing" user name to batch name after indexing, and used that in "FilterBatchList" script to prevent "Indexing" user from seeing that batch in "Control" list.

How can I achieve this with Captiva Desktop?

Thanks in advance,

Stipe Sumic

Hi Stipe,

I'm not at liberty to commit to future functionality that's not on the published IIG roadmap, but I can assure you that we are well aware of this issue and hope to be able to announce positive news soon.

Regards,

Justin

Stipe,

The challenge as you stated is with ensuring that operator #1 is not presented with the same item twice - this is typically required in a true 'double blind keying' scenario for example where field accuracy on certain fields is desired to be the highest it can be by certain customers. We have ran across this. I will be back to you here shortly with our suggestion and\or thoughts on this! Appreciate the great question!

Hello @James,

many thanks for your answer. The longer e-mail that you sent me is not visible here, so I will copy it. Please see my comments in italics.

Stipe,   Great question - thank you! We too have ran across this 'challenge' ourselves and do have a method to suggest. In InputAccel 6.x, what EMC was trying to accomplish with the “FilterBatchlist” was to limit batch access to operators who had the permissions or limit batch access to batches that matched a certain criteria. In Captiva 7, this is still possible but in a different manner.  Instead of directly affecting the batch list (like FilterBatchList did) you now give the operator the batches they have access to from the start.  This is done with departments.  With the example you described, using departments would be possible because departments can be set dynamically during run time. So for example, your user just finished keying a batch that was read in the “Indexing” department.  What would happen next is that the same batch would have its department changed to “Control” during runtime. This means you would end up with a batch that went from Indexing, to Control, just what you needed. Dynamic departments existed in IA6.5, however, they can't be used to fulfill my requirement. Let me explain this a bit better: Let’s say I have 5 operators; A, B, C, D and E. ALL of them are members of both „Indexing“ and „Control“ groups/departments. This is requirement from the customer, because they move operators from “indexing“ to „control“ very frequently (once or more per day), depending on required workload (advanced, lean-office principles ). So, if operator B performs indexing, he can also open Captiva Desktop with „Control“ department, and perform control of the document. In IA6.5 I used FilterBatchList to hide specific batch from user B in "control", In Captiva 7.x, I no longer have such possibility. Theoretically, I could have departments such as „control_without_user_A“, „control_without_user_B“,„control_without_user_C”,... but this is practically impossible, because we have ~30 operators, and they change over time. Maybe there is some other solution, but I can't see it at the moment... There is another customer’s requirement that I have solved by using FilterBatchList in IA6.5 (the requirement may sound funny at first, but it comes from real world… ). Namely, operators used to pick “tidy” batches (mostly printed with laser printers), and used to open&close hand-print filled batches. They did this becuse "tidy" batches are well recognized by OCR and require significanly less typing. So, we have created a mechanism of “locking” the batch, by appending operator’s name to batch name as soon as it is opened for indexing for the first time. Operator is allowed to cancel or exit the batch, but it is now “locked” for the operator, i.e. no other operator can see it (due to filtering performed in FilterBatchList event), and the operator that opens it for the first time MUST execute it. How could I achieve this functionality in Captiva 7.x? Also, a little bit more of information for you - in Captiva 7 EMC has expanded access limitation even more.  In 7 not only can you limit what batches an operator can access, but you can also limit what they can access from that specific batch. What this means is that once an operator opens up a task you can limit what they see.  Maybe you have an operator that should only be checking the image quality, then you can show them just the image and none of the fields. Maybe you have an operator that should just be keying what they see, then instead of showing them the entire image you show them snippets of the image. I agree that this is a welcome improvement. Hope that helps! Keep the great questions coming, this new version has some differences in method and\or approach that take a little getting used to at first. However, once you get a chance to work with it enough the improvements are clearly visible and pretty significant in most cases!

Stipe,

Sorry about the mix-up with the other post that 'disappeared', that was my mistake on the first send last night. I realized immediately after the initial post that you were in fact looking for something much more complex and thought the post delete worked before it was published - clearly not the way the forum posting mechanism worked

Thank you for the more thorough explanation regardless as that was very helpful and will be to others who read this.

So... I spent time talking to our staff today more in an effort to find out the latest and the greatest with their efforts on this challenge. Unfortunately the latest is that there is no current way to do what you are asking for in the current Captiva 7 Desktop release that we are aware of. Although the use of Departments does bring some nice features as we have both commented on, it does not help in the scenario you described so well where an operator has 'dual roles' with the condition determined dynamically. The use of a 'control indexer' is definitely something we do run across from time to time as well most always in the scenario described earlier with the 'double blind keying' requirement.

What we ended up doing in one of our EMC Certified Solutions (DepositCritical) where the double blind keying is typically always required for critical fields where 100% accuracy is desired is we ended up using the Captiva 7 SDK to build a custom user interface index module that has the ability to utilize onstart and other methods to provide the filtering that you are describing. Thankfully EMC does a great job in providing access to pretty much everything to their SDK and regularly encourage Partners to fill those 'gaps' for very specific and unique end user needs like the one you are describing here (since it seems like we only have this come up once in a awhile with only certain customers).

Thanks again for the great post - I will let you know if we end up finding some sort of other work around for this other than SDK development in the near future!

Stipe,

James is right.  I looked into this as well since yesterday and determined that there is currently no FilterBatchList and I have not come up with a way to address your use case.  Also, it seems you're not the first to ask about this, so I think we need to consider addressing this use case for Desktop. It seems part of the reason for not providing scripted filtering of tasks was to prevent customers from getting into a state where batches with work cannot be processed because (for whatever reason) they are always filtered out of the list.

Can you confirm, in IndexPlus you were triggering at the Batch level?  Do you have a use case where Desktop needs to trigger below Batch level but at the same time you need to implement a non overlapping verification step?  Also, I assume you wouldn't have a problem with configuring a "mutually exclusive" routing pattern in Desktop vs a script like you did in IndexPlus.

Figured it might be good to post a few best practices this week as well - hope this helps someone out there in their day to day endeavors!

Part of the Captiva 7.x experience is figuring out how the new modules work and how to try and avoid errors.  This is something that I can personally say we spend countless hours with and I want to discuss one error in particular that we may not necessarily help you to avoid it altogether but will help you tackle it quickly when you encounter it.  This is something that we discovered the hard way, with trial and error of course.

In Captiva 7.x we have a new module called Extraction that replaces the Dispatcher Recognition module.  Extraction relies highly on the quality of the image it is performing OCR on.  Essentially what this means is that it is very sensitive to the types of images that it can process.  If an image has incorrect DPI or incorrect compression type it will throw an error in Extraction and cause the batch to enter an error state.  The reason for the error is because the PixTools tool that is used for image manipulation in Extraction is unable to read the input image. The error will read something along the lines of: “Error while loading image” or “PixTools error”.   Here is a screenshot of that.

Troubleshoot

Whenever you get an error like the one above in Extraction is most likely the image.  To troubleshoot it there are a few steps you can take to pinpoint the problem.  First off make sure that the input image for extraction is valid.  Here is a screenshot of an invalid input image in Extraction:

When the input image is not valid then you need to figure out where in the workflow the image was manipulated.  It could be that the image was manipulated and never updated or saved incorrectly.

Best practice/tip to avoid errors like this

When our team would get errors like the one above they started to think: How can we avoid this? How can we make sure that the image is always the correct format when it gets to extraction?  That is when they came up with a best practice that we use in our projects to try and minimize this error.  The best practice is to add an Image Converter step at the beginning of the workflow after all our images have entered the workflow.  This Image Converter step has only one job, to convert all the images in the batch to the necessary format.  I won’t specify what that format is because it can differ.

Some of you may want 200DPI images while some may want 300DPI images. It really does not matter what the format is because Image Converter can convert to your specific scenario.

For example say my project expects 300DPI images with a compression type of CCIT4.  Then all images will be converted to that format in Image Converter.  This way, when it gets to extraction it is the correct format and we avoid having our batch being set to an error state.   Here is a screenshot of that:

In Captiva Desktop, is there any way to set focus on a table field?

The data entry form is divided into groups; each table is in its own group. The first field in the first group will be the one that has focus. Based on that, the initial focus can be on the table, but only if the table is the first group (at the top of the form).  However, the scripting APIs let you find any field—table or otherwise—and set focus to it.

Are there any future plans or methods for Dispatcher 7 to OCR tables from at least 2 tables on a form image?  We've discussed a workaround is to make a copy of a classified image page node (Template1) and set the copy to a different template (Template1a) and OCR the 2nd table, then load the tables on one multipage Doc Type form in Captiva Desktop.  Has anyone ever tried this?

Hello Justin,

I apologize for late answer.

Yes in IndexPlus I was triggering at Batch level. It was good-enough for me (otherwise I would need "FilterTaskList"which was never available :)).

Is it possible to log this feature request officially to Captiva product management?

Without nonoverlapping verification, it is almost impossile for me to justify expenses of upgrade to "new and shiny" Captiva 7 modules to my customers. In adition, customers are stuck to Dispatcher Validation module which is inferior to competitive products (primarily Kofax and Datacap) and customers are aware of that.

Best regards,

Stipe