第一篇：責任矩陣分配表,項目范圍說明書,項目變更文件,工作總結體會

項目范圍說明書

1.項目名稱及描述：

名稱：大學生校園生活信息咨詢服務臺

描述：主要解決的問題是，為大學低年級學生提供其想了解的，在生活和學習上的問題，并且為其解決各方面的難題。

2.項目目的：

雖然當前大學生獲取各方面的信息途徑有很多，信息量也很龐大，但是很雜亂，缺乏系統性信息和缺乏指導。為此，我們項目小組提供一個了校園生活信息咨詢服務臺這樣的一個平臺，提供一個溝通和指導的途徑，旨在減少校園生活和學習上的誤區，為其提供一個完整的大學規劃。

3.項目目標：

項目時間期限：項目啟動階段一周、計劃階段三周、執行階段兩周、收尾階段一周。費用預算：堅持節約、高效的原則，合理對費用進行使用。本項目實施過程中，費用涉及較多的內容是打印費，海報制作費，材料費等，初步定費用預算值60元左右。

質量要求指標：為了測定此次活動的實際價值，項目小組將質量要求指標量化，即在項目結束階段，借助整理通過學生反饋回來的服務滿意度來衡量。

4.項目可交付成果：

（1）信息搜集調查問卷

（2）可行性研究報告

（3）項目范圍說明書

（4）項目調查報告

（5）項目實施系列文件

（6）服務滿意度調查問卷

5.項目制約因素：

開展實施項目小組活動主要是利用課余時間，在實施階段受到最主要的制約因素就是時間因素，計劃時間隨時可能因為課程計劃而變化。此外，團隊各個人員分工在已經明確的情況下，人員的變動如請假或離開，也影響項目的計劃實施。

6.假設前提：

假設我們開展活動一切順利，各項任務按時按序有效地完成。

7.附件：

大學生信息服務臺項目責任分配矩陣圖

注意：P（President）表示主要負責人，S（Service）表示次要負責人。任務編號為1200---1325，除主要負責人外，其余均為次要負責人。

項目變更文件

項目中一些不確定性因素導致了項目的推動過程不會像計劃的那樣順利，隨著工作的深入，那些不確定因素逐漸變得明確且和當初的預測不一致的時候，就會導致項目變更，項目的變更是不可避免的。一般來說，項目的目標是項目所有活動的最終判斷準則，變更的發生可能會引起項目目標變化。所以，變更控制是所有項目管理者要高度關注的問題，變更往往會牽一發而動全身，搞不好會一招不慎，全盤皆輸，所以大家對變更的普遍態度是慎之又慎。

為了對項目變更進行有效控制，應由項目實施組織建立變更控制系統。變更控制系統就是一套事先確定的修改項目文件或改變項目活動時應遵循的程序，其中包括必要的表格或其它書面文件，責任追蹤和變更審批制度、人員和權限。變更控制系統應當明確規定變更控制委員會的責任和權力，并由所有的項目干系人認可。

變更控制系統可細分為整體、范圍、進度、費用變更控制系統。變更控制系統應當同項目管理信息系統一起通盤考慮，形成整體。

從變更產生的來源來看，變更的因素可以分為兩類：內部因素和外部因素。內部因素是指項目的實施過程中，對實施的狀態對比計劃，發現產生了偏差，從而導致變更項目計劃。外部因素則是指服務對象對項目目標本身發生了變化，從而引起計劃的變更。

在本次項目小組活動中，從項目整體、范圍、費用上看，幾乎沒有變動；少許變動影響到項目小組的進度，主要是在項目開展時間、項目成員任務劃定等，但未有影響項目按照原定計劃完成。

影響變動內部原因和解決措施：

一、項目實施計劃時間即將預定，突如其來的‘考研交流會”影響到我們小組60%以上的成員，原定的計劃不得不將其推遲至下一周。

二、人員的任務都已經確定，此時有小組成員因為請假離開一段時間，小組各個成員任務不得不重新制定和分配。

三、原定項目利用兩次課余時間開展兩次活動，由于小組內部對項目實施反饋結果意見不統一，最后成員協商通過，第二次取消。

影響變動的外部原因和解決措施：無。

WBS工作分解圖

第二篇：軟件項目范圍說明書

軟件項目范圍說明書

一、引言

1、編寫目的

說明編寫這份項目需求說明書的目的，指出預期的讀者。

2、背景說明

(1)待開發的軟件系統的名稱。

(2)本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡。(3)該軟件系統同其他系統或其他機構的基本的相互來往關系。

