在做對(duì)賬系統(tǒng)之前，需要掌握一定的財(cái)務(wù)知識(shí)。對(duì)賬系統(tǒng)很難做，網(wǎng)絡(luò)上基本沒有手把手教怎么做對(duì)賬系統(tǒng)的。本文作者結(jié)合自身所經(jīng)歷的對(duì)賬系統(tǒng)項(xiàng)目進(jìn)行自我梳理整合輸出，希望能夠?qū)δ阌兴鶐椭?/p>

導(dǎo)讀

本篇文章基于我本身所經(jīng)歷的對(duì)賬系統(tǒng)項(xiàng)目進(jìn)行自我梳理整合輸出。

雖然我盡可能往通用性去編寫，但它還是不一定適合所有系統(tǒng)及業(yè)態(tài)，而我本人也是在不斷的學(xué)習(xí)自我提升中，或許文章內(nèi)容有些錯(cuò)誤或描述不嚴(yán)謹(jǐn)?shù)牡胤?，懂行的老師辛苦幫忙指出來，我?huì)修改優(yōu)化。

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

在做對(duì)賬系統(tǒng)之前，系統(tǒng)的學(xué)習(xí)財(cái)務(wù)基礎(chǔ)知識(shí)是有必要的，要不然你在需求溝通時(shí)，或許連需求方（財(cái)務(wù)人員）的話都聽不懂。

財(cái)務(wù)人員，有一套專業(yè)的財(cái)務(wù)語言！很有意思的，大家可以去了解一下！

一、前言

互聯(lián)網(wǎng)的迅猛發(fā)展，帶動(dòng)了各行各業(yè)的數(shù)字化轉(zhuǎn)型，數(shù)字化的轉(zhuǎn)型又免不了要從2C，2B兩個(gè)大方向上下功夫。

前幾年，大家忙于搭建屬于自己的業(yè)務(wù)及管理系統(tǒng)，通過中臺(tái)集群或SaaS或PaaS模式，讓自己進(jìn)入互聯(lián)網(wǎng)時(shí)代的賽道，時(shí)至今日，隨便去哪個(gè)地方，都可以小程序、APP、三方平臺(tái)進(jìn)行購(gòu)物點(diǎn)餐預(yù)約等。

在面向消費(fèi)者的方向，2C的業(yè)務(wù)遍地開花；而在后方，2B能力也在不斷的提升，2C與2B的融合也為各行業(yè)品牌帶來了一個(gè)較大的痛點(diǎn)：

對(duì)賬難。

為什么會(huì)對(duì)賬難呢？

數(shù)據(jù)種類多、來源多、樣式多、完整性參差不齊、準(zhǔn)確性參差不齊、各系統(tǒng)或三方提供數(shù)據(jù)時(shí)間節(jié)點(diǎn)一致性弱、對(duì)賬功能靠后前端感受不到；

對(duì)賬系統(tǒng)介于業(yè)務(wù)與財(cái)務(wù)系統(tǒng)之間，市場(chǎng)沒有通用能力強(qiáng)的對(duì)賬系統(tǒng)。

它所在位置如下圖：

從上圖可以看到，他的上游有訂單和支付（賬單），下游有財(cái)務(wù)（用友、金蝶等），還有各類的財(cái)務(wù)能力工具，如發(fā)票管理等。

在寫這篇文章之前，我有在網(wǎng)絡(luò)上、書籍中去學(xué)習(xí)了解行業(yè)中對(duì)賬系統(tǒng)的做法，總的來說，因行業(yè)問題和專業(yè)性問題，各有優(yōu)劣，同時(shí)，我自己也主導(dǎo)過多次對(duì)賬系統(tǒng)從0-1的建設(shè)，有相對(duì)簡(jiǎn)單一點(diǎn)的，也有復(fù)雜一點(diǎn)的，其中涉及的難點(diǎn)巨多。

復(fù)雜一點(diǎn)的，當(dāng)時(shí)系統(tǒng)評(píng)審會(huì)就連續(xù)開了十個(gè)工作日以上，平均每天不低于6小時(shí)的會(huì)議時(shí)間。而且，對(duì)賬系統(tǒng)介于業(yè)務(wù)與財(cái)務(wù)系統(tǒng)之間，單純的了解業(yè)務(wù)是不可行的，必踩坑，所以同步需要了解財(cái)務(wù)的相關(guān)知識(shí)，具體的后文會(huì)講解一部分。

在這幾年對(duì)賬系統(tǒng)的建設(shè)過程中，從十位以上財(cái)務(wù)從業(yè)人員、財(cái)務(wù)專家那里學(xué)習(xí)到很多財(cái)務(wù)對(duì)賬相關(guān)的知識(shí)。

有些知識(shí)在對(duì)賬系統(tǒng)中的運(yùn)用很重要，但在前面所了解學(xué)習(xí)的對(duì)賬相關(guān)文章或教程中都沒有看到過，而本人也覺的這部分內(nèi)容在對(duì)賬系統(tǒng)中作用性很大，在后續(xù)的篇幅中也會(huì)進(jìn)行講述。

對(duì)賬系統(tǒng)很難做，網(wǎng)絡(luò)上基本上沒有手把手教做對(duì)賬系統(tǒng)的，很多的內(nèi)容似是而非，前后翻閱能把人看懵。

想著既然要寫這篇文章，不如就干脆寫的細(xì)一點(diǎn)。

因?yàn)闀?huì)寫的比較細(xì)，所以對(duì)賬相關(guān)的文章肯定不是短時(shí)間能寫完，畢竟不是一兩篇的篇幅就能講清楚的。

會(huì)分成多次更新，更新頻率“隨緣”，但肯定會(huì)更新完。

第一篇會(huì)為大家普及一些財(cái)務(wù)知識(shí)，以方便大家迅速進(jìn)入有效的財(cái)務(wù)基礎(chǔ)理解階段。

同時(shí)，在第一篇中先預(yù)設(shè)一個(gè)對(duì)賬系統(tǒng)建設(shè)的需求場(chǎng)景，把需求進(jìn)行羅列，作為后續(xù)詳細(xì)拆的來源。

二、財(cái)務(wù)基礎(chǔ)

2.1 對(duì)賬的基本概念

對(duì)賬，就是核對(duì)賬目，是指在會(huì)計(jì)核算中，為保證賬簿記錄正確可靠，對(duì)賬簿中的有關(guān)數(shù)據(jù)進(jìn)行檢查和核對(duì)的工作。

對(duì)即是核對(duì)，賬即賬目。

