关于电子文档管理系统设计
由于5S的要求，公司要对现在文档就行电子化管理，所以需要开发一套系统！
公司现在的文档大改分为3类：

1.pdf和图片类的文档（由于我们公司是一家供应链的公司，每天大改收货单，出货单，PO单，备料单之类的大概在1500张左右）
2.Excel类文件（BM，Planning，Fac等部门做的一些Excel表格）
3.面试资料（HR部门的面试时填的资料）
以上资料处了Excel文件意外，全部为扫描图片（pdf内容也是图片）

需求：
1.系统能够读取文档中的某些信息，比如出货单号，PO之类的，存档之后能够用这些关键信息查询并生成相应的pdf格式文件（Excel文件除外）
2.每天处理文档的能力要知道达到3000张（因为业务可能会增涨）
3.准确率要在90%以上
4.B/S和C/S都行
5.方便维护和扩展

我的初步设想：
1.B/S+Windows service

2.B/S界面允许用户导入相关的pdf或者图片，然后对图片进行处理，提取关键信息，然后生成相应的文件，并将文件存盘，路径和关键信息保存到数据库

3.用户将文件扫描至指定的文件，不同的文件类型放在不同的文件夹，做一个windows service定时检查这些文件夹时候寻在文件，有的话就执行处理，类似步骤2

4.将没有转换成功的文档用邮件的形式发送给相关的人员人工的提取关键信息并且存盘

5.有时上传的单个文件很大，asp.net自带的上传控件估计是不行的，用socket做个给予tcp自定义的上传控件

6.提取关键信息，很大一部分的文档都是有条码的，我采取的就去读取条码，网上有很多例子，codeproject也有现成的源码，但是对模糊条码识别率不高，对这个代码进行优化，模糊条码的识别率可以达到要求，但是一部分是没有条码的，想到了用OCR，MODI和一些第三方的都用了，识别率一般，开源的代码也没有，在codeproject上看到一个bp神经网络识别的，但是看的一头雾水，看看有没更好的方法

疑问：
1.设计思路是否有问题

2.有没有必要用WCF做数据逻辑层

3.是不是winform效率更有优势，其实不想用B/S，因为公司以后的所有的web application都到移植到share point上，要是现在做了，以后迁移又麻烦，但是winform会浪费一台电脑，并且浪费了服务器的性能，B/S可以让服务器来处理提取关键信息的功能

4.对服务器要求如何，应该买个啥样的服务器，数据库是sqlserver2008，开发工具vs2008（公司不许用盗版软件）

5.预算$50K（包括购买服务器以及第三方插件（OCR）是否足够

------解决方案--------------------
国企的吧……这东西也拿上论坛来问。此贴必沉。
------解决方案--------------------
局域网使用还是外网，并发量多少，
为什么不让用户上传文件的时候填写文件关键信息
你想的挺全面
------解决方案--------------------
30万的话，有成熟产品的可以买一套。
自己开发的话，一次性项目，钱差不多，想做好还是不够，就算够了吧。
几个问题点
1、你的电子文档管理要有自定义流程设计的部分么。有工作流的部分么。有的话，一大块工作，没有的话还成。
2、服务器端要做图片分析么？复杂么，专业图片分析项目的二包还是很贵的。你的钱不够。只做条码的话，也就能用个开源的了。自动的有点不太可能，估计还是要人工参与，确认条码区域的。

3、从那儿读数据？pdf和xls还成，要求非常严格遵守某一格式，图片的估计实现的可能性不大。

4、文件转化，用服务器端的com来做的话，程序有可能不稳定，维护工作量会加大。比如在服务器端启office 的com有时候会关不掉。

5、定时查询文件没问题，发邮件也没问题。

6、wcf？下游没有服务调用方就别用了，没意义。UI变化大的话，分个简单的三层得了。或者mvc也行。

你的这些工作？包括扫描文件啊，生成pdf呀，要在线下做么，用户能接受，这么繁的操作么？
总的下来，感觉是个出力不讨好的活。
------解决方案--------------------
这个需要整体性改造，你可以去找一下有关“智能文档”方面的提供商

国内来说一般是两拨一拨是基于shartpoint server的微软派，这一派需要公司本身有比较强的技术能力

另一派是基于adobe pdf,openxml，Xform的IBM派，这派的方案比较成熟了，毕竟这块东西非微软的人启动比较早产品已经比较成熟了