Joe Kaufman Bell Laboratories Inc No longer there

Raymond,

It looks like you don't have the extension methods for the FileCabinet object (of which UploadDocument is one).

Did you install all the proper NuGet packages so that your .NET solution has the DocuWare assemblies? That is where the extension methods reside, namely:
 

​​​​​​​​​​​​​​namespace DocuWare.Platform.ServerClient
{
    public static class FileCabinetExtensions
    {
        public static Document AddDocumentSections(this Document document, params FileInfo[] file);
        public static Task<DeserializedHttpResponse<Document>> AddDocumentSectionsAsync(this Document document, params FileInfo[] file);
        public static Section ChunkAddSection(this Document document, FileInfo file, int chunkSize = 0);
        public static ImportResult ChunkImportArchive(this FileCabinet fileCabinet, FileInfo file, ImportSettings importSettings);
        public static ImportResult ChunkSynchronize(this FileCabinet fileCabinet, FileInfo file, SynchronizationSettings synchronizationSettings);
        public static Document ChunkUploadDocument(this FileCabinet fileCabinet, FileInfo[] files, int chunkSize = 0);
        public static Document ChunkUploadDocument(this DialogInfo dialog, Document document, FileInfo[] files, int chunkSize = 0);
        public static Document ChunkUploadDocument(this DialogInfo dialog, Document document, FileInfo file, int chunkSize = 0);
        public static Document ChunkUploadDocument(this FileCabinet fileCabinet, Document document, FileInfo[] files, int chunkSize = 0);
        public static Document ChunkUploadDocument(this FileCabinet fileCabinet, Document document, FileInfo file, int chunkSize = 0);
        public static Document ChunkUploadDocument(this FileCabinet fileCabinet, FileInfo file, int chunkSize = 0);
        public static Section ChunkUploadSection(this Section section, FileInfo file, int chunkSize = 0);
        public static ImportResult ImportArchive(this FileCabinet fileCabinet, FileInfo file);
        public static ImportResult ImportArchive(this FileCabinet fileCabinet, FileInfo file, ImportSettings settings);
        public static ImportResult Synchronize(this FileCabinet fileCabinet, FileInfo file, SynchronizationSettings settings);
        public static Document UploadDocument(this FileCabinet fileCabinet, params FileInfo[] file);
        public static Document UploadDocument(this DialogInfo dialog, Document document, params FileInfo[] file);
        public static Document UploadDocument(this FileCabinet fileCabinet, Document document, params FileInfo[] file);
        public static Task<DeserializedHttpResponse<Document>> UploadDocumentAsync(this DialogInfo dialog, Document document, params FileInfo[] file);
        public static Task<DeserializedHttpResponse<Document>> UploadDocumentAsync(this FileCabinet fileCabinet, params FileInfo[] file);
        public static Task<DeserializedHttpResponse<Document>> UploadDocumentAsync(this FileCabinet fileCabinet, Document document, params FileInfo[] file);
        public static Task<DeserializedHttpResponse<Section>> UploadSectionAsync(this Document document, FileInfo file);
    }
}

Make sure the DocuWare NuGet packages are installed, rebuild your solution, and try again.

Good luck!
JoeK

I see now the max number of shots is 10,000, so that is what I am using.

As far as resetting the full-text information, I click the "Reset" button and just use the defaults on the screen that comes up. It seems to be reindexing a lot of documents, so I think it is re-processing things appropriately.

Thanks,

Joe Kaufman

Josef,

OK, so viewing the document skews the results, which is what I was afraid of...

So, if I up the number of pages for all full-text indexed cabinets, I have the following questions:
 

1. How high should (can) I go? can I go 999999, for example?
2. How do I trigger a rescan of the text shots after I up the limit?
3. Is this going to bloat textshot data in the database and cause me storage issues? (And I mean beyond the obvious growth due to documents with more than 200 pages having more pages getting processed.)

Looks like I need to fix up a bunch of file cabinet configurations!

Thanks,
Joe Kaufman

Simon,

I did some further testing...

I found a file with 274 pages and picked one of those sticker-based numbers, slightly atilt, on page 121. Should be in between the first 100 and last 100 pages. I did a search while viewing the document, and it found the number on page 121.

Then I thought that perhaps searching for text while viewing forces DocuWare to do a quick full-text scan of ALL pages. So, I found another file with 240 pages, and just viewed a number to search for on page 103. Went back and reset the search, then searched for the number in the "Fulltext" field. It found the document and went straight to page 103 in the viewer.