在互聯(lián)網(wǎng)產(chǎn)品中，檢查指的是對(duì)需要對(duì)賬的數(shù)據(jù)進(jìn)行查驗(yàn)，保證數(shù)據(jù)的完整性與準(zhǔn)確性，一般會(huì)在不變動(dòng)數(shù)據(jù)的情況下，對(duì)該部分?jǐn)?shù)據(jù)進(jìn)行有效獲取、校驗(yàn)、標(biāo)準(zhǔn)化（統(tǒng)一格式）。

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

對(duì)賬就是將需要對(duì)比的數(shù)據(jù)，經(jīng)過校驗(yàn)及標(biāo)準(zhǔn)化后，進(jìn)行一對(duì)一的對(duì)比，以保證數(shù)據(jù)記錄的可靠，同時(shí)找出雙方的差異，并支持對(duì)差異數(shù)據(jù)進(jìn)行溯源處理。

2.2 本方與對(duì)方的概念

對(duì)賬是指將需要核對(duì)的數(shù)據(jù)（一般為訂單及賬單）進(jìn)行一對(duì)一的對(duì)比，在對(duì)比前，需預(yù)設(shè)本方與對(duì)方。

本方指的是可靠性較高（主觀判斷）的一方數(shù)據(jù)，或需主要對(duì)比的一方數(shù)據(jù)。

對(duì)方指的是被對(duì)比的一方數(shù)據(jù)。

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

2.3 原始憑證

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

原始憑證是在經(jīng)濟(jì)業(yè)務(wù)發(fā)生時(shí)取得或填制的，用以記錄和證明經(jīng)濟(jì)業(yè)務(wù)發(fā)生或完成情況的憑證。

我們?cè)谫?gòu)買商品或服務(wù)時(shí)，所獲得的原始票據(jù)，即為原始憑證，如：

去餐廳點(diǎn)餐時(shí)，點(diǎn)餐完成服務(wù)員提供的點(diǎn)餐單（有的有價(jià)格有的沒有價(jià)格），付款時(shí)手機(jī)付款記錄；

去超市購(gòu)買商品時(shí)，付款完成，超市所提供的交易清單及付款記錄；

通過互聯(lián)網(wǎng)購(gòu)物，產(chǎn)生的訂單，訂單對(duì)應(yīng)的支付記錄（支付寶、微信等）均屬于原始憑證。

因此，原始憑證的種類很多，如發(fā)貨單、收貨單、領(lǐng)料單、銀行結(jié)算憑證、各種報(bào)銷單據(jù)等在業(yè)務(wù)發(fā)生過程中產(chǎn)生的依據(jù)都算作原始憑證。

從對(duì)賬業(yè)務(wù)來說，涉及的憑證偏向于訂單、賬單、支付單等原始憑證。

2.4 記賬憑證

記賬憑證，會(huì)計(jì)專業(yè)術(shù)語，是財(cái)會(huì)部門根據(jù)原始憑證填制，記載經(jīng)濟(jì)業(yè)務(wù)簡(jiǎn)要內(nèi)容，確定會(huì)計(jì)分錄，作為記賬依據(jù)的會(huì)計(jì)憑證。記賬憑證亦稱分錄憑證，又稱記賬憑單，按照登記賬簿的要求、確定賬戶名稱、記賬方向（借貸方向）和金額的一種記錄，是登記明細(xì)分類賬和總分類賬的依據(jù)。

那會(huì)計(jì)分錄又是什么？

我們?nèi)粘Ｈ绻杏涃~的習(xí)慣的話，一般會(huì)這么記：

• 購(gòu)買商品：電腦，單價(jià)8000元，數(shù)量1臺(tái)
• 支付總額：8000元
• 支付方式：支付寶（招商銀行卡）

而，財(cái)務(wù)側(cè)在對(duì)原始憑證確認(rèn)后，記賬的方法叫做復(fù)式記賬法（借貸記賬法），其所記錄的內(nèi)容，叫做會(huì)計(jì)分錄，會(huì)計(jì)分錄基于復(fù)式記賬法有標(biāo)準(zhǔn)的格式。如：

• 借：庫(kù)存商品-電腦 8000元
• 貸：銀行存款-招行 8000元

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

即，在我所有的資產(chǎn)中，庫(kù)存商品增加了一臺(tái)電腦，但銀行存款減少了8000元。

如果購(gòu)買商品時(shí)，商戶開具了發(fā)票，在借方的分錄應(yīng)該是庫(kù)存商品-電腦不含稅價(jià)與稅金兩條記錄，這里就不細(xì)寫了。

因此，記賬憑證其實(shí)就是會(huì)計(jì)分錄，會(huì)計(jì)分錄就是財(cái)務(wù)人員的標(biāo)準(zhǔn)記賬方法。

記賬憑證是由會(huì)計(jì)人員對(duì)審核無誤的原始憑證或匯總原始憑證，按其經(jīng)濟(jì)業(yè)務(wù)的內(nèi)容加以歸類整理，作為登記賬簿依據(jù)的會(huì)計(jì)憑證。會(huì)計(jì)人員填制記賬憑證要嚴(yán)格按照規(guī)定的格式和內(nèi)容進(jìn)行。

專用記賬憑證，是指分類反映經(jīng)濟(jì)業(yè)務(wù)的記賬憑證。這種記賬憑證按其反映經(jīng)濟(jì)業(yè)務(wù)的內(nèi)容不同，又可以分為收款憑證、付款憑證和轉(zhuǎn)賬憑證。

在對(duì)賬系統(tǒng)中，對(duì)賬的整體動(dòng)作，其實(shí)相當(dāng)于財(cái)務(wù)人員對(duì)原始憑證的對(duì)比與審查，審查完成的記錄成會(huì)計(jì)分錄，最終生成明細(xì)賬（有多少訂單就有多少條明細(xì)）及匯總賬（無論多少條，只要在我計(jì)算的歸屬范圍內(nèi)的，統(tǒng)一匯總成一條）。

因此，對(duì)賬系統(tǒng)完成對(duì)賬后，會(huì)根據(jù)用戶實(shí)際訴求，生成明細(xì)賬及總分類賬，即記賬憑證。

2.5 單邊

在一對(duì)一對(duì)賬完成之后，發(fā)現(xiàn)某一條數(shù)據(jù)對(duì)應(yīng)的另一方無數(shù)據(jù)，一般稱為單邊。

比如有訂單信息，但無與訂單對(duì)應(yīng)的賬單數(shù)據(jù)，那么本次對(duì)賬差異稱為訂單單邊。

比如有賬單信息，但無與賬單對(duì)應(yīng)的訂單數(shù)據(jù)，那么本次對(duì)賬差異稱為賬單單邊。

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

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

公式金額等于0為平賬，金額等于本方金額為本方單邊，金額等于對(duì)方金額為對(duì)方單邊，金額大于零且小于本方金額或金額為負(fù)責(zé)默認(rèn)為金額不一致，屬于長(zhǎng)短款，需溯源查詢差異原因。

