網上關于刷卡機怎么清算余額的刷卡知識比較多，也有關于刷卡機怎么清算余額的問題，今天第一pos網(www.xingyun520.com)為大家整理刷卡常見知識，未來的我們終成一代卡神。

本文目錄一覽：

1、刷卡機怎么清算余額

刷卡機怎么清算余額

不同角色在產品各端的操作及整個流轉環節的單據生成和關系是怎么樣的呢？本文作者以一次外賣的業務流程為例，從用戶層到內部業務層進行分析，一起來看一下吧。

說清楚一件事容易，但是說清楚一個體系難；難不代表說不清楚，我們將承接一張小票看透清結算（上）

我們重點講了很多計費的邏輯和流程，下我們將重點講不同角色在產品的各端的操作以及整個流轉環節的單據生成和關系；這兩篇文章放到一起看，信息會更全面和完整。

大家對外賣都很熟悉，因為基本每天都會點外賣，所以像（上）一樣，我們依然以外賣場景為例，分析外賣交易全鏈路；從用戶層的“用戶下單，商家接單，分配騎手，騎手取餐，配送，用戶取餐”到內部業務層的“訂單，計價，配送，清分，記賬，結算，付款”等方面講清楚每個環節的邏輯和內容。

01 一次外賣的業務流程

一次外賣體驗會涉及到非常多的參與者以及過程，每個參與者都有自己的一個子流程，這些子流程共同串起了整個外賣交易的復雜流程體系，這個流程里涉及到了每個角色的行為。

比如：

用戶選品、下單、支付、取餐、評價商家的接單、制作騎手的接單、到店、取餐、配送、確認送達平臺的訂單創建，計價計費、支付提交、分配騎手、記賬結算

我們將這些不同角色、不同行為、不同節點所形成的一個復雜的流程繪制成下圖，便于我們動態地審視整個交易鏈條的全部事件；這也有利于后續我們去設計抽象清結算的業務節點。

02 搞清楚這些單據

上面說的過程中會產生很多的單據，每類單據會給到不同的參與者，每類單據記載著不同的但又相互關聯的信息，我們要了解這些主要的單據，并知道其用途、關聯關系和設計方法。

用戶訂單，作為外賣的發起者，用戶的外賣訂單信息記錄了購買的商品、商品價格、優惠信息、支付信息、配送信息、商家信息等全部內容，這個信息是外賣平臺給用戶提供的交易信息。

商家小票，我們收到餐以后餐盒上都會附帶一個紙質小票，也記載著該單商品的基本信息，這個信息是商家給用戶提供的商品和服務內容以及收費情況。

商家賬單，外賣平臺給商家提供在平臺上的經營數據，賣了多少餐，掙了多少錢，給商家付了多少款的信息。

騎手賬單，外賣平臺給騎手提供的其在平臺的服務信息，包括訂單信息，收入信息，獎懲信息，付款情況內容。

內部單據，而外賣平臺自己內部存在著眾多業務系統，這些系統共同協同完成這行個外賣業務，像訂單系統記錄訂單，計費系統記錄計費結果，賬務系統記錄賬務信息等，這些系統依賴各種單據完成記錄工作，以及通過各種單據相關鏈接傳遞信息。

我們將各角色，各類單據，各系統之間的關系用下面的結構表示：

清楚了外賣的全流程，以及流程中涉及到的單據以后，我們再看，每個環節都是什么樣的邏輯，相關單據是如何產生的，單據的具體內容是什么。

03 用戶下單

用戶下單是一次外賣旅程的開始，我們對這個過程再熟悉不過了，就不過多贅述。

用戶選擇商品，我們假設購買了如下的菜品，本次下單享受的優惠，要支付的信息等，為了便于分析我們讓訂單更加簡單一些，但是其所涉及到的面是完整的；用戶看到的訂單信息如下：

對于一個訂單首先我們要支付其商品有哪些，買了多少數量。

營銷優惠，選購了商品以后我們需要知道這一單在這些商品情況下會有什么活動，有多少優惠，本單有如下優惠：

我們再把優惠信息增加到表格中得到了如下的信息，該訂單的優惠比較簡單，都是針對整單的優惠，沒有針對單品的優惠，未來完整起見我們將單品優惠也放進去，只不過優惠金額為0。

交易計價，該過程是要計算出用戶下的這一單應該付多少錢，這個計價包含很多內容，比如計算優惠，計算商品總價，計算配送費，結算優惠后的訂單金額，計算用戶應付金額等，計算完成以后反饋給交易。

