ETC后臺處理系統(tǒng)方案

1、etc后臺處理系統(tǒng)方案1、系統(tǒng)架構32、系統(tǒng)實現(xiàn)32.1 系統(tǒng)管理子系統(tǒng)32.1.1 方案說明32.1.1.1 權限管理32.1.1.2 配置文件管理32.1.1.3 日志管理42.1.1.4 數(shù)據(jù)庫系統(tǒng)密碼管理42.1.2 數(shù)據(jù)流程62.1.2.1 用戶登陸62.1.2.2 修改密碼72.1.2.3 修改數(shù)據(jù)庫密碼72.1.2.4 屏蔽系統(tǒng)功能72.1.2.5 維護系統(tǒng)日志72.1.2.6 系統(tǒng)參數(shù)設定82.1.2.7 個人操作日志查詢82.2 參數(shù)管理子系統(tǒng)82.2.1 方案說明82.2.2 數(shù)據(jù)流程82.2.2.1 操作員維護82.2.2.2 角色維護92.2.2.3 操作員角色維護92

2、.2.2.4維護角色權限92.2.2.5 維護發(fā)行點（營業(yè)網點）102.2.2.6 客戶信息維護102.2.2.7 業(yè)主信息維護102.2.2.8 客戶銷戶112.2.2.9 客戶預銷戶112.2.2.10 銀行信息維護112.2.2.11 結算中心信息維護122.3 數(shù)據(jù)結算子系統(tǒng)122.3.1 方案說明122.3.1.1 客戶結算132.3.1.2 業(yè)主結算132.3.2 數(shù)據(jù)流程132.3.2.1 上傳流水流程132.3.2.2 客戶結算142.3.2.3 業(yè)主結算152.3.2.4客戶銀行調賬劃撥指令172.3.2.5 業(yè)主銀行調賬劃撥指令182.3.2.6銀行劃撥指令維護182.3.

3、2.7銀行劃撥欠費處理182.3.2.8銀行劃撥繳費后處理192.4 數(shù)據(jù)交換子系統(tǒng)202.5 卡管理子系統(tǒng)202.5.1 方案說明202.5.1.1讀寫器的操作202.5.1.2出入庫的管理212.5.1.3 卡押金的管理212.5.2 數(shù)據(jù)流程222.5.2.1空白卡出入庫222.5.2.2空白卡出庫沖減222.5.2.3空白卡初始化232.5.2.4初始化卡出入庫232.5.2.5初始化卡出入庫沖減232.5.2.6 obu標簽出入庫242.5.2.7 obu標簽出入庫沖減242.5.2.8 記帳卡發(fā)行242.5.2.9 儲值卡發(fā)行252.5.2.10 掛失262.5.2.11 解掛27

4、2.5.2.12 記帳卡換卡282.5.2.13 記帳卡退卡292.5.2.14 儲值卡充值292.5.2.15 儲值卡退卡302.5.2.16 發(fā)行obu標簽312.6 銀行系統(tǒng)子系統(tǒng)323、數(shù)據(jù)庫結構321、系統(tǒng)架構1.1 系統(tǒng)結構etc后臺處理系統(tǒng)采用三層結構處理方式。即客戶端、應用服務器、數(shù)據(jù)庫。為了保證每層能夠保持穩(wěn)定，在每個部分增加相應接口。如圖： 目前，首先考慮使用delphi作為開發(fā)工具。即客戶端、應用服務器使用delphi本身的三層架構的技術。數(shù)據(jù)庫采用sqlserver。增加數(shù)據(jù)操縱層是為了當數(shù)據(jù)庫發(fā)生變化時，僅僅修改數(shù)據(jù)操作層就可以完成，不會將修改擴大化。當采用cics或

5、mq作為中間業(yè)務層實現(xiàn)技術時，客戶端增加通訊層，將相應的字符串改成delphi自身技術支持的相應信息，而用戶界面基本不用修改。不管是在結算中心還是營業(yè)點都是在線工作，沒有本地數(shù)據(jù)庫。1.2 功能結構2、系統(tǒng)實現(xiàn)2.1 系統(tǒng)管理子系統(tǒng)2.1.1 方案說明 2.1.1.1 權限管理 本系統(tǒng)權限管理要管理到菜單級。影響操作員權限的因素有兩個。一個是系統(tǒng)操作員屏蔽的菜單功能；一個是該操作員對應角色所具有的菜單權限。對于一個操作員的角色驗證是：假如某一個操作員有n個角色，r1到rn，每一個角色對子菜單（1001）的權限為ra1到ran，系統(tǒng)對子菜單（1001）的屏蔽為s，則操作員對于子菜單（1001）的

