銀行對帳單 銀行對賬單是什么意思

銀行對帳單、銀行存折等憑證，以及有關單位出具的證實材料。這些材料一般包括：收款人姓名、賬號、開戶行、賬號密碼、有效期、還款日期、金額款人、擔保人、抵押物、質押物等。假如是委托他人代收款，還需要提供代收款人的身份證實、委托書、代收款人的授權書等。此外，還還要提供收款人的銀行賬戶，以便核對款項是否到賬。

一：銀行對帳單余額

經過推算，結果是96320。首先告訴你貸方指的是你的收入，借方指的是你的支出。由此可以得出余額=100000+100000-2000-3510-40800-2000+32500+1930-1000-38000-50800=96320元。與銀行提供的結果一致。

二：銀行對帳單余額表

網上銀行

拿工商銀行來說，1、進入工商銀行網銀，點擊賬戶治理。

2、進入賬戶治理之后，點擊銀企對賬。

3、之后點擊查詢對賬記錄。

4、之后勾選余額對賬單。

5、挑選賬單的期限，點擊查詢。

6、頁面彈出余額對賬單，點擊具體信息。

7、頁面彈出對賬單明細表，點擊打印或者鼠標右鍵單擊點擊

網商銀行企業賬戶如何

1、進入交易明細頁面后，點擊【

2、點擊【確認】后，

三：銀行對賬單怎么看

在做對賬系統之前，需要把握肯定的財務知識。對賬系統很難做，網絡上基本沒有手把手教怎么做對賬系統的。本文

導讀

本篇文章基于我本身所經歷的對賬系統項目進行自我梳理整合輸出。

雖然我盡可能往通用性去編寫，但它還是不肯定合適所有系統及業態，而我本人也是在不斷的學習自我提升中，或許文章內容有些錯誤或描述不嚴謹的地方，懂行的老師辛勞幫助指出來，我會修改優化。

所以，這篇文章我僅提供參考。

在做對賬系統之前，系統的學習財務基礎知識是有必要的，要不然你在需求溝通時，或許連需求方（財務人員）的話都聽不懂。

財務人員，有一套專業的財務語言！很有意思的，大家可以去了解一下！

一、前言

互聯網的迅猛發展，帶動了各行各業的數字化轉型，數字化的轉型又免不了要從2C，2B兩個大方向上下功夫。

前幾年，大家忙于搭建屬于自己的業務及治理系統，通過中臺集群或SaaS或PaaS模式，讓自己進入互聯網時期的賽道，時至今日，隨便去哪個地方，都可以小程序、APP、三方平臺進行購物點餐預約等。

在面向生產者的方向，2C的業務遍地開花；而在后方，2B能力也在不斷的提升，2C與2B的融合也為各行業品牌帶來了一個較大的痛點：

對賬難。

為什么會對賬難呢？

數據種類多、

對賬系統介于業務與財務系統之間，市場沒有通用能力強的對賬系統。

它所在位置如下圖：

從上圖可以看到，他的上游有訂單和支付（賬單），下游有財務（用友、金蝶等），還有各類的財務能力工具，如發票治理等。

在寫這篇文章之前，我有在網絡上、書籍中去學習了解行業中對賬系統的做法，總的來說，因行業問題和專業性問題，各有優劣，同時，我自己也主導過多次對賬系統從0-1的建設，有相對簡樸一點的，也有復雜一點的，其中觸及的難點巨多。

復雜一點的，當時系統評審會就連續開了十個工作日以上，平均天天不低于6小時的會議工夫。而且，對賬系統介于業務與財務系統之間，單純的了解業務是不可行的，必踩坑，所以同步需要了解財務的相關知識，詳細的后文會講解一部分。

在這幾年對賬系統的建設過程中，從十位以上財務從業人員、財務專家那里學習到許多財務對賬相關的知識。

有些知識在對賬系統中的使用很重要，但在前面所了解學習的對賬相關文章或教程中都沒有看到過，而本人也覺的這部分內容在對賬系統中作用性很大，在后續的篇幅中也會進行講述。

對賬系統很難做，網絡上基本上沒有手把手教做對賬系統的，許多的內容似是而非，前后翻閱能把人看懵。

想著既然要寫這篇文章，不如就干脆寫的細一點。

