ETC后台处理系统方案.doc

《ETC后台处理系统方案.doc》由会员分享，可在线阅读，更多相关《ETC后台处理系统方案.doc（33页珍藏版）》请在三一文库上搜索。

1、ETC后台处理系统方案1、系统架构32、系统实现32.1 系统管理子系统32.1.1 方案说明32.1.1.1 权限管理32.1.1.2 配置文件管理32.1.1.3 日志管理42.1.1.4 数据库系统密码管理42.1.2 数据流程62.1.2.1 用户登陆62.1.2.2 修改密码72.1.2.3 修改数据库密码72.1.2.4 屏蔽系统功能72.1.2.5 维护系统日志72.1.2.6 系统参数设定82.1.2.7 个人操作日志查询82.2 参数管理子系统82.2.1 方案说明82.2.2 数据流程82.2.2.1 操作员维护82.2.2.2 角色维护92.2.2.3 操作员角色维护92

2、.2.2.4维护角色权限92.2.2.5 维护发行点（营业网点）102.2.2.6 客户信息维护102.2.2.7 业主信息维护102.2.2.8 客户销户112.2.2.9 客户预销户112.2.2.10 银行信息维护112.2.2.11 结算中心信息维护122.3 数据结算子系统122.3.1 方案说明122.3.1.1 客户结算132.3.1.2 业主结算132.3.2 数据流程132.3.2.1 上传流水流程132.3.2.2 客户结算142.3.2.3 业主结算152.3.2.4客户银行调账划拨指令172.3.2.5 业主银行调账划拨指令182.3.2.6银行划拨指令维护182.3.

3、2.7银行划拨欠费处理182.3.2.8银行划拨缴费后处理192.4 数据交换子系统202.5 卡管理子系统202.5.1 方案说明202.5.1.1读写器的操作202.5.1.2出入库的管理212.5.1.3 卡押金的管理212.5.2 数据流程222.5.2.1空白卡出入库222.5.2.2空白卡出库冲减222.5.2.3空白卡初始化232.5.2.4初始化卡出入库232.5.2.5初始化卡出入库冲减232.5.2.6 OBU标签出入库242.5.2.7 OBU标签出入库冲减242.5.2.8 记帐卡发行242.5.2.9 储值卡发行252.5.2.10 挂失262.5.2.11 解挂27

4、2.5.2.12 记帐卡换卡282.5.2.13 记帐卡退卡292.5.2.14 储值卡充值292.5.2.15 储值卡退卡302.5.2.16 发行OBU标签312.6 银行系统子系统323、数据库结构321、系统架构1.1 系统结构ETC后台处理系统采用三层结构处理方式。即客户端、应用服务器、数据库。为了保证每层能够保持稳定，在每个部分增加相应接口。如图： 目前，首先考虑使用Delphi作为开发工具。即客户端、应用服务器使用Delphi本身的三层架构的技术。数据库采用SQLServer。增加数据操纵层是为了当数据库发生变化时，仅仅修改数据操作层就可以完成，不会将修改扩大化。当采用CICS或

5、MQ作为中间业务层实现技术时，客户端增加通讯层，将相应的字符串改成Delphi自身技术支持的相应信息，而用户界面基本不用修改。不管是在结算中心还是营业点都是在线工作，没有本地数据库。1.2 功能结构2、系统实现2.1 系统管理子系统2.1.1 方案说明 2.1.1.1 权限管理 本系统权限管理要管理到菜单级。影响操作员权限的因素有两个。一个是系统操作员屏蔽的菜单功能；一个是该操作员对应角色所具有的菜单权限。对于一个操作员的角色验证是：假如某一个操作员有N个角色，R1到Rn，每一个角色对子菜单（1001）的权限为RA1到RAn，系统对子菜单（1001）的屏蔽为S，则操作员对于子菜单（1001）的

