本申請屬于互聯(lián)網技術領域，尤其涉及一種數據處理方法和裝置。

背景技術：

隨著第三方支付平臺和第三方理財平臺的不斷發(fā)展，現在人們的支付和理財已經不局限在原有的現金支付、刷卡支付、柜臺理財等，而是越來越多的人通過第三方平臺在手機等終端上就可以實現支付和理財等操作。

尤其是通過第三方平臺的理財，近些年得到了廣泛的應用，既然是通過第三方平臺的理財操作，那么勢必需要有第三方平臺與機構之間的交互，這種相互之間的交互，一般是通過文件的方式進行的。這主要是考慮到基于文件的方式具有穩(wěn)定性高、無需考慮并發(fā)問題、解耦等有點，因此在第三方平臺和機構的交互中占據著很大的比重。

然而，現有的基于文件的處理方式僅支持機構一天內僅上傳一次正式的還款文件，一旦該文件出錯，不管是文件格式有錯誤，還是內容校驗沒通過，又或者某條流水處理時候發(fā)生錯誤，都會影響機構當天的正常處理流程，而且在當日沒有任何的補救措施，只能等到第二天才可以再次上傳文件，這樣勢必給流水處理過程帶來不便，也嚴重影響機構和用戶的體驗。

針對上述問題，目前尚未提出有效的解決方案。

技術實現要素：

本申請目的在于提供一種數據處理方法和裝置，可以當日對處理失敗的流水及時進行處理，以便提高機構和用戶的體驗。

本申請?zhí)峁┮环N數據處理方法和裝置是這樣實現的：

一種數據處理方法，所述方法包括：

獲取機構上傳的待處理文件，其中，所述待處理文件中攜帶有一條或多條流水；

根據所述待處理文件的文件類型標識，確定所述待處理文件是否為預定標準文件；

如果是預定標準文件，則對所述一條或多條流水進行處理；

如果是非預定標準文件，則在對所述非預定標準文件審核通過后，再對所述一條或多條流水進行處理；

其中，所述非預定標準文件是在機構獲知預定標準文件處理失敗后當日重新上傳的文件。

一種數據處理裝置，所述裝置包括：

獲取模塊，用于獲取機構上傳的待處理文件，其中，所述待處理文件中攜帶有一條或多條流水；

確定模塊，用于根據所述待處理文件的文件類型標識，確定所述待處理文件是否為預定標準文件；

第一處理模塊，用于在確定是預定標準文件的情況下，對所述一條或多條流水進行處理；

第二處理模塊，用于在確定是非預定標準文件的情況下，在對所述非預定標準文件審核通過后，再對所述一條或多條流水進行處理；

其中，所述非預定標準文件是在機構獲知預定標準文件處理失敗后當日重新上傳的文件。

本申請?zhí)峁┑臄祿幚矸椒ê脱b置，機構在獲知預定標準文件處理失敗后當日可以重新上傳文件，而不是一天內僅可以上傳一次文件，從而使得在對預定標準文件處理失敗的情況下，當天可以及時進行補救，解決了現有技術中文件處理失敗需要等到第二天才可以進行補救而導致的用戶和機構的體驗差的技術問題，達到了有效提高用戶和機構的體驗的目的。

附圖說明

為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請中記載的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據這些附圖獲得其他的附圖。

圖1是本申請?zhí)峁┑臄祿幚矸椒ㄒ环N實施例的方法流程圖；

圖2是本申請?zhí)峁┑臄祿幚矸椒ǖ木唧w方法流程圖；

圖3是本申請?zhí)峁┑奈募ｒ灧椒ǖ氖疽鈭D；

圖4是本申請?zhí)峁┑臄祿幚硌b置一種實施例的模型結構示意圖。

具體實施方式

為了使本技術領域的人員更好地理解本申請中的技術方案，下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├绢I域普通技術人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應當屬于本申請保護的范圍。

