1.2 逻辑审核

（1）品名审核。根据货票运输类型分为两种审核情况：一种是对铁路局补录的军运票审核，判断品名是否为军运物资、军运人员、军运车辆等。另一种是车站上报的普通票审核，如果是未列品名，查找品名代码是否在品名代码表中，如果是整车和零担货票需要核对品名代码价号；如果不是未列品名，品名代码与名称必须同时满足品名代码表某一品名，当票种为整车和零担货票时，需要核对该品名的价号。

（2）车辆审核。审核货票车数与车辆列表的车数是否一致；审核车型是否规范，车型首字符是否为字母；车型标重之和与货票总标重是否一致；车型允增重相加是否小于计费重量；如果办理按自轮运转运输，货票计费轴数与实际车辆轴数是否一致。

（3）箱主审核。货票箱主箱号单位属性是否与集装箱实际公司属性一致；对于一票多箱的货票，每箱的箱主是否一致。

（4）下浮审核。根据货票工作日期、发站、发局、发站省市、到站、到局、到站省市、品名、五定班列号、主车型、主箱型、收发货人验证下浮条件是否成立，下浮比例是否无误。

（5）D 型 篷 布审核。D 型篷布号码是否在已经公布范围内；篷布使用费核收是否正确。

（6）专用线审核。车站是否有此专用线；取送车费核收是否正确。

（7）发到站审核。根据货票工作日期，核对发到站是否具备办理该货票的能力。

（8）制票版本审核。核对该工作日期的制票版本号和实际发布的版本字典是否一致；通过比较两个版本，有效监控车站的窗口是否按时升级。

1.3 计费审核

根据货票发站、到站、收货人、发货人、品名、票种、货票类型、记事等审核货票费用合计、国铁运费、特价费用、运杂费等。

根据用户的参与情况，货票审核分为前台处理和后台处理，货票审核前台工作以B/S 交互方式实现，用户通过浏览器查看审核结果，根据实际情况下发退补款订正通知、录入车站退款证明书、取消托运等操作；货票审核还有一部分重要工作不需要用户参与，系统自动运行，这一部分工作称为货票后台处理。

为了满足货票审核的需求，需要设计一些审核字典。对于逻辑审核，需要建立品名字典、车辆字典、箱主字典、下浮字典、D 型篷布字典、专用线字典、站名字典、制票版本字典；对于计费审核，需要建立费率字典、记事字典、线号字典等，并且保留多个版本，根据货票工作日期系统自动选择适用计费字典；对于径路审核，需要建立径路专用字典，并且保留多个径路计算版本。

货票数据在工作库里保留两年，如果按照一天12 万批货票，全路18 个铁路局，每个铁路局每天平均为6 600 张，两年的数据量为48 万张，考虑到运输量较大的铁路局，可能达到100 万张。如果在设计时没有充分考虑百万级的数据量，数据库服务器和访问客户端没有得到优化，服务器的访问压力会很大，查询速度会随着数据量增加显著降低，为了提高货票审核处理效率，可以做以下的设计：（1）减少访问数据库的次数，多在内存中处理。每次访问数据库时，抓取多个财收四数据，同时获得多个财收四对应货票数据，以减少访问数据库的次数。（2）优化访问数据库查询条件。在数据库设计时对数据关键字段增加索引；尽可能减少查询条件，在货票查询中，利用财收四的信息，拼接货票关键字起止段，减少数据库比对条件的个数，少用like 或in 等对数据库的操作。（3）多点部署、并发访问。系统设计多点部署，通过多个进程来增强数据处理能力，进程间需要有良好的协作关系，如果某一进程发生如系统宕机等异常情况，其它进程要能够接替该进程完成未处理的事务；多个进程间可以按照策略设定优先级，优先级高的系统优先处理。

考虑到货票数据量大，处理耗时，数据接口文件到达时间不固定等特点，需设计货票审核自动处理模块，分别为货票自动入库、货票自动审核、货票自动拆分模块。

（1）货票自动入库。当接到收入系统专用货票接口文件后，入库程序检查文件是否匹配，查看文件内容是否存在改动，文件内容中票据部分和财收四部分是否一致。当检查通过后再校验数据是否重复入库，按照电报码、机器号以及结帐日期在记录表查看是否有入库记录，每次入库前都要对接口文件与记录表进行核对以确保不重复入库，如果记录表中存在，表示此接口文件已经入库，不需要再次处理，会自动将接口文件移除；接口文件校验通过后，入库子进程解析票据文件和财收四文件，将数据入库，财收四审核标记设置为未审状态，并写文件入库记录表，发送消息，通知货票自动审核程序处理该组财收四。

（2）货票自动审核。货票自动审核程序接到有待审核的货票消息后，自动提取收入系统货票库中未审核的财收四及对应的货票，校验货票张数与财收四张数以及费用分项与费用合计一致后，逐票进行径路、计费以及逻辑审核，将审核结果写入货票财收四明细表、货票拆分表、货票审核差错表，并将审核标记设置为已经审核状态，最后通知货票自动拆分程序进行数据处理。其中货票审核流程又是自动处理中最复杂环节。

（3）货票自动拆分。货票自动拆分程序根据货票拆分表内容，按照货运报表财收55-1、财收55-2、财收55-4、财收55-5、财收55-6、财收55-8、财收56-0、财收56-2 的内容以及业务部门规定的报表，计算不同维度的数据，写入数据表中。为了达到7×24 h 货票审核自动处理，在设计时要做如下处理：a. 在处理过程中异常情况以文本日志方式输出，便于查看和查找原因。b. 实现数据库中断重连机制。系统自动探测网络连接以及数据库连接情况，发生中断后，能根据连接情况短时间内自动恢复连接，继续工作。c. 为保持数据字典及时性，系统自动比照数据字典版本，确认有新版本时及时更新，保证审核内容正确性。

（4）货票定制审核。在货票自动审核中，存在由于数据字典没有及时升级导致的错误，用户需要在数据字典升级后通过重新审核来消除该错误，所以需要设计一个货票定制审核程序，指定将某个条件的数据进行重新审核。定制审核处理比自动审核优先级高，可以对自动审核后的数据进行再次审核，相反则不可以。因为定制审核是由用户发起的，需要与用户进行友好交互，在定制审核过程中，定时反馈结果，能让用户看见总共有几组财收四需要审核，目前审核的是第几组，该组财收四有多少张需要审核的货票，如果因为任务多需要等待审核，显示当前等待处理排名，估计等待的时间。

（1）数据部分回滚机制。为了提高处理速度，在货票审核时，一次性处理多组财收四，在操作过程中存在某组财收四处理异常而其它财收四处理正常的情况，此时系统只回滚有异常的财收四货票，其它审核成功的货票提交，达到一个事务内数据部分回滚的处理技术。

（2）多线程处理。货票审核不仅要审核发送货票数据而且还要审核杂费数据，为了充分利用系统资源，缩短程序响应时间，改善用户体验，系统采用多线程处理机制。

（3）多点部署减少访问冲突。系统多点部署后，会发生访问冲突的情况，冲突越多，浪费资源越多，为此系统专门设计了减少访问冲突的机制，经过试验证明，该设计起到了良好效果。

2011 年1 月开始，货票审核子系统分别在北京、济南、成都、昆明铁路局进行了不同层次的试点工作，取得了良好效果，试点开始时间不一，最长已经运行了12 个月，没有出现因为程序漏洞需要重启服务的情况，货票审核数据不仅能满足平衡表、货运各种报表以及收入系统各子系统数据共享的需要，而且还能为后续统计分析、经营分析和财务报表提供数据支持。