技術規(guī)范方案書點對點應答

《技術規(guī)范方案書點對點應答》由會員分享，可在線閱讀，更多相關《技術規(guī)范方案書點對點應答（52頁珍藏版）》請在裝配圖網上搜索。

1、 2011年聯通導航平臺114 系統改造工程工程 技術規(guī)X書 中國聯合網絡通信某市分公司 2011年7月 目 錄 1 總那么 1 2 賣方技術建議書要求 3 3 賣方報價要求 5 4 工程概述 6 4.1 建立背景 6 4.2 業(yè)務現狀 7 4.2.1 導航業(yè)務現狀 7 4.2.2 客戶資源聚集分析與應用系統現狀 8 5 軟件設計要求 10 5.1 建立目標 10 5.2 建立原那么 11 5.3 軟件設計要求 11 5.3.1 客戶資源聚集分析系統根本要求 11 5.3.2 總體設計要求 12 5.3.3 系統軟件配置 14 5.3.

2、4 應用軟件配置 14 5.3.5 前向客戶分析增強 15 5.3.6 后向商家分析增強 16 5.3.7 產品分析增強 17 5.3.8 精準營銷支撐增強 18 5.3.9 導航業(yè)務代理商管理 19 5.3.10 數據聚集增強 19 5.3.11 數據效勞支撐增強 19 5.3.12 報表中心增強 19 5.3.13 系統管理增強 20 5.4 軟件建立規(guī)模 20 6 系統集成局部 21 6.1 賣方應根據以下原那么提出詳細、完整的技術方案建議 21 6.2 賣方應完成以下集成工作內容 21 6.3 賣方應對整個系統負責 22 6.4 賣方提供詳細的工程管理及工

3、程實施方案 22 7 工程實施 22 7.1 工程實施方案 22 7.2 設備安裝及調測 22 7.3 測試 22 7.4 初驗與試運行條件 23 7.5 試運行 23 7.6 終驗 23 7.7 保修 23 7.8 其它 23 8 技術效勞和技術培訓 24 8.1 技術文件 24 8.2 效勞要求 24 8.3 技術培訓 25 8.4 工程聯絡會議 25 8.5 其它 25 1 總那么 〔1〕本文件為中國聯合網絡通信公司市分公司〔以下簡稱買方〕“2011年聯通導航平臺114系統改造工程工程〔以下簡稱“114〞〕〞技術規(guī)X書，供廠商及集成商〔以下簡稱賣方〕編寫

4、建議書和報價之用，建議書的內容格式應符合本規(guī)X書的要求。同時，買方保存其后續(xù)工程根據實際情況對本規(guī)X進展補充完善的權力。賣方在收到本規(guī)X書后須在要求的時間內，提供滿足本規(guī)X書的技術建議書。逾期那么視為自動放棄提供建議書的權利。 答：滿足。 〔2〕本規(guī)X書只是針對2011年聯通導航平臺114系統改造工程工程，聯通有權在簽訂合同前，根據需要修改和補充本規(guī)X書，修改和補充后的最終規(guī)X書將作為合同的組成局部。 答：滿足。 〔3〕未經買方書面許可，賣方不得以任何形式向第三方透露本規(guī)X書的內容。 答：滿足。 〔4〕買方在任何時候保存和擁有對本規(guī)X書的解釋權和修改權。 答：滿足。

5、 〔5〕賣方應提供所供網絡通信設備的工業(yè)和信息化部入網證及相關測試報告。 答：滿足。 〔6〕賣方所提供的設備應保證軟件系統是已經大量商用的最新版本軟件，賣方應對此設備的軟件硬件所涉及的各種專利、知識產權等法律條款承擔義務，買方對此不承擔任何責任。 答：滿足。 〔7〕賣方提供的軟硬件必須為原廠商通過正常銷售渠道提供，并具有合法的授權。 答：滿足。 〔8〕賣方應對以下提出的每一項要求，如實地說明其設備的支持程度。首先對實現或滿足程度明確做出“滿足〞、“不滿足〞等應答，然后做出具體、詳細的說明。不得使用“明白〞、“理解〞、“局部滿足〞等詞語。對同一條款下的多個要求不能全部滿足的應視為“

6、不滿足〞。建議局部應和其它局部分別進展答復。 答：滿足。 〔9〕在答復中，要求明確滿足的程度，凡采用“詳見〞、“參見〞方式說明的，應指明參見文檔〔如技術建議書等〕的具體章節(jié)和頁碼。需要做詳細解釋的內容應盡量放在逐條逐項答復中，假設內容太多，可放在指明的附件中。 答：滿足。 〔10〕賣方在答復中如無特別說明，賣方聲明支持的功能應為設備已實現的功能，不包括有能力支持但尚未實現的、近期將要實現的、未來方案實現的功能。買方將適時進展驗證測試，如發(fā)現賣方聲明支持的功能和性能要求與測試結果不符，將依法保存采取進一步措施的權利。 答：滿足。 〔11〕賣方提供的各項設備和系統〔包括軟、硬件〕的功能

7、和性能應完全符合聯通指明的標準，并滿足或高于聯通提出的要求。對于文件中未規(guī)定的相關設備性能，賣方應提出建議，并陳述理由。本規(guī)X書應視為保證網絡運行所需的最低要求，如有遺漏，賣方應予以補充，否那么一旦中標，將認為賣方認同遺漏局部并免費提供。 答：滿足。 〔12〕賣方所提供的所有各項設備和系統〔包括軟、硬件〕應符合有關標準如〔ISO、ITU-T、ETSI、IETF等〕，賣方應在建議書中具體說明，并附上相應的詳細技術資料。 答：滿足。 〔13〕賣方的設備和系統如包含非標準擴展協議或自有專用標準，應在建議書中具體說明，并附上相應的詳細技術資料〔包括用戶使用手冊、技術白皮書等〕。假設有相應的中國

8、〔或國際〕標準確立，賣方應保證在一年內無償過渡到買方要求的相應中國〔或國際〕標準。 答：滿足。 〔14〕賣方應對所有提供產品的功能和性能負責。如因賣方配置不合理，而造成所提供的產品或采用其提供產品及建議方案建立未能滿足本規(guī)X書要求，賣方應負全部責任。 答：滿足。 〔15〕賣方在建議書中應說明對供貨時間、供貨質量控制等的具體安排。 答：滿足。 〔16〕賣方在技術建議書中應說明給買方提供的技術文件、技術支持、技術效勞、人員培訓、廠驗等的X圍和程度。 答：滿足。 〔17〕賣方應在建議書中列出提供的書面技術資料詳細清單。 答：滿足。 〔18〕規(guī)X書有關內容的澄清。 a〕賣方對于規(guī)