2.6 長(zhǎng)短款

財(cái)務(wù)側(cè)的現(xiàn)金長(zhǎng)短款是指在盤點(diǎn)和核對(duì)庫(kù)存現(xiàn)金時(shí)，發(fā)現(xiàn)除挪用現(xiàn)金、白條頂庫(kù)、超限額留存現(xiàn)金等情況以外原因的現(xiàn)金日記賬余額與庫(kù)存現(xiàn)金數(shù)額不符。在對(duì)賬系統(tǒng)中，一般代表應(yīng)收與實(shí)收不符（非單邊）。

對(duì)賬時(shí)，除了會(huì)發(fā)生2.5項(xiàng)所述單邊現(xiàn)象，也會(huì)存在長(zhǎng)短款現(xiàn)象。

• 長(zhǎng)款：應(yīng)收100元，實(shí)收120元，計(jì)算后，出現(xiàn)了20元的額外收益，這部分即為長(zhǎng)款。
• 短款：應(yīng)收120元，實(shí)收100元，計(jì)算后，少收20元，這部分即為短款。

2.7 軋（gá）差

軋差是指利用抵銷、合同更新等法律制度，最終取得一方對(duì)另一方的一個(gè)數(shù)額的凈債權(quán)或 凈債務(wù)，如市場(chǎng)交易者之間，可能互有內(nèi)容相同，方向相反的多筆交易，在結(jié)算或結(jié)束交易時(shí)，可以將各方債權(quán)在相等數(shù)額內(nèi)抵銷，僅支付余額。

上述為財(cái)務(wù)側(cè)軋差的概念，或許難以理解，但舉個(gè)例子就明白了：

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

在對(duì)賬系統(tǒng)中，軋差一般指的是兩兩之間金額匯總之后的總差額。

2.8 平賬與差異（差錯(cuò)）

這里的平賬是指對(duì)賬系統(tǒng)的對(duì)賬結(jié)果：對(duì)賬對(duì)平，而不是財(cái)務(wù)管理所說的讓各個(gè)分類賬戶的金額與其匯總賬戶的金額互相核算相等，達(dá)成會(huì)計(jì)中的所說的“賬賬相符”。

差異（差錯(cuò)）指的是未對(duì)平的數(shù)據(jù)。一般差異包括單邊、長(zhǎng)短款等。

差異的原因一般包括：

• 單邊，即本方或?qū)Ψ綗o數(shù)據(jù)；
• 長(zhǎng)短款，即本方與對(duì)方有數(shù)據(jù)，但對(duì)賬金額不一致。

單邊及長(zhǎng)短款可以依靠系統(tǒng)進(jìn)行初始預(yù)判斷，再人工復(fù)核；但長(zhǎng)短款的原因一般需要人工判斷及確認(rèn)。

2.9 財(cái)年財(cái)月

財(cái)年指財(cái)務(wù)年度，財(cái)月指財(cái)務(wù)月。

一般來說，我國(guó)的財(cái)年指的是自然年，財(cái)月指的是自然月。

國(guó)外的財(cái)年和財(cái)月有遵循自然年自然月的，也有跳出自然年與自然月單獨(dú)設(shè)定的，比如美國(guó)部分州，會(huì)將企業(yè)成立當(dāng)年的10月份定義為下一年的財(cái)年初始，10月份為下一財(cái)年第一個(gè)財(cái)月，且其財(cái)月并非自然月，而是以445標(biāo)準(zhǔn)執(zhí)行，即第一季度第一個(gè)財(cái)月是從10月1日起的四周，第二個(gè)財(cái)月為后續(xù)四周，第三個(gè)財(cái)月為再后續(xù)五周，所以每個(gè)財(cái)月都跨自然月。

一般我國(guó)國(guó)內(nèi)系統(tǒng)對(duì)應(yīng)的財(cái)年財(cái)月以自然年自然月為準(zhǔn)。

2.10 其他

只要涉及與財(cái)務(wù)相關(guān)的系統(tǒng)，絕對(duì)不允許對(duì)源數(shù)據(jù)（原始憑證）進(jìn)行任何修改。

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

本章2.3-2.8僅作基于對(duì)賬系統(tǒng)的簡(jiǎn)單描述，其在財(cái)務(wù)中所代表的含義相對(duì)較為復(fù)雜，個(gè)人建議應(yīng)該從財(cái)務(wù)的角度去豐富相關(guān)的知識(shí)。

同時(shí)，沒有財(cái)務(wù)基礎(chǔ)想走對(duì)賬或需要走對(duì)賬發(fā)展路線的，建議先惡補(bǔ)復(fù)式記賬法、資產(chǎn)負(fù)債表等；若有財(cái)務(wù)基礎(chǔ)的，忽略本篇財(cái)務(wù)基礎(chǔ)部分，當(dāng)然，若發(fā)現(xiàn)我有描述不當(dāng)?shù)?，還請(qǐng)不吝指出，我將請(qǐng)教確認(rèn)后進(jìn)行修改更新。

三、需求場(chǎng)景

某零售品牌2C業(yè)務(wù)擴(kuò)展迅速，對(duì)賬系統(tǒng)老舊，且人工干涉較多，原對(duì)賬中心已經(jīng)跟不上業(yè)務(wù)發(fā)展，需建設(shè)最新對(duì)賬中心。

3.1 現(xiàn)狀

• 法人A：負(fù)責(zé)自有渠道，包括APP、微信小程序、支付寶小程序；
• 法人B：負(fù)責(zé)三方渠道，包括京東、天貓、美團(tuán)、抖音；
• 支付方式：APP對(duì)接微信、支付寶、云閃付，以直連模式接入；
• 儲(chǔ)值卡：APP支持儲(chǔ)值卡支付，支持儲(chǔ)值卡+三方組合支付；
• 儲(chǔ)值卡賬戶：合規(guī)的單用途預(yù)付費(fèi)卡，消費(fèi)者儲(chǔ)值統(tǒng)一存入法人A管理賬戶，消費(fèi)者使用儲(chǔ)值消費(fèi)時(shí)，從法人A管理賬戶支付至門店/渠道賬戶；

3.2 建設(shè)目標(biāo)

搭建對(duì)賬系統(tǒng)，以三方賬單為本方，實(shí)現(xiàn)最小周期T+1的對(duì)賬，每財(cái)月月結(jié)輸出明細(xì)賬、匯總賬，匯總賬支持按法人、渠道維度進(jìn)行查詢，支持輸出匯總憑證，輸出月結(jié)報(bào)表；

