本申請涉及電子技術領域，尤其涉及一種派單處理方法及系統(tǒng)。

背景技術：

當前，網絡約車已經逐漸普及，用戶可以通過客戶端生成訂單，系統(tǒng)將根據客戶端發(fā)送來的訂單來為客戶端分配對應的司機端，這里的司機端就是駕駛車輛的司機。司機端根據系統(tǒng)發(fā)送來的可以確定客戶端所在位置，從而行駛到客戶端所處位置為客戶端提供服務。

但是，目前在線司機端中，存在大量司機端收到派單信息，但不接單的情況，可能司機在出車狀態(tài)，并無接單意愿，或者是一些司機端為待機司機端，這里的待機司機端為可以收到派單，但是該待機司機端并不會接單，這樣到就導致了較多無效派單的產生，特別影響系統(tǒng)的派單效率，使得真正有接單意愿的司機端無法接派到訂單。減少了成單率，也降低了用戶體驗。

技術實現要素：

本發(fā)明實施例提供了一種派單處理方法及系統(tǒng)，用以解決現有技術無效派單的產生，影響系統(tǒng)的派單效率，并且較少成單率的問題。

其具體的技術方案如下：

一種派單處理方法，所述方法包括：

服務器檢測在指定時長內司機端是否聽單總數是否超過預設閾值，其中，所述聽單總數為司機端接收到訂單并未接單的總數；

若是，則檢測所述指定時長內是否存在所述司機端的接單信息；

若不存在，則將所述司機端置為收車狀態(tài)；

若存在，則維持所述司機端的狀態(tài)。

可選的，在檢測在指定時長內司機端是否聽單總數是否超過預設閾值之前，所述方法還包括：

接收用戶輸入的時長以及數值；

將所述時長作為所述指定時長，并將所述數值作為所述預設閾值。

可選的，檢測在指定時長內司機端是否聽單總數是否超過預設閾值，包括：

在司機端存在第一個聽單開啟計時，獲取在計時點到指定時長內的所有聽單總數，其中，所述聽單總數包含所述第一個聽單；

檢測所述聽單總數是否超過所述預設閾值。

可選的，在將所述司機端置為收車狀態(tài)之后，所述方法還包括：

生成用于提示所述司機端進入收車狀態(tài)提示信息；

將所述提示信息下發(fā)至所述司機端。

可選的，在將所述司機端置為收車狀態(tài)之后，所述方法還包括：

檢測是否接收到司機端上報的出車請求；

若是，則驗證所述司機端；

若所述司機端驗證通過，則將所述司機端置為出車狀態(tài)。

一種派單處理系統(tǒng)，包括：

檢測模塊，用于檢測在指定時長內司機端是否聽單總數是否超過預設閾值，其中，所述聽單總數為司機端接收到訂單并未接單的總數；

處理模塊，用于在所述聽單總數超過預設閾值時，檢測所述指定時長內是否存在所述司機端的接單信息；若不存在，則將所述司機端置為收車狀態(tài)；若存在，則維持所述司機端的狀態(tài)。

可選的，所述系統(tǒng)還包括：

接收模塊，用于接收用戶輸入的時長以及數值；

閾值處理模塊，用于將所述時長作為所述指定時長，并將所述數值作為所述預設閾值。

可選的，所述處理模塊，還用于在司機端存在第一個聽單開啟計時，獲取在計時點到指定時長內的所有聽單總數；檢測所述聽單總數是否超過所述預設閾值。

可選的，所述處理模塊，生成用于提示所述司機端進入收車狀態(tài)提示信息；將所述提示信息下發(fā)至所述司機端。

可選的，所述處理模塊，還用于檢測是否接收到司機端上報的出車請求；若是，則驗證所述司機端；若所述司機端驗證通過，則將所述司機端置為出車狀態(tài)。

在本發(fā)明技術方案中，系統(tǒng)會檢測在指定時長內司機端是否聽單總數是否超過預設閾值，若是，則檢測指定時長內是否存在司機端的接單信息；若不存在，則將司機端置為收車狀態(tài)；若存在，則維持司機端的狀態(tài)。也就是說，若是司機端長時間聽單，并且未接單，則系統(tǒng)判定該司機端為無效司機端，并將該司機端從平臺下線，從而避免了無線訂單的派發(fā)，提高了派單效率，提升了成單效率，提升了平臺的用戶體驗。

附圖說明

圖1為本發(fā)明實施例中一種派單處理方法的流程圖；

圖2為本發(fā)明實施例中一種派單處理系統(tǒng)的結構示意圖。

具體實施方式

下面通過附圖以及具體實施例對本發(fā)明技術方案做詳細的說明，應當理解，本發(fā)明實施例以及實施例中的具體技術特征只是對本發(fā)明技術方案的說明，而不是限定，在不沖突的情況下，本發(fā)明實施例以及實施例中的具體技術特征可以相互組合。

為了解決現有技術中無效派單的產生，影響系統(tǒng)的派單效率，并且較少成單率的問題，本發(fā)明實施例中提供了一種派單處理方法，如圖1所示為本發(fā)明實施例中一種派單處理方法的流程圖，該方法包括：

S101，服務器檢測在指定時長內司機端是否聽單總數是否超過預設閾值；

在本發(fā)明實施例中，系統(tǒng)設置了一個指定時長，以及一個聽單總數，這里的聽單總數為司機端接收到訂單并未接單的總數。