因為會寫的比較細，所以對賬相關的文章一定不是短工夫能寫完，究竟不是一兩篇的篇幅就能講清晰的。

會分成多次更新，更新頻率“隨緣”，但一定會更新完。

第一篇會為大家普及一些財務知識，以方便大家飛快進入有效的財務基礎理解階段。

同時，在第一篇中先預設一個對賬系統建設的需求場景，把需求進行羅列，作為后續具體拆的

二、財務基礎2.1 對賬的基本概念

對賬，就是核對賬目，是指在會計核算中，為保證賬簿記錄準確可靠，對賬簿中的有關數據進行審查和核對的工作。

對即是核對，賬即賬目。

在互聯網產品中，審查指的是對需要對賬的數據進行查驗，保證數據的完整性與正確性，一般會在不變動數據的情景下，對該部分數據進行有效獲取、校驗、標準化（統一格式）。

核對指的是一對一的核實對比，比如訂單與賬單對比，訂單指的是電子或紙質合同，賬單指的是資金記錄（支付寶賬單、銀行賬單等）。

對賬就是將需要對比的數據，經過校驗及標準化后，進行一對一的對比，以保證數據記錄的可靠，同時找出雙方的差異，并支持對差異數據進行溯源處理。

2.2 本方與對方的概念

對賬是指將需要核對的數據（一般為訂單及賬單）進行一對一的對比，在對比前，需預設本方與對方。

本方指的是可靠性較高（主觀判定）的一方數據，或需主要對比的一方數據。

對方指的是被對比的一方數據。

在訂單和賬單兩種數據類型上，理論就任何一方都可以被定義為本方，一類數據僅能被定義為某一方，不可同時將某數據既定義為本方又定義為對方。

2.3 原始憑證

會計憑證按照編制的程序和用途不同，分為原始憑證和記賬憑證。

原始憑證是在經濟業務發生時取得或填制的，用以記錄和證實經濟業務發生或實現情景的憑證。

我們在購買商品或服務時，所獲得的原始票據，即為原始憑證，如：

去餐廳點餐時，點餐實現服務員提供的點餐單（有的有價格有的沒有價格），付款時手機付款記錄；

去超市購買商品時，付款實現，超市所提供的交易清單及付款記錄；

通過互聯網購物，產生的訂單，訂單對應的支付記錄（支付寶、

因此，原始憑證的種類許多，如發貨單、收貨單、領料單、銀行結算憑證、各種報銷單據等在業務發生過程中產生的依據都算作原始憑證。

從對賬業務來說，觸及的憑證偏向于訂單、賬單、支付單等原始憑證。

2.4 記賬憑證

記賬憑證，會計專業術語，是財會部門根據原始憑證填制，記載經濟業務簡要內容，確定會計分錄，作為記賬依據的會計憑證。記賬憑證亦稱分錄憑證，又稱記賬憑單，按照登記賬簿的要求、確定賬戶名稱、記賬方向（借貸方向）和金額的一種記錄，是登記明細分類賬和總分類賬的依據。

那會計分錄又是什么？

我們日常假如有記賬的習慣的話，一般會這么記：

而，財務側在對原始憑證確認后，記賬的辦法叫做復式記賬法（借貸記賬法），其所記錄的內容，叫做會計分錄，會計分錄基于復式記賬法有標準的格式。如：

基于借貸邏輯（參考資產負債表），我們可看出，庫存商品-電腦屬于資產類科目，在本分錄中屬于借方，代表資產增加，銀行存款-招行屬于資產類科目，在本分錄中屬于貸方，代表資產減少。

即，在我所有的資產中，庫存商品增加了一臺電腦，但銀行存款減少了8000元。

假如購買商品時，商戶開具了發票，在借方的分錄應當是庫存商品-電腦不含稅價與稅金兩條記錄，這里就不細寫了。

因此，記賬憑證其實就是會計分錄，會計分錄就是財務人員的標準記賬辦法。

記賬憑證是由會計人員對審核無誤的原始憑證或匯總原始憑證，按其經濟業務的內容加以歸類整理，作為登記賬簿依據的會計憑證。會計人員填制記賬憑證要嚴格按照規定的格式和內容進行。

專用記賬憑證，是指分類反映經濟業務的記賬憑證。這種記賬憑證按其反映經濟業務的內容不同，又可以分為收款憑證、付款憑證和轉賬憑證。

