本發(fā)明涉及數(shù)據(jù)處理技術領域，尤其是指一種異步實現(xiàn)發(fā)票實時上傳的方法。

背景技術：

目前增值稅收入已占我國年稅收總額的近50％，成為名符其實的第一大稅種。在稅制改革之初，由于增值稅建立在手工操作、傳統(tǒng)落后的稅收征管方式上，僅靠幾十萬稅務人員手工操作，還無法從根本上解決全國的增值稅專用發(fā)票偽造、虛開、騙抵等問題。

隨著信息化時代的到來，采用信息化手段進行稅收控制已經(jīng)成為當前的主流，如公開號為（ CN103761251A）的現(xiàn)有中國發(fā)明專利公開了一種基于FTP協(xié)議的同步上傳與下載文件的方法，包括：獲取需要上傳的壓縮文件；拆分所述文件為N個子文件，其中N大于等于2；上傳所述子文件給FTP服務器；在FTP服務器上下載所述子文件，相對應的將所有的子文件組合為原壓縮文件。在上傳端上傳的過程中，如果每成功上傳一個子文件，下載端都可以進行下載；當上傳較大文件時，所述方法能夠節(jié)約下載端的等待時間。上述方法采用同步上傳與下載，如果企業(yè)端發(fā)出發(fā)票上傳請求，處理端接收到請求后如果企業(yè)端請求一直在后臺等待處理結果，而且處理端系統(tǒng)也是直接開始處理上傳的發(fā)票信息，一直到有發(fā)票信息處理結果后才將結果信息拋給上傳請求，返回到企業(yè)開票端，這種同步處理方式會加大處理端服務器的壓力，容易導致企業(yè)開票端獲取結果超時。

技術實現(xiàn)要素：

為此，本發(fā)明所要解決的技術問題在于克服現(xiàn)有技術中采用同步處理方式會增加服務器端的壓力導致企業(yè)開票端獲取結果超時等問題，從而提供一種可有效地降低處理服務器端的壓力，同時大幅度減少企業(yè)端等待發(fā)票結果時間的一種異步實現(xiàn)發(fā)票實時上傳的方法。

為解決上述技術問題，本發(fā)明的一種異步實現(xiàn)發(fā)票實時上傳的方法，其步驟如下：步驟S1：開票端將上傳的發(fā)票數(shù)據(jù)通過密文通道傳輸至稅局端的受理平臺；步驟S2：所述受理平臺將所述上傳的發(fā)票數(shù)據(jù)發(fā)送到業(yè)務處理系統(tǒng)進行處理；步驟S3：所述業(yè)務處理系統(tǒng)調用上傳服務接口將發(fā)票數(shù)據(jù)上傳成功信息返回至所述開票端，并通過所述上傳服務接口將上傳的發(fā)票數(shù)據(jù)傳輸至上傳數(shù)據(jù)處理線程池，利用所述上傳數(shù)據(jù)處理線程池對上傳的發(fā)票數(shù)據(jù)進行處理。

在本發(fā)明的一個實施例中，所述步驟S3之后，所述開票端接收到所述業(yè)務處理系統(tǒng)返回的發(fā)票數(shù)據(jù)上傳成功信息后，經(jīng)過第一預設時間，開票端發(fā)起查詢上傳結果的請求，獲取上傳的發(fā)票數(shù)據(jù)的處理結果，并根據(jù)接收到的處理結果信息更新開票端已開具發(fā)票的狀態(tài)。

在本發(fā)明的一個實施例中，所述開票端發(fā)起查詢上傳結果的請求后，若沒有獲取相應處理結果，則每隔一第二預設時間，再次發(fā)起查詢上傳結果的請求。

在本發(fā)明的一個實施例中，所述開票端發(fā)起預設次數(shù)的查詢上傳結果的請求后，若沒有獲取相應處理結果，則返回步驟S1，重新上傳所述發(fā)票數(shù)據(jù)。

在本發(fā)明的一個實施例中，所述步驟S3中，利用所述上傳數(shù)據(jù)處理線程池對發(fā)票數(shù)據(jù)進行處理時，首先判斷用戶的有效性，如果是無效信息，則在處理結果表中寫入失敗標志；如果是有效信息，則判斷稅控設備的有效性，如果是無效信息，則在處理結果表中寫入失敗標志；如果是有效信息，繼續(xù)判斷上傳發(fā)票數(shù)據(jù)的完整性，若完整，則對發(fā)票數(shù)據(jù)進行驗簽，否則處理結果表寫入失敗標志。