9、X書的疑問可以通過書面材料與買方聯系。在規(guī)定的建議書提交最后期限以前，買方將以書面材料給予答復，有關買方答復材料的復印件也將遞交所有得到規(guī)X書的賣方。 答：滿足。 b〕在技術談判的各個階段，買方將以書面形式要求賣方對有關問題進展進一步的技術澄清，賣方應以書面資料給予正式應答；所有各階段的技術澄清文件都將作為合同附件。 答：滿足。 〔19〕本技術規(guī)X書中涉及到非本期工程實現的內容，根據這些內容，賣方在技術設計時要充分考慮系統的可擴展性。 答：滿足。 〔20〕賣方應提供本工程的主機效勞器、網絡設備、存儲設備、系統軟件、應用軟件和系統集成效勞，對效勞器提出推薦方案和配置清單。 答：滿足

10、。 〔21〕賣方承諾所提供的應用軟件支持主流的存儲設備、主機效勞器、網絡設備、數據庫軟件，并能提供本工程的系統集成效勞。 答：滿足。 〔22〕賣方購置的系統軟件、應用軟件必須有合法的使用權，自己開發(fā)的軟件也應和招標人明確問題。 答：滿足。 〔23〕賣方承諾所開發(fā)的系統軟件，在系統驗收之前，賣方須根據買方的要求及時做出設計修改，以保證系統功能的完整性和可靠性。 答：滿足。 2 賣方技術建議書要求 賣方所提供的工程建議書需按順序必須包含以下章節(jié)的內容〔由于內容的不完整性造成的一切后果由賣方負責〕： 〔1〕綜述 〔2〕工程技術規(guī)X書點對點應答。逐條對買方規(guī)X書的應答。對于本規(guī)X書

11、內容，賣方應逐項應答，沒有編號的應逐段應答。 答：滿足。 〔3〕詳細設計和實施方案，至少應包括以下內容： a.系統承載的業(yè)務X圍及業(yè)務功能處理能力； 答：滿足。 b.系統的整體架構，軟硬件體系構造； 答：滿足。 c.系統的部署方案，對設備和軟件的配置方案提供詳細的計算過程； 答：滿足。 d.系統各子系統的功能描述，以及各子系統之間的控制流、數據流的協議格式，對于非標準協議或賣方內部協議應詳細描述協議規(guī)X和數據格式〔要求賣方必須開放各個子系統之間的通信協議，對通信協議進展詳細技術描述，要求說明協議中的每個字節(jié)、每個協議字段的功能屬性〕； 答：滿足。 賣方應提供各項業(yè)務功能的

12、詳細技術實現細節(jié)，其中包括實現一項完整業(yè)務流程，系統各子系統間的數據通信過程、詳細描述流程各階段、各子系統間的通信協議〔要求說明使用的設備、協議中某個字段含義、與后臺系統交互的指令〕； 答：滿足。 e.與其他系統的系統接口建立方案； 答：滿足。 f.系統功能描述，業(yè)務能力及指標描述； 答：滿足。 g.系統的平安性、可靠性解決方案； 答：滿足。 h.對現有系統流程的影響〔要求賣方必須詳細描述系統流程的變化，對原有流程的影響〕； 答：滿足。 i.對現有效勞器等硬件設備的利舊復用方案〔要求賣方必須描述并計算系統變化對利舊復用的效勞器、盤陣等硬件設備的影響〕； 答：滿足。 j.

13、系統組織連接圖〔包括網絡和硬件的拓撲圖以及軟件的詳細部署方案〕； 答：滿足。 k.系統監(jiān)控及管理； 答：滿足。 l.系統集成、后期運維等。 答：滿足。 〔4〕軟件產品和系統配置詳細說明和配置詳細清單。 答：滿足。 賣方需提供詳細的軟硬件配置清單，要求詳細描述系統部署應用構造，以及對業(yè)務的支持和實現程度。 答：滿足。 賣方需對提供的產品配置建議負責，并保證工程整體實施和集成效果不受影響。 答：滿足。 〔5〕賣方需根據4.2節(jié)中的硬件系統部署現狀，結合自身軟件系統實際情況給出具體軟件系統在硬件系統上的部署方案，并且提出為實現軟件功能，硬件系統必須提供的功能，對于未明確提出的

14、功能要求所導致的系統部署困難，賣方需承擔后續(xù)補救所產生的軟、硬件。 答：滿足。 〔6〕賣方需根據自身軟件的構造、硬件系統的部署方式，對所有雙/多機HA系統的異常狀態(tài)切換進展詳細描述，本局部需設立“高可用性建立方案〞章節(jié)進展獨立說明，具體內容應至少包含以下內容：正常狀態(tài)業(yè)務流程及數據流向；正常狀態(tài)人工主備切換流程及數據流向；異常狀態(tài)預警工作方式及閾值設置說明；異常狀態(tài)切換流程及數據流向；異常狀態(tài)切換時間及業(yè)務中斷時間說明。上述內容需包含對應各效勞器的具體流程圖及文字說明。 答：滿足。 〔7〕系統軟件和購置的第三方軟件〔第三方資源庫〕的情況〔含功能、性能等指標以及軟件授權許可license

15、的證明文件〕。 答：滿足。 〔8〕安裝設備和材料、備件和工具的數量清單。 答：滿足。 〔9〕買賣雙方責任及分工界面。 答：滿足。 〔10〕工程實施方案。 答：滿足。 a.工程進度表，包括需求分析、供貨、安裝、調測、割接、驗收等工程各環(huán)節(jié)。 答：滿足。 b.工程實施和效勞人員安排，并提供參加本工程效勞人員的簡歷。 答：滿足。 c.工程實施過程中按買方要求提交周報或日報。 答：滿足。 〔11〕機房場地及環(huán)境準備要求以及在工程實施過程中對買方的其它要求。 答：滿足。 〔12〕設備安裝要求及建議，抗震加固措施。 答：滿足。 〔13〕技術文件，包括但不限于系統說明文件

16、、技術手冊〔安裝、操作、維護、故障排除等〕、系統設計文檔、數據字典等。 答：滿足。 〔14〕買方技術人員和業(yè)務使用人員培訓。 答：滿足。 〔15〕驗收及測試安排，設備測試、系統測試的方法和環(huán)境。 答：滿足。 〔16〕技術效勞的X圍和程度〔包括技術效勞、支持、保修、軟件升級等〕。售后效勞安排及質量保證措施。 答：滿足。 〔17〕賣方須詳細介紹賣方公司的總體情況〔包括人員構造、企業(yè)資質等方面〕、曾做過的類似運營商工程情況〔包括工程背景、建立規(guī)模、系統投運時間點、最終用戶評議等〕。賣方必須提供相關工程的蓋章的正式的證明材料，如初驗報告、終驗報告等。 答：滿足。 3 賣方報價要求