下面結合附圖對本申請所述的數據處理方法和裝置進行詳細的說明。圖1是本申請?zhí)岢龅臄祿幚矸椒ǖ囊环N實施例的方法流程圖。雖然本申請?zhí)峁┝巳缦率鰧嵤├蚋綀D所示的方法操作步驟或裝置結構，但基于常規(guī)或者無需創(chuàng)造性的勞動在所述方法或裝置中可以包括更多或者更少的操作步驟或模塊結構。在邏輯性上不存在必要因果關系的步驟或結構中，這些步驟的執(zhí)行順序或裝置的模塊結構不限于本申請實施例提供的執(zhí)行順序或模塊結構。所述的方法或模塊結構的在實際中的裝置或終端產品執(zhí)行時，可以按照實施例或者附圖所示的方法或模塊結構連接進行順序執(zhí)行或者并行執(zhí)行(例如并行處理器或者多線程處理的環(huán)境)。

本申請可以機構上傳的攜帶有流水的文件出發(fā)，對于這種攜帶流水的文件，需要第三方平臺對其進行相應的處理。當然，這些文件可以是還款流水文件、借款流水文件、凍結流水文件等，在申請實施例中可能更多的是以還款流水文件進行說明，然而這僅是為了更好地說明本申請，并不構成對本申請的不當限定。具體的如圖1所示，本申請?zhí)峁┑臄祿幚矸椒ǖ囊环N實施例可以包括：

s1：獲取機構上傳的待處理文件，其中，所述待處理文件中攜帶有一條或多條流水；

所謂的機構可以是一些理財的機構，或者是一些放貸或者是貸款的機構，這些機構在第三方平臺(例如：支付寶、招財寶、螞蟻聚寶等平臺)上進行業(yè)務擴展，人們通過對第三方平臺的使用實現在機構中的理財操作，例如，基金理財的機構可以在螞蟻聚寶或者是招財寶上投放可以被用戶認購的基金產品，銀行等金融機構也可以在招財寶等平臺上投放個人貸等理財產品。

在實際實現的時候，機構一般通過上傳待處理文件的方式以實現還款等業(yè)務，在第三方平臺中其實具有多種還款模式，例如：文件還款、接口還款、頁面還款、代扣等。在本申請實施例中，主要是對基于文件的處理方式進行說明，例如，機構可以通過文件交互的方式處理還款需求，從而將資金從機構發(fā)放到投資人者賬戶，并將資產注銷。

例如，機構可以將待處理文件(諸如還款文件、借款文件等)上傳到第三方平臺，然后等待第三方平臺對該文件進行處理，文件中可以包括：文件頭和文件內容，其中，文件頭中可以包括：版本號、總筆數和總金額等信息，文件內容中可以包括：一筆或者多筆流水，每一筆流水中可以包括：機構申請流水號、訂單號、資產標識、機構產品代碼、用戶id、還款類型、還款總金額、還款本金、還款利息、還款手續(xù)費和交易確認時間等信息。

s2：根據所述待處理文件的文件類型標識，確定所述待處理文件是否為預定標準文件；

考慮到現有的文件處理方式是，機構一天內僅可以上傳一次待處理文件，如果這份文件處理失敗，或者是這份文件中的一條或多條流水處理失敗，當天是無法進行補救的，因為機構當天沒有權限再次上傳文件，只能等到第二天。因此，在本申請實施例中，控制機構在第一次上傳文件處理失敗后，可以再次上傳文件，以便對第一次上傳處理失敗的流水再當天就可以處理完畢。即，將上傳規(guī)則修改為可以重傳，或者，是修改為可以多次重傳。例如：如果上傳的文件的格式有錯誤，那么可以通知機構，機構修改文件為正確格式后，重命名文件，然后再次上傳。再比如：如果有些流水在處理的時候，處理失敗，可以將這些處理失敗的流水通知機構，機構可以將這些處理失敗的流水整合為一個文件，重新上傳，也可以將整個文件作為重傳文件重新上傳。為此，在本申請實施例中，設置了預定標準文件和非預定標準文件，其中，預定標準文件就是當天第一次上傳的文件，非預定標準文件就是第二次、第三次等(即非第一次)上傳的文件。通過這種方式實現對標準文件和非標準文件的區(qū)分，如果是標準文件則可以按照正常的處理流程進行處理，如果是非標準文件則按照對非標準文件的處理方式進行處理。

