中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：很多人都有記賬的習慣，但是記到后面卻發現自己的帳算不清楚，記賬不能只靠著單方面的賬單，還要進行對賬才能確保無誤；本文將會從產品設計的業務知識點出發，詳細介紹對賬業務流程，并列舉會出現的常見問題和解決方法。

業務背景：

對賬模塊是支付系統的核心能力之一，是信息流和資金流關聯的重要依據，平臺如果只使用渠道的單邊賬單或者平臺流水訂單，出現差錯或渠道惡意扣單的風險極高。

為提高資金賬務的正確性和保障平臺的利益，需要通過平臺系統對賬能力與上游渠道對賬單逐筆勾兌確認，如有差異能及時解決或歸檔。

用戶畫像：

1）清結算專員：負責發起清分的操作者，首先確保信息流對平，然后確認資金流應收款和信息流平賬賬單金額一致。希望能及時發現長短款問題，并解決，保障資金清算給商戶（平臺可收款用戶）的時效性。

2）對賬異常訂單處理專員：負責核算異常訂單原因，并在平臺操作將異常訂單執行修正、平賬。

一、必須知道的業務知識點

1. 對賬

在會計上概念：指為了保證賬簿記錄的正確性而進行的有關賬項的核對工作；做到賬證相符、賬賬相符、賬實相符。

在支付系統上的體現：

1）賬證核對：是將賬簿記錄與記賬憑證進行核對。這里是記賬憑證是指第三方上游提供的渠道對賬單，第三方渠道會根據對賬單金額實際結算資金，也就是常說的信息流對賬。（有的支付公司或銀行只要收到對賬單了且平賬，即使資金未實際到賬，業務也允許發起清分以提高清算時效性）

2）賬賬核對：是把有相互關系的多個賬簿記錄進行核對，有相互關系的賬簿記錄，包括總分類賬簿間核對，明細賬簿間核對等多種類型。整個支付系統可以被拆分成了多個子系統，如交易系統、賬戶系統、會計系統、賬戶系統，每個子系統在處理各自的業務并記錄，其實就相當于會記理論中的賬簿。系統間的對賬，主要用于修正內部系統的數據不一致。

3）賬實核對：是各項資產物資的記錄數值與實際真實數額間的核對。確認第三方匯款到銀行賬戶資金和平賬對賬單結算金額是否匹配，也就是常說的資金流對賬。

2. 軋帳

對賬系統主要做的是信息流的對賬，若對賬中發現有差異的訂單歸類記入對賬異常訂單表，可稱為軋帳。

3. 平帳

對賬異常訂單進入差錯流程，可以通過人工或者自動的方式，按照事先設計好的規則處理這些異常差錯，可稱為平帳。

4、渠道對賬單

上游渠道會按照平臺在其申請的渠道賬戶維度推送對賬單，渠道賬戶也就是常說的支付通道。

如果是第三方支付公司或銀行，上游渠道是微信、支付寶、銀聯二維碼（云閃付）等等。例如：支付平臺申請有微信2通道和微信6通道，則微信側會生成2份對賬單文件。

每份對賬單會包括支付成功訂單和退款成功訂單。第三方會以對賬單中的結算金額（支付訂單金額-支付訂單手續費）-（退款訂單金額-退款訂單手續費）結算匯款給到平臺資金賬戶。

5、銀聯二維碼（難點）

銀聯二維碼是銀聯平臺自主推出的支付產品，C端使用云閃付、各手機銀行APP支付，訂單底層走的都是銀聯二維碼通道。

為什么銀聯二維碼需要重點說呢？

因為它不同于微信、支付寶通道統一費率的原則，銀聯會根據C端用戶支付時使用的銀行卡借貸性質和交易金額是否大于1000作為費率規則，并且還會收取額外的品牌服務費，詳情參見下圖。

所以設計銀聯二維碼通道對賬時，還需考慮到多費率及品牌服務費的場景。

二、對賬流程

1. 業務流程

對賬業務可以插解為5個業務環節，本文主要說明每個環節的能力職責、常見問題和通用解決方法，具體的產品方案還需要結合讀者平臺自身的業務特點和系統架構設計。

三、對賬任務

對賬是一個日常操作，正常情況下上游渠道都會以D+1的周期生成渠道對賬單。