17、 〔1〕報價內容應包含： ① 自有軟件報價〔含軟件LICENSE報價，按照軟件模塊列明報價〕。 答：滿足。 ② 第三方軟件報價〔含軟件LICENSE費用〕。 答：滿足。 ③ 在買方硬件系統之外需補充部署的硬件設備報價〔含效勞器，三層交換機，磁盤陣列，硬件防火墻，監(jiān)控系統客戶端等〕。 答：滿足。 ④ 安裝輔助材料、備件、工具、儀表、技術文件及安裝調測報價。 答：滿足。 ⑤ 培訓報價〔含自有軟件，第三方軟件，硬件設備的相關培訓〕。 答：滿足。 ⑥ 效勞報價〔含自有軟件，第三方軟件，硬件設備的最高原廠級別效勞〕。 答：滿足。 ⑦ 系統集成費用。 答：滿足。 ⑧ 凡本次工

18、程需要但上述工程并未列出的內容，賣方應包含在報價書中。 答：滿足。 〔2〕報價應包括設備名稱、型號及配置模塊、數量等詳細內容。 答：滿足。 〔3〕賣方提出的報價以人民幣為單位，應報設備到現場〔買方指定地點〕的價格，運輸費單獨列出。 答：滿足。 〔4〕報價應按目錄價、折扣價和折扣率分項列清。 答：滿足。 〔5〕對于賣方向買方建議采用的業(yè)務和功能，賣方應詳細描述和說明這些業(yè)務和功能并作為可選項提出報價。 答：滿足。 〔6〕賣方對本規(guī)X書涉及到的效勞器、存儲系統、操作系統軟件、數據庫軟件等提出合理的建議配置，并提供詳細的計算依據。 答：滿足。 〔7〕硬件報價要求報出系統所需的

19、全部設備的價格。 答：滿足。 〔8〕軟件報價要求賣方應提供最新的、成熟的、穩(wěn)定的軟件版本，并注明所提供軟件的版本號，提供詳細的功能清單。 答：滿足。 〔9〕軟件報價按以下分類方法 系統軟件報價：包括操作系統〔如果硬件平臺采用商用計算機平臺，可包含在硬件報價中〕、工具和組件等。 答：滿足。 〔10〕賣方應承諾買方在后續(xù)的設備訂貨時，同一類型的軟、硬件設備成交價格至少不高于本次合同的成交價格，折扣率至少不低于本次合同的折扣率。 答：滿足。 〔11〕效勞報價要求 賣方應對工程中需要原廠支撐的效勞進展報價。 答：滿足。 〔12〕培訓 賣方就所提供的產品提供原廠技術培訓，分為高

20、級培訓〔高級技術人員或管理者〕和操作培訓；賣方同時提供運維流程培訓，保證系統正常運行。 答：滿足。 賣方需就以上培訓，列出培訓人員的數量和費用單價并給出詳細的培訓方案〔包括時間、地點、課程等〕。 答：滿足。 〔13〕可選報價 對于可選軟件、硬件和效勞或賣方認為可以推薦給買方選擇的軟件、硬件和效勞，可單獨提出其工程和報價，但不計入總價，并提供技術性能及經濟技術比較所需的資料。 答：滿足。 4 工程概述 4.1 建立背景 114導航〔簡稱114〕為用戶提供導航業(yè)務宣傳、信息查詢、電子商務等綜合信息效勞。目前114已經實現了會員注冊、會員管理、積分管理、商家管理、合作商家產品管理等

21、功能。當前系統具體實現的功能包括： 會員注冊功能，包括web會員注冊功能、話務員代客注冊功能和撥打114導航的用戶自動成為會員功能等。 答：滿足。 會員管理功能，包括會員資料管理、會員積分管理、訂單歷史明細查詢、會員積分查詢等。 答：滿足。 積分管理功能，包括積分計算、積分規(guī)那么管理等。 答：滿足。 商家管理功能，包括商家信息維護、商品分類管理和商品管理。 答：滿足。 支持短信下行功能。用戶短信回復信息時，系統將根據相關的規(guī)那么進展后續(xù)處理。 答：滿足。 EXCEL導出功能，會員的積分數據和訂單數據能夠以EXCEL的方式進展導出。 答：滿足。 目前，114中已經具有4

22、00多萬左右的具備會員注冊、會員資料管理的用戶，但還無法進展積分兌換等功能；話務員界面還無法支撐為用戶辦理通用卡業(yè)務，用戶感知降低，影響收益。目前114的業(yè)務數據根本都是從合作平臺獲取的，由于數據分散在各個合作平臺，無法及時準確的獲取業(yè)務運營數據，如訂單跟蹤等，對業(yè)務的后續(xù)開展影響較大。 答：滿足。 隨著互聯網業(yè)務和手機業(yè)務的高速開展，WEB/WAP電子商務迅速擴展。中國電信從2009年開場啟動集團版的號百商城，2010年開場，某、某、某、某、某各省也開場啟動本地版號百商城。聯通作為聯通集團114導航業(yè)務的領導者，需要及時適應市場變化，緊跟行業(yè)潮流，利用114導航品牌和500萬前向客戶和后

23、向商家資源，大力開展以導航品牌效勞為根底的實物訂購業(yè)務。 答：滿足。 賣方應充分了解本工程的上述建立背景。 4.2 業(yè)務現狀 4.2.1 114業(yè)務現狀 目前運營商的商旅業(yè)務主要分為三類： 代客預訂：比方酒店預訂、餐飲預訂等。代客預訂的目標客戶主要是商務人士，預訂內容需要客戶親自去消費，客戶一般在消費單位完成支付，由消費單位提取一定比例的提成費用給運營商。 答：滿足。 實物預訂：比方訂鮮花、訂農產品。實物預訂的目標客戶有消費需求的人員，主要是為了方便人們購物消費，需要由支付和物流配送系統的支持，這種方式一般由消費者在運營商側完成支付，運營商扣除一定比例的提成費用后把實物費用結算

24、給實物供給商和物流供給商。 答：滿足。 票務類預訂：比方機票預訂、火車票預訂等。票務類預訂業(yè)務的特點是其預訂內容具有稀缺性和壟斷性的特點，票務代理商或者供給商在資源控制上比較強勢，因此在支付方式商和代客預訂類似，由票務代理商或者供給商完成用戶收費后提取一定比例的提成費用給運營商； 答：滿足。 目前，聯通在導航平臺只實現了自營酒店等局部業(yè)務的訂單流轉控制和自營酒店等商家的管理，無法進展實物預訂和購置。只實現了語音接入，缺少WEB/WAP等新的接入方式。 答：滿足。 4.2.2 114系統現狀 4.2.2.1 系統已實現功能 模塊 功能 WEB 產品宣傳與發(fā)布 陽光政務、尾

25、號限行 商場折扣與優(yōu)惠券下載 權限管理 后臺管理 WAP 產品宣傳與發(fā)布 尾號限行 114語音查詢 會員管理 會員注冊 會員資料修改 話務員代客注冊 話務員代客修改資料 話務員代客查詢積分 短信模板管理 導入內部員工、VIP會員數據 訂單查詢 積分管理 積分規(guī)那么配置 積分查詢 積分短信提醒 答：滿足。 4.2.2.2 系統技術框架 系統框架采用當前較為流行的SSH框架。 SSH： Struts〔表示層〕+Spring〔業(yè)務層〕+Hibernate〔持久層〕 。 Struts： Struts是一個表示層框架，主要作用是界面展示，接收請求，分發(fā)請