6、權限為（r1+r2.+rn）*s。如果該值大于零則有權限，反之沒有權限。2.1.1.2 配置文件管理本系統(tǒng)的配置文件要加密管理。同時為了方便進行配置文件設定（配置文件設定應該是在可瀏覽的非加密狀態(tài)），需要一個比較復雜的流程，假如應用程序為app，應用程序的非加密配置文件應該為app.ini；應用程序的加密配置文件應該為app.cfg描述如下：2.1.1.3 日志管理 本系統(tǒng)的日志紀錄操作員的操作過程。由于操作員可能發(fā)生變化，而系統(tǒng)顯示的是當時過程以及因為操作日志數(shù)量很大，不做關聯(lián)，違反第三范式設計。增加操作員姓名、應用程序名稱。opcardno，opcardid只有在用刷卡方式進入系統(tǒng)才會有數(shù)

7、。日志內容以文字形式表達。如：刪除操作員；刪除從2003-1-1到2003-1-31日日志等。具體粒度由程序員自己管理。但是，至少進出系統(tǒng)以及所有影響數(shù)據(jù)的信息應該記錄下來。 系統(tǒng)還要有文本日志，用來記錄發(fā)生的不可預料的錯誤！2.1.1.4 數(shù)據(jù)庫系統(tǒng)密碼管理本系統(tǒng)的數(shù)據(jù)庫密碼可以隨時修改。這時，系統(tǒng)登陸時會有一些不同，如下圖：注意：其實數(shù)據(jù)庫用戶名沒有用，真正的用戶叫etcmtc。在修改數(shù)據(jù)庫密碼時（流程圖見修改數(shù)據(jù)庫密碼），可能會出現(xiàn)剛剛修改完數(shù)據(jù)庫密碼卻不能成功修改ubuserforapp時（在sqlserver中不能將兩個東東放在一個事務里），一定要出現(xiàn)明顯提示。這也是系統(tǒng)脆弱的一個方

8、面。2.1.2 數(shù)據(jù)流程2.1.2.1 用戶登陸 2.1.2.2 修改密碼 2.1.2.3 修改數(shù)據(jù)庫密碼2.1.2.4 屏蔽系統(tǒng)功能 系統(tǒng)顯示整個系統(tǒng)（不管是不是本應用程序）的所有功能。采用樹狀（treeview）顯示。并且通過checkbox選擇。默認是全部允許。2.1.2.5 維護系統(tǒng)日志 顯示輸入條件時間段、操作人員、應用程序。顯示排序條件時間、操作人員、應用程序。按照條件過濾按照排序條件顯示日志內容?？梢詣h除相應條件日志，但是刪除操作同樣紀錄日志（先刪除后添加，在一個事務中）。2.1.2.6 系統(tǒng)參數(shù)設定2.1.2.7 個人操作日志查詢 顯示輸入條件時間段、操作人員（只能是該操作員）

9、、應用程序。顯示排序條件時間、操作人員、應用程序。按照條件過濾按照排序條件顯示日志內容?？梢詮木S護系統(tǒng)日志繼承。2.2 參數(shù)管理子系統(tǒng)2.2.1 方案說明 目前，營業(yè)網點通過網絡直接與應用服務器連接才能夠進行操作。所以所有的營業(yè)網點具有的功能可能相同會造成網點之間互相修改對方建立數(shù)據(jù)的可能，因為有日志紀錄，不會造成太多的影響。2.2.2 數(shù)據(jù)流程2.2.2.1 操作員維護說明：刪除操作員必須首先處理完身份卡才可以刪除。要么還原身份卡，要么身份卡掛失（丟失情況）。2.2.2.2 角色維護2.2.2.3 操作員角色維護瀏覽操作員角色時，應該可以對操作員或角色按照操作員號碼、姓名、角色號碼、角色名稱