Unless DocuWare immediately full-text scans any file that gets viewed, it looks like I have full coverage of all pages, not just the first and last 100, even though our default max. number of shots is still at 100. This is good news (for me), but I can't explain why other folks are stuck at the 100-page limit. I am on DW 6.11, on-premise.

Thanks,
Joe Kaufman

 

Josef,

I am a little confused by the 100-page limit... Our setup looks to be at the default 100 "shots", which the help states is equivalent to 100 pages (one shot per page). But I just ran a full text search on a very specific number of our Production file cabinet (it is a sticker they stick on a batch sheet, and DocuWare does a good job of OCRing them), and it came right up with the single document in the cabinet, moving me straight to the page where the sticker was -- page 205 out of 212.

How am I finding text on page 205 if the text shots are stopping after 100 pages? Or is the 100-page limit only for an initial shot-take? Does it run a longer full-text analysis later and get everything indexed?

I never knew about this, but am now concerned, since we have full-text turned on for several file cabinets where the documents are over 100 pages...

Thanks,
Joe Kaufman

Kim,

Just to make sure folks aren't put off by the idea of single-character barcodes, I'd like to reiterate they work fine across the board as long as devices are configured for it. In DocuWare it is the setting described above, and for some barcode readers you may need to talk to support and get a special setting configured. I bought a Nadamoo USB barcode reader and had to email them about it. Overnight they sent me a system barcode I could print out and scan, and now the gun reads single-character barcodes (numeric or alphabetic) perfectly.

In any other scenario it is the fault of how the barcodes are being generated and/or the printer printing them. We use standard Code128 across the board, and I can read every barcode with my iPhone (no special changes needed), Android tablet (no special changes needed), Motorola industrial handheld computer (no special changes needed), USB scan gun (system barcode required), and DocuWare scanner (VintaSoft settings change).

I guess I would say single-character barcodes aren't just possible, they should be the norm. If it won't scan with RedLaser on an iPhone, the barcode itself is malformed and nothing will read it. Are they best to avoid or work around? Maybe, but that's not always possible. Even barcoding something like a first name means some folks will just have a single character there, e.g. just the initial.

Workarounds that work are wonderful though.  *smile*

Thanks,
Joe Kaufman
 

Kim,

DocuWare can totally handle barcodes of length 1. That's what the setting:
 

MinimalBarcodeLength="1"

in the VintaSoft settings file I posted is for. We have been handling single-character barcodes for two years now. Install a barcode reader on your phone and scan a single-character code -- should work, and should also work in DocuWare. Though, it is possible the barcode-writing tool itself does not handle single-character codes, which would be a function of your barcode generator (ours handles them fine).

Sounds like your solution works just as well, though, and lots of devices and scanner have issues with single-character barcodes.

Thanks,
Joe Kaufman

Phillip,

DocuWare stores all timestamp indexes in UTC time (like GMT). It would appear that when fields are sent out as part of a notification they come out as their literal stored date/time without being translated into any other time zone. This makes sense, as what if the email is sent to someone halfway across the world? Would you want to show the time as it was stored from a specific client location, or just treat everything as UTC so various destinations can shift accordingly?

The reason the indexes in the web client view show as local time is because all timestamps are converted back to the timezone of the one currently viewing the information.

I am curious to see what DocuWare support has to say, though, as I could see you wanting the time to be translated into some other time zone...

Thanks,
Joe Kaufman

Kim,

Hi, Kim, long time no see!

Just a bit over two years ago after initial roll-out (a Fortis migration that you assisted with), we were seeing a 5-10% failure rate of barcodes as well, on everything from splitter/ID barcodes to index fields (we use a lot of barcoded scan sheets). One of our scan sheets has something like 20 barcodes on it.

I spent two days testing batch after batch, just trying to increase accuracy. I ran across the same article you found, but it didn't go deep enough. DocuWare support was, in a word, unsupportive. They did tell me more about some of the other VintaSoft settings, but basically said don't mess with them (or gave a standard, "Well, if you do touch them you are on your own, and they won't make any difference anyway.") They were wrong.