3、定義

列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。

4、參考資料

列出用得著地參考資料，如：

(1)本項目的經核準的計劃任務書或合同、上級機關的批文。(2)屬于本項目的其他已發表的文件。

(3)本文件中各處引用的文件、資料、包括所要用到的軟件開發標準。列出這些文件資料的標題、文件編號、發飆日期和出版單位，說明能夠得到這些文件資料的來源。

二、任務概述

1、目標

敘述該項軟件開發的意圖、應用目標、作用范圍以及其它應向讀者說明的有關該軟件的開發的背景資料。解釋被開發軟件與其它有關有軟件之間的關系。如果本軟件產品是一項獨立的軟件，而且全部內容子涵，則說明這一點。如果所定義的產品是一個更大的系統的一個組成部分，則應說明本產品與該系統中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統的組成和本產品同其他各部分的聯系和接口。

2、用戶的特點

列出本軟件的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟件的預期使用頻度。這些是軟件設計工作的重要約束。

3、假定和約束

列出進行本軟件開發工作的假定和約束，例如經費限制、開發期限等。

三、需求規定

1、對功能的規定

用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地描述對軟件所提出的功能要求，說明輸入什么量、經過怎么樣的處理、得到什么輸出，說明軟件應支持的終端數和應支持的并行操作的用戶數。

2、對性能的規定

(1)精度

說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。(2)時間特性要求

說明對于該軟件的時間特性要求，如對： ① 相應時間。

② 更新處理時間。③ 數據的轉換和傳送時間。④ 解題時間。

等的要求。(3)靈活性

說明對該軟件的靈活性的要求，即當需求發生某些變化時，該軟件對這些變化的適應能力，如：

① 操作方式上的變化。② 運行環境的變化。

③ 同其他軟件的接口的變化。④ 精度和有效時限的變化。⑤ 計劃的變化或改進。

對于為了提供這些靈活性而進行的專門的設計的部分應該加以表明。

3、輸入輸出要求

解釋各輸入輸入數據類型，并逐項說明其媒體、格式、數值范圍、精度等。對軟件的數據輸出及必須標明的控制輸出量進行解釋并舉例。包括對硬拷貝報告（正常結果輸出、狀態輸出及異常輸出）以及圖形或顯示報告的描述。

4、數據管理能力要求

說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求做出估算。

5、故障處理要求

列出可能的軟件、硬件故障以及對各項性能而言所產生的后果和對故障處理的要求。

6、其它專門要求

如用戶單位對安全保密的啊喲球，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環境可轉換性的特殊要求等。

四、運行環境規定

1、設備

列出運行該軟件所需要的硬件設備。說明其中的新型設備及其專門功能，包括：(1)處理器型號及內存容量。

(2)外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量。(3)輸入及輸出設備的型號和數量，聯機或脫機。(4)數據通信設備的型號和數量。(5)功能鍵及其他專用硬件。

2、支持軟件

列出支持軟件，包括要用到的操作系統、編譯（或匯編）程序、測試支持軟件等。

3、接口

說明該軟件同其他軟件之間的結構、數據通信協議等。

4、控制

說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源。

五、數據要求

1、數據的邏輯描述

對數據進行邏輯描述時可把數據分為動態數據和靜態數據。所謂靜態數據，指再運行過程中主要作為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。所謂動態數據。包括所有在運行中要發生變化的數據以及在運行中要輸入、輸出的數據。進行描述時應把各數據元素邏輯地分成若干組，列如函數、源數據或對于其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定義（或物理意義）度量單位、值域、格式和類型等有關信息。

(1)靜態數據：列出所有作為控制或參考用的數據元素。

(2)動態輸入數據：列出動態輸入數據元素（包括在常規運行中或聯機操作中要改變的數據）。

(3)動態輸出數據：列出動態輸出數據元素（包括在常規運行中或聯機操作中要改變的數據）。

(4)內部生成數據：列出向用戶或開發單位中的維護調試人員提供的內部生成數據。(5)數據約定：說明對數據要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制（容量、文卷、記錄和數據元的個數的最大值）。對于在設計和開發中去頂的臨界性的限制更要明確指出。

2、數據的采集

(1)要求和范圍

按數據元的邏輯分組來說明數據采集的要求和范圍，指明數據的采集方法，說明數據采集工作的承擔者是用戶還是開發者。具體的內容包括： ① 輸入數據的來源：例如是單個操作員、數據輸入站，專業的數據輸入公司或它們的一個分組。② 數據輸入（指把數據輸入處理系統內部）所用的媒體和硬件設備。如果只有指定輸入點的輸入才是合法的，則必須對此加以說明。③ 接受者：說明輸出數據的接受者。