在對賬系統中，對賬的整體動作，其實相稱于財務人員對原始憑證的對比與檢查，檢查實現的記錄成會計分錄，最終生成明細賬（有多少訂單就有多少條明細）及匯總賬（無論多少條，只要在我計算的歸屬范圍內的，統一匯總成一條）。

因此，對賬系統實現對賬后，會根據用戶實際訴求，生成明細賬及總分類賬，即記賬憑證。

2.5 單邊

在一對一對賬實現之后，發現某一條數據對應的另一方無數據，一般稱為單邊。

比如有訂單信息，但無與訂單對應的賬單數據，那么本次對賬差異稱為訂單單邊。

比如有賬單信息，但無與賬單對應的訂單數據，那么本次對賬差異稱為賬單單邊。

舉例以訂單為本方，某訂單金額為300元，但對賬時未找到賬單，則對賬差異為300元，差異類型為訂單單邊。

其公式為：本方金額-對方金額（雙方均可以是合并金額）

公式金額等于0為平賬，金額等于本方金額為本方單邊，金額等于對方金額為對方單邊，金額大于零且小于本方金額或金額為負責默認為金額不一致，屬于長短款，需溯源查詢差異原因。

2.6 長短款

財務側的現金長短款是指在盤點和核對庫存現金時，發現除挪用現金、白條頂庫、超限額留存現金等情景以外原因的現金日記賬余額與庫存現金數額不符。在對賬系統中，一般代表應收與實收不符（非單邊）。

對賬時，除了會發生2.5項所述單邊現象，也會存在長短款現象。

2.7 軋（gá）差

軋差是指利用抵銷、合同更新等法律制度，最終取得一方對另一方的一個數額的凈債權或 凈債務，如市場交易者之間，可能互有內容相同，方向相反的多筆交易，在結算或結束交易時，可以將各方債權在相等數額內抵銷，僅支付余額。

上述為財務側軋差的概念，或許難以理解，但舉個例子就知道了：

預設A和B都很講信用，A欠B10萬元，B欠A4萬元，沒有軋差的情景下，B需要向A支付4萬元，而A需向B支付10萬元；軋差后，則A對B的凈欠額為6萬元，A只需向B直接支付6萬元。

在對賬系統中，軋差一般指的是兩兩之間金額匯總之后的總差額。

2.8 平賬與差異（差錯）

這里的平賬是指對賬系統的對賬結果：對賬對平，而不是財務治理所說的讓各個分類賬戶的金額與其匯總賬戶的金額互相核算相等，達成會計中的所說的“賬賬相符”。

差異（差錯）指的是未對平的數據。一般差異包括單邊、長短款等。

差異的原因一般包括：

單邊及長短款可以依賴系統進行初始預判定，再人工復核；但長短款的原因一般需要人工判定及確認。

2.9 財年財月

財年指財務年度，財月指財務月。

一般來說，我國的財年指的是天然年，財月指的是天然月。

國外的財年和財月有遵循天然年天然月的，也有跳出天然年與天然月單獨設定的，比如美國部分州，會將企業成立當年的10月份定義為下一年的財年初始，10月份為下一財年第一個財月，且其財月并非天然月，而是以445標準執行，即第一季度第一個財月是從10月1日起的四面，第二個財月為后續四面，第三個財月為再后續五周，所以每個財月都跨天然月。

一般我國海內系統對應的財年財月以天然年天然月為準。

2.10 其他

只要觸及與財務相關的系統，絕對不答應對源數據（原始憑證）進行任何修改。

除了最終匯總金額小數位控制，其他任何階段，在計算過程中，不可進行四舍五入、小數位限制等操作。

本章2.3-2.8僅作基于對賬系統的簡樸描述，其在財務中所代表的含義相對較為復雜，個人建議應當從財務的角度去豐富相關的知識。

同時，沒有財務基礎想走對賬或需要走對賬發展路線的，建議先惡補復式記賬法、資產負債表等；若有財務基礎的，忽略本篇財務基礎部分，當然，若發現我有描述不當的，還請不吝指出，我將請教確認后進行修改更新。

三、需求場景

某零售品牌2C業務擴展飛快，對賬系統老舊，且人工干涉較多，原對賬中央已經跟不上業務發展，需建設最新對賬中央。

