0.   引言

运输是第三方物流企业中最主要的业务活动^[1], 运输子系统在第三方物流信息系统中处于一个非常重要的地位。在项目需求分析过程中, 发现运输子系统业务逻辑异常复杂, 设计任务非常繁重, 因此如何降低系统设计的复杂性对于项目的按时完工有着非常重要的意义, 同时采用的手段与方法也预示着工程质量的高低。为了解决上述问题, 本文设计了一个第三方物流信息系统运输子系统。

1.   系统结构设计

运输子系统一共分为5个部分: 业务管理、监控、查询与统计、财务接口与运费调整的审核, 其系统设计架构见图 1。

图  1  运输子系统设计架构Fig.1 Transportation subsystem design framework

下载: 全尺寸图片 幻灯片

业务系统包括客户运单管理(涵盖客户运单录入、审核以及提货预报的发送)、车辆管理(包括运输工具档案记录、运输工具报到以及运输工具的审核)、运输方式优化(包括运输方式规划和虚拟配载)、运输工具装载、运输执行合同生成、货物在途管理、中转与事故签收、到货签收、成本结算(包括索赔)和收入结算(包括赔付)几个子系统。

监控部分主要对运输子系统的客户运单和运输工具信息进行跟踪和警示。

运费调整的审核以动态树的形式提供对于成本、收入调整审核的功能。

财务接口主要体现在2个方面, 一是收入结算开票时要将相应的成本和收入形成相应的凭证, 然后导入用友系统; 二是在月末时统计成本收入信息, 进行帐目汇总。

查询与统计是在主要业务过程完成之后, 对于业务过程进行分析和汇总的相关模块, 可以对以后的业务运作起到支持和参考作用。其包括接单查询、运输工具查询、运输调度查询、货物装载查询、合同查询、在途控制查询、客户运单查询、异常情况查询、中转事故签收查询、到货签单查询、承运商结费查询、返单情况查询、回单情况查询、承运商索赔查询、客户赔付查询、核算查询项目总表、线路分析、业务分析报表、成本收入日报表、成本分析、运输成本查询、代垫运费查询以及运费余款查询。

2.   业务流程设计

根据用户需求设计的界面体现不出企业内部的业务逻辑和业务约束, 因此需要对企业的内部业务逻辑进行进一步的规划和设计。运输子系统的工作流比较复杂, 为了优化业务逻辑的过程, 验证软件实现的完整性, 明确各个子模块之间的关联和调用关系, 对功能相近或重复的子模块进行合并, 最大程度地实现软件复用。经过讨论和分析, 对于运输子系统的大部分业务逻辑可以用着色Petri网(图 2)描述^[2,3]。其大体过程可以分为记录客户运单、运输工具报到、装载、生成执行合同、运输工具在途记录、签收6个子过程。

图  2  运输子系统业务流程着色Petri网

Figure  2.  Operation flow colored Petri net of transportation subsystem

下载: 全尺寸图片 幻灯片

记录客户运单子过程包含记录客户运单接单信息与并单请求、审核记录信息、更正记录信息、计算运费、通知仓库备货、生成作业号、记录货物发运方式和线路、审核运作方式和更正运作方式几个变迁。记录客户运单接单信息与并单请求是运输业务开始的起点, 用以完成客户运单上货物的内容、委托的运输描述、接单情况以及并单请求的录入; 当客户运单记录完成之后就要进行审核记录信息的操作, 如果审核通过则进入下面的流程, 如果没有通过则进行记录信息的审核; 更正记录信息只是对审核未通过的运单信息进行修改, 然后再次提交审核, 直至审核通过为止; 计算运费主要进行收入标准的读取, 用来判断相应业务是否有收入的标准, 如果没有则提示用户, 先录入合同中有关的收入标准然后再运作, 如果找到了相应的运费标准则进行下面的操作, 并且通知相应的仓库备货; 通知仓库备货作为辅助的变迁给仓库发送提货预报; 当并单信息已经取得, 并且找到了相应的收入标准以后, 同一收入单位的几个客户单会生成一个作业号, 用以标识一个独立的收入单元; 记录货物发运方式和线路用以对每笔货物的发运量和运作路线、分段作以规划; 审核运作方式将对规划的结果进行审核, 如果审核通过则进入下一阶段, 并且标志着货物信息即运输任务生成的结束(如果分为多段运输则会生成每一段运输的运输任务), 如果不通过则要进行更正; 更正运作方式是对审核没有通过的运作方式进行进一步的更正, 直至审核通过为止。

除了业务系统的主流程之外, 还有许多辅助和更为详细的子业务流程, 如客户运单原件的经手信息跟踪过程也可以以如下的Petri网(图 3)形式进行描述。其中涉及接单、携单、返单、回单4个概念。接单是指有效的客户运单录入过程, 即经过审核通过的客户运单录入; 携单是指运输执行合同的乙方携单客户运单原件的过程; 返单是指目的地为第三方物流公司的邮寄或携带客户运单的过程; 回单是指目的地为客户的客户运单经手过程。