• 當(dāng)業(yè)務(wù)渠道新增時(shí)，支持靈活配置化補(bǔ)充渠道信息，迅速接入對(duì)賬系統(tǒng)；
• 當(dāng)支付渠道新增時(shí)，支持靈活配置化補(bǔ)充渠道信息，迅速接入對(duì)賬系統(tǒng)；
• 支持訂單以文件形式導(dǎo)入；
• 支持賬單以文件形式導(dǎo)入；
• 支持賬務(wù)審核流程；
• 支持用戶權(quán)限管理及數(shù)據(jù)權(quán)限管理；
• 支持人工平賬。

3.3 數(shù)據(jù)關(guān)系

APP、微信小程序、支付寶小程序、京東、天貓、美團(tuán)、抖音各渠道統(tǒng)一通過訂單中心向?qū)~中心輸出訂單，其周期為D+1，即每日0點(diǎn)獲取前一日全部訂單，以接口形式獲取；

各支付渠道支付賬單需從各渠道下載導(dǎo)入對(duì)賬系統(tǒng)，其可支持下載周期為T+1。

3.4 其他說明

以上為基礎(chǔ)需求描述，在后續(xù)講解中若發(fā)現(xiàn)有遺漏的，在實(shí)際設(shè)計(jì)篇幅中進(jìn)行補(bǔ)充，同時(shí)會(huì)對(duì)本篇進(jìn)行優(yōu)化更新。

四、需求梳理

學(xué)習(xí)做產(chǎn)品時(shí)，總有人在你耳邊說，要想把產(chǎn)品做好，需要有自己的產(chǎn)品方法論。

什么是產(chǎn)品方法論？以需求梳理階段舉例，其實(shí)就是你去獲取、拆解、梳理、規(guī)整需求的方法、使用的工具或者步驟等。

我所常用的方法是從上往下看，通過總-分模式，先從大框架上了解整體業(yè)務(wù)目標(biāo)，再基于組成大框架的一個(gè)個(gè)小模塊，去分別拆解、梳理細(xì)節(jié)內(nèi)容。

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

以當(dāng)前需求為例，首先確認(rèn)清楚，我們要做什么？

做什么：做一套財(cái)務(wù)人員所需要的基于業(yè)務(wù)訂單與支付賬單的對(duì)賬系統(tǒng)，對(duì)賬完成后輸出財(cái)務(wù)人員所需的憑證及報(bào)表。

使用者、輸入、輸出、核心能力已經(jīng)很明確了。

• 使用者：財(cái)務(wù)人員；
• 輸入：業(yè)務(wù)訂單與支付賬單；
• 輸出：憑證及報(bào)表；
• 核心能力：基于訂單與賬單的對(duì)賬。

框架方向了解后，我們應(yīng)該怎么去梳理細(xì)節(jié)內(nèi)容呢？

從整個(gè)產(chǎn)品的維度思考，我們的用戶是財(cái)務(wù)人員，系統(tǒng)的屬性也是偏向于財(cái)務(wù)的，那么整體來說，我們系統(tǒng)中將包含很多的財(cái)務(wù)底層規(guī)則。

因此，如果在看同學(xué)沒有財(cái)務(wù)基礎(chǔ)的，或財(cái)務(wù)基礎(chǔ)很薄弱的，建議先閱讀第一篇。而財(cái)務(wù)知識(shí)很豐富的同學(xué)可以接著往下看。

我們已經(jīng)對(duì)框架熟悉了，也知道需要考慮財(cái)務(wù)規(guī)范，那么我們?cè)谛枨蟮牟鸾馀c梳理過程中，每一個(gè)步驟應(yīng)該把模塊功能和財(cái)務(wù)規(guī)范做有效的結(jié)合。

4.1 業(yè)務(wù)輸入

從第一篇模擬的業(yè)務(wù)需求來看，我們可以對(duì)獲得的信息進(jìn)行拆解：

法人： 是具有民事權(quán)利能力和民事行為能力，依法獨(dú)立享有民事權(quán)利和承擔(dān)民事義務(wù)的組織，是企業(yè)、公司的另一種稱呼。在本需求中，某集團(tuán)下有兩個(gè)分公司（法人），分別負(fù)責(zé)自有渠道（自行建設(shè)）和三方平臺(tái)渠道（外部合作渠道）的業(yè)務(wù)管理。

補(bǔ)充閱讀：一個(gè)公司就是一個(gè)法人，我們看到公司營(yíng)業(yè)執(zhí)照中有法人代表，一般該法人代表就是公司老板，法人代表的含義是，他代表這個(gè)公司，是該公司（法人）的代言人。

所以在上游原始數(shù)據(jù)可能存在多個(gè)歸屬時(shí)，應(yīng)著重考慮輸入的原始數(shù)據(jù)歸類問題。同時(shí)，在我們拿到這部分信息時(shí)，應(yīng)該意識(shí)到我們所設(shè)計(jì)的表結(jié)構(gòu)中，一定要有數(shù)據(jù)歸屬字段，如所屬法人、所屬渠道等。

從上表，我們已知需要從哪些法人及渠道獲取訂單數(shù)據(jù)，同時(shí)我們還應(yīng)該從需求方獲取相關(guān)的信息，包括但不限于：數(shù)據(jù)提供方式、提供周期、是否有統(tǒng)一訂單中心進(jìn)行處理等。

如果需求方當(dāng)前系統(tǒng)比較簡(jiǎn)單，沒有統(tǒng)一的訂單中心負(fù)責(zé)接入全部訂單信息，我們需要直接從三方拉取訂單，那么需要額外準(zhǔn)備與三方支持溝通的方式（釘釘群、微信群、企微群等），以便在需求梳理、數(shù)據(jù)傳輸確認(rèn)過程中及時(shí)溝通了解一些不清楚的地方。

一般來說，三方平臺(tái)都會(huì)有指定的支付方式，比如京東自有的京東支付、天貓的支付寶支付、抖音自有的抖音支付或微信/支付寶支付等；所以法人B負(fù)責(zé)的三方渠道部分我們不考慮支付功能接入。

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

同時(shí)，明確了接入模式為直連。

直連指的是APP直接與三方支付（如微信）對(duì)接，不通過聚合支付統(tǒng)一處理。而通過三方聚合支付（如隨心付、掃唄等）對(duì)接的一般屬于間連。

直連與間連各有優(yōu)劣，本文不涉及支付具體細(xì)節(jié)就不細(xì)講了，有想了解的朋友可以自行去了解一下支付相關(guān)的知識(shí)。

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

儲(chǔ)值第一要素是合規(guī)，除了企業(yè)自身需要去申請(qǐng)單用途預(yù)付費(fèi)卡資質(zhì)之外，同步需要與銀行簽訂監(jiān)管協(xié)議，儲(chǔ)值金額統(tǒng)一存入企業(yè)在該銀行的監(jiān)管賬戶中。

單用途預(yù)付費(fèi)卡主要分兩種，記名卡與不記名卡。兩者可儲(chǔ)值額度不同、有效期限制也不同，可以單獨(dú)去了解一下。