10、進行相應過濾。按照操作員工號、姓名、角色編碼、角色名稱等進行排序。增加操作員角色時，應該可以對于操作員和角色分別進行多選。在實際增加時，如果該操作員已經具有該角色，不要提示錯誤，可以直接進行。刪除操作員角色時，應該可以對于操作員和角色分別進行多選。在實際刪除時，如果該操作員不具有該角色，不要提示錯誤，可以直接進行。所有增加刪除操作要寫日志。2.2.2.4維護角色權限 通過checkbox選擇相應角色后，右邊的treeview顯示各個應用程序（一層）下各個一級菜單（二層）下的二級菜單（三層）。通過選擇、不選擇上一層菜單可以自動全選、全不選下層的所有菜單。子菜單的選擇，必須保證父菜單也是選中的。2

11、.2.2.5 維護發(fā)行點（營業(yè)網點） 2.2.2.6 客戶信息維護客戶信息刪除在客戶銷戶中處理。所有客戶信息都要保留（假刪除）。2.2.2.7 業(yè)主信息維護業(yè)主信息維護比較簡單。主要是考慮到如果業(yè)主信息錯誤，其實需要修改的東西很多。同樣業(yè)主信息刪除，也很難有正確的判斷條件。如果真出現(xiàn)了業(yè)主不參與本系統(tǒng)，相應的處理要復雜的多，肯定需要人工干預。2.2.2.8 客戶銷戶2.2.2.9 客戶預銷戶不能在這里自動掛失，因為客戶的這些記賬卡應該退卡，涉及到卡押金。不用考慮儲值卡用戶，因為客戶信息并沒有刪除，同樣可以顯示出儲值卡的客戶。2.2.2.10 銀行信息維護刪除、修改銀行信息可能涉及到其他很多業(yè)務

12、，如：已經發(fā)出沒有確認的劃賬指令；業(yè)主銀行信息；客戶銀行信息等等。所以實際上，真正刪除一個銀行是要考慮很多東東的。2.2.2.11 結算中心信息維護刪除、修改結算中心信息可能涉及到其他很多業(yè)務，如：已經發(fā)出沒有確認的劃賬指令等等。所以實際上，真正刪除一個結算中心是要考慮很多東東的。另外，銀行信息必須同時輸入完成。2.3 數(shù)據(jù)結算子系統(tǒng)2.3.1 方案說明結算模型的主要難點。結算必須有兩種結算：客戶結算和業(yè)主結算。由于客戶結算主要是對記賬卡進行結算。必須詳細記錄每次用戶結算銀行劃帳信息與客戶相應消費的關系。儲值卡需要注意的是消費的連續(xù)性。但是，由于記賬卡如果銀行沒有完成劃撥指令，可能影響業(yè)主結算

13、的進行。而業(yè)主結算需要能夠和工班日期相對應。需要將結算日期與工班日期相對應。目前專營公司的結算模型是：每天接收到數(shù)據(jù)后進行客戶結算。設立一個特殊劃撥賬號，里面有保證金，保證即使客戶劃撥沒有完成，也可以保證業(yè)主劃撥的完成。由于有區(qū)域中心保證完整性，所以如果想做到結算日期與工班日期對應，是有可能的。同時還有對自己的劃撥指令（專營公司收益）。目前，本系統(tǒng)處理原則是：結算中心保留三個賬戶：收益帳戶、儲值卡賬戶、記賬卡支出賬戶、記賬卡收入帳戶。所有結算中心的收益劃撥到收益帳戶；所有儲值卡的資金存入儲值卡賬戶，在業(yè)主劃撥指令中，所有儲值卡的劃撥都從該賬戶支出，對于系統(tǒng)而言，該賬戶就是業(yè)主劃撥的儲值卡資金的

14、支出賬戶；記賬卡賬戶目前考慮收支兩條線（如果一條線，將兩個賬戶設成一樣即可）客戶結算客戶資金進入記賬卡收入帳戶，業(yè)主結算資金從記賬卡支出賬戶進入到業(yè)主賬戶。路段很難保證完整性，而且由于主要在省外進行該項目，能否有路段完整性，還是未知。故，不再考慮完整性，即結算日期（客戶、業(yè)主）可以包括多個工班日期，一個工班日期的數(shù)據(jù)可以出現(xiàn)在多個結算日中。具體做法如下：儲值卡數(shù)據(jù)通過觸發(fā)器直接進入storeoutlist。etcsplitresultlist有sn號碼。記賬卡數(shù)據(jù)通過觸發(fā)器進入到tallyoutlist，有sn號碼。etcoutlist上傳后產生sn號碼，該號碼保證先上傳的肯定號碼小。同時，增