具體地，為了實現對預定標準文件和預定非標準文件的區(qū)分，可以在文件中設置文件類型標識，通過設置的文件類型標識可以確定出當前的文件是預定標準文件(即，當日第一次上傳的文件)還是非預定標準文件(即，非當日第一次上傳的文件)。為了實現對不同文件類型基于文件類型標識的區(qū)分，可以通過在文件名中設置標識字段的方式實現。具體地，在實際實現的時候，可以通過文件名中的日期字段來區(qū)分是否為預定標準文件，例如，當日第一次上傳的文件(預定標準文件)用當天的日期作為命名，如果不是當日第一次上傳的文件(非預定標準文件)則用一個其他的日期，這樣通過日期命名的方式就可以確定出當前的文件是否為預定標準文件；還可以通過文件名中的后綴字段區(qū)分是否為預定標準文件，例如，可以在文件名后加上例如“-1”“-2”這種后綴字段，如果是第一次重傳的可以通過-1表示，如果是第二次重傳的可以通過-2表示。當然，還可以采用其它方式來標識，例如，還可以在文件名中加上版本號等，以實現對預定標準文件和非預定標準文件的區(qū)分。

在一個實施方式中，如果以文件名中的標識字段作為文件類型表示，則上述步驟s2可以按照以下方式實現，包括：

s2-1：提取待處理文件的文件名中的標識字段；

s2-2：確定所述標識字段是否與預設的預定標準文件的文件名的命名方式相匹配；

s2-3：如果匹配，則確定所述待處理文件為預定標準文件；如果不匹配，則確定所述待處理文件為非預定標準文件。

在確定待處理文件是否為預定標準文件之后，可以對待處理文件進行校驗，在進行校驗的時候，可以校驗以下內容：

a)文件頭的筆數是否與文件內容中的記錄一致；

b)文件頭的總金額是否與文件內容中的記錄一致；

c)文件內容中是否存在任意兩筆資產id相同；

d)文件內容中是否存在任意兩筆機構申請流水號相同；

e)機構申請流水號是否只包含字母和數字；

f)還款類型是否是數字。

如果以上的校驗內容有任意一項校驗失敗，那么就終止對該待處理文件的校驗，也不進行后續(xù)的流水處理，而是直接生成處理失敗結果文件，其中，可以在該處理失敗結果文件中記錄校驗失敗的原因(例如：文件頭筆數與文件內容中的記錄不一致)，在整個還款流程終止，并通知機構和第三方平臺的審核人員(例如支付寶小二)文件校驗失敗，若每一項都校驗成功，那么就可以進入后續(xù)的流水處理流程。

s3：如果是預定標準文件，則對所述一條或多條流水進行處理；

在確定該待處理文件為預定標準文件，且進行了文件校驗之后，就可以對該文件進行處理，即，對其中的流水信息進行處理。

進一步的，為了保證對流水的處理不出現偏差，不會出現重復處理等問題，可以在進行流水處理前，做前置檢驗，具體的，前置檢驗可以包括：

a)該筆流水中的資金是否已經代發(fā)；

b)該筆流水的資產是否已經被贖回。

在完成上述前置檢驗，且前置檢驗通過后，就可以對該筆流水進行處理。例如，如果待處理文件為還款文件，那么對該條流水的處理就可以是對該文件中的該筆流水進行資金代發(fā)、資產注銷等一系列操作，從而最終將資金從機構賬戶轉到投資人賬戶，實現還款，在處理完成后，可以將處理結果通知機構和第三方平臺審核人員。

s4：如果是非預定標準文件，則在對所述非預定標準文件審核通過后，再對所述一條或多條流水進行處理，其中，所述非預定標準文件是在機構獲知預定標準文件處理失敗后當日重新上傳的文件。

也就是說，相對于預定標準文件，對于非預定標準文件的處理還包括對文件的審核，這個審核步驟主要是由第三方平臺的審核人員進行的，主要就是審核一下非預定標準文件的有效性等，這個審核操作是與預定標準文件之間的差別，對應預定標準文件是沒有這個操作步驟的，這個審核操作是非預定標準文件所特有的。

對于非預定標準文件而言，在進行審核之后，后續(xù)的前置檢驗和流水的處理與上述對預定標準文件的處理是相同的，也可以是按照以下方式進行前置校驗和流水處理：

前置檢驗可以包括：

a)該筆流水中的資金是否已經代發(fā)；

b)該筆流水的資產是否已經被贖回。