26、求。在MVC框架中，Struts屬于VC層次，負責界面表現，負責MVC關系的分發(fā)?！睼iew：沿用JSP、 、Form、Tag、Resourse ；Controller：ActionServlet、struts-config.xml、Action〕 。 Hibernate： Hibernate是一個持久層框架，它只負責與關系數據庫的操作。 Spring： Spring是一個業(yè)務層框架，是一個整合的框架，能夠很好地黏合表示層與持久層。 答：滿足。 4.2.2.3 系統總體構造 導航業(yè)務平臺的建立采用業(yè)務與交換別離的設計思想，總體構造分三層實現，即交換接入層、功能支撐層、業(yè)務實現層

27、。 答：滿足。 〔1〕交換接入層 交換接入層負責各種媒體的綜合接入，實現語音接入、小靈通短信下行接入、G網用戶短信上下行等多種接入方式。 答：滿足。 〔2〕功能支撐層 功能支撐層負責對呼叫進展統一的管理，如完成對呼叫的控制、路由的管理、資源的管理等，它針對具體業(yè)務對話務的需求，通過解釋轉化為任務，向交換接入層提交，在交換接入層的配合下，完成豐富多變的話務功能。功能支撐層包括核心控制效勞器、智能路由中心、IVR控制系統、用戶接口效勞、業(yè)務開發(fā)平臺等。 答：滿足。 〔3〕業(yè)務實現層 業(yè)務實現層通過接口按照具體應用的話務需求向上層提出需求，結合計算機網絡和數據庫技術實現具體的業(yè)務應

28、用。 答：滿足。 業(yè)務實現層目前實現的業(yè)務有114查號業(yè)務和導航業(yè)務。支撐114查號業(yè)務的應用軟件包含如下功能：查詢功能、增刪改功能、質檢功能、IVR功能、統計分析功能、外呼功能以及監(jiān)控管理功能，并且能根據話務員的實際從事話務工作的不同設置不同的權限。導航業(yè)務是在114查號應用軟件的根底上實現的增值效勞，共包含7大類22項效勞。 答：滿足。 4.2.2.4 系統拓撲 聯通114導航系統由東四和皂君廟兩套接入平臺組成，兩套平臺之間可以構成網絡呼叫中心，實現114話務的全網均衡、負荷分擔以及局部容災備份功能：當其中某一套平臺的處理能力不夠或者出現故障，另一套接入平臺可以通過網絡智能分配系

29、統〔NIRC〕獲得相關的控制信息，完成114業(yè)務。 答：滿足。 4.2.2.5 系統接口 當前114與外圍系統的接口主要有114與聚集分析系統的數據接口，與114導航平臺的接口。 答：滿足。 〔1〕與聚集分析系統的數據接口 此接口包括聚集分析系統到114和114到聚集分析系統的雙向數據接口，用于114定時向聚集分析系統同步訂單等信息和聚集分析系統定時向114同步用戶消費行為等信息。 答：滿足。 〔2〕與114導航平臺的接口 此接口用于114導航平臺話務員代客操作，點擊，頁面跳轉到114代客操作頁面。 答：滿足。 4.3 系統需求 針對目前114現狀和訂單業(yè)務管理現狀，以

30、及電子商務行業(yè)趨勢，需要增強和擴展114功能，實現統一實物預訂業(yè)務門戶、統一訂單管理、統一支付平臺接口、統一物流管理、統一前向客戶管理、統一商家合作伙伴管理，建立面向農產品、鮮花、蛋糕、電影票、雜志等商旅業(yè)務的集中運營管控。 答：滿足。 5 建立方案 5.1 網絡拓撲圖 本工程目標網絡拓撲構造如以下圖： 答：滿足。 5.2 系統架構 如以下圖所示： 答：滿足。 5.3 增強話務員應用模塊 在現有代客注冊、代客修改資料、代客積分查詢功能根底上，新增農產品通用卡管理模塊、有卡(指農產品通用卡)實物預訂模塊、實物搜索模塊。 答：滿足。 農產品通用卡管理模塊包括農產品通

31、用卡建卡、農產品通用卡充值、農產品通用卡余額查詢、凍結金額查詢和有效期查詢。 答：滿足。 有卡實物預訂模塊包括以下功能：訂單查詢、新增訂單、訂單修改和訂單撤銷。 答：滿足。 5.3.1 農產品通用卡建卡功能： 下建卡訂單，一次性可以動態(tài)的創(chuàng)立多X不同面值的農產品預訂卡?？梢詫ㄟM展動態(tài)刪除操作。 答：滿足。 建卡流程圖如下： 答：滿足。 5.3.2 農產品通用卡建卡回填功能 回填時可以動態(tài)對多X卡進展建卡回填， 且系統自動將卡有效期默認填寫為當前日期向后推至一年的日期。如果回填金額>=2000元,那么有效期默認為當前日期向后推至兩年的日期，且話務員可以手工修改有效期。

32、 答：滿足。 5.3.3 農產品通用卡充值功能 用戶可以一次為多X農產品通用卡進展充值。 流程圖同建卡流程圖。 答：滿足。 5.3.4 農產品通用卡充值回填功能 回填時可以動態(tài)對多X卡進展充值回填， 且系統自動將卡有效期默認填寫為當前日期向后推至一年的日期。如果回填金額>=2000元,那么有效期默認為當前日期向后推至兩年的日期，且話務員可以手工修改有效期。 答：滿足。 5.3.5 有卡實物預訂功能 農產品實物預訂卡采用非記名方式制卡發(fā)卡。 發(fā)卡后，持卡人可以將卡贈送給他人。 答：滿足。 此卡如果曾經有過交易實物的記錄，那么持卡人使用此卡再次進展購物的時候，系統會將此

33、卡最近一次交易人的信息自動帶入，從而減少了話務員的工作量，提高了話務員的工作效率，話務員只需確認收貨人信息即可。 答：滿足。 有卡實物預訂流程圖如下： 答：滿足。 5.3.6 實物訂單修改功能 話務員點擊修改按鈕后，舊訂單商品信息重新回到購物車以后，話務員可以隨意進展如下操作： 更改商品數量、增減商品(只有符合修改規(guī)那么的才能被修改) 。如果新增商品，卡金額缺乏，可以添加卡 (所有卡合計可用總金額大于等于訂購貨款的時候，提示不讓添加新卡) 。 答：滿足。 此功能方便話務員更改訂單信息，提高了話務員的工作效率。 5.4 新增WEB用戶電子商城應用模塊 該模塊包括WEB商品搜索

