GamePP Platform V2

幣商作業系統升級提案
工程版 / ENGINEERING
三系統職責切分 + 服務業表象 + 買賣業內涵
含完整資料模型、撮合事件流、遷移路徑與 know-how 設計
內部技術文件|2026 年 4 月

目錄

1. 核心訊息與設計原則

戰略目標

把幣商作業系統拆成三個職責清晰的子系統:gamepp(幣商管理 / 經營面)、ATMatch(撮合引擎)、gamepp_accounting(內帳)。三系統各有清楚邊界,但都圍繞同一個 know-how 設計:「服務業表象 + 買賣業內涵」。

三系統的角色

系統角色對應現有 codebase
gamepp幣商管理系統 / 核心經營面🆕 全新開發
ATMatch訂單撮合引擎現有 gamepp-web + gamepp-branch(rename)
gamepp_accounting內帳會計系統現有 gamepp_accounting(維持)

命名決策的意義

2. 稅務 know-how:服務業表象 + 買賣業內涵

🔒 核心 know-how(不對外)

「國稅局給了幣商一條路(按差額課稅、視為服務業),但這條路是錯的,幣商實際業態是買賣業。」

這個判斷是整個系統設計的基石。三系統的所有設計,都圍繞「對外維持服務業表象(符合 113 函令)+ 對內反映買賣業真相」的雙視角原則。

法規依據

發票邏輯

情境計稅基礎發票類型
C2B(玩家賣家)C = A - B 差額二聯式應稅自留
B2B(營業人賣家)全額 A三聯式(可向前手取得進項扣抵)

服務業 vs 買賣業 本質衝突

維度服務業視角(國稅局)買賣業視角(實際)
標的「撮合服務」遊戲幣這個商品
所有權無移轉(仲介)進貨後歸幣商
庫存永遠 = 0進貨後可能持有數天
風險價格波動、匯率風險
收入服務費 C銷貨收入 A,COGS = B
帳務只記 C完整進銷存 + COGS + 毛利

雙視角設計(核心 know-how 實作)

概念對外(服務業說法)對內(買賣業實質)
庫存「等待撮合的待出商品池」進貨後的庫存風險敞口
預收「待撮合的買單金額」銷貨應收 / 客戶預付
預付「待撥款的賣單金額」進貨應付 / 供應商預付
進貨明細「商品進銷存統計」完整 COGS 來源追蹤

⚠️ Know-how 保護原則

3. 三系統職責拓樸

三系統職責拓樸
三系統並列:gamepp(核心) / ATMatch(引擎) / gamepp_accounting(內帳)

各系統的元件清單

🎯 gamepp(幣商管理系統 / 核心經營面)

元件職責
進銷存模組多公司 / 遊戲 / 角色的庫存管理(含 know-how 內涵)
進貨管理產包 / 同業 / 玩家 / 活動贈送 等多管道進貨入口
撮不完單管理從 ATMatch 接收撮不完事件,做 aged 追蹤、預收/預付風控
報表 / 毛利分析取代手寫日報表,按管道拆分毛利
稅務申報輸出113 函令法定明細表自動產出
公司別路由跨公司資金與訂單路由決策
異常單(經營層)玩家行為異常、KYC 過期、4 萬門檻、風控警示
基礎資料層客戶(幣商)、會員(玩家)、風控資料

⚙️ ATMatch(訂單撮合引擎)

元件職責
買賣單建立會員 / 非會員開單入口
撮合引擎4 條件檢查(公司 / 遊戲 / 幣種 / 數量)
結算水位代出款餘額追蹤
異常單(作業層)撮合配對失敗、銀行對帳異常、轉帳異常
銀行對帳自動對帳、審核賣單
🆕 多池取貨擴展支援從 gamepp 的 inventory_in 池取貨撮合(新功能)

💼 gamepp_accounting(內帳)

元件職責
Journal買賣業視角的會計事件記錄
COGS / 毛利從 gamepp 的進銷存事件取進貨成本
BS / IS / 月結真實財務狀況呈現
🔒 純內部使用不對客戶 / 國稅局 / 股東開放