在完成上述前置檢驗，且前置檢驗通過后，就可以對該筆流水進行處理。例如，如果待處理文件為還款文件，那么對該條流水的處理就可以是對該文件中的該筆流水進行資金代發(fā)、資產注銷等一系列操作，從而最終將資金從機構賬戶轉到投資人賬戶，實現還款，在處理完成后，可以將處理結果通知機構和第三方平臺審核人員。

進一步的，考慮到非預定標準文件是在機構獲知預定標準文件處理失敗后當日重新上傳的文件，為了避免處理時候發(fā)生沖突，在處理非預定標準文件的時候，在文件校驗階段可以增加一些前置條件，以便確定當前是否有與自身處于同一階段的文件，例如，在進行文件校驗之前，可以先判斷：

a)預定標準文件已經完成校驗操作；

b)沒有其它的非預定標準文件正在進行文件校驗。

如果以上條件滿足，則可以對該文件進行校驗。

對于非預定標準文件，可以采用以下方式進行審核：

a)確定當前是否有預定標準文件；

b)確定當前是否有其它非預定標準文件處于審核階段；

如果沒有，則確定所述非預定標準文件審核通過。

這些增加前置條件進行判斷的操作，也可以是本申請實施例中，非預定標準文件相對于預定標準文件處理上的差別。

在實際實現的過程中，考慮到非預定標準文件作為預定標準文件的一個功能上的不足，存在的主要目的是為了使得預定標準文件在第三方平臺處理的時候如未處理成功，可以在當日對其進行補救。因為在實際處理的過程中，處理失敗可能是整個文件都失敗，也可能是僅有幾條流水處理失敗。因此，對于非預定標準文件可以攜帶有與預定標準文件完全相同的流水，也可以攜帶有預定標準文件中處理失敗的流水，或者是既攜帶有處理失敗的流水又攜帶有部分處理成功的流水，本申請對此不作限定。進一步的，非預定標準文件可以僅存在一個，也可以有多個，具體的非預定標準文件的數量可以需要選取。

在本申請實施例中，還提供了一個具體的實施例對上述數據處理方法進行說明，在本例中以還款文件作為待處理文件進行說明，然而，值得注意的是，該具體實施例僅是為了更好地說明本發(fā)明，并不構成對本發(fā)明的不當限定。

一般的基于文件的處理方式僅支持機構一天內上傳一次正式的還款文件，一旦該文件出錯，不管是文件格式有錯誤，還是內容校驗沒通過，又或者某條流水處理時候發(fā)生錯誤，都會影響機構當天的正常處理流程，而且在當日沒有可以補救的方式，只能等到第二天再上傳另一個還款文件，這樣勢必給流水處理過程帶來不便。

在本例中，將當天第一次上傳的還款文件稱為標準還款文件，將除當天第一次上傳的還款文件之外的還款文件稱為非標準還款文件。

對于標準還款文件，按照以下規(guī)則進行命名：

${instid}_refund_${yyyymmdd}.txt

其中，日期${yyyymmdd}必須為當前系統(tǒng)的日期，例如：guohua_refund_20151225.txt，表示在當前日期2015年12月25日，機構國華當天的還款文件。

對于非標準還款文件，可以按照以下兩種規(guī)則進行命名：

第一種：${instid}_refund_${yyyymmdd}.txt

其中，日期${yyyymmdd}不是當前系統(tǒng)日期；

第二種：${instid}_refund_${yyyymmdd}_{seq}.txt

其中，{seq}表示批次號。

通過上述的命名方式，可以實現標準還款文件和非標準還款文件之間的區(qū)分。

在本申請實施例中，文件還款可以多批次進行處理，支持機構同一天內上傳多個還款文件，即使第一次還款文件(即預定標準文件)出錯，機構還可以繼續(xù)上傳一到多個還款文件，也就是非預定標準文件，供第三方平臺(例如：招財寶系統(tǒng))處理，從而優(yōu)化了還款的異常處理機制，提升了機構的用戶體驗，并提高了后臺審核人員(例如：招財寶小二)的工作效率，也避免了由于機構預期還款給投資者帶來的負面影響。