要點(diǎn)：所有人都應(yīng)該重視的是，消費(fèi)者儲(chǔ)值資金雖然在監(jiān)管銀行所設(shè)立的企業(yè)賬戶中，但這筆錢的所有權(quán)仍是消費(fèi)者，對(duì)于企業(yè)來說，這不是收入，而是負(fù)債，在資產(chǎn)負(fù)債表中屬于右側(cè)，在憑證中所體現(xiàn)的科目主要是預(yù)付費(fèi)或遞延收益。

這部分資金，只有消費(fèi)者在使用儲(chǔ)值消費(fèi)后，才能基于訂單支付信息從監(jiān)管賬戶劃入收入賬戶。

在本示例需求中，用戶使用儲(chǔ)值卡金額支付時(shí)，其訂單來源是法人A所屬業(yè)務(wù)渠道APP，賬單來源是法人A監(jiān)管銀行。

我們?cè)谶M(jìn)入4.1之前有講，必須考慮財(cái)務(wù)屬性，因此，除以上信息外，我們還需要補(bǔ)充財(cái)務(wù)相關(guān)信息，包括但不限于：

財(cái)年財(cái)月、稅金管理、會(huì)計(jì)科目等。

同時(shí)，輸入給系統(tǒng)的全部數(shù)據(jù)，需要區(qū)分主數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)。

主數(shù)據(jù)指的是能夠輔助系統(tǒng)功能的數(shù)據(jù)類型，包括法人、渠道門店、支付渠道、商品類型、活動(dòng)營(yíng)銷、財(cái)年財(cái)月、稅率管理、會(huì)計(jì)科目等，后續(xù)在產(chǎn)品設(shè)計(jì)過程中，配置的各種屬性如對(duì)賬規(guī)則、憑證規(guī)則等都算主數(shù)據(jù)范疇。

業(yè)務(wù)數(shù)據(jù)指的是需基于系統(tǒng)規(guī)則進(jìn)行對(duì)賬處理的數(shù)據(jù)，在本系統(tǒng)中，業(yè)務(wù)數(shù)據(jù)為訂單數(shù)據(jù)及賬單數(shù)據(jù)。

對(duì)賬完成輸出的會(huì)計(jì)憑證及報(bào)表數(shù)據(jù)，也屬于業(yè)務(wù)數(shù)據(jù)。

• 主數(shù)據(jù)的來源一般分為兩種，從上游系統(tǒng)同步或在自有系統(tǒng)創(chuàng)建。
• 業(yè)務(wù)數(shù)據(jù)來源一般也分兩種，從上游系統(tǒng)推送或通過文檔導(dǎo)入。

本小節(jié)拆解梳理完成后，可以形成如下導(dǎo)圖：

注：是否有OC或OMS提供訂單數(shù)據(jù)統(tǒng)一功能，應(yīng)根據(jù)實(shí)際項(xiàng)目情況進(jìn)行確認(rèn)。本文案例默認(rèn)有訂單中心統(tǒng)一管理兩個(gè)法人下全部渠道訂單數(shù)據(jù)。

從系統(tǒng)關(guān)系來思考，可以形成如下框圖：

在實(shí)際項(xiàng)目中，如果甲方（需求方）已有訂單與賬單中心可以統(tǒng)一管理并提供業(yè)務(wù)數(shù)據(jù)，那么直接與其對(duì)接獲取即可，若數(shù)據(jù)不能滿足對(duì)賬中心需求（缺核心字段、缺狀態(tài)等），則應(yīng)向?qū)~中心上游（訂單與賬單中心）提出需求即可。

特殊情況下，可能需要配合上游與上上游進(jìn)行少量溝通（以實(shí)際情況為準(zhǔn)）。

4.2 成果輸出

輸出的要求：以三方賬單為本方，實(shí)現(xiàn)最小周期T+1的對(duì)賬，每財(cái)月月結(jié)輸出明細(xì)賬、匯總賬，匯總賬支持按法人、渠道維度進(jìn)行查詢，支持輸出匯總憑證，輸出月結(jié)報(bào)表。

前文有講本方與對(duì)方的關(guān)系，在本示例需求里，要求本方為三方賬單，三方賬單即微信、支付寶、銀聯(lián)、京東、抖音等提供的支付記錄明細(xì)。從此需求也可以看出，用戶對(duì)市場(chǎng)上較大平臺(tái)的信任度較高（或許是目前自研系統(tǒng)財(cái)務(wù)訴求的一個(gè)常態(tài)）。

本條不算輸出需求，但屬于輸出成果時(shí)，重要的規(guī)則依據(jù)。

在很多的術(shù)語中，我們常見的有T+1、D+1、W+1、M+1，或者不僅僅是+1，而是+N。

+1指在當(dāng)天基礎(chǔ)上加一天，隔日的意思；+N指延長(zhǎng)的天數(shù)不確定，一般來說有這種需求的項(xiàng)目，N是支持可配置的，比如T+1、T+3等。

• T是Time，業(yè)務(wù)中表示工作日；
• D是Day，業(yè)務(wù)中表示自然日；
• W是Week，業(yè)務(wù)中表示一周；
• M是Month，業(yè)務(wù)中表示一個(gè)月，財(cái)務(wù)上用來表示財(cái)務(wù)月；

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

本周一的數(shù)據(jù)，本周二對(duì)賬；本周五的數(shù)據(jù)下周一對(duì)賬；本周六和本周日的數(shù)據(jù)也是下周一對(duì)賬。

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

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

需要按指定維度輸出明細(xì)結(jié)果、月結(jié)總賬以及會(huì)計(jì)憑證。

需要按照法人、渠道兩個(gè)層級(jí)維度查詢階段明細(xì)數(shù)據(jù)，并支持基于該兩層維度生成月結(jié)總報(bào)表及會(huì)計(jì)憑證。

如，渠道維度：

• 明細(xì)賬：法人A所屬APP渠道，2022年9月1日明細(xì)記錄共計(jì)1000條，其中對(duì)平980條，差異20條；該兩類數(shù)據(jù)分別在平賬明細(xì)與差異明細(xì)中查詢。
• 匯總賬：法人A所屬APP渠道對(duì)平明細(xì)980條，合計(jì)收入總額3萬元；差異中包含應(yīng)收未收、應(yīng)付未付，匯總軋差后，應(yīng)收未收200元。
• 月結(jié)匯總報(bào)表：法人A所屬APP渠道，2022年9月份對(duì)平共30000條，差異1200條。合計(jì)收入總額9萬元，應(yīng)收未收3800元，應(yīng)付未付1000元（其中商品退款500元，用戶補(bǔ)償500元）。

憑證信息（例）：