图  3  运输子系统返单Petri网

Figure  3.  Customer order returned Petri net of transportation subsystem

下载: 全尺寸图片 幻灯片

当接单过程完成之后, 要进行一次或多次的返单、携单过程, 直至目的地最终回到了运营分部, 客户运单原件回到运营分部之后, 运营分部首先要确认针对给定客户运单第三方物流公司的违约情况, 然后决定返单给总部还是回单给客户; 如果返单给了总部, 总部在接到返单之后, 只能再将签收过的客户运单原件回单给客户^[4]。

3.   数据库设计

数据库设计的过程见图 4,先从分析企业实际运作的单据开始, 识别基本的实体, 然后根据界面中对于操作方式、步骤的要求画出数据流图, 并且结合业务流程的Petri网, 进一步识别系统应具备的实体集, 接着画出E-R图, 识别实体之间的关系, 最后再将其转化为关系模型, 成为数据库中表的基本结构。

图  4  数据库设计过程

Figure  4.  Database design process

下载: 全尺寸图片 幻灯片

3.1   从单据中识别实体

对于实际运作中出现的单据, 并不是所有的都要与数据库中的表对应起来, 比如说到货预报, 它实际上可以通过在途运输工具所携带的装运单信息查询得到, 就没有必要进行持久存储; 而有些运营过程中的关键性单据则被识别为独立的实体集或实体集族, 如客户运单, 它实际上就构成了数据库中存储的客户运单的主要内容。在纸面单据上并没有出现而系统必须要进行记录的一些内容还要补充上去, 比如说录入人、录入时间等, 而且这些单据中还可能包含多值属性, 如杂费、电话号码等也要识别出来, 以便形成公共信息的内容或形成子表。在进行数据库设计时, 以客户运单为中心展开的一系列数据库表, 如客户运单成本累计表、客户运单收入分摊表等, 就构成了客户运单实体集族。

3.2   根据界面绘制数据流图

数据流图是描述系统静态数据构成和关系的有力工具。与Petri网不同, Petri网的重点在于描述业务过程, 具有动态性; 而数据流图更多地从静态的观点来考察一个实际的业务系统^[5]。数据流图的绘制应该分层次、有规律地展开, 见图 5。

图  5  运输子系统顶层数据流

Figure  5.  Top data flow of transportation subsystem

下载: 全尺寸图片 幻灯片

顶层数据流图表达了运输子系统与外界交换数据的主要内容和形式, 包括与操作者之间的交互和与第三方物流信息管理系统其他子系统之间的交互。运输子系统与客户的交互包括接收客户运单、返回签收单、确认客户结算单和赔付确认单; 与承运方的数据交互包括承运方的运输工具信息提供、签收单以及按照签收结果进行结算的承运方结算单; 与合同子系统的数据耦合体现在对于客户保险合同、客户主、子合同、团购保险合同、单车保险合同、预约保险合同以及供应商主、子合同内容的读取上; 与仓储子系统的关系主要体现在提供提货预报和收货预报; 与质量子系统的数据联系体现在要提供给质量子系统事故总结的相关内容。

第1层数据流图(图 6)体现了运输子系统中几个组成部分之间的数据耦合关系以及顶层数据流图中运输子系统与外界的数据交互来源和用途。运输子系统以静态的观点看, 可以被分成7个部分: 客户运单管理、运输工具管理、运输调度、中转与在途处理、到货管理、业务管理以及审计部分。除了审计部分之外, 每一个部分都与其他部分有着数据上的联系。比如客户运单管理会为运输调度提供运作方式待定产品表, 运输工具管理会为运输调度提供可用运输工具信息等。而且, 此数据流图也交待了顶层数据流图中的外界交互数据来源与用途, 比如说: 提货预报产生自运输调度, 中转与在途处理中要参考供应商主、子合同等。同理, 第2、3层数据流图与其相同。

图  6  运输子系统第1层数据流

Figure  6.  First layer data flow of transportation subsystem

下载: 全尺寸图片 幻灯片

3.3   从E-R图中识别关系

当数据流图完成之后, 结合Petri网中业务逻辑的内容就可以识别出绝大部分系统所需的实体集, 在此时, 对实体之间的关系再一次进行确认, 就要借助于实体关系E-R图(图 7)。图 7中方框对应的实体在数据库设计中可能对应多个表, 菱形代表的是实体之间的关系, 椭圆表示实体或者关系的属性^[6]。

图  7  运输子系统E-R

Figure  7.  E-R diagram of transportation subsystem

下载: 全尺寸图片 幻灯片