在本發(fā)明的一個實施例中，對發(fā)票數(shù)據(jù)進行驗簽時，若發(fā)票數(shù)據(jù)與發(fā)票的加簽信息匹配，則獲取相應稅務機關代碼，將發(fā)票數(shù)據(jù)存入數(shù)據(jù)庫，在處理結果表寫入成功標志；若發(fā)票數(shù)據(jù)與發(fā)票的加簽信息不匹配或者不能獲取相應稅務機關代碼且沒有成功將發(fā)票數(shù)據(jù)存入數(shù)據(jù)庫，則均在處理結果表寫入失敗標志。

在本發(fā)明的一個實施例中，所述處理結果表是數(shù)據(jù)庫中記錄上傳發(fā)票處理結果的表格。

在本發(fā)明的一個實施例中，所述步驟S3中，所述上傳數(shù)據(jù)處理線程池是所述業(yè)務受理系統(tǒng)可以配置的最大處理線程。

在本發(fā)明的一個實施例中，所述開票端在開具發(fā)票時使用技術手段利用發(fā)票的全票面信息對發(fā)票進行加簽，所述業(yè)務處理系統(tǒng)處理上傳發(fā)票過程中采用驗簽的方式辨別發(fā)票信息的真?zhèn)巍?/p>

在本發(fā)明的一個實施例中，所述步驟S2中，所述受理平臺根據(jù)發(fā)出請求的用戶類型以及發(fā)出請求的業(yè)務類型將用戶請求發(fā)送至所述業(yè)務處理系統(tǒng)進行處理。

本發(fā)明的上述技術方案相比現(xiàn)有技術具有以下優(yōu)點：

本發(fā)明所述異步實現(xiàn)發(fā)票實時上傳的方法，將企業(yè)端開票系統(tǒng)與稅局端稅控處理系統(tǒng)以及稅局端數(shù)據(jù)庫三者合成一張電子網(wǎng)，通過采集企業(yè)端開具的發(fā)票全票面信息，并將采集到的信息實時上傳的方式，有效解決發(fā)票偽造、虛開、騙抵等問題。

附圖說明

為了使本發(fā)明的內容更容易被清楚的理解，下面根據(jù)本發(fā)明的具體實施例并結合附圖，對本發(fā)明作進一步詳細的說明，其中

圖1是本發(fā)明所述發(fā)票實時上傳流程圖；

圖2是本發(fā)明所述開票端查詢發(fā)票流程圖。

具體實施方式

如圖1所示，本實施例提供一種異步實現(xiàn)發(fā)票實時上傳的方法，其步驟如下：步驟S1：開票端將上傳的發(fā)票數(shù)據(jù)通過密文通道傳輸至稅局端的受理平臺；步驟S2：所述受理平臺將所述上傳的發(fā)票數(shù)據(jù)發(fā)送到業(yè)務處理系統(tǒng)進行處理；步驟S3：所述業(yè)務處理系統(tǒng)調用上傳服務接口將發(fā)票數(shù)據(jù)上傳成功信息返回至所述開票端，并通過所述上傳服務接口將上傳的發(fā)票數(shù)據(jù)傳輸至上傳數(shù)據(jù)處理線程池，利用所述上傳數(shù)據(jù)處理線程池對上傳的發(fā)票數(shù)據(jù)進行處理。

本實施例所述一種異步實現(xiàn)發(fā)票實時上傳的方法，所述步驟S1中，開票端發(fā)出上傳發(fā)票數(shù)據(jù)請求，所述開票端可以是企業(yè)端，企業(yè)端通過互聯(lián)網(wǎng)發(fā)出上傳發(fā)票數(shù)據(jù)，所述開票端發(fā)出的請求數(shù)據(jù)通過密文通道傳輸至稅局端的受理平臺，有效保障了信息傳輸?shù)陌踩?；所述步驟S2中，所述受理平臺將所述上傳的發(fā)票數(shù)據(jù)發(fā)送到業(yè)務處理系統(tǒng)進行處理，所述受理平臺是在外網(wǎng)環(huán)境中，用于接收從所述企業(yè)端發(fā)出的請求，且所述受理平臺起到一個數(shù)據(jù)清分的作用，會根據(jù)發(fā)出請求的用戶類型，將用戶請求發(fā)送到相應的業(yè)務處理端進行處理；所述步驟S3中，所述業(yè)務處理系統(tǒng)調用上傳服務接口將發(fā)票上傳成功信息返回至所述開票端，并通過所述上傳服務接口將上傳的發(fā)票數(shù)據(jù)傳輸至上傳數(shù)據(jù)處理線程池，利用所述上傳數(shù)據(jù)處理線程池對上傳的發(fā)票數(shù)據(jù)進行處理，具體地，所述開票端實時上傳發(fā)票信息后，不必等待所述業(yè)務處理系統(tǒng)對發(fā)票的處理結果，所述業(yè)務處理系統(tǒng)接收到發(fā)票上傳成功信息后，返回給開票端發(fā)票信息上傳成功的消息，同時利用所述上傳數(shù)據(jù)處理線程池對上傳的發(fā)票數(shù)據(jù)進行處理。由于整個流程采用異步方式實現(xiàn)，與同步相比，有效地降低了處理服務器端的壓力，同時大幅度減少了企業(yè)端等待發(fā)票結果的時間。

