max*_*max
6
ocr
web-applications
barcode
archiving
image-scanner
我已经思考如何处理纸质文档输入的webapps一段时间.主要问题是如何统一元数据和扫描的PDF.为了这个例子,我将提出一个假设的费用索赔申请.到目前为止我考虑过的方法:
- Web 1.0的,打开网页,创建一个费用报销和输入数据,切换到扫描应用程序,扫描到文件,切换到浏览器,点击"选择文件"导航到扫描的文件上传.优点:简单的代码.缺点:可怕的工作流程,每个工作站需要一个扫描仪(和驱动器和磁盘空间等/可能不会与瘦客户机工作:思杰/ iPad的)
- 条形码样式打开网页,创建费用索赔并输入数据,保存,打印条形码标签,将条形码粘贴到纸上.在一天结束时扫描所有条形码纸.批量上传并根据条形码将其分配给费用索赔.(在扫描中OCRing条形码是一个已解决的问题,例如参见exactCODE)优点:体面的工作流程,每个部门一个扫描仪就足够了.缺点:每个工作站都需要条形码标签打印机(比扫描仪更容易但不便宜),扫描后的纸张只能在几个小时后才能使用
- Web 2.0样式使用本地扫描仪扫描到[Dropbox]文件夹.Web应用程序使用的Dropbox API来检测新的扫描,它们呈现给用户,让他们进入元数据.优点:漂亮的工作流程.缺点:每个人都需要一个扫描仪,不能的webapp只是弹出,并说"有可用的新的扫描".
- 批处理样式有人扫描由必须处理它们的人(或按文档类型:费用索赔,发票,订单)分隔它们的所有文档.文档被批量上载(例如,作为ZIP)到队列中的Web服务器.现在,一个人必须完成此队列并输入所需的元数据.优点:只需要维护一台扫描仪.缺点:工作人员不再有纸,只有在线版本.这被我的同事们视为一个重要的节目.
- 条形码批处理条形码标记所有传入文档,在单个文件夹中扫描它们并将它们批量上载到存储库,然后将旧纸张分发到不同的部门.处理费用索赔的人员也会从纸张输入条形码编号.Webapp联系存储库并根据条形码编号检索扫描的文档,并将其与元数据一起保存.PPros:代码简单,缺点:很多纸张仍在四处闲逛,文件可能会扫描,可能永远不会进入数字存储库 - 例如医疗记录
- 桌面应用程序编写基于TWAIN的小型桌面应用程序,该应用程序扫描,上传到Web应用程序并打开浏览器窗口以添加元数据.优点:良好的工作流程,缺点:每个桌面一台扫描仪,而不是Webapp /平台问题
有关上述方法之一的更好解决方案或评论的任何建议吗？