④ 輸出數據的形式和設備列出輸出數據的形式和硬設備。無論接受者將接受到的數據是打印輸出，還是CRT上的一組字符、一幀圖形，或一聲警鈴，或向開關線圈提供的一個電脈沖，或常用介質如磁盤、磁帶、穿孔卡片等，應具體說明。⑤ 數據值的范圍：給出每個數據的合法值的范圍。⑥ 量綱：給出數字的度量單位、增量的步長、零點的定標等。在數據是非數字量的情況下，要給出每一種合法值的形式和含意。⑦ 更新和處理的頻度：給出預定的對輸入數據的更新和處理的頻度。如果數據的輸入是隨機的，應給出更新處理的平度和平均值，或變化情況的某種其他度量。(2)輸入的承擔者

說明預定的對數據輸入工作的承擔者。如果輸入數據同某一接口軟件有關，還應說明該接口軟件的來源。

(3)預處理

對數據的采集和預處理過程提出專門的規定，包括適合應用的數據格式、預定的數據通信媒體和對輸入的時間要求等。對于需經模擬轉換或數字轉換處理的數據量，要給出轉換方法和轉換因子等有關信息，以便軟件系統使用這些數據。

(4)影響

說明這些數據要求對于設備、軟件、用戶、開發單位所可能產生的影響，例如要求用戶單位增設某個機構等。

第三篇：《××項目軟件需求變更說明書》

軟件需求變更說明書

項目名稱： 長益高速收費數據分析系統一、概述

因湖南省高速公路聯網拆分系統軟件升級，導致長益下屬收費站入口和出

口交易數據、拆分數據、代收拆分數據無法獲取。而現階段省高管局監控中心無法在上報報表日期內提供拆分數據，從而導致長益高速收費數據分析系統無法輸出相關報表。經過深入了解和分析，在與業主方多次探討后，提出以下變更說明。

二、變更內容

? MTC實收和流量

原始情況：

人工收費系統出口站收費數據和出口流量的導入，是由收費站工作

人員從站級拆帳網下載的“收費數據統計報表”并再錄入部分細分數據，導入長益收費數據分析系統。

變更后：

收費站工作人員在分析系統中MTC實收功能模塊中只錄入出口各車

型實收收入、各車型流量、免費車流量、綠通車流量、系統外收入、綠通車減免金額、免費車減免金額、手工票金額。

運營部工作人員在分析系統中MTC實收功能模塊中導入本路段各站

進，其他路段出的代收流量的各車型估算流量。其中包括各車型流量、綠通車流量、免費車流量。

? MTC實得

原始情況：

人工收費系統實得數據的導入，是由收費站工作人員從站級拆帳網

下載的“拆帳統計報表”，導入長益收費數據分析系統。

代收實得的導入，是由運營部工作人員從拆帳網下載的“長張高速

公司名稱，版本號

2公路聯網收費實際分配收入統計表”，導入長益數據分析系統。

變更后：

運營部工作人員在分析系統中MTC實得功能模塊中導入估算MTC各

車型拆分收入。其中包括本路段各車型收入、系統外收入及代收業主各車型收入、系統外收入。

? 報表輸出

由于原始基礎數據的變更，所導致從數據模型上的建立發生了變化，從而將導致原長益數據分析系統輸出報表無法根據原來基礎數據的數據輸出，需要轉換為估算的數據輸出，需要對所有的報表進行修改。

需要修改的報表有以下：

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

?

? 公司－綠色通道車輛 公司－收費站拆帳情況表 公司－單車收費標準計算表 公司－流量對比表 公司－各類車流量收入比重對比圖 公司－各類車流量收入比重表 公司－實征率 公司－高速免費車 公司－收費車流量統計 公司－ETC收費車與免費車 公司－月流量分析 公司－ETC征費情況 公司－月收入圖 公司－月收費情況總表 公司-收費車流量與收入統計 路勁-收入影響因素對比表 路勁-項目每月輸入及車流匯總表 路勁-各站每月收入及車流匯總表 路勁-歷年路費收入圖 路勁-歷年次票車流量圖 路勁-日報 省局-交通流量統計月報表 省局-綠色通道和免費車公司名稱，版本號

? 省局-其他收入分項統計

? 三年同天對比-1月

? 三年同期對比-2月

? 三年同天對比-3月

? 三年同期對比-4月