3.1 現狀3.3 數據關系

APP、

各支付渠道支付賬單需從各渠道

3.4 其他說明

以上為基礎需求描述，在后續講解中若發現有遺漏的，在實際設想篇幅中進行補充，同時會對本篇進行優化更新。

四、需求梳理

學習做產品時，總有人在你耳邊說，要想把產品做好，需要有自己的產品辦法論。

什么是產品辦法論？以需求梳理階段舉例，其實就是你去獲取、拆解、梳理、規整需求的辦法、運用的工具或者步驟等。

我所常用的辦法是從上往下看，通過總-分模式，先從大框架上了解整體業務目標，再基于組成大框架的一個個小模塊，去分別拆解、梳理細節內容。

這也就是人們常說的，框架思維。

以當前需求為例，首先確認清晰，我們要做什么？

做什么：做一套財務人員所需要的基于業務訂單與支付賬單的對賬系統，對賬實現后輸出財務人員所需的憑證及報表。

運用者、輸入、輸出、核心能力已經很明確了。

框架方向了解后，我們應當怎么去梳理細節內容呢？

從整個產品的維度思索，我們的用戶是財務人員，系統的屬性也是偏向于財務的，那么整體來說，我們系統中將包含許多的財務底層規則。

因此，假如在看同學沒有財務基礎的，或財務基礎很薄弱的，建議先閱讀第一篇。而財務知識很豐富的同學可以接著往下看。

我們已經對框架認識了，也明白需要考慮財務規范，那么我們在需求的拆解與梳理過程中，每一個步驟應當把模塊功能和財務規范做有效的結合。

4.1 業務輸入

從第一篇模仿的業務需求來看，我們可以對獲得的信息進行拆解：

法人： 是具有民事權利能力和民事行為能力，依法獨立享有民事權利和承擔民事義務的組織，是企業、公司的另一種稱呼。在本需求中，某集團下有兩個分公司（法人），分別負責自有渠道（自行建設）和三方平臺渠道（外部合作渠道）的業務治理。

補充閱讀：一個公司就是一個法人，我們看到公司營業執照中有法人代表，一般該法人代表就是公司老板，法人代表的含義是，他代表這個公司，是該公司（法人）的代言人。

所以在上游原始數據可能存在多個歸屬時，應著重考慮輸入的原始數據歸類問題。同時，在我們拿到這部分信息時，應當意識到我們所設想的表結構中，肯定要有數據歸屬字段，如所屬法人、所屬渠道等。

從上表，我們已知需要從哪些法人及渠道獲取訂單數據，同時我們還應當從需求方獲取相關的信息，包括但不限于：數據提供方式、提供周期、是否有統一訂單中央進行處理等。

假如需求方當前系統比較簡樸，沒有統一的訂單中央負責接入全部訂單信息，我們需要直接從三方拉取訂單，那么需要額外預備與三方支持溝通的方式（釘釘群、

一般來說，三方平臺都會有指定的支付方式，比如京東自有的京東支付、天貓的支付寶支付、抖音自有的抖音支付或

而法人A所負責的自有渠道，可能會對接多種支付方式，以上需求描述也明確的給出了對接的三方支付。

同時，明確了接入模式為直連。

直連指的是APP直接與三方支付（如

直連與間連各有優劣，本文不觸及支付詳細細節就不細講了，有想了解的朋友可以自行去了解一下支付相關的知識。

回歸需求拆解，我們還需要明確：對接的支付渠道通過何種方式提供賬單數據、提供賬單的周期等；三方平臺如何提供賬單數據、提供賬單的周期等。

儲值第一要素是合規，除了企業自身需要去申請單用途預付費卡資質之外，同步需要與銀行簽訂監管協議，儲值金額統一存入企業在該銀行的監管賬戶中。

單用途預付費卡主要分兩種，記名卡與不記名卡。兩者可儲值額度不同、有效期限制也不同，可以單獨去了解一下。

要點：所有人都應當重視的是，生產者儲值資金雖然在監管銀行所建立的企業賬戶中，但這筆錢的所有權仍是生產者，對于企業來說，這不是收入，而是負債，在資產負債表中屬于右側，在憑證中所體現的科目主要是預付費或遞延收益。