如圖2所示，所述步驟S3之后，所述開票端接收到所述業(yè)務處理系統(tǒng)返回的發(fā)票數(shù)據(jù)上傳成功信息后，經(jīng)過第一預設時間，開票端發(fā)起查詢上傳結果的請求，獲取上傳的發(fā)票數(shù)據(jù)的處理結果，并根據(jù)接收到的處理結果信息更新開票端已開具發(fā)票的狀態(tài)。所述開票端發(fā)起查詢上傳結果的請求后，若沒有獲取相應處理結果，則每隔一第二預設時間，再次發(fā)起查詢上傳結果的請求。所述第二預設時間與所述第一預設時間可以相同或者不同。所述開票端發(fā)起預設次數(shù)的查詢上傳結果的請求后，若沒有獲取相應處理結果，則返回步驟S1，重新上傳所述發(fā)票數(shù)據(jù)，由于對發(fā)票上傳結果提供單獨的查詢接口，有效地減輕了發(fā)票處理服務端的壓力，同時減少了企業(yè)端查詢發(fā)票處理結果的等待時間。

所述步驟S1中，所述開票端在開具發(fā)票時使用技術手段利用發(fā)票的全票面信息對發(fā)票進行加簽，不但可以保證發(fā)票的真實性，而且可以防止在傳輸過程中發(fā)票信息被篡改；所述密文通道是SSL（Secure Sockets Layer 安全套接層）通道，所述SSL通道首先會進行用戶身份驗證，有效保證了用戶的合法性，另一方面也保證了信息傳輸過程中的安全性，有效保障了傳輸數(shù)據(jù)在傳輸過程中不被截取或者竊聽。

所述步驟S2中，所述受理平臺根據(jù)發(fā)出請求的用戶類型以及發(fā)出請求的業(yè)務類型將用戶請求發(fā)送至所述業(yè)務處理系統(tǒng)進行處理，具體地，所述開票端發(fā)出的請求數(shù)據(jù)經(jīng)過所述SSL通道進而接入稅局端部署的受理平臺，所述平臺是在外網(wǎng)環(huán)境中，用于接收從開票端發(fā)出的請求，該平臺起到一個數(shù)據(jù)清分的作用，會根據(jù)發(fā)出請求的用戶類型，將用戶請求發(fā)送到相應的業(yè)務處理端進行處理。

所述步驟S3中，所述業(yè)務處理系統(tǒng)處理上傳發(fā)票過程中采用驗簽的方式辨別發(fā)票信息的真?zhèn)危行У亟鉀Q了偽造、虛開發(fā)票的問題，既提高了效率，同時也加大了稅控的力度。稅局端部署的業(yè)務處理系統(tǒng)根據(jù)收到的用戶請求業(yè)務類型以及發(fā)出請求的業(yè)務類型，調用業(yè)務處理系統(tǒng)的發(fā)票上傳服務接口，對上傳發(fā)票數(shù)據(jù)進行處理。具體地，所述業(yè)務處理系統(tǒng)通過上傳服務接口將上傳信息返回至所述開票端，所述上傳信息是指上傳數(shù)據(jù)成功信息，使所述開票端獲取上傳成功的信息；同時通過所述上傳服務接口將發(fā)票數(shù)據(jù)傳輸至上傳數(shù)據(jù)處理線程池，利用所述上傳數(shù)據(jù)處理線程池對發(fā)票數(shù)據(jù)進行處理。利用所述上傳數(shù)據(jù)處理線程池對發(fā)票信息進行處理時，首先判斷用戶的有效性，如果是無效信息，則在處理結果表中寫入失敗標志；如果是有效信息，則判斷稅控設備的有效性，如果是無效信息，則在處理結果表中寫入失敗標志；如果是有效信息，繼續(xù)判斷上傳數(shù)據(jù)的完整性，若完整，則對發(fā)票進行驗簽，否則處理結果表寫入失敗標志；對發(fā)票進行驗簽時，若信息與發(fā)票的加簽信息匹配，則獲取相應稅務機關代碼，將發(fā)票數(shù)據(jù)存入數(shù)據(jù)庫，在處理結果表寫入成功標志；若信息與發(fā)票的加簽信息不匹配或者不能獲取相應稅務機關代碼且沒有成功將發(fā)票數(shù)據(jù)存入數(shù)據(jù)庫，則均在處理結果表寫入失敗標志，其中所述處理結果表是數(shù)據(jù)庫中記錄上傳發(fā)票處理結果的表格。

