基于JavaEE的汽車售后服務管理系統(tǒng)的設計與實現(xiàn)

喬凡

（山西農(nóng)業(yè)大學 山西省晉中市 030600）

1 引言

隨著我國社會工業(yè)化水平的提升，汽車行業(yè)的規(guī)模也逐日擴大，人們對物質生活的追求，使汽車的社會擁有量基本實現(xiàn)家庭普及化，隨即帶來了汽車維護、修理耗時長，用戶滿意度下降、相關資源浪費等一系列問題，順應“互聯(lián)網(wǎng)+”技術在各行各業(yè)的廣泛應用，將互聯(lián)網(wǎng)技術與汽車服務售后聯(lián)系起來，通過搭建一個平臺，方便用戶與汽車維護中心交互，用戶訂單處理和配件交互，提高人工售后的效率，解決汽車售后保養(yǎng)消耗時間的難題。

2 系統(tǒng)需求分析

2.1 系統(tǒng)功能需求分析

汽車售后服務管理系統(tǒng)針對特定的對象實現(xiàn)其相應的功能：

（1）普通用戶：用戶注冊、登錄、預約、評論、修改基本信息、上傳資料（車身照片，車況文件等）。

（2）維護中心管理：管理員登錄、用戶管理、配件管理、信息管理、權限管理、基礎數(shù)據(jù)、系統(tǒng)維護。

（3）維修員：維修員注冊、登錄、配件管理、任務管理、修改基本信息、車輛派件剩余量預警發(fā)送。

（4）發(fā)票報銷管理：報銷申請單管理。

2.2 汽車售后服務管理系統(tǒng)性能

（1）可靠性：在預定的時間周期內，能夠充分自主的完成項目模塊功能。

（2）安全性：在登錄時通過身份驗證，來賦予相應的權限。

（3）可用性：系統(tǒng)可不間斷、連續(xù)、穩(wěn)定的運行。

（4）易用性：本系統(tǒng)直觀易懂，使用非常方便，普通用戶、維修員及管理員可以直接上手。

（5）可擴充性：系統(tǒng)在開發(fā)過程中采用的是接口的思想，設計過程中可通過新增接口的方式添加功能。

（6）可維護性：本系統(tǒng)通過程序的容錯性、系統(tǒng)性能的維護、用戶輸入不合法數(shù)據(jù)時的處理三方面來提高可維護性。

3 系統(tǒng)概要設計

3.1 設計概述

本系統(tǒng)主要由普通用戶模塊、維護中心管理模塊、維修員模塊、發(fā)票報銷管理模塊四大部分構成。在普通用戶模塊：用戶注冊登錄后，可在預約表單區(qū)填寫預約表單進行預約處理，隨時查看申請單審批狀態(tài)及結果等；在維護中心管理模塊：管理員登錄后，通過扇形統(tǒng)計圖直觀了解維修員工的工作量，并根據(jù)預約表單的內容對其做出指配處理（需根據(jù)維修員狀態(tài)進行指派），在指派維修員的同時可以更新處理過程中所需要的配件信息，管理員在此模塊進行用戶預約申請單、維修員發(fā)票報銷申請單及配件申請單的審批；在維修員模塊：維修員登錄后，可以查看管理員給自己分派的任務，并根據(jù)任務聯(lián)系用戶，了解相應的需求，進行必要配件的增加、刪除，在對訂單處理過程中選擇自己所需要的派件進行下單報備處理。在發(fā)票報銷模塊：維修員填寫發(fā)票報銷申請單申請報銷，并可隨時查看申請單的審批狀態(tài)及結果。

3.2 數(shù)據(jù)庫設計

表1

如表1所示。

4 系統(tǒng)詳細設計

4.1 普通用戶

本模塊主要是普通用戶進行預約處理。用戶進入登錄注冊界面，基于安全考慮，如果未注冊則需要先進行注冊否則無法實現(xiàn)登錄，注冊后自動跳轉至登錄頁面。用戶登錄成功后，進入普通用戶預約表界面，用戶需要填寫自己的基礎信息：電話、故障描述、故障地點并上傳車身照片、車況文件等，預約申請單提交后，用戶狀態(tài)自動更改為待處理，預約單狀態(tài)是非實時回顯，用戶可通過查看預約單審批狀態(tài)來查看預約單流轉程度。

4.2 維護中心管理

