本發(fā)明涉及數(shù)據(jù)處理領(lǐng)域,具體而言,涉及一種訂單資金處理方法和裝置。
背景技術(shù):
危險品物流運輸?shù)馁M用結(jié)算過程中,承運人企業(yè)在跟托運人(大型化工生產(chǎn)企業(yè))結(jié)算運輸費用時,一般都會有1到3個月不等的賬期,導(dǎo)致運輸企業(yè)運輸應(yīng)收賬款不及時,而在運輸過程中的燃油費、過路費、維修費等都是現(xiàn)金支出,不僅給承運人企業(yè)帶來資金壓力,而且嚴(yán)重制約承運人企業(yè)的發(fā)展,es云平臺提供危險品物流訂單進(jìn)行保理功能,為承運人企業(yè)解決應(yīng)收賬款的煩惱,解決資金壓力。
在危險品物流行業(yè)中即沒有專門針對訂單保理功能的平臺,也沒有任何的金融機構(gòu)能有類似的服務(wù)方式為承運人企業(yè)解決運輸結(jié)算的問題。
技術(shù)實現(xiàn)要素:
本發(fā)明提供一種訂單資金處理方法和裝置,旨在改善上述問題。
第一方面,本發(fā)明提供的一種訂單資金處理方法,所述方法包括:接收承運方通過承運終端上傳的保理申請材料。其中,所述保理申請材料包括所述承運方與托運方簽訂的承運危險品的承運合同和該承運合同所需承運資金的承運金額。接收所述承運終端返回的承運完成指示,將所述保理申請材料發(fā)送至保理終端。將所接收的所述保理終端在審核所述保理申請材料合格后返回的對應(yīng)所述承運金額的保理資金,發(fā)送至所述承運終端。在接收到所述托運方通過托運終端發(fā)送的對應(yīng)所述保理資金的償還資金時,將所述償還資金發(fā)送至所述保理終端。
第二方面,本發(fā)明提供的一種訂單資金處理裝置,所述裝置包括:申請材料接收模塊,用于接收承運方通過承運終端上傳的保理申請材料,其中,所述保理申請材料包括所述承運方與托運方簽訂的承運危險品的承運合同和該承運合同所需承運資金的承運金額。完成指示接收模塊,用于接收所述承運終端返回的承運完成指示。申請材料發(fā)送模塊,用于將所述保理申請材料發(fā)送至保理終端。保理資金發(fā)送模塊,用于將所接收的所述保理終端在審核所述保理申請材料合格后返回的對應(yīng)所述承運金額的保理資金,發(fā)送至所述承運終端。償還資金發(fā)送模塊,用于在接收到所述托運方通過托運終端發(fā)送的對應(yīng)所述保理資金的償還資金時,將所述償還資金發(fā)送至所述保理終端。
本發(fā)明實施例提供的訂單資金處理方法,應(yīng)用于本發(fā)明提供的訂單資金處理裝置。所述訂單資金處理裝置與托運目標(biāo)危險品的托運方所在的托運終端、承運目標(biāo)危險品的承運方所在的承運終端、以及提供承運資金保理服務(wù)的保理機構(gòu)所在的保理終端均連接。承運終端通過上傳保理申請材料申請承運資金的保理,并將所述承運合同作為質(zhì)押物上傳至訂單資金處理裝置,交由保理終端審核。保理終端審核通過后,將對應(yīng)承運合同內(nèi)的承運資金金額的保理資金發(fā)送給承運方,并在托運終端償還托運資金后,將相應(yīng)的資金償還給保理機構(gòu)。與承運終端、托運終端以及保理終端均連接,在承運作業(yè)完成后托運資金尚未償還時,由所述保理機構(gòu)提供相應(yīng)的保理資金,將相應(yīng)的償還資金償還給提供保理資金的保理終端,減少了承運方因承運作業(yè)結(jié)束后初期不能收回承運資金影響承運方正常運營進(jìn)而導(dǎo)致危險品承運率較低的問題,且設(shè)置保理終端的保理申請審核模式,多方監(jiān)控,提高了訂單資金處理的安全性和可靠性。
附圖說明
為了更清楚地說明本發(fā)明實施例的技術(shù)方案,下面將對實施例中所需要使用的附圖作簡單地介紹,應(yīng)當(dāng)理解,以下附圖僅示出了本發(fā)明的某些實施例,因此不應(yīng)被看作是對范圍的限定,對于本領(lǐng)域普通技術(shù)人員來講,在不付出創(chuàng)造性勞動的前提下,還可以根據(jù)這些附圖獲得其他相關(guān)的附圖。
圖1是本發(fā)明實施例提供的訂單資金處理方法和裝置所應(yīng)用的服務(wù)器與多終端之間交互的交互示意圖;
圖2是本發(fā)明實施例提供的訂單資金處理方法和裝置所應(yīng)用的服務(wù)器的方框圖;
圖3是本發(fā)明第一實施例提供的訂單資金處理方法的步驟流程圖;
圖4是本發(fā)明第一實施例提供的訂單資金處理方法的步驟s303的子步驟流程圖;
圖5是本發(fā)明第二實施例提供的訂單資金處理裝置的功能模塊圖圖。
具體實施方式
本領(lǐng)域技術(shù)人員長期以來一直在尋求一種改善該問題的工具或方法。
鑒于此,本發(fā)明的設(shè)計者通過長期的探索和嘗試,以及多次的實驗和努力,不斷的改革創(chuàng)新,得出本方案所示的較佳的訂單資金處理方法和裝置。
為使本發(fā)明實施例的目的、技術(shù)方案和優(yōu)點更加清楚,下面將結(jié)合本發(fā)明實施例中的附圖,對本發(fā)明實施例中的技術(shù)方案進(jìn)行清楚、完整地描述,顯然,所描述的實施例是本發(fā)明一部分實施例,而不是全部的實施例?;诒景l(fā)明中的實施例,本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。因此,以下對在附圖中提供的本發(fā)明的實施例的詳細(xì)描述并非旨在限制要求保護的本發(fā)明的范圍,而是僅僅表示本發(fā)明的選定實施例?;诒景l(fā)明中的實施例,本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例,都屬于本發(fā)明保護的范圍。
如圖1所示,是本發(fā)明實施例提供的訂單資金處理方法和裝置所應(yīng)用的服務(wù)器200與承運方所在的承運終端101、托運方所在的托運終端102與保理機構(gòu)所在的保理終端103進(jìn)行交互的交互示意圖。所述服務(wù)器200通過網(wǎng)絡(luò)與一個或多個承運終端101、托運終端102和保理終端103進(jìn)行通信連接,以進(jìn)行數(shù)據(jù)通信或交互。所述服務(wù)器200可以是網(wǎng)絡(luò)服務(wù)器、數(shù)據(jù)庫服務(wù)器等,也可以是網(wǎng)絡(luò)服務(wù)器、數(shù)據(jù)庫服務(wù)器等集成式服務(wù)器系統(tǒng)。所述承運終端101、托運終端102和保理終端103等各個終端設(shè)備均可以是個人電腦(personalcomputer,pc)、平板電腦、智能手機、個人數(shù)字助理(personaldigitalassistant,pda)等。
如圖2所示,是本實施例提供的訂單資金處理方法和裝置所應(yīng)用的服務(wù)器200的方框示意圖。所述服務(wù)器200包括訂單資金處理裝置201、存儲器202、存儲控制器203、處理器204、外設(shè)接口205、輸入輸出單元206、顯示單元207。
所述存儲器202、存儲控制器203、處理器204、外設(shè)接口205、輸入輸出單元206、顯示單元207,各元件相互之間直接或間接地電性連接,以實現(xiàn)數(shù)據(jù)的傳輸或交互。例如,這些元件相互之間可通過一條或多條通訊總線或信號線實現(xiàn)電性連接。所述訂單資金處理裝置201包括至少一個可以軟件或固件(firmware)的形式存儲于所述存儲器中或固化在所述服務(wù)器200的操作系統(tǒng)(operatingsystem,os)中的軟件功能模塊。所述處理器204用于執(zhí)行存儲器202中存儲的可執(zhí)行模塊,例如所述訂單資金處理裝置201包括的軟件功能模塊或計算機程序。
其中,存儲器202可以是,但不限于,隨機存取存儲器(randomaccessmemory,ram),只讀存儲器(readonlymemory,rom),可編程只讀存儲器(programmableread-onlymemory,prom),可擦除只讀存儲器(erasableprogrammableread-onlymemory,eprom),電可擦除只讀存儲器(electricerasableprogrammableread-onlymemory,eeprom)等。其中,存儲器202用于存儲程序,所述處理器204在接收到執(zhí)行指令后,執(zhí)行所述程序,前述本發(fā)明實施例任一實施例揭示的過程定義的服務(wù)器201所執(zhí)行的方法可以應(yīng)用于處理器204中,或者由處理器204實現(xiàn)。
處理器204可能是一種集成電路芯片,具有信號的處理能力。上述的處理器可以是通用處理器,包括中央處理器(centralprocessingunit,簡稱cpu)、網(wǎng)絡(luò)處理器(networkprocessor,簡稱np)等;還可以是數(shù)字信號處理器(dsp)、專用集成電路(asic)、現(xiàn)成可編程門陣列(fpga)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件??梢詫崿F(xiàn)或者執(zhí)行本發(fā)明實施例中的公開的各方法、步驟及邏輯框圖。通用處理器204可以是微處理器或者該處理器也可以是任何常規(guī)的處理器等。
所述外設(shè)接口205將各種輸入輸出單元206耦合至處理器204以及存儲器202。在一些實施例中,外設(shè)接口,處理器以及存儲控制器可以在單個芯片中實現(xiàn)。在其他一些實例中,他們可以分別由獨立的芯片實現(xiàn)。
輸入輸出單元206用于提供給用戶輸入數(shù)據(jù)實現(xiàn)用戶與數(shù)據(jù)采集終端的交互。所述輸入輸出單元可以是,但不限于,鼠標(biāo)和鍵盤等。
顯示單元207在所述服務(wù)器與用戶之間提供一個交互界面,例如用戶操作界面,或用于顯示圖像數(shù)據(jù)給用戶參考。在本實施例中,所述顯示單元可以是液晶顯示器或觸控顯示器。若為觸控顯示器,其可為支持單點和多點觸控操作的電容式觸控屏或電阻式觸控屏等。支持單點和多點觸控操作是指觸控顯示器能感應(yīng)到來自該觸控顯示器上一個或多個位置處同時產(chǎn)生的觸控操作,并將該感應(yīng)到的觸控操作交由處理器進(jìn)行計算和處理。
請參見圖3,為本發(fā)明第一實施例提供的訂單資金處理方法的步驟流程圖,應(yīng)用于上述的訂單資金處理裝置。下面將結(jié)合圖3,對本發(fā)明實施例提供的訂單資金處理方法的具體實施過程進(jìn)行詳細(xì)解釋。
步驟s301,接收承運方通過承運終端上傳的保理申請材料。
本發(fā)明實施例設(shè)計的訂單資金處理方法,主要涉及訂單資金的申請方即承運方、訂單資金的相關(guān)處理操作的執(zhí)行方即本實施例的訂單資金處理裝置、訂單資金的審核者和提供者即保理機構(gòu)、所述訂單資金的實際償還者即托運方等,所述承運方通過承運終端、所述保理機構(gòu)通過保理終端以及所述托運方通過托運終端,均可通過本實施例的訂單資金處理裝置進(jìn)行交互。
托運方在需要進(jìn)行針對目標(biāo)危險品的托運行為時,需要同所需要的目標(biāo)危險品的承運方簽訂承運合同。托運方在簽訂托運合同委托承運方執(zhí)行承運操作時暫時不能支付承運方承運所述目標(biāo)危險品所需要的承運資金,然而所述承運方在執(zhí)行承運操作時需要較多資金才能執(zhí)行完承運操作,因此所述承運方需要通過所述訂單資金處理裝置向可以提前提供周轉(zhuǎn)資金的保理機構(gòu)申請資金保理。所述承運方將其與所述目標(biāo)危險品的托運方簽訂的承運合同作為申請預(yù)支資金的質(zhì)押物,將包含所述承運合同的保理申請材料上傳至所述訂單資金處理裝置。所述保理申請材料還可以包括對應(yīng)所述承運合同中所需承運資金的承運金額的相關(guān)指示信息。以使所述訂單資金處理裝置以及所述保理機構(gòu)可以明了其所需要申請的保理資金的金額。
在一種實施方式中,所述保理申請材料所包含的對應(yīng)所述承運合同的保理金額不一定要完全等于所述承運合同中所記錄的承運所述交易金額,承運方可以根據(jù)其當(dāng)前的資金能力選擇申請保理金額等于全部或者部分的承運所需的交易金額。申請保理金額的發(fā)送方式以及申請保理金額的數(shù)值與承運合同內(nèi)記錄的交易金額的相對數(shù)值關(guān)系,可以根據(jù)實際需要設(shè)置,在此不做限定。
步驟s302,接收所述承運終端返回的承運完成指示。
所述承運方通過所述承運終端上傳包含承運合同的保理申請材料,以申請承運資金保理后,進(jìn)行承運完成后的保理資金接收操作。所述承運方在完成所述目標(biāo)危險品的承運操作后,發(fā)送承運完成指示至所述訂單資金處理裝置,告知所述訂單資金處理裝置,該承運訂單所對應(yīng)的承運操作均已完成,可以進(jìn)行后續(xù)的放款操作。
步驟s303,將所述保理申請材料發(fā)送至保理終端。
所述訂單資金處理裝置在接收到所述承運終端發(fā)送的承運完成指示后,將所述承運終端上傳的保理申請材料發(fā)送至保理終端,以啟動承運后的承運資金保理環(huán)節(jié)。所述訂單資金處理裝置將所述承運終端上傳的保理申請材料,發(fā)送至所述保理終端,以使所述保理終端的保理機構(gòu)接收所述保理申請材料,并根據(jù)所述保理申請材料審核所述承運方的申請資格。
在一種實施方式中,所述訂單資金處理裝置在接收所述承運終端上傳的保理申請材料后,可以對所接收的保理申請材料進(jìn)行申請資格初審。所述訂單資金處理裝置可以通過所述承運終端或者托運終端以往的信用記錄設(shè)置相應(yīng)的信用等級,不同的信用等級可以申請的保理金額范圍不同。與所述訂單資金處理裝置所對接的保理終端的保理資質(zhì)也可以進(jìn)行設(shè)置,設(shè)置不同保理終端的保理資質(zhì)不同,提供的保理資金的金額也不同。
所述訂單資金處理裝置對所述保理申請資格的初審操作可以包括:判斷所述承運終端是否具有保理資金申請資格,所述承運終端的保理申請資格與所述保理申請材料的申請資金金額是否匹配,所述保理申請材料是否齊全,以及所述保理申請材料與所申請的保理終端是否匹配等。
在一種實施方式中,所述保理申請材料可以包括承運終端選擇的目標(biāo)保理機構(gòu),所述訂單資金處理裝置在初審所述保理申請材料合格后,可以將所述保理申請材料發(fā)送至所述承運終端選擇的目標(biāo)保理機構(gòu)所在的保理終端,由所述保理終端對所述保理申請材料進(jìn)行審核。
在其他實施方式中,所述保理申請材料也可以不包括承運終端選擇的目標(biāo)保理機構(gòu),所述訂單資金處理裝置在初審所述融資申請材料合格后,可以根據(jù)保理申請材料的申請類型和申請金額,匹配與所述申請類型和申請金額對應(yīng)的至少一個可選保理終端。所述訂單資金處理裝置可以將所述保理申請材料不發(fā)送至所述至少一個可選保理終端,由多個保理終端進(jìn)行保理申請資格審核。在接收到部分保理終端分虧的保理申請資格審核通過的指示信息后,可以將反饋指示信息的保理終端作為目標(biāo)保理終端進(jìn)行保理申請,也可以將目標(biāo)保理終端發(fā)送至承運終端,由承運終端從多個目標(biāo)保理終端中選擇一個目標(biāo)保理終端進(jìn)行保理申請。
在其他實施方式中,所述訂單資金處理裝置在接收到保理申請材料后,還可以自動為該保理申請材料匹配對應(yīng)承運終端或者托運終端的資質(zhì)信息,所述承運終端或者所述托運終端的資質(zhì)信息可以包括營業(yè)執(zhí)照、信用記錄等。所述訂單資金處理裝置為所述保理申請材料匹配對應(yīng)終端的資質(zhì)信息后,將匹配后的保理申請材料發(fā)送至所述保理終端,由所述保理終端進(jìn)行保理申請資格的審核操作。
步驟s304,將所接收的所述保理終端在審核所述保理申請材料合格后返回的對應(yīng)所述承運金額的保理資金,發(fā)送至所述承運終端。
依據(jù)上述步驟,所述訂單資金處理裝置將所述保理申請材料發(fā)送至所述保理終端進(jìn)行審核后,由所述保理終端返回申請審核結(jié)果。如果所述保理終端審核所述保理申請材料合格,則會返回對應(yīng)所述承運金額的保理資金。所述訂單資金處理裝置接收到所述保理終端發(fā)送的保理資金后,將所述保理資金發(fā)送給所述承運合同的承運方所在的承運終端,即為完成了訂單資金處理初期的資金供應(yīng)。
在一種實施方式中,所述訂單資金處理裝置在將所述保理申請材料發(fā)送至所述保理終端后,會接收到所述保理終端在審核所述保理申請材料結(jié)束后返回的指示信息。如果所述保理終端審核所述保理申請材料合格,則所述保理終端可以返回申請審核通過的指示信息至所述訂單資金處理裝置。所述訂單資金處理裝置在接收到所述申請審核通過的指示信息后,可以發(fā)送資金接收申請至所述保理終端,以使所述保理終端可以繼續(xù)后續(xù)的資金發(fā)送操作,所述保理終端會將相應(yīng)的保理資金發(fā)送至所述訂單資金處理裝置。
如果所述保理終端審核所述保理申請材料不合格,則所述保理終端可以返回申請審核未通過的指示信息至所述訂單資金處理裝置。所述訂單資金處理裝置將所接收的申請審核未通過的指示信息發(fā)送至所述承運終端,以告知所述貿(mào)易終端此次保理申請未通過所述保理終端的審核。所述訂單資金處理裝置可以直接結(jié)束此次訂單資金處理操作,也可以根據(jù)所述保理終端發(fā)送的審核未通過的指示信息中所提供的未通過原因,進(jìn)行相應(yīng)的分析,提供相應(yīng)的處理結(jié)果至所述承運終端,例如提供其他的保理終端、保理材料整理或者保理分批等,在此不做限定。
在其他實施方式中,所述訂單資金處理裝置也可以提供承運方的承運終端的資金接收方式,由所述保理終端直接按照承運終端的資金接收方式發(fā)送保理資金。
在一種實施方式中,所述保理終端提供的保理資金的金額,可以等于承運合同中的交易資金的金額,也可以等于所述保理申請材料中的申請保理金額??紤]到實際應(yīng)用中,保理機構(gòu)提供保理資金一般會收取一定的保理費用,即提供保理服務(wù)的手續(xù)費。所述保理機構(gòu)可以在提供保理資金時,直接將承運終端發(fā)送的申請保理金額扣除所述保理費用后,作為保理資金提供給承運終端。所述保理機構(gòu)也可以將全額的申請保理金額的保理資金提供給承運終端,由所述承運終端或者托運終端支付或者承運相應(yīng)的保理費用。保理機構(gòu)收取保理費用的方式,在此不做限定。
步驟s305,在接收到所述托運方通過托運終端發(fā)送的對應(yīng)所述保理資金的償還資金時,將所述償還資金發(fā)送至所述保理終端。
所述訂單資金處理裝置在完成初步的保理資金申請和供應(yīng)后,進(jìn)行保理資金的回收償還。承運合同的托運方將對應(yīng)所述申請保理金額的償還資金發(fā)送至保理終端,以償還所述保理終端在先提供的保理資金。
在一種實施方式中,所述償還資金可以僅等于保理資金,所述訂單資金處理裝置可以直接將所述償還資金發(fā)送給保理終端。所述償還自己還可以包括對應(yīng)所述保理資金的償還資金,以及保理終端提供保理資金所需要的保理費用。所述訂單資金處理裝置將所述托運終端發(fā)送的包含所述保理資金和所述保理費用的償還資金發(fā)送至所述保理終端。實際應(yīng)用中,可以根據(jù)用戶需求,進(jìn)行償還資金的合理分配模式,在此不做限定。
在上述實施例的基礎(chǔ)上,所述步驟s303中所述的保理資金的獲取和發(fā)送的具體實施方式過程還可以由其他實施方式。下面將結(jié)合圖4,對上述步驟的可能實施方式進(jìn)行具體解釋。
步驟s401,接收所述保理終端在所述保理申請材料審核合格后返回的允許保理指示。
所述訂單資金處理裝將保理申請材料發(fā)送至保理終端進(jìn)行審核,保理終端在審核所述保理申請材料合格后,發(fā)送允許保理指示至所述訂單資金處理裝置。
步驟s402,將所述承運合同的應(yīng)收賬款債權(quán)轉(zhuǎn)讓給所述保理終端。
所述訂單資金處理裝置在接收到保理終端發(fā)送的允許保理指示后,推斷所述保理終端允許為所述承運終端提供保理資金,并同時將所述承運終端接收托運終端發(fā)送的承運資金的應(yīng)收賬款債權(quán)轉(zhuǎn)讓給所述保理終端,以便所述保理終端可以接收所述托運終端后期補償?shù)馁Y金。
步驟s403,接收所述托運終端發(fā)送的對應(yīng)所述保理資金的償還資金。
所述保理終端在審核所述保理申請材料合格,并且接收到承運合同的應(yīng)收賬款債權(quán)后,提供保理資金,完成承運作業(yè)初期的承運資金的提供。所述托運終端在償還前期的托運資金時,將對應(yīng)所述保理資金的償還資金發(fā)送至所述訂單資金處理裝置。
步驟s404,將所述償還資金發(fā)送至當(dāng)前具有所述承運合同的應(yīng)收賬款債權(quán)的所述保理終端。
所述訂單資金處理裝置在接收到所述托運終端發(fā)送的對應(yīng)保理資金的償還資金時,將所述償還資金發(fā)送給應(yīng)收債權(quán)所有者。在所述保理終端提供給承運終端保理資金時,所述訂單處理裝置將所述承運終端的應(yīng)收賬款債權(quán)轉(zhuǎn)讓給所述保理終端。因此,在所述訂單資金處理裝置接收到當(dāng)前具有所述承運合同的應(yīng)收債權(quán)時,將所述償還資金發(fā)送至所述保理終端,即為完成了此次承運訂單的保理處理操作。
上述本發(fā)明實施例提供的訂單資金處理方法,通過承運終端通過上傳保理申請材料申請承運資金的保理,并將所述承運合同作為質(zhì)押物上傳至訂單資金處理裝置,交由保理終端審核。保理終端審核通過后,將對應(yīng)承運合同內(nèi)的承運資金金額的保理資金發(fā)送給承運方,并在托運終端償還托運資金后,將相應(yīng)的資金償還給保理機構(gòu)。與承運終端、托運終端以及保理終端均連接,在承運作業(yè)完成后托運資金尚未償還時,由所述保理機構(gòu)提供相應(yīng)的保理資金,將相應(yīng)的償還資金償還給提供保理資金的保理終端,減少了承運方因承運作業(yè)結(jié)束后初期不能收回承運資金影響承運方正常運營進(jìn)而導(dǎo)致危險品承運率較低的問題,且設(shè)置保理終端的保理申請審核模式,多方監(jiān)控,提高了訂單資金處理的安全性和可靠性。
請參見圖5,為本發(fā)明第二實施例提供的訂單資金處理裝置500的功能模塊圖。所述訂單資金處理裝置500包括:申請材料接收模塊501、完成指示接收模塊502、申請材料發(fā)送模塊503、保理資金發(fā)送模塊504和償還資金發(fā)送模塊505。
申請材料接收模塊501,用于接收承運方通過承運終端上傳的保理申請材料,其中,所述保理申請材料包括所述承運方與托運方簽訂的承運危險品的承運合同和該承運合同所需承運資金的承運金額;
完成指示接收模塊502,用于接收所述承運終端返回的承運完成指示;
申請材料發(fā)送模塊503,用于將所述保理申請材料發(fā)送至保理終端,以使所述保理終端審核所述保理申請材料是否合格;
保理資金發(fā)送模塊504,用于將所接收的所述保理終端在審核所述保理申請材料合格后返回的對應(yīng)所述承運金額的保理資金,發(fā)送至所述承運終端;
償還資金發(fā)送模塊505,用于在接收到所述托運方通過托運終端發(fā)送的對應(yīng)所述保理資金的償還資金時,將所述償還資金發(fā)送至所述保理終端。
在上述實施例的基礎(chǔ)上,所述保理資金發(fā)送模塊504用于:
接收所述保理終端在所述保理申請材料審核合格后返回的允許保理指示;
將所述承運合同的應(yīng)收賬款債權(quán)轉(zhuǎn)讓給所述保理終端;
接收所述保理終端發(fā)送的對應(yīng)所述保理資金的償還資金;
將所述償還資金發(fā)送至當(dāng)前具有所述承運合同的應(yīng)收賬款債權(quán)的所述保理終端。
在上述實施例的基礎(chǔ)上,所述申請材料發(fā)送模塊503用于:
獲取所述承運方的承運資質(zhì)信息;
將所獲取的所述承運方的所述承運資質(zhì)信息匹配至該承運方上傳的保理申請材料;
將匹配所述承運資質(zhì)信息后的所述保理申請材料發(fā)送至所述保理終端。
在上述實施例的基礎(chǔ)上,所述完成指示接收模塊502還用于:
接收對應(yīng)所述承運合同的收貨終端返回的確認(rèn)收貨指示。
在上述實施例的基礎(chǔ)上,所述保理資金為從所述承運資金中扣除保理費用后的資金,所述償還資金為所述承運資金加上所述保理費用的資金,所述償還資金發(fā)送模塊505用于:
接收所述托運終端發(fā)送的償還資金;
將所述償還資金中的所述承運資金發(fā)送至所述保理終端;
將所述保理費用發(fā)送至所述承運終端。
上述本發(fā)明實施例提供的訂單資金處理裝置,承運終端通過上傳保理申請材料申請承運資金的保理,并將所述承運合同作為質(zhì)押物上傳至訂單資金處理裝置,交由保理終端審核。保理終端審核通過后,將對應(yīng)承運合同內(nèi)的承運資金金額的保理資金發(fā)送給承運方,并在托運終端償還托運資金后,將相應(yīng)的資金償還給保理機構(gòu)。與承運終端、托運終端以及保理終端均連接,在承運作業(yè)完成后托運資金尚未償還時,由所述保理機構(gòu)提供相應(yīng)的保理資金,將相應(yīng)的償還資金償還給提供保理資金的保理終端,減少了承運方因承運作業(yè)結(jié)束后初期不能收回承運資金影響承運方正常運營進(jìn)而導(dǎo)致危險品承運率較低的問題,且設(shè)置保理終端的保理申請審核模式,多方監(jiān)控,提高了訂單資金處理的安全性和可靠性。本實施例訂單資金處理裝置的具體實施過程可參照上述方法實施例,在此不再一一贅述。
以上所述僅為本發(fā)明的優(yōu)選實施例而已,并不用于限制本發(fā)明,對于本領(lǐng)域的技術(shù)人員來說,本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi),所作的任何修改、等同替換、改進(jìn)等,均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。