Joe Kaufman Bell Laboratories Inc No longer there

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

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

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

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

Hey guys,

Great tips, and that is what Chris from DocuWare did -- he got back to me FAST. I now know about how IIS links in to all this, and Chris changed a GPO setting related to a problem with a deleted registry key error. Now everything starts and stays working, and our desktop apps are funcitonal again.

I will research more from your posts, too, so that I have more troubleshooting skills in my arsenal... Thanks much!

Joe Kaufman

Hey all,

Support ticket is in, but I am looking for any help ASAP.

Server room had some issues this morning, but now everything is back up. DocuWare web client works fine, but when scanning Desktop Apps stops at the point of upload and says no connection. Delete the connection, make it again, looks fine, next scan says no connection. I have several "In progress..." jobs that just sit there, and I don't know how to clear them. I even uninstalled all of DocuWare (including deleting the Program Files and ProgramData folders), reinstalled, same issue. Company-wide. All scanners are dead in the water.

I rebooted the DocuWare server, still no luck. BP server starts but then stops immediately, so I do not know if that has something to do with it.

When I try to create a connection in desktop apps now it says username and password are invalid. These are the same credentials that work for the web client. How is that possible? Authentication should use the same creds.

Really need a lot a help really fast over here.

Thanks,

Joe Kaufman

Casey's idea is a good one, and Quick Copy can operate on multiple documents at the same time. If index fields are the same in the destination file cabinet, indexes will copy over, too. Then you could use a index change on multiple documents in the destination to set them to whatever they need to be in their new home.

Incidentally, Folders are sort of useful in this regard. If you make a Folder that displays all the documents you want to view, you don't run into pager limits. That is, a Folder result list will return all the documents that match, not just 100 at a time. That can be a problem if Folders are not defined strictly enough (it can take a loooong time to load 30,000 results, for example), but in the scenario where you want to see many documents all at once, it can be useful.

Folders and Quick Copy are going to get you quite a ways toward your desired result, everything except changing the indexes once replicated documents are in their destination file cabinet.

Incidentally, you could do all this via the Platform SDK if you have any folks competent in C#/.NET...

Thanks,

Joe Kaufman

One more (hopefully helpful) response on this... Here is the comment section of the Foxpro subroutine I wrote to run free queries via URL integration. Covers some of the experiences I have had doing integration queries:

===========================
REMEMBER! Field names in queries are case sensitive! Field names (in the database) are usually ALL CAPS. The actual database field name of a field can be viewed in the DocuWare Administration desktop application. Queries place field name in square brackets and the value on double-quotes. Though, for numeric fields,  the quotes appear to be optional. Operators can have whitespace around them. Here are example query expressions:
    
[DWDOCID]=123                                       && Query by the internal document ID.
[CUST_NO] = "WA60"                               && Query field "CUST_NO" to exactly match "WA60".
[LASTNAME] LIKE "K*"                             && Wildcard search.
[SHIPTO_STATE] = EMPTY()                   && Query SHIPTO_STATE for empty values.
[BILLTO_STATE] = NOTEMPTY()             && Query BILLTO_STATE for non-empty values.
[DocuWareFulltext] = "find this string"       && Full-text search.
[DWSTOREDATETIME] > 2017-06-14 19:45:31              && Date/time expression.
[START_DATE] >= 2016-06-01 AND [START_DATE] <= 2016-08-01    && Boolean conditional.

Expressions can be joined by AND or OR and can be qualified with NOT. Delimiters around string values MUST be double-quotes. Also, the conditional statements and compound keywords (e.g. LIKE, AND, OR, etc.) need to be capitalized as well. If multiple documents are found, a result list is displayed in the browser. If only one document matches the search, it is directly displayed.

*** SPECIAL NOTE WHEN USING DATE/TIME FIELDS ***  Date/time fields are stored in DocuWare as UTC timestamps. While queries in the web client or Platform SDK allow the use of local date/time formats, URL Integration queries appear to use the date/times passed in as-is and compare against the stored UTC timestamps. So, if you are using date/time fields in your query, the date/time values need to be converted to UTC to get accurate results.
===========================