? 三年同期對比-5月

? 三年同期對比-6月

? 三年同期對比-7月

? 三年同期對比-8月

? 三年同期對比-9月

? 三年同期對比-10月

? 三年同期對比-11月

? 三年同期對比-12月

? 周報-高速公路

? 周報-總表

? 周報-流量圖

? 周報-收入圖

? 周報-老路

? 月報-月收費

? 月報-財務系統內金額拆帳

? 月報-月度收費情況

公司名稱，版本號 4

第四篇：關于合作開發項目相關文件材料移交說明書

關于合作開發項目相關文件材料移交說明書

新疆珠江塑料廠、新疆珠江塑料有限責任有限公司、烏魯木齊容天物業管理有限公司與新疆安隆房地產開發有限公司就土地合作開發項目前期的土地掛牌、土地司法解封及拆遷階段性工作已完成，現就所完成工作的相關文件、法律裁定及土地證等材料移交作以說明。

一、移交方所移交的相關文件、材料僅為該土地開發項

目的順利實施使用，不得進行其他用途。移交后如

出現相關的經濟、法律等糾紛損失應由接收方承擔。

二、高級法院（長城資產公司）、中級法院（外經貿公司

和富潤祥公司）和沙區法院（東方資產公司）關于

土地解封的全部法律文件及裁定移交詳見2014年1

月22日的兩頁《移交材料情況》清單。

三、關于相關的土地證及它項證的移交材料詳見2014

年1月24日新疆安隆公司的《承諾書》及《收條》。

以上情況，僅此說明。

移交方代表：新疆珠江塑料有限責任公司接收方：新疆安隆房地產開發公司簽字蓋章：簽字蓋章：

2014年1月24日2014年1月24日

第五篇：營改增系統改造項目需求范圍說明書

奇瑞徽銀汽車金融股份有限公司

營改增系統改造項目

需求范圍說明書

奇瑞汽車金融股份有限公司

二〇一六年三月

1/ 19

項目要求 第一節 概述

根據國家稅務總局的安排，銀行業將實施“營改增”，即銀行由繳營業稅改繳增值稅，同時為客戶提供增值稅稅票。為配合“營改增”改革后各類應稅和稅務管理信息化需求，滿足財政部、國稅總局頒布的各類監管要求，啟動營改增系統改造建設和現有系統改造。

第二節 系統方案與技術方面要求

1.1.總體目標

1.2.技術要求

技術方案需充分考慮到先進性要求，體現在以下方面但不限于以下方面：

1、開標供應商提供的功能應滿足我司業務開展的要求；

2、開標供應商所提供的系統軟件應符合業界相關技術標準；

3、提供系統完整的源代碼，提供開發平臺，至少滿足我司二次開發的要求。

4、通過我司會計核算平臺及核心、總賬對接的方案，5、提供完整的營改增系統改造功能應用，基于營改增要求，完成我司現有系統改造功能；

6、系統支持跨平臺部署等；

7、系統應充分考慮我司數據標準化的要求，能夠支撐標準化和監管統計需求；

2/ 19

8、系統應采用平臺化設計，支持功能性拓展；

9、系統擴充方便，設置修改靈活，操作維護簡單，能夠適應業務的快速變化及發展；

10、系統提供的軟件產品在業務擴展、應用工具、數據庫、操作系統等方面具有開放性，做到標準化、通用化；

11、系統安全、可靠，供用戶進行有效的維護與使用,系統運行維護要求自動化、參數化和交易化;

12、系統嚴格按照軟件工程要求提供詳細的各類文檔；

13、能夠滿足我司現有的開發規范，保證代碼的可讀性和統一性；

14、操作系統、數據庫和中間件的配置符合我司技術架構要求，ip地址與目錄等參數配置信息不得寫在程序中；

15、基礎軟件，包括操作系統、數據庫、中間件必須符合我司基礎軟件規范；

16、不允許使用RSA1024及以下強度的加密算法，建議使用國密算法；

17、在設計技術架構時需要充分利用我司現有的軟硬件環境，充分考慮我司現有的軟硬件環境，保證兼容性，保護我司現有投資；

18、滿足我司應用架構的管理要求，充分考慮與其他系統之間的關聯性。

19、系統支持負載均衡部署方式，性能不足時可以通過增加設

3/ 19

備線性擴展處理能力。

20、產品必須是行業主流產品，符合業界相關技術標準，在國內外有成功的技術實施案例，滿足監管需求；

21、產品必須有后續研發系列，并有良好的發展前景；

