苏州工业园区服务外包职业学院软件技术毕业论文-客诉系统的设计与实现(论文)

QPJW-11-F03 苏州工业园区服务外包职业学院 毕业设计（论文） 论文题目论文题目: :客诉系统的设计与实现客诉系统的设计与实现 届 别 2016 届 系 别 信息技术系 专 业 软件技术 班 级 软件 13（1） 姓 名 董思盼 学 号 130101009 指导教师 张趁香 1 毕业设计（论文）独创性声明 本人声明，所呈交的毕业设计（论文）系在指导老师的指导 下本人独立完成的研究成果。论文中依法引用他人的成果，均已 做出明确标注或得到许可。 论文内容未包含法律意义上已属于他 人的任何形式的研究成果，如论文涉及任何知识产权纠纷，本人 将承担一切责任。 学生签名：_日期：_ 1 目录目录 第一章 绪论 . 2 1.1 课题背景 . 2 1.2 课题目的与意义 . 2 第二章 相关环境和技术 . 3 2.1 ASP.NET MVC 简介 . 3 2.2WebAPI 简介 . 3 2.3 SQL Server 简介 . 3 2.4 HTML5 简介 . 4 第三章 系统需求分析 . 5 3.1 可行性分析 . 5 3.1.1 必要性 . 5 3.1.2 可能性 . 5 3.2 功能需求概述 . 5 3.2.1 网站系统功能需求模块 . 6 3.3 主要功能需求分析 . 6 第四章 系统设计 . 9 4.1 系统总体设计 . 9 4.1.1 网站系统总体结构设计 . 9 4.1.2 数据存储的总体设计 . 9 4.1.3 网站系统功能设计 . 9 4.2 数据库设计 . 11 4.2.1 数据库详细设计 . 11 4.2.2 E-R 图设计 . 11 4.2.3 数据库主要表结构设计 . 12 第五章 系统详细设计与实现 . 18 5.1 系统首页 . 18 5.1.1 系统首页界面的展示 . 18 5.1.2 首页界面部分功能代码展示 . 18 5.2 客诉处理模块设计 . 19 5.2.1 系统结构划分 . 19 5.2.2 功能流程图 . 19 第六章 系统测试 . 31 6.1 测试的基本概念 . 31 6.2 测试的目的 . 31 6.3 测试的步骤 . 31 6.3.1 客诉系统测试计划 . 31 6.3.2 客诉系统测试用例 . 32 6.4 测试总结 . 34 2 总结 . 35 致谢 . 36 参考文献. 37 1 客诉管理系统的设计和实现 摘要：摘要： 伴随着互联网技术以及经济的进一步发展， 以客户和消费作为中心的服务管理体系越 来越完备。 客户服务流程中的重要一环是客诉管理， 这种管理模式受到企业管理者的高度重 视；通过系统化的管理，可以高效、圆满、公平、可视化的处理客户意见，同时提高了企业 的服务质量。 本系统基于 ASP.NET MVC5 和.NET Framework 4.5 框架，数据库采用 SQL Server2014, 以前后端分离的方式（前端采用 MVC 后端采用 WEBAPI），该系统主要是给企业客服部门高 效，准确的处理客户投诉使用。同时该系统以处理流程可视化为领导监督工作提供可方便。 关键字：关键字：网站系统；客诉管理系统；ASP.NET MVC5；WEB API2；SQL Server;HTML5 2 第一章 绪论 1.1 课题背景 客户投诉一直以来是每个企业都面临的一个巨大挑战， 同时也是一个很好的 机遇。 有关研究表明，当遇到问题或着不满意去不投诉的客户或消费者再次进行 交易的概率是非常低的，只有不到 9%；然而消费者或客户投诉了，即使问题没 能得到非常合理的解决，客户和消费者再一次交易的意向也会进一步增加到 19%；再看那些投诉后的主要问题得到合理的解决的客户再一次交易的概率会提 高到 54%不等，再看一下另一个数据，投诉后就立即得到合理的解决的客户再一 次购买产品或其他服务的概率增加到了 82%。对于一个公司或企业来说，有效的 客户投诉管理手段可以明确企业的服务质量或产品质量存在的问题。一般情况 下， 客户或消费者向企业的有关部门进行客户投诉，都是因为他们购买的产品质 量或有关人员的服务质量或态度存在一定问题， 这是一个企业改进产品质量和服 务质量管理的最基本依据； 客户投诉信息除了可以反馈产品的质量和服务问题之 外， 还隐含着客户， 以及消费者对现有的产品的不满和对更为理想的产品的期待， 这是一个企业了解消费者需求，了解市场情况最为直接的途径。一个不满意的客 户会将他的不满意传播给其他人，当这些人产生同样的消费需求时，购买被批评 过的企业的产品的可能性会很低， 然而客户的投诉给了企业第二次满足客户需求 的机会，企业可以通过合理妥善的处理客户投诉再次赢得消费者的信赖，同时还 能够进一步赢得与其相关的更多潜在的客户信赖。 然而目前公司的受理客诉信息 反馈还是通过 400 热线、QQ 等渠道，在时效性和便捷性上无法满足日益发展的 时代需求，且目前 OA 系统功能单一，无法实现批量客诉预警、过程可视化、流 程签批提醒等必要功能。不同业务单位需求的相关报表，如个人及关联部门工作 效率统计、客诉内容严重程度统计目前均靠手工操作，在准确性及效率方面均需 改善。 1.2 课题目的与意义 伴随着信息技术以及经济的飞速发展， 以客户和消费为中心的服务管理体系越来 越完善。客户服务流程中的重要一环是客诉管理，这种管理模式受到企业管理者 的高度重视；通过系统化的管理，可以高效、圆满、公平、可视化的处理客户意 见，同时提高了企业的服务质量。 该设计以某企业处理客户反馈及意见的过程为背景，分析、设计、开发一套“客 户投诉管理系统”的软件。该系统内容包括客诉信息登记、客诉工单、客诉信息 分析、客诉处理流程、客诉结案等模块组成； 此外， 通过该课题的设计过程， 可以进一步掌握软件系统的开发方法和开发原理， 从而了解了软件工程意义，提高解决实际问题的能力。 3 第二章 相关环境和技术 2.1 ASP.NET MVCASP.NET MVC简介 ASP.NET MVC 是构 建 Web 应 用程 序的 一 种 框 架， 它将一 般 的 MVC(Model-View-Controller)模式应用于 ASP.NET 框架。Model（模型）， 它是软件中用于处理软件程序数据逻辑的部分。 通常模型对象的主要功能就 是负责在数据库中存取数据。View（视图）则是应软件中处理数据如何显示 的部分。通常视图是依据模型数据创建的。Controller（控制器）作为软件 的处理用户交互的核心部分。通常情况下控制器负责从视图读取数据，控制 用户的输入， 然后向模型发送相应的数据。 MVC 模式同时提供了对 HTML、 CSS、 JavaScript 的完全控制。ASP.NET MVC 还支持 Razor 语言，是一种允许您向 网页中嵌入基于服务器的代码（Visual Basic 和 C#）的标记语法。 当网 页被写入浏览器时，基于服务器的代码能够创建动态内容。在网页加载时， 服务器在向浏览器返回页面之前，会执行页面内的基于服务器代码。由于是 在服务器上运行，这种代码能执行相对复杂的任务，例如数据库的访问。 2.2WebAPI 简介 ASP.NET Web API 是一种框架，用于轻松构建可以访问多种客户端（包括浏览器和移 动设备）的 HTTP 服务。 ASP.NET Web API 是一种用于在 .NET Framework 上构建 RESTful 应用程序的理想平台。Web API 使用了 RESTful 的架构思想，最大的好处就是前 后端更好的解耦。其默认的数据格式是 JSON，这样方便使用 JavaScript AJAX 调用，并处 理前端数据。 2.3 SQL ServerSQL Server简介 SQL Server 是微软公司推出的一个关系型的数据库管理系统。它使用方便可伸 缩性好与相关软件集成程度高， 可跨越大型多处理器的服务器等以及多种平台使 用。众所周知，SQL Server 能够满足当今商业环境要求不同类型的数据库解决方 案。它一种应用最为广泛的数据库管理系统，其有点有：易用性、可伸缩性、数 据仓库功能、集成性、良好的性价比等。SQL Server 可以快速的开发新一代的 企业级商品应用程序，同时也为企业赢得了核心竞争优势。一直以来 SQL Server 都是基准测试可伸缩性和速度奖的记录保持者，它是一个拥有完全 Web 支持的 数据库产品，提供了对 XML 的核心支持以及在互联网上和防火墙外进行查询的 能力。 4 2.4 HTML5 简介简介 HTML 5 是 HTML 的最新标准，是近十年来 Web 开发标准最巨大的一次飞跃。 和以前的其他版本不同，HTML 5 不仅用来表示 Web 内容，还把 Web 带入一个成 熟的应用平台，在 HTML 5 平台上，图像，动画，视频，音频，以及人机交互都 被标准化。HTML5 的设计目的是为了在移动设备上支持多媒体。新的语法特征被 引进以支持这一点， 如 video、 audio 和 canvas 标记。 HTML5 还引进了新的功能， 可以真正改变用户与文档的交互方式。 5 第三章 系统需求分析 3.1 可行性分析 随着当代互联网技术的进一步发展，Web 应用在各大浏览器的支持下，风靡 全球。 现在通过对广大用户及消费者的调查和了解， 我对系统进行了以下几个方 面的可行性分析： 3.1.1 必要性 随着移动互联网的广泛普及，移动终端已经渗透到各行各业的各个角落，客 户反馈问题也习惯通过移动终端，直接、快速，方便。 目前公司的受理客诉信息反馈还是通过 400 热线、QQ 等渠道，在时效性和 便捷性上无法满足日益发展的时代需求，且目前 OA 系统功能单一，无法实现批 量客诉预警、过程可视化、流程签批提醒等必要功能。不同业务单位需求的相关 报表， 如个人及关联部门工作效率统计、客诉内容严重程度统计目前均靠手工操 作，在准确性及效率方面均需改善。 3.1.2 可能性 1.整洁全面。 系统平台中的界面设计及信息的整合都是根据用户需求做了细 致全面的设计和修改。 2.便捷高效。在系统平台上的操作简单便捷，对用户待办进行提醒，及工作 效率进行统计。能够进一步提高客诉处理效率。 处理过程的可视化使客诉过程更 加透明。 3规范有序。按消费者投诉内容进行分类处理，分类统计，是整个系统规 范有序从，从而进一步提高客诉办理的效率。 4编码规范。规范的代码编写以及良好的拓展性，可为公司现有管理系统 进行对接。 3.2 功能需求概述 系统需求分析毫无疑问是客诉管理系统开发至关重要的阶段，全面，细致的 分析可以让开发人员更加明确要实现的功能。避免了代码的重新开发。开发一个 性能良好的管理系统，明确用户的应用环境和需求对系统的设计是必要的。本系 统就从以下四个方面对网站的功能需求进行了分析和概述： 1. 工单起草：客诉工程师根据 CC 系统数据、微信自主提交的数据或者 web 端手动填写，进行工单起草；工单区分为质量工单和供应工单，供应工 单包含订单类型和物流类型。 2. 工单流转：工单起草后即进入后续工作流程，系统根据已设定的工作流 对工单进行分步流转处理；质量工单经由品质部初步判定原因客 6 诉部初步回复品质部8D分析客诉部领导审批客诉工程 师最终回复关怀组回访等流程；供应工单经由责任部门初步判断 原因客诉部初步回复责任部门调查处理客诉部领导审 批客诉工程师最终回复关怀组回访等流程； 3. 待办事项： 系统根据当前登录用户统计出属于该用户的待处理工单数量， 以可视化的界面展示出来，点击可查看具体列表； 4. 知识矩阵：对知识库进行维护和管理；工单流转过程中，系统可根据相 关条件智能匹配出相关知识库数据； 5. 批量预警：系统根据用户配置的相关预警项数据，包括产品、客诉类别、 区域、来源等条件，自动生成预警状态； 6. 统计报表：个人效率统计、部门效率统计、个人业务量统计、部门业务 量统计、工单明细报表等； 3.2.1 网站系统功能需求模块 通过对系统的需求分析，把网站系统分解成含义明确，功能单一的若干个功 能模块，从而得到系统的功能模块结构图。主要包括 Web 端管理模块、基础信息 模块、统计分析模块等模块，如图 3-1 所示。 图 3-1 系统功能模块结构图 3.3 主要功能需求分析 根据需求分析，把系统功能分成全局模块、基本客诉处理、基本客诉管理三 7 大模块。详细功能列表，如表 3-1 所示： 表 3-1 功能需求分析 功能模块功能模块 功能点功能点 明细明细 WebWeb 客诉管理系统客诉管理系统 全局模块全局模块 登录模块 按系统注册账户、登录密码，进行账户合法性和安全性的校验 基本信息 用户查看自己的账户信息、角色信息，并可完成基本信息的修改 密码修改 修改原有密码，设置新密码 找回密码 设置找回密码的通道 用户组织 按照与客诉处理业务相关责任的事业部，设置组织虚拟架构 通讯录控 件 依据系统相关用户的基本信息资料，生成内部通讯录控件 角色应用 配置 设定及更新系统的应用角色，及其业务权限 系统账户 管理 对业务系统的用户进行基本账户管理，及用户信息的更新 公共门户 提供公共信息门户，提供功能导航和系统接口集成后 SSO 服务 基本客诉处基本客诉处 理理 客诉信息 登记 1、话务组人员，通过 Call Center 登记客诉登记表，详细登记客 诉相关信息（如基本信息、客诉品名信息、内容信息等）生成客 诉单抛入客诉系统； 2、无论质量客诉、供应客诉，客户在移动端自助填写客诉单，抛 入系统； 客诉工单 1、审核：对于抛入客诉系统的客诉信息单，由客诉工程师审核， 如果信息不全、描述不尽，流程可退回提醒（补填），如果审核 通过生成客诉工单流转； 2、自建工单：市场客诉、供应客诉的情况，由客诉工程师自建生 成工单流转。 客诉信息 分析 1、建立客诉工单流转逻辑，实现客诉工单的分类、分理、分流的 智能化； 2、客诉判断：按照客诉类型、客诉损失等信息，由客诉工程师判 定客诉风险等级，在预制相应流程中，启动后续的处理流程； 3、 客诉判断提示： 为客诉工程师提供支撑知识库和批量预警提示， 辅助快速判断客诉分理分流的决策； 4、选择启动预制的相应处理流程，如直接处理；审批处理流程； 判定相关部门协调处理的流程 客诉处理 流程 1、直接处理，直接填写客户回复结果，然后发送投诉客户，并关 闭客诉； 2、审批处理，按照预设的流程发起审批，有客诉主管终审审批， 并关闭； 3、质量客诉，发起对品质部门的处理协作流程，由品质部经由 8D 分析，可回复相关的信息返回，然后由客诉工程师手动选择处理； 4、供应客诉，发起对售后、物流部门的工单，先相关部门可完成 相关操作后返回信息到客诉，之后由客诉工程选择处理； 5、 发送邮件通知到审批处理人， 包括首次提醒、 超时未处理提醒、 8 二次超时未处理提醒，通过邮件发送链接，直接到相关的信息填 报页面去补充信息； 客诉结案 1、 归档工单的审查， 对已经做归档处理的客诉档案，可进行审查； 2、在本系统中为客服组部门用户开辟客诉回访通知。 资讯和提 醒 1、支持发送资讯信息（通知、公告）消息； 2、支持客诉管理制度的发布和管理； 3、对待办事项、待审批流程等消息提供待办事项的提醒 支撑知识 库 1、支撑知识库服务，提供一个可分类查询、关键字查询、分类导 航的客诉处理知识库，内容可添加和更新，方便客诉处理环节； 2、知识矩阵服务，包含知识矩阵构造、知识检索服务、知识更新 维护、知识登记审核； 3、支持按照事业部、时间段、产品型号、投诉类型、客诉等级、 当前处理人、客诉处理有效性等关键字的即席查询。 基本客诉管基本客诉管 理理 风险点基 本配置 1、投诉类别、投诉途径、投诉点信息，相关信息经由系统配置； 2、客诉性质（P0、P1、P2、P3）的配置； 3、客诉批量预警的阈值设置和阶梯设置。 批量客诉 预警 按照投诉信息的相关关键字呈现批量客诉预警统计信息，并提供 界面的可视化呈现数据 客诉绩效 监控 按照客诉处理工程师个人解决量/解决率（趋势比对）、事业部门 处理量/率信息，采用柱状图、折线图的方式呈现数据信息 周报/月报 为客诉主管提供不同内容的周报/月报信息内容 9 第四章 系统设计 4.1 系统总体设计 系统的总体结构设计包括模块设计、功能设计、流程设计、代码设计、界面 设计和数据库设计等方面的相关的一系列设计，当然，这些设计都是在基于用户 的需求之上进行的合理化的网站设计。 4.1.1 网站系统总体结构设计 管理系统总体结构设计的主要任务就是将整个网站系统有条理的划分成各 个功能模块，这样做的目的是在保证实现功能逻辑的基础上，尽可能的提高目标 系统的简单性、可变性、一致性、完整性、经济性、系统的运行效率和安全，并 且能合理的处理模块与模块之间的内部联系，降低了软件系统的耦合性。为系统 的可拓展提供了保障。本管理系统的总体结构按照自顶向下的原则，而且对于信 息保证隐蔽抽象，网站信息的显示保持一致性原则，在整个网站系统的设计过程 中一直是面向用户的原则进行设计。 4.1.2 数据存储的总体设计 按需求的功能分类可把本网站系统的文件分成以下几种： （1）主文件：网站系统中的主文件是整个系统中的最重要的共享文件，主 要是用来存放共享属性的数据。 并且不涉及到对于用户类型的权限的限制就可以 访问用户可查询的相关信息。 （2）处理文件：处理文件包括了网站系统中所有数据更新的进度以及记录 的查询和显示，保证数据的安全性和数据的完整性，是针对数据的处理能进行保 存和查看的数据存储文件。 4.1.3 网站系统功能设计 根据系统的需求分析和对系统的大概的数据流程图进行分析， 把系统分解成 含义明确，功能单一的若干个功能模块，从而得到系统的功能模块结构图。如图 4-1 所示。 10 图 4-1 系统功能设计图 11 4.2 数据库设计 4.2.1 数据库详细设计 数据库的设计一般来说指的是对于一个给定的应用程序的环境， 来构造最优 的数据模式，是它能够有效的存储数据，满足各种各样用户的信息要求和处理要 求。数据库是软件开发、管理和服务的一种手段，是信息系统开发和建设的核心 技术。它的应用已经越来越普遍，从小型的事务处理系统到大型的信息系统 ， 几乎每一个系统都用先进的数据库技术来保持系统数据的安全性、 完整性和共享 性。 4.2.2 E-R 图设计 E-R 图也称实体-联系图(Entity Relationship Diagram)，提供了表示实 体类型、属性和联系的方法，用来描述现实世界的概念模型。在网站系统的数据 库设计中，首先要对系统分析后得到的数据存储进行分析，理清各数据存储之间 的关系，最后总结得出系统的关系模式。E-R 图由实体、属性、联系三部分组成， 其符号表示如图 4-2 所示： 图 4-2 E-R 图符号说明 相关模块的部分 E-R 图 见图 4-3： 12 图 4-3 部分 E-R 图 4.2.3 数据库主要表结构设计 为了进一步确定数据库的关系模式中各个数据项的各个信息， 并将数据库中 每个关系转换成二维表格，相关的模块表结构大致如下： 表 4-1 T_BasicInfo 表:业务表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 起草人 文本框 是 否 当前登陆人 String 起草人的姓 名 申请日期 日期控件 是 否 当前日期 DateTime 起草时间 CC 系统单号 文本框 是 是 无 String 呼叫中心工 单编号 客诉单号 文本框 是 是 自动生成 String 客诉的唯一 标识 事业部 下拉框 是 否 无 Int 投诉产品所 属事业部 反馈对象 文本框 是 否 无 Int 投诉产品的 制造工厂 大区 下拉框 是 否 无 Int 工厂所属的 大区 办事处 下拉框 是 否 无 Int 工厂所在的 办事处 销售渠道 下拉框 是 否 无 Int 产品的销售 渠道 13 客户代码 文本框 是 否 无 String 客户店面的 代码 客户名称 文本框 是 否 无 String 店面名称 联系人 文本框 是 否 无 String 联系人 联系电话 文本框 是 否 无 String 联系电话 省 下拉框 是 否 无 Int 用户所在的 省 市 下拉框 是 否 无 Int 市 具体地址 文本框 是 否 无 String 具体地址 物料代码 1 文本框 是 否 无 String 物料代码 物料名称 1 文本框 是 否 无 String 物料代码 物料代码 2 文本框 否 否 无 String 物料代码 物料名称 2 文本框 否 否 无 String 物料名称 物料代码 3 文本框 否 否 无 String 物料名称 物料名称 3 文本框 否 否 无 String 物料名称 是否 LED 复选框 否 否 默认（否） Int 灯的类型 产品类别 下拉框 是 否 无 Int 所属类别 制造工厂 下拉框 是 否 无 Int 制造工厂 生产日期 日期控件 是 否 无 DateTime 生产日期 物流码 文本框 否 否 无 String 物流代码 使用时间 下拉框 是 否 无 Int 使用的天数 销售/使用总数 数量控件 是 否 无 Int 使用或销售 的数量 不良数量 数量控件 是 否 无 Int 不良数量 不良率 标签 是 否 自动计算 百分比 （int） 不良率 处理单位 文本框 是 否 无 Int 处理单位 质保情况 文本框 是 否 无 Int 保 质 期内 / 已过保质期 投诉品使用场所 下拉框 是 否 无 Int 选择其它时 手动输入 客户进货数 数量控件 是 否 无 Int 进货数量 投诉类别 下拉框 是 否 无 Int 选择其它时 手动输入 不良现象 下拉框 是 否 无 Int 不良现象 客诉等级 文本框 是 否 无 String 客诉严重等 级 服务等级 文本框 是 否 无 String 服务的优先 级 客诉发生时间 日期控件 是 否 无 DateTime 投诉的时间 客户要求上门时 间 日期控件 否 否 无 DateTime 要求上门的 时间 14 投诉内容 文本框 是 否 无 String 投诉的内容 客户要求处理方 法 复选框 是 否 无 String 客户要求的 处理方法 客诉工程师判定 原因是否明确 单选框 是 否 明确 Int 客诉工程师 的判断 表 4-2 T_OC_PreliminaryAnalysis 表:初步分析表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 库存品质量状况 排查 复选框 是 是 数据绑定 String 无 负责人 标签 是 是 数据绑定 String 无 完成时间 标签 是 是 数据绑定 DateTime 无 库存数量 标签 是 是 数据绑定 Int 无 库存品质量抽检 状况 标签 是 是 数据绑定 String 无 不良描述 标签 是 是 数据绑定 String 无 在制品质量状况 排查 复选框 是 是 数据绑定 String 无 负责人 标签 是 是 数据绑定 String 无 完成时间 标签 是 是 数据绑定 DateTime 无 在制品数量 标签 是 是 数据绑定 Int 无 在制品质量抽检 状况 标签 是 是 数据绑定 String 无 不良描述 标签 是 是 数据绑定 String 无 已出货产品处理 方式 复选框 是 是 数据绑定 String 无 库存原材料状况 排查 复选框 是 是 数据绑定 String 无 负责人 文本框 是 是 数据绑定 String 无 RDC 仓产品及运 输中产品处理方 式 复选框 是 是 数据绑定 String 无 表 4-3 T_OC_PreliminaryReply 表:初步回复表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 客服初步回复 文本框 是 否 无 String 回复说明 是否寄送不良品 单选框 是 否 否 Int 寄送不良品 选项 邮件通知下一处 理人 复选框 否 否 无 邮件格式 通知下一个 处理人 短信通知客户 复选框 否 否 无 Int 通知客户 表 4-4 T_OC_ConfirmReceipt 表:确认收货表 15 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 收件人 文本框 是 否 无 String 寄送货物的 收件人 邮箱 文本框 是 否 无 邮箱格式 收件人邮箱 文本框 复选框 是 否 无 String 填写相关说 明 收货日期 日期控件 是 否 无 DateTime 收货日期 备注 文本框 否 否 无 String 备注信息 是否等待 8D 分析结果 复选框 是 否 否 Int 选择是否等 待质量检测 系统数据 表 4-5T_OC_ComprehensiveAnalysis 表:详细分析表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 FA 分析/数据 分析 标签 是 否 无 String 无 FA 分析/数据 分析附件 链接 是 否 无 附件 无 根本原因确认 标签 是 否 无 String 无 根本原因确认 附件 链接 是 否 无 附件 无 流出原因 标签 是 否 无 String 无 流出原因附件 链接 是 否 无 附件 无 流程提交时间 下拉框 是 否 无 String 无 是否有重复客 诉 复选框 是 否 无 String 无 纠正措施 标签 是 否 无 String 无 纠正措施附件 标签 是 否 无 String 无 流程提交时间 标签 是 否 无 String 无 制程验证 标签 是 否 无 String 无 制程验证附件 链接 是 否 无 附件 无 客户追踪 标签 是 否 无 String 无 客户追踪附件 链接 是 否 无 附件 无 SOP 标签 是 否 无 String 无 SOP 附件 链接 否 否 无 附件 无 WI 标签 是 否 无 String 无 WI 附件 链接 否 否 无 附件 无 D/P FEMA 标签 是 否 无 String 无 D/P FEMA 附 件 链接 否 否 无 附件 无 程序文件 标签 是 否 无 String 无 程序文件附件 链接 否 否 无 附件 无 16 QCP 标签 是 否 无 String 无 QCP 附件 链接 否 否 无 附件 无 其他 标签 否 否 无 String 无 其他附件 链接 否 否 无 附件 无 是否结案 单选框 是 否 无 String 无 是否需根据改 善 单选框 是 否 无 String 无 追踪改善确认 时间 标签 是 否 无 String 无 审核 标签 是 否 无 String 无 最终结案天数 标签 是 否 无 String 无 表 4-6 T_OC_FinalClosing 表:最终结案表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 客诉有效性 单选框 是 否 有效 Int 判断客诉是否 有效 处理方式 单选框 是 否 无 String 处理方式 最终处理结果 文本框 是 否 无 String 反馈给用户的 结果 是否回访 单选框 是 否 否 Int 确认回访 是否邮件通知 下一处理人 复选框 否 否 无 邮件格式 发送邮件 是否短信通知 客户 复选框 否 否 无 Int 发送短信给客 户 表 4-6 T_OC_Returning 表:回访表 字段字段 控件类型控件类型 必填必填 只读只读 默认值默认值 有效数据有效数据 逻辑说明逻辑说明 问题一 标签 问题一分值 单选框 是 否 无 Int 统计客户满意 度 问题二 标签 问题二分值 单选框 是 否 无 Int 统计客户满意 度 问题三 标签 问题三分值 单选框 是 否 无 Int 统计客户满意 度 问题四 标签 问题四分值 单选框 是 否 无 Int 统计客户满意 度 问题五 标签 问题五分值 单选框 是 否 无 Int 统计客户满意 17 度 其他 文本框 否 否 无 String 统计客户满意 度 18 第五章 系统详细设计与实现 5.1 系统首页 系统首页主要包括各个子模块的快捷入口和不同类型客诉统计， 以及当前登陆用 户的待办工作提醒。 5.1.1 系统首页界面的展示 系统首页页面见图 5-1 图 5-1 系统首页界面 5.1.2 首页界面部分功能代码展示 HomeController.cs 部分代码如下： public ActionResult Index() var url = string.Format(api/OppleComplaint/StatisticalReports/); var Qcount = this.ApiCaller.GetAs(url + GetQualityCount); var Scount = this.ApiCaller.GetAs(url + GetSupplyCount); var Fcount = this.ApiCaller.GetAs(url + GetFamilyExpensesCount); 19 var Bcount = this.ApiCaller.GetAs(url + GetBusinessCount); var Pcount = this.ApiCaller.GetAs(url + GetP0Count); var Ecount = this.ApiCaller.GetAs(url + GetExtendedCount); var SEcount = this.ApiCaller.GetAs(url + GetSoonExtendedCount); var productcount = this.ApiCaller.GetAs(url + GetProduction_Count); var userinfo = this.ApiCaller.GetAs(url + GetUserInfo?userid= + this.UserIdentity.User_ID); if (userinfo.iscomplaintmanager | Convert.ToInt32(userinfo.departmentid) = (int) v_enum.Department.客诉处理室) var wait2reply_count = this.ApiCaller.GetAs(url + Wait2ReplyCount?userid= + this.UserIdentity.User_ID); var wait2closing_count = this.ApiCaller.GetAs(url + Wait2ClosingCount?userid= + this.UserIdentity.User_ID); ViewDatawait2reply_count = wait2reply_count; ViewDatawait2closing_count = wait2closing_count; else var personasSchedule_count = this.ApiCaller.GetAs(url + PersonalScheduleCount?userid= + this.UserIdentity.User_ID); ViewDatapersonasSchedule_count = personasSchedule_count;