一、先分清兩種數(shù)據(jù)結構：樹和網(wǎng)

做分銷系統(tǒng)的團隊，第一反應通常是把層級建成一棵樹：平臺是根，下面是各級代理，每個節(jié)點掛一個parent_id。這種結構適合"傭金從平臺往下派發(fā)"的模式，但不適合"每一級自己賺差價"的批發(fā)模式。

差別在于：樹結構里，錢的源頭是平臺；網(wǎng)結構里，錢的源頭是終端消費者，每一級只是貨物的一個流轉(zhuǎn)環(huán)節(jié)，各自與上下游發(fā)生獨立的買賣關系。

工程上的直接后果是，賬務主體從"一個平臺賬戶"變成"N個兩兩之間的應收應付"。團長對消費者是零售應收，團長對上級是采購應付；小批發(fā)對團長是批發(fā)應收，對中批發(fā)是采購應付。每一級都是一個獨立的經(jīng)營主體，平臺不在鏈條中間，只在Zui上端與總代發(fā)生公對公結算。

這個建模如果一開始做錯，后面所有的對賬、開票、稅務都會連鎖出錯。

二、價差截留：賬務上怎么記

價差不是"平臺發(fā)給你一筆傭金"，而是"你賣出價比你進貨價高出來的部分"。

賬務上的標準記法是：每一級確認銷售收入（向下游的售價）和采購成本（向上游的進價），毛利即價差。比如零售價75、向上級進貨 71，這一級確認收入 75、成本 71、毛利 4。它不需要平臺做任何"分傭計算"，平臺也不需要知道這 4塊錢怎么分——因為這一級本來就是一個獨立經(jīng)營主體。

這一點在系統(tǒng)實現(xiàn)上意味著：結算引擎的核心不是"分傭算法"，而是"價差核算+逐級應收應付" 。前者依賴平臺持有資金，后者依賴每一級真實的購銷憑證。前者一旦被認定平臺在分錢，性質(zhì)就變了；后者天然自帶購銷合同和發(fā)票。

三、資金路由：平臺不進 C 端路徑

系統(tǒng)設計上Zui關鍵的約束是：消費者的付款不能進入平臺賬戶。

具體實現(xiàn)是：C端支付直接結算到團長（個人收款碼或小微商戶），團長把貨款支付給上級批發(fā)商，逐級向上，平臺只與總代發(fā)生對公收款。平臺側(cè)系統(tǒng)記錄的不是"代收資金"，而是"訂單與貨物在各級之間的流轉(zhuǎn)記錄"。

這帶來一個技術難點：平臺要能看到全鏈路的訂單和資金動作，但不能碰資金。做法是"記錄與執(zhí)行分離"——每一級在自己的收款渠道完成收付，同時把訂單號、金額、時間回傳平臺，平臺只做歸集、核對、生成對賬單和發(fā)票信息。

接口設計上要有三個明確的能力：訂單逐級回傳（含上級確認收貨）、資金動作登記（不代收，只登記流水號）、異常掛起與人工介入（金額不符、超時未付、退貨沖銷）。

四、四流合一：對賬結構的核心

合同流、資金流、發(fā)票流、貨物流，四者必須能一一對應。系統(tǒng)上對應四張核心表：購銷合同/訂單表（含上下游主體、SKU、數(shù)量、單價、金額）、資金流水表（含付款方、收款方、金額、渠道流水號、對應訂單）、發(fā)票表（含開票主體、票號、金額、對應訂單）、物流表（含發(fā)貨倉、運單號、收貨人、對應訂單）。

對賬邏輯按"逐級、逐單"跑：一筆終端訂單，向上可以追溯每一級的購銷記錄，向下可以追溯物流軌跡。任何一個環(huán)節(jié)缺失（有訂單無付款、有付款無發(fā)票、有發(fā)票無物流），都進入差異池并告警。

這套結構的價值在于：一旦需要向監(jiān)管或稅務說明業(yè)務實質(zhì)，拿出來的不是一句"我們只有五級"，而是一整套可逐單核驗的貿(mào)易記錄。這也是為什么"四流合一"不是財務部門的加分項，而是系統(tǒng)架構的一等公民。

五、云倉與結算解耦

多級批發(fā)容易讓人誤解為貨物要層層轉(zhuǎn)運。實際做法是：貨在中心倉，統(tǒng)一質(zhì)檢、統(tǒng)一一件代發(fā)，直接寄到終端買家；各級之間只是結算關系，不是物理轉(zhuǎn)運關系。

系統(tǒng)上必須把三條線拆開：資金線（逐級向上）、信息線（訂單逐級回傳確認）、物流線（云倉直發(fā)終端）。三者用訂單號關聯(lián)，但不要求物理一致。這樣設計的好處是：既避免了層層轉(zhuǎn)運的損耗和時效損失，又保證了每一筆資金背后都有真實的物流軌跡——沒有"只收錢不發(fā)貨"的空轉(zhuǎn)空間。

技術要點是庫存歸屬：云倉庫存屬于平臺或總代，各級批發(fā)商是"虛擬庫存"（可售額度），下單時凍結額度、云倉實際扣減實物庫存。虛擬庫存與實際庫存的同步延遲，是這類系統(tǒng)Zui常見的超賣來源，必須用額度預占+ 定期校準解決。

六、計酬算法：分母是貨不是人

如果激勵按"團隊人數(shù)"計算，系統(tǒng)里就必然出現(xiàn)"層級樹 + 人頭計數(shù)"的字段；如果按"出貨量"計算，字段就是"訂單 + 金額 +團隊聚合銷量"。

后者的實現(xiàn)是：晉升條件判定函數(shù)只讀取團隊的歷史出貨數(shù)據(jù)（按周期匯總的實際銷售額、活躍下級數(shù)、退貨率），不讀取"拉新人數(shù)"或"繳費人數(shù)"。計酬發(fā)放只與訂單掛鉤，沒有訂單就沒有任何收益。

這條規(guī)則寫進代碼，比寫進制度更重要，因為制度可以被臨時繞過，代碼不會。

七、為什么后補等于重構

很多團隊先上線一個"帶層級分傭"的商城模板，等流水做大再改。這時會遇到三個死結：底層寫死了"資金進平臺公戶再派發(fā)"，改要動支付路由、賬務、對賬三條主鏈；沒有預留公對公開票的主體和字段，財務無法合規(guī)出票；歷史訂單的賬務結構不匹配新模型，遷移等于重建。

正確的順序是：先定交易結構（誰是賣方、錢怎么走、票怎么開），再定數(shù)據(jù)模型，Zui后才寫業(yè)務功能。價差表一周可抄，結算底座要按季度設計。