34、模塊、商品瀏覽、在線客服模塊、積分查詢模塊、投訴功能模塊、歷史訂單明細模塊和個人信息管理模塊。 答：滿足。 5.4.1 商品搜索 用戶可以通過web，通過不同的檢索條件組合，搜索自己喜歡的商品。如果訂購，需要打讓話務員預訂。 答：滿足。 5.4.2 在線客服 用戶可以通過web提供的在線客服，如QQ、MSN或電子等方式，向效勞人員進展內相關信息的咨詢, 方便用戶了解產品，促成交易。 答：滿足。 5.4.3 積分查詢 用戶可以通過web自助查詢個人積分記錄情況，包括當前總積分、積分來源明細、積分消費明細等。 答：滿足。 5.4.4 投訴功能 用戶可以通過web提供的投訴

35、受理模塊進展投訴，投訴方式可以通過電子結合訂單情況進展產品、效勞等方面的投訴。 答：滿足。 5.4.5 歷史訂單明細 用戶可以通過web登錄成功后，進入自助效勞頁面，可以通過不同的檢索條件查詢歷史訂單情況及訂單狀態(tài)。 答：滿足。 5.4.6 個人信息管理模塊 用戶可以通過web登錄成功后，進入自效勞頁面，可以修改個人信息，包括某、、通信地址等信息。 答：滿足。 5.5 增強WAP應用模塊。 目前WAP提供了產品預訂、交通出行、通信助理業(yè)務咨詢的114直撥功能。本期新增包括WAP方式注冊、WAP方式積分查詢、預約掛號、隨身號薄、商務總機、優(yōu)惠券等功能。 答：滿足。 5.6

36、增強商家應用模塊 增強商家商品維護模塊、新增商家投訴處理模塊、客服應答處理模塊、商家訂單處理模塊、商家信息維護模塊、商家配送模塊、商家統計分析效勞和商家管理功能模塊。 答：滿足。 5.6.1 商家商品維護模塊 包括商品的上架、下架，商品的審核，商品模板維護, 商家通過商品管理對屬于自己X圍內的商品信息進展維護和及時提醒。 答：滿足。 5.6.2 商家投訴處理模塊 針對于web客戶的投訴信息進展回復。 答：滿足。 5.6.3 客服應答處理模塊 針對于前臺web客戶實時的問題咨詢做應答處理，如詢問商品等信息等。 答：滿足。 5.6.4 商家訂單處理模塊 商家對訂單的管理，

37、如審核、跟蹤，商家對分流到自己的訂單可處理給物流公司。 答：滿足。 5.6.5 商家信息維護模塊 商家自效勞中可以對公司信息進展維護，如修改商家地址、商家名稱、商家編碼等信息。 答：滿足。 5.6.6 商家配送模塊 商家對于配送環(huán)節(jié)的管理, 商家可進展可視的物流選擇。 答：滿足。 5.6.7 商家統計分析效勞 商家對商品庫存的統計、銷售商品的排名(按照不同時間)、訂單的統計等。 答：滿足。 5.7 新增中臺業(yè)務人員應用模塊 包括業(yè)務報表統計模塊、商品管理模塊、中臺業(yè)務人員訂單管理模塊。 答：滿足。 5.7.1 業(yè)務報表統計模塊 業(yè)務報表統計模塊包括以下功能：訂單統

38、計、商家統計、商品統計、WEB用戶統計、銷售排行、點擊排行、評論排行、物流結算、客戶信息查詢、訂單查詢、配送回執(zhí)查詢、應收賬款查詢、銷售收入分析、報表統計分析和銷售數據統計等統計報表管理。 答：滿足。 5.7.2 商品管理模塊 商品管理模塊包括以下功能：審核商品、刪除商品、新增商品、商品模板維護、新增商品模板、商品發(fā)布等。 答：滿足。 5.7.3 訂單管理模塊 訂單管理模塊包括訂單分發(fā)、訂單審核、訂單跟蹤。 答：滿足。 訂單分發(fā)功能：二線合作方管理人員可以對建卡訂單池、充值訂單池和實物訂單池分別進展管理，可以根據檢索條件，定位到不同配送日期的待派發(fā)訂單，然后可以批量選中待派發(fā)訂

39、單，分發(fā)給指定的二線操作員。已派發(fā)的訂單會從訂單池中移走。 答：滿足。 訂單審核功能：二線操作員沒有權限對訂單進展修改和撤銷，所以二線操作員遇到處理不了的訂單，會將訂單全部回傳給二線管理人員。二線管理人員會對這些訂單進展審核，根據回傳原因進展修改或者撤銷。 答：滿足。 5.8 增強后臺管理員應用模塊。 包括會員管理模塊、商家管理模塊、配送方式維護模塊、支付方式維護模塊、信息管理模塊、頁面管理模塊、業(yè)務報表統計模塊、系統管理員模塊。 答：滿足。 5.8.1 會員管理模塊 會員管理模塊包括：會員增加、會員修改。 答：滿足。 5.8.2 商家管理模塊 商家管理模塊包括：新增供給

40、商、修改供給商和刪除供給商。 答：滿足。 5.8.3 配送方式維護模塊 配送方式維護模塊實現商家配送方式的修改操作。 答：滿足。 5.8.4 支付方式維護模塊 支付方式維護模塊實現通用卡支付和貨到付款操作。 答：滿足。 5.8.5 話務員管理模塊 話務員管理模塊包括：話務員增加、話務員修改、話務員刪除。 答：滿足。 5.8.6 114信息管理模塊 114信息管理模塊包括：增加信息、欄目維護和留言管理。 答：滿足。 5.8.7 114頁面管理模塊 114頁面管理模塊包括：增加廣告、廣告管理、增加頁面和頁面管理。 答：滿足。 5.9 新增訂單管理引擎 包括訂單池

41、、訂單處理角色分類、訂單流程、訂單功能模塊。 答：滿足。 5.9.1 訂單池 系統對所有已經確認后的咨詢單自動池化，生成訂單總池，池中包含所有未經處理的訂單。主要狀態(tài)為：未處理和變更未處理訂單。 答：滿足。 5.9.1.1 訂單分揀： 訂單分為話務員手工領取、系統自動派發(fā)、二線管理人員進展手工派發(fā)。 答：滿足。 5.9.1.2 二線管理人員手工派發(fā) 二線管理人員派發(fā)訂單流程圖如下： 答：滿足。 5.9.1.3 話務員手工領?。? 二線話務員登錄系統后，對未處理和變更未處理的訂單做分配操作，領取訂單，二線管理員針對領取后的訂單進展審核和分配處理，系統支持同時領取多個訂單