這部分資金，只有生產者在運用儲值生產后，才能基于訂單支付信息從監管賬戶劃入收入賬戶。

在本示例需求中，用戶運用儲值卡金額支付時，其訂單

我們在進入4.1之前有講，必須考慮財務屬性，因此，除以上信息外，我們還需要補充財務相關信息，包括但不限于：

財年財月、稅金治理、會計科目等。

同時，輸入給系統的全部數據，需要區分主數據與業務數據。

主數據指的是能夠輔助系統功能的數據類型，包括法人、渠道門店、支付渠道、商品類型、活動營銷、財年財月、稅率治理、會計科目等，后續在產品設想過程中，配置的各種屬性如對賬規則、憑證規則等都算主數據范疇。

業務數據指的是需基于系統規則進行對賬處理的數據，在本系統中，業務數據為訂單數據及賬單數據。

對賬實現輸出的會計憑證及報表數據，也屬于業務數據。

如需求所述，最小對賬周期顆粒度支持到T+1，也就是工作日對賬，比如：

本周一的數據，本周二對賬；本周五的數據下周一對賬；本周六和本周日的數據也是下周一對賬。

本條不算輸出需求，而是屬于對賬周期，也是輸出成果的周期。

與上兩項不同，該3條輸出要求均屬于成果類輸出要求。

需要按指定維度輸出明細結果、月結總賬以及會計憑證。

需要按照法人、渠道兩個層級維度查詢階段明細數據，并支持基于該兩層維度生成月結總報表及會計憑證。

如，渠道維度：

憑證信息（例）：

會計憑證1：

會計憑證2：

會計憑證4：（退款500元）

會計憑證5：（用戶補償500元）

示例中同步體現了稅金與不含稅金額的分錄，默認以商品銷售稅率13%為基準進行演示計算。

4.3 系統功能

輸入清楚、輸出明了。

那么，在功能設想上，也應當著重從這三點考慮，分別對應輸入、對賬、輸出。

4.3.1 輸入相關

與上游系統對接，包括主數據、業務數據系統，在對賬系統規劃導入數據規范、數據處理邏輯。

接收上游系統提供的主數據，包括渠道門店、商品分類、營銷活動等，支持渠道門店在系統中自行創建。

接收上游訂單中央推送的訂單、接收上游賬單中央推送的賬單、接收手動導入的訂單及賬單。

對主數據日常/更新推送至系統的進行完整性校驗，考慮主數據的變更、重復、缺失字段等處理手段。

對訂單進行完整性校驗，包括去重、非空、狀態篩選、數據歸屬判定及補充。

對賬單進行完整性校驗，包括去重、非空、數據歸屬判定及補充。

對通過校驗的訂單及賬單進行字段結構的格式統一，以便于后續對賬階段有效拉取相應對賬數據。

對未通過校驗的訂單、賬單、主數據進行獨立展現、標簽，設立處理規則。

4.3.2 對賬相關

在需求梳理過程中，許多的功能需求方是無法提出來的，如本示例需求，輸入和輸出說的很清楚明了，但功能其實基本略過，只有核心的對賬及基于對賬結果的處理。

那么，我們可以從事務處理的維度去思索功能的規劃設想，事前、事中、事后。

事前：事前主要分兩部分，第一部分為輸入對接，第二部分為輸入處理，這兩點在4.3.1已梳理。

在對賬模塊中，事前還包括從規范后的數據表中拉取對賬數據；

事中：指的是對賬過程中對賬的功能及邏輯，這里是整個對賬模塊最復雜的部分，會觸及到對賬使命、對賬組別、對賬批次、對賬類型、多次對賬、差異對賬，以至是對賬回退等；

事后：指對賬實現后的處理，包括差異分析、差異處理，輸出最終結果等。

在事后階段輸出最終報表成果時，表中展現含稅總價、未稅總價、稅金總額，其中稅金相關計算公式如下：

含稅單價＝未稅單價＊稅率（1+13%）

未稅單價＝含稅單價／稅率（1+13%）

稅金=未稅單價＊稅率（13%）

4.3.3 輸出相關

對賬實現后，依據財務側需求，需要輸出對賬結果，包括明細表單、匯總表單、會計憑證。

4.2部分示例描述了輸出成果內容，本節主要講述通過何種邏輯規則輸出所需成果內容。