15、加兩個表，storeerroutlist，tallyerroutlist。這兩個表主要用來存儲收費流水里的卡號沒有出現(xiàn)在卡動態(tài)表中（錯誤或試驗的卡號）。這里的數(shù)據(jù)不能參與結算。結算暫時不考慮滯納金自動計算的問題。如果出現(xiàn)滯納金，可以通過人工計算輸入調賬指令的辦法解決。2.3.1.1 客戶結算所有上傳的數(shù)據(jù)都進行結算，結算是針對tallyoutlist的產生的。每天可以結算多次，形成多條劃撥指令。沒有結算日期，只有結算時間。如果沒有記賬卡數(shù)據(jù)，客戶結算可以省略。如果發(fā)現(xiàn)錯誤數(shù)據(jù)，需要進行錯誤數(shù)據(jù)處理流程。每天只能結算一次。2.3.1.2 業(yè)主結算業(yè)主結算如果單純依靠etcsplitresultl

16、ist可能會產生以后有些報表沒有辦法產生的情況。但是，如果修改etcsplitresultlist會對目前系統(tǒng)產生很大影響。所以，暫時先以etcsplitresultlist為基礎，考慮到業(yè)主應該不會關心客戶信息。每天只能結算一次。2.3.2 數(shù)據(jù)流程2.3.2.1 上傳流水流程插入黑名單表的表示偽卡。gencau=3。為了防止已經存在該卡信息，應該先刪除后添加黑名單信息。2.3.2.2 客戶結算輸入結束工班日期，主要是可以讓用戶有一個條件限定的機會。其實，工班日期可以輸入的超過今天。注意：客戶結算需要考慮折扣，這也是customacc與customtrans分離的原因之一。customadj

17、usttrans是折扣后的數(shù)據(jù)。錯誤處理流程其實就是人工參與修改數(shù)據(jù)。isskip=0是為了向后兼容，可以自動處理。日志根據(jù)編程需要進行，由程序員決定。2.3.2.3 業(yè)主結算輸入結束工班日期，主要是可以讓用戶有一個條件限定的機會。其實，工班日期可以輸入的超過今天。但是根據(jù)校驗拆分與流水可能不符。注意：業(yè)主結算需要考慮折扣，這也是owneracc與ownertrans分離的原因之一。owneradjusttrans是折扣后的數(shù)據(jù)。同時，還應該考慮服務費的收取。服務費出現(xiàn)分以下數(shù)據(jù)時，四舍五入計算每一個業(yè)主的收入。服務費=每個業(yè)主折扣后應得資金-業(yè)主折扣后應得資金*折扣率*（1-服務費率）。調賬

18、指令是折扣后的數(shù)據(jù)，調賬指令與服務費無關。錯誤處理流程其實就是人工參與修改數(shù)據(jù)。isskip=0是為了向后兼容，可以自動處理。日志根據(jù)編程需要進行，由程序員決定。2.3.2.4客戶銀行調賬劃撥指令由于有日志，所以刪除、修改可以不采用沖減的方式。2.3.2.5 業(yè)主銀行調賬劃撥指令由于有日志，所以刪除、修改可以不采用沖減的方式。2.3.2.6銀行劃撥指令維護 在銀行劃撥指令完成以前（銀行端確認），可以修改除了劃撥號碼以及資金以外的任何信息。甚至，連銀行確認標示也可以修改。主要是為了真的出現(xiàn)銀行端出了問題，但是手工已經將該劃撥完成的情況。2.3.2.7銀行劃撥欠費處理可以輸入相應日期，查詢銀行劃撥

19、指令中沒有劃撥成功的。同時，可以將這些帳戶的所屬客戶的所屬記賬卡掛失。該掛失與丟失掛失可以同時發(fā)生。數(shù)據(jù)流程如下：對于記賬卡黑名單應該先刪除，后添加。2.3.2.8銀行劃撥繳費后處理可以輸入相應日期，查詢銀行劃撥指令中已經劃撥成功的客戶。同時，可以將這些客戶的所屬記賬卡解掛。該解掛不影響丟失掛失的用戶。數(shù)據(jù)流程如下：2.4 數(shù)據(jù)交換子系統(tǒng)2.4.1 方案說明數(shù)據(jù)交換系統(tǒng)分為客戶端與服務端兩個程序。不論參數(shù)下發(fā)還是數(shù)據(jù)上傳采用相同的機制。系統(tǒng)發(fā)送的參數(shù)大致如下：客戶端：源目的表=表名，源臨時表=表名，本地表=表名，一次讀取數(shù)量，成功發(fā)送刪除否（0：不刪除，1：刪除）， 其中一次讀取數(shù)量=0表示一