Thanks,
Joe Kaufman

Casey,

You are not confused, our processes are just very foreign to Workflow because we have never used Workflow (or any sort of "real" ERP integration) before. We have two types of documents in the system right now, primarily: scanned in stuff and then documetns for this new area that wants to play with Workflow. The former documents are catch-all. An AR invoice document has everything in it because it is scanned in when the order is done (we have a sales order system that handles data entry, approvals, notifications, fulfillment, etc.). We also have a PO system that handles approvals, thresholds, etc. etc. 

The latter documents, though are going to be more Workflow-y (at least I think they will) coming in from emails and other manual uploads. Like a query from a customer about technical services. Every customer inquiry needs to be addressed -- think helpdesk system. So, if they are asking about SKU 12345, the system will have lots of information on item 12345, and we can link file cabinets to the customer's query. That query then will go through various stages of approval and even adding data to the document (not sure if we will use versioning or not) until the query is resolved.

There is no document that we will not want to process because the query sets off the Workflow every time. I do see what people mean in that surely some aspect of the query means it will route to one place or another, but I am not sure that will always be the case. They may need to all route through a single tech info specialist to be (human) intelligently sent to the right spot in a secondary Workflow step. I am not entirely sure, as we are letting that department figure out Workflow enough to see if it is what we need or if we can just get by with Task Manager (notifications are the first main thing we need).

Like I said, you aren't confused, you are more likely in Kyle's camp and would simply find our processes "cumbersome". And I wouldn't argue with your opinion on that except to say it isn't cumbersome for us and is dictated by not ever having had anything like Workflow or a fully integrated ERP system in the past. And that's why I asked about "always on" triggers in the first place.

Thanks,

Joe Kaufman

Kyle,

I shouldn't have lumped consultants in there, at least not in the way I meant, so I am sorry about that (if that is the camp you fall into). But I will say I know most end-users need help with things like normalization and data design. I am not going to apologize for saying I am "better than" most end users at that -- because I am and should be; it is my job to be. And from the experience side, we do have one area where we are allowing a department to build their own cabinets and flow, and we have already seen spots where things are not constructed in a way conducive to scalability and ease of use.

I am not stuck in any mindset -- certainly not a Fortis one -- because DocuWare is MUCH better than Fortis as it does away with all the complexity of database locations and document types. After converting to DocuWare, I will never understand why Fortis over-designed in that way (though it does do two things better than DocuWare: identifying scan sheets and complex linkages). As far as our processes being cumbersome, it is the way we run our business based on the requirements leadership dictates. We can't have a single page mis-scanned and we can't have a single document go missing. How is it "cumbersome" to have a system in place that assures that? How do you assure it for your company (or the companies you consult for -- I am not sure if you are an end-customer or a reseller/consutant)? Are you saying nothing has ever been wrongly indexed or had a page scan in badly that gets missed? What sort of processes do you have in place to make sure every closed PO or AR invoice has all materials properly on file in DocuWare? Is it because every piece and part is part of a Workflow and so must exist by definition? That is fine, but understand we don't have Workflow yet (this is just a trial) and implementing Workflow for all of our processes would involve an entire ERP implementation -- we aren't there yet. That's not due to my mindset, it is due to where the company is at as a whole.

As I concluded in my previous post, I am not saying our way is better or anything like that. It is the way we do things, and is the reason I wondered about a catch-all trigger in the first place. I do realize that a full embrace of Workflow would completely change the way we we flow documents and could very well make all of my questions moot, but I am still going to ask so that I can help the people testing Workflow understand things as they are learning. I want to be proactive on that and stay ahead of whatever direction they might want to go.

Nothing personal against you or anyone else, and it was not my intention to sound "right" or "better".

Thanks,

Joe Kaufman