從需求描述來說，可分兩個階段的輸出，分別是日常對賬階段與月結階段。

日常對賬階段，需要輸出對賬結果、差異分析。

對賬結果邏輯在對賬規則中體現，差異分析邏輯在差異分析規則中體現。同時，差異分析因為觸及到系統與人工處理的雙重邏輯，所以需要有獨立的差異處理邏輯。以上兩點，均需要支持將成果導出文檔，一般是Excel格式，這部分需要預設表格字段規則。

月結階段成果包含月結明細報表、匯總報表、會計憑證。

明細報表

匯總報表應基于財務需求，預設多報表字段及計算規則，如基于法人的匯總、基于渠道的匯總、基于商品類型的匯總等；

會計憑證需要根據財務側需求，支持可配置憑證格式，配置憑證內容取值，需要有借貸平衡相關的財務校驗邏輯等。

五、方案設想

無論什么行業，嘗試總分模式/先框架后細節的結構化做事辦法其實是許多人形成自我辦法論雛形的過程。除了需求階段我們運用總-分模式進行梳理之外，在方案設想階段，這種辦法依舊好用。

最終的結果需要達到：大能統察全局、合規合法、業務準確、冗余有度，小能功能具象、細節合理、流程清楚、落地可行。

這樣輸出的內容，在項目團隊中，即可向上戰略，又可平行溝通，還可向下賦能。

因此，在本次的第五大部分，我們從兩個維度進行闡述：

5.1 系統框架

5.1.1 系統主要組成部分

系統的框架不是憑空而來，而是基于對需求的透徹理解，對所設想出來的各個功能組件的有效融合，整個系統中，各功能組件都有各自不可或缺的作用，且盡可能保持功能的獨立性（觸及解耦的不在這里講）。

就如一張桌子，至少需要有桌面、桌腿兩個大模塊組成，其都有各自的作用，各自作用由獨立不重合。

基于此，我們從業務維度考慮，可以進行如下設想參考（包括但不限于）：

5.1.1.1 數據獲取

數據獲取模塊分別對接外部業務數據系統、主數據系統，獲得外部系統推送的相關數據，同時為了提高對賬系統的數據獲取的靈活性，增加文檔導入功能。

5.1.1.2 數據預備

數據預備階段，需要對業務數據進行歸類、校驗，補充主要字段，如財月信息等，訂單數據需篩選出可用來對賬的狀態。

無論是訂單或賬單數據，無論其

5.1.1.3 對賬引擎

對賬引擎作為對賬系統最核心的模塊能力，其在設想時需要考慮數據拉取、規則匹配、對賬取值、批次分配、差異對賬、結果輸出等正向流程之外，同時需要考慮特別場景產生的逆向流程，如使命撤銷引起的對賬回退，已對賬數據的歷史版本恢復等。

5.1.1.4 差異處理

對賬結果一般分別對平與差異（差錯）兩種，簡樸的差異可以通過系統預設邏輯進行預判定（如單邊），人工二次驗證確認即可，該做法可有效減少財務人員工作量，提高效率，而特別差異，如金額不一致的，無法預判定的，則需要人工判定差異并確認。

人工判定處理流程中，應包含人工平賬規則。

5.1.1.5 憑證處理

基于指定周期的對平數據、處理實現的差異數據（最新），拉取憑證生成規則生成所需的財務憑證。

憑證生成完畢應由財務人員基于審核流程進行審核。

5.1.1.6 報表輸出

報表與憑證的設想邏輯相對一致，均是從對賬結果獲取數據后依據模塊規則生成結果。

報表在系統中有兩個流程位置的可能，第一種與憑證平行，雙方取值

此兩種做法應以實際業務需求為準。

5.1.1.7 系統配置

本次系統設想中，法人、業務渠道、支付渠道、財務主數據、對賬規則等都歸屬于系統配置模塊，但因其在整個系統主線流程中各有交叉，在前幾項中也有所展現，故本項圖片中僅展現非業務配置項。

5.1.2 系統框架

在實際設想產品時，總有人會說，什么總-分模式都是扯淡，當沒有能力將需求轉換為功能的時，很難去規劃出產品的【總】。

說的對。

所以，5.1.1其實就是在將需求轉換為功能模塊，在補充規劃【總】之前的積累。