值得注意的是：所述開票端對發(fā)票進行加簽后，發(fā)票信息被傳輸至所述業(yè)務處理端，所述業(yè)務處理端利用所述的全票面發(fā)票信息對發(fā)票進行驗簽時，加簽與驗簽是一個不可逆的過程，只有驗證完全通過，此發(fā)票才會被認可，存入數(shù)據(jù)庫，以方便后續(xù)查找操作，一方面保證發(fā)票的真實性，另一方面也可以檢測出是否在傳輸問題中發(fā)票信息被篡改，由于業(yè)務處理系統(tǒng)在將發(fā)票信息入庫前驗簽，有效地保證了入庫發(fā)票的真實性，很大程度上加大了稅控的力度。

為了提高了系統(tǒng)的吞吐量，上傳的發(fā)票數(shù)據(jù)提交給異步處理的線程池處理，所述上傳數(shù)據(jù)處理線程池是所述業(yè)務受理系統(tǒng)可以配置的最大處理線程，從而可以根據(jù)服務器性能和并發(fā)用戶動態(tài)調整異步處理的線程數(shù)，超過最大線程將拒絕新的請求，從而可以保證服務的穩(wěn)定性。

本實施例中，所述企業(yè)開票系統(tǒng)與稅局端稅控處理系統(tǒng)以及稅局端數(shù)據(jù)庫三者合成一張電子網(wǎng)，通過采集企業(yè)開票端開具的發(fā)票全票面信息，并將采集到的信息實時上傳的方式，有效解決發(fā)票偽造、虛開、騙抵等問題。

本發(fā)明的一個成功案例是基于JAVA語言開發(fā)的標準J2EE項目。

綜上，本發(fā)明所述技術方案具有以下優(yōu)點：

1.本發(fā)明所述異步實現(xiàn)發(fā)票實時上傳的方法，所述步驟S1中，開票端發(fā)出上傳發(fā)票數(shù)據(jù)，所述開票端可以是企業(yè)端，企業(yè)端通過互聯(lián)網(wǎng)發(fā)出上傳發(fā)票數(shù)據(jù)；所述開票端發(fā)出的請求數(shù)據(jù)通過密文通道傳輸至稅局端的受理平臺，有效保障了信息傳輸?shù)陌踩裕凰霾襟ES2中，所述受理平臺將所述請求數(shù)據(jù)發(fā)送到業(yè)務處理系統(tǒng)進行處理，所述受理平臺是在外網(wǎng)環(huán)境中，用于接收從所述企業(yè)端發(fā)出的請求，且所述受理平臺起到一個數(shù)據(jù)清分的作用，會根據(jù)發(fā)出請求的用戶類型，將用戶請求發(fā)送到相應的業(yè)務處理端進行處理；所述步驟S3中，所述業(yè)務處理系統(tǒng)通過上傳服務接口將上傳成功信息返回至所述開票端，同時調用所述上傳服務接口將發(fā)票數(shù)據(jù)傳輸至上傳數(shù)據(jù)處理線程池，利用所述上傳數(shù)據(jù)處理線程池對發(fā)票數(shù)據(jù)進行處理，由于整個流程采用異步方式實現(xiàn)，與同步相比，有效地降低了處理服務器端的壓力，同時大幅度減少了企業(yè)端等待發(fā)票結果的時間。

2.本發(fā)明所述一種異步實現(xiàn)發(fā)票實時上傳的方法，所述步驟S3之后，所述開票端接收到所述業(yè)務處理系統(tǒng)返回的發(fā)票數(shù)據(jù)上傳成功信息后，經(jīng)過第一預設時間，開票端發(fā)起查詢上傳結果的請求，獲取上傳的發(fā)票數(shù)據(jù)的處理結果，并根據(jù)接收到的處理結果信息更新開票端已開具發(fā)票的狀態(tài)。所述開票端發(fā)起查詢上傳結果的請求后，若沒有獲取相應處理結果，則每隔一第二預設時間，再次發(fā)起查詢上傳結果的請求。所述第二預設時間與所述第一預設時間可以相同或者不同。所述開票端發(fā)起預設次數(shù)的查詢上傳結果的請求后，若沒有獲取相應處理結果，則返回步驟S1，重新上傳所述發(fā)票數(shù)據(jù)，由于對發(fā)票上傳結果提供單獨的查詢接口，有效地減輕了發(fā)票處理服務端的壓力，同時減少了企業(yè)端查詢發(fā)票處理結果的等待時間。

顯然，上述實施例僅僅是為清楚地說明所作的舉例，并非對實施方式的限定。對于所屬領域的普通技術人員來說，在上述說明的基礎上還可以做出其它不同形式變化或變動。這里無需也無法對所有的實施方式予以窮舉。而由此所引伸出的顯而易見的變化或變動仍處于本發(fā)明創(chuàng)造的保護范圍之中。