會(huì)計(jì)憑證1：

• 借：銀行存款-招行 90000元
• 貸：主營(yíng)業(yè)務(wù)收入-APP 79646.08元
• 貸：應(yīng)交稅費(fèi)-應(yīng)交增值稅-銷項(xiàng)稅 10353.92元

會(huì)計(jì)憑證2：

• 借：應(yīng)收賬款-APP 3800元
• 貸：主營(yíng)業(yè)務(wù)收入-APP 3362.93元
• 貸：應(yīng)交稅費(fèi)-應(yīng)交增值稅-銷項(xiàng)稅 437.17元

會(huì)計(jì)憑證4：（退款500元）

• 借：商品庫(kù)存-APP 500元
• 貸：銀行存款-招行 500元

會(huì)計(jì)憑證5：（用戶補(bǔ)償500元）

• 借：營(yíng)業(yè)外支出-APP 500元
• 貸：銀行存款-APP 500元

示例中同步體現(xiàn)了稅金與不含稅金額的分錄，默認(rèn)以商品銷售稅率13%為基準(zhǔn)進(jìn)行演示計(jì)算。

4.3 系統(tǒng)功能

輸入清晰、輸出明了。

那么，在功能設(shè)計(jì)上，也應(yīng)該著重從這三點(diǎn)考慮，分別對(duì)應(yīng)輸入、對(duì)賬、輸出。

4.3.1 輸入相關(guān)

與上游系統(tǒng)對(duì)接，包括主數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)系統(tǒng)，在對(duì)賬系統(tǒng)規(guī)劃導(dǎo)入數(shù)據(jù)規(guī)范、數(shù)據(jù)處理邏輯。

接收上游系統(tǒng)提供的主數(shù)據(jù)，包括渠道門店、商品分類、營(yíng)銷活動(dòng)等，支持渠道門店在系統(tǒng)中自行創(chuàng)建。

接收上游訂單中心推送的訂單、接收上游賬單中心推送的賬單、接收手動(dòng)導(dǎo)入的訂單及賬單。

對(duì)主數(shù)據(jù)日常/更新推送至系統(tǒng)的進(jìn)行完整性校驗(yàn)，考慮主數(shù)據(jù)的變更、重復(fù)、缺失字段等處理手段。

對(duì)訂單進(jìn)行完整性校驗(yàn)，包括去重、非空、狀態(tài)篩選、數(shù)據(jù)歸屬判斷及補(bǔ)充。

對(duì)賬單進(jìn)行完整性校驗(yàn)，包括去重、非空、數(shù)據(jù)歸屬判斷及補(bǔ)充。

對(duì)通過校驗(yàn)的訂單及賬單進(jìn)行字段結(jié)構(gòu)的格式統(tǒng)一，以便于后續(xù)對(duì)賬階段有效拉取相應(yīng)對(duì)賬數(shù)據(jù)。

對(duì)未通過校驗(yàn)的訂單、賬單、主數(shù)據(jù)進(jìn)行獨(dú)立展示、標(biāo)簽，建立處理規(guī)則。

4.3.2 對(duì)賬相關(guān)

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

那么，我們可以從事務(wù)處理的維度去思考功能的規(guī)劃設(shè)計(jì)，事前、事中、事后。

事前：事前主要分兩部分，第一部分為輸入對(duì)接，第二部分為輸入處理，這兩點(diǎn)在4.3.1已梳理。

在對(duì)賬模塊中，事前還包括從規(guī)范后的數(shù)據(jù)表中拉取對(duì)賬數(shù)據(jù)；

事中：指的是對(duì)賬過程中對(duì)賬的功能及邏輯，這里是整個(gè)對(duì)賬模塊最復(fù)雜的部分，會(huì)涉及到對(duì)賬任務(wù)、對(duì)賬組別、對(duì)賬批次、對(duì)賬類型、多次對(duì)賬、差異對(duì)賬，甚至是對(duì)賬回退等；

事后：指對(duì)賬完成后的處理，包括差異分析、差異處理，輸出最終結(jié)果等。

在事后階段輸出最終報(bào)表成果時(shí)，表中展示含稅總價(jià)、未稅總價(jià)、稅金總額，其中稅金相關(guān)計(jì)算公式如下：

含稅單價(jià)＝未稅單價(jià)＊稅率（1+13%）

未稅單價(jià)＝含稅單價(jià)／稅率（1+13%）

稅金=未稅單價(jià)＊稅率（13%）

4.3.3 輸出相關(guān)

對(duì)賬完成后，依據(jù)財(cái)務(wù)側(cè)需求，需要輸出對(duì)賬結(jié)果，包括明細(xì)表單、匯總表單、會(huì)計(jì)憑證。

4.2部分示例描述了輸出成果內(nèi)容，本節(jié)主要講述通過何種邏輯規(guī)則輸出所需成果內(nèi)容。

從需求描述來說，可分兩個(gè)階段的輸出，分別是日常對(duì)賬階段與月結(jié)階段。

日常對(duì)賬階段，需要輸出對(duì)賬結(jié)果、差異分析。

對(duì)賬結(jié)果邏輯在對(duì)賬規(guī)則中體現(xiàn)，差異分析邏輯在差異分析規(guī)則中體現(xiàn)。同時(shí)，差異分析因?yàn)樯婕暗较到y(tǒng)與人工處理的雙重邏輯，所以需要有獨(dú)立的差異處理邏輯。以上兩點(diǎn)，均需要支持將成果導(dǎo)出文檔，一般是Excel格式，這部分需要預(yù)設(shè)表格字段規(guī)則。

月結(jié)階段成果包含月結(jié)明細(xì)報(bào)表、匯總報(bào)表、會(huì)計(jì)憑證。

明細(xì)報(bào)表來源于日常對(duì)賬明細(xì)一致，其取值邏輯與導(dǎo)出表格規(guī)則一致即可；

匯總報(bào)表應(yīng)基于財(cái)務(wù)需求，預(yù)設(shè)多報(bào)表字段及計(jì)算規(guī)則，如基于法人的匯總、基于渠道的匯總、基于商品類型的匯總等；

會(huì)計(jì)憑證需要根據(jù)財(cái)務(wù)側(cè)需求，支持可配置憑證格式，配置憑證內(nèi)容取值，需要有借貸平衡相關(guān)的財(cái)務(wù)校驗(yàn)邏輯等。

五、方案設(shè)計(jì)

無論什么行業(yè)，嘗試總分模式/先框架后細(xì)節(jié)的結(jié)構(gòu)化做事方法其實(shí)是很多人形成自我方法論雛形的過程。除了需求階段我們使用總-分模式進(jìn)行梳理之外，在方案設(shè)計(jì)階段，這種方法依舊好用。