本模塊主要包括用戶管理，配件管理，信息管理，權限管理，基礎數(shù)據(jù)，系統(tǒng)維護等。在用戶管理欄，管理員對用戶評論進行查看和回復，可查看用戶的預約申請單，并對預約單進行審批處理，審批結果非實時回顯給用戶，在配件管理欄，管理員可為公司增加新型配件，刪除老舊配件，同時可實時查看配件的具體情況，如果配件數(shù)量小于一定范圍時，系統(tǒng)將自動發(fā)出“及時補存配件”的提示警告。在權限管理欄，可以增加和刪除管理權限低于自己的管理員。為保證系統(tǒng)安全性，新增管理員時需要為其附上具體的信息，包含登錄名、登錄密碼、電話、所屬管理組及所屬權限，并且必須啟用，否則為偽信息，刪除管理員時需根據(jù)實際情況進行刪除操作。在權限管理欄，可更改維修員權限及管理員權限低于自己的管理員權限。維修員權限分為在線和出勤兩種狀態(tài)，維修員在線時可以為其賦予新的任務，出勤狀態(tài)則無法為其賦予新任務。管理員權限有凍結和解凍兩種狀態(tài)，修改管理員權限需通過工作流的方式流轉到最高管理者方可更改成功，當管理員處于解凍狀態(tài)時，管理員可以進行登錄，并實施具體任務，當處于凍結狀態(tài)時，管理員無法進行登錄和執(zhí)行具體操作，在基礎數(shù)據(jù)欄，管理員通過用戶預約申請表為用戶選擇在線維修員，在處理明細處可查看用戶訂單處理細則，處理后的訂單可以選擇刪除或者保留。在系統(tǒng)維護欄管理員可自行修改密碼。修改密碼后需重新登錄。

4.3 維修員

本模塊主要為維修員查看接收任務等操作。維修員登錄進去會優(yōu)先顯示管理員交互過來的用戶預約申請名單，維修員將根據(jù)任務做出具體的操作。處理操作的同時在配件申請區(qū)根據(jù)用戶需求選擇相應的配件，并及時更新配件庫存信息，點擊提交按鈕，維修員的狀態(tài)會非實時回顯至維修中心管理，如果在配貨時，配件出現(xiàn)“配件xxx型號xxx數(shù)量不足，當前數(shù)量為xx!”預警信息，維修員將在配件申請單中備注提醒管理員及時處理。

4.4 發(fā)票報銷管理

本模塊主要為維修員報銷處理。維修員在報銷時填寫發(fā)票報銷單，并采用前后端校驗，驗證通過后提交等待管理員審批。

5 系統(tǒng)實現(xiàn)

汽車售后服務管理系統(tǒng)是基于JavaEE的web開發(fā)項目，系統(tǒng)中項目管理工具采用Maven倉庫，前端使用框架Vue和Bootstrap,MulLine及ECharts 組件實現(xiàn)圖形化處理，Vue是一套用于構建用戶界面的漸進式框架，內部封裝主要是基于js，Bootstrap將頁面中的樣式進行便捷的樣式處理，MulLine將頁面中的表格數(shù)據(jù)進行展現(xiàn)和處理，這些框架使系統(tǒng)使用更快捷流暢。后端采用SSM框架實現(xiàn)，SSM框架由Spring+SpringMVC+MyBatic組成，Spring是一個輕量級的控制反轉（IoC）和面向切面（AOP）的容器框架；SpringMVC分離了控制器、模型對象、分派器以及處理程序對象的角色，更容易對各個對象進行定制；MyBatis是一個支持常用SQL查詢，存儲過程和高級映射的優(yōu)秀持久層框架；在系統(tǒng)實現(xiàn)中，JSP頁面發(fā)送請求給Controller層，Controller層調用Service層接口，Service層接口處理具體的業(yè)務邏輯，將數(shù)據(jù)進行合理的校驗，校驗通過后，Service層會向DAO層發(fā)送請求，DAO層將封裝好的數(shù)據(jù)存儲在數(shù)據(jù)庫中，存儲成功后將返回信息展現(xiàn)給用戶。系統(tǒng)中的工作流采用的是開源的Activiti，在維護中心管理模塊，管理員對用戶預約申請單、維修員發(fā)票報銷申請單、維修員配件申請單等都是通過Activiti內部流轉方式進行審批后，將審批結果非實時回顯至各大模塊中，使相關人員可隨時查看到審批狀態(tài)。

下述為系統(tǒng)模塊部分實現(xiàn)：

5.1 普通用戶模塊