22、可與主流廠商軟件集成而不影響系統性能；

23、與系統連接的整體配置無單點故障，所有部件采用冗余設計，確保無任何單點故障，并能滿足未來7×24小時的應用服務。

24、支持在線維護、更換、升級硬件部件和微碼；

25、提供后續開發支持，對于人員成本單獨報價。

1.3.系統技術設計原則

1、實用性和適用性

充分利用成熟的先進技術，采用性能/價格比比較高的產品。應用系統設計必須符合實際，適用于銀行信息系統建設。

2、完整性

所設計需滿足增值稅管理所有要求，設計范圍包括營改增系統改造和現有系統改造。

3、開放性、兼容性和連通性

所設計的系統在結構上真正實現開放，各種設計規范、技術指標及產品均符合國際和工業標準，包括各種廣域網、局域網、計算機及數據庫協議，并可提供多廠家產品的支持能力，從而為未來的業務發展奠定基礎。系統中所采用的所有產品都要滿足相關的國際標準和國家標準，是開放的可兼容系統，能與不同廠牌的產品兼容，4/ 19

可以有效保護投資。系統具備與各種協議計算機通行網絡互連互通的特性，確保綜合網公用基礎設施功能充分發揮。

3、先進性

系統技術水平要保證先進性，符合當代信息技術發展形勢，代表當前計算機科學的發展方向。所選擇的各平臺供應商應有能力對該項進行持續開發，可以保證該項技術不斷地更新并可順利升級而維持系統的先進性。提供良好的技術支持和技術服務，以滿足當前的業務需求，使業務或生產系統具有較強的運作能力。

4、高可靠性和可用性

通過提供給用戶高可靠的產品（硬件、軟件、服務），帶有系統容錯性的方案(冗余、備份)，較強的管理機制和控制手段，具備事故監控和網絡安全保密等技術措施，保證系統的安全可靠和高可用性。

系統建設盡量用主流產品，以保證系統的高質量和穩定性。系統應最大限度集成世界上最穩定且優秀的技術及組件，采用成熟技術以降低系統的不穩定性。對系統如硬件、操作系統、網絡、數據庫應設計盡可能詳盡的故障處理方案，以保證系統的快速恢復。

5、靈活性和可擴充性

所設計的系統應具有良好的擴充性，能夠根據管理要求，方便擴展網絡覆蓋范圍、網絡容量和網絡各層節點的功能，以適應今后可能出現的較大任務符合。硬件平臺具有可升級性，當需要時可以通過新的計算機設備同原有計算機設備一起工作以提高系統的5/ 19

處理能力，而保護原有的投資。在源系統改造或者前端應用的需求發生變化時，整個系統的架構和設計方法可以適應這種變化，不會對已有的平臺造成影響。

6、易維護性

在系統總體設計上注意系統的維護性。盡量采用大家熟悉的易于維護系統平臺。系統軟件安裝簡單、易于操作。

7、標準化

應用軟件開發符合軟件開發標準的要求，方便維護和擴展。業務處理符合國家法律、法規和有關政策規定。

1.4.功能要求

系統需滿足（但不限于）奇瑞汽車金融營改增系統改造系統的以下全部需求：

基于我司IT架構優化，設計現有系統改造功能，包括： 交易認定、價稅分離； 會計核算； 客戶信息管理； 發票回傳。

需要建立統一 “營改增系統改造”實現各類應稅和稅務管理信息化的目標，包括以下幾個功能：

實現“增值稅票”的管理、打印等功能 搭建統一的稅務管理平臺

6/ 19

滿足對外披露需求

基礎功能 1 價稅分離模塊

1.1 價稅分離原始數據導入

通過系統自動接口（手工導入作為輔助方式）方式，將涉及價稅分離的各類交易數據導入營改增外掛管理平臺，并支持導入數據驗證校驗、版本控制、導入日志記錄等功能。

1.2 價稅分離交易認定規則設置

提供增值稅相關各類交易（包括常規貸款交易及特殊交易，如：經銷商服務費攤銷、貼息攤銷、逾期利息轉表外、期末補提利息、期初沖回等）認定規則和計稅方法配置功能，形成交易明細與價稅分離規則映射關系。

1.3 稅率設置

提供增值稅所屬稅目及稅率信息維護功能，根據交易代碼設置的稅率，并作為價稅分離計算參數。

1.4 價稅分離計算

根據價稅分離交易認定規則、稅率和交易明細數據，進行價稅分離計算。

1.5 會計分錄生成

支持根據價稅分離計算結果和銀行會計科目及分錄規則，自動生