1. 總：考慮清楚整體的業(yè)務(wù)結(jié)構(gòu)（或功能結(jié)構(gòu)），理清楚需要哪些大模塊來組成目標(biāo)系統(tǒng)。
2. 分：在各個(gè)模塊中填入子模塊及關(guān)鍵能力。

最終的結(jié)果需要達(dá)到：大能統(tǒng)察全局、合規(guī)合法、業(yè)務(wù)正確、冗余有度，小能功能具象、細(xì)節(jié)合理、流程清晰、落地可行。

這樣輸出的內(nèi)容，在項(xiàng)目團(tuán)隊(duì)中，即可向上戰(zhàn)略，又可平行溝通，還可向下賦能。

因此，在本次的第五大部分，我們從兩個(gè)維度進(jìn)行闡述：

1. 總：系統(tǒng)框架設(shè)計(jì)
2. 分：系統(tǒng)各功能模塊設(shè)計(jì)

5.1 系統(tǒng)框架

5.1.1 系統(tǒng)主要組成部分

系統(tǒng)的框架不是憑空而來，而是基于對(duì)需求的透徹理解，對(duì)所設(shè)計(jì)出來的各個(gè)功能組件的有效融合，整個(gè)系統(tǒng)中，各功能組件都有各自不可或缺的作用，且盡可能保持功能的獨(dú)立性（涉及解耦的不在這里講）。

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

基于此，我們從業(yè)務(wù)維度考慮，可以進(jìn)行如下設(shè)計(jì)參考（包括但不限于）：

• 對(duì)接外部輸入，以有效接收主數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)，暫定為數(shù)據(jù)獲取模塊；
• 數(shù)據(jù)獲取后，進(jìn)行有效的歸類、驗(yàn)證、格式統(tǒng)一，以支持對(duì)賬處理，暫定為數(shù)據(jù)準(zhǔn)備模塊；
• 數(shù)據(jù)準(zhǔn)備完畢后，基于各種規(guī)則進(jìn)行對(duì)賬，需要獨(dú)立的對(duì)賬引擎模塊；
• 對(duì)賬完成后，結(jié)果輸出，除了對(duì)平部分結(jié)果，差異需要分析及人工判斷，需要差異處理模塊；
• 差異處理后匯總對(duì)賬結(jié)果，需要輸出憑證及報(bào)表，需要憑證規(guī)則模塊、報(bào)表邏輯模塊；
• 憑證與報(bào)表需要審核驗(yàn)證流程，需要業(yè)務(wù)審核模塊；
• 憑證與報(bào)表展示需要憑證管理與報(bào)表管理模塊；
• 系統(tǒng)需要進(jìn)行用戶管理、主數(shù)據(jù)管理、規(guī)則管理、權(quán)限管理等系統(tǒng)配置模塊。

5.1.1.1 數(shù)據(jù)獲取

數(shù)據(jù)獲取模塊分別對(duì)接外部業(yè)務(wù)數(shù)據(jù)系統(tǒng)、主數(shù)據(jù)系統(tǒng)，獲得外部系統(tǒng)推送的相關(guān)數(shù)據(jù)，同時(shí)為了提高對(duì)賬系統(tǒng)的數(shù)據(jù)獲取的靈活性，增加文檔導(dǎo)入功能。

5.1.1.2 數(shù)據(jù)準(zhǔn)備

數(shù)據(jù)準(zhǔn)備階段，需要對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行歸類、校驗(yàn)，補(bǔ)充主要字段，如財(cái)月信息等，訂單數(shù)據(jù)需篩選出可用來對(duì)賬的狀態(tài)。

無論是訂單或賬單數(shù)據(jù)，無論其來源屬性，最終字段格式會(huì)在本流程模塊中進(jìn)行最終統(tǒng)一，以便于對(duì)賬引擎面對(duì)的永遠(yuǎn)是“標(biāo)準(zhǔn)”且統(tǒng)一的數(shù)據(jù)格式。

5.1.1.3 對(duì)賬引擎

對(duì)賬引擎作為對(duì)賬系統(tǒng)最核心的模塊能力，其在設(shè)計(jì)時(shí)需要考慮數(shù)據(jù)拉取、規(guī)則匹配、對(duì)賬取值、批次分配、差異對(duì)賬、結(jié)果輸出等正向流程之外，同時(shí)需要考慮特殊場(chǎng)景產(chǎn)生的逆向流程，如任務(wù)撤銷引起的對(duì)賬回退，已對(duì)賬數(shù)據(jù)的歷史版本恢復(fù)等。

5.1.1.4 差異處理

對(duì)賬結(jié)果一般分別對(duì)平與差異（差錯(cuò)）兩種，簡(jiǎn)單的差異可以通過系統(tǒng)預(yù)設(shè)邏輯進(jìn)行預(yù)判斷（如單邊），人工二次驗(yàn)證確認(rèn)即可，該做法可有效減少財(cái)務(wù)人員工作量，提高效率，而特殊差異，如金額不一致的，無法預(yù)判斷的，則需要人工判斷差異并確認(rèn)。

人工判斷處理流程中，應(yīng)包含人工平賬規(guī)則。

5.1.1.5 憑證處理

基于指定周期的對(duì)平數(shù)據(jù)、處理完成的差異數(shù)據(jù)（最新），拉取憑證生成規(guī)則生成所需的財(cái)務(wù)憑證。

憑證生成完畢應(yīng)由財(cái)務(wù)人員基于審核流程進(jìn)行審核。

5.1.1.6 報(bào)表輸出

報(bào)表與憑證的設(shè)計(jì)邏輯相對(duì)一致，均是從對(duì)賬結(jié)果獲取數(shù)據(jù)后依據(jù)模塊規(guī)則生成結(jié)果。

報(bào)表在系統(tǒng)中有兩個(gè)流程位置的可能，第一種與憑證平行，雙方取值來源一致，分別生成憑證與報(bào)表，且可基于勾稽關(guān)系互相可以驗(yàn)證數(shù)據(jù)的準(zhǔn)確性；第二種則是基于對(duì)賬結(jié)果先生成報(bào)表，再直接從報(bào)表中取值生成憑證。

此兩種做法應(yīng)以實(shí)際業(yè)務(wù)需求為準(zhǔn)。

5.1.1.7 系統(tǒng)配置

本次系統(tǒng)設(shè)計(jì)中，法人、業(yè)務(wù)渠道、支付渠道、財(cái)務(wù)主數(shù)據(jù)、對(duì)賬規(guī)則等都?xì)w屬于系統(tǒng)配置模塊，但因其在整個(gè)系統(tǒng)主線流程中各有交叉，在前幾項(xiàng)中也有所展示，故本項(xiàng)圖片中僅展示非業(yè)務(wù)配置項(xiàng)。

5.1.2 系統(tǒng)框架