6、权限为（R1+R2.+Rn）*S。如果该值大于零则有权限，反之没有权限。2.1.1.2 配置文件管理本系统的配置文件要加密管理。同时为了方便进行配置文件设定（配置文件设定应该是在可浏览的非加密状态），需要一个比较复杂的流程，假如应用程序为App，应用程序的非加密配置文件应该为App.ini；应用程序的加密配置文件应该为App.cfg描述如下：2.1.1.3 日志管理 本系统的日志纪录操作员的操作过程。由于操作员可能发生变化，而系统显示的是当时过程以及因为操作日志数量很大，不做关联，违反第三范式设计。增加操作员姓名、应用程序名称。OpCardNo，OpCardID只有在用刷卡方式进入系统才会有数

7、。日志内容以文字形式表达。如：删除操作员；删除从2003-1-1到2003-1-31日日志等。具体粒度由程序员自己管理。但是，至少进出系统以及所有影响数据的信息应该记录下来。 系统还要有文本日志，用来记录发生的不可预料的错误！2.1.1.4 数据库系统密码管理本系统的数据库密码可以随时修改。这时，系统登陆时会有一些不同，如下图：注意：其实数据库用户名没有用，真正的用户叫ETCMTC。在修改数据库密码时（流程图见修改数据库密码），可能会出现刚刚修改完数据库密码却不能成功修改UBUserForApp时（在SQLServer中不能将两个东东放在一个事务里），一定要出现明显提示。这也是系统脆弱的一个方

8、面。2.1.2 数据流程2.1.2.1 用户登陆 2.1.2.2 修改密码 2.1.2.3 修改数据库密码2.1.2.4 屏蔽系统功能 系统显示整个系统（不管是不是本应用程序）的所有功能。采用树状（TreeView）显示。并且通过CheckBox选择。默认是全部允许。2.1.2.5 维护系统日志 显示输入条件时间段、操作人员、应用程序。显示排序条件时间、操作人员、应用程序。按照条件过滤按照排序条件显示日志内容。可以删除相应条件日志，但是删除操作同样纪录日志（先删除后添加，在一个事务中）。2.1.2.6 系统参数设定2.1.2.7 个人操作日志查询 显示输入条件时间段、操作人员（只能是该操作员）

9、、应用程序。显示排序条件时间、操作人员、应用程序。按照条件过滤按照排序条件显示日志内容。可以从维护系统日志继承。2.2 参数管理子系统2.2.1 方案说明 目前，营业网点通过网络直接与应用服务器连接才能够进行操作。所以所有的营业网点具有的功能可能相同会造成网点之间互相修改对方建立数据的可能，因为有日志纪录，不会造成太多的影响。2.2.2 数据流程2.2.2.1 操作员维护说明：删除操作员必须首先处理完身份卡才可以删除。要么还原身份卡，要么身份卡挂失（丢失情况）。2.2.2.2 角色维护2.2.2.3 操作员角色维护浏览操作员角色时，应该可以对操作员或角色按照操作员号码、姓名、角色号码、角色名称

10、进行相应过滤。按照操作员工号、姓名、角色编码、角色名称等进行排序。增加操作员角色时，应该可以对于操作员和角色分别进行多选。在实际增加时，如果该操作员已经具有该角色，不要提示错误，可以直接进行。删除操作员角色时，应该可以对于操作员和角色分别进行多选。在实际删除时，如果该操作员不具有该角色，不要提示错误，可以直接进行。所有增加删除操作要写日志。2.2.2.4维护角色权限 通过CheckBox选择相应角色后，右边的TreeView显示各个应用程序（一层）下各个一级菜单（二层）下的二级菜单（三层）。通过选择、不选择上一层菜单可以自动全选、全不选下层的所有菜单。子菜单的选择，必须保证父菜单也是选中的。2