7/ 19

成增值稅調整及相關分錄。2 銷項發票管理模塊

2.1空白發票管理

支持集中維護銀行購買的空白發票功能，并提供總行對空白增值稅專票的統一管控功能。包括請領入庫，將購買的空白專票維護到營改增外掛平臺中，每筆開票記錄應與實物專票一一對應；專票分發，由總行或地市分行統一管理下轄所有機構空白發票的請領入庫，并分發至各機構，系統上對空白發票的請領和分發進行統一管理（目前沒有分支機構，但是該功能需保留）。

2.2發票盤點

支持對空白發票進行盤點，保證總分行發票打印的準確性及發票庫存的準確性。其中各打印終端可按日盤點打印成功及待打印發票信息，按月盤點發票庫存情況。支持生成盤點報表，并經復核人復核。

2.3發票打印

能夠與金稅系統開票請求接口集成，執行增值稅專票打印工作。打印時，對客戶資質、是否已開具發票等自動校驗，防止錯開或重復開票。同時，支持同一交易對手增值稅發票打印的合并與拆分，拆分方式可選擇平均拆分或自定義拆分。

2.4例外處理

對增值稅打印過程中遇到系統異常等意外情況進行記錄，并支持對例外事件后續跟進處理。例如，打印未成功需重打，但已經從待打印池中已找不到該筆發票信息；需要沖紅已打印的發票再重打；打印

8/ 19

沖紅發票等情況。

2.5手工開票

對于需手工開票的業務收入，若屬于系統內中間業務收入，由專票打印員通過模糊查詢，向交易數據的接口提交數據請求，交易系統返回交易信息和客戶信息給營改增外掛管理平臺，選擇需要打印的任務，提交審批完成后發起打印請求；若屬于系統外相關業務收入，由專票打印員手工錄入專票信息，提交審批完成后發起打印請求。

2.6發票追溯

提供增值稅發票的追溯功能，支持對發票各個節點操作的記錄、時間、操作人進行追溯。

2.7發票遺失管理

對遺失的增值稅專用發票進行登記記錄，并將信息傳給金稅系統進行掛失處理。

2.8發票作廢

當發生空白專票或已開專票作廢情況時（如尚未使用的紙質專票損毀），支持相應專票作廢處理流程，并進行詳細記錄。

2.9紅字發票管理

支持紅字發票開具、申請和審批流程管理功能，并進行詳細記錄。2.10電子稅票管理

待電子發票在行業內推行之后，支持電子發票的開具與管理，并與稅務局電子發票系統對接，實現發票數據的傳輸。3 進項發票管理模塊

9/ 19

3.1認證 掃描認證

登記銀行收到的各類增值稅發票，記錄各類進項稅票銀行內部審批結果，支持進項發票審批狀態查詢。通過金稅系統掃描登記進項專票信息，提交給稅務專員審核。

電子認證

對于取得的專票，能夠實現與稅務局電子發票系統對接，進行電子認證。

3.2進項轉出

支持對涉及進項轉出的數據信息錄入平臺，并按照預設邏輯對進項發票進行進項轉出操作，并提供匯總功能。

3.3預警提示

對進項發票的認證狀態進行跟蹤，對于接近認證期限仍未進行認證的發票設置自動預警提示。

3.4抵扣認證

支持通過審批的進項專票上傳至稅務局網站進行認證，可即時聯機認證或統一批量認證，認證通過后將認證信息回傳至財務管理系統進行進項科目的調整。

3.5未通過認證管理

對于未通過認證發票，顯示原因并記錄后續跟進和處理流程。4 稅務管理

4.1納稅申報管理

10/ 19

支持增值稅納稅申報數據采集、計算和人工調整功能，生成納稅申報報表和相應會計分錄。

4.2稅務管理統計查詢

支持多維度、跨組織的稅務管理數據、增值稅計算明細、發票信息綜合查詢功能，并提供稅務數據分析和風險監控功能。

4.3稅會差異分析

針對增值稅會計口徑數據、稅務申報口徑以及開票口徑進行自動差異分析，形成稅會差異分析報表。5 系統基礎管理

5.1納稅主體管理

提供納稅主體基本信息維護功能。5.2用戶權限和日志管理

提供基于角色授權的用戶權限管理體系和詳細的系統操作日志記錄機制，保障系統數據信息安全。

5.3系統接口管理

提供包括金稅系統、數據倉庫、財務系統、業務系統等與平臺相連接的數據接口管理和維護功能，接口應為開放式，對于新增業務能夠及時維護，并導入數據。

