本發(fā)明涉及物流領域,具體而言,涉及物流支付方法及系統(tǒng)。
背景技術:
傳統(tǒng)的物流支付方式中,通常是用戶填寫發(fā)貨地、寄件人、收貨地和收件人信息等后,按照物流公司的收費標準直接計算物流費用,這樣,在物流公司的服務行為尚未發(fā)生的情況下,用戶不得不提前支付物流費用。這種先付款后服務的方式無疑排除了物流公司的服務質(zhì)量因素,即無論物流公司服務質(zhì)量,如發(fā)貨速度、物流時間或物品質(zhì)量保護效果等如何,物流公司收到的均為按照預定規(guī)則計算好的物流費用。這樣一定程度上造成的物流公司對服務質(zhì)量的懈怠,缺乏對物流公司的激勵機制。
技術實現(xiàn)要素:
本發(fā)明正是基于上述問題,提出了物流支付方法及系統(tǒng),可以根據(jù)物流服務質(zhì)量計算物流費用。
有鑒于此,本發(fā)明的一方面提出了一種物流支付方法,包括:
響應用戶的寄件請求,獲取用戶輸入的物流信息;
根據(jù)存儲的物流信息與物流費用的對應關系,生成及顯示參考物流費用信息;
響應用戶的支付請求,獲取及根據(jù)服務器記錄的該物品的物流信息調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
進一步地,所述“響應用戶的寄件請求,獲取用戶輸入的物流信息”包括:
響應用戶的寄件請求,獲取用戶的身份信息;
根據(jù)所述身份信息,檢測該用戶是否足額繳納押金;
當用戶足額交納押金時,獲取用戶輸入的物流信息,生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司;
當用戶沒有足額繳納押金時,生成及顯示押金繳納提示信息。
進一步地,所述物流支付方法還包括:
在預設時間內(nèi)檢測用戶是否支付所述最終物流費用;
當用戶在預設時間內(nèi)沒有支付最終物流費用時,支付所述押金給物流公司;
當用戶在預設時間內(nèi)已支付最終物流費用時,支付所述最終物流費用給物流公司。
進一步地,所述物流信息包括物品的目的地信息,所述物流支付方法還包括:
獲取服務器端的物流跟蹤信息,根據(jù)所述物流跟蹤信息,判斷物品是否送達用戶輸入的目的地;
當判斷結果為否時,接收及顯示來自服務器端的物流跟蹤信息;
當判斷結果為是時,生成及顯示付款提示信息。
進一步地,所述“響應用戶的支付請求,獲取及根據(jù)服務器記錄的該物品的物流信息調(diào)整所述參考物流費用,生成及顯示最終物流費用信息”包括:
響應用戶的支付請求,接收及根據(jù)來自服務器端的物流跟蹤信息,判斷物流公司的服務質(zhì)量;
根據(jù)所述服務質(zhì)量調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
本發(fā)明另一方面提供了一種物流支付系統(tǒng),包括:獲取模塊、參考模塊和支付模塊。獲取模塊,用于響應用戶的寄件請求,獲取用戶輸入的物流信息。參考模塊,用于根據(jù)存儲的物流信息與物流費用的對應關系,生成及顯示參考物流費用信息。支付模塊,用于響應用戶的支付請求,獲取及根據(jù)服務器記錄的該物品的物流信息調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
進一步地,所述獲取模塊包括獲取單元、押金檢測單元、訂單單元和押金提示單元。獲取單元,用于響應用戶的寄件請求,獲取用戶的身份信息。押金檢測單元,用于根據(jù)所述身份信息,檢測該用戶是否足額繳納押金。訂單單元,用于當用戶足額交納押金時,獲取用戶輸入的物流信息,生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司。押金提示單元,用于當用戶沒有足額繳納押金時,生成及顯示押金繳納提示信息。
進一步地,所述支付模塊包括費用檢測單元和支付單元。費用檢測單元,用于在預設時間內(nèi)檢測用戶是否支付所述最終物流費用。支付單元,當用戶在預設時間內(nèi)沒有支付最終物流費用時,支付所述押金給物流公司,或當用戶在預設時間內(nèi)已支付最終物流費用時,支付所述最終物流費用給物流公司。
進一步地,所述物流信息包括物品的目的地信息,還包括跟蹤模塊,所述跟蹤模塊包括判斷單元、跟蹤單元和付款提示單元。所述判斷單元,用于獲取服務器端的物流跟蹤信息,根據(jù)所述物流跟蹤信息,判斷物品是否送達用戶輸入的目的地。所述跟蹤單元,用于當判斷結果為否時,接收及顯示來自服務器端的物流跟蹤信息。所述付款提示單元,用于當判斷結果為是時,生成及顯示付款提示信息。
進一步地,所述支付模塊包括質(zhì)量判斷單元和調(diào)整單元。質(zhì)量判斷單元,用于響應用戶的支付請求,接收及根據(jù)來自服務器端的物流跟蹤信息,判斷物流公司的服務質(zhì)量。調(diào)整單元,用于根據(jù)所述服務質(zhì)量調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
本發(fā)明實施例提供的物流支付方法及系統(tǒng),只有當用戶寄送的物品到達目的地時,用戶才需要支付物流費用;支付行為發(fā)生在物流行為之后,切最終物流費用充分考慮物流公司的服務質(zhì)量,從而物流公司服務質(zhì)量直接影響其收到的物流費用,形成對物流公司形成激勵機制。
為使本發(fā)明的上述目的、特征和優(yōu)點能更明顯易懂,下文特舉較佳實施例,并配合所附附圖,作詳細說明如下。
附圖說明
為了更清楚地說明本發(fā)明實施例的技術方案,下面將對實施例中所需要使用的附圖作簡單地介紹,應當理解,以下附圖僅示出了本發(fā)明的某些實施例,因此不應被看作是對范圍的限定,對于本領域普通技術人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)這些附圖獲得其他相關的附圖。圖1示出了本發(fā)明實施例提供的物流支付方法的第一流程示意圖;
圖2示出了本發(fā)明實施例提供的物流支付方法的第二流程示意圖;
圖3示出了本發(fā)明實施例提供的物流支付系統(tǒng)的結構示意圖。
主要元件符號說明:
100-物流支付系統(tǒng);10-獲取模塊;11-獲取單元;12-押金檢測單元;13-訂單單元;14-押金提示單元;20-參考模塊;30-支付模塊;31-質(zhì)量判斷單元;32-調(diào)整單元;33-費用檢測單元;34-支付單元;40-跟蹤模塊;41-判斷單元,42-跟蹤單元;43-付款提示單元。
具體實施方式
為了便于理解本發(fā)明,下面將參照相關附圖對物流支付方法及系統(tǒng)進行更清楚、完整地描述。附圖中給出了物流支付方法及系統(tǒng)的優(yōu)選實施例。物流支付方法及系統(tǒng)可以通過許多不同的形式來實現(xiàn),并不限于本文所描述的實施例。因此,以下對在附圖中提供的本發(fā)明的實施例的詳細描述并非旨在限制要求保護的本發(fā)明的范圍,而是僅僅表示本發(fā)明的選定實施例?;诒景l(fā)明的實施例,本領域技術人員在沒有做出創(chuàng)造性勞動的前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
實施例1
圖1示出了本發(fā)明實施例提供的一種物流支付方法的流程示意圖。
如圖1所示,本發(fā)明實施例提供了一種物流支付方法,應用于智能終端或物流箱柜等,包括:
步驟S1,響應用戶的寄件請求,獲取用戶輸入的物流信息。
當用戶寄送物品到某地時,用戶在智能終端或物流箱柜輸入要寄送的物品的物流信息。具體地,響應用戶的寄件請求,獲取用戶輸入或選定的物流信息。所述物流信息包括物流始發(fā)地信息、物品信息和附加服務信息等。更具體地,所述物流始發(fā)地信息包括發(fā)貨地信息、目的地信息、寄件人信息和收件人信息;所述物品信息包括物品的名稱、質(zhì)量、體積、易碎/腐等屬性信息;所述附加服務信息包括是否要求上門取貨、送貨上門或貨物包裝等服務信息。
步驟S2,根據(jù)存儲的物流信息與物流費用的對應關系,生成及顯示參考物流費用信息。
需要說明的是,本發(fā)明提供的物流支付方法,只有當用戶寄送的物品到達目的地或收到購買的物品時,用戶才需要支付物流費用和/或購買物品金額。
具體地,存儲的所述“物流信息與物流費用的對應關系”為預設的一種物流費用計算規(guī)則。獲取與用戶輸入的物流信息相匹配的物流費用,生成并顯示參考物流費用信息,供用戶參考,方便用戶大致了解需要的物流費用。與傳統(tǒng)物流支付方式不同的是,此時用戶并不需要支付。
進一步地,響應用戶的寄件請求,根據(jù)用戶輸入的物流信息,生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司。優(yōu)選地,服務器端對物品的位置變化跟蹤,檢測服務器端存儲的物品的物流信息是否更新。當所述物流信息發(fā)生更新時,接收并顯示來自服務器端更新的物流信息,便于用戶及時了解物品的物流狀態(tài)。當物品運輸至用戶輸入的目的地時,生成及顯示付款提示信息,從而通知用戶物品已經(jīng)送達。所述付款提示信息為用于提示用戶支付物流費用的文本、圖片或語音信息等。
步驟S3,響應用戶的支付請求,獲取及根據(jù)服務器中記錄的該物品的物流信息調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
具體地,響應用戶的支付請求,獲取服務器端記錄的該物品的物流信息。服務器端記錄的物流信息包括物流狀態(tài)信息和物品保護信息。更具體地,所述物流狀態(tài)信息包括多個時間戳及各個時間對應的物品的位置信息和/或物品保護效果信息。換句話說,服務器端記錄有用于判斷物流公司服務質(zhì)量的主要參考因素,如物流運輸?shù)乃俣燃斑\輸物品是否受到損壞等。
進一步地,根據(jù)服務器中記錄的該物品的物流信息,按照預設規(guī)則調(diào)整所述參考物流費用,生成并顯示最終物流費用信息。所述最終物流費用為用戶實際需要支付的物流費用??梢岳斫?,最終物流費用充分考慮物流公司的服務質(zhì)量,從而物流公司服務質(zhì)量直接影響其收到的物流費用,利于對物流公司形成激勵制約機制。
實施例2
圖2示出了本發(fā)明實施例提供的一種物流支付方法的流程示意圖。
如圖2所示,本發(fā)明實施例提供了一種物流支付方法,包括:
步驟S11,響應用戶的寄件請求,獲取用戶的身份信息。
當用戶寄送物品到某地時,首先對用戶的身份信息進行確認。具體地,響應用戶的寄件請求,獲取用戶的身份信息。所述身份信息為可以唯一識別用戶身份的賬號、二維碼或指紋信息等。所述身份信息包括用戶的姓名、聯(lián)系方式、地址或押金繳納信息等。
步驟S12,根據(jù)所述身份信息,檢測該用戶是否足額繳納押金。
需要說明的是,本發(fā)明提供的物流支付方法,只有當用戶寄送的物品到達目的地或收到購買的物品時,用戶才需要支付物流費用和/或購買物品金額。正因為用戶的支付行為發(fā)生在物流行為之后,為了避免用戶延期支付或拒絕支付等情況,用戶在發(fā)起寄件請求時,應該繳納指定金額的押金。具體地,根據(jù)存儲的用戶的押金繳納信息判斷用戶是否已經(jīng)足額繳納押金。
步驟S13,當用戶沒有足額繳納押金時,生成及顯示押金繳納提示信息。
具體地,當用戶沒有足額繳納押金時,表示該用戶為首次使用該物流支付方法的新用戶,或用戶已經(jīng)發(fā)生過至少一次延期支付或拒絕支付行為而被減扣所述押金抵作物流費用。
進一步地,生成及顯示押金繳納提示信息,從而提示用戶及時繳納押金。執(zhí)行步驟S12,即重新檢測用戶是否足額繳納押金,如此重復,以保證用戶繳納押金后才能進行寄件。
步驟S14,當用戶足額交納押金時,獲取用戶輸入的物流信息,生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司。
具體地,當用戶足額交納押金時,獲取用戶輸入或選定的物流信息。所述物流信息包括物流始發(fā)地信息、物品信息和附加服務信息等。更具體地,所述物流始發(fā)地信息包括發(fā)貨地信息、目的地信息、寄件人信息和收件人信息;所述物品信息包括物品的名稱、質(zhì)量、體積、易碎/腐等屬性信息;所述附加服務信息包括是否要求上門取貨、送貨上門或貨物包裝等服務信息。
進一步地,根據(jù)用戶輸入的物流信息生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司,從而通知物流公司進行攬件、運輸?shù)任锪餍袨椤?/p>
步驟S15,獲取服務器端的物流跟蹤信息,根據(jù)所述物流跟蹤信息,判斷物品是否送達用戶輸入的目的地。
具體地,服務器端對物品的位置變化跟蹤,檢測服務器端存儲的物品的物流信息是否更新。當所述物流信息發(fā)生更新時,接收并顯示來自服務器端的物流跟蹤信息。所述物流跟蹤信息包括多個時間戳及各個時間對應的物品的位置信息和/或物品保護效果信息。進一步地,根據(jù)服務器端記錄的物品的位置信息和用戶輸入的目的地信息是否一致,從而判斷物品是否送達用戶輸入的目的地。
步驟S16,當判斷結果為否時,接收及顯示來自服務器端的物流跟蹤信息。
具體地,當服務器端記錄的物品的位置信息和用戶輸入的目的地信息一致時,表示物品仍在運輸途中。接收及顯示來自服務器端的物流跟蹤信息,便于用戶及時了解物品的物流狀態(tài)。
步驟S17,當判斷結果為是時,生成及顯示付款提示信息。
具體地,當服務器端記錄的物品的位置信息和用戶輸入的目的地信息一致時,表示物品已經(jīng)送達,物流行為結束。生成及顯示付款提示信息,從而通知用戶物品已經(jīng)送達。所述付款提示信息為用于提示用戶支付物流費用的文本、圖片或語音信息等。
步驟S18,響應用戶的支付請求,接收及根據(jù)來自服務器端的物流跟蹤信息,判斷物流公司的服務質(zhì)量。
具體地,響應用戶的支付請求,接收來自服務器端的物流跟蹤信息,判斷物流公司的服務質(zhì)量。所述物流跟蹤信息包括用于判斷物流公司服務質(zhì)量的主要參考因素,如物流運輸?shù)乃俣燃斑\輸物品是否收到損壞等。
步驟S19,根據(jù)所述服務質(zhì)量調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
具體地,根據(jù)物流公司的服務質(zhì)量,按照預設規(guī)則調(diào)整所述參考物流費用,生成并顯示最終物流費用信息。所述最終物流費用為用戶實際需要支付的物流費用??梢岳斫?,最終物流費用充分考慮物流公司的服務質(zhì)量,從而物流公司服務質(zhì)量直接影響其收到的物流費用,利于對物流公司形成激勵制約機制。
步驟S20,在預設時間內(nèi)檢測用戶是否支付所述最終物流費用。
具體地,所述預設時間為自顯示最終物流費用信息開始的一段時間,如,1天。所述預設時間可以根據(jù)實際需求自由設置。
步驟S21,當用戶在預設時間內(nèi)沒有支付最終物流費用時,支付所述押金給物流公司。
具體地,當用戶在預設時間內(nèi)沒有支付最終物流費用時,從用戶提前支付的押金中支付相應金額給物流公司。
步驟S22,當用戶在預設時間內(nèi)已支付最終物流費用時,支付所述最終物流費用給物流公司。
實施例3
圖3示出了本發(fā)明實施例提供的一種物流支付系統(tǒng)的結構示意圖。
如圖3所示,本發(fā)明實施例提供了一種物流支付系統(tǒng)100,包括獲取模塊10、參考模塊20和支付模塊30。
獲取模塊10用于響應用戶的寄件請求,獲取用戶輸入的物流信息。本實施例中,獲取模塊10包括獲取單元11、押金檢測單元12、訂單單元13和押金提示單元14。
獲取單元11用于響應用戶的寄件請求,獲取用戶的身份信息。
押金檢測單元12用于根據(jù)所述身份信息,檢測該用戶是否足額繳納押金。
訂單單元13用于當用戶足額交納押金時,獲取用戶輸入的物流信息,生成物流訂單,發(fā)送所述物流訂單至用戶選定的物流公司。
押金提示單元14用于當用戶沒有足額繳納押金時,生成及顯示押金繳納提示信息。
參考模塊20用于根據(jù)存儲的物流信息與物流費用的對應關系,生成及顯示參考物流費用信息。
另一實施例中,本發(fā)明實施例提供的物流支付系統(tǒng)100還包括跟蹤模塊40。跟蹤模塊40包括判斷單元41、跟蹤單元42和付款提示單元43。
判斷單元41用于獲取服務器端的物流跟蹤信息,根據(jù)所述物流跟蹤信息,判斷物品是否送達用戶輸入的目的地。
跟蹤單元42用于當判斷結果為否時,接收及顯示來自服務器端的物流跟蹤信息。
付款提示單元43用于當判斷結果為是時,生成及顯示付款提示信息。
支付模塊30用于響應用戶的支付請求,獲取及根據(jù)服務器記錄的該物品的物流信息調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。本實施例中,支付模塊30包括質(zhì)量判斷單元31、調(diào)整單元32、費用檢測單元33和支付單元34。
質(zhì)量判斷單元31用于響應用戶的支付請求,接收及根據(jù)來自服務器端的物流跟蹤信息,判斷物流公司的服務質(zhì)量。
調(diào)整單元32用于根據(jù)所述服務質(zhì)量調(diào)整所述參考物流費用,生成及顯示最終物流費用信息。
費用檢測單元33用于在預設時間內(nèi)檢測用戶是否支付所述最終物流費用。
支付單元34用于當用戶在預設時間內(nèi)沒有支付最終物流費用時,支付所述押金給物流公司,或當用戶在預設時間內(nèi)已支付最終物流費用時,支付所述最終物流費用給物流公司。
本發(fā)明實施例提供的物流支付方法及系統(tǒng),只有當用戶寄送的物品到達目的地時,用戶才需要支付物流費用;支付行為發(fā)生在物流行為之后,切最終物流費用充分考慮物流公司的服務質(zhì)量,從而物流公司服務質(zhì)量直接影響其收到的物流費用,形成對物流公司形成激勵機制。
本發(fā)明實施例所提供的系統(tǒng),其實現(xiàn)原理及產(chǎn)生的技術效果和前述方法實施例相同,為簡要描述,系統(tǒng)實施例部分未提及之處,可參考前述方法實施例中相應內(nèi)容。
在這里示出和描述的所有示例中,任何具體值應被解釋為僅僅是示例性的,而不是為限制,因此,示例性實施例的其他示例可以具有不同的值。應注意到:相似的標號和字母在下面的附圖中表示類似項,因此,一旦某一項在一個附圖中被定義,則在隨后的附圖中不需要對其進行進一步定義和解釋。
在本申請所提供的幾個實施例中,應該理解到,所揭露的物流支付方法及智能倉庫可以通過其它的方式實現(xiàn)。以上所描述的物流支付方法及智能倉庫實施例僅僅是示意性的,例如,所述單元的劃分,僅僅為一種邏輯功能劃分,實際實現(xiàn)時可以有另外的劃分方式,又例如,多個單元或組件可以結合或者可以集成到另一個系統(tǒng),或一些特征可以忽略,或不執(zhí)行。另一點,所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些通信接口,裝置或單元的間接耦合或通信連接,可以是電性,機械或其它的形式。
所述為分離部件說明的單元可以是或者也可以不是物理上分開的,為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個地方,或者也可以分布到多個網(wǎng)絡單元上??梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。
另外,在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中,也可以是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個單元中。
以上所述,僅為本發(fā)明的具體實施方式,但本發(fā)明的保護范圍并不局限于此,任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內(nèi),可輕易想到變化或替換,都應涵蓋在本發(fā)明的保護范圍之內(nèi)。因此,本發(fā)明的保護范圍應所述以權利要求的保護范圍為準。