在實(shí)際設(shè)計(jì)產(chǎn)品時(shí)，總有人會(huì)說，什么總-分模式都是扯淡，當(dāng)沒有能力將需求轉(zhuǎn)換為功能的時(shí)，很難去規(guī)劃出產(chǎn)品的【總】。

說的對(duì)。

所以，5.1.1其實(shí)就是在將需求轉(zhuǎn)換為功能模塊，在補(bǔ)充規(guī)劃【總】之前的積累。

題外話：為什么說方法論是學(xué)不到，而是需要自我的經(jīng)驗(yàn)、學(xué)習(xí)、踩坑等各種經(jīng)歷積累梳理后的成果？

你沒有從微小到大框架循序漸進(jìn)思考、成長(zhǎng)的過程，又如何能夠迅速形成自我思維模式，再反向從框架到細(xì)節(jié)去剖析？

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

積累、學(xué)習(xí)、提升，從細(xì)小功能到子模塊到主模塊到系統(tǒng)到產(chǎn)品戰(zhàn)略，當(dāng)你在摸爬滾打N久后，自我梳理后，你面對(duì)新的需求、新的挑戰(zhàn)時(shí)，你的腦子里瞬間閃過了無數(shù)的畫面及可能，思考1秒或者2秒，你大方向的解決方案其實(shí)就出來了，再仔細(xì)思考一番后，核心流程也能梳理出來，這個(gè)時(shí)候，你會(huì)一點(diǎn)點(diǎn)去跟對(duì)方（需求方）確認(rèn)這是否就是對(duì)方所要達(dá)成的目標(biāo)。

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

5.1.2.1 系統(tǒng)總框圖

總框圖體現(xiàn)的是業(yè)務(wù)結(jié)構(gòu)，包含了需要設(shè)計(jì)的系統(tǒng)組件結(jié)構(gòu)與外部輸入或輸出的關(guān)聯(lián)關(guān)系。

在整個(gè)系統(tǒng)設(shè)計(jì)中，總框圖是劃定主線、刻畫核心能力、體現(xiàn)模塊依賴關(guān)系的重要藍(lán)圖。所以，總框圖的繪制要點(diǎn)是模塊獨(dú)立、相互依賴、全而不細(xì)、路徑準(zhǔn)確、組成清晰。

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

橙色框線內(nèi)，除系統(tǒng)設(shè)置外，主要區(qū)分了量大模塊組合，分別為數(shù)據(jù)處理相關(guān)與對(duì)賬處理相關(guān)。數(shù)據(jù)處理業(yè)務(wù)流程基于橙色箭頭所示，從獲取到處理屬于單向業(yè)務(wù)流；對(duì)賬處理中，對(duì)賬引擎為處理主模塊，基于結(jié)果分別輸出憑證與報(bào)表。

紅色箭頭的定義：對(duì)賬中心可以拆分為兩個(gè)系統(tǒng)，分別為對(duì)賬處理系統(tǒng)（紅色箭頭上方部分）與數(shù)據(jù)處理系統(tǒng)（紅色箭頭下方部分），部分公司因業(yè)務(wù)因素，需要獨(dú)立處理大量數(shù)據(jù)，包括訂單、賬單、活動(dòng)、營(yíng)銷等，其已有或計(jì)劃或正在實(shí)施數(shù)據(jù)中臺(tái)，對(duì)賬處理系統(tǒng)所需的可對(duì)賬數(shù)據(jù)，將由該數(shù)據(jù)中臺(tái)統(tǒng)一處理（處理后的數(shù)據(jù)除了推送對(duì)賬，也會(huì)推送至BI或成本核算等系統(tǒng)）。

也有部分公司，處于財(cái)務(wù)獨(dú)立性的考慮，會(huì)將數(shù)據(jù)處理與對(duì)賬處理合并為一套整系統(tǒng)進(jìn)行規(guī)劃。

在實(shí)際產(chǎn)品規(guī)劃過程中，應(yīng)著重考慮以上因素。

5.1.2.2 對(duì)賬主流程

流程圖中，體現(xiàn)了幾個(gè)重要的節(jié)點(diǎn)或數(shù)據(jù)：橙色部分標(biāo)明，每次對(duì)賬應(yīng)將對(duì)賬數(shù)據(jù)進(jìn)行凍結(jié)；淺紅色部分差異處理邏輯比較重要；中紅色部分特殊標(biāo)明凍結(jié)本財(cái)月，指的是從本節(jié)點(diǎn)往后生成財(cái)月報(bào)表及財(cái)月憑證邏的輯，其成果輸出一般每財(cái)月處理一次（月結(jié)、季結(jié)、年度總結(jié)等）。

5.1.3 依賴關(guān)系

5.1.3.1 系統(tǒng)間依賴

我們從總框圖中已經(jīng)可以看到，從系統(tǒng)關(guān)聯(lián)維度考慮，包括上游輸入系統(tǒng)、對(duì)賬系統(tǒng)、下游輸出系統(tǒng)，三個(gè)系統(tǒng)組成整體的業(yè)務(wù)流程，這三個(gè)系統(tǒng)之間存在著強(qiáng)依賴關(guān)系：

對(duì)賬系統(tǒng)依賴上游輸入系統(tǒng)提供的數(shù)據(jù)源；

下游輸出系統(tǒng)依賴對(duì)賬系統(tǒng)提供的對(duì)賬結(jié)果數(shù)據(jù)。

其所形成的業(yè)務(wù)鏈如下，且不可逆、不可空缺。

5.1.3.2 功能組件依賴

在總框圖及主流程圖中，我們不難看出，對(duì)賬系統(tǒng)核心組件主要包括數(shù)據(jù)獲取、數(shù)據(jù)準(zhǔn)備、對(duì)賬引擎、結(jié)果處理、業(yè)務(wù)輸出；其業(yè)務(wù)關(guān)系如展示順序，業(yè)務(wù)不可逆不可缺。

其中，設(shè)計(jì)的規(guī)則部分雖然獨(dú)屬于系統(tǒng)設(shè)置模塊，但其目的亦是為以上業(yè)務(wù)組件服務(wù)，可以拆解到五大核心中。

從圖中也可以看出，整個(gè)對(duì)賬系統(tǒng)組件關(guān)系也可以基于業(yè)務(wù)有效區(qū)分事前、事中、事后。與我們前面所講的產(chǎn)品階段思考維度又有重疊。

因此，在做產(chǎn)品設(shè)計(jì)階段，我們應(yīng)該從多維度去剖析，互相驗(yàn)證，以保證設(shè)計(jì)成果的準(zhǔn)確性、可行性。

注：以上部分圖片來自互聯(lián)網(wǎng)，如有侵權(quán)請(qǐng)私聊告知?jiǎng)h除，謝謝！