42、動作。但對于已領取未處理的訂單到達指定時間未進展下一步處理時，自動彈回訂單池，并記錄彈回日志。在進展訂單領取時，系統對訂單進展鎖定操作，一旦鎖定，其他用戶將只能進展查看操作。不能進展領取操作。 答：滿足。 答：滿足。 5.9.1.4 系統自動派發(fā)： 如果訂單在指定時間〔系統設定〕內沒有被任何操作員領取，系統將隨機分配給選擇話務員。 答：滿足。 5.9.1.5 訂單預警： 系統在訂單池中的訂單數量到達一定數目〔系統設定〕的時候自動預警，紅色字體顯示。系統在訂單池中的超期〔系統設定〕訂單進展預警，并以紅色顯示。系統在訂單距離超期時間〔系統設定〕還有指定時間〔系統設定〕的時候，自動預警

43、〔黃色顯示〕。 答：滿足。 5.9.2 訂單角色分類 訂單處理角色分類是根據訂單業(yè)務使用對象不同，將系統使用者分為一線話務員、二線話務員、商家和業(yè)務管理員。 答：滿足。 5.9.2.1 一線話務員： 為用戶提供訂購業(yè)務效勞的接線員，一線話務員對訂單進展咨詢、訂單生成操作。 答：滿足。 具體包括：生成建卡訂單，生成充值訂單，使用農產品通用卡進展實物預訂，以及對三種訂單的管理，包括查詢、修改和撤銷。一線話務員并被以處理訂單效率為標準進展績效考核 ； 答：滿足。 5.9.2.2 二線話務員： 負責審核訂單、處理催單，通過和商家溝通，確認能否為已經申請成功的訂單提供效勞，負責對訂

44、單處理過程進展催分配，催聯系等； 答：滿足。 目前二線話務員分為合作方管理員和合作方操作員，合作方管理員對訂單進展派發(fā)、對訂單進展修改和撤銷操作；合作方操作員對訂單進展具體處理，包括配送確認、回填確認、到貨簽收確認的操作。 答：滿足。 5.9.2.3 業(yè)務管理員： 負責核對訂單，通過和商家溝通，確認訂單數量，以及傭金結算。 答：滿足。 5.9.3 訂單流程 訂單流程如以下圖所示： 答：滿足。 5.9.4 訂單功能模塊 主要包括新增訂單、訂單修改、訂單撤銷、訂單狀態(tài)查詢、訂單監(jiān)控、歷史訂單查詢、訂單統計分析。 答：滿足。 5.9.4.1 新增訂單： 話務員代客操作

45、或用戶自己通過進展農產品通用卡預訂、對通用卡進展充值、使用農產品通用卡進展實物預訂,產生訂單。 答：滿足。 使用農產品通用卡進展實物預訂，如果當前使用的卡已經有過交易的記錄，那么本次交易會自動將本卡最近一次交易的收貨人信息帶入系統，話務員根據實際情況進展修改或者只對信息進展核對即可。節(jié)省了話務員的工作量，提高了工作效率。 答：滿足。 5.9.4.2 訂單修改： 話務員代客或用戶自己通過修改訂單信息，如修改商品、數量、配送地址。 答：滿足。 對于建卡訂單和充值訂單：話務員可以代客進展修改除卡號外任何信息，修改需要在規(guī)那么X圍內。 答：滿足。 修改實物訂單：重新回到購物車以后，話

46、務員可以進展如下操作： 更改商品數量 、增減商品 。 答：滿足。 新增商品卡金額缺乏，可以添加卡。(所有卡合計可用總金額大于等于訂購貨款的時候，提示不讓添加新卡) 答：滿足。 農產品實物預訂卡采用非記名方式制卡發(fā)卡。 發(fā)卡后，持卡人可以將卡贈送給他人。 答：滿足。 此卡如果曾經有過交易實物的記錄，那么持卡人使用此卡再次進展購物的時候，系統會將此卡最近一次交易人的信息自動帶入，從而大大減少了話務員的工作量，提高了話務員的工作效率，話務員只需詢問確認收貨人信息即可。 答：滿足。 5.9.4.3 訂單撤銷： 話務員代客或者用戶自己通過在指定的規(guī)那么X圍內進展訂單的撤銷。 目

47、前實物預訂中，撤銷訂單，會將農產品通用卡中凍結的金額退還。 答：滿足。 5.9.4.4 訂單狀態(tài)查詢： 話務員代客或者用戶在訂單流轉的過程中對訂單的實時狀態(tài)進展查詢。話務員通過訂單管理功能查看所有訂單的狀態(tài)，對于已經配送或處理完畢的訂單，訂單不可再被更改或做撤消操作。 答：滿足。 5.9.4.5 訂單監(jiān)控： 系統對訂單池中的訂單進展實時監(jiān)控和預警，如訂單數量到達1000份、訂單超過3小時無人處理等。 答：滿足。 5.9.4.6 歷史訂單查詢： 話務員代客或者用戶通過系統對自己的歷史訂單進展查詢。如：查詢近一個月的訂單、按訂單分類查詢近半年的訂單等。 答：滿足。 5.9.4

48、.7 訂單統計分析： 對系統中的訂單進展統計分析。如：按商家進展統計分析、按訂單產生時間進展統計分析、按訂單分類進展統計分析等。 答：滿足。 6 軟件設計要求 6.1 根本要求 (1) 賣方的應用軟件應能支持各類主流效勞器； 答：滿足。 (2) 應用軟件應支持Windows、Linux或UNIX等主流操作系統； 答：滿足。 (2) 應用軟件應采用分層次的體系構造，以便于系統的維護和擴展； 答：滿足。 (3) 應用軟件應能根據用戶規(guī)模的不同支持集中處理模式和分布式處理； 答：滿足。 (4) 應用軟件應具有很好的開放性，以便于與其他應用系統的連接； 答：滿足。

49、 (5) 應用軟件應能適應多種大型數據庫系統，例如Oracle、Sybase等； 答：滿足。 (6) 系統的運行應是平安、可靠的，具備完善的、分級的操作/訪問權限控制機制； 答：滿足。 (7) 系統應具有數據備份及災難恢復功能。 答：滿足。 (8) 要求軟件采用分層的模塊化構造，模塊之間的通信應按規(guī)定接口進展。任何一層的任何一個模塊的維護和更新以及新模塊的追加都不影響其他模塊； 答：滿足。 (9) 系統參數、用戶數據與處理程序應有相對的獨立性。用戶數據的任何變更都不應引起運行版本程序的變更。處理程序應與系統參數、用戶數據相適應； 答：滿足。 (10) 軟件應有容錯能力，一般

50、的軟件故障不應引起各類嚴重的系統再啟動； 答：滿足。 (11) 軟件設計應有防護性能，某一軟件模塊內的軟件錯誤應限制在本模塊內，而不應造成其他軟件模塊的錯誤； 答：滿足。 (12) 應具有軟件運行故障的監(jiān)視功能。一旦軟件出現死循環(huán)等重大故障，應能自動再啟動，并能出即時故障報告信息； 答：滿足。 (13) 軟件具有詳細、完善、靈活的業(yè)務、用戶等數據的統計、分析、預測能力； 答：滿足。 (14) 賣方需對銷售的核心軟件局部擁有自主知識產權。 答：滿足。 6.2 總體設計要求 〔1〕賣方應提供本工程各設備運行的詳細的軟件配置描述，包括業(yè)務軟件模塊，及可能涉及的設備擴容所使用的專