4. 資料模型

4.1 庫存的四層結構

資料層級
幣商 → 公司 → 遊戲 → 遊戲角色 → (幣 × 管道)

4.2 為什麼「遊戲角色」這層特別重要

4.3 進貨管道枚舉

Channel來源入庫方式成本特性
玩家ATMatch 撮合的賣單自動變動
產包跟遊戲商批發手動進貨單穩定但低毛利
同業跟同業調貨手動進貨單應急用,毛利窄
活動贈送遊戲商活動贈幣手動進貨單0 成本
自家持有早期累積 / 獲利轉持手動進貨單視成本基礎

4.4 核心資料表(草案)

game_account(遊戲角色 = 庫存容器)

CREATE TABLE game_account ( id BIGINT PRIMARY KEY, company_id BIGINT, -- 幣商旗下哪家公司 game_id BIGINT, -- 哪款遊戲 role_name VARCHAR(64), role_id_in_game VARCHAR(64), status ENUM('active', 'banned', 'locked'), capacity_limit BIGINT -- 該角色的存量上限 );

inventory_position(當前庫存快照)

CREATE TABLE inventory_position ( id BIGINT PRIMARY KEY, company_id BIGINT, game_id BIGINT, game_account_id BIGINT, coin_type VARCHAR(32), channel ENUM('player', 'pack', 'peer', 'event', 'self'), qty BIGINT, avg_cost DECIMAL(12,4), UNIQUE(company_id, game_id, game_account_id, coin_type, channel) );

inventory_in(進貨事件,多管道)

CREATE TABLE inventory_in ( id BIGINT PRIMARY KEY, company_id BIGINT, game_id BIGINT, game_account_id BIGINT, coin_type VARCHAR(32), channel VARCHAR(32), qty BIGINT, unit_cost DECIMAL(12,4), total_cost DECIMAL(14,2), source_type ENUM('atmatch_sell', 'manual_purchase', 'activity'), source_ref VARCHAR(64), in_at DATETIME );

match_event(撮合事件,由 ATMatch 產出)

CREATE TABLE match_event ( id BIGINT PRIMARY KEY, buy_order_id BIGINT, sell_order_id BIGINT, -- 來自玩家或虛擬進貨單 company_id BIGINT, game_id BIGINT, game_account_id BIGINT, coin_type VARCHAR(32), qty BIGINT, amount_a DECIMAL(14,2), -- 買方付款 = 銷貨收入 amount_b DECIMAL(14,2), -- 給賣方 = 進貨成本 fee_c DECIMAL(14,2), -- 毛利 = A - B channel VARCHAR(32), -- 該批幣的來源管道 matched_at DATETIME );

unsettled_order(撮不完的單 = 預收 / 預付)

CREATE TABLE unsettled_order ( id BIGINT PRIMARY KEY, type ENUM('buy', 'sell'), company_id BIGINT, game_id BIGINT, coin_type VARCHAR(32), qty BIGINT, amount_twd DECIMAL(14,2), aged_days INT, blocked_reason VARCHAR(128), created_at DATETIME );

member(玩家會員)

CREATE TABLE member ( id BIGINT PRIMARY KEY, name VARCHAR(64), id_card VARCHAR(20), phone VARCHAR(20), is_business BOOLEAN, -- 影響發票邏輯(C2B/B2B) monthly_sales DECIMAL(14,2), -- 4 萬門檻追蹤 risk_flags JSON, kyc_status ENUM('pending', 'verified', 'rejected'), bank_accounts JSON );

5. 主業務流程

橫跨三系統的完整業務流程,涵蓋從訂單建立到對外輸出。

主業務流程
完整業務流程:訂單 → 撮合 → 進銷存 → 報表 → 內帳 → 對外輸出

事件來源

來源建立位置後續流向
買賣單ATMatch進撮合條件檢查
進貨(產包/同業/活動)gamepp 進貨管理進 inventory_in 池,🆕 等待 ATMatch 多池取貨

6. 撮合事件流(單軌成本)

撮合事件流
4 條件 + 雙路徑(成功 → 三件事 / 失敗 → 待結算池)

