關于智能客運站系統采購項目
市場詢價征集公告
為提高我司的客運站智能化管理水平，適應“互聯網+”時代的要求，提高客戶服務品質，提升企業競爭力，我司計劃采購智能客運站系統。本次市場詢價征集結果作為招標控制價的參考依據。
第一部分：智能客運站系統
一、項目概況
1.項目目標
綜合智慧交通系統平臺圍繞交通客運創新驅動發展戰略，結合寧德相對完備的基礎交通網絡，以“互聯網+軟件”為支撐，建設寧德交通智慧場站以及互聯網線上服務能力，提升寧德市交通客運的軟實力，提高寧德市交通客運的品味，擴大寧德市對外的影響力。讓市民及商旅人士舒心、安心、放心出行的同時，也為寧德市營造一個有規、有矩、有序、有效的智慧交通體系。
建立智慧場站全面高效的站務系統。
1.1 穩定性和可靠性
（1）系統應具備開放的標準化體系結構，可方便地與其它業務系統銜接，實現與大數據展示平臺、保險統籌系統、車輛管理等業務系統的無縫集成。
（2）系統應經過完善的設計和充分的測試運行，具備在較長時間內連續無故障的運行能力。
（3）系統應提供全面、有效的系統安全機制。
（4）系統應具備強大的容錯、數據恢復與穩定運行的能力。
1.2 兼容性和易用性
（1）全面預算管理軟件在安裝、配置、升級、維護等管理方面應該簡單快捷。
（2）系統應具備易操作的特點，好記易學、實用高效。
（3）系統應易于擴展和升級，能夠根據用戶的具體需求快速、方便地定制、擴展原系統的功能，尤其是和數據中臺的打通。
1.3 平臺先進性
系統具有穩定的技術平臺，靈活開放，具有良好的安全性，能滿足寧德汽運集團業務擴展的需要。
定制類軟件功能，應切合企業實際情況進行開發、定制。應根據業務或技術上的經驗來充分判斷思考功能的必要性，做到以適用為原則，不過度開發。
1.5 可持續服務原則
整個業務軟件平臺是一個長期業務系統，需要不斷的調整、升級。為保證業務不中斷、投入不浪費，應當以可持續服務為基本要求，貫穿系統規劃、建設、實施、運維等工作環節中?？沙掷m服務關鍵在于業務知識的積累、軟件技術的傳承、可持續服務保障制度的完善。
1.6 信息的輸入、輸出
系統功能需實現業務數據的輸入及輸出，未實現各系統間的數據聯動之前，不能讓每個系統成為信息孤島，系統需支持各種數據格式的文件信息導入導出功能。
1.7 項目團隊
項目團隊應當選用項目經驗豐富的項目經理；項目啟動后，項目經理要全程參與項目的調研和實施工作，負責項目調研、實施的團隊，如非采購人提出異議，必須保持一致。
二、技術和服務要求
壹、技術要求（本項目核心產品為系統軟件平臺）
（項號1）1.平臺化開發
業務軟件開發應基于成熟的開發平臺，模塊化設計，各模塊無縫集成、一體化應用，并可以逐步拓展，適應寧德汽運集團國內不同地區的業務需求和集成性的要求。能夠靈活迅速的構建一套隨需應變的業務系統，并能夠與現有的IT基礎設施無縫地協同運作。應用模式、業務流程、用戶界面等可根據需要靈活配置應用，而不能通過大量的代碼編寫或者客戶化開發的方式進行，避免后續系統升級或維護時可能帶來的風險；
對于系統的版本的更新，應能快速部署，不能因系統版本的更新而使系統停止運行。
（項號2）2.組件化（減少重復建設）
各業務軟件提供的服務以組件化的方式讓業務端可以即取即用。通過抽象出的組件化服務提供，前臺業務端可以以組合挑選的方式“按需取件”，減少重復建設得以實現。
（項號3）3.功能模塊可復用
數據中心提供的服務要能滿足即取即用和循環使用的要求。
（項號4）4.基礎服務可共用
各業務權限、各業務屬權，各有差別，通過開放共享實現“可共用”
（項號5）5.可靈活擴展，自主開發
未來集團信息業務量可能會激增，能扛得住大流量高峰時期的高并發、高可用將成為一個大挑戰，底層的可靈活擴展能力將非常重要，可支持企業進行自主開發。
（項號6）6.網絡化應用
滿足局域網、廣域網和互聯網應用要求，支持TCP、HTTP、HTTPS等多種網絡協議。支持C/S和B/S使用模式，滿足本地局域網以及移動用戶的接入。
（項號7）7.數據庫和操作系統
支持如DB2、Oracle等高性能或大型數據庫管理軟件的接入；PC端支持Windows操作系統、Mac OS X系統，多主流瀏覽器的使用；移動應用需支持安卓、蘋果手機及常見的平板電腦；保證系統界面、交互、功能一致。
（項號8）8.安全保障
要求數據庫更新采用非覆蓋式，數據庫備份要求系統能自動定期進行或按用戶要求隨時進行，并且可以對數據進行異地災備，保證信息數據的安全和穩定性。要求系統具備嚴格的權限管理，可設定企業對系統不同模塊、子模塊乃至數據項的不同級別操作權限。要求業務網絡具體高安全性的架構設計。
（項號9）9.簡潔易用性需求
要求支持用戶自行設計各種所需報表,所有報表能在屏幕上顯示并可打印或保存為EXCEL、WORD、PDF等多種文件格式的一種或幾種。同時，要求具備完善的圖形統計分析功能，操作簡單不復雜，易于接受與學習。
（項號10）10.接口開放
提供標準開放的集成數據、業務接口和工具，實現與其他系統的對接。支持文本（Excel、txt）、XML、Web Service、Http、微服務、數據接口表、數據庫表等多種技術手段提供系統外使用的相關信息。
（項號11）11.運行快捷性要求
支持大量用戶同時在線。要求在大量用戶同時對系統進行訪問或操作時，系統及開發報表仍能快速響應、穩定運行。
（項號12）12.可升級性需求
要求系統可進行持續升級。并且升級系統時，針對自身需求獨立開發的功能不可產生不利影響或能同步升級，要求業務系統做普通更新時做到系統業務不中斷，重大更新時可做短時間恢復。
（項號13）13.數據存儲、備份及恢復
可做到數據庫的即時備份，在重大災難發生時，可進行相關恢復操作，支持磁盤陣列、磁帶設備、光學介質等存儲介質。
貳、系統實施要求
（項號14）1.權限管理
1.1要求系統可以按照經營管理人員的職責不同進行權限的分配，可以支持功能權限和數據權限的賦權管理。
1.2要求提供用戶角色定義、訪問權限定義，可對用戶進行角色分配，實現不同資源控制的組合式訪問控制與授權管理。
1.3系統對移動終端配置要求應盡可能底，以滿足絕大部分手機使用。
1.4系統的人機交互性是第一要素，需要普通人和年紀較大者迅速熟練使用。
（項號15）2.系統實施后達到的效果
提升企業整體管理能力（可以有效落地企業單車成本管理制度）
提升企業運行效率（可以結合系統的智能推薦有效的進行車輛的調度）
降低企業運營成本（通過加強單車各項成本的管控，可以降低單車成本）
提升企業安全和風險管控能力（可以對安全、風險及例外進行智能的預警）
提供企業運營數據支持依據（可以讓領導及時的掌控公司的整體情況，并為領導決策提供可靠的數據支撐）
提升企業服務標準及體驗（可以為用戶提供更標準的服務）
叁、主要功能
模塊一：業務管理需求
1．功能框圖
2．功能描述
2.1區域設置
2.1.1說明
區域是用來劃分站點和線路的一個分類標準，用來按類別統計站點和線路的。
2.1.2功能需求
1）系統能夠按層次管理區域信息。
2）用戶能夠設定區域的助記符。
3）區域的編碼必須能夠體現它的層次。
4）系統能夠實現區域的查詢。
2.2站點設置
2.2.1說明
站點是組成線路的最小元素，并且是用來描述收費點、難行路段等元素的。
2.2.2功能需求
1）用戶能夠設定站點的助記符。
2）站點的編碼應該是四位數的代碼。
3）站點的編碼必須能夠體現它的所屬區域。
4）系統能夠實現站點的查詢。
2.3線路設置
2.3.1說明
線路是由起點站、終點站構成，并且包含線路通過路段、收費點、難行路段和繞道。
2.3.2功能需求
1）系統能夠在線路中設置起點站、終點站。
2）線路的六位編碼由兩個部分組成，所屬車站的編碼和線路的序號。
3）系統能夠根據線路中設定的路段算出線路的總路程。
4）系統能夠為線路設定一個以上（包含一個）的收費點、難行路段、繞道。
5）系統能夠為不同的車站設定線路。
6）系統能夠實現對已有的線路進行復制的功能。
2.4班次管理
2.4.1說明
班次是針對線路來設定的，一個班次只能對應一條線路，一條線路可以對應多個班次。一個班次可以有一個或多個班次循環。
2.4.2功能需求
1）班次的六位編碼由兩個部分組成，所屬車站的編碼和班次的序號。
2）系統能夠設定班次是否能夠聯網售票和多點上車。
3）系統能夠根據線路編號設定班次所屬線路。
4）系統能夠設定班次的營運時間段。
5）系統能夠設定班次循環的起始時間。
2.5車型管理
2.5.1說明
車型是按照不同的車根據規格來進行分類的。
2.5.2功能需求
1）系統能夠設定多種不同的車型。
2）系統能夠設定不同車型的不同的票價因素。
3）系統能夠設定不同車型的座位表。
4）系統能夠設定針對車型的結算費率。
2.6車牌/報到卡管理
2.6.1說明
車牌在系統中唯一標識每一輛車，報到卡是車站用來進行報到管理的一種工具。但報到卡不是每一輛車都具有的，不具有報到卡的車只能進行手工報到。
2.6.2功能需求
1）系統能夠設定每輛車的車牌和車屬單位。
2）系統能夠設定每輛車的車型。
3）系統能夠自動設定每輛車的車屬單位跟車站簽署的合同。
2.7票價管理
票價管理主要為票版生成票價時提供可維護的票價公式，生成票價時全部按照全票的價格來計，對于半票、學生票、打折票都是以此為基礎在售票時再具體生成的。
2.7.1票價硬調
票價硬調是針對班次進行班次中對應的站點根據車型進行票價調整。它只能調整班次所經過的站點的票價。
1）系統能夠設定執行票價硬調的時間段。
2）系統能夠根據指定的班次生成可選擇的能夠實行票價硬調的站點集合。
2.7.2折扣管理
2.7.2.1說明
折扣管理是設定可以打折的班次、打折的時段及最低折扣率，對售票員出售打折票時選擇打折班次及折扣率的一種限制。
打折分三種情況：1.對規定的班次，可以按批量打折；2.往返票；3.學生票、半票。
2.7.2.2功能需求
通過維護打折起始時間、結束時間、折扣率以及是否分時段打折等來實現控制到某天的某個時段進行打折的情況。
2.8售票點管理
2.8.1說明
售票點是出售車票的地點，可以是車站的售票窗口、各地的社會代售票點、建行代售票點。
2.8.2功能需求
1）系統能夠對一個班次設定多個上車點。
2）系統能夠對不同的上車點設定不同的上車時間和檢票口。
2.9車屬單位
2.9.1說明
車屬單位是用來設定每輛車的所屬單位。
2.9.2功能需求
1）用戶能夠設定車屬單位的助記符。
2）車屬單位的編碼應該是四位數的代碼。
2.10結算協議
2.10.1結算方式
2.10.1.1說明
結算方式就是財務結算時提供的幾種結款方式。
2.10.1.2功能需求
此功能是用來維護結算方式的名稱、代碼和類型，通過此功能維護可以靈活的調整結算方式來滿足將來的需求。比如：按現（也就是按現金結算）、本司、外司。
2.10.2外司協議管理
外司協議管理是對外公司的運力單位按車型和站點的不同而實行的結算標準。
1）系統能夠設定不同公司的不同車型的結算費率。
2）系統能夠設定同種車型不同站點的結算費率。
2.10.3本司結算硬調
2.10.3.1說明
結算硬調是對本公司的運力單位按車型和站點的不同而實行的結算調整。
2.10.3.2功能需求
1）系統能夠設定不同公司的不同車型的結算費率。
2）系統能夠設定同種車型不同站點的結算費率。
2.11進站合同
2.11.1說明
進站合同是車屬單位與車站之間簽訂的一項合同。
2.11.2功能需求
錄入和跟蹤進站合同，每次簽訂合同后都要進行錄入工作，錄入的項目有合同編號、甲方、乙方、經營者、車牌號碼、起點站、終點站、日發班次、座位數、季度停車費、勞務費率、發班保證金、合同生效日期、合同終止日期、甲方簽字人、乙方簽字人、甲方聯系電話、乙方聯系電話、合同內容、備注等信息，這些信息為后面的電腦自動結算提供重要參數。
2.12承包合同
2.12.1說明
承包合同是客運公司和承包者之間簽訂的一項合同。
2.12.2功能需求
與進站合同一樣需要進行維護，主要也是為財務結算提供參數。
2.13包車管理
2.13.1說明
包車在這里只是記錄包車單位的包車信息。
2.13.2功能需求
系統能夠根據設定的車型、到站、總路程和其他費率計算出參考租價。
2.14查詢報表
業務相關的報表主要包括：
站務作業分析
客運班車派車記錄簿
跨省區班車旅客日流量匯總
客運站旅客流量分線月報表
道路旅客流量分線月報表
車輛進站發班月統計表
的士作業量日報表
車次、終點、時間
發車時刻表
車次、時刻、車型、車屬
站點、車型、執行價
站點、車型、標準價
班次匯總表：區域車屬
班次匯總表：車型等級
2.15關鍵業務：票價管理
票價管理主要為票版生成票價時提供可維護的票價公式，生成票價時全部按照全票的價格來計算，對于半票、學生票、打折票都是以此為基礎在售票時再具體生成的。
模塊二：調度需求
1．功能框圖
2．功能描述
2.1 車輛報到處理
2.1.1車輛報到
說明：當車輛為了進站完成特定班次的旅客運載，需要經過報到的確認和對車輛的車型和座位進行核對，然后才能針對那個班次進行檢票，如果需要在多個站上客，則應該到各個站分別報到和檢票。
優先級：高。
車輛報到時，可以通過兩種方式輸入車牌號：1）刷卡輸入；2）手工輸入車牌號。
必須驗證獲得的車牌號是否存在，如不存在，給出“無效的車牌號”的提示。
要區別“通票車”和“班車”兩種車輛的報到情況?！巴ㄆ薄笔侵笡]有固定的班次和發車時間，只有到達站和票價的車票，憑“通票”可以乘坐當天對應到站的任意“通票車”。
如果報到車型座位與票版座位數不符，要提示進行座位調整。
如果報到車型與票版車型不符，要提示進行車型調整。
要記錄車輛每次進出站的刷卡信息。
必須記錄每次的報到情況。
2.1.2撤銷報到
2.1.2.1說明和優先級
說明：撤銷報到是對車輛報到的反向操作，由于偶然的錯誤或特殊原因使得已報到的車輛需要執行“撤銷報到”操作。
優先級：高。
2.1.2.2功能需求
只能針對當天已報到且沒開始檢票的班次進行“撤銷報到”。
2.1.3班次晚點
2.1.3.1說明和優先級
說明：由于特殊原因，某個（或幾個）班次可能無法按照正常的發車時間發車，需要對班次的發車時間進行臨時調整，要求售票點、檢票點根據晚點時間進行相應的調整，退票有效時間也應進行調整，但客票票面的發車時間仍然保持不變。
優先級：高。
2.1.3.2功能需求
該項操作只針對未報到班次進行。
需要調整“售票截止時間”。
記錄晚點信息。
多點上車的其他上車檢票點也應按照新的時間進行售票、檢票。
2.1.4班次暫停
2.1.4.1說明和優先級
說明：突發原因導致班次無法開行，而暫時停止當天的這個班次運行，這只是暫時的行為，而不是長期的計劃，如果要長期停開班次，應進行“班次長?！?。
優先級：高。
2.1.4.2功能需求
如果在報到之后，檢票之前暫停班次，則應先執行“撤銷報到”操作。
在暫停班次之前或之后，需要對已售出的車票進行“退票”或“并班”處理。
“多點上車”的班次，在暫停后，要及時通知其他上車點。
使該班次票版處于“暫?！睜顟B。
記錄“暫停信息”。
2.2 臨時加班
2.2.1說明和優先級
說明：由于某些特殊原因，如：客運高峰期、突發事件引起某條線路的客流量大幅增加，需要在該線路增開臨時班次，臨時加班只在特定的時間范圍有效。
優先級：高。
2.2.2功能需求
根據輸入的線路、到達站、期限、車型生成臨時班次，臨時班次的編碼參考“臨時班次編碼規則”。
生成臨時班次的同時，也應生成一個班次循環。
臨時班次的?？奎c必須從班次線路的站點中選擇。
設置相應?？奎c的硬調金額。
只有在票版、票價生成完成之后，才能出售車票。
2.3 合并班次
2.3.1說明和優先級
說明：把一個班次已售出的客票合并到其他一班或幾班中，這可能是由于一個班次暫停，或兩個班次賣出較少，并在一班進行運載。
優先級：高。
2.3.2功能需求
合并前的原班次，必須是在票版中的有效班次，否則，應該提示“輸入的原班次無效”。
合并后的新班次，必須是在票版中的有效班次，否則，應該提示“輸入的新班次無效”。
兩個班次的發車點必須相同（屬于同一個車站）。
兩個班次必須屬于同一條線路。
合并座位數=min(已售座位數-已并座位數，剩余座位數)。
如果合并座位數為0，則提示“沒有需要合并的客票”。
必須確定并班后的結算方式：1）按實結算；2）按新車型；3）按原車型。
從售票記錄中取出原班次客票信息。
根據客票座位號，跟新原班次票版座位信息，在新班次票版中給客票分配一個座位。
更新售票記錄，表示出該客票“已并班”。
記錄該客票的新舊班次變化，以便將來能夠恢復。
2.4 恢復班次合并
2.4.1說明和優先級
說明：將已合并的班次恢復到原來的狀態。
優先級：高。
2.4.2功能需求
合并前的原班次，必須是在票版中的有效班次，否則，應該提示“輸入的原班次無效”。
合并后的新班次，必須是在票版中的有效班次，否則，應該提示“輸入的新班次無效”。
通過并班記錄，驗證是否存在該“班次合并”，否則提示“不存在這樣的班次合并”。
根據并班記錄，將各車票恢復到原班次中，同時還原新班次座位。
2.5 調整車型
2.5.1說明和優先級
說明：如果報到車輛的車型與班次計劃的車型不一致，則需要“調整車型”，調整車型除了可能同時影響到票價。
優先級：高。
2.5.2功能需求
“調整車型”一般由“車輛報到”所觸發：報到車輛的車型與班次循環的車型不同。
新車牌、車型由報到的實際車輛決定，舊車型則根據班次，按照班次循環的規則來計算當天當班的車型（參考“班次循環規則”），這個過程一般都在前期直接生成在票版中，因此，可直接從票版中得到。
更新票版中的車型。
如果是由報到引起的車型變化，應注明“引起的車型變化”已經調整成功。
車型變化可能引起以后售票票價與已售出的不同，對于已經售出車票怎樣處理？
采用成批生成票價方式，則需要重新生成該班次的票價。
2.6 修改座位
2.6.1說明和優先級
說明：對某班次的票版的可售座位數進行調整。該操作主要發生在報到車輛與票版中座位數不同或臨時加班車輛中。
優先級：高。
2.6.2功能需求
新座位數如果小于票版中已售座位數，允許報到
更新票版座位數。
2.7 生成票版
2.7.1說明和優先級
說明：對暫停班次進行恢復處理。
優先級：高。
2.7.2功能需求
取消班次票版的“暫停狀態”。
取消“暫停信息”。
2.8調度查詢
2.8.1說明和優先級
說明：查詢調度相關信息。
優先級：中。
2.8.2功能需求
查詢報到情況。
查詢班次動態。
查詢售票情況。
查詢晚點情況。
查詢加班情況。
查詢并班信息。
查詢未報到班次。
2.9關鍵業務：多點報到、多點上車
1、在多點報到的情況下，一個班次會產生多個報到記錄；
2、通過在報到表中加入“上車點”字段，來識別班次在不同站的報到情況；
3、在“班次?？俊闭局性黾印笆欠裆宪圏c”字段，來表示班次是否在該點報到、上車；
3、車輛報到：
根據輸入班次在“班次?？空尽焙推卑嬷袡z索該班次是否應在該站報到；
如果是通票班次，應生成報到序號；
記錄報到信息；
4、多點檢票上車：
系統檢索滿足下列條件的待檢班次：在“班次?？空尽敝兴小吧宪圏c”標志為“Y”且站點為本站的班次；
檢索班次、序號組合的報到記錄存在；
班次、序號組合的車輛必須未檢票、開客憑；
通票班次以班次、序號來識別，普通班次的序號始終為1。
以班次、序號為標識來生成客憑。
模塊三：售票管理需求
1．功能框圖
2．功能描述
2.1售票
2.1.1說明和優先級
說明：售票員為滿足乘客購買車票所進行的系列任務。
優先級：高。
2.1.2功能需求
初始化：系統進入售票狀態后，系統要在狀態欄顯示當前票號、剩余票數、售票員和售票時間信息。
如果選擇普票，則在普票中查找所有符合條件的班次(包括班次號、上車點、?？奎c、發車時間、全票價、車型和剩余座位信息)；
如果選擇通票，則在通票中查找所有符合條件的班次；
根據發車時間，選定相應的班次，系統顯示此班次的座位情況：1）座位號碼 2）座位狀態信息 3）票價；
系統在提示欄顯示此班次的班次號、發車時間、?？奎c、總共座位數和剩余座位數。
輸入全票數和半票數，自動選定相應的座號，可以手動選座號；
輸入的票數大于可售座位數，系統提示“可售座位不足”；
手動選的座號大余實際座號，系統提示“超出座號范圍”；
手動選的座號已被出售或預留時，系統提示“此座號不可售”。
確認座號后，系統鎖定座位狀態，根據選定座位類型和票價類型計算需要的總票價；
輸入乘客交付的現金小于總票價，系統提示“購票金額不足”；
計算應找兌余額。
售票時間太長，根據系統參數，取消座位鎖定，當繼續操作時系統提示“售票時間超時，請重新售票”；
確認購票后，剩余座位數自動減去售出票數，票號自動加上售票數，剩余票數自動減去售票數；
為每張車票生成一條記錄，并逐一打印車票。
將每條記錄插入到售票記錄實體中保存。
2.2補票
2.2.1說明和優先級
說明：售票員為滿足乘客補買車票所進行的系列任務。
優先級：高。
2.2.2功能需求
在普票中查找所有符合條件的班次(包括班次號、上車點、?？奎c、發車時間、全票價、車型和剩余座位信息)；
所列出的班次中的發車時間必須大余系統時間，即未發車的班次；
如果沒有相關的班次，則提示“沒有可售的班次”。
根據發車時間，選定相應的班次，系統顯示此班次的座位情況：1）座位號碼 2）座位狀態信息 3）票價；
系統在提示欄顯示此班次的班次號、發車時間、?？奎c、總共座位數和剩余座位數。
輸入全票數和半票數，自動選定相應的座號，可以手動選座號；
輸入的票數大余可售座位數，系統提示“可售座位不足”；
手動選的座號大余實際座號，系統提示“超出座號范圍”；
手動選的座號已被出售或預留時，系統提示“此座號不可售”。
確認座號后，系統鎖定座位狀態，根據選定座位類型和票價類型計算需要的總票價；
輸入乘客交付的現金小于總票價，系統提示“購票金額不足”；
計算應找兌余額。
補票時間太長，根據系統參數，取消座位鎖定，當繼續操作時系統提示“補票時間超時，請重新補票”；
確認補票后，剩余座位數自動減去售出票數，票號自動加上售票數，剩余票數自動減去售票數；
為每張車票生成一條記錄，并逐一打印車票。
將每條記錄插入到補票記錄實體中保存。
2.3留票
2.3.1說明和優先級
說明：售票員為滿足普通留票點和特權留票點進行留票業務的系列任務。
優先級：高。
2.3.2功能需求
初始化：系統進入留票狀態后，系統要在狀態欄顯示當前票號、剩余票數、售票員和系統時間信息。
在普票中查找所有符合條件的班次(包括班次號、上車點、?？奎c、發車時間、全票價、車型和剩余座位信息)；
所列出的班次中的發車時間必須大余系統時間，即未發車的班次；
如果沒有相關的班次，則提示“沒有可預留的班次”。
根據發車時間，選定相應的班次，系統顯示此班次的座位情況：1）座位號碼 2）座位狀態信息 3）票價；
系統在提示欄顯示此班次的班次號、發車時間、?？奎c、總共座位數和剩余座位數。
輸入全票數和半票數，自動選定相應的座號，可以手動選座號；
輸入的票數大余可售座位數，系統提示“可預留座位不足”；
手動選的座號大余實際座號，系統提示“超出座號范圍”；
手動選的座號已被出售或其它留票點預留時，系統提示“此座號不可預留”。
確認座號后，系統鎖定座位狀態，根據選定座位類型和票價類型計算需要的總票價；
系統要求售票員輸入留票點代碼。
留票操作時間太長，根據系統參數，取消座位鎖定，當繼續操作時系統提示“留票時間超時，請重新進行留票業務”；
確認留票后，首先判斷留票點的類型，是普通留票點則生成售票記錄，是特權留票點則只是鎖定相應座號，并不生成售票記錄，然后剩余座位數自動減去預留票數，票號自動加上留票數，剩余票數自動減去留票數；
為每張車票生成一條留票記錄，不打印車票。
將每條留票記錄插入到留票記錄實體中保存。
2.4銷票
2.4.1說明和優先級
說明：售票員對廢票進行注銷操作的系列任務。
優先級：高。
2.4.2功能需求
初始化：系統進入銷票狀態后，系統要在狀態欄顯示當前票號、剩余票數、售票員和售票時間信息。
如果選擇按票號進行銷票，則在售票記錄中查找所有符合條件的售票記錄(包括?？奎c、票價、乘車日期、票號、班次、發車時間、座號)；
如果選擇按座位進行銷票，需輸入乘車日期、班次、座號，則在售票記錄中查找所有符合條件的售票記錄(包括?？奎c、票價、乘車日期、票號、班次、發車時間、座號)；
如果沒有相關的售票記錄，則提示“沒有可注銷的售票記錄”。
（3） 銷票時間校驗
銷票時間太長，根據系統參數，當繼續操作時系統提示“操作時間太長，請重新銷票”；
確認銷票后，將相應的座號從其它狀態改為未售狀態；
（4）記錄銷票情況
將每條注銷記錄插入到銷票記錄實體中保存。
2.5簽票
2.5.1說明和優先級
說明：提供退簽票時的信息錄入。
優先級：中。
2.5.2激勵/響應序列
退票員輸入票號，系統找出當前票號的售票記錄信息；
退票員錄入簽票人、日期、退票費率等信息，系統記錄此信息。
2.6退票
2.6.1說明和優先級
說明：售票員為滿足乘客退票所進行的系列任務。
優先級：高。
2.6.2功能需求
初始化：系統進入退票狀態后，系統要在狀態欄顯示當前票號、剩余票數、售票員和系統時間信息。
如果選擇按票號進行退票，則在售票記錄中查找所有符合條件的售票記錄(包括?？奎c、票價、乘車日期、票號、班次、發車時間、座號)；
（2） 驗證退票類型
當售票員進行退票操作時，系統提示“確認退票嗎？”；
（3） 計算退票費
（4） 退票時間校驗
退票時間太長，根據系統參數，當繼續操作時系統提示“操作時間太長，請重新進行退票”；
確認退票后，將相應的座號從其它狀態改為未售狀態；
（5）記錄退票情況
將每條退票記錄插入到退票記錄實體中保存。
2.7重打車票
2.7.1說明和優先級
說明：售票員在由于打印卡紙等因素導致的打空而進行重打的一系列任務。
優先級：中。
2.7.2功能需求
1．輸入票號，系統列出此票號的售票記錄；
2．輸入乘車日期、班次和座號，系統列出此售票記錄。
2.8打印票卡
2.8.1說明和優先級
說明：售票員接到停止使用系統及停機時間后進行打印票卡的一系列任務。
優先級：中。
2.8.2功能需求
將系統時間加上停機時間作為發車時間范圍；
（2）查出已售記錄
依次選擇上述班次，系統列出相應班次售出座號及上車點；
對應班次有售出記錄，才可打印票卡。
2.9廢票處理
2.9.1說明和優先級
說明：售票員發現打印出的票號與票版的票號不符或票版印刷問題導致不能使用而出現空票進行處理的一系列任務。
優先級：中。
2.9.2功能需求
售票記錄中的票號出現不連續，根據領票記錄中的票號，對當前票號進行校驗，得出空票數和空票號。
其實就是假打印，票號自動加一，但不打印。
2.10 查詢與報表
查詢包括：售票情況、預售情況、留票情況、退票情況、銷票情況、本站代售、它站代售、售票動態。
報表包括：
售票員營收報表
售票情況分析
2.11關鍵業務：聯網售票
1、區內班次納入聯網售票范圍；
2、售非起點票：
在班次?？奎c中增加“可售起點”標志字段，表示該?？奎c是否可以作為售票起點；
所有上車點也作為?？奎c處理，即把上車點看成是一種?？奎c，當售賣非起點票時（如：檢查站售票），可以通過把不同上車點的票價差異與一般售票統一處理；
3、售通票：
在班次表中，通過字段“類別”來標識該班次是否“通票班次”，通票班次的座位數；
在班次表中，增加“日發班次”來表示該通票班次每天發班次數；
在報到記錄中，增加“序號”字段來表示通票班次的第幾班報到；
在檢票記錄中，增加“序號”字段來表示通票班次的第幾班檢票；
模塊四：票務中心管理需求
1. 功能框圖
2. 功能描述
2.1 售票員營收報表
2.2站務作業分析表
2.3客運運費分配明細表
2.4按車屬單位統計
2.5按車牌統計
2.6加班班次運量統計表
2.7春運生產統計表
模塊五：檢票管理需求
1．功能框圖
2．功能描述
2.1檢票
2.1.1說明和優先級
說明：車票檢票。
優先級：高。
2.1.2激勵/響應序列
激勵序列：①掃描或輸入票號；
②輸入班次和座位號。
響應序列：①驗證車票；
②做檢票標志。
2.1.3功能需求：A. 按票號檢票; B. 按班次和座位檢票
A. 按票號檢票
票號的取得：
①用掃描槍掃描出票號；
②手工檢票：輸入票號。
驗證車票類型：
①普通班次的車票；
②通票檢票時，必須對流對應到報到的車號；
③的士票檢票和通票一樣。
必須是有效的車票才能檢票，無效的車票給出相應的提示。
班次必須報到了才能檢票，沒有報到給出“班次沒有報到，不能開始檢票！”的提示。
①必須是本站上車的車票才能檢票；
②檢票的時間必須在設好的時間段內；
④檢票后在售票記錄中寫入檢票信息；
③恢復已檢的車票。
B. 按班次，座位號檢票
輸入：
①班次；
②座位號。
驗證車票是否存在：
在售票記錄中驗證。
如果售票記錄中不存在，再在并班記錄中驗證，如果也不存在，則給出相關提示；
必須是有效的車票才能檢票，無效的車票給出相應的提示。
班次必須報到了才能檢票，沒有報到給出“班次沒有報到，不能開始檢票！”的提示。
①必須是本站上車的車票才能檢票；
②檢票的時間必須在設好的時間段內；
④檢票后在售票記錄中寫入檢票信息；
③恢復已檢的車票。
2.2補檢
補檢和檢票過程是一樣的，只有檢票的時間不必在設好的時間段內，補檢完后可以重開一張客憑。
2.3綠色通道
2.3.1說明和優先級
說明：當車從站臺發出，到車站大門口的途中，又有乘客上車，為了簡化手續，可以先上車，事后再通過綠色通道將數據錄入。
優先級：中。
2.3.2激勵/響應序列
激勵序列：有經綠色通道上車的乘客。
響應序列：記錄綠色通道數據。
2.3.3功能需求
錄入經綠色通道上車的乘客數據：發車日期，班次，車號，車屬單位，上車點，終點站，人數，價格，金額，錄入人，錄入日期。
2.4開具客憑
2.4.1說明和優先級
說明：檢票或補檢完成后，匯總檢票了的車票記錄，生成并打印出客憑。
優先級：高。
2.4.2激勵/響應序列
激勵序列：選擇要開客憑的班次。
響應序：①生成客憑；
②打印客憑。
2.4.3功能需求
驗證所選班次是否有已檢的票，如果沒有已檢的車票，則給出相應提示；
如果有已檢的票，則轉入下一步操作。
如果已檢的票都開過客憑，則給出相應提示；
如果存在未開過客憑的已檢票，則轉入下一步操作。
在售票記錄中將此班次已檢的車票匯總，生成客憑；
打印客憑。
2.5注銷客憑
2.5.1說明和優先級
說明：如果客憑開錯了或客憑損壞，則可以注銷已開的客憑。
優先級：中。
2.5.2激勵/響應序列
激勵序列：輸入要注銷的客憑號。
響應序列：①注銷客憑；
②清除售票記錄中相關車票的檢票信息。
2.5.3功能需求
根據要輸入的客憑號驗證客憑是否存在，如果不存在，則給出相關提示；
如果客憑存在，則轉入下一步。
如果客憑是無效的，則給出相關的提示；
如果客憑有效，則轉入下一步；
如果客憑已結算，則給出相關的提示；
如果沒有結算，則轉入下一步。
在客憑表中加入注銷信息；
清除售票記錄中的檢票信息
2.6補打客憑
2.6.1說明和優先級
說明：開具客憑時，因打印機故障客憑沒有開出則可以補打客憑。
優先級：低。
2.6.2激勵/響應序列
激勵序列：輸入要補打的客憑號。
響應序列：①打印客憑；
②在客憑表中加入補打信息。
2.6.3功能需求
補打有效的客憑；
記錄補打信息。
2.7客憑一覽
2.7.1說明和優先級
說明：查詢客憑。
優先級：中。
2.7.2激勵/響應序列
激勵序列：輸入日期。
響應序列：查詢出客憑；
2.7.3功能需求
查詢出客憑主體：班次，終點站，客憑號，有效標志，車型，車號，總人數，總金額，結算金額，余額，開單人，開單時間，車屬單位；
查詢出客憑詳細：到站，票價，全票數，半票數，結算價，分成價，分成金額，結算金額；
查詢出客憑客憑所含車票：座位號，起點站，到站，票型，票價，票號，里程；
注銷客憑；
補打客憑。
2.8報表一覽
2.8.1說明和優先級
說明：查詢客憑使用情況。
優先級：中。
2.8.2激勵/響應序列
激勵序列：輸入日期。
響應序列：查詢出客憑；
2.8.3功能需求
查詢出客憑的使用情況：開客憑時間，開客憑人，起始號碼，終止號碼，總份數，空白份數，注銷份數，分成價，結算價，總金額，差價，站場費。
2.9關鍵業務：綠色通道
為了方便旅客上車，提高運行效率，新系統具有綠色通道的功能。綠色通道的處理是先將經綠色通道產生的記錄錄入電腦中，錄入的內容有：班次、車牌、車屬單位、起點站、終點站、人數、票價、總金額、發車日期、制單人、制單日期。
綠色通道產生的票款繳款后，將繳款人、繳款單號、繳款日期回寫到綠色通道記錄表中。
綠色通道產生的票款結算后，將結算人、結算地點、結算日期回寫到綠色通道記錄表中。
模塊六：財務管理需求
1. 票證管理
1.1功能框圖
1.2功能描述
各級財務部門對營業用的各種票證（特別是有價票證）進行入庫、分發、退庫、銷票、盤存等管理工作。在入庫后，如還未分發，可以取消入庫，其他相關的操作也可以取消。所管理的票證都有連續的編號，且在整個總公司范圍內是連貫的，號碼按使用頻度決定是按年重新編號還是按季度重新編號等。通過批次來區分重新編號過的票證，在各級領用入庫中都需要注明批次。
1.2.1票據類型
票據分為有價票證（如客憑、行包發票、車票等是由稅務核定頒發的需嚴格控制）、一般票證（公司內部印發的票證）；各種票證應標識有無面值。包括：電腦車票、人工車票、人工客憑、電腦行包發票、人工行包發票等。
1.2.2設置票庫
票證采用兩級管理方式，總公司財務部設立“票證總庫”，各車站財務股設立“票證分庫”?？偣矩攧詹扛鶕a計劃安排印票、印票入庫、發放票證到車站“分庫”，車站將票證再發放給售票員售票。
1.2.3票證入庫
票據從印刷廠領回后，由總公司財務部進行入庫處理，對于沒有跟總公司聯網的車站，車站也要將總公司發放的票證進行分庫入庫處理。
1.2.4票證發放
總庫發放票證給分庫，如果分庫已跟總庫聯網，系統同步進行“分庫入庫”，否則分庫必須自己進行“入庫處理”。
分庫發放票證給售票員，如果售票點已跟分庫聯網，系統同步進行“票證請領”，否則售票員要自己進行“票證請領”。
1.2.5票據退回
售票員將未使用票證退回分庫，分庫同時進行“入庫操作”，以便重復使用。
車站分庫將未用票證退回給總庫，總庫同時進行“入庫操作”，以便重用。
1.2.6票據作廢
售票員作廢票證，車站財務審核確認，上報總公司。
車站作廢票證，總公司審核確認。
總公司直接作廢票證。
1.2.7票據盤存
查詢各種票證的使用情況。
清點票證實物情況。
處理帳實不符的問題。
總庫和分庫分別進行，分庫盤存的結果應上報總庫處理。
總庫與分庫進行庫存同步的處理。
1.2.8票據過帳
每個月結束時，將所發生的票證業務進行分類匯總，產生票證明細賬、票證總帳。
1.2.9統計查詢
總庫查詢
分庫查詢
查詢使用情況
查詢票證明細
2. 營收繳款
說明：處理每日的各種營業收入的繳款，及時了解營收、已繳、未繳款的情況。
2.1 繳款
2.1.1 客票繳款
2.2.2 綠色通道繳款
錄入繳款記錄，并打印相應的綠色通道客憑供結算用。其數據要參與計算。
2.3.3 包車繳款
2.4.4 行包繳款
2.5.5 其他繳款（停車費、退票費、站場費、雜項收入等）。
聯網票點營收
票點營收繳到所屬站，相當于一個售票員，如何扣除勞務費給售票點，歸站內部處理。
聯網站售其他站的聯網票也是同社會票處理。這些聯網票要計入所屬站的營收中參與與車隊的結算，事后再同售票站進行勞務費結算，而不實際收款。
繳款確認：售票員繳款，車站財務要確認。車站繳款，后總公司要確認。
在確認之前，可以取消繳款。
2.2營收、繳款查詢
查詢售票員每日售票情況；
查詢以前售今天的售票金額；
查詢今天的售票金額；
查詢銷票金額、張數；
查詢廢票張數；
查詢退票金額、張數。
查詢當日營收應繳情況。要分清退票費、售票款、銷票張數。
查詢未繳、已繳情況?？偣疽樵兛偟臓I收匯總數據（分別按售票員、車站、業務種類進行）。
3.結算管理
說明：所有的營收都統一繳到總公司，由總公司進行結算的處理，計算出各車站、車隊應得的收入，然后再將收入劃撥到各車站、車隊。與外司的結算，由車站根據客憑和合同規則來進行分成。需要考慮結算費率、合同、分成比例等因素，存在總公司和車站兩級結算。
3.1 結算基礎資料
結算方式（外司協議結算、本司結算、按實結算、結算一半、現金結算、互不結算），由總公司管理。
班次的結算方式，由各車站負責。
車型的結算比率，由總公司財務部負責。
經營單位的結算方式，由總公司財務部負責。
車輛的結算方式，由各車站負責。
線路各車型結算價硬調、外司結算班次結算價硬調、本司結算班次不同于線路結算價硬調，由各車站負責。
3.2 外司客憑錄入
因為本系統沒有與外司客運系統聯網，外司的客憑必須手工錄入本系統，作為與外司結算的依據。
3.3 結算處理
結算分為本司結算和外司結算。
1、數據收集：
車站、總公司財務部檢索檢票產生的車輛實際營運信息并選擇要進行結算分成處理的部分（以一定時間范圍、經營單位為條件）。
取得相應的結算方式和結算價格等信息。
2、結算處理：
對選擇的每一筆根據相應的結算方式和結算價、分成價等形成結算數據。
3、結算分配：
選擇需要分成、分配的結算數據（按時間、經營單位、車輛進行）。
錄入車站、車隊、車主等相對應的結算價、分成價的分成比例。
進行分成處理。
可以取消操作，但前提是不能實際發生計算。
4、結算、分配實際發生跟蹤：
總公司：公司內部結算依據電腦數據，而客憑只作為有問題時核對單據。不需要直接針對實際客憑進行審核，而只是在站隊層次對結算與分成進行跟蹤。而外司的客憑已在結算時進行了核對，在這里只是記錄有否與外司進行實際結算。
4.財務報表
財務報表分兩級：車站、車隊財務報表和總公司財務報表?？偣矩攧詹恳樵儬I收報表和匯總客憑，車站、車隊要查詢結算分成前后的營收、客憑和應得收入。
4.1售票日營收統計表
4.2售票日營收匯總表
4.3 營收情況分析表
4.4車站分車屬單位匯總客憑
4.5車屬單位分車站匯總客憑
4.6車屬單位分車號匯總客憑
4.7 異地上車客憑報表
4.8車站客憑日報表
4.9客運運費分配明細表
4.10行包車憑日報
4.11行包托運日報
4.12 行包進出庫日報
模塊七：系統管理需求
總公司對各站進行權限管理，模塊信息的授權與維護、操作日志等。
1功能框圖
2關鍵業務：分級權限管理
1、系統用戶通過被授予的角色進入系統；
2、每個角色被賦予適當的權限，如：角色“售票員”被賦予：1）售票；2）補票；3）留票；4）銷票等多項權限；
3、設置每個角色能存取的數據的范圍：如：設置南站售票員能存取的機構為：南站；
4、當南站售票員進入系統時，他只能看到與1）售票；2）補票；3）留票；4）銷票等相關功能菜單，同時他只能存取南站范圍的數據；
5、總公司能夠有效地進行角色授權，限制不同的用戶的權限，從而達到集中控制、分級權限管理的目的。
序號 | 項目名稱 | 規格型號及技術參數 |
1 | 外形尺寸 | 不低于1400mm×120mm×1050mm(L×W×H) |
2 | 通道寬度 | 650mm～ 950mm |
3 | 檢測技術 | 邏輯紅外檢測，防尾隨距離80mm |
4 | 使用壽命 | >5,000,000次 |
5 | 通行頻率 | 20～60人/分鐘 |
6 | 功率 | 200W |
7 | 工作環境溫度 | -20℃～+60℃ |
8 | 存儲環境溫度 | -30℃～+70℃ |
9 | 工作環境濕度 | ＜90% |
10 | 機器外殼 | SUS304 油磨拉絲不銹鋼機箱，厚度1.5mm |
11 | 擺閘機芯 | 1)模式：編碼器 2)助力驅動：電機驅動 3)安全摸式：斷電自動開閘 4)解鎖方式：離合制動 5)轉動方向：單/雙向（出廠設置），入口檢票、出口計數 6)復位方式：自動復位 7)防尾隨：全程防尾隨 8)防夾：電流+位置雙檢測，靈敏度可調，紅外防夾。 |
12 | 閘機與主機通訊方式 | RS232串口通訊，支持Modbus協議 |
13 | 直流電機 | 帶2400線位置反饋無刷電機 |
14 | 指示方式 | 跑馬燈式箭頭指示 |
15 | 工業級光電傳感器 | 6對 |
16 | 主機 | 1）操作系統：安卓7.1 |
17 | LCD/信息顯示屏 | 1)8寸IPS全視角LCD顯示屏 2)分辨率：800*1280 |
18 | 身份證閱讀器 | 1） 符合GA450-2013臺式居民身份證閱讀器通用技術要求，兼容ISO14443（TypeB）標準； 2） 讀卡響應時間：<1s 3） 閱讀距離：0-30mm 4） 工作頻率：13.56MHZ 5） 蜂鳴器：有 |
19 | 人臉識別專用攝像頭 | 1） 分辨率：200W 2） 類型：雙目寬動態攝像頭 3） 光圈：F2.4 4） 聚焦距離：50-150cm 5） 白平衡：自動 6） 補光燈：LED 和紅外雙補光燈 |
20 | 二維碼閱讀器 | 1) 識別碼制： QR Code, Micro QR ，Code 128, EAN-13, EAN-8, Code 39, UPC-A, UPC-E, Codabar, Interleaved 2 of 5, ITF-6, ITF-14, ISBN, ISSN, Code 93, UCC/EAN128, GS1 Databar, Matrix 2 of 5, Code 11, Industrial 2 of 5, Standard 2 of 5, AIM128, Plessey, MSI-Plessey 2)掃描傳感器：640*480 CMOS 傳感器 3)照明：白色LED 4)提示方式：蜂鳴器 5)接口：支持USB和RS232 |
請有意者對該項目進行報價（含對兩個部分分別進行報價）。報價要求：1.提供營業執照；2.報價截止時間：2021年10月13日下午5時止；3.報價材料需加蓋公章，密封后郵寄或送至福建省寧德市東僑經濟技術開發區金馬北路19號寧德客運樞紐站綜合樓二層寧德汽運集團技術信息部，聯系人：王文靖，電話：05936560099，15059346800。
福建省寧德市汽車運輸集團有限公司
二0二一年十月八日
閩公網安備 35098102351050號