51、業(yè)軟件，賣方需詳細描述各種軟件功能、能力限制〔license限制〕和硬件平臺、操作系統支持情況。 答：滿足。 〔2〕賣方應提供本工程對平臺各模塊的影響，需要列出平臺的全部功能模塊并按下表標識各模塊在本工程中是否發(fā)生變化。 答：滿足。 模塊名 新增 改造 不變 針對上表中新增、改造局部，賣方應明確描述新增和改造的具體流程、數據格式和接口變化，以及該變化導致的現有業(yè)務流程、數據格式和接口等變化。 答：滿足。 〔3〕賣方應給出本工程的整體軟件架構〔邏輯功能構造〕和各個功能模塊，同時應說明功能模塊之間的關系和采用的接口技術,并就各局部之間中間件內部通訊機制和協議進展

52、詳細說明。 答：滿足。 〔4〕針對每個模塊給出詳細的功能列表及進程名稱，并作為獨立附件提供。 答：滿足。 〔5〕賣方應根據各個具體業(yè)務對各模塊之間的工作流程、數據流向、數據交互的關系圖進展詳細描述。上述內容要求作為技術建議書的獨立附件。 答：滿足。 〔6〕賣方應對各個模塊用到的數據模型和數據構造和E-R圖作詳細說明。上述內容要求作為技術建議書的獨立附件。 答：滿足。 〔7〕賣方應給出各軟件功能模塊在硬件設備上的部署關系對照表。并作為技術建議書的獨立附件。 答：滿足。 〔8〕本工程建立系統中各功能應采用模塊化構造，各子系統間要以松耦合方式建立，可以靈活修改，每個模塊的調整不能

53、影響其他系統的正常工作；且各模塊功能之間邏輯劃分準確，盡量減少操作數量。 答：滿足。 〔9〕賣方應說明提供的所有功能模塊，可以順利實施上線的時間周期〔從合同小簽之日算起〕。 答：滿足。 〔10〕平臺的數據庫主機效勞器、接口主機效勞器等重要效勞器需采用備份工作方式。 答：滿足。 〔11〕平臺的主機和數據庫應按照行業(yè)規(guī)X和聯通內控要求，配置平安化，規(guī)X化。 答：滿足。 〔12〕對于需要經常查詢的日志，新系統應可以提供頁面化的查詢方式，以提高維護的方便性，系統還應能夠支持認證失敗信息實時統計查詢的功能。 答：滿足。 〔13〕為保證關鍵業(yè)務數據可用性，本工程建立系統應具備完善數據可

54、靠存儲策略。 答：滿足。 〔14〕所有存儲的關鍵業(yè)務數據，必須使用采用RAID0+1方式(HOT SPARE配置按照通行慣例或原廠商的推薦標準配置)，其他普通數據可采用RAID5方式。存儲系統擴容可沿用現有方式，但需就系統性能和平安性進展說明。 答：滿足。 〔15〕賣方應提供本次工程中使用的軟件清單證明。 賣方應就本次工程建議方案中使用的軟件承載用戶能力、系統設計的性能指標、系統配置、以及軟件功能、詳細的功能模塊進展詳細說明。 答：滿足。 〔16〕賣方應就系統要求做出詳細的應答與說明。 假設賣方方案與本規(guī)X書中所述方案不符，賣方可根據自身產品特點，在不影響系統建立目標與功能的前

55、提下，做出修正，可單獨提出其工程和報價，并提出相應的配置表及報價清單，同時應進展比較，做出詳細說明。但不計入合價，并提供技術性能及供經濟技術比較所需的資料。 答：滿足。 6.2.1 系統軟件配置 賣方提供的方案中假設包含操作系統或數據庫軟件配置，那么需滿足以下要求。 答：滿足。 6.2.1.1 操作系統 關鍵業(yè)務應用主機采用Windows、Linux或UNIX等主流操作系統。 答：滿足。 操作系統支持虛擬內存管理，支持多用戶、多任務、多進程和多線程。 答：滿足。 操作系統應至少到達C2級的平安標準。 答：滿足。 操作系統應遵循X/open XPG4, POSIX 100

56、3.1等國際或工業(yè)標準。 答：滿足。 提供完整的軟件開發(fā)環(huán)境，包括C編譯器等開發(fā)工具。 答：滿足。 操作系統應提供圖形化的系統管理工具。 答：滿足。 支持在線診斷和軟硬件的自動錯誤記錄。 答：滿足。 電源故障或其他緊急情況可提供自保護和自恢復。 答：滿足。 支持高可用性集群。 答：滿足。 6.2.1.2 數據庫軟件 選擇標準如下： 支持主流硬件和操作系統平臺。 答：滿足。 支持網絡上大型同構或異構數據庫之間的數據的有效傳輸和冗余性復制。 答：滿足。 支持主流的網絡協議。 答：滿足。 實現和高級語言互連的能力。 答：滿足。 具有支持并行操作所需的技術，

57、包括多效勞器協同技術、事務處理的完整性控制技術等。 答：滿足。 支持C2級平安標準，多級平安控制。 答：滿足。 支持數據庫存儲加密、數據傳輸通道加密及相應冗余控制。 答：滿足。 提供Web效勞接口模塊，對客戶端輸出協議支持 2.0、SSL等。 答：滿足。 6.2.2 應用軟件配置 賣方應詳細解釋其應用軟件產品的總體構造和業(yè)務流程。如果采用第三方產品，指明第三方產品在整個體系構造中所起的作用。做到軟件框架和文字描述一一對應。 答：滿足。 (1)賣方應對其軟件產品的模塊名稱，所屬的X疇和層面及其功能進展詳細描述。 答：滿足。 (2)賣方應說明自身產品目前可以直接運行

58、在何種主流效勞器(如HP、IBM、SUN等)和操作系統上(HP-UNIX、IBM-AIX、SUN-SOLARIS等)，說明效勞器名稱、操作系統名稱和版本。并說明對于其他效勞器和操作系統是否可以移植，移植難度主要表達在什么地方；如果不能移植的技術原因；如果可以移植，一般情況下從開場移植到最終可以正式商用之間的時間。 答：滿足。 (3)賣方應說明自身產品目前可以直接運行在何種主流數據庫產品(如ORACLE、INFORMIX、SYBASE、SQL SEVER等)，并說明對于其他數據庫產品，賣方是否可以移植，移植難度主要表達在什么地方；如果不能移植的技術原因；如果可以移植，一般情況下從開場移植到最