撮合 4 條件

  1. 公司一致:同統編
  2. 遊戲一致:同款遊戲幣
  3. 幣種一致:同幣種
  4. 數量配對:qty 對得起來

為什麼不需要 FIFO 雙軌

原本設計過「FIFO 預估 + 實際成本」雙軌記錄,但 DC 點出:

「銷售 = 撮合,每筆撮合事件直接含成本(A、B、C),不需要從歷史庫存找成本。」

每筆 match_event 自帶完整的進銷貨資訊(A 銷貨 / B 進貨 / C 毛利),COGS 直接從事件取,不需要 inventory_lot 的 avg_cost,邏輯大幅簡化。

7. 現有 codebase ↔ 新系統對照

Codebase 對照
gamepp-web + branch → ATMatch;新建 gamepp

對照表

現有新系統動作
gamepp-web (總站)ATMatchrename + rebrand
gamepp-branch (分站)ATMatchrename + rebrand
gamepp_accountinggamepp_accounting維持
(無)gamepp 🆕從零開發

8. 功能遷移範圍

現有 gamepp-web 內有些功能未來要搬到新 gamepp,以下是逐項對照:

功能目前位置最終歸屬備註
買賣單建立gamepp-webATMatch
撮合引擎gamepp-webATMatch4 條件擴展
公司別路由gamepp-webgamepp經營面決策
異常單系統gamepp-web兩系統都有意義不同(見下)
結算水位gamepp-webATMatch水位 = 代出款餘額
銀行明細gamepp-web三系統都用用途不同(見下)
玩家會員 KYCgamepp-webgamepp但低調呈現
客戶(幣商)管理gamepp-web sites短期並存 → 長期 gamepp漸進策略
撮不完單管理(尚無)gamepp 🆕新建
報表 / 日報匯出(尚無)gamepp 🆕新建
進銷存(尚無)gamepp 🆕新建
稅務輸出(尚無)gamepp 🆕新建

異常單的兩種意義

系統異常單意義範例
ATMatch作業異常撮合配對失敗、銀行對帳對不上、玩家轉帳異常
gamepp經營異常玩家行為異常、KYC 過期、4 萬門檻提醒、風控警示

銀行明細的三系統用途

系統用途
ATMatch自動對帳、審核賣單
gamepp_accounting帳務(轉成 journal entry)
gamepp對帳

9. ATMatch 多池取貨擴展

🆕 新功能需求

現在 ATMatch 撮合只能配對「買單 ↔ 玩家賣單」。新提案要擴展為「買單 ↔ 多個來源池」。

背景

幣商有多種進貨管道:

現況問題

非玩家來源的進貨(產包、同業、活動)目前沒辦法被 ATMatch 撮合掉。這些幣只能靠人工出單,無法享受撮合自動化。

解法(DC 偏向方案 B)

  1. gamepp 進貨管理建立 inventory_in 記錄
  2. ATMatch 撮合引擎擴展為從兩個池取貨:
    • 玩家賣單池(現有)
    • inventory_in 池(新增)
  3. 撮合時取貨來源不影響 buyer 體驗(buyer 看到的還是「我下單→收到幣」)
  4. match_event.channel 記錄這批幣的來源管道,方便毛利分析

取貨優先順序(待定)

未來可能的策略:

⚠️ 目前先實作純 FIFO,未來再依業務需求調整。

10. 待後續討論的事項

  1. 客戶(幣商)管理的長期歸屬細節:短期三系統並存,長期放 gamepp 授權給 ATMatch — 但「並存怎麼運作 / 同步策略」尚未定
  2. 遷移時程:從現有 gamepp-web 拆出非撮合功能到新 gamepp 的步驟與優先級
  3. ATMatch 多池取貨的實作細節:何時取 inventory_in 池 vs 玩家賣單池?取貨優先順序的決策機制
  4. 商業模式 / 定價:DC 指示「先不管商業模式」,待系統設計定案後再討論
  5. 客戶 onboarding 模式:原 Trello card 的四模式(有/沒系統 × 有/沒日報),重新對應後是什麼?要不要納入工程提案