11、.2.2.5 维护发行点（营业网点） 2.2.2.6 客户信息维护客户信息删除在客户销户中处理。所有客户信息都要保留（假删除）。2.2.2.7 业主信息维护业主信息维护比较简单。主要是考虑到如果业主信息错误，其实需要修改的东西很多。同样业主信息删除，也很难有正确的判断条件。如果真出现了业主不参与本系统，相应的处理要复杂的多，肯定需要人工干预。2.2.2.8 客户销户2.2.2.9 客户预销户不能在这里自动挂失，因为客户的这些记账卡应该退卡，涉及到卡押金。不用考虑储值卡用户，因为客户信息并没有删除，同样可以显示出储值卡的客户。2.2.2.10 银行信息维护删除、修改银行信息可能涉及到其他很多业务

12、，如：已经发出没有确认的划账指令；业主银行信息；客户银行信息等等。所以实际上，真正删除一个银行是要考虑很多东东的。2.2.2.11 结算中心信息维护删除、修改结算中心信息可能涉及到其他很多业务，如：已经发出没有确认的划账指令等等。所以实际上，真正删除一个结算中心是要考虑很多东东的。另外，银行信息必须同时输入完成。2.3 数据结算子系统2.3.1 方案说明结算模型的主要难点。结算必须有两种结算：客户结算和业主结算。由于客户结算主要是对记账卡进行结算。必须详细记录每次用户结算银行划帐信息与客户相应消费的关系。储值卡需要注意的是消费的连续性。但是，由于记账卡如果银行没有完成划拨指令，可能影响业主结算

13、的进行。而业主结算需要能够和工班日期相对应。需要将结算日期与工班日期相对应。目前专营公司的结算模型是：每天接收到数据后进行客户结算。设立一个特殊划拨账号，里面有保证金，保证即使客户划拨没有完成，也可以保证业主划拨的完成。由于有区域中心保证完整性，所以如果想做到结算日期与工班日期对应，是有可能的。同时还有对自己的划拨指令（专营公司收益）。目前，本系统处理原则是：结算中心保留三个账户：收益帐户、储值卡账户、记账卡支出账户、记账卡收入帐户。所有结算中心的收益划拨到收益帐户；所有储值卡的资金存入储值卡账户，在业主划拨指令中，所有储值卡的划拨都从该账户支出，对于系统而言，该账户就是业主划拨的储值卡资金的

14、支出账户；记账卡账户目前考虑收支两条线（如果一条线，将两个账户设成一样即可）客户结算客户资金进入记账卡收入帐户，业主结算资金从记账卡支出账户进入到业主账户。路段很难保证完整性，而且由于主要在省外进行该项目，能否有路段完整性，还是未知。故，不再考虑完整性，即结算日期（客户、业主）可以包括多个工班日期，一个工班日期的数据可以出现在多个结算日中。具体做法如下：储值卡数据通过触发器直接进入StoreOutList。ETCSplitResultList有SN号码。记账卡数据通过触发器进入到TallyOutList，有SN号码。ETCOutList上传后产生SN号码，该号码保证先上传的肯定号码小。同时，增

15、加两个表，StoreErrOutList，TallyErrOutList。这两个表主要用来存储收费流水里的卡号没有出现在卡动态表中（错误或试验的卡号）。这里的数据不能参与结算。结算暂时不考虑滞纳金自动计算的问题。如果出现滞纳金，可以通过人工计算输入调账指令的办法解决。2.3.1.1 客户结算所有上传的数据都进行结算，结算是针对TallyOutList的产生的。每天可以结算多次，形成多条划拨指令。没有结算日期，只有结算时间。如果没有记账卡数据，客户结算可以省略。如果发现错误数据，需要进行错误数据处理流程。每天只能结算一次。2.3.1.2 业主结算业主结算如果单纯依靠ETCSplitResultL

16、ist可能会产生以后有些报表没有办法产生的情况。但是，如果修改ETCSplitResultList会对目前系统产生很大影响。所以，暂时先以ETCSplitResultList为基础，考虑到业主应该不会关心客户信息。每天只能结算一次。2.3.2 数据流程2.3.2.1 上传流水流程插入黑名单表的表示伪卡。GenCau=3。为了防止已经存在该卡信息，应该先删除后添加黑名单信息。2.3.2.2 客户结算输入结束工班日期，主要是可以让用户有一个条件限定的机会。其实，工班日期可以输入的超过今天。注意：客户结算需要考虑折扣，这也是CustomAcc与CustomTrans分离的原因之一。CustomAdj