對于我們例子中的訂單的計價是比較簡單的，日常我們點的外賣有時候會非常復雜，那么計價過程也相對復雜很多，只不過無論復雜與簡單，原理都是一樣的；我們將計價結果記錄到表格中：

用戶完成了訂單的填寫和提交，內部系統完成了交易的計價，此時交易系統請求訂單系統完成訂單的創建，下一步用戶就可以進行支付了。

04 用戶支付

從上面我們知道用戶應付金額是47.6，整個支付過程的起點是用戶點擊去支付，然后跳轉到收銀臺，這個過程我們在收銀臺設計設計方法中介紹的比較清楚，這里就不詳細說明了。

05 商家接單制作

用戶支付成功以后商家在其后臺就可以看到該筆訂單，然后選擇接單，進行菜品的制作和打包；以下信息不是我們案例中訂單的信息，大家可以腦補一下本單信息填充到以下的商家賬單信息中即可；賬單中展示了商品信息和數量，打包費，優惠信息以及優惠的承擔方。

06 騎手配送

一個訂單可以平臺分配給騎手，也可以騎手自己搶單，有很多中方式；這里關于運力的調度和策略不過多贅述，不是本文的重點。

騎手在騎手端可以看到附近用戶下的全部訂單并可以做出決策要不要槍這一單，對于騎手來說距離越短，掙得越多，肯定就越喜歡。

覺得這一單的配送費很高，還有獎勵活動，那么點進去看一看，從地圖里可以看出這一單的店鋪在哪要配送到哪里，肯定是越近越好，目的地的單量越多越好。

同樣騎手可以看到這一單涉及到的菜品信息，詳細的配送費信息等內容，便于騎手做要不要搶單的決策。

騎手搶了訂單就去店里取餐吧，用戶也可以看到騎手的實時位置和配送狀態，這樣可以極大地緩解用戶等待的焦慮。

07 管控業務

整個訂單過程中會存在各種的事務，比如用戶把訂單取消了，商家拒單了，騎手拒單改派了，騎手把用戶的餐弄丟了等等，都需要進行一個判責，是誰的責任，要不要罰錢，封禁等。

用戶下了單，商家制作了餐，騎手完成了配送，用戶完成了評價，訂單就正式完結了。

整個訂單過程中，發生了突發事件被管控，以及訂單完結以后，每個環節都可能需要記賬，而有些記賬業務之前需要完成計費和清分，比如完單以后商家傭金的計算，過程中騎手獎懲的計算，商家的結算收入，騎手的結算收入等業務，以下部分便進入了清結算范疇。

08 費用項體系

業務在發生的過程中不同的節點，不同的用戶，不同的菜品或者活動都會產生各種不同的費用，該費用是業務層信息到賬務層信息轉換的非常關鍵的要素，比如商家賣了一些菜品，這些菜品就是商家的菜品收入；平臺為商家提供的交易撮合平臺和配送服務，所以平臺也會收取商家的傭金，這樣就需要一個傭金的費用。

同樣財務需要基于業務做會計記賬，那么不能直接以業務數據入賬，而是以費用視角入賬，比如抽商家的傭金記為“平臺收入”。

這樣我們就形成了一個費用體系，業務的新增和變化，都需要針對性的建立新的費用，每個費用也就有了其依賴的業務場景，就如我們的工資一樣；而針對這一單外賣來說我們會用到如下的費用：

09 清分計費

業務完成以后或者過程當中我們要進行計費，其實在交易計價環節已經完成了一些費用的計算，比如用戶實付金額，這也是資金記賬的依據。

計費的邏輯和流程我們在清算系統設計方法中介紹的非常詳細這里就不在贅述了，總之通過計費以后我們就獲得了所有費用的金額。

這里我們約定商家的抽傭為20%，這里我們按照菜品原價進行抽傭：2007商家傭金=54.6*20%=10.92。

整個計費結果如下：

10 記賬場景定義

我們知道記賬是在整個交易過程中分多次記錄的，用戶支付成功以后要記賬，商家接單以后要記賬，騎手搶單以后要記賬，完單以后要記賬；這樣我們就需要跟業務層約定業務場景的識別，而業務場景就對應了記賬的場景。

