ssumic
1 Nickel

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

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!

0 Kudos