It took me a long time to start tweaking the ExpectedNoBarcodes setting because I thought it meant that the import should expect "no" barcodes. Turns out it is just a really stupidly named parameter that means "expected NUMBER of barcodes", and it was set to 0 by default (because, remember, it wasn't supposed to have any effect on anything anyway). I also researched that the higher the number, the more it could affect performance.

The bottom line is that everyone was wrong. I upped ExpectedNoBarcodes to 99, and BAM! The next three test runs I did had 100% barcode accuracy, and the scan job did not run appreciably slower. And we have seen pretty much 100% accuracy for 2 years now. Some printers still print unreadable separator/ID barcodes (which is weird), but by and large we are chugging through thousands of barcodes a day with perfect scanning.

Below are the notes I took about the additional fields in the VintaSoft settings (with my ExpectedNoBarcodes comments asterisked):

==================

10/06/2017 - Additional information from DocuWare tech support:

TradeOff is the option which tries to bring together speed and quality. The possible values are BestSpeed, Balanced, BestQuality. In case barcodes are not recognized (especially smaller barcodes) then switch to BestQuality. This will decrease performance and increase the average number of recognized garbage barcodes. Changing the trade off can make things better, but also worse. So be careful. When changing the trade off the quality threshold should be adapted (the higher the trade off the lower the quality threshold).

All other mentioned setting should not be touched, that's why they are not included in the faq.

ExpectedNoBarcodes
Possible values are: any integer number equal or larger than zero
Default value: 0
*** Set this value to 99 to make sure the VintaSoft engine reads all barcodes on a page and doesn't stop prematurely! ***

QualityThreshold
Possible values are: 0.00 - 1.00
Default value: 0.20

ConfidenceThreshold
Possible values are: 0.00 - 1.00
Default value: 0.95
==================

Here is the full VintaSoft.settings file we use, where we have everything commented out except Code128 barcodes:

==============================
<?xml version="1.0"?>
<BarcodeSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" TradeOff="BestSpeed" MinimalBarcodeLength="1" ExpectedNoBarcodes="99" RenderResolution="300" Iso15415Threshold="-1.0" Iso15416Threshold="-1.0" QualityThreshold="0.2" ConfidenceThreshold="0.95" Erode="false" AutomaticMode="true" xmlns="http://dev.docuware.com/settings/barcode/configuration">
  <BarcodeTypes>
    <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
    <!--<BarcodeType DwBarcodeType="Code39" />-->
    <BarcodeType DwBarcodeType="Code128" />
    <!--<BarcodeType DwBarcodeType="Ean128" />-->
    <!--<BarcodeType DwBarcodeType="EanExt5" />-->
    <!--<BarcodeType DwBarcodeType="EanExt2" />-->
    <!--<BarcodeType DwBarcodeType="Code93" />-->
    <!--<BarcodeType DwBarcodeType="Codabar" />-->
    <!--<BarcodeType DwBarcodeType="Ean13" />-->
    <!--<BarcodeType DwBarcodeType="Ean8" />-->
    <!--<BarcodeType DwBarcodeType="C25Industrial" />-->
    <!--<BarcodeType DwBarcodeType="UpcA" />-->
    <!--<BarcodeType DwBarcodeType="UpcE" />-->
    <!--<BarcodeType DwBarcodeType="Code11" />-->
    <!--<BarcodeType DwBarcodeType="MSI" />-->
    <!--<BarcodeType DwBarcodeType="RSS" />-->
    <!--<BarcodeType DwBarcodeType="Postal" />-->
    <!--<BarcodeType DwBarcodeType="PatchCode" />-->
    <!--<BarcodeType DwBarcodeType="Telepen" />-->
    <!--<BarcodeType DwBarcodeType="Aztec" />-->
    <!--<BarcodeType DwBarcodeType="DataMatrix" />-->
    <!--<BarcodeType DwBarcodeType="QR" />-->
    <!--<BarcodeType DwBarcodeType="PDF417" />-->
    <!--<BarcodeType DwBarcodeType="MaxiCode" />-->     
    <!--<BarcodeType DwBarcodeType="Pharmacode" />-->    
  </BarcodeTypes>
  <Iso15415BarcodeTypes>
  </Iso15415BarcodeTypes>
  <Iso15416BarcodeTypes>
    <!--<BarcodeType DwBarcodeType="Code128" />-->
    <!--<BarcodeType DwBarcodeType="C25Interleaved" />-->
    <!--<BarcodeType DwBarcodeType="UpcE" />-->
  </Iso15416BarcodeTypes>
</BarcodeSettings>
==========================================

I do not know how DW 7.1 does things on the Desktop, but hopefully you can still swap out the settings file, restart desktop services, and try to scan again. Hopefully it increases your accuracy.

Thanks,
Joe Kaufman

Martin,

The .NET code is just a wrapper around the Platform SDK resources which can be called from any language. If you do a Google search on the following:

docuware platform "non-.net"

you will find several posts about that. More recently, DocuWare has even released a Postman collection of examples that illustrate how to perform calls to the Platform SDK from any web-capable language or scripting tool (e.g. curl):

https://developer.docuware.com/rest/examples/postman-collection-download.html

There is also a link to some node.js examples there which may translate more easily into JavaScript...

Good luck!

Joe Kaufman