每天系統可以默認生成定時對賬任務，每個上游渠道生成時間不一樣，可以事前和上游確認，并結合平臺對賬的處理時效和商戶到賬需求，設計一個合理的時間執行。

對賬任務設計前需確認，渠道對賬單推送方式、解析方法、匹配字段，并提前做好聯調適配工作；例如渠道有可能會需要申請白名單權限或提供SFTP地址信息，要謹防上線后才發現系統無法正常獲取對賬單的情況。

1. 創建任務批次

創建批次一方面是為了防止重復對賬，另一方面需要在對賬結束的時候將對賬的結果信息存儲到批次中。

2. 記錄任務信息

對賬任務信息，例如：通道名稱、通道編號、渠道商戶號、對賬任務批次、對賬任務狀態、交易時間、任務創建時間、下載開始時間、下載結束時間、下載狀態、對賬開始時間、對賬結束時間、對賬結果、對賬方式；

對賬方式為對賬處理時的對賬規則，可以根據業務實際情況分為：無需對賬、以渠道為準、以平臺為準。

• 以渠道為準，則若對賬訂單平臺交易狀態為支付中或支付失敗，但渠道為支付成功，則平臺狀態改為支付成功。
• 以平臺為準，則是若出現上述情況，對賬訂單記錄為異常訂單。

3. 重置任務機制

考慮到對賬過程中可能會遇到的來自上游渠道的問題或平臺系統自身問題，需要設計重置機制。

上游渠道對賬單錯誤，需求二次或多次推送，所以需要設計重新下載渠道對賬單或重新上傳渠道對賬單；有可能平臺自身數據錯誤導致出現大量的差異訂單，修復后需要重新對賬。

4. 對賬任務詳情示例

1. 對賬信息：記錄對賬任務基本情況；
2. 對賬結果信息：顯示關鍵對賬字段值；
3. 掛銷賬信息：顯示是否有掛銷賬訂單及金額；
4. 對賬異常信息：顯示是否有對賬異常訂單及金額；
5. 備注：將系統自動處理的過程記錄，也可以手動修改。

四、對賬單下載

1. 獲取文件

渠道對賬單獲取方式，一般提前作為任務規則寫死。

大多數銀行都要求接入方提供ftp服務，銀行定時將對賬單推送到接入方提供的ftp服務器上面；

還有一部分銀行會提供對賬單的下載服務，通過ftp/http的都有，ftp方式居多；

另外網銀的對賬單比較特殊，一般都需要結算登錄網銀的后臺管理系統中，手動下載，結算下載完對賬單后在導入到對賬系統。

2. 判斷文件是否存在

任務自動獲取文件的情況下需要判斷任務是否存在：

自動獲取渠道對賬單：不存在需要設置輪詢，每間隔一段時間重新獲取。重試次數和間隔的設置需要小心，重試太頻繁，容易把服務器打死.；時間間隔太大，又會阻塞后續處理步驟。5～10分鐘是一個合適的重試間隔區間。

手動導入渠道對賬單：要設計導入入口，導入成功后任務狀態也要做相應的變更。

3. 下載文件

技術實現上可以做成工廠模式，不同的支付渠道有不同的下載類，如果是http接口將文件寫入到對賬單，如果是ftp服務器，將服務器中的對賬單下載到本地帶解析的目錄中。主要涉及的代碼ftp工具類、http(s)工具類，相關IO讀寫。

4. 判斷來源渠道

獲取到上游對賬單文件后，很有可能多個渠道的對賬單在同一個SFTP地址，根據文件名匹配到對應的對賬任務，文件名一般會包含賬單時間、渠道商戶號，然后再執行下一步。

五、文件解析

1. 解析文件

解析文件主要是將下載的對賬文件解析成我們可以對賬的數據類型并且入庫。

解析的文件不同渠道有不同的類型，因此也可以設計成不同的解析模板，使用工廠模式將不同格式的文件解析成可以對賬的統一數據類型。

解析的文件類型一般包括：json、text、cvs、excle等，另外部分銀行會對賬單做加密或者提供zip打包的格式，這里就需要額外開發zip工具類和加解密工具類進行處理。

對賬文件中包含的主要信息有：商戶訂單號、交易流水號、交易時間、支付時間、付款方、交易金額、交易類型、交易狀態這些字段。