此模塊主要實現(xiàn)用戶預約，考慮到用戶在遇到汽車發(fā)生問題時需要便捷快速處理，在頁面設計時采用了單點登錄技術，使得用戶可快速創(chuàng)建賬戶和密碼并綁定用戶基本信息，預約申請單填寫按鈕以高亮顯示的方式標注，使用戶能夠快速找到并進行填寫，在填寫預約單時支持用戶拍照、視頻文件上傳及獲取具體地理位置等，服務方式（到店服務、上門服務）設置為必填項，維修完成后用戶可對此次服務進行評價及回訪單填寫。

5.2 維護中心管理模塊

此模塊主要實現(xiàn)管理員的一些審批操作，包括管理員審批預約申請單、倉庫信息維護、管理員審批配件申請單、管理員審批發(fā)票申請單等。管理員在審批用戶預約申請單時，通過ECharts 組件實現(xiàn)扇形顯示維修員工作詳情、以數(shù)據(jù)渲染成列表形式來顯示維修員基本情況來篩選無工作任務的維修員，并進行指派。審批狀態(tài)非實時回顯至用戶預約申請單中，同時維修員接收到任務并進行相應處理。在倉庫信息維護中，實現(xiàn)配件入庫、配件出庫及庫存量預警，配件入庫時對庫存信息進行新增操作，出庫時對庫存數(shù)量進行修改操作，當所需商品數(shù)量大于庫存數(shù)量時或庫存數(shù)量小于等于0時，拋出異常，并在管理員登錄時高亮顯示預警信息。管理員審批維修員配件申請單時，可查看處理所涉及的配件詳情及預計時間等信息，審批通過后，維修員會以短信方式收到指派同意指令。用戶在查看預約單的審批狀態(tài)也會是相應的狀態(tài)（審批中或配發(fā)中）。管理員查看維修員發(fā)票申請單列表，可查看到報銷人、報銷事項、報銷憑證等發(fā)票基本信息，點擊審批即可查看發(fā)票號碼、發(fā)票代碼，發(fā)票金額等詳細信息，點擊審批通過后流轉至下一審批人直至審批結束。管理員可通過查看用戶評價及回執(zhí)單對維修員進行評優(yōu)及績效考核處理。一個任務完成，管理員會歸檔用戶車況詳情，并在今后店鋪活動日以短信方式向用戶推送活動。

5.3 維修員模塊

此模塊主要實現(xiàn)維修員接收任務。維修員在接收到維護中心管理發(fā)送的用戶預約申請單后，可查看用戶上傳的資料信息及管理員委派任務時間，隨后將配件的型號，單價，數(shù)量等基本信息與用戶進行溝通，征得同意后提交配件申請單并接收任務。

5.4 發(fā)票報銷模塊

此模塊主要實現(xiàn)維修員發(fā)票報銷。維修員在進行報銷的時候填寫發(fā)票報銷申請單（發(fā)票號碼、發(fā)票代碼及金額等基本信息），后端通過調用國家稅務系統(tǒng)API進行驗真操作，前端通過發(fā)票代碼進行簡單校驗，校驗發(fā)票代碼是否非法，校驗成功后提交，提交后維修員可隨時查看發(fā)票申請單狀態(tài)，若狀態(tài)為提交狀態(tài)，可進行撤銷處理，若狀態(tài)為審批中則不能夠進行撤銷處理，撤銷后的申請單管理員無法查看審批，提交成功的申請單管理員可以查看其具體內容并進行審批通過和回退操作，回退的申請單需要注明回退理由，回退的申請單維修員可進行修改并重新提交。

6 系統(tǒng)測試

軟件測試的目的是查漏補缺，打破原有格局查找錯誤，避免上線后出現(xiàn)的損失，軟件測試的內容包括軟件項目編碼測試、前段頁面測試、軟件系統(tǒng)功能模塊測試、服務器測試以及瀏覽器測試，具體內容就是對項目中的增加、刪除、修改、查找以及數(shù)據(jù)庫的數(shù)據(jù)進行驗證和確認，包括項目在運行環(huán)境中的亂碼，在瀏覽器中的兼容性的測試，保證項目在真正提交時沒有問題，保證需求的合理完整的運行。

7 結論

汽車售后服務管理系統(tǒng)使得線下服務逐漸線上化，提高了對維修員與用戶的管理，為4S店等提供了一個平臺，提高汽車售后服務的效率及質量，在一定程度上使得服務售后信息化與數(shù)字化，滿足開發(fā)此系統(tǒng)的初衷。