我們根據業務的發生流程，這里應該包含正向及逆向，訂單類，管控類，獎懲類等場景，只不過我們本文不涉及逆向過程，大家可以自己思考逆向的過程。

在外賣場景里我們可以將業務劃分成這樣的場景并給與定義，并且我們要約定好用什么信息去判定該場景已經發生，比如可以用訂單狀態，工單流轉等進行定義。

11 場景發生與記賬設定

定義好了業務場景以及費用，那么我們就需要設定什么場景發生了需要記什么費用，這些費用要記哪些賬，因為一個費用的發生不一樣只記一筆，而是要計入多個賬戶，我們需要設定每個類場景要記什么賬。

當然每個場景發生以后記那些賬不僅僅由訂單狀態這個場景決定，還需要其他要素參與，比如01支付成功，我們還需要知道這個是什么類型的訂單，另外需要不需關注渠道，因為不同渠道的訂單可能需要記跟渠道的分成。

12 記賬交互

業務場景發生以后，后端清分系統需要知道業務發生了，這里需要一個交互信息的方式，可以通過MQ的手段，比如訂單支付成功了，訂單層就發一個MQ，清分系統監聽到該MQ以后通過訂單狀態字段判斷訂單狀態，如果是“01”怎知道這是“01用戶支付”成功發生了。

如果說該MQ里包含了記賬需要的全部金額那么可以以MQ為依據生成業務單據，如果MQ內沒有過多信息，就需要訂單業務給一個查詢數據的服務，比如查詢接口或者SQL，去獲取記賬需要的數據。

13 記賬規則

在每個業務場景發生以后我們需要記哪些賬在上面已經完成設定，那么這些賬怎么記呢，計給哪些對象，計入哪些賬戶呢？這就是我們的記賬規則了，比如我們介紹01支付成功以后的記賬：

有了規則以后，業務發生了就可以通過規則判定該場景需要記哪些賬，然后獲得相應的數據；獲得數據以后先生成業務最原始的憑證存下來，然后進行清分處理；這里記賬單據我們按生成的先后順序，依賴關系分成三類：

14 業務原始憑證

是業務發生以后完成計費以后最原始的數據，比如訂單支付成功以后獲得的記賬數據存儲在清分系統，這筆數據里包含了01用戶支付成功需要記賬的全部信息：

15 清分憑證

上面我們介紹了“01用戶支付成功”場景發生以后，我們需要記錄3個費用“1001、3005、30010”，這樣我們根據業務憑證的數據進行清分，并根據記賬規則知道每個清分出的費用、金額、對象就有了，清分結果如下：

16 賬戶流水

有了清分明細以后，我們就可以根據記賬規則計入對應賬戶，更新賬戶余額，記錄賬戶流水了。

17 計稅開票

計稅模式可以按照每個費用進行計稅、也可以按照每個結算周期進行計稅；同樣需要知道是什么稅，個人所得稅還是增值稅。

假如我們按照費用進行計稅，也就是每入一筆賬都需要計稅；入賬成功以后賬務系統將入賬明細推送給稅務子系統，稅務子系統根據稅種、稅基、稅率等配置計算該筆入賬的稅額，并推送賬務系統進行稅務的扣除。

18 結算付款

按照約定我們需要完成給商家和騎手的結算，將商家的應收和騎手的收入打款給商家。

這里不同的城市，不同的商家可能有不同的結算周期，有的按照日結，有的按照月結，有的按照周結。

結算的依據可以是賬戶的當期余額，也可以是當期的賬戶流水，結算到指定的結算賬戶或者生成結算單進行打款，這里我們就不詳細介紹了，詳細介紹可以參考結算系統設計方法

19 清結算架構總結

在一張小票看透清結算架構（上）等多篇文章中介紹了不同的架構，這里針對上面介紹的內容進行規則，可以得到下面的架構圖，便于理解清結算的業務流程以及單據之間的關聯和交互。

專欄作家

陳天宇宙，微信公眾號：陳天宇宙，人人都是產品經理專欄作家。多平臺支付領域專欄作者，十年資深產品；天使投資人；專注為10萬支付產品經理和支付機構以及企業提供深度支付內容和服務！

本文原創發布于人人都是產品經理。未經許可，禁止轉載。

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

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

以上就是關于刷卡機怎么清算余額的知識，后面我們會繼續為大家整理關于刷卡機怎么清算余額的知識，希望能夠幫助到大家！

轉載請帶上網址：http://www.xingyun520.com/shuaka/127815.html