舉例而言，如果支持機構一天內僅可以上傳一個正式的還款文件，如果該文件校驗通過，則第三方平臺可以進行正常的還款處理，生成還款結果文件，供機構使用。然而一旦該文件出錯，由于當天只能上傳一個還款文件，只能等到第二天再上傳另一個還款文件，因此會影響機構當天的正常還款流程。然而，如果支持機構在同一天內多次上傳還款文件，那么即使上一次傳的文件有錯誤，也可以及時進行補救。通過再次上傳文件，文件校驗之后，經過招財后臺管理系統(tǒng)的審核，走還款處理流程，可以生成結果文件。

具體地，在本例中，支持機構在同一天內多次上傳還款文件，將當天第一次上傳的文件稱為標準文件，如果文件校驗通過，則直接進行還款處理，處理完畢則生成還款結果文件；將不是第一次上傳的文件稱為非標準文件，如果當天有上傳非標準文件，那么在文件校驗通過后，需要招財寶小二在后臺管理系統(tǒng)審核該文件，在審核通過后才可以進行還款處理，待處理完畢，生成還款結果文件。

為了實現上述功能，在本例中，還提供了一個具體的實現系統(tǒng)，該系統(tǒng)可以應用在例如招財寶等第三方平臺上，該系統(tǒng)可以由三個子系統(tǒng)組成，分別為：

1)文件處理系統(tǒng)，用以對還款文件做校驗、并進行還款處理。

2)后臺管理系統(tǒng)，當還款文件是非標準還款文件時，需要小二在該系統(tǒng)審批該文件，然后文件處理系統(tǒng)才可以進行還款處理。

3)中心處理系統(tǒng)，在進行還款處理時，文件處理系統(tǒng)會調用該系統(tǒng)做資金代發(fā)、資產注銷等操作。

基于上述的處理系統(tǒng)，可以按照如圖2所示的流程進行文件還款，不管是標準文件還是非標準文件，都需要做文件校驗和還款處理兩個部分，區(qū)別在于非標準文件在文件檢驗通過之后，需要后臺審核，該審核過程可以是后臺工作人員審核，也可以是預置一段程序，通過機器審核。下面分別對兩種還款文件的還款流程進行一下說明：

1)標準還款文件的處理：

標準還款文件的處理設置為最高優(yōu)先級，且在實際執(zhí)行的過程中相對使用比例比較高，對于標準還款文件的處理，主要可以分為兩個步驟：文件檢驗和還款處理，下面逐一說明。

a)文件校驗

文件處理系統(tǒng)獲取到機構上傳的標準還款文件之后，對該文件進行校驗，如圖3所示，校驗的內容可以包括：

文件頭的筆數是否與文件內容中的記錄一致；

文件頭的總金額是否與文件內容中的記錄一致；

文件內容中是否存在任意兩筆資產id相同；

文件內容中是否存在任意兩筆機構申請流水號相同；

機構申請流水號是否只包含字母和數字；

還款類型是否是數字。

如果上述校驗內容有任意一項校驗失敗，那么就需要終止對整個還款文件的校驗，同時生成還款結果文件，文件中記錄校驗失敗的原因(例如：文件頭筆數與文件內容中的記錄不一致)，整個還款流程終止，并通知機構和小二文件校驗失敗。反之，如果文件校驗成功，則進入下一步的還款處理。

b)還款處理

如圖2所示，經過文件校驗之后，進入還款處理流程，首先做還款前置校驗(也可以稱為還款前置檢驗)，例如：該筆流水中的資金是否已經代發(fā)，資產是否已經贖回等；如果前置校驗通過，則做還款處理。具體地，文件處理系統(tǒng)調用中心處理系統(tǒng)對文件逐筆進行資金代發(fā)、資產注銷等一系列操作，從而最終將資金從機構賬戶轉到投資人賬戶，實現還款。最后，通知機構和招財寶小二還款成功。

2)非標準還款文件的處理：

對于非標準還款文件的處理可以認為是異常處理機制，一般情況下，是在對標準還款文件處理失敗的情況下，才啟用對非標準還款文件的處理。類似于對標準還款文件的處理，對于非標準還款文件的處理也可以分為兩個步驟：文件檢驗和還款處理，下面逐一說明。

a)文件校驗

該步驟與上述對標準還款文件的校驗內容一樣，不同的是，在開始對文件進行校驗之前，可以設置一些前置條件，例如：

有標準還款文件且已經完成文件校驗操作；