5.4工作流設置

支持系統內部各類管理流程的審批工作流配置與維護。5.5 數據備份還原管理

支持平臺中各類數據、信息的備份和還原功能，確保業務連續性。

11/ 19

電子發票管理

6.1電子發票數據生成

支持按預先設置的開票規則填開發票，提交稅務機關后臺系統生成電子發票數據，并自動分配電子發票號碼同時對開票信息加密，生成防偽碼和二維碼，最終生成完整的電子發票。

6.2電子發票作廢

當發生開票錯誤等情況時支持電子發票的作廢處理，并進行詳細記錄。

6.3電子發票紅沖管理

支持電子紅字發票開具、申請和審批流程管理功能，并進行詳細記錄。

6.4電子發票查詢和統計

支持在系統中查詢和統計已開/未開電子發票以及已收進項電子發票的開票項目、開票金額等信息。

6.5進項電子發票認證抵扣

支持系統錄入獲得的進項電子發票信息，將通過審核的進項電子發票上傳至稅務局網站進行認證，可即時聯機認證或統一批量認證，認證通過后將認證信息回傳至財務管理系統進行進項科目的調整。

6.6電子發票預警

支持對電子發票開具過程中異常情況的預警，包括作廢過多、紅沖過多、申報異常等。營改增系統改造其他業務要求

12/ 19

7.1實現財管系統、會計核算平臺、數據集市及其他相關系統的對接，與其他系統交互通過DS或文件分發平臺。

1.5其他要求

一、系統測試

系統測試是項目質量的重要保證，開標供應商必須配備專業的測試人員，組建專業的測試團隊，制定完善的測試方案。測試方案包括功能測試和非功能測試。

1.功能測試方案應包括如下測試內容： －測試目標 －測試范圍

－參加測試人員及組織分工。－測試過程中的缺陷管理。－測試完成標準

－測試工具：測試用例管理工具、缺陷管理工具、性能測試工具、配置管理工具等。－測試數據。－測試實施計劃。-測試風險分析。－測試交付物。

－測試的審核和結果認定方法。2.非功能測試方案應包括如下測試內容： －測試目的

13/ 19

－測試范圍 －測試啟停準則

－模型：業務模型、測試模型 －測試指標 －測試策略 －測試內容

－測試實施準備：環境準備、工具準備、數據準備、腳本準備 －測試組織結構 －測試實施計劃 －測試風險分析 －測試交付物

－測試的審核和結果認定方法。

二、項目驗收

驗收是在項目完成開發并成功試運行的基礎上進行的。試運行期不能少于兩個月。測試驗收由采購人組織，對應用軟件進行測試驗收，合格后出具合格證明。如試運行期間統計或測試數據表明系統在功能、性能指標或可靠性方面不符合要求，開標供應商有責任及時解決，應根據問題嚴重程度和解決時間，順延或重新開始試運行。

成交供應商必須為每一項的測試編寫測試手冊。驗收測試手冊的內容包括：測試目的、測試環境和測試所需的設備、測試過程的描述、測試結果及分析、具體的安裝、測試和驗收要求以最終合同

14/ 19

簽訂為準。

驗收需要開標供應商提交的文檔至少包括：系統建設的詳細工程日志、系統的需求說明書、系統的概要設計、詳細設計說明書、系統的數據庫設計說明書、系統的使用說明書、系統的操作說明書、系統的測試大綱、系統的測試報告。

驗收需要開標供應商提交的全部源程序，提供開發工具、自有產品及開發平臺，以及相應的書面說明等，并保證其合法性，由此產生的所有爭議和法律問題由開標供應商負責，由此產生的全部費用由開標供應商負責。

如試運行期間統計或測試數據表明符合要求，將通過延伸，在雙方簽署驗證證書后進入保修期。

三、技術支持及售后服務

開標供應商在邀標文件中必須書面聲明充分了解并接受奇瑞汽車金融股份有限公司的技術支持及售后服務條款，即：

1、在跟蹤維護期內，乙方每年必須為甲方提供2次應用系統檢測和評估，并提供檢測和評估報告，偵測應用系統中可能會出現的問題，以協助防范可能出現的風險；

2、在跟蹤維護期內，乙方保證按照本合同約定的服務內容、服務方式和服務質量向甲方提供合格的服務，乙方保證服務質量符合甲方要求，并通過甲方驗收；

3、在跟蹤維護期內，乙方保證提供服務的技術人員的數量和素質滿足履行本合同的要求；保證人員的穩定性，未經甲方同意不