也就是說，司機端可能一直在線，而系統(tǒng)會自動的給司機端給司機端派單，司機端會不停的接收到訂單。

在本發(fā)明實施例中，為了減少無效派單的產生，所以在司機端存在第一個聽單開啟計時，并獲取在計時點到指定時長內的該的所有聽單總數，比如說，司機端在14:00開始第一個聽單，系統(tǒng)內設置的指定時長為2小時，此時系統(tǒng)將連續(xù)的獲取到達16:00的所有聽單。

這里需要說明是，該指定時長以及預設閾值可以根據需求來進行調整，也就是說，接收用戶輸入的時長以及數值，并將輸入的時長作為指定時長，將輸入的數值作為預設閾值。比如說，管理人員可以將指定時長設置為2小時，或者是3小時；可以將預設閾值設置為100單，或者150單等等。這樣可以實時的對閾值進行設定，提升系統(tǒng)的實用性以及判定的準確性。

在系統(tǒng)檢測司機端的聽到數時，系統(tǒng)會實時的檢測指定時長內司機端的聽單總數是否超過預設閾值。

若是司機端的聽單總數未超過預設閾值，則繼續(xù)檢測司機端的聽單，若是司機端的聽單總數超過了預設閾值，則執(zhí)行S102。

S102，檢測指定時長內是否存在司機端的接單信息；

在獲取到司機端的聽到總數之后，系統(tǒng)將檢在該指定時長內是否存在司機端的接單信息，也就是說，檢測在聽單的過程中，司機端是否接單。若是在指定時長內存在司機端的接單信息，則執(zhí)行S103；若是在指定時長內不存在司機端的接單信息，則執(zhí)行S104。

S103，將司機端置為收車狀態(tài)；

S104，維持司機端的狀態(tài)。

簡單來講，若是司機端長時間聽單，并且未接單，則系統(tǒng)判定該司機端為無效司機端，并將該司機端從平臺下線，從而避免了無線訂單的派發(fā)，提高了派單效率，提升了成單效率，提升了平臺的用戶體驗。

進一步，在本發(fā)明實施例中，在將司機端下線之后，系統(tǒng)將生成用戶提示司機端進入收車狀態(tài)的提示信息，并將該提示信息下發(fā)至司機端。也就是說，系統(tǒng)在將無效司機端下線之后，系統(tǒng)將生成一個提示信息來提示司機端對應用戶該司機端已經下線，這樣該司機端對應用戶能夠及時的獲知到運行狀態(tài)。

進一步，在本發(fā)明實施例中，在該司機端被下線之后，系統(tǒng)將檢測是否接收到司機端上報的出車請求，也就是說，司機端對應司機通過在司機端上手動操作生成出車請求之后，系統(tǒng)將接收到司機端上報的出車請求，然后系統(tǒng)將基于該出車請求將司機端的狀態(tài)調整為出車狀態(tài)，這樣系統(tǒng)可以根據司機端的請求及時調整司機端狀態(tài)。

綜上實施例，若是司機端長時間聽單，并且未接單，則系統(tǒng)判定該司機端為無效司機端，并將該司機端從平臺下線，從而避免了無線訂單的派發(fā)，提高了派單效率，提升了成單效率，提升了平臺的用戶體驗。

對應本發(fā)明實施例中一種派單處理方法，本發(fā)明實施例中還提供了一種派單處理系統(tǒng)，如圖2所示為本發(fā)明實施例中一種派單處理系統(tǒng)的結構示意圖，該系統(tǒng)包括：

檢測模塊201，用于檢測在指定時長內司機端是否聽單總數是否超過預設閾值，其中，所述聽單總數為司機端接收到訂單并未接單的總數；

處理模塊202，用于在所述聽單總數超過預設閾值時，檢測所述指定時長內是否存在所述司機端的接單信息；若不存在，則將所述司機端置為收車狀態(tài)；若存在，則維持所述司機端的狀態(tài)。

進一步，在本發(fā)明實施例中，該系統(tǒng)還包括：

接收模塊，用于接收用戶輸入的時長以及數值；

閾值處理模塊，用于將所述時長作為所述指定時長，并將所述數值作為所述預設閾值。

進一步，在本發(fā)明實施例中，所述處理模塊202，還用于在司機端存在第一個聽單開啟計時，獲取在計時點到指定時長內的所有聽單總數；檢測所述聽單總數是否超過所述預設閾值。

進一步，在本發(fā)明實施例中，所述處理模塊202，生成用于提示所述司機端進入收車狀態(tài)提示信息；將所述提示信息下發(fā)至所述司機端。

進一步，在本發(fā)明實施例中，所述處理模塊202，還用于檢測是否接收到司機端上報的出車請求；若是，則驗證所述司機端；若所述司機端驗證通過，則將所述司機端置為出車狀態(tài)。

盡管已描述了本申請的優(yōu)選實施例，但本領域內的普通技術人員一旦得知了基本創(chuàng)造性概念，則可對這些實施例作出另外的變更和修改。所以，所附權利要求意欲解釋為包括優(yōu)選實施例以及落入本申請范圍的所有變更和修改。

顯然，本領域的技術人員可以對本申請進行各種改動和變型而不脫離本申請的精神和范圍。這樣，倘若本申請的這些修改和變型屬于本申請權利要求及其等同技術的范圍之內，則本申請也意圖包含這些改動和變型在內。