20、次全讀，大于零表示相應數(shù)量。 對于數(shù)據(jù)同步（以etcoutlist為例），源目的表=，源臨時表=etcoutlist，本地表=etcoutlist，100，1， 對于參數(shù)下發(fā)（以tallycardblacklist），源目的表=tallycardblacklist，源臨時表=tallycardblacklist_tmp，本地表=tallycardblacklist，0，0，傳送方式可以采用delta包的方式。2.4.2 數(shù)據(jù)流程2.5 卡管理子系統(tǒng)2.5.1 方案說明卡管理有一部分涉及硬件的操作，通過本軟件并結合讀寫器以實現(xiàn)卡的初始化及發(fā)行，儲值卡充值等目的，同時它也需要將所做的任何操作反映到

21、后臺的數(shù)據(jù)庫表。至于其它諸如掛失，出入庫管理，其操作結果只在后臺數(shù)據(jù)庫反映。每個功能的操作，可能需要一些后續(xù)工作支持才能真正完成，系統(tǒng)可以建立這樣的一種向導，將原來可以獨立的兩個界面連接起來，并且所需要的后一界面的內容如果可以根據(jù)前一界面得到，系統(tǒng)能夠自動給出，以簡化輸入或選擇操作。2.5.1.1讀寫器的操作本系統(tǒng)要結合讀寫器進行操作，而且在多個用例中出現(xiàn)。因此最好將讀寫器的操作做成一個控件，既可用于復用，還可增加與用戶交互操作的美感。即是這樣的一個控件，能夠模擬顯示讀寫器的操作，如同鼠標的滾動在屏幕上以指針的移動來反映。當激活這個控件，檢測計算機是否與讀寫器相連并且系統(tǒng)能夠識別，如果連接不成

22、功，控件中以圖片顯示兩個設備未連通的狀態(tài)，否則以一個就緒的狀態(tài)圖片表示。當放上卡時，又會立即顯示有卡的圖片，當讀寫器識別不出這張卡時，以壞卡的圖片顯示并發(fā)出一長聲提醒。當正在讀(寫)卡，以正在讀(寫)卡的狀態(tài)圖片顯示，讀(寫)卡成功后也顯示一個成功的狀態(tài)圖片并以聲音提示。而且在這個控件中，提供不同狀態(tài)下的事件以進行其它的動作，比如寫卡時提供一個onwritecard的事件，其它程序員根據(jù)實際操作在寫卡的事件中描述具體的動作，比如是發(fā)行還是充值或是卡還原等。2.5.1.2出入庫的管理因為發(fā)行點和管理中心都是使用同一臺機器上的數(shù)據(jù)庫，所以基本上是物品在位置上的變化，可以知道哪類物品在那個地方有多少

23、，所以有界面上操作比較簡單，實際關鍵在于數(shù)據(jù)庫中的數(shù)據(jù)流動方式上。對于卡的管理，考慮到有可能在印刷的時候可能已經區(qū)分為記賬卡和儲值卡，所以在庫存管理中需要考慮。所以卡的庫存分為記賬卡、儲值卡、未知三類，用以滿足各種情況。庫存的管理目前對于空白卡、初始化卡只是管理到數(shù)量。對于真正的記賬卡、儲值卡通過動態(tài)表的方式管理。對于錯誤的出庫、入庫仍然采用沖減的辦法處理。對于沒有安裝的obu標簽的出入庫目前也僅僅反映到數(shù)量。但是對于已經安裝的obu標簽需要按照編號單獨管理。obu標簽的安裝，目前不需要管理其安裝費等財務信息。2.5.1.3 卡押金的管理卡押金采用動態(tài)管理的辦法。每一張卡在發(fā)行的時候按照參數(shù)表