15/ 19

得隨意更換；如果甲方要求更換服務人員的，乙方應根據甲方的要求更換；

4、對于重大系統的上線、決算等重要時點，乙方將提供現場的技術支持服務，以協助系統的順利運行。

5、乙方提供7x24x365的故障應急反應機制。甲方系統一旦出現重大故障，則馬上啟動故障應急反應程序，提供遠程技術支持，并承諾采用最快的交通工具趕到現場，提供現場的技術支持和技術保障，以協助生產和運行的順利進行。到達現場后，乙方將協助客戶進行故障診斷和排除。如故障發生的原因是由乙方提供的產品或服務引起的，則乙方會調集技術人員以盡早修復，并提出書面故障分析報告；如確認故障發生的原因是由第三方提供的產品或服務引起的，則乙方向客戶提供書面故障診斷分析報告，在提供書面故障診斷分析報告之前，乙方將口頭報告故障原因，并協助客戶與該第三方交涉，配合第三方排除故障。

6、在跟蹤維護期內，乙方為甲方提供甲方工作時間的遠程技術電話支持。乙方在接到甲方通過電話或電子郵件方式提出的服務請求后，應在2小時之內給予響應。如有軟件故障不能通過電話解決，乙方應在24小時內提供現場技術支持。

7、服務完成后，乙方應將完整的、與所提供服務有關的技術資料，包括但不限于：系統維護紀錄、系統變更記錄、完整的源程序代碼等裝訂成冊提交給甲方系統管理部門；

8、乙方應提供必要的技術指導和不少于5人天的封閉式技術

16/ 19

業務培訓，保證甲方能正確、安全、有效地使用及維護系統。

9、根據甲方要求對修正系統差錯、改進系統性能、增加系統功能；

10、乙方保證派出人員遵守甲方有關制度、工作紀律和安全規定，乙方服務人員應在甲方規定的工作場地范圍內工作。

11、在跟蹤維護期內，由于乙方軟件產品質量產生的問題，乙方免費提供維護。

四、項目實施

1、項目管理

開標供應商應按照項目管理的要求向我司提供開發計劃、時間進度。

開標供應商應明確提出參與本項目的工作人員構成、職責、學歷背景、從業背景及參與本職工作的時間。開標供應商應確保在項目實施過程中不變更奇瑞汽車金融認可的項目經理。

在技術需求應答書中，開標供應商應明確其分擔職責，進行清晰的工作任務描述。

開標供應商應向買方明確提出詳細的質量控制、風險控制措施，確保項目的順利進行。

2、項目人員

a、項目經理、咨詢人員

項目經理、咨詢人員必須有2（含）家以上相關銀行營改增系統改造完整項目實施、咨詢經驗。

17/ 19

b、開發人員以及測試人員

開發、測試人員必須有2年以上的開發、測試工作經驗，在通過我司相關考試、審核后方能進入項目組開始項目的開發、測試工作，開發、測試人員不允許復用。

以上項目經理、咨詢、開發、測試人員，中選方在駐場實施前必須提供相應的工作、學習簡歷，供采購方進行審核，如采購方不予認可，成交供應商必須按照采購方的要求更換人員。在項目實施階段，如采購方認為項目經理及實施人員達不到相應要求，采購方有權要求成交供應商更換符合要求的人員，成交供應商不得以任何形式、理由進行拒絕。另，成交供應商需承諾保證實施過程中研發團隊的穩定性。

3、進度

項目應在2016年5月1日前完成（包括應急方案）。

4、技術業務支撐

參與我司項目各階段（系統調研、硬件采購、需求分析、系統設計、系統聯調測試、培訓、系統上線）的工作。

第三節 售后服務

開標供應商對售后服務及系統維護、數據整理和維護工作的技術責任應作明確說明，包括質保期限承諾、服務響應承諾、系統應急方案、技術支持和相應軟件的升級承諾。

一、中選供應商承諾提供一年免費原廠維護。

二、在保修期內，如果軟件設計廠家對用戶購買的軟件有了升級

18/ 19

版本，成交供應商應及時通知用戶。如果用戶有要求，成交供應商應向用戶免費提供相同功能的相同軟件升級和技術支持。成交供應商有責任在保修期內提供以下形式的技術支持服務：

詳見第二節1.5項”技術支持及售后服務”部分。

三、保修期后，成交供應商有義務在本系統的維護、運行管理和開放方面繼續給予用戶技術協作和咨詢，并明確維護費用標準。19/ 19