csxj2026/junhong_cmp_fiber
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
Files
743db126f78302f131eed22c774b641a9562d6a0
junhong_cmp_fiber/docs/待沟通/关于分佣.md
huang 6fc90abeb6 实现服务启动时自动生成OpenAPI文档 
主要变更:
1. 新增 cmd/api/docs.go 实现文档自动生成逻辑
2. 修改 cmd/api/main.go 在服务启动时调用文档生成
3. 重构 cmd/gendocs/main.go 提取生成函数
4. 更新 .gitignore 忽略自动生成的 openapi.yaml
5. 新增 Makefile 支持 make docs 命令
6. OpenSpec 框架更新和变更归档

功能特性:
- 服务启动时自动生成 OpenAPI 文档到项目根目录
- 保留独立的文档生成工具 (make docs)
- 生成失败时记录错误但不影响服务启动
- 所有代码已通过 openspec validate --strict 验证

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-09 12:25:50 +08:00

300 lines
13 KiB
Markdown
Raw Blame History

上周跟杨经理沟通了关于分佣的问题
我们的业务分为分为两条线分别是流量卡(按照流量计算的为大代理,不走我们的卡管)跟号卡
之前大萝卜去沟通的分佣逻辑事实上是倾向于号卡的,跟流量卡的实际销售路径其实是完全不一样的
## 流量卡
目前咱们公司的流量卡销售的分佣虽然叫作分佣,其实他本质上是一种阴阳菜单
平台按照50元的进货价进货后,加上自己的成本以及一定利润加价给代理商,可能A代理商给他是60,B代理商给他是70...
之后A代理商可能又加价给他的下游代理商(也可能不加价),同时代理商们可以基于他们的成本价/进货价(我们给这个代理设置的成本价)决定他们终端客户能[看/买]到多少钱的套餐,假设代理商拿到手的流量卡成本价是80元,那么他可以给终端客户的价格是80+10=90元,或者80+20=100元,或者80+30=110元...
此时终端客户购买了110元的套餐此时平台(我们公司)收账110,我们从中拿走80元,其他的归代理所有.
同时流量卡还有一个真正的分佣,这个分佣是从我们给代理商的价格中分钱给他,譬如上面的例子中,我们再加一个分佣规则,每卖一个套餐就给 5元/5% 佣金
这个是我们流量卡真正的分佣,同时他还有号卡的梯度分佣
流量卡流程:
```mermaid
flowchart TD
Start([平台以50元进货]) --> Config[配置代理阴阳菜单成本价<br/>成本价包含进货价运营成本平台利润]
Config --> Distribute{分配至不同代理层级}
Distribute -->|A代理| CostA[(A代理成本价: 60元)]
Distribute -->|B代理| CostB[(B代理成本价: 70元)]
Distribute -->|其他代理| CostC[(其他代理成本价: 自定义)]
CostA & CostB & CostC --> AgentPrice[代理根据成本价自主加价]
AgentPrice --> RetailPrice[(终端套餐价: 90/100/110元)]
RetailPrice --> OrderType{订单类型}
%% 流程1: 用户主动购买
OrderType -->|流程1: 用户主动购买| UserPay[用户直接向平台支付套餐价]
UserPay --> PlatformReceive1[平台收款 套餐价90元]
PlatformReceive1 --> Deduct1[平台扣除代理成本价60元]
Deduct1 --> PriceDiff[差价30元归代理]
%% 流程2: 代理预充值购买
OrderType -->|流程2: 代理预充值购买| AgentRecharge[代理提前充值余额到平台]
AgentRecharge --> AgentBalance[(代理账户余额)]
AgentBalance --> AgentBuy[代理帮客户下单]
AgentBuy --> DeductBalance[从代理余额扣除成本价60元]
DeductBalance --> AgentCollect[代理自行向客户收取套餐价90元]
AgentCollect --> AgentProfit[代理赚取差价30元]
%% 分佣逻辑 - 流程1
PriceDiff --> Commission1{流程1触发分佣}
Commission1 -->|订单完成| CheckRule1[查找该代理的分佣规则]
CheckRule1 --> HasRule1{是否配置分佣?}
HasRule1 -->|固定分佣| Fixed1[示例: 每单返5元]
HasRule1 -->|比例分佣| Percent1[示例: 按成本价5%返佣<br/>60元乘5% 得3元]
HasRule1 -->|无分佣| NoCommission1[不返佣仅保留差价]
Fixed1 & Percent1 --> Return1[从平台收入中返还给代理]
%% 分佣逻辑 - 流程2
DeductBalance --> Commission2{流程2触发分佣}
Commission2 -->|订单完成| CheckRule2[查找该代理的分佣规则<br/>基于成本价分佣]
CheckRule2 --> HasRule2{是否配置分佣?}
HasRule2 -->|固定分佣| Fixed2[示例: 每单返5元]
HasRule2 -->|比例分佣| Percent2[示例: 按成本价5%返佣<br/>60元乘5% 得3元]
HasRule2 -->|无分佣| NoCommission2[不返佣]
Fixed2 & Percent2 --> Return2[从平台收入返还到代理余额<br/>或直接提现]
%% 资金流总结
Return1 & Return2 & AgentProfit --> Summary[资金流总结]
Summary --> Flow1[流程1平台收90元<br/>给代理差价30元<br/>给代理分佣3到5元<br/>平台净利润55到57元]
Summary --> Flow2[流程2平台收60元<br/>给代理分佣3到5元<br/>平台净利润55到57元<br/>代理自行赚差价30元]
classDef highlight fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
classDef profit fill:#f9f2d2,stroke:#caaa44,stroke-width:2px
classDef commission fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
class UserPay,AgentBuy highlight
class PriceDiff,AgentProfit profit
class Return1,Return2 commission
```
## 号卡
我们号卡还是跟原来一样
> 核心差异：号卡是**厂家定价**，资金流**直连厂家**。平台仅负责分发产品和二次结算佣金。
```mermaid
flowchart TD
%% Initialization
Factory([上游厂家/运营商]) -->|制定固定套餐| Product["标准号卡产品<br/>(价格/流量/语音由厂家定死)"]
Product -->|上架| Platform[平台]
Platform -->|分销| Agent[代理商]
%% User Action
Agent -->|推广链接/卡板| User(终端用户)
User -->|激活 & 充值| PayUpstream[直接支付给运营商/厂家]
%% Money Logic
PayUpstream --"资金不经过平台"--> FactoryWallet[(厂家账户)]
%% Commission Settlement
FactoryWallet -->|周期性结算| TotalCommission[支付总佣金给平台]
TotalCommission --> PlatformWallet[平台收款]
%% Internal Distribution
PlatformWallet --> MatchRule{匹配代理规则}
MatchRule -->|计算佣金| AgentComm[代理佣金]
AgentComm -->|"状态: 冻结/在途"| Verify{"满足返佣条件?<br/>(首充/三无/在网时长)"}
Verify -->|条件满足| Unfreeze[解冻/发放]
Unfreeze --> AgentBalance[(代理商余额)]
Verify -->|条件不满足| Invalid[佣金失效]
%% Profit
PlatformWallet -->|总佣金 - 代理佣金| Profit[平台留存利润]
classDef highlight fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
classDef profit fill:#f9f2d2,stroke:#caaa44,stroke-width:2px
classDef commission fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
class PayUpstream,TotalCommission highlight
class Profit,AgentBalance profit
class AgentComm,Unfreeze commission
```
整体流程:
```mermaid
flowchart TD
%% ================= 角色与外部系统 =================
subgraph Clients [客户与渠道]
User((C端个人用户))
Enterprise["B端企业客户<br/>(批量采购/自行管卡)"]
Agent[代理商/分销商]
end
subgraph UpstreamLayer [上游基础设施]
Upstream[上游运营商/厂家API]
Tower[基站/用量数据源]
end
%% ================= 平台核心逻辑 =================
subgraph Platform [Junhong CMP 核心平台]
direction TB
%% --- 1. 交易与开卡链路 ---
subgraph TradeFlow [交易与开通]
OrderStart{订单类型?}
%% 流量卡分支
TrafficCard["流量卡业务<br/>(平台定价+代理加价)"]
PayPlatform[支付给平台]
SplitBill[资金分流: <br/>1. 扣除平台成本<br/>2. 代理赚差价]
%% 号卡分支
NumberCard["号卡业务<br/>(厂家固定定价)"]
PayFactory[用户直付运营商]
WaitSettle[等待厂家结算佣金]
%% 开通动作
ActivateCmd[调用上游激活API]
end
%% --- 2. 监控与风控链路 (卡管核心) ---
subgraph MonitorFlow [监控与生命周期]
DataSync[用量/状态同步]
MonitorEngine{风控规则引擎}
%% 监控分支
CheckPersonal{个人套餐<br/>是否超量?}
CheckEnterprise{企业卡池/额度<br/>是否超标?}
%% 动作
ActionStop[发送停机指令]
ActionResume[发送复机指令]
end
%% --- 3. 佣金结算链路 ---
subgraph FinanceFlow [佣金结算]
CommCalc[佣金计算]
%% 流量卡佣金
TrafficProfit[流量卡收益:<br/>差价 + 基础返点]
%% 号卡佣金
NumberProfit[号卡收益:<br/>冻结 -> 三无校验 -> 解冻]
Wallet[(用户/代理余额)]
end
end
%% ================= 连线关系 =================
%% 1. 推广与购买
Agent -->|推广链接/开户| Clients
User -->|购买单卡| OrderStart
Enterprise -->|批量采购| OrderStart
OrderStart -->|流量卡| TrafficCard
TrafficCard --> PayPlatform
PayPlatform --> SplitBill
SplitBill --> ActivateCmd
OrderStart -->|号卡| NumberCard
NumberCard --> PayFactory
PayFactory -.->|资金不经平台| Upstream
PayFactory -->|通知开通| ActivateCmd
ActivateCmd -->|API请求| Upstream
%% 2. 资金结算流
SplitBill -->|入账| Wallet
Upstream -.->|周期结算单| WaitSettle
WaitSettle --> CommCalc
SplitBill --> CommCalc
CommCalc --> TrafficProfit
CommCalc --> NumberProfit
TrafficProfit --> Wallet
NumberProfit --> Wallet
%% 3. 监控与控制流 (闭环)
Upstream -->|1. 推送话单/用量| DataSync
DataSync --> MonitorEngine
MonitorEngine --> CheckPersonal
MonitorEngine --> CheckEnterprise
%% 个人判断
CheckPersonal -->|超量| ActionStop
CheckPersonal -->|正常| DataSync
%% 企业判断
Enterprise -->|设置额度/查看报表| CheckEnterprise
CheckEnterprise -->|卡池耗尽/单卡超额| ActionStop
CheckEnterprise -->|余额充足| ActionResume
%% 执行控制
ActionStop -->|API: 停机| Upstream
ActionResume -->|API: 复机| Upstream
%% 样式定义
classDef actor fill:#e1f5ff,stroke:#0288d1,stroke-width:2px
classDef process fill:#e8f5e9,stroke:#4caf50,stroke-width:2px
classDef logic fill:#fff9c4,stroke:#fbc02d,stroke-width:1px
classDef warning fill:#ffcdd2,stroke:#c62828,stroke-width:2px
class User,Enterprise,Agent,Upstream actor
class PayPlatform,PayFactory,ActivateCmd,DataSync,ActionStop,ActionResume process
class OrderStart,MonitorEngine,CheckPersonal,CheckEnterprise,CommCalc logic
class ActionStop warning
```
需要处理的事情
1. 确认上面的东西是不是对的
2. 确认一下是否还有别的业务
3. 跟我讲一下我们的实际业务
1. 代理的销售价格不能大于平台给他的成本价两倍(奇成是写死的)
2. 物联网卡行业中的佣金=实际售价-平台给的成本价(这个其实是长期分佣)(阴阳菜单)
3. 一次性佣金关于客户的逻辑 客户充值100 只能≤一百(流量卡)
(号卡 可能≥100)
A 用户买了一个A产品,那么现在给代理的成本价60 售价 90 (一次性佣金)(首次购买时预存100 佣金10块)
当一个套餐被设置一次性佣金后他第一次去购买只能通过钱包付款
组合佣金(一次性佣金+长期分佣)(1.某个时间点后,2. 使用套餐个数(只作用于一个物联网卡 例如 某个套餐的使用套餐个数是10,那么这个张卡需要达到10个套餐周期后才能开始分佣,只有这一张卡才会分佣))
阶梯分佣基于一次性佣金以及长期佣金之上,当到达某个条件后,变更分佣值
阶梯分佣(提货量/激活量(实名+历史存在过套餐)/保证金(未来做的))
1. 激活量根据当前时间态统计
2. 如果是进行时统计,例如年底汇报 1-12月 每月的激活量时 应该是固定的,例如 1月的激活是10 2月的激活是20,3月的激活是30,4月的激活是40,5月的激活是50,6月的激活是60,7月的激活是70,8月的激活是80,9月的激活是90,10月的激活是100,11月的激活是110,12月的激活是120
可能会存在1月的激活中因为是历史数据,会存在同一个iccid在2月的激活量中存在,这是可以接受的,需要业务方知道
1. 一次性佣金满足 激活(实名) + 达到累计/首次充值金额 = 产生佣金(冻结) (可能是[7]天后 状态变成解冻中 同步产生一条佣金解冻审批等待审批)
2. 长期佣金满足 激活(实名) + 达到累计/首次充值金额 + 在网状态(必须是正常的)(能不能拿到在网状态 存疑) + 三无(能不能拿到 存疑) = 产生佣金(冻结 必须通过excel导入, 状态 变成 解冻中 同步产生对应的佣金解冻审批 等待审批)
3. 组合佣金 (一次性佣金+长期佣金)(1. 连续在网多少个月后开始长期分佣)
4. 阶梯分佣满足 激活(实名 + 达到累计/首次充值金额 + 在网状态(必须是正常的)(能不能拿到在网状态 存疑) ) = 激活
Reference in New Issue View Git Blame Copy Permalink