17、ustTrans是折扣后的数据。错误处理流程其实就是人工参与修改数据。IsSkip=0是为了向后兼容，可以自动处理。日志根据编程需要进行，由程序员决定。2.3.2.3 业主结算输入结束工班日期，主要是可以让用户有一个条件限定的机会。其实，工班日期可以输入的超过今天。但是根据校验拆分与流水可能不符。注意：业主结算需要考虑折扣，这也是OwnerAcc与OwnerTrans分离的原因之一。OwnerAdjustTrans是折扣后的数据。同时，还应该考虑服务费的收取。服务费出现分以下数据时，四舍五入计算每一个业主的收入。服务费=每个业主折扣后应得资金-业主折扣后应得资金*折扣率*（1-服务费率）。调账

18、指令是折扣后的数据，调账指令与服务费无关。错误处理流程其实就是人工参与修改数据。IsSkip=0是为了向后兼容，可以自动处理。日志根据编程需要进行，由程序员决定。2.3.2.4客户银行调账划拨指令由于有日志，所以删除、修改可以不采用冲减的方式。2.3.2.5 业主银行调账划拨指令由于有日志，所以删除、修改可以不采用冲减的方式。2.3.2.6银行划拨指令维护 在银行划拨指令完成以前（银行端确认），可以修改除了划拨号码以及资金以外的任何信息。甚至，连银行确认标示也可以修改。主要是为了真的出现银行端出了问题，但是手工已经将该划拨完成的情况。2.3.2.7银行划拨欠费处理可以输入相应日期，查询银行划拨

19、指令中没有划拨成功的。同时，可以将这些帐户的所属客户的所属记账卡挂失。该挂失与丢失挂失可以同时发生。数据流程如下：对于记账卡黑名单应该先删除，后添加。2.3.2.8银行划拨缴费后处理可以输入相应日期，查询银行划拨指令中已经划拨成功的客户。同时，可以将这些客户的所属记账卡解挂。该解挂不影响丢失挂失的用户。数据流程如下：2.4 数据交换子系统2.4.1 方案说明数据交换系统分为客户端与服务端两个程序。不论参数下发还是数据上传采用相同的机制。系统发送的参数大致如下：客户端：源目的表=表名，源临时表=表名，本地表=表名，一次读取数量，成功发送删除否（0：不删除，1：删除）， 其中一次读取数量=0表示一

20、次全读，大于零表示相应数量。 对于数据同步（以ETCOutList为例），源目的表=，源临时表=ETCOutList，本地表=ETCOutList，100，1， 对于参数下发（以TallyCardBlackList），源目的表=TallyCardBlackList，源临时表=TallyCardBlackList_Tmp，本地表=TallyCardBlackList，0，0，传送方式可以采用Delta包的方式。2.4.2 数据流程2.5 卡管理子系统2.5.1 方案说明卡管理有一部分涉及硬件的操作，通过本软件并结合读写器以实现卡的初始化及发行，储值卡充值等目的，同时它也需要将所做的任何操作反映到

21、后台的数据库表。至于其它诸如挂失，出入库管理，其操作结果只在后台数据库反映。每个功能的操作，可能需要一些后续工作支持才能真正完成，系统可以建立这样的一种向导，将原来可以独立的两个界面连接起来，并且所需要的后一界面的内容如果可以根据前一界面得到，系统能够自动给出，以简化输入或选择操作。2.5.1.1读写器的操作本系统要结合读写器进行操作，而且在多个用例中出现。因此最好将读写器的操作做成一个控件，既可用于复用，还可增加与用户交互操作的美感。即是这样的一个控件，能够模拟显示读写器的操作，如同鼠标的滚动在屏幕上以指针的移动来反映。当激活这个控件，检测计算机是否与读写器相连并且系统能够识别，如果连接不成

