【毕业学位论文】（Word原稿）天津移动定制终端营销管理系统-软件工程

分类号 密级 编号 硕士学位论文 天津移动定制终端营销管理系统 s to 要 I 摘要 2012年中国移动 提出“以终端为载体、合约计划为抓手、客户需求为导向、客户体验为依据 2，整合业务及促销资源、构建多渠道协同销售体系，实现对终端、话音、流量、数据业务的一体化营销”工作目标。 为更好地支撑业务的发展，实现工作目标，解决移动业务与终端销售相互独立，系统间相互分离的问题，在现有二级系统管理支撑架构下建设了天津移动定制终端营销管理系统，以满足终端、话音、流量、数据业务资源整合的一体化营销的管理和支撑要求。 系统 基于面向服务（ 架构体系，在传统基于 B/S 开发的 台 4 层结构基础上进行了改进，并选用 立了一个松耦合、可复用、可扩展、配置化的系统级应用平台。 系统在未来研究中需要 增加营销活动个性化推荐的功能，优化系统兼容性，提升系统易用性。 关键字： 定制终端 营销 资源整合 012 as on of to a of s to to of to of of on a 4 / S 2EE of of a is on a be in to of I 目录 第一章 绪论 . 1 第一节 选题的背景及研究意义 . 1 第二节 课题研究工作 . 2 第三节 论文结构 . 3 第二章 相关技术概述 . 4 第一节 向服务技术架构 . 4 第二节 台 . 5 第三节 . 6 第四节 架 . 7 第五节 架 . 8 第六节 . 9 第七节 台 . 错误 !未定义书签。 第八节 据库 . 错误 !未定义书签。 第九节 小结 . 11 第三章 需求分析 . 12 第一节 任务目标和用户范围 . 12 第二节 系统的整体用例图及系统边界确定 . 12 第三节 定制终端营销管理系统功能点详细描述 . 13 . 13 . 14 . 14 . 14 . 18 口需求 . 18 结 . 错误 !未定义书签。 第四章 设计与实现 . 21 第一节 设计约定和约束 . 21 第二节 开发框架 . 22 第三节 数据库设计 . 25 团下发数据新增实体 . 25 约计划产品模型新增实体 . 40 目录 集采终端涉及实体改造 . 43 第四节 功能模块的设计与实现 . 44 体流程设计 . 44 . 47 第五节 系统接口的设计与实现 . 59 第六节 系统错误、异常的设计 . 61 错误、异常分类 . 61 错误、异常信息记录输出 . 62 错误、异常处理技术实现 . 62 第七节 小结 . 63 第五章 测试与运行 . 64 第一节 系统软硬件情况 . 64 第二节 系统物理部署图 . 65 第三节 系统运行时截图 . 65 终端营销活动审核 . 65 定制终端信息查询 . 66 终端营销活动办理 . 67 终端营销活动取消 . 68 终端营销活动返销 . 68 参加终端营销活动 用户过户 . 68 参加终端营销活动用户销户 . 69 参加终端营销活动用户转网 . 70 参加终端营销活动用户取消平台业务 . 70 参加终端营销活动用户取消流量套餐 . 71 加终端营销活动用户取消 务 . 72 第四节 压力测试 . 73 测试结果 . 73 第六章 总结 . 79 参考文献 . 78 致谢 . 79 目录 一章 绪论 1 第一章 绪论 本章介绍了天津移动定制终端营销管理系统的研究背景及研究内容，提出了天津移动定制终端营销管理系统的必要性和紧迫性，并在此基础上指出通信运营商建设此系统对未来营销管理和支撑的意义。 第一节 选题的背景及研究意义 中国移动提出了“以终端为载体、合约计划为抓手、客户需求为导向、客户体验为依据，整合业务及促销资源、构建多渠道协同销售体系，实现对终端、话音、流量、数据业务”的一体化营销模式，以改变目前移动业务与终端销售相互独立，系 统间相互分离的现状，实现对全网级“终端 +业务”合约计划营销的支撑；并逐步扩展社会连锁渠道和第三方电子商务平台实现“终端 +业务”合约计划的营销。 为更好地支撑业务的开展，在二级系统管理支撑架构下，建设了天津移动定制终端营销管理系统，通过新增产品模型，新增业务流程及业务办理界面等改造，满足终端、话音、流量、数据业务的一体化营销的管理和支撑要求。 在本次建设中，通过省级系统功能与一级系统接口改造，需要实现如下业务目标： 接收一级定制终端营销管理系统下发的全网统一营销资源数据、全网统一合约计划数据以及合约折让 /赠费 规则数据，在省定制终端营销管理系统中完成对应的套餐及合约配置工作，生成客户在营业厅订购“终端+业务”时，可选购的“终端 +业务”产品及自动计算出应补缴的购机款、预存金额等。 移动自营营业厅和签约社会渠道，采用终端折价销售 +客户预存话费的方式销售合约机。通过开发一体化销售界面，实现终端 +业务的购物车第一章 绪论 2 式营销流程。各营业厅（零售店）通过定制终端营销管理系统，完成“终端 +业务”捆绑销售，省定制终端营销管理系统采集“终端 +业务”销售订单。省级定制终端营销管理系统通过两级接口，向一级定制终端营销管理系统同步的销售订单，一 级定制终端营销管理系统从销售订单中采集客户订购的终端销售信息和捆绑的合约信息，进行销量统计和酬金结算。 非签约社会渠道，采用终端合约价销售 +向客户赠送话费的方式销售合约机。购机客户通过二码合一激活短信，向一级定制终端营销管理系统申报承诺合约并申请得到赠送话费。一级定制终端营销管理系统对购机客户申请进行鉴权，对通过鉴权的客户申请，生成客户赠费指令下发给省定制终端营销管理系统。省定制终端营销管理系统需要根据收到的赠费指令，为客户订购开通合约，并捆绑赠送话费。 第二节 课题研究工作 本文主要研究天津移动定制终端营 销管理系统的设计与实现，整个过程中主要完成了以下 4 个方面工作： 天津移动定制终端营销管理系统需求分析。通过对目前终端产品、资费产品、流量产品、数据业务的分析总结出了本课题所要完成的定制终端营销管理系统需求，又通过对目前终端类营销活动的分析总结出定制终端营销管理系统应具有的的用户体验，两者相结合最后完成了本课题所要完成的定制终端营销管理系统的需求分析。 天津移动定制终端营销管理系统整体设计。在其他运营商现有成果的基础上完成天津移动定制终端营销管理系统整体设计，并确定天津移动定制终端营销管理系统开发中的层次划 分。 根据需求分析和详细设计，最终实现天津移动定制终端营销管理系统，及达到需求列表中所要求的各种用户需求。 第一章 绪论 3 对已开发完成的天津移动定制终端营销管理系统进行测试，验证天津移动定制终端营销管理系统的有效性和可靠性。 第三节 论文结构 通过对软件工程理论的学习，将软件工程规范的开发过程用于系统实际开发中，并按照软件开发规范流程组织了本次论文的章节结构。各章节的内容安排如下所述： 第一章：说明了 天津移动定制终端营销管理系统的研究背景及研究内容，提出了天津移动定制终端营销管理系统的必要性和紧迫性，并在此基础上指出通信 运营商建设此系统对未来营销管理和支撑的意义。 第二章：介绍了该天津移动定制终端营销管理系统开发中所涉及到的关键技术， 向服务技术架构、 架、 架、 台和 据库。 第三章：阐述了天津移动定制终端营销管理系统的需求分析，首先描述了整体用例图及系统边界确定，然后通过文字和图表相结合的方式详细说明了用户对该系统的总体功能需求。 第四章：首先介绍了天津移动定制终端营销管理系统涉及的约定和约束以及开发框架，并阐述了选择开发 框架的原因，然后描述了数据库的设计结构和详细功能和系统接口的设计，最后介绍了系统错误、异常的设计和优化系统性能设计。 第五章：描述了天津移动定制终端营销管理系统的软硬件的配置情况，并展现了系统的物理部署图。以细化的功能模块为基本单位分别展示了运行时的界面，使读者对系统有更具体的了解。最后以需求中的用例为单位进行了系统的功能性测试，以表格的形式给出了测试的最终结果。 第六章：首先说明了本文的背景及意义，然后说明了本文所做的工作，最后 叙述了本文所做工作的后续工作。 第二章 相关技术概述 4 第二章 相关技术概述 在实现天津移动 定制终 端营销管理系统 过程中，需要选择相关技术来进行支撑。本章主要围绕 发的关键技术进行描述。 第一节 向服务技术架构 叫面向服务体系结构或面向服务架构）是指为了解决在 过连接能完成特定任务的独立实体来实现的一种软件体系架构。 一种构建分布式系统的方法，这些系统把应用功能以服务的形式提供给其他服务调用。服务是一个具有清晰定义的、可以被调用的业务功能单元，通过在外围接口进行定义，与服 务的实现相互独立，在服务的请求者与服务的提供者之间提供通道。可以通过标准的通讯协议进行通讯，提供交互性、位置透明化“一个面向服务体系架构 (一个用于整合业务流程和支持 础设施的框架，通过对其中作为安全、标准化的组件 服务的复用和组合来解决业务优先级的改变问题”。 如下特点： 松耦合：服务依赖性小，比较独立。 标准性：应用由服务之间定义良好标准的接口。 自治性：服务提供商完全的控制了其所提供的业务逻辑。 抽象性：服务对消费者隐藏了具体业务逻辑的实现。 复用性：将业务逻辑划分为多个可重用 的服务。 流程化：通过服务的流程化调用完成业务功能。 可见性：基于服务描述去发现和访问服务。 系架构带来的主要观点是业务驱动。以业务服务作为基础对项目进行建模，这样就能产生清晰的业务及系统视图；以业务服务作为基础所实现的系第二章 相关技术概述 5 统具有更强的灵活性、复用性、也能更快地应对业务需求的变化；以业务服务作为基础，定义、描述、实现和管理业务层次的服务，将开发重点放到服务的合成上，便于新的业务需求和流程的改进、优化，更具可靠性、稳定性的被交付使用。 第二节 台 在许多企业级应用中，许多企业级应用框架的需 求（例如数据库连接、邮 件服务、事务处理等）都是一些通用的企业需求模块，这些模块如果每一次都要求开发人员进行开发的话，将会造成开发周期长、代码可靠性差等问题。于是许多大公司开发了一套自己的通用模块服务，也就是我们经常说的中间件。中间件处在操作系统和和应用程序之间，它将应用程序运行环境与操作系统隔离，从而使应用程序开发者可以直接关注应用程序在解决问题上的能力，而不必忧虑更多的系统问题。著名的软件设计大师 框架进行了如下的定义：框架是整个系统或系统的一部分的可重用设计，由一组抽象的类 及其实例间的相互作用方式组成。一个框架就是一个可复用的设计构件，它具有即插即用的可重用性、成熟的稳定性以及良好的团队协作性。但是由于中间件种类众多，许多公司都有一套自己的、独立的中间件，与用户的沟通都各有不同，导致用户无法将不同公司的中间件组装在一块为自己服务。于是提出标准的概念。 是基于 术的一系列标准。从整体上讲， 使用 术开发企业级应用的事实上的工业标准。 用了多层的分布式体系结构，应用逻辑按功能划分为不同的组件。组件之间根据自己所在的层分布在不同的机 器上或者也是可以在同一台机器上，这种分层方法克服了两层模式的弊端 10。在传统 B/S 模式中，虽然第一次部署时比较容易，但是不便于日后升级或改进，可维护性很不理想，同时这种系统常基于某种特定的协议通用性很差，它使得重用业务逻辑和界面逻辑非常困难。现在 多层企业级应用能够为不同的各种服务提供一个独立的层。但在大多数的实际项目应用中，数据第二章 相关技术概述 6 层是关系型数据库，不能明确映射要实现的面向对象的机制，业务逻辑层与数据库交互的过程需要对数据库调用接口做进一步的封装，这在项目的开发和维护上会增加了一定的复杂性和管 理的难度。基于上述原因，后来对此结构进行了改进：在业务逻辑层与数据库之间增加数据持久层，隐藏有数据访问代码细节，将客户应用程序和底层存储机制隔离开，完全抽象出开发应用程序时使用的数据物理细节。 第三节 由 司和许多公司参与共同建立的一种使软件开发者可以响应客户端请求，而动态生成 其他格式文档的 页的技术标准，在 用开发中大多作为应用表现层的开发技术。 承了 言移植性强的特 点，允许开发人员开发和维护与平台无关、内容丰富的动态 面，使得搭建网络平台、建立 站变得轻而易举。并且开发人员不用修改底层内容，即可修改整体的页面布局。 在普通 嵌入了 码的一个脚本 7，构成 面。 面请求时，首先执行的是程序脚本，然后将执行结果以 式返回给客户。所有程序的执行都是在服务器端完成的，将得到的结果通过网络传送给客户，因此对客户浏览器的要求很低。现在 E 已经成为电子商务网站、动态网站和 用与服务开发的首选，作为这一平台的基础， 重要性日益突出，并在极短的时间内得以迅速普及。采用 发 用具有以下好处： 复用性强。除了系统之外，代码不用做任何更改。 要是在操作系统的 拟机）上运行，而基本上所有的平台都能运行 系统的多平台支持。基本上可以在任意环境中开发，在任意环境中部署，在任意环境中扩展，代码重用性能异常出色。 第二章 相关技术概述 7 强大的可伸缩性。从只有一个小的 件就可以运行 多台服务器进行集群和负载均衡，再到多项 行事务和消息处理。 示了其强大的实用价值。 多种功能强大的开发工具支持。 许多非常优秀的开发工具，并且由于 开源特性，很多优秀的开发工具可以免费得到，并且其中大部分可以在多平台顺利运行。 自由扩展的标签。开发人员能自由扩展 签，自定义标签库，并且能利用 强大功能。 该是未来发展的趋势，尤其是电子商务类的网站，多采用 界上一些大的电子商务解决方案提供商都采 第四节 架 架足基于 式 控制器）模式的框架。 件基金组织 目的一个子项目， 术的前身是 写的 构。在 E 的 用发展初期，除了使用 术外，普遍采用 码混合的方式进行开发。由于表现与业务逻辑的代码混合在一起，给前期开发和 后期维护带来巨大的复杂度。为了摆脱上述的约束与局限，把业务逻辑代码从表现层中清晰的分离出来， 2000 年， 用了 设计模式开发来该框架产品被认为是 广泛、最流行的 用框架。架的核心是一个弹性的控制层（基于 标准技术），和类库（如 ）。基于 用程序基本上符合 设计标准，可以说是一个传统 计模式的一种变化类型。 英文中是“支架、支撑”的意思，这表明了 用开发中的巨大作用，采用 以更好地遵循和实现 式。此外， 供了一套完备的规范，以及基础类库，第二章 相关技术概述 8 可以充分利用 优点，减轻程序员的工作量，具有很强的可扩展性。此外， 一个开源项目，这是它的一大优点，使开发者能够更深入的了解 内部机制，对于 发展具有深远的影响。 第五节 架 一个开源框架，是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构，分层架构允许您选择使用哪一个组件，同时为 用程序开发提供集成的框架。 架是轻量级的 用程式框架，旨在简化 开发，降低 目实施难度 1819，它一个分层架构，由 7 个定义良好的模块组成。 心容器定义了创建、配置和管理 方式组成 架的每个模块（或组件）都能单独存在 ，或者与一个或多个模块联合实现。每个模块的功能如下： 核心容器：核心容器提供 架的基本功能。其主要组件是是工厂模式的实现。通过控制反转（ 式将应用程序的配置和依赖性规范与应用程序代码分开。 下文： 下文是一个配置文件，向 架提供上下文信息，包括 子邮件、国际化、校验、调度功能等企业功能。 过配置管理特性， 块直接将 向方面编程）功能集成到 架中。可以很容易地使 架管理的任何对象支持 过使用 用依赖件，就可以将声明性事务管理集成到应用程序中。 象层提供了异常层次结构，可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理，并且极大地降低了需要编写的异常代码数量。 第二章 相关技术概述 9 架插入了若干个 象关系映射）框架，从而提供了 对象关系工具，其中包括 下文模块建立在应用程序上下文模块之上，为基于 应用程序提供了上下文。所以， 架支持与 集成。 架是一个全功能的构建 用程序的 现。 通过策略接口， 架变成为高度可配置的，并容纳了大量视图技术，包括 架的功能可以在任何 务器中使用，其核心要点是：支持不 绑定到特定 务的可重用业务和数据访问对象。毫无疑问，这样的对象可 以在不同 境、独立应用程序以及测试环境之间重用。 第六节 据库连接）是一种用于执行以为多种关系数据库提供统一访问，它由一组用 言编写的类和接口组成。 供了一种基准，据此可以 构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序。要实现应用程序与数据库的连接，通常用到两个类 和 由独立厂商提供，负责建立数据库连接和处理所有与数据库的通讯。 负责管理 动程序，作用于用户和驱动程序之间。在使用 动程序之前，必须先加载驱动程序并向 册后才能使用。 系结构是 用程序连接数据库的标准方法。对 序员来说，它是 数据库供应商来说则是接口模型，按照 准与其它数据库连接。有了 能轻而易举的向各种关系数据发送 句。继承了 植性强的特点，通过 论是访问 据库，还是访问 据库，又或者访问 据库；无论是在 统，还是 统， 第二章 相关技术概述 10 又或者是 统，只需用 一个程序就够了。 第七节 台 由企业发布的完成其特定商务需求的在线应用服务，其他公司或应用软件能够通过 访问并使用这项在线服务。 一种构建应用程序的普遍模型，在所有支持网络通信的操作系统中都能实施运行；它是一种新的 用程序分支，是自包含、自描述、模块化的应用，可以发布、定位和通过 用。 一个应用组件，逻辑性的为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式如 来访问 过 部执行得到所需结果。 以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他 用程序可以发现并调用它部署的服务，在构建和使用 ，主要用到以下几个关键的技术和规则： 扩展标记语言）是 台中表示数据的基本格式。除了易于建立和易于分析外， 要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。 好以后，你或者其他人就会去调用它。 单对象访问协议）提供了标准的 法来调用 际上， 这里有点用词不当：它意味着下面的 以对象的方式表示的，但事实并不一定如此：你完全可以把你的 成一系列的 仍然使用 行调用。 范定义了 息的格式，以及怎样通过 议来使用 是基于 ， 数据编码方式。 如何介绍你的 可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的第二章 相关技术概述 11 些非正式的方法至少存在一个严重的问题：当程序员坐到电脑前，想要使用你的 们的工具 (如 法给他们提供任何帮助，因为这些工具根本就不了解你的 决方法是用机器能阅读的方式提供一个正式的描述文档。是这样一个基于 语言，用于描述 数和返回值。因为是基于 ，所以 是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的 能导入 成调用相应 为加速 强 基于标准的服务描述和发现的规范 (以资源共享的方式由多个运作者一起以 形式运作 用描述、发现与集成服务）商业注册中心。 划的核心组件是 业注册，它使用 档来描述企业及其提供的 第八节 据库 世界上最大的 系型数据库管理系统 ）供应商， 过数据、关系和对数据的约束三者组成的数据模型来存放和管理数据。在管理信息系统、企业数据处理、因特网及电子商务等领域有着非常广泛的应用。因其在数据安全性与数据完整性控制方面的优越性能，以及跨操作系统、跨硬件平台的数据互操作能力，使得越来越多的用户将 为其应用数据的处理系统。 第九节 小结 本章说明并介绍了此系统中涉及的关键技术，并阐述了这些技术的特点以及第三章 需求分析 12 在系统设计中选用这些技术的原因。第三章 需求分析 在软件的开发过程中，系统的需求分析占据了重要的位置。本章首先介绍了 天津移动定制终端营销管理系统的任务目标和用户范围，并结合实际需求，通过文字、系统用例图和系统数据流图相结合的形式说明了用户对系统总体功能的需求。 第一节 任务目标和用户范围 中国移动提出了“以终端为载体、合约计划为抓手、客户需求为导向、客户体验为依据，整合业务及促销资源、构建多渠道协同销售体系，实现对终端、话音、流量、数据业务”的一体化营销模式，以改变目前移动业务与终端销售相互独立，系统间相互分离的现状，实现对全网级“终端 +业务”合约计划营销的支撑；并逐步扩展社会连锁渠道和第三方电子商务平台实现“终端 +业 务”合约计划的营销。为更好地支撑业务的开展，在二级系统管理支撑架构下，建设了定制终端营销管理系统，通过新增产品模型，新增业务流程及业务办理界面等改造，满足终端、话音、流量、数据业务的一体化营销的管理和支撑要求。 第二节 系统的整体用例图及系统边界确定 整个天津移动定制终端营销管理系统构建在 台上，在 间件平台之上，设计并实现 定制终端营销管理 系统的公共基础服务子系统（通信服务 /接口管理、工作流引擎、本地化管理、实现多语言版本、安全管理、分派管理、业务对象管理、展现层管理等服务组件），基于这 些基础服务之上，设计与实现业务逻辑对象实例，再实现数据展现层的用户界面。 天津移动定制终端营销管理 系统按两级结构进行组织，即在集团总部及各省第三章 需求分析 13 分别建立系统，集团总部与省级系统之间通过一级 定制终端营销管理 系统的两级架构强调了系统的物理组织分布形式，而在技术上、以及业务层面的表现方面，总部及各省系统应共同构成一个有机的统一整体。 图 统功能模块用例分析图 第三节 定制终端营销管理系统功能点详细描述 销资源组织管理 对全网统一营销资源数据、合约计划数据和客户应缴费计算规则数据进行系统内部的管理、配置，实现营业员可通过界面查询全网合约计划中可选的营销资源列表，协助客户组合完成全网合约；客户订购合约中包含的各类营销资源，包括语音、流量、增值业务等可以正常记录、提供服务并计费。 下发的合约数据包括： 全网统一营销资源数据：是总部定义的可以和 定制终端捆绑销售的资源，包括：资费套餐（纯语音套餐）、数据包流量套餐、 时长套第三章 需求分析 14 餐、 据业务、客户承诺月最低消费、在网时长，营销资源通过灵活组合，可以组成客户签订的合约。 全网统一合约计划数据：是总部定义的以定制终端机型 为索引的客户可选合约列表。合约中可包含：资费套餐（纯语音套餐）、数据包流量套餐、 据业务、客户承诺在网时长等资源，客户可在各类资源中自由选择，组合成自己的合约计划。 全网统一客户折让 /赠费规则：是总部定义，可以根据客户选择的合约计算客户应缴费用的规则。规则中定义了客户的月消费档次、承诺时长等参数。当客户选购合约后，省 以根据这些参数，检索出客户实际购机款、客户预存话费、话费分月返还额等规则。 全网统一合约机零售价：总部统一制定的全网统一合约机零售价。包 括裸机零售价、合约零售价、省移动公司结算价等价格参数。 制终端信息管理 完成定制终端相关机型参数的配置，同时管理省级定制终端机型编码与全网定制终端物料编码的对应管理，并支持相关业务人员管理界面查询、更新、管理等功能。 价管理 支持计算客户购买合约机折让价格和预存话费，在通过界面组合完成全网合约后，可根据系统中记录的终端销售价格和全网统一客户折让 /赠费规则，检索出客户的“客户购机补贴金额”、“客户预存话费”、“实缴购机款”， 并可据此完成后续客户缴费、打印发票等功能。 端销 售管理 支持客户通过界面完成“终端 +合约”订购的功能， 在移动自营渠道和签约社会渠道，需要向客户提供一体化营销预存购机方案。预存购机方案要第三章 需求分析 15 求客户选购全网统一套餐，并根据客户选购的全网统一套餐得到客户每月最低消费金额，签订合约。 具体业务流程可分为如下环节： 图 预校验环节流程图 流程说明：此流程图中包括客户明确办理意愿、客户品牌及已有合约预校验两个环节。客户明确办理意愿环节：客户抵达省公司营业厅，明确其办理终端 +套餐合约的意愿。客户品牌及已有合约校验环节：省公司营业厅营业员在 获得客户手机号码的前提下，查明客户手机号码的所属品牌、以及合约产品和套餐产品的订购情况。如果客户所属品牌与本合约或合约中欲办理的套餐产品不相符，则由营业员提示客户，让客户考虑办理转品牌，或只订购客户所属品牌的套餐产品。如果客户当前正处在其他类型合约的合约期内，那么客户无法办理本合约计划，需要客户待合约期满时，再到营业厅办理本合约计划。 第三章 需求分析 16 图 约计划选择流程图 流程说明：此流程图中包括选择合约计划环节。选择合约计划环节：营业员为客户办理合约计划及其包含的套餐产品。而客户需要提供营业员，其希望 办理的合约机机型、语音资费套餐、数据包流量套餐、 餐、数据业务，以及合约时长。营业员在终端 +套餐合约受理界面中按照客户的需求，为其定制相应的合约计划。客户选定套餐后，其可自行向上变更月最低承诺消费总金额，以满足不同客户的定制化需求，客户在订购完成后可自行再订购其他套餐产品，以达到本合约的月最低消费金额。 图 端销售订单处理流程图 流程说明：此流程图中包括终端销售订单处理、告知客户终端销售结果环节。终端销售订单处理环节：营业员按照客户意愿，将其需办理的合约以及套餐产品选择完毕后，提 交业务受理，由 统进行实际的第三章 需求分析 17 订单施工。订单施工过程中出现产品规则异常或其他情况，需要营业员向客户解释清楚。告知客户终端销售结果环节：营业员在得到系统的处理结果后，将受理成功的情况告知客户，并将指定的终端提供给客户，并完成终端出库操作。 图 流程说明：此流程图中包括销售订单数据上报一级系统环节。销售订单数据上报一级系统环节：省公司将销售订单详情通过实时接口上报一级系统，一级系统对销售事件进行入库处理。 功能点描述： 全网统一操盘合约计划以终端为载 体，引导客户办理合约所关联的套餐类业务，并承诺相应合约时长。 在客户选择套餐类业务的基础上，根据套餐资费之和，在 全网统一客户折让 /赠费规则中检索出对应最低消费档次，并计算出客户需要缴纳的 终端的购机款与预存 /押金款金额。 在此基础上，用户可根据自己的需要，对 最低消费档次进行人工调整。 最终按客户调整后的最低消费档次、合约时长及 套餐类业务，办理合约。 完成全网统一合约销售后，要求通过接口向一级营销资源管理系统实时同步上报全网统一合约销售数据。保存全网统一合约销售记录和业务开通记录，保证客户通过电话、门户、短信等 客服手段接入后，可查询合约订购关系、订购记录、业务开通状态、业务开通记录等信息。 第三章 需求分析 18 统管理 完成系统相关日志的记录，监控的管理，权限的分配等。 第四节 接口需求 接口名称 业务功能 接口方式 全网统一营销资源 下发总部制定的全网统一营销资源数据 文件接口 全网统一合约计划 总部制定的全网统一合约计划数据 文件接口 全网统一操盘购机客户折让 /赠费价格规则 下发总部制定的全网统一操盘终端购机客户折让 /赠费价格规则数据 文件接口 全网统一操盘合约机零售价格 下发总部制定的全网统一操盘合约机零售价 格数据 文件接口 省公司终端销售事件上报 把终端 +业务的销售数据同步到一级营销资源管理系统 实时接口 促销员数据上报 把省促销员数据同步到一级营销资源管理系统 文件接口 全网统一优惠方案下发 下发非签约社会渠道通过二码合一承诺合约的客户需要执行的营销优惠方案 实时接口 客户赠费指令下发 下发携带客户承诺合约及话费赠送金额的赠费指令 实时接口 客户赠费指令执行结果上报 把省赠费处理结果同步到一级营销资源管理系统 实时接口 第三章 需求分析 19 激活 /赠费指令问题流水对账下发 下发总部未收到处理结果的客户承诺合约激活申请 文件接口 激活 /赠费指令问题流水对账结果上传 把总部下发的未收到处理结果的客户激活申