Whenever I have a user scanning a bunch of policy documents using bar codes, it does not allow any of my other users to use the drag and drop feature. I am pretty sure this is because when the barcoded batch is scanning, it creates a file in the EIM\Unrouted folder without an extension. Is there any way that I can avoid this problem?
I see that you are on 10.3, but 10.3 was supposed to fix that. When someone is doing the barcode scanning it should be creating the file without the extension in an UNROUTED\BATCH folder, not just the UNROUTED folder. Check your system settings (Homebase, Tools, System Settings) and on the Efiling tab see where your path defaults. Mine shows for the Batch Scan Paths: H:\ATTACH\UNROUTED\BATCH
This is what I have under the Efiling tab of system setup:
Attachment Routed Paths: g:\ATTACH;g\eim;
Attachment Unrouted Paths: g:\EIM\unrouted
Batch Scan Paths: g:\EIM\unrouted\BATCH
Anything look funky?
I think you need to change your paths. Here are mine:
Attachment Routed Paths: H:\attach;h:\eim
Attachment Unrouted Paths: H:\attach\unrouted
Batch Scan Paths: H:\attach\unrouted\batch
I think that with one of the updates it changed the path from eim to attach. You still need to have the eim in the attachment routed path to be able to view those that were attached in prior versions, but the unrouted and batch scan paths should be changed from eim to attach. Version 10.0 is the version that resolved the issue that you are having by creating the attach path. Here is text from the 10.0 release notes documentation that address this issue:
• A new batch scan path is on the E-filing tab of System Setup. Upon
upgrade, this path defaults to the existing Attachment Unrouted Path plus
BATCH. The first time the Image Scan/Attach Batch utility runs on 10.0, it
detects the presence of the folder defined by the batch scan path value and
creates it (if it does not already exist). The multi-page TIF saves to that folder
during the batch scan. Because the extensionless multi-page TIF is stored in
\ATTACH\UNROUTED, errors no longer occur while you use the File Router.
PMR 17029, 51815, 58264, 62137.
I was just speaking with Applied about an issue and mentioned this issue and they said you should log a call since you shouldn't be having an issue with your current path setup.
An alternate solution that works well, especially for larger offices is to map the \unrouted folder to the user's personal directory. This eliminates the issue of trying to figure out which files you are responsible for since anything you can see i your responsibility.