22、功，控件中以图片显示两个设备未连通的状态，否则以一个就绪的状态图片表示。当放上卡时，又会立即显示有卡的图片，当读写器识别不出这张卡时，以坏卡的图片显示并发出一长声提醒。当正在读(写)卡，以正在读(写)卡的状态图片显示，读(写)卡成功后也显示一个成功的状态图片并以声音提示。而且在这个控件中，提供不同状态下的事件以进行其它的动作，比如写卡时提供一个OnWriteCard的事件，其它程序员根据实际操作在写卡的事件中描述具体的动作，比如是发行还是充值或是卡还原等。2.5.1.2出入库的管理因为发行点和管理中心都是使用同一台机器上的数据库，所以基本上是物品在位置上的变化，可以知道哪类物品在那个地方有多少

23、，所以有界面上操作比较简单，实际关键在于数据库中的数据流动方式上。对于卡的管理，考虑到有可能在印刷的时候可能已经区分为记账卡和储值卡，所以在库存管理中需要考虑。所以卡的库存分为记账卡、储值卡、未知三类，用以满足各种情况。库存的管理目前对于空白卡、初始化卡只是管理到数量。对于真正的记账卡、储值卡通过动态表的方式管理。对于错误的出库、入库仍然采用冲减的办法处理。对于没有安装的OBU标签的出入库目前也仅仅反映到数量。但是对于已经安装的OBU标签需要按照编号单独管理。OBU标签的安装，目前不需要管理其安装费等财务信息。2.5.1.3 卡押金的管理卡押金采用动态管理的办法。每一张卡在发行的时候按照参数表

24、里的卡押金收取费用。退卡时，按照卡动态表里的卡押金退回卡押金。2.5.2 数据流程2.5.2.1空白卡出入库 如果出库发现没有相应纪录，同样表示库存不足。用户需要选择出入库，卡类型（未知、储值卡、记账卡），以及输入卡数量。系统自动生成出入库流水号码。2.5.2.2空白卡出库冲减 显示出入库信息时，不需要显示出入库流水号信息。2.5.2.3空白卡初始化 插入密钥母卡与密钥传输卡。空白卡初始化不修改库存信息，只写入系统日志。2.5.2.4初始化卡出入库2.5.2.5初始化卡出入库冲减2.5.2.6 OBU标签出入库2.5.2.7 OBU标签出入库冲减2.5.2.8 记帐卡发行记帐卡发行界面要求：发

25、行界面应该有选项，是否安装OBU标签。如果安装，可以立即转到OBU发行的界面上去，OBU发行时所需要填写的车型、车种、车牌、卡号、客户号，系统依据上一界面的内容自动给出，以减少信息的重复输入。 从原则上讲，从数据库中查找是否存在该卡可以替代不是上一张卡的判断。比较不符和写入不成功之所以不直接写卡还要判断主要是防止中途换卡。不知道初始化卡能否分清是不是记账卡，如果能够分清，还需要增加初始化卡是否是记账卡的判断。如果刷的是已经退卡的卡，应该判断，退卡时间（TallyCardDyn.Optime）到现在是否经过了一个数据完整时间。2.5.2.9 储值卡发行储值卡发行界面要求：发行界面应该有选项，是否

26、安装OBU标签。如果安装，可以立即转到OBU发行的界面上去，OBU发行时所需要填写的车型、车种、车牌、卡号、客户号，系统依据上一界面的内容自动给出，以减少信息的重复输入。储值卡发行完成，直接转到储值卡充值界面中。 从原则上讲，从数据库中查找是否存在该卡可以替代不是上一张卡的判断。比较不符和写入不成功之所以不直接写卡还要判断主要是防止中途换卡。不知道初始化卡能否分清是不是储值卡，如果能够分清，还需要增加初始化卡是否是储值卡的判断。如果刷的是已经退卡的卡，应该判断，退卡时间（StoreCardDyn.Optime）到现在是否经过了一个数据完整时间。2.5.2.10 挂失挂失不分卡类型。因为挂失找不