2. 轉換入庫

每個渠道的賬單格式都不盡相同， 在得到賬單后，下一步是對賬單做標準化處理，這樣軋帳以及后續工作就可以統一處理了。

標準化后的賬單數據可以放在文件系統或者數據庫中，這取決于交易數據量；每天百萬以上的量，還是使用文件系統，比較合適，數據庫操作相對比較慢，也浪費資源。

基于文件系統的標準化涉及如下內容:

• 文件格式標準化統一使用csv或者json或者xml格式，如果是使用hadoop或者spark來對賬，也可以使用csv。
• 文件存儲統一化文件目錄，文件名都需要遵循統一命名規范。

六、對賬單處理

1. 獲取對方對賬單

將事前準備的上游對賬單標準文件放入緩沖對賬池。

2. 獲取我方對賬單

本地交易記錄的準備，總的來說有如下方法:

啥都不做，直接用訂單表的原始數據：鑒于大部分系統使用的是MySQL，這也意味著在MySQL上做對賬。對賬時需要大量的數據查找工作，必然會影響線上業務。在數據規模較大，比如超過100萬時，就不太合適了。

使用備庫來執行對賬：這樣既簡單，也不影響線上業務，這是典型的空間換時間的做法。

采用分表分庫對賬：如果業務大到需要分表分庫才能處理，那對賬數據準備也不一樣。

3. 逐一匹配

前文有提到對賬方式有三種，不對賬、以渠道為準、以平臺為準，大部分的情況下的對賬方式都以渠道為準，信息流的傳遞方向，支付成功結果是由上游渠道通知平臺的，平臺很有可能會因網絡或系統問題而沒有收到通知。

一般按照交易金額、交易狀態、手續費金額逐一匹配，對賬方式選擇以渠道為準的處理邏輯為例：

1）交易金額不匹配：記入異常訂單。

2）交易狀態不匹配：若上游為支付成功，我方為未支付或支付失敗，則以上游為準。

• 若我方訂單為支付成功，上游只會推送支付成功的訂單為對賬單，上游對賬單不存在的情況，將我方訂單記入為掛賬訂單；
• 若上游對賬單存在，我方不存在的情況，記入異常訂單。

3）手續費金額不匹配：記入異常訂單。

4. 掛銷賬處理

常會存在因日切時間點不一致或網絡延時等情況，導致我方平臺訂單時間與上游渠道時間不一致，同一個訂單在渠道交易時間是1月1號，但在平臺是1月2號。

1. 掛賬，對賬時若上游無我方有，訂單放入掛賬訂單中。
2. 銷賬，若匹配中掛賬訂單匹配上了，記錄為當日平臺賬單，掛銷賬狀態改為已銷賬。

七、差錯處理

關于差錯流程，每個系統的業務特性、運營團隊流程、公司財務管理辦法不一樣，不能生搬硬套，但原則是一樣的，所有的異常訂單的報銷賬必須有理有據，多重審核。

1. 異常原因

（1）若出現訂單金額不一致的情況，一般是平臺調用上游交易接口時，雙方字段的定義不匹配導致的。

（2）若出現手續費金額不一致的情況，一般是平臺手續費計算規則和上游不匹配導致的，差額不會太大，可以設計閥值若在可以接受的范圍類不計為異常。

（3）若出現上游對賬單存在，平臺訂單不存在的情況，通常是有第三方繞過平臺系統與上游系統發生支付或退款交易。需要及時核查是否存在交易密鑰泄露或被繞過商戶去上游系統平臺操作。

2. 修正

選擇以平臺為準或以上游為準，修改訂單金額、訂單狀態、手續費金額。此時寫入修正原因很重要，便于后期業務追蹤考求。

3. 平賬

將平臺異常訂單狀態改為平賬，并將平賬時的時間作為賬單時間，合入至平臺賬單。平臺會根據平臺賬單計算渠道分潤金額和商戶結算金額。

八、業務規則系統化

最后，每個平臺產品細節都會有其特定的業務規則，就不具體說明平臺頁面和和平臺操作功能，筆者不做詳情說明。以上業務規則系統化，系統流程圖如下，讀者可以結合自己平臺業務情況提取細化。

本文由 @Jamie Gao 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議