24、里的卡押金收取費用。退卡時，按照卡動態(tài)表里的卡押金退回卡押金。2.5.2 數(shù)據(jù)流程2.5.2.1空白卡出入庫 如果出庫發(fā)現(xiàn)沒有相應紀錄，同樣表示庫存不足。用戶需要選擇出入庫，卡類型（未知、儲值卡、記賬卡），以及輸入卡數(shù)量。系統(tǒng)自動生成出入庫流水號碼。2.5.2.2空白卡出庫沖減 顯示出入庫信息時，不需要顯示出入庫流水號信息。2.5.2.3空白卡初始化 插入密鑰母卡與密鑰傳輸卡?？瞻卓ǔ跏蓟恍薷膸齑嫘畔ⅲ粚懭胂到y(tǒng)日志。2.5.2.4初始化卡出入庫2.5.2.5初始化卡出入庫沖減2.5.2.6 obu標簽出入庫2.5.2.7 obu標簽出入庫沖減2.5.2.8 記帳卡發(fā)行記帳卡發(fā)行界面要求：發(fā)

25、行界面應該有選項，是否安裝obu標簽。如果安裝，可以立即轉到obu發(fā)行的界面上去，obu發(fā)行時所需要填寫的車型、車種、車牌、卡號、客戶號，系統(tǒng)依據(jù)上一界面的內容自動給出，以減少信息的重復輸入。 從原則上講，從數(shù)據(jù)庫中查找是否存在該卡可以替代不是上一張卡的判斷。比較不符和寫入不成功之所以不直接寫卡還要判斷主要是防止中途換卡。不知道初始化卡能否分清是不是記賬卡，如果能夠分清，還需要增加初始化卡是否是記賬卡的判斷。如果刷的是已經退卡的卡，應該判斷，退卡時間（tallycarddyn.optime）到現(xiàn)在是否經過了一個數(shù)據(jù)完整時間。2.5.2.9 儲值卡發(fā)行儲值卡發(fā)行界面要求：發(fā)行界面應該有選項，是否

26、安裝obu標簽。如果安裝，可以立即轉到obu發(fā)行的界面上去，obu發(fā)行時所需要填寫的車型、車種、車牌、卡號、客戶號，系統(tǒng)依據(jù)上一界面的內容自動給出，以減少信息的重復輸入。儲值卡發(fā)行完成，直接轉到儲值卡充值界面中。 從原則上講，從數(shù)據(jù)庫中查找是否存在該卡可以替代不是上一張卡的判斷。比較不符和寫入不成功之所以不直接寫卡還要判斷主要是防止中途換卡。不知道初始化卡能否分清是不是儲值卡，如果能夠分清，還需要增加初始化卡是否是儲值卡的判斷。如果刷的是已經退卡的卡，應該判斷，退卡時間（storecarddyn.optime）到現(xiàn)在是否經過了一個數(shù)據(jù)完整時間。2.5.2.10 掛失掛失不分卡類型。因為掛失找不

27、到原來的卡。此時只能輸入卡的卡號（或其它信息，應該是一個查詢界面，因為很多人記不住卡號），系統(tǒng)調出此卡的信息。當此卡原屬于正?？ǎ_認掛失時，系統(tǒng)將會為此卡寫一個掛失狀態(tài)的標志，并提示用戶是否需要為此車申請新的卡，如果同意，系統(tǒng)轉到相應卡發(fā)行界面，記賬卡發(fā)行時所需要填寫的車型、車牌、客戶編號，系統(tǒng)依據(jù)上一界面的內容自動給出，無需操作者重復輸入。流程如下：gencau=1。考慮可能黑名單已經存在該信息，可以考慮先刪除后添加。2.5.2.11 解掛解掛不分卡類型，并且必須是好卡。是因為找到了原來的卡，此時或可以通過刷卡來得到卡號，如果該卡對應的車牌已經在掛失時就申請了新的卡（可能新卡類型與舊卡不同）在使用，則系統(tǒng)提示用戶。由用戶選擇解掛繼續(xù)（之所以可以繼續(xù)，是因為在發(fā)卡時并沒有限制一張卡只能一輛車，實際使用也沒有必要限制），還時轉入退卡流程。流程如下：之所以這么復雜，主要是防止因為欠費造成的掛失，通過手工掛失解掛取消掉。2.5.2.12 記帳卡換卡記賬卡換卡，是因為正在使用的記賬卡，讀寫器不能識別了。本系統(tǒng)首先檢查記賬卡是否真正不能讀寫了，只有是壞卡才可以換卡，是好卡，