27、到原来的卡。此时只能输入卡的卡号（或其它信息，应该是一个查询界面，因为很多人记不住卡号），系统调出此卡的信息。当此卡原属于正常卡，确认挂失时，系统将会为此卡写一个挂失状态的标志，并提示用户是否需要为此车申请新的卡，如果同意，系统转到相应卡发行界面，记账卡发行时所需要填写的车型、车牌、客户编号，系统依据上一界面的内容自动给出，无需操作者重复输入。流程如下：gencau=1。考虑可能黑名单已经存在该信息，可以考虑先删除后添加。2.5.2.11 解挂解挂不分卡类型，并且必须是好卡。是因为找到了原来的卡，此时或可以通过刷卡来得到卡号，如果该卡对应的车牌已经在挂失时就申请了新的卡（可能新卡类型与旧卡不同

28、）在使用，则系统提示用户。由用户选择解挂继续（之所以可以继续，是因为在发卡时并没有限制一张卡只能一辆车，实际使用也没有必要限制），还时转入退卡流程。流程如下：之所以这么复杂，主要是防止因为欠费造成的挂失，通过手工挂失解挂取消掉。2.5.2.12 记帐卡换卡记账卡换卡，是因为正在使用的记账卡，读写器不能识别了。本系统首先检查记账卡是否真正不能读写了，只有是坏卡才可以换卡，是好卡，系统拒绝更换。换卡可以通过先退卡的方式再发行卡的两步操作来完成。但是，换卡操作不会隐藏在系统中由操作员人工选择这两个功能来完成，而是系统就有换卡功能，系统会根据操作员的输入的卡号自动地向退卡与发行卡的界面前进。具体流程参

29、见退卡与发行卡。2.5.2.13 记帐卡退卡退还记账卡，是因为客户不再需要使用记账卡的情况。本系统要求操作员刷卡或输入卡号得到这张记账卡的客户号，车型，车种，以及要退的押金。原则上，退卡如果记账卡是坏卡，不能退卡押金；反之可以（也就是说输入卡号是不退卡押金，读卡的退）。但是，因为记账卡可能是操作员弄坏的，所以通过复选框选择。不管其实卡状态是什么，只要有实物卡在，肯定应该可以退卡。记账卡退还之后卡状态是退还，只有预定日期进行了结算后才将此卡标记为已结算状态。此时客户销户时将解除对这张卡不能销户的限制。2.5.2.14 储值卡充值储值卡充值是将所交的现金数量写到储值卡中，以让储值卡保持持续不断的使

30、用。充值时将读出这张储值卡的卡号，如果是坏卡(读不出或写卡时写坏了)，应该先挂失，过一段时间以后再退卡。如果是好卡，就可以进行充值。为了保证卡上金额与系统数据的同步性，需要先检查读写器是否连接以及数据库是否写入成功，如果有一个操作失败，另一个操作也将强制失效。同时，为了防止误操作或作弊，在开始读卡显示的卡号与金额，在充值写卡时也要进行相同的检查，只有是这张卡号时才可以写入，阻止了读A卡，本要为A卡充100，但在写卡时操作员换成了B卡。2.5.2.15 储值卡退卡退卡可以刷卡退卡和输入卡号退卡。2.5.2.16 发行OBU标签2.6 银行系统子系统2.6.1 方案说明银行子系统接收数据有三种办法。1 银行端有银行开发的新系统，通过标准的数据交换格式进行银行划拨指令的传递。因为目前还不知道数据格式，所以暂时不采用这种办法，作为以后扩充用。2 没有银行端。因为本系统提供了对于划账指令的维护功能，可以采用通知，人工管理的方式，这边通过手工维护划账指令来输入划拨信息。3 银行端有一个客户端，可以通过操作，直接修改划账指令。相当于第二种方案的远程客户端。但是，要求在传输过程中需要加密。2.6.2 数据流程3、数据库结构