整个运输子系统以收入和支出被划分为2个部分。收入部分是指客户与第三方物流公司之间的关系, 也就是第三方物流公司负责把客户指定的货物运送到目的地, 客户付给第三方物流公司费用的过程。收入首先是从客户运单开始的, 多个客户运单可以合并为一个作业单, 所以客户单和作业单之间是多对一的关系, 同样多个作业单可以同时结费, 这两者也是多对一的关系。

连接收入和支出的就是可用运输工具的配载, 根据系统中运输工具和货物的信息进行配载, 每一辆运输工具可能运多个客户运单上的货物, 一个客户运单货物也可能由多个运输工具来运输, 所以客户运单和可用运输工具之间是多对多的关系。然而, 这种关系的产生是通过配载来产生的, 配载的结果又以系统发运单的形式保存起来, 因此系统发运单与配载之间的关系是发生在实体与关系之间的关系, 所以用到了聚集。而每个运输工具的一次运输都要签订一个运输执行合同, 所以可用运输工具和执行合同之间是一对一的关系。

支出部分是指第三方物流公司和承运商之间的关系, 即承运商把第三方物流公司指定的货物运送到目的地, 第三方物流公司支付相应费用的过程。在经过对运输工具的虚拟配载之后, 进行实际装载, 将实际装载结果录入系统中, 每个运输工具上对应同一个客户运单会产生相应的装运单, 用以记载货物信息, 所以一个执行合同可以对应多个装运单。接下来签订执行合同, 合同签订之后这个运输工具就可以出发了, 运送货物的过程中还要对货物状态进行在途监控。如果运输途中出现了质量事故, 则需要填写事故检查单, 每次事故都要填写相应的事故检查单, 所以每个运输执行合同对应0到n个事故检查单。货物运到目的地之后进行的就是签收, 签收分为客户运单的签收和装运单的签收, 客户运单的签收由最终客户完成, 装运单的签收则由第三方物流公司来完成^[7]。

根据E-R图, 不难看出系统中的实体集可以大致分为客户运单族、执行合同族和系统发运单族。因为几乎其他的实体都可以找到一对一或多对一的关系与其联系起来, 因此这3张表是系统的核心。客户运单族除了客户运单以外, 还包括客户单变更信息、作废客户单、客户单跟踪信息以及客户单明细和运作方式待定产品表。其中, 运作方式待定产品实际上就是客户单明细的全部或者部分, 其他的实体集都可以通过客户运单的主键对其内容进行分类、查询; 执行合同族还包括监控记录、运输工具档案、发运单、事故检查单及事故总结; 系统发运单族还包括签收单和签收单明细。主表与明细之间在明细不采用独立编码的情况下, 由于明细需要借助主表的关键字才能唯一定位某一条记录, 因此明细属于弱实体集, 而主表属于标识实体集; 如果明细独立编码, 那么与主表之间就不再是标识实体集与弱实体集之间的关系, 而是多对一的关系。

3.4   转化为关系模型

E-R图中的实体和关系都已经识别清楚之后, 要进行E-R模型到关系模型的转化才能在关系型数据库中进行持久存储。按照通行的转化方法, 将上述E-R模型转换为关系模型之后建立物理数据模型(Power Designer设计)。

其中共有125张表, 可以被分成临时客户单族、客户单族、作业族、运作规划族、运输工具族、收入结算族、执行合同族、公共信息族、签收族、客户签收族、开票族、日志族、回返单记录族以及历史表族14个族。有的是按照E-R图中的实体集族进行划分的, 称为实体集族, 如临时客户单族、客户单族、作业族、运输工具族、收入结算族、执行合同族、签收族、客户签收族、开票族、回返单记录族, 这一类表族中一般都会有一个能够贯穿族中所有表联系序列号, 比如说临时客户单族的临时客户单序列号、客户单族中的客户单流水号、作业族中的作业号、运输工具族中的运输工具号、收入结算族中的客户确认单号、执行合同族中的执行合同流水号、签收族中的系统发运单流水号、客户签收族中的客户单流水号、开票族中的开票通知单号、回返单记录族中的客户单流水号; 还有一类是根据功能进行划分的, 称为功能族, 比如运作规划族、公共信息族、日志族和历史表族, 它们在族中一般没有什么相互联系的纽带, 而只是因为功能相互类似才放在一族之中。这里得到的只是数据库设计的架构, 其中的字段以及表族中的表还要在程序设计的过程中进行进一步的调整, 如设计一些冗余字段支持逆向物流和方便查询。

4.   结语

分析和设计了第三方物流信息系统运输子系统的系统设计架构、业务流程着色Petri网、返单Petri网、数据库设计过程、运输子系统顶层和第1层数据流图、E-R图, 并将根据物理数据模型建立的125张表分成了14个族。这些方法降低了系统设计的复杂性, 提高了项目工程质量。