This content has been marked as final. Show 11 replies
As per official documentation....
"The Priority and Status options allow you to attach special information to a batch. You might want to alert other users about a particular batch, by assigning it a high priority number (from 1 to 10, where 10 is the highest priority.) Or, you might want to assign it a status of RUSH or type in a new status.".
So, as such changing priority value of the batch actually has no impact on when it would get processed by any of the ODC utilities.
Better approach for you might be to execute "Urgent" batches in a separate Commit Server every minute and "Non-Urgent" ones in another Commit Server every hour.
As from the same Commit Server, the job execution will pick up all the indexed batches sequentially, irrespective of the priority.
Hi jiri.machotka ,
But the issue in this case is user should wait in indexing window till the indexed document get disappeared from the window. Since we are having more than 10 pages (Not all the time) in a particular invoice, it takes long time to commit.
Any workarounds for this issue???
Edited by: Nir on Jan 30, 2013 12:56 AM
Well, Capture has its pace, and you can't expect it will go faster if you go one or the other way.
Commit Server (as a Windows service) runs in a batch mode - processes all the documents in a batch one by one. Manual indexing allows a user to process documents in an arbitrary order. But you can't expect to achieve a better result than processing one (large or small) document.
Btw. to your other question: I don't think it is possible to install Commit server more than once in a single Windows instance. You could go with virtualization here, or more physical servers.
P.S. would you mind sharing more details what is your use case for such drastic time requirements?
Thanks for the reply...
We are using this SW to index our day to day AP transactions. Our AP data entry team has more than 900 invoices to enter for a day. (some times more than 1200)
Then they have to process the images very quickly and cannot wast any single minute.
Even though we introduce this method, they will complain that they are having waiting time.
That's why we were also went for the commit server.
Let me recap: you have a simple processing like
1. scan a document (or batch of documents)
2. index it
3. process it (where?)
and you have a problem that there is a time delay between 2. and 3. (how much in average?)
If that is true, can you somehow skip 2. and do indexing as a part of 3.? Do you use features like OCR/data validations, etc. in 2. or is it just manual filling-in data? If the latter, I can imagine that you could use the app that you use for 3. (is it Imaging?)
Btw. you have also an excellent opportunity to suggest process automation so that as many invoices as possible is processed in an automated manner. It might be more expensive to implement, but it will save time/money during operations. Note that automation might require process changes (e.g. introducing barcodes), but in such a quantity it will pay off.
Hi jiri.machotka ,
Yes as you said those are the three steps we are performing.
In current process, batches will be sent to the commit server after manual batch indexing . Commit server runs in scheduled time and process the batches and send those batches to IPM.
If we directly commit those batches without using commit server (now once the user has indexed images will suddenly disappear and shows the next batch) it take 15 - 40 seconds for a particular batch.
This waiting time should be avoided.
We tried OCR but due to low quality of the some of the images it is not working properly..
Thanks a lot for your valuable suggestions.
It seems that you don't use ODC for anything you could not do elsewhere.
It is just an idea, but I'd recommend you to take a look at IPM's Input Agents - see http://docs.oracle.com/cd/E23943_01/admin.1111/e12782/c09_input_agents.htm#BABBCBIC
The idea is to remove the delay between 2. and 3. - note that you will replace it by another delay between 1. and 2., which can be even bigger, but this delay should upload several document to IPM, so your users will have enough work to process before another batch comes. Also, you will have to move indexing to IPM (images will come with a very limited set of metadata, and users will use IPM, not ODC to fill other metadata in).
Don't worry - I'm more think aloud, so it is more a hypothesis than a solution.
You write that
We are using ODC to Index the documentsWhat exactly does this mean? If it means that a user types in metadata values, then you could take a look whether those metadata are needed for the item to be checked in (like the mentioned security group), or whether it is "other" metadata (e.g. supplier, invoice number, etc.) that you could, in theory, fill in in your application in IPM - imagine that you use IPM to check in the document and all you have is a TIFF.
Btw. you also write that
(we) use Input agent to sent documents to IPMI thought that ODC (Commit Profile) does this work for you, or not? If you use ODC to commit to a disk, and Input agent to get it from a disk to IPM, how about using a direct commit profile to IPM?