59、終可以正式商用之間的時間。 答：滿足。 (4)賣方應保證所提供的軟件具有良好的可擴展性，當新增功能需求時，能較快地實現系統功能模塊的整合擴展，而不需要變更系統的根底架構。 答：滿足。 6.3 114系統功能要求 6.3.1 業(yè)務功能 本期系統在原有WEB的根底上建立網絡商城、配送管理、在線支付、數據統計、商品發(fā)布、消息提醒功能，目的是實現網上訂購、付款及配送工作，增加114導航業(yè)務的訂單，提升整體收入。在原有導航前向客戶會員和積分管理模塊增強功能。 答：滿足。 6.3.1.1 網絡商城 系統支撐用戶通過WEB進展商品瀏覽及在線預定功能，客戶預訂后系統通過實時接口向訂單系統傳輸

60、訂單詳細數據，訂單系統獲取訂單數據后將數據提供給后向商家?？蛻艨呻S著登錄系統查看貨物派送流程，處理環(huán)節(jié)等工作。 答：滿足。 6.3.1.2 配送管理 主要是根據訂單情況，安排配送車輛與配送時間，并自動通過與車機的交互，獲得配送油量信息。當訂單下發(fā)時，可通過消息效勞來將打印的信息發(fā)送到車機中；當訂單完成時，將車機傳回的實時油量自動回寫到配送單回執(zhí)中。在途、配送完成后，都將向客戶發(fā)送一條短消息，以提示客戶訂單的狀態(tài)以及訂貨量、價格等信息，并確認。 答：滿足。 6.3.1.3 在線支付 系統通過與農產品卡管理平臺建立接口，實現農產品卡的在線支付功能，客戶訂購產品后可立即進展在線付款。

61、答：滿足。 6.3.1.4 商品發(fā)布 此功能模塊包括后向商家信息注冊、后向商家信息審核、后向商家產品信息發(fā)布、后向商家產品信息審核、后向商家產品信息加載功能。其中商家信息審核和產品信息審核由系統管理員進展審核，管理員審核通過后客戶能看到后向商家的信息及產品信息。系統獲取商家信息后，通過實時接口將數據傳輸到訂單系統，同時訂單系統獲取數據后通過回執(zhí)進展確認。 答：滿足。 6.3.1.5 消息提醒 系統可通過頁面、短信等多種方式進展重要日期提醒，如積分變更、客戶生日、客戶自定義的紀念日、客戶貨物下發(fā)通知等信息。 答：滿足。 6.3.1.6 數據統計 對一些有用信息提供查詢與統計的功能

62、。主要實現：客戶信息查詢、效勞日志查詢、訂單查詢、配送回執(zhí)查詢、貨物信息查詢、某信息查詢 、應收帳款查詢 、客戶信息統計 、銷售出庫差量 、銷售收入分析 、貨物價格分析 、銷售品種分析 、銷售業(yè)績分析 、報表統計匯總 、銷售數據統計。 答：滿足。 6.3.1.7 會員管理增強 包括后向客戶會員管理和會員級別擴展及配置。 答：滿足。 6.3.1.8 積分管理增強 包括積分規(guī)那么擴展以及配置及發(fā)起搶換積分活動。 答：滿足。 6.3.2 系統功能 本期建立主要提供以下系統功能： 1〕實現商戶通過Web/Wap方式完成網上查號及綜合信息查詢。114系統通過調用114導航綜合信息搜索

63、引擎，提供精準信息效勞，讓用戶在感受到便捷的同時，體會到與一般互聯網查詢的區(qū)別。 答：滿足。 2〕實現商戶網上業(yè)務受理(預受理)、商戶相關信息的預登記。 答：滿足。 3〕實現商戶網上客戶資料自助登記/修改，為用戶提供基于互聯網的自助管理效勞。 答：滿足。 4〕實現用戶熱線預定的網上訂單交易等效勞。 答：滿足。 5〕利用114導航強大的后臺數據庫支撐系統，全面的統計分析管理功能，進展市場商機挖掘，后向收費商戶的展示與排名。 答：滿足。 6〕實現話務員代客預訂農產品通用卡，客戶可以每次預訂多X農產品通用卡。一線話務員將農產品通過卡訂單下發(fā)后，二線管理人員將農產品通用卡訂單派發(fā)給

64、二線普通操作人員，二線普通操作人員在自己的訂單池中可以看到這條待處理的訂單，然后聯系物流人員，更改訂單配送狀態(tài)。物流配送人員上門效勞配送農產品通用卡，將商品清單交付客戶，客戶付錢，待客戶簽收后，物流配送人員拿回客戶簽收單，交給二線操作人員對此訂單進展回填，二線操作人員對此訂單的卡號、金額和有效期進展回填，回填成功后，一條正常的建卡訂單才算完畢。 答：滿足。 7〕實現話務員代客對農產品通用卡進展充值，客戶可以每次對多X農產品通用卡進展充值。一線話務員將農產品通過卡充值訂單下發(fā)后，二線管理人員將農產品通用卡訂單派發(fā)給二線普通操作人員，二線普通操作人員在自己的訂單池中可以看到這條待處理的訂單，然

65、后聯系物流人員，更改訂單配送狀態(tài)。物流配送人員上門效勞配送農產品通用卡，將商品清單交付客戶，客戶付錢，待客戶簽收后，物流配送人員拿回客戶簽收單，交給二線操作人員對此訂單進展回填，二線操作人員對此訂單的卡號、充值金額和有效期進展回填，回填成功后，一條正常的農產品通用卡充值訂單才算完畢。 答：滿足。 8〕實現話務員代客預訂農產品。 答：滿足。 6.4 系統接口要求 6.4.1 獲取主叫接口(與導航平臺) 用于來電顯示獲取用戶的。 答：滿足。 6.4.2 短信發(fā)送接口(與導航平臺) 114導航平臺面向114系統提供短信發(fā)送接口，用于用戶在114注冊、推薦贈送積分、修改信息等短信提醒

66、功能。接口采用jdbc連接方式。 答：滿足。 6.4.3 與聚集分析雙向數據接口 包括：114到聚集分析系統數據同步接口 和 聚集分析系統到114數據同步接口。用于114定時向聚集分析系統同步訂單等信息和聚集分析系統定時向114同步用戶消費行為等信息。 答：滿足。 6.4.4 與合作方數據同步接口 包括：農產品通用卡信息同步接口 和 合作方商品信息同步、導入接口 前者用于獲取合作方通用卡金額、有效期等信息進展驗證； 后者用于同步合作方商品名稱、價格、圖片等商品根本信息 。 答：滿足。 6.4.5 與聯通主要門戶接口 主要包括：WAP門戶、.10010. 中國聯通網上營業(yè)廳門戶下掛114 、.bj.chinauni. 中國聯通市分公司門戶下掛114。 答：滿足。 6.4.6 用戶權限認證接口 (與導航平臺) 包括與IVR流程接口、獲取IVR數據接口以實現話務員代客操作提示用戶手機輸入密碼，實現114登錄。具體流程見以下圖： 導航平臺通過捕捉用戶鍵盤輸入信息傳遞給114話務員應用模塊，114應用模塊經過驗證后將結果反響給導航平臺 答：滿足。 6