沒有其它的非標準還款文件正處于校驗階段；

如果以上兩條都滿足，那么就對該非標準還款文件進行校驗，校驗內容與上述對標準還款文件的校驗內容相同，如果其中的任意一項校驗失敗，則終止對整個還款文件的校驗，生成還款結果文件，文件中記錄校驗失敗的原因，整個還款流程終止，并通知機構和小二文件校驗失??；反之，如果文件校驗成功，則進入下一步的還款處理。

b)還款處理

如圖2所示，如果非標準還款文件校驗成功，則會通知招財寶小二去后臺審核該文件，審核時，需要滿足以下條件：

有標準還款文件且已經完成文件校驗操作；

沒有其它的非標準還款文件正處于審核階段；

如果以上兩條都滿足，那么則小二審核文件通過，然后做還款處理，對于非標準還款文件的還款處理與對標準還款文件的還款處理是一樣的，文件處理系統(tǒng)調用中心處理系統(tǒng)對文件逐筆進行資金代發(fā)、資產注銷等一系列操作，從而最終將資金從機構賬戶轉到投資人賬戶，實現還款，最后通知機構和小二還款成功。

在上述實施例中，支持同一個機構在同一天內多次上傳還款文件，優(yōu)化了第三方平臺的異常處理機制，優(yōu)化了處理流程，提升了機構的用戶體驗，同時降低了由于機構文件傳錯而造成的逾期還款風險，提高了投資者對第三方平臺的信任。

基于同一發(fā)明構思，本發(fā)明實施例中還提供了一種數據處理裝置，如下面的實施例所述。由于數據處理裝置解決問題的原理與數據處理方法相似，因此數據處理裝置的實施可以參見數據處理方法的實施，重復之處不再贅述。以下所使用的，術語“單元”或者“模塊”可以實現預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現，但是硬件，或者軟件和硬件的組合的實現也是可能并被構想的。圖4是本發(fā)明實施例的數據處理裝置的一種結構框圖，如圖4所示可以包括：獲取模塊401、確定模塊402、第一處理模塊403和第二處理模塊404，下面對該結構進行說明。

獲取模塊401，可以用于獲取機構上傳的待處理文件，其中，所述待處理文件中攜帶有一條或多條流水；

確定模塊402，可以用于根據所述待處理文件的文件類型標識，確定所述待處理文件是否為預定標準文件；

第一處理模塊403，可以用于在確定是預定標準文件的情況下，對所述一條或多條流水進行處理；

第二處理模塊404，可以用于在確定是非預定標準文件的情況下，在對所述非預定標準文件審核通過后，再對所述一條或多條流水進行處理，其中，所述非預定標準文件是在機構獲知預定標準文件處理失敗后當日重新上傳的文件。

在一個實施方式中，確定模塊402可以包括：提取單元，用于提取所述待處理文件的文件名中的標識字段，其中，通過文件名中的標識字段作為文件類型標識；確定單元，用于確定所述標識字段是否與預設的預定標準文件的文件名的命名方式相匹配；如果匹配，則確定所述待處理文件為預定標準文件；如果不匹配，則確定所述待處理文件為非預定標準文件。

在一個實施方式中，標識字段可以包括：文件中的日期字段，和/或，文件中的后綴字段。

在一個實施方式中，第一處理模塊和第二處理模塊，可以逐條確定所述一條或多條流水是否已被處理；對所述一條或多條流水中未被處理的流水進行處理。

在一個實施方式中，上述數據處理裝置還可以包括：審核模塊，用于確定當前是否有預定標準文件或其它非預定標準文件處于審核階段；如果沒有，則對所述非預定標準文件審核。

在一個實施方式中，所述非預定標準文件攜帶有與所述預定標準文件完全相同的流水，或者，所述非預定標準文件中攜帶有所述預定標準文件中處理失敗的流水。

在一個實施方式中，第一處理模塊403和第二處理模塊404具體用于對所述待處理文件中的一條或多條流水逐條進行資金代發(fā)或者資產注銷，其中，所述待處理文件為還款文件。

