关键技术标准规范书点对点应答.doc

北京联通电话导航平台114网站 系统改造工程项目技术规范书中华人民共和国联合网络通信有限公司北京市分公司7月目 录1 总则12 卖方技术建议书规定33 卖方报价规定54 工程概述64.1 建设背景64.2 业务现状74.2.1 电话导航业务现状74.2.2 客户资源汇集分析与应用系统现状85 软件设计规定105.1 建设目的105.2 建设原则115.3 软件设计规定115.3.1 客户资源汇集分析系统基本规定115.3.2 总体设计规定125.3.3 系统软件配备145.3.4 应用软件配备145.3.5 前向客户分析增强155.3.6 后向商家分析增强165.3.7 产品分析增强175.3.8 精准营销支撑增强185.3.9 导航业务代理商管理195.3.10 数据汇集增强195.3.11 数据服务支撑增强195.3.12 报表中心增强195.3.13 系统管理增强205.4 软件建设规模206 系统集成某些216.1 卖方应依照下列原则提出详细、完整技术方案建议216.2 卖方应完毕如下集成工作内容216.3 卖方应对整个系统负责226.4 卖方提供详细项目管理及工程实行方案227 工程实行227.1 工程实行筹划227.2 设备安装及调测227.3 测试227.4 初验与试运营条件237.5 试运营237.6 终验237.7 保修237.8 其他238 技术服务和技术培训248.1 技术文献248.2 服务规定248.3 技术培训258.4 工程联系会议258.5 其他251 总则（1）本文献为中华人民共和国联合网络通信公司北京市分公司（如下简称买方）“北京联通电话导航平台114网站系统改造工程项目（如下简称“114网站”）”技术规范书，供厂商及集成商（如下简称卖方）编写建议书和报价之用，建议书内容格式应符合本规范书规定。同步，买方保存其后续项目依照实际状况对本规范进行补充完善权力。卖方在收到本规范书后须在规定期间内，提供满足本规范书技术建议书。逾期则视为自动放弃提供建议书权利。 答：满足。（2）本规范书只是针对北京联通电话导航平台114网站系统改造工程项目，北京联通有权在订立合同前，依照需要修改和补充本规范书，修改和补充后最后规范书将作为合同构成某些。答：满足。（3）未经买方书面允许，卖方不得以任何形式向第三方透露本规范书内容。答：满足。（4）买方在任何时候保存和拥有对本规范书解释权和修改权。答：满足。（5）卖方应提供所供网络通信设备工业和信息化部入网证及有关测试报告。答：满足。（6）卖方所提供设备应保证软件系统是已经大量商用最新版本软件，卖方应对此设备软件硬件所涉及各种专利、知识产权等法律条款承担义务，买方对此不承担任何责任。答：满足。（7）卖方提供软硬件必要为原厂商通过正常销售渠道提供，并具备合法授权。答：满足。（8）卖方应对如下提出每一项规定，如实地阐明其设备支持限度。一方面对实现或满足限度明确做出“满足”、“不满足”等应答，然后做出详细、详细阐明。不得使用“明白”、“理解”、“某些满足”等词语。对同一条款下各种规定不能所有满足应视为“不满足”。建议某些应和其他某些分别进行答复。答：满足。（9）在答复中，规定明确满足限度，凡采用“详见”、“参见”方式阐明，应指明参见文档（如技术建议书等）详细章节和页码。需要做详细解释内容应尽量放在逐条逐项答复中，若内容太多，可放在指明附件中。答：满足。（10）卖方在答复中如无特别阐明，卖方声明支持功能应为设备已实现功能，不涉及有能力支持但尚未实现、近期将要实现、将来筹划实现功能。买方将适时进行验证测试，如发现卖方声明支持功能和性能规定与测试成果不符，将依法保存采用进一步办法权利。答：满足。（11）卖方提供各项设备和系统（涉及软、硬件）功能和性能应完全符合北京联通指明原则，并满足或高于北京联通提出规定。对于文献中未规定有关设备性能，卖方应提出建议，并陈述理由。本规范书应视为保证网络运营所需最低规定，如有漏掉，卖方应予以补充，否则一旦中标，将以为卖方认同漏掉某些并免费提供。答：满足。（12）卖方所提供所有各项设备和系统（涉及软、硬件）应符合关于原则如（ISO、ITU-T、ETSI、IETF等），卖方应在建议书中详细阐明，并附上相应详细技术资料。答：满足。（13）卖方设备和系统如包括非原则扩展合同或自有专用原则，应在建议书中详细阐明，并附上相应详细技术资料（涉及顾客使用手册、技术白皮书等）。若有相应中华人民共和国（或国际）原则确立，卖方应保证在一年内免费过渡到买方规定相应中华人民共和国（或国际）原则。答：满足。（14）卖方应对所有提供产品功能和性能负责。如因卖方配备不合理，而导致所提供产品或采用其提供产品及建议方案建设未能满足本规范书规定，卖方应负所有责任。答：满足。（15）卖方在建议书中应阐明对供货时间、供货质量控制等详细安排。答：满足。（16）卖方在技术建议书中应阐明给买方提供技术文献、技术支持、技术服务、人员培训、厂验等范畴和限度。答：满足。（17）卖方应在建议书中列出提供书面技术资料详细清单。答：满足。（18）规范书关于内容澄清。a）卖方对于规范书疑问可以通过书面材料与买方联系。在规定建议书提交最后期限此前，买方将以书面材料予以答复，关于买方答复材料复印件也将递交所有得到规范书卖方。答：满足。b）在技术谈判各个阶段，买方将以书面形式规定卖方对关于问题进行进一步技术澄清，卖方应以书面资料予以正式应答；所有各阶段技术澄清文献都将作为合同附件。答：满足。（19）本技术规范书中涉及到非本期工程实现内容，依照这些内容，卖方在技术设计时要充分考虑系统可扩展性。答：满足。（20）卖方应提供本工程主机服务器、网络设备、存储设备、系统软件、应用软件和系统集成服务，对服务器提出推荐方案和配备清单。答：满足。（21）卖方承诺所提供应用软件支持主流存储设备、主机服务器、网络设备、数据库软件，并能提供本工程系统集成服务。答：满足。（22）卖方购买系统软件、应用软件必要有合法使用权，自己开发软件也应和招标人明确版权问题。答：满足。（23）卖方承诺所开发系统软件，在系统验收之前，卖方须依照买方规定及时做出设计修改，以保证系统功能完整性和可靠性。答：满足。2 卖方技术建议书规定卖方所提供项目建议书需按顺序必要包括如下章节内容（由于内容不完整性导致一切后果由卖方负责）：（1）综述（2）工程技术规范书点对点应答。逐条对买方规范书应答。对于本规范书内容，卖方应逐项应答，没有编号应逐段应答。答：满足。（3）详细设计和实行方案，至少应涉及如下内容：a.系统承载业务范畴及业务功能解决能力；答：满足。b.系统整体架构，软硬件体系构造；答：满足。c.系统布置方案，对设备和软件配备方案提供详细计算过程；答：满足。d.系统各子系统功能描述，以及各子系统之间控制流、数据流合同格式，对于非原则合同或卖方内部合同应详细描述合同规范和数据格式（规定卖方必要开放各个子系统之间通信合同，对通信合同进行详细技术描述，规定阐明合同中每个字节、每个合同字段功能属性）；答：满足。卖方应提供各项业务功能详细技术实现细节，其中涉及实现一项完整业务流程，系统各子系统间数据通信过程、详细描述流程各阶段、各子系统间通信合同（规定阐明使用设备、合同中某个字段含义、与后台系统交互指令）；答：满足。e.与其她系统系统接口建设方案；答：满足。f.系统功能描述，业务能力及指标描述；答：满足。g.系统安全性、可靠性解决方案；答：满足。h.对既有系统流程影响（规定卖方必要详细描述系统流程变化，对原有流程影响）；答：满足。i.对既有服务器等硬件设备利旧复用方案（规定卖方必要描述并计算系统变化对利旧复用服务器、盘阵等硬件设备影响）；答：满足。j.系统组织连接图（涉及网络和硬件拓扑图以及软件详细布置方案）；答：满足。k.系统监控及管理；答：满足。l.系统集成、后期运维等。答：满足。（4）软件产品和系统配备详细阐明和配备详细清单。答：满足。卖方需提供详细软硬件配备清单，规定详细描述系统布置应用构造，以及对业务支持和实现限度。答：满足。卖方需对提供产品配备建议负责，并保证工程整体实行和集成效果不受影响。答：满足。（5）卖方需依照4.2节中硬件系统布置现状，结合自身软件系统实际状况给出详细软件系统在硬件系统上布置方案，并且提出为实现软件功能，硬件系统必要提供功能，对于未明确提出功能规定所导致系统布置困难，卖方需承担后续补救所产生软、硬件。答：满足。（6）卖方需依照自身软件构造、硬件系统布置方式，对所有双/多机HA系统异常状态切换进行详细描述，本某些需设立“高可用性建设方案”章节进行独立阐明，详细内容应至少包括如下内容：正常状态业务流程及数据流向；正常状态人工主备切换流程及数据流向；异常状态预警工作方式及阈值设立阐明；异常状态切换流程及数据流向；异常状态切换时间及业务中断时间阐明。上述内容需包括相应各服务器详细流程图及文字阐明。答：满足。（7）系统软件和购买第三方软件（第三方资源库）状况（含功能、性能等指标以及软件授权允许license证明文献）。答：满足。（8）安装设备和材料、备件和工具数量清单。答：满足。（9）买卖双方责任及分工界面。答：满足。（10）工程实行筹划。答：满足。a.工程进度表，涉及需求分析、供货、安装、调测、割接、验收等工程各环节。答：满足。b.工程实行和服务人员安排，并提供参加本项目服务人员简历。答：满足。c.工程实行过程中按买方规定提交周报或日报。答：满足。（11）机房场地及环境准备规定以及在工程实行过程中对买方其他规定。答：满足。（12）设备安装规定及建议，抗震加固办法。答：满足。（13）技术文献，涉及但不限于系统阐明文献、技术手册（安装、操作、维护、故障排除等）、系统设计文档、数据字典等。答：满足。（14）买方技术人员和业务使用人员培训。答：满足。（15）验收及测试安排，设备测试、系统测试办法和环境。答：满足。（16）技术服务范畴和限度（涉及技术服务、支持、保修、软件升级等）。售后服务安排及质量保证办法。答：满足。（17）卖方须详细简介卖方公司总体状况（涉及人员构造、公司资质等方面）、曾做过类似运营商项目状况（涉及项目背景、建设规模、系统投运时间点、最后顾客评议等）。卖方必要提供有关工程盖章正式证明材料，如初验报告、终验报告等。答：满足。3 卖方报价规定（1）报价内容应包括： 自有软件报价（含软件LICENSE报价，按照软件模块列明报价）。答：满足。 第三方软件报价（含软件LICENSE费用）。答：满足。 在买方硬件系统之外需补充布置硬件设备报价（含服务器，三层互换机，磁盘阵列，硬件防火墙，监控系统客户端等）。答：满足。 安装辅助材料、备件、工具、仪表、技术文献及安装调测报价。答：满足。 培训报价（含自有软件，第三方软件，硬件设备有关培训）。答：满足。 服务报价（含自有软件，第三方软件，硬件设备最高原厂级别服务）。答：满足。 系统集成费用。答：满足。 凡本次工程需要但上述项目并未列出内容，卖方应包括在报价书中。答：满足。（2）报价应涉及设备名称、型号及配备模块、数量等详细内容。答：满足。（3）卖方提出报价以人民币为单位，应报设备到现场（买方指定地点）价格，运送费单独列出。答：满足。（4）报价应按目录价、折扣价和折扣率分项列清。答：满足。（5）对于卖方向买方建议采用业务和功能，卖方应详细描述和阐明这些业务和功能并作为可选项提出报价。答：满足。（6）卖方对本规范书涉及到服务器、存储系统、操作系统软件、数据库软件等提出合理建议配备，并提供详细计算根据。答：满足。（7）硬件报价规定报出系统所需所有设备价格。答：满足。（8）软件报价规定卖方应提供最新、成熟、稳定软件版本，并注明所提供软件版本号，提供详细功能清单。答：满足。（9）软件报价按如下分类办法系统软件报价：涉及操作系统（如果硬件平台采用商用计算机平台，可包括在硬件报价中）、工具和组件等。答：满足。（10）卖方应承诺买方在后续设备订货时，同一类型软、硬件设备成交价格至少不高于本次合同成交价格，折扣率至少不低于本次合同折扣率。答：满足。（11）服务报价规定卖方应对工程中需要原厂支撑服务进行报价。答：满足。（12）培训卖方就所提供产品提供原厂技术培训，分为高档培训（高档技术人员或管理者）和操作培训；卖方同步提供运维流程培训，保证系统正常运营。答：满足。卖方需就以上培训，列出培训人员数量和费用单价并给出详细培训筹划（涉及时间、地点、课程等）。答：满足。（13）可选报价对于可选软件、硬件和服务或卖方以为可以推荐给买方选取软件、硬件和服务，可单独提出其项目和报价，但不计入总价，并提供技术性能及经济技术比较所需资料。答：满足。4 工程概述4.1 建设背景114电话导航网站（简称114网站）为顾客提供电话导航业务宣传、信息查询、电子商务等综合信息服务。当前114网站已经实现了会员注册、会员管理、积分管理、商家管理、合伙商家产品管理等功能。当前系统详细实现功能涉及：会员注册功能，涉及web网站会员注册功能、话务员代客注册功能和拨打114电话导航顾客自动成为会员功能等。答：满足。会员管理功能，涉及会员资料管理、会员积分管理、订单历史明细查询、会员积分查询等。答：满足。积分管理功能，涉及积分计算、积分规则管理等。答：满足。商家管理功能，涉及商家信息维护、商品分类管理和商品管理。答：满足。支持短信下行功能。顾客短信回答信息时，系统将依照有关规则进行后续解决。答：满足。EXCEL导出功能，会员积分数据和订单数据可以以EXCEL方式进行导出。答：满足。当前，114网站中已经具备400多万左右具备会员注册、会员资料管理顾客，但还无法进行积分兑换等功能；话务员界面还无法支撑为顾客办理通用卡业务，顾客感知减少，影响收益。当前114网站业务数据基本都是从合伙平台获取，由于数据分散在各个合伙平台，网站无法及时精确获取业务运营数据，如订单跟踪等，对业务后续开展影响较大。答：满足。随着互联网业务和手机业务高速发展，WEB/WAP电子商务迅速扩展。中华人民共和国电信从开始启动集团版号百商城，开始，湖南、重庆、江苏、浙江、新疆各省也开始启动本地版号百商城。北京联通作为联通集团114电话导航业务领导者，需要及时适应市场变化，紧跟行业潮流，运用114电话导航品牌和500万前向客户和后向商家资源，大力发展以电话导航品牌服务为基本实物订购业务。答：满足。卖方应充分理解本工程上述建设背景。4.2 业务现状4.2.1 114网站业务现状当前运营商商旅业务重要分为三类：代客预订：例如酒店预订、餐饮预订等。代客预订目的客户重要是商务人士，预订内容需要客户亲自去消费，客户普通在消费单位完毕支付，由消费单位提取一定比例提成费用给运营商。答：满足。实物预订：例如订鲜花、订农产品。实物预订目的客户有消费需求人员，重要是为了以便人们购物消费，需要由支付和物流配送系统支持，这种方式普通由消费者在运营商侧完毕支付，运营商扣除一定比例提成费用后把实物费用结算给实物供应商和物流供应商。答：满足。票务类预订：例如机票预订、火车票预订等。票务类预订业务特点是其预订内容具备稀缺性和垄断性特点，票务代理商或者供应商在资源控制上比较强势，因而在支付方式商和代客预订类似，由票务代理商或者供应商完毕顾客收费后提取一定比例提成费用给运营商；答：满足。当前，北京联通在电话导航平台只实现了自营酒店等某些业务订单流转控制和自营酒店等商家管理，无法进行实物预订和购买。只实现了语音接入，缺少WEB/WAP等新接入方式。答：满足。4.2.2 114网站系统现状4.2.2.1 系统已实现功能模块功能WEB网站产品宣传与发布阳光政务、尾号限行商场折扣与优惠券下载权限管理后台管理WAP网站产品宣传与发布尾号限行114语音查询会员管理会员注册会员资料修改话务员代客注册话务员代客修改资料话务员代客查询积分短信模板管理导入内部员工、VIP会员数据订单查询积分管理积分规则配备积分查询积分短信提示答：满足。4.2.2.2 系统技术框架系统框架采用当前较为流行SSH框架。SSH： Struts（表达层）+Spring（业务层）+Hibernate（持久层） 。Struts： Struts是一种表达层框架，重要作用是界面展示，接受祈求，分发祈求。在MVC框架中，Struts属于VC层次，负责界面体现，负责MVC关系分发。（View：沿用JSP、HTTP、Form、Tag、Resourse ；Controller：ActionServlet、struts-config.xml、Action） 。Hibernate： Hibernate是一种持久层框架，它只负责与关系数据库操作。Spring： Spring是一种业务层框架，是一种整合框架，可以较好地黏合表达层与持久层。答：满足。4.2.2.3 系统总体构造电话导航业务平台建设采用业务与互换分离设计思想，总体构造分三层实现，即互换接入层、功能支撑层、业务实现层。答：满足。（1）互换接入层互换接入层负责各种媒体综合接入，实现语音接入、小灵通短信下行接入、G网顾客短信上下行等各种接入方式。答：满足。（2）功能支撑层功能支撑层负责对呼喊进行统一管理，如完毕对呼喊控制、路由管理、资源管理等，它针对详细业务对话务需求，通过解释转化为任务，向互换接入层提交，在互换接入层配合下，完毕丰富多变话务功能。功能支撑层涉及核心控制服务器、智能路由中心、IVR控制系统、顾客接口服务、业务开发平台等。答：满足。（3）业务实现层业务实现层通过接口按照详细应用话务需求向上层提出需求，结共计算机网络和数据库技术实现详细业务应用。答：满足。业务实现层当前实现业务有114查号业务和电话导航业务。支撑114查号业务应用软件包括如下功能：查询功能、增删改功能、质检功能、IVR功能、记录分析功能、外呼功能以及监控管理功能，并且能依照话务员实际从事话务工作不同设立不同权限。电话导航业务是在114查号应用软件基本上实现增值服务，共包括7大类22项服务。答：满足。4.2.2.4 系统拓扑北京联通114电话导航系统由东四和皂君庙两套接入平台构成，两套平台之间可以构成网络呼喊中心，实现114话务全网均衡、负荷分担以及某些容灾备份功能：当其中某一套平台解决能力不够或者浮现故障，另一套接入平台可以通过网络智能分派系统（NIRC）获得有关控制信息，完毕114业务。答：满足。4.2.2.5 系统接口当前114网站与外围系统接口重要有114网站与汇集分析系统数据接口，与114电话导航平台链接接口。答：满足。（1）与汇集分析系统数据接口此接口涉及汇集分析系统到114网站和114网站到汇集分析系统双向数据接口，用于114网站定期向汇集分析系统同步订单等信息和汇集分析系统定期向114网站同步顾客消费行为等信息。答：满足。（2）与114电话导航平台链接接口此接口用于114电话导航平台话务员代客操作，点击网站链接，页面跳转到114网站代客操作页面。答：满足。4.3 系统需求针对当前114网站现状和订单业务管理现状，以及电子商务行业趋势，需要增强和扩展114网站功能，实现统一实物预订业务门户、统一订单管理、统一支付平台接口、统一物流管理、统一前向客户管理、统一商家合伙伙伴管理，建立面向农产品、鲜花、蛋糕、电影票、杂志等商旅业务集中运营管控。答：满足。5 建设方案5.1 网络拓扑图本工程目的网络拓扑构造如下图：答：满足。5.2 系统架构如下图所示：答：满足。5.3 增强话务员应用模块在既有代客注册、代客修改资料、代客积分查询功能基本上，新增农产品通用卡管理模块、有卡(指农产品通用卡)实物预订模块、实物搜索模块。答：满足。农产品通用卡管理模块涉及农产品通用卡建卡、农产品通用卡充值、农产品通用卡余额查询、冻结金额查询和有效期查询。答：满足。有卡实物预订模块涉及如下功能：订单查询、新增订单、订单修改和订单撤销。答：满足。5.3.1 农产品通用卡建卡功能：下建卡订单，一次性可以动态创立多张不同面值农产品预订卡。可以对卡进行动态删除操作。答：满足。建卡流程图如下：答：满足。5.3.2 农产品通用卡建卡回填功能回填时可以动态对多张卡进行建卡回填， 且系统自动将卡有效期默认填写为当前日期向后推至一年日期。如果回填金额=元,则有效期默以为当前日期向后推至两年日期，且话务员可以手工修改有效期。 答：满足。5.3.3 农产品通用卡充值功能 顾客可以一次为多张农产品通用卡进行充值。 流程图同建卡流程图。答：满足。5.3.4 农产品通用卡充值回填功能回填时可以动态对多张卡进行充值回填， 且系统自动将卡有效期默认填写为当前日期向后推至一年日期。如果回填金额=元,则有效期默以为当前日期向后推至两年日期，且话务员可以手工修改有效期。 答：满足。5.3.5 有卡实物预订功能农产品实物预订卡采用非记名方式制卡发卡。 发卡后，持卡人可以将卡赠送给她人。 答：满足。此卡如果曾经有过交易实物记录，则持卡人使用此卡再次进行购物时候，系统会将此卡近来一次交易人信息自动带入，从而减少了话务员工作量，提高了话务员工作效率，话务员只需确认收货人信息即可。 答：满足。有卡实物预订流程图如下：答：满足。5.3.6 实物订单修改功能话务员点击修改按钮后，旧订单商品信息重新回到购物车后来，话务员可以随意进行如下操作： 更改商品数量、增减商品(只有符合修改规则才干被修改) 。如果新增商品，卡金额局限性，可以添加卡 (所有卡共计可用总金额不不大于等于订购货款时候，提示不让添加新卡) 。答：满足。此功能以便话务员更改订单信息，提高了话务员工作效率。5.4 新增WEB顾客电子商城应用模块该模块涉及WEB商品搜索模块、商品浏览、在线客服模块、积分查询模块、投诉功能模块、历史订单明细模块和个人信息管理模块。答：满足。5.4.1 商品搜索顾客可以通过web网站，通过不同检索条件组合，搜索自己喜欢商品。如果订购，需要打电话让话务员预订。答：满足。5.4.2 在线客服顾客可以通过web网站提供在线客服，如QQ、MSN或电子邮件等方式，向网站服务人员进行网站内有关信息征询，以便顾客理解产品，促成交易。答：满足。5.4.3 积分查询 顾客可以通过web网站自助查询个人积分记录状况，涉及当前总积分、积分来源明细、积分消费明细等。答：满足。5.4.4 投诉功能顾客可以通过web网站提供投诉受理模块进行投诉，投诉方式可以通过电子邮件结合订单状况进行产品、服务等方面投诉。答：满足。5.4.5 历史订单明细顾客可以通过web网站登录成功后，进入自助服务页面，可以通过不同检索条件查询历史订单状况及订单状态。答：满足。5.4.6 个人信息管理模块顾客可以通过web网站登录成功后，进入自服务页面，可以修改个人信息，涉及姓名、电话、通信地址等信息。答：满足。5.5 增强WAP应用模块。当前WAP提供了产品预订、交通出行、通信助理业务征询114电话直拨功能。本期新增涉及WAP方式注册、WAP方式积分查询、预约挂号、随身号薄、商务总机、优惠券等功能。答：满足。5.6 增强商家应用模块增强商家商品维护模块、新增商家投诉解决模块、客服应答解决模块、商家订单解决模块、商家信息维护模块、商家配送模块、商家记录分析服务和商家管理功能模块。答：满足。5.6.1 商家商品维护模块涉及商品上架、下架，商品审核，商品模板维护，商家通过商品管理对属于自己范畴内商品信息进行维护和及时提示。答：满足。5.6.2 商家投诉解决模块针对于web网站客户投诉信息进行回答。答：满足。5.6.3 客服应答解决模块针对于前台web网站客户实时问题征询做应答解决，如询问商品等信息等。答：满足。5.6.4 商家订单解决模块商家对订单管理，如审核、跟踪，商家对分流到自己订单可解决给物流公司。答：满足。5.6.5 商家信息维护模块商家自服务中可以对公司信息进行维护，如修改商家地址、商家名称、商家编码等信息。答：满足。5.6.6 商家配送模块商家对于配送环节管理，商家可进行可视物流选取。答：满足。5.6.7 商家记录分析服务商家对商品库存记录、销售商品排名(按照不同步间)、订单记录等。答：满足。5.7 新增中台业务人员应用模块涉及业务报表记录模块、商品管理模块、中台业务人员订单管理模块。答：满足。5.7.1 业务报表记录模块业务报表记录模块涉及如下功能：订单记录、商家记录、商品记录、WEB顾客记录、销售排行、点击排行、评论排行、物流结算、客户信息查询、订单查询、配送回执查询、应收账款查询、销售收入分析、报表记录分析和销售数据记录等记录报表管理。答：满足。5.7.2 商品管理模块商品管理模块涉及如下功能：审核商品、删除商品、新增商品、商品模板维护、新增商品模板、商品发布等。答：满足。5.7.3 订单管理模块订单管理模块涉及订单分发、订单审核、订单跟踪。答：满足。订单分发功能：二线合伙方管理人员可以对建卡订单池、充值订单池和实物订单池分别进行管理，可以依照检索条件，定位到不同配送日期待派发订单，然后可以批量选中待派发订单，分发给指定二线操作员。已派发订单会从订单池中移走。答：满足。订单审核功能：二线操作员没有权限对订单进行修改和撤销，因此二线操作员遇到解决不了订单，会将订单所有回传给二线管理人员。二线管理人员会对这些订单进行审核，依照回传因素进行修改或者撤销。答：满足。5.8 增强后台管理员应用模块。涉及会员管理模块、商家管理模块、配送方式维护模块、支付方式维护模块、信息管理模块、页面管理模块、业务报表记录模块、系统管理员模块。答：满足。5.8.1 会员管理模块会员管理模块涉及：会员增长、会员修改。答：满足。5.8.2 商家管理模块商家管理模块涉及：新增供应商、修改供应商和删除供应商。答：满足。5.8.3 配送方式维护模块配送方式维护模块实现商家配送方式修改操作。答：满足。5.8.4 支付方式维护模块支付方式维护模块实现通用卡支付和货到付款操作。答：满足。5.8.5 话务员管理模块话务员管理模块涉及：话务员增长、话务员修改、话务员删除。答：满足。5.8.6 114网站信息管理模块114网站信息管理模块涉及：增长信息、栏目维护和留言管理。答：满足。5.8.7 114网站页面管理模块114网站页面管理模块涉及：增长广告、广告管理、增长页面和页面管理。答：满足。5.9 新增订单管理引擎涉及订单池、订单解决角色分类、订单流程、订单功能模块。答：满足。5.9.1 订单池系统对所有已经确认后征询单自动池化，生成订单总池，池中包括所有未经解决订单。重要状态为：未解决和变更未解决订单。答：满足。5.9.1.1 订单分拣：订单分为话务员手工领取、系统自动派发、二线管理人员进行手工派发。答：满足。5.9.1.2 二线管理人员手工派发二线管理人员派发订单流程图如下：答：满足。5.9.1.3 话务员手工领取：二线话务员登录系统后，对未解决和变更未解决订单做分派操作，领取订单，二线管理员针对领取后订单进行审核和分派解决，系统支持同步领取各种订单动作。但对于已领取未解决订单达到指定期间未进行下一步解决时，自动弹回订单池，并记录弹回日记。在进行订单领取时，系统对订单进行锁定操作，一旦锁定，其她顾客将只能进行查看操作。不能进行领取操作。答：满足。答：满足。5.9.1.4 系统自动派发：如果订单在指定期间（系统设定）内没有被任何操作员领取，系统将随机分派给选取话务员。答：满足。5.9.1.5 订单预警：系统在订单池中订单数量达到一定数目（系统设定）时候自动预警，红色字体显示。系统在订单池中超期（系统设定）订单进行预警，并以红色显示。系统在订单距离超期时间（系统设定）尚有指定期间（系统设定）时候，自动预警（黄色显示）。答：满足。5.9.2 订单角色分类订单解决角色分类是依照订单业务使用对象不同，将系统使用者分为一线话务员、二线话务员、商家和业务管理员。答：满足。5.9.2.1 一线话务员：为顾客提供订购业务服务接线员，一线话务员对订单进行征询、订单生成操作。答：满足。详细涉及：生成建卡订单，生成充值订单，使用农产品通用卡进行实物预订，以及对三种订单管理，涉及查询、修改和撤销。一线话务员并被以解决订单效率为原则进行绩效考核 ；答：满足。5.9.2.2 二线话务员：负责审核订单、解决催单，通过和商家沟通，确认能否为已经申请成功订单提供服务，负责对订单解决过程进行催分派，催联系等；答：满足。当前二线话务员分为合伙方管理员和合伙方操作员，合伙方管理员对订单进行派发、对订单进行修改和撤销操作；合伙方操作员对订单进行详细解决，涉及配送确认、回填确认、到货签收确认操作。答：满足。5.9.2.3 业务管理员：负责核对订单，通过和商家沟通，确认订单数量，以及佣金结算。答：满足。5.9.3 订单流程订单流程如下图所示：答：满足。5.9.4 订单功能模块重要涉及新增订单、订单修改、订单撤销、订单状态查询、订单监控、历史订单查询、订单记录分析。答：满足。5.9.4.1 新增订单：话务员代客操作或顾客自己通过网站进行农产品通用卡预订、对通用卡进行充值、使用农产品通用卡进行实物预订,产生订单。答：满足。使用农产品通用卡进行实物预订，如果当前使用卡已有过交易记录，则本次交易会自动将本卡近来一次交易收货人信息带入系统，话务员依照实际状况进行修改或者只对信息进行核对即可。节约了话务员工作量，提高了工作效率。答：满足。5.9.4.2 订单修改：话务员代客或顾客自己通过网站修改订单信息，如修改商品、数量、配送地址。答：满足。对于建卡订单和充值订单：话务员可以代客进行修改除卡号外任何信息，修改需要在规则范畴内。答：满足。修改实物订单：重新回到购物车后来，话务员可以进行如下操作： 更改商品数量 、增减商品 。答：满足。新增商品卡金额局限性，可以添加卡。(所有卡共计可用总金额不不大于等于订购货款时候，提示不让添加新卡) 答：满足。农产品实物预订卡采用非记名方式制卡发卡。 发卡后，持卡人可以将卡赠送给她人。 答：满足。此卡如果曾经有过交易实物记录，则持卡人使用此卡再次进行购物时候，系统会将此卡近来一次交易人信息自动带入，从而大大减少了话务员工作量，提高了话务员工作效率，话务员只需询问确认收货人信息即可。 答：满足。5.9.4.3 订单撤销：话务员代客或者顾客自己通过网站在指定规则范畴内进行订单撤销。当前实物预订中，撤销订单，会将农产品通用卡中冻结金额退还。答：满足。5.9.4.4 订单状态查询：话务员代客或者顾客在订单流转过程中对订单实时状态进行查询。话务员通过订单管理功能查看所有订单状态，对于已经配送或解决完毕订单，订单不可再被更改或做撤除操作。答：满足。5.9.4.5 订单监控：系统对订单池中订单进行实时监控和预警，如订单数量达到1000份、订单超过3小时无人解决等。答：满足。5.9.4.6 历史订单查询：话务员代客或者顾客通过系统对自己历史订单进行查询。如：查询近一种月订单、按订单分类查询近半年订单等。答：满足。5.9.4.7 订单记录分析：对系统中订单进行记录分析。如：按商家进行记录分析、按订单产生时间进行记录分析、按订单分类进行记录分析等。答：满足。6 软件设计规定6.1 基本规定(1) 卖方应用软件应能支持各类主流服务器；答：满足。(2) 应用软件应支持Windows、Linux或UNIX等主流操作系统； 答：满足。(2) 应用软件应采用分层次体系构造，以便于系统维护和扩展；答：满足。(3) 应用软件应能依照顾客规模不同支持集中解决模式和分布式解决；答：满足。(4) 应用软件应具备较好开放性，以便于与其她应用系统连接；答：满足。(5) 应用软件应能适应各种大型数据库系统，例如Oracle、Sybase等；答：满足。(6) 系统运营应是安全、可靠，具备完善、分级操作/访问权限控制机制；答：满足。(7) 系统应具备数据备份及劫难恢复功能。答：满足。(8) 规定软件采用分层模块化构造，模块之间通信应按规定接口进行。任何一层任何一种模块维护和更新以及新模块追加都不影响其她模块；答：满足。(9) 系统参数、顾客数据与解决程序应有相对独立性。顾客数据任何变更都不应引起运营版本程序变更。解决程序应与系统参数、顾客数据相适应；答：满足。(10) 软件应有容错能力，普通软件故障不应引起各类严重系统再启动；答：满足。(11) 软件设计应有防护性能，某一软件模块内软件错误应限制在本模块内，而不应导致其她软件模块错误；答：满足。(12) 应具备软件运营故障监视功能。一旦软件浮现死循环等重大故障，应能自动再启动，并能出即时故障报告信息；答：满足。(13) 软件具备详细、完善、灵活业务、顾客等数据记录、分析、预测能力；答：满足。(14) 卖方需对销售核心软件某些拥有自主知识产权。答：满足。6.2 总体设计规定（1）卖方应提供本工程各设备运营详细软件配备描述，涉及业务软件模块，及也许涉及设备扩容所使用专业软件，卖方需详细描述各种软件功能、能力限制（license限制）和硬件平台、操作系统支持状况。答：满足。（2）卖方应提供本工程对平台各模块影响，需要列出平台所有功能模块并按下表标记各模块在本工程中与否发生变化。答：满足。模块名新增改造不变针对上表中新增、改造某些，卖方应