題外話：為什么說辦法論是學不到，而是需要自我的經驗、學習、踩坑等各種經歷積累梳理后的成果？

你沒有從微小到大框架按部就班思索、成長的過程，又如何能夠飛快形成自我思維模式，再反向從框架到細節去剖析？

那么，辦法論的成熟到底怎么來？

積累、學習、提升，從細小功能到子模塊到主模塊到系統到產品戰略，當你在摸爬滾打N久后，自我梳理后，你面對新的需求、新的挑戰時，你的腦子里瞬間閃過了無數的畫面及可能，思索1秒或者2秒，你大方向的解決方案其實就出來了，再細心思索一番后，核心流程也能梳理出來，這個時分，你會一點點去跟對方（需求方）確認這是否就是對方所要達成的目標。

在5.1.2，我們將進入真正的【總】，這需要你對前文充分閱讀。

5.1.2.1 系統總框圖

總框圖體現的是業務結構，包含了需要設想的系統組件結構與外部輸入或輸出的關聯關系。

在整個系統設想中，總框圖是劃定主線、刻畫核心能力、體現模塊依靠關系的重要藍圖。所以，總框圖的繪制要點是模塊獨立、相互依靠、全而不細、路徑正確、組成清楚。

總框圖從下往上，灰色部分為外部系統，灰色箭頭代表對賬系統與外部其他系統的交互，支持接收外部數據（業務數據及部分主數據），支持推送成果至外部系統，如審核通過后的憑證推送至用友、金蝶或SAP等系統。

橙色框線內，除系統設置外，主要區分了量大模塊搭配，分別為數據處理相關與對賬處理相關。數據處理業務流程基于橙色箭頭所示，從獲取處處理屬于單向業務流；對賬處理中，對賬引擎為處理主模塊，基于結果分別輸出憑證與報表。

紅色箭頭的定義：對賬中央可以拆分為兩個系統，分別為對賬處理系統（紅色箭頭上方部分）與數據處理系統（紅色箭頭下方部分），部分公司因業務因素，需要獨立處理大量數據，包括訂單、賬單、活動、營銷等，其已有或計劃或正在施行數據中臺，對賬處理系統所需的可對賬數據，將由該數據中臺統一處理（處理后的數據除了推送對賬，也會推送至BI或成本核算等系統）。

也有部分公司，處于財務獨立性的考慮，會將數據處理與對賬處理合并為一套整系統進行規劃。

在實際產品規劃過程中，應著重考慮以上因素。

5.1.2.2 對賬主流程

流程圖中，體現了幾個重要的節點或數據：橙色部分標明，每次對賬應將對賬數據進行凍結；淺紅色部分差異處理邏輯比較重要；中紅色部分特別標明凍結本財月，指的是從本節點往后生成財月報表及財月憑證邏的輯，其成果輸出一般每財月處理一次（月結、季結、年度總結等）。

5.1.3 依靠關系

5.1.3.1 系統間依靠

我們從總框圖中已經可以看到，從系統關聯維度考慮，包括上游輸入系統、對賬系統、下游輸出系統，三個系統組成整體的業務流程，這三個系統之間存在著強依靠關系：

對賬系統依靠上游輸入系統提供的數據源；

下游輸出系統依靠對賬系統提供的對賬結果數據。

其所形成的業務鏈如下，且不可逆、不可空缺。

5.1.3.2 功能組件依靠

在總框圖及主流程圖中，我們不難看出，對賬系統核心組件主要包括數據獲取、數據預備、對賬引擎、結果處理、業務輸出；其業務關系如展現順序，業務不可逆不可缺。

其中，設想的規則部分雖然獨屬于系統設置模塊，但其目的亦是為以上業務組件服務，可以拆解到五大核心中。

從圖中也可以看出，整個對賬系統組件關系也可以基于業務有效區分事前、事中、事后。與我們前面所講的產品階段思索維度又有重疊。

因此，在做產品設想階段，我們應當從多維度去剖析，互相驗證，以保證設想成果的正確性、可行性。

注：以上部分圖片來自互聯網，如有侵權請私聊告知刪除，謝謝！

本文由@PM陳鏡安 原創發布于人人都是產品經理。未經許可，禁止

題圖來自Unsplash，基于CC0協議。

該文觀點僅代表