本申請?zhí)峁┑臄祿幚矸椒ê脱b置，機構在獲知預定標準文件處理失敗后當日可以重新上傳文件，而不是一天內僅可以上傳一次文件，從而使得在對預定標準文件處理失敗的情況下，當天可以及時進行補救，解決了現有技術中文件處理失敗需要等到第二天才可以進行補救而導致的用戶和機構的體驗差的技術問題，達到了有效提高用戶和機構的體驗的目的。

本申請中各個實施例所涉及的上述描述僅是本申請中的一些實施例中的應用，在某些標準、模型、方法的基礎上略加修改后的實施方式也可以實行上述本申請各實施例的方案。當然，在符合本申請上述各實施例的中所述的處理方法步驟的其他無創(chuàng)造性的變形，仍然可以實現相同的申請，在此不再贅述。

雖然本申請?zhí)峁┝巳鐚嵤├蛄鞒虉D所述的方法操作步驟，但基于常規(guī)或者無創(chuàng)造性的勞動可以包括更多或者更少的操作步驟。實施例中列舉的步驟順序僅僅為眾多步驟執(zhí)行順序中的一種方式，不代表唯一的執(zhí)行順序。在實際中的裝置或客戶端產品執(zhí)行時，可以按照實施例或者附圖所示的方法順序執(zhí)行或者并行執(zhí)行(例如并行處理器或者多線程處理的環(huán)境)。

上述實施例闡明的裝置或模塊，具體可以由計算機芯片或實體實現，或者由具有某種功能的產品來實現。為了描述的方便，描述以上裝置時以功能分為各種模塊分別描述。在實施本申請時可以把各模塊的功能在同一個或多個軟件和/或硬件中實現。當然，也可以將實現某功能的模塊由多個子模塊或子單元組合實現。

本申請中所述的方法、裝置或模塊可以以計算機可讀程序代碼方式實現控制器按任何適當的方式實現，例如，控制器可以采取例如微處理器或處理器以及存儲可由該(微)處理器執(zhí)行的計算機可讀程序代碼(例如軟件或固件)的計算機可讀介質、邏輯門、開關、專用集成電路(applicationspecificintegratedcircuit，asic)、可編程邏輯控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存儲器控制器還可以被實現為存儲器的控制邏輯的一部分。本領域技術人員也知道，除了以純計算機可讀程序代碼方式實現控制器以外，完全可以通過將方法步驟進行邏輯編程來使得控制器以邏輯門、開關、專用集成電路、可編程邏輯控制器和嵌入微控制器等的形式來實現相同功能。因此這種控制器可以被認為是一種硬件部件，而對其內部包括的用于實現各種功能的裝置也可以視為硬件部件內的結構?；蛘呱踔粒梢詫⒂糜趯崿F各種功能的裝置視為既可以是實現方法的軟件模塊又可以是硬件部件內的結構。

本申請所述裝置中的部分模塊可以在由計算機執(zhí)行的計算機可執(zhí)行指令的一般上下文中描述，例如程序模塊。一般地，程序模塊包括執(zhí)行特定任務或實現特定抽象數據類型的例程、程序、對象、組件、數據結構、類等等。也可以在分布式計算環(huán)境中實踐本申請，在這些分布式計算環(huán)境中，由通過通信網絡而被連接的遠程處理設備來執(zhí)行任務。在分布式計算環(huán)境中，程序模塊可以位于包括存儲設備在內的本地和遠程計算機存儲介質中。

通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可借助軟件加必需的硬件的方式來實現?；谶@樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，也可以通過數據遷移的實施過程中體現出來。該計算機軟件產品可以存儲在存儲介質中，如rom/ram、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，移動終端，服務器，或者網絡設備等)執(zhí)行本申請各個實施例或者實施例的某些部分所述的方法。

本說明書中的各個實施例采用遞進的方式描述，各個實施例之間相同或相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。本申請的全部或者部分可用于眾多通用或專用的計算機系統(tǒng)環(huán)境或配置中。例如：個人計算機、服務器計算機、手持設備或便攜式設備、平板型設備、移動通信終端、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、可編程的電子設備、網絡pc、小型計算機、大型計算機、包括以上任何系統(tǒng)或設備的分布式計算環(huán)境等等。

雖然通過實施例描繪了本申請，本領域普通技術人員知道，本申請有許多變形和變化而不脫離本申請的精神，希望所附的權利要求包括這些變形和變化而不脫離本申請的精神。