|
成品卡台账管理系统实例分享 笔者供职于国内某电信运营商，负责为公司各部门开发内部办公系统，各部门要求开发的系统五花八门，虽然大部门都只涉及数据存储展现，但有时候会有逻辑关系相对复杂的过程。以下就是我最近负责开发的一个专门对手机卡进行管理的系统。 说到这样的管理系统，不管针对的对象是什么，基本概念都很一致，：数量上的增减（也就是出入库）。但实例中的系统在设计思路上有两个较为特殊的地方。 第一是分块管理，也就是说进入数据库的数据并不是按“个数”分条，而是按照“块数”逐条存储，而这样的块又会被用户不断切割。 第二个特殊的地方是操作流程的不断反复，从原始数据导入系统后分别会经历预申请、确定申请、取消申请、特殊申请、二次预申请、二次确认申请、二次取消申请、二次特殊申请……整个过程像瀑布一样，不断重复。因此在完成了此次系统的交付后，我将这次开发的经验写成了如下这篇实例分享，供同样被需求方折磨的同行参考。 案例按照用户操作的顺序，依次介绍每一张报表中用到的一些方法。 一：原始数据导入到余量表 这一步比较简单，直接上传，导入到原始数据表(图1.0)，但因为原始数据字段太多，在后期也用不到，且在后期中卡段会被不断切割。因此，在原始表导入的同时，筛选了部分数据导入到余量表（图2.0），以后的所有操作都是在余量表中进行。 原始数据导入表样1.0 填报进入余量表2.0 为了避免用户重复导入相同数据，保存数据进入数据库前先对报表中相同的数据进行了删除。 二：文件名的逐条导入 文件名的导入是原始数据导入的另一个难点，用户上传时只上传了首文件的文件名和末尾文件的文件名（如图3.0），中间所有文件名称都是按照数字顺序排列的，而我要做的就是后期对文件名逐条进行展现（如图4.0）。 用户上传的文件名样式3.0 逐条展现的文件名4.0 这里应用到了帆软RANGE函数，但因为文件名的数字太长（12~13位），因此不能直接使用该函数。在这里我做了两次转换，第一次转换是对文件名进行截断，只取后三位数字，利用RANGE函数得到起始数字和结尾数字中间所有的数字（如图5.0），公式如下： if(len(d5)==0,"",RANGE(TOINTEGER(RIGHT(LEFT(D5,len(d5)-4),3)),TOINTEGER(RIGHT(LEFT(E5,len(e5)-4),3)))) 第一次转换后的文件名5.0 接下来的第二次转化是把得到的数字用字符串的方式暂存于单元格，再采用字符串分离的方式按照数组形式逐个存进数据库。在此处同时被保存进数据库的还有文件名中除开被截断三位数字后剩下的前几位数字（如图6.0），注意：此时数据库中的ID不能是主键 字符串分离后保存进数据库6.0 三：卡号申请
申请卡号的表格样式如下（图7.0），其中涉及到的一些固定信息比如申请人信息、号码描述、配置产品等均另开报表填报存入数据库，此处填报的时候只需要下拉框选择即可（图8.0）。 申请卡号表样7.0 固定信息填报报表8.0 由于对卡号的存储都是按照“块/段”来进行的，因此涉及到一个潜在的BUG：用户要求的卡号段不在原始号段以内或者根本就是输错了卡号
因此，我们在用户申请卡的起始号单元格内添加了下拉框控件，规定用户申请的卡号起始段只能是余量中存有的卡号段的开头卡号（图9.0）
下拉框限制起始卡号9.0 四：提示申请数量限制
为了用户操作的便捷，每一行数据的结尾卡号、余量、卡片类型、卡片规格等均通过sql语句从数据库中存储的原始数据处得到（图10.0）
自动匹配的各类信息10.0
在用户申请数量单元格的文本控件里，我增加了一个事件来限制用户申请的卡数量，即申请数量必须小于余量（图11.0） 限制用户申请数量11.0
| 
