上学期末校务会上，徐校问县教育系统的公文流转系统每位教师都可用吗？我给出了肯定答案。但是有人提出了一个建议：不可能时时刻刻都开着公文流转系统看的，能否有短信通知的功能（我估计受报修子系统短信通知功能的启发）？我给出了否定的答案。因为县教育系统的公文流转系统是县教育技术中心搭建的，我没有任何修改源代码的权限。就算是有修改的权限，ZDsoft的作品基本都不是开源的，也没法修改。于是徐校就提出了我们学校能否自己开发一个有短信通知的公文流转系统，反正数字化校园平台里面肯定有这块功能的。当时我犹豫了一下，还是答应了。
暑假已经过去大半个月，也忙碌了半个月的时间。经过了两天多时间的构思，今天开始动手编写了，界面模板仿照万辰网络办公系统，但内核自己编写。下午遇到了一个难题：一个公文发给多人，数据怎么存储。如果仿照万辰系统的存储模式，那就是发几个人就生成几条公文数据，在已发公文里也会显示出多条一模一样的公文来。这样的存储方式会使数据库存在大量重复的数据，而且如果正文内容非常多的话会是数据库异常庞大，那系统在读取数据的时候会越来越慢。
考虑到系统使用的长久性，我放弃了模仿万辰系统的数据生成模式。选择了自己的构思模式：在数据库中建了两个表，一个表存储公文信息，一个表存储公文签收信息（表中的项目：公文流水号、收件人ID，是否签收数字判断，签收时间，数据量少）。如果一个公文发给多人，则在第一个表中生成一条公文数据，另一个表中生成多条签收判断数据。这样的存储模式的困难就在于：一个公文发给多人时，查看该公文各个收件人的签收信息的代码编写。
经过半个多小时的不断调试，困难终于解决。一兴奋，随时会破的椅子终于崩溃了。
现在公文子系统已基本编写完成，就差短信通知模块了。因为还没定下来用商业短信API还是用免费短信发送模式，所以这个模块也就先不写了。用商业短信API的话，那就是编写商业短信提供的API接口，这样教师那边不需要做任何事，只要系统里面填写有手机号码即可；用免费短信的话，也就写个发送模块，教师需要开通手机运营商的相关服务，还要进行相关设置，而教师不一定会弄。具体用什么通知由领导拍板决定。
以下为效果图：
发文起草界面
待办公文界面
归档公文界面
公文查看界面
公文转发界面
