Run Import Config on document tray documents?-1523041099

Hey all,

One of our accounting clerks scanned in 16 scanner trayfuls, at about 70 pages per, for a total of around 70 documents and over 1100 pages.

She did not have Auto Identification set as her import config, so everything went to her Inbox.

I told her no problem, I'd just download the documents and run them through an Import job. Didn't work. Documents did not split out correctly. Three or four would properly split (I used direct identification instead of Auto ID because these were all invoices), but then the last document would actually be 4-5 documents all in one, not having properly split on the barcode page.

So I tried DocuWare Printer. Didn't work. I got a resource error when printing from PDF-XChange, plus I do not know if DocuWare Printer allows choosing of an import config anyway. If they just ended up back in my Inbox, I would not be any further along.

Finally, I just stored the documents from the tray, but that just stores the whole scan job as one document. Is there no way to choose an Import Configuration from a document tray document to use as a storage mechanism? What is "Store automatically", then?

In summary, I feel pretty stupid that I cannot figure out a way to reliably get documents from a document tray into the proper file cabinet, splits and indexes intact. Now the clerk needs to re-scan in over 1100 pages of paper.

Can anyone think of why an Import job failed so miserably, or does anyone have ideas to better handle this in the future?

Finally, has anyone brought up the idea to auto-lock import config on "Automatic identification", or at at least an option to make that the default? I have no control over that, and it will blip back to the first thing in the list (Inbox) with no rhyme or reason. It is one of the most maddening (and error-inducing) facets of Desktop Apps. If I could force it to always stay Auto ID I would have solved about a dozen fiascos that have happened to us in the past six months (including a stretch of 60 days where our production scans all went nowhere and they didn't know about it until someone finally said, "Hey there are no production documents since Christmas!"). All could have been fixed by "Automatic identification" staying persistent in the Scan app.

Thanks,

Joe Kaufman

Joe,
There is no Import configuration that can be run from a tray. Automatic storage allows you to select a number of documents in the tray and store them in a batch in to the file cabinet that is the default for the tray. Of course they need tov be pre-indexed.
I don't think there is a way to stop the user from selecting another import configuration or just their inbox. It is a worthy suggestion under the circumstances.
In my experience, a configuration that generally works and suddenly fails can be caused by the configuration being created at say 300 dpi, and the user changing their scan settings to say 200 dpi. That will cause huge problems for the OCR.

Phil Robson
Senior Director Support Americas

Phil,

Thanks for the reply. The documents are exactly how they are usually scanned (all 300 dpi), and had she been using Automatic identification they would have gone to the correct file cabinet, split and indexed properly. Our barcodes been working for months without a single failure to ID, split, and index -- it's bulletproof. So, all I can think is that when the documetns are saved as PDF that things like margins and spacing change just enough to throw off the import. However, I do not fully understand how much the OCR process depends on the scanner and how much depends on the VintaSoft barcode-reading engine. The lack of splitting (and the fact that it was sporadic -- I could run the same PDF through Import several times and get a different number of split-out documents every time) reminds me very much of the issues we had early on until I discovered the "ExpectedNoBarcodes" setting in the VintaSoft file and all errors stopped.

But I have the same VintaSoft settings file on my machine as everyone else. That's why I am guessing when an Import job tries to use an Import Config it is depending on pure software to look at barcodes rather than the hardware/software hybrid that occurs when a job is scanned in and uploaded directly to a file cabinet. I don't really know the detailed mechanics of that, though.

Thanks,

Joe Kaufman

Actually, once the scanned document is delivered to the jobs folder,it is processed basically as if it was an import job.

See this graphic on the desktop architecture.

Phil Robson
Senior Director Support Americas

https://www.docuware.com/sites/default/files/forums-images/Architecture.png

Joe,

I suggest you try to run the Import job against the downloaded PDFs on the scanstation itself - even if result is the same, it would eliminate many things as the problem cause.

Also I suggest you push Docuware hard enough so they make possible running Import Jobs from Trays. This functionality used to be available in old Docuware version.

I tried long time ago but did not get anywhere. 

Phil,

Then something must happen when downloading the PDF from the document tray ( downloaded all of them as a ZIP file), because I can assure you the Import job technique did not properly split the documents, while when it is done in-line with scanning it has not failed once on tens of thousands of documents over the past 4-5 months...  I am at a loss for why it didn't work, but I don't have time to analyze the files against against the Import Configuration right now... to see what might be off.

Thanks,

Joe Kaufman

Josef,
Web trays are not on the local machine. Web Trays are basically a file cabinet, and all you have in the tray is the representation of the documents. Importing from a web tray makes little sense since the documents have basically already been stored - just not in to a file cabinet. I doubt that it will ever happen. Still I might be wrong, it has happened before.

Phil Robson
Senior Director Support Americas

Josef,

Thanks for that idea -- I will look into trying that next time (scan stations do not have Import installed by default -- I kept things lite). I should probably get it installed since most of the engine must already be there if the underlying framework treats the images the same. Then, if it still doesn't work, I will dig into comparing the PDF to the Import Config when I have more time.

It is interesting that one used to be able to use an import conbfig directly from the DocuWare tray. Looking at the configuration image Phil posted, it seems like the import configuration usage is now on the desktop side, and by the time one is in the web client the Job Server takes over. I wonder if that web/app redistributionforced the removal of the funcitonality from the web-client (tray) side of things. Did it used to work in the web client tray, or were trays part of the Windows Explorer desktop client? Fascinating history!

Thanks,

Joe Kaufman

Joe,
Josef is referring to the old Windows Client and Baskets. The windows client was a C++ application that was installed and run on the workstation. The baskets were document respositories on the actual workstation hard drive. Completely different technology and architecture. It cannot be compared to the web trays, the web client or the desktop apps.

Phil Robson
Senior Director Support Americas

Gotcha. With the way things are split between desktop and web server now, I can see why documents in a tray (already on the web) cannot be run directly through a an Import Config...

Thanks,

Joe Kaufman

Joe,

the feature was only available in old Docuware Windows Client, when trays were called baskets. With those you could 'cascade' Import Jobs - Called Active Import then - from a folder to a basket, or to one of many basket based on conditions - and that basket was in turn monitored by another job, pretty powerful, you could do multiple separation and even simulate in Docuware Fortis-like 'Folder" level index fields.

Unfortunaltely, with webclient it's no longer available,  Technically impossibe? but if you can download a document from a tray into a monitored folder, why can't it be done by a client-based DesktopApp program.

On top of all tha great fuctionality from before I really miss, here is a new use case. An office with no servers - everything including Docware is in the Cloud, only client computers, printers and copiers, and no servers means no network shares, so the scanning is done on copiers to Docuware-Online FTP folders. From there is automatically moved to trays. No import possible. IntelligentIndexing is surely great, but what about document separation? 

Yes, an office that has completely commoditized computing to use "dumb" scanners (as opposed to scanners hooked to a smart desktop client) is a good use case for why processing documents (fully) on the web would be nice. Would be quite an architecture change, though, to include that sort of processing on the server. I'd also worry about scanning consistency when using copier-based scanners. Hard to beat the consistency of a desktop scanner.

Such a company could devote a single workstation to an industrial scanner and people could just drop off packets of bar-coded materials, ready to go. But that is where another weakness of DocuWare's identification and splitting comes into play -- splitting does not work if you mix different document types onto one batch of scannables -- it won't do a split AND auto-ID at the same time. I figured that out as one of the first issues coming from Fortis (which does handle that situation), and we are just lucky that we don't do much of that any more...

Thanks,

Joe Kaufman