版本：V1.0 | 编制日期：2026-03-03
本文档依据【汇牧通】生猪/肉牛产业控制塔项目定义与蓝图（V3.0）及需求访谈整理而成，展示汇牧通交易系统的业务设计全貌、核心价值与实施路径。
1
目录
2
一、项目概述
1.1 项目背景
生猪、肉牛产业的供应链条长、参与方多、交易标的为活体生物，具有以下行业特点：
| 序号 | 痛点 | 说明 |
|---|---|---|
| 1 | 链条复杂 | 从养殖方（A）到收货方（C）之间普遍存在 1~3 级中间商（B1-B3），多级交易叠加，信息极度不透明，各方仅能看到直接上下游，无法掌握全链路动态 |
| 2 | 凭证残缺 | 行业内大量交易依赖纸质合同、手写单据、口头确认，结算纠纷频发，发票缺失、对账困难 |
| 3 | 资金风险高 | 定金、货款金额大，支付周期长（T+N 结算），逾期追款成本高，资金安全缺乏系统性保障 |
| 4 | 物流黑箱 | 活体动物在途时间长（跨省长途运输），养殖方和收货方均无法实时掌握在途状态，病死/事故/检疫问题难以追溯 |
| 5 | 合规不统一 | 合同要素不完整、签署流程不规范导致纠纷时举证困难，电子合同法律效力认可度参差不齐 |
在上述背景下，运营方（即汇牧通平台）需要一套私域供应链协同系统，将其所服务的生猪/肉牛贸易圈内的全部交易主体纳入统一的数字化管理体系，实现"合同在线化、签章合规化、资金可追溯、物流可管控、结算自动化"的管理目标。
1.2 项目定位
汇牧通定位为：「跨品种（生猪+肉牛）私域供应链协同操作系统」
- 私域：系统不对公众开放注册，所有用户（A/B/C 及内部角色）均由平台方（M/N）统一录入和授权，形成封闭的可信交易圈。
- 供应链协同：横向覆盖交易链上的所有参与方（供货方、中间商、收货方、物流方、财务方）；纵向贯穿交易全生命周期（合同→订单→物流→验收→结算→发票）。
- 操作系统：不只是记录工具，而是业务操作的载体。所有关键业务动作（签章、确认、审批、结算传导）均在系统内完成，系统是业务执行的主渠道。
1.3 核心价值与意义
对平台运营方（M 方）：
- 全链路数据透明：可查看任意一笔交易在任何节点的完整状态
- 风险主动防控：系统自动识别逾期、异常，M 第一时间介入
- 收益保障：通过基础毛利率机制，确保每笔交易的盈利空间受到系统保护
- 决策数据支撑：多维度统计看板提供经营分析依据
对交易各方（A/B/C）：
- 合同法律效力保障：电子签章符合《电子签名法》，纠纷有据可查
- 对账效率提升：系统自动生成对账台，应收应付一目了然
- 资金安全：定金、货款支付均有截图凭证，系统留存
- 上下游信息同步：订单状态、物流进度、发票状态实时可查
对物流管理（F 方）：
- 系统化管理运输资源（司机、车辆、承运商数据库）
- 一站式管理运输发票池
- 在途异常有规范处理流程，责任清晰
对财务管理（L 方）：
- 结算链自动传导，无需手动计算各级金额
- 逾期账款自动预警，应收账款管理效率大幅提升
- 财务凭证集中存档，对账有据
1.4 项目目标
| 目标维度 | 具体目标 |
|---|---|
| 交易透明化 | 全链路交易节点在线化，信息实时同步至所有相关方 |
| 合规签章 | 电子签章（符合《电子签名法》）+ 智能合同识别验真 + 三单三章闭环 |
| 风控体系 | 定金比例、T+N 周期、损耗阈值、审批规则均系统化管理 |
| 效率提升 | 结算自动传导、对账台自动生成、逾期自动预警 |
| 数据资产 | 沉淀交易数据、物流数据、价格数据，为增值业务奠定基础 |
3
二、系统用户与协作体系
2.1 平台管理团队（手机 + 电脑）
| 代号 | 角色名称 | 使用终端 | 职责范围 |
|---|---|---|---|
| M | 首席管理员 | 手机 + 电脑 | 全局最高权限。配置所有角色权限；设置风险阈值（最低定金比例、最大 T+N 周期、允许损耗范围）；定义审批触发规则；处理全部异常事项；统计看板监控全局经营数据。唯一不可被替换的角色 |
| N | 权限管理员 | 电脑为主 | 业务运营执行层。录入 A/B/C 主体信息；标注上下游关系拓扑；上传合同并触发智能识别验证；绑定单据模板；创建/跟进订单全流程。权限范围由 M 在线配置 |
| F | 物流专管员 | 手机 + 电脑 | 物流与合规执行层。维护承运商/司机/车辆数据库；填写在途监管计划；作为司机与系统的唯一信息桥梁（接收微信信息上传至系统）；管理运输发票池；上传动物检疫合格证 |
| L | 财务专管员 | 电脑为主 | 财务结算执行层（M 的团队成员）。核验 C 方签收单和结算单；驱动结算向上传导；管理应收账款催收；跟进货物发票开具 |
| T | IT 管理员 | 电脑管理后台 | 系统建模与技术保障层。定义全部业务字段；维护单据格式模板库；保障电子签章和智能识别服务稳定运行；负责系统环境的部署与维护 |
注： L 归属于 M 方团队，其他外部交易主体（A/B/C）不单独设立财务人员使用系统。
2.2 外部交易主体（专属客户端）
| 代号 | 角色名称 | 使用终端 | 说明 |
|---|---|---|---|
| A | 供货方 | 专属客户端 | 供应链起点（养殖方/供应商）。只有应收账款，无应付账款。是最终签收单/结算单链条的终点接收方 |
| B1 | 一级中间商 | 专属客户端 | 直接从 A 采购，向 C（或 B2）销售。同时具有应付和应收账款 |
| B2 | 二级中间商 | 专属客户端 | 从 B1 采购，向 C（或 B3）销售。同时具有应付和应收账款 |
| B3 | 三级中间商 | 专属客户端 | 从 B2 采购，向 C 销售。同时具有应付和应收账款 |
| C | 收货方 | 专属客户端 | 供应链终点（屠宰场/养殖场/贸易商终端）。只有应付账款。是三单三章闭环的发起方（订单发起+签收单+结算单同步提交） |
注： 各交易主体的银行账户信息在 N 录入主体信息时一并预存，用于支付凭证的收款方展示。
2.3 权限管理机制
M 通过在线配置（实时生效）将 21 项可配置权限下放给 N/F/L 执行，配置后该待办项从 M 工作台移入对应角色的工作台。
2.4 权限矩阵
| 功能域 | M | N | F | L | T | A | B | C |
|---|---|---|---|---|---|---|---|---|
| 系统建模/字段定义 | ○ | ◎ | ||||||
| 主体录入管理 | ○ | ● | ||||||
| 拓扑关系管理 | ○ | ● | ||||||
| 合同上传与识别 | ○ | ● | ||||||
| 电子签章 | ○ | ● | ● | ● | ● | |||
| 订单创建 | ○ | ● | ● | ● | ● | |||
| 定金确认 | ○ | ● | ● | ● | ||||
| 车辆安排修改 | ○ | ● | ||||||
| 物流信息上传 | ○ | ◎ | ||||||
| 签收单核验 | ○ | ◎ | ||||||
| 结算单核验 | ○ | ◎ | ||||||
| 结算传导 | ○ | ◎ | ||||||
| 货款支付确认 | ○ | ● | ● | ● | ● | |||
| 发票管理 | ○ | ◎ | ||||||
| 权限配置 | ◎ | |||||||
| 风险阈值设置 | ◎ | |||||||
| 异常处置 | ◎ | ○ | ○ | ○ |
◎ = 独占权限 ● = 有权操作 ○ = 可委托给该角色
M 独占权限（不可下放）：
- 交易主体彻底删除/禁用
- 拓扑关系彻底解除
- 合同终止
- 风险阈值调整（最低定金比例、最大 T+N 天数、允许损耗范围）
- 审批触发规则修改
- 结算金额异常的最终裁定
- 订单修改/取消的最终审批
- 全部子角色（N/F/L/T）的权限调整
4
三、交易模式与合同管理
3.1 四种交易形态
graph LR
subgraph "形态一：直取"
A1[A 供货方] --> C1[C 收货方]
end
subgraph "形态二：单级"
A2[A] --> B1_2[B1] --> C2[C]
end
subgraph "形态三：双级"
A3[A] --> B1_3[B1] --> B2_3[B2] --> C3[C]
end
subgraph "形态四：全链"
A4[A] --> B1_4[B1] --> B2_4[B2] --> B3_4[B3] --> C4[C]
end
| 形态 | 链路 | 三单三章套数 | 说明 |
|---|---|---|---|
| 直取 | A → C | 1 套 | 供货方直接与收货方签约，最简洁链路 |
| 单级 | A → B1 → C | 2 套 | 一级中间商介入 |
| 双级 | A → B1 → B2 → C | 3 套 | 二级中间商介入 |
| 全链 | A → B1 → B2 → B3 → C | 4 套 | 最长链路（中间商最多 3 级） |
核心规则：
- 每个买卖对之间必须有且仅有一份有效合同
- 合同绑定的单据模板决定该链路所有订单/结算单/签收单的格式
- 同一批货物在全链路形成一个主订单号，每个买卖对产生一个子订单号
- 拓扑关系由 N 录入并标注，系统强制单向（A 方向 C 方，不可反向交易）
3.2 合同核心要素（13 项）
智能识别必检 9 项
| 字段编号 | 字段名 | 法律/业务必要性 | 示例值 |
|---|---|---|---|
| C01 | 甲方（卖方）全称 | 合同主体认定 | 某某牧业有限公司 |
| C02 | 乙方（买方）全称 | 合同主体认定 | 某某肉业有限公司 |
| C03 | 甲方统一社会信用代码 | 企业身份唯一标识 | 91XXX... |
| C04 | 乙方统一社会信用代码 | 企业身份唯一标识 | 91XXX... |
| C05 | 甲方法定代表人 | 签章人身份校验 | 张三 |
| C06 | 乙方法定代表人 | 签章人身份校验 | 李四 |
| C07 | 商品名称及规格 | 交易标的认定 | 三元杂交猪/西门塔尔牛 |
| C08 | 定金比例 | 资金风控基线 | 20% |
| C09 | 结算方式（T+N） | 账期管理基础 | T+15 天 |
以上 9 项中任意 1 项未能自动识别或与系统录入信息不符，合同驳回，不予上传。
系统补充必填 4 项
| 字段编号 | 字段名 | 说明 | 示例值 |
|---|---|---|---|
| C10 | 交货方式 | 物流安排依据 | 卖方送货 |
| C11 | 车辆安排方 | 叫车责任认定 | 买方叫车 |
| C12 | 基础毛利率 | 结算传导计算依据 | 2%（百分比模式）或 3000元/车（固定值模式） |
| C13 | 合同有效期 | 合同时间约束 | 2026-03-01 至 2027-02-28 |
合同有效性三要素
合同有效性 = 智能识别通过 + 三类单据模板绑定 + 双方电子签章完成
合同预置数据项
| 数据项 | 说明 |
|---|---|
| 定金比例（%） | 百分比形式 |
| T+N 结算周期 | N 值：具体天数 |
| 基础毛利率 | 模式 A：百分比 → 上游结算金额 = 下游结算金额 × (1 - 毛利率%) |
| 模式 B：固定值 → 上游结算金额 = 下游结算金额 - 每车固定金额 | |
| 默认车辆安排方 | 可在订单阶段修改 |
3.3 合同样本模板
以下展示标准合同的结构框架（以 A→B1 的供货合同为例）：
《生猪/肉牛购销合同》
合同编号： HMT-CON-YYYYMMDD-XXXX（系统自动生成）
甲方（卖方）： __________________ 【C01】 统一社会信用代码：__________________ 【C03】 法定代表人：__________________ 【C05】 地址：__________________ 联系电话：__________________ 开户银行：__________________ 银行账号：__________________
乙方（买方）： __________________ 【C02】 统一社会信用代码：__________________ 【C04】 法定代表人：__________________ 【C06】 地址：__________________ 联系电话：__________________ 开户银行：__________________ 银行账号：__________________
第一条 商品名称及规格 品种：__________________ 【C07】 规格要求：__________________（如体重范围、品级要求）
第二条 定金 每笔订单，乙方须在下单时向甲方支付订单金额的 __________% 【C08】作为定金。
第三条 结算方式 采用 T+__________ 天 【C09】结算。T 为双方结算单签章确认之日，届满日为 T+N 天。
第四条 交货方式与车辆安排 交货方式：__________________ 【C10】 车辆安排方：__________________ 【C11】
第五条 验收标准 以乙方实际收货时清点为准，损耗由双方按合同约定标准扣减。
第六条 违约责任 （按双方协商约定）
第七条 争议解决 双方协商解决，协商不成，提交 __________ 仲裁委员会仲裁。
第八条 合同有效期 自 __________ 至 __________ 【C13】
甲方签章：（电子签章区域） 乙方签章：（电子签章区域）
签署日期： __________
各级合同差异说明
| 合同类型 | 甲方（卖方） | 乙方（买方） | 特殊说明 |
|---|---|---|---|
| A-B1 供货合同 | A（养殖方） | B1（一级中间商） | A 只出现在卖方位置 |
| B1-B2 转销合同 | B1 | B2 | B1 在此合同中为卖方，在 A-B1 合同中为买方 |
| B2-B3 转销合同 | B2 | B3 | 同上，B2 角色切换 |
| B(n)-C 销售合同 | B1/B2/B3 | C（收货方） | C 只出现在买方位置 |
| A-C 直取合同 | A | C | 无中间商，最简形态 |
所有级别的合同结构完全一致，仅甲乙方信息不同。系统通过拓扑关系自动识别合同层级。
3.4 合同生命周期状态机
stateDiagram-v2
[*] --> 草稿
草稿 --> 待智能识别 : N上传合同
待智能识别 --> 识别通过_模板绑定 : 智能识别成功
待智能识别 --> 草稿 : 识别失败退回
识别通过_模板绑定 --> 待双方签章 : 模板绑定+数据填写完成
待双方签章 --> 已生效 : 双方电子签章完成
已生效 --> 执行中 : 产生首笔订单
执行中 --> 已终止 : M终止
执行中 --> 已到期 : 自然到期
5
四、核心业务单据
4.1 订单（预估货款）
订单记录的是交易发起时的预估金额，实际到货后以结算单为准。
《购销订单》
| 字段 | 内容 | 来源 |
|---|---|---|
| 订单编号 | HMT-ORD-YYYYMMDD-XXXX | 系统自动生成 |
| 关联合同编号 | HMT-CON-XXXXXX | 系统自动关联 |
| 主订单号 | HMT-MAIN-XXXXXX | 系统自动生成（全链唯一） |
| 卖方名称 | __________ | 合同自动带入 |
| 买方名称 | __________ | 合同自动带入 |
| 商品品种 | __________ | 买方填写 |
| 预估数量（头） | __________ | 买方填写 |
| 预估单价（元/头 或 元/公斤） | __________ | 买方填写 |
| 预估总金额（元） | __________ | 系统自动计算 = 数量 × 单价 |
| 定金金额（元） | __________ | 系统自动计算 = 预估总金额 × 定金比例 |
| 定金比例（%） | __________ | 合同自动带入（只读） |
| 期望交货时间 | __________ | 买方填写 |
| 车辆安排方 | __________ | 合同默认值，可修改 |
| 卖方收款银行 | __________ | 主体库自动带入（只读） |
| 卖方收款账号 | __________ | 主体库自动带入（只读） |
| 备注 | __________ | 可选 |
| 买方电子签章 | （签章区域） | |
| 卖方电子签章 | （签章区域） | |
| 买方签署日期 | __________ | |
| 卖方签署日期 | __________ |
关键说明：
- 订单中的金额为预估货款，用于计算定金
- 实际货款以验收后的结算单为准
- 定金金额 = 预估总金额 × 合同定金比例（系统自动计算，只读）
4.2 收货确认书（签收单）
《收货确认书》
| 字段 | 内容 | 来源 |
|---|---|---|
| 签收单编号 | HMT-RCV-YYYYMMDD-XXXX | 系统自动生成 |
| 关联子订单编号 | HMT-ORD-XXXXXX | 系统自动关联 |
| 关联主订单号 | HMT-MAIN-XXXXXX | 系统自动关联 |
| 卖方名称 | __________ | 订单自动带入 |
| 买方（收货方）名称 | __________ | 订单自动带入 |
| 商品品种 | __________ | 订单自动带入 |
| 订单数量（头） | __________ | 订单自动带入（只读） |
| 实际到货数量（头） | __________ | C 方实际清点填写 |
| 实际到货重量（公斤） | __________ | C 方实际称重填写（如适用） |
| 在途损耗数量（头） | __________ | 系统自动计算 = 订单数量 - 实际到货数量 |
| 损耗原因说明 | __________ | C 方填写 |
| 到货时间 | __________ | C 方填写 |
| 签收人姓名 | __________ | C 方填写 |
| 质量检验结果 | 合格 / 部分不合格 / 不合格 | C 方选择 |
| 质量问题说明 | __________ | 如有质量问题，C 方填写 |
| 收货方电子签章 | （签章区域） | C 方操作 |
| 签收日期 | __________ |
关键说明：
- 收货确认书记录的是实际到货情况，与订单预估可能存在差异
- 在途损耗数量 = 订单数量 - 实际到货数量（系统自动计算）
- 中间商的上游收货确认书由系统自动生成（品种/数量/重量与下游一致，仅更换双方名称/时间/编号）
4.3 结算单（最终货款）
《结算单》
| 字段 | 内容 | 来源 |
|---|---|---|
| 结算单编号 | HMT-STL-YYYYMMDD-XXXX | 系统自动生成 |
| 结算单类型 | 销售结算单 / 采购结算单 | 系统自动标注 |
| 关联子订单编号 | HMT-ORD-XXXXXX | 系统自动关联 |
| 关联收货确认书编号 | HMT-RCV-XXXXXX | 系统自动关联 |
| 卖方名称 | __________ | 订单自动带入 |
| 买方名称 | __________ | 订单自动带入 |
| 商品品种 | __________ | 收货确认书带入 |
| 实际数量（头） | __________ | 收货确认书带入（只读） |
| 实际重量（公斤） | __________ | 收货确认书带入（只读） |
| 结算单价（元/头 或 元/公斤） | __________ | 订单单价带入 |
| 订单原始金额（元） | __________ | 系统计算 = 订单数量 × 单价 |
| 损耗扣减金额（元） | __________ | 系统计算 = 损耗数量 × 单价 |
| 实际应结金额（元） | __________ | 系统计算 = 原始金额 - 损耗扣减 |
| 已付定金（元） | __________ | 系统自动带入（只读） |
| 待付余款（元） | __________ | 系统计算 = 实际应结金额 - 已付定金 |
| T+N 结算周期 | T+____ 天 | 合同自动带入（只读） |
| 结算到期日 | __________ | 系统计算 = 签章日 + N 天 |
| 买方电子签章 | （签章区域） | |
| 卖方电子签章 | （签章区域） | |
| L 核验签章（平台方） | （签章区域） | L 操作 |
| 签署日期 | __________ |
两种结算单的关系：
| 类型 | 含义 | 示例 |
|---|---|---|
| 销售结算单 | "我（卖方）应从下游收多少钱" | B1 的销售结算单 = C 应付给 B1 的金额 |
| 采购结算单 | "我（买方）应向上游付多少钱" | B1 的采购结算单 = B1 应付给 A 的金额 |
中间商同时拥有两种结算单，差额即为本层级毛利。
关键说明：
- 结算单记录的是最终货款，以实际到货为准
- 结算单金额 = 实际到货数量 × 单价 - 损耗扣减
- 余款 = 结算单金额 - 已付定金
- 上游采购结算单金额 = 下游销售结算单金额 × (1 - 毛利率%) 或 下游金额 - 每车固定值
4.4 三单三章关系总览
graph TB
subgraph "三单三章 — 每对买卖关系必须完成"
ORD[📄 订单
交易发起时签署
记录品种/数量/预估金额] RCV[📄 收货确认书
货物到达后签署
记录实际到货品种/数量/重量/损耗] STL[📄 结算单
收货确认后签署
记录实际应付金额] end ORD -->|"交易发起阶段"| RCV RCV -->|"验收完成后"| STL ORD -.->|"买方签章 + 卖方签章"| SIG1[双方电子签章] RCV -.->|"收货方签章"| SIG2[收货方电子签章] STL -.->|"买方签章 + 卖方签章 + L核验签章"| SIG3[三方电子签章]
交易发起时签署
记录品种/数量/预估金额] RCV[📄 收货确认书
货物到达后签署
记录实际到货品种/数量/重量/损耗] STL[📄 结算单
收货确认后签署
记录实际应付金额] end ORD -->|"交易发起阶段"| RCV RCV -->|"验收完成后"| STL ORD -.->|"买方签章 + 卖方签章"| SIG1[双方电子签章] RCV -.->|"收货方签章"| SIG2[收货方电子签章] STL -.->|"买方签章 + 卖方签章 + L核验签章"| SIG3[三方电子签章]
6
五、核心业务流程（含流程图）
5.0 总体业务闭环流程图（从订单到发票的完整链路）
graph TD
START([业务起点]) --> CONTRACT[合同签订与管理
智能识别 + 电子签章] CONTRACT --> ORDER[订单流转
C发起 → 逐级传导至A] ORDER --> DEPOSIT[定金支付
逐级线下转账 + 截图上传] DEPOSIT --> VEHICLE[车辆安排
F录入司机/车辆信息] VEHICLE --> TRANSIT[在途物流监管
F采集上传在途信息] TRANSIT --> ACCEPT[到货验收
C清点 → 三单三章] ACCEPT --> SETTLE[结算传导
C→B→A逐级传导] SETTLE --> PAY[货款支付
余款转账 + 对账台] PAY --> INVOICE[发票管理
货物发票 + 运输发票池] INVOICE --> FINISH([业务闭环完成]) TRANSIT -.->|在途异常| EX1[F记录 → M审批] ACCEPT -.->|验收异常| EX2[C举证 → L核验 → M裁定] SETTLE -.->|结算争议| EX3[争议方提交 → L复核 → M裁定] PAY -.->|逾期未付| EX4[系统标红 → L催收 → M跟进]
智能识别 + 电子签章] CONTRACT --> ORDER[订单流转
C发起 → 逐级传导至A] ORDER --> DEPOSIT[定金支付
逐级线下转账 + 截图上传] DEPOSIT --> VEHICLE[车辆安排
F录入司机/车辆信息] VEHICLE --> TRANSIT[在途物流监管
F采集上传在途信息] TRANSIT --> ACCEPT[到货验收
C清点 → 三单三章] ACCEPT --> SETTLE[结算传导
C→B→A逐级传导] SETTLE --> PAY[货款支付
余款转账 + 对账台] PAY --> INVOICE[发票管理
货物发票 + 运输发票池] INVOICE --> FINISH([业务闭环完成]) TRANSIT -.->|在途异常| EX1[F记录 → M审批] ACCEPT -.->|验收异常| EX2[C举证 → L核验 → M裁定] SETTLE -.->|结算争议| EX3[争议方提交 → L复核 → M裁定] PAY -.->|逾期未付| EX4[系统标红 → L催收 → M跟进]
5.1 合同签订与管理流程
flowchart TD
A1[N 录入交易主体信息
公司名称/信用代码/法人/地址/银行账户] --> A2{M 审核} A2 -->|通过| A3[主体已激活] A2 -->|驳回| A1 A3 --> A4[N 标注拓扑关系
选择两个主体标注买卖方向] A4 --> A5{系统校验} A5 -->|通过| A6[N 上传合同文件] A5 -->|反向关系/跨级跳跃| A4 A6 --> A7[触发智能识别
自动提取9项关键字段] A7 --> A8{识别校验} A8 -->|全部通过| A9[N 绑定三类单据模板
订单模板 + 收货确认书模板 + 结算单模板] A8 -->|有不通过项| A6 A9 --> A10[N 填写合同预置数据
定金比例/T+N/毛利率/叫车方] A10 --> A11[系统向双方发送签章请求] A11 --> A12[甲方电子签章] A11 --> A13[乙方电子签章] A12 --> A14{双方均已签章?} A13 --> A14 A14 -->|是| A15[合同状态 → 已生效 ✅] A14 -->|否| A11
公司名称/信用代码/法人/地址/银行账户] --> A2{M 审核} A2 -->|通过| A3[主体已激活] A2 -->|驳回| A1 A3 --> A4[N 标注拓扑关系
选择两个主体标注买卖方向] A4 --> A5{系统校验} A5 -->|通过| A6[N 上传合同文件] A5 -->|反向关系/跨级跳跃| A4 A6 --> A7[触发智能识别
自动提取9项关键字段] A7 --> A8{识别校验} A8 -->|全部通过| A9[N 绑定三类单据模板
订单模板 + 收货确认书模板 + 结算单模板] A8 -->|有不通过项| A6 A9 --> A10[N 填写合同预置数据
定金比例/T+N/毛利率/叫车方] A10 --> A11[系统向双方发送签章请求] A11 --> A12[甲方电子签章] A11 --> A13[乙方电子签章] A12 --> A14{双方均已签章?} A13 --> A14 A14 -->|是| A15[合同状态 → 已生效 ✅] A14 -->|否| A11
步骤说明：
- N 录入交易主体：录入 A/B/C 各方公司名称、统一社会信用代码、法定代表人、地址、联系方式、银行账户（开户行+账号+户名）、主体类型。上传营业执照扫描件。
- N 标注拓扑关系：选择两个已激活主体，标注买卖方向。系统强制校验不允许反向关系和跨级跳跃。
- N 上传合同：选择对应买卖双方，上传合同文件，触发智能识别自动提取 9 项关键字段。
- 绑定模板 + 填写预置数据：从 T 预置的模板库中选择三类单据模板，填写定金比例、T+N 值、基础毛利率、默认叫车方。
- 双方电子签章：双方均完成签章后合同生效。
5.2 订单流转与定金支付流程
flowchart TD
B1[C 在新建订单页
选择交易对象 → 填写订单内容] --> B2[C 进行电子签章] B2 --> B3[C 线下银行转账定金
上传付款截图] B3 --> B4[系统推送至卖方工作台] B4 --> B5[卖方第一步：确认已收到定金
查看C的付款截图] B5 --> B6[卖方第二步：确认叫车方
买方/卖方/第三方] B6 --> B7[卖方第三步：电子签章] B7 --> B8[订单 C→卖方 生效 ✅] B8 --> B9{卖方是中间商B?} B9 -->|是| B10[B向上游发起采购订单
流程与C发起完全一致] B10 --> B11[上游卖方三步确认] B11 --> B12{已到达最上游A?} B12 -->|否| B10 B12 -->|是| B13[全链订单闭合 ✅
触发车辆安排] B9 -->|否,卖方就是A| B13
选择交易对象 → 填写订单内容] --> B2[C 进行电子签章] B2 --> B3[C 线下银行转账定金
上传付款截图] B3 --> B4[系统推送至卖方工作台] B4 --> B5[卖方第一步：确认已收到定金
查看C的付款截图] B5 --> B6[卖方第二步：确认叫车方
买方/卖方/第三方] B6 --> B7[卖方第三步：电子签章] B7 --> B8[订单 C→卖方 生效 ✅] B8 --> B9{卖方是中间商B?} B9 -->|是| B10[B向上游发起采购订单
流程与C发起完全一致] B10 --> B11[上游卖方三步确认] B11 --> B12{已到达最上游A?} B12 -->|否| B10 B12 -->|是| B13[全链订单闭合 ✅
触发车辆安排] B9 -->|否,卖方就是A| B13
C 填写订单内容：
- 商品品种、数量（头/公斤）、期望交货时间
- 系统自动填入（只读）：定金比例、卖方银行账户、默认叫车方
定金支付关键规则：
- 定金金额 = 订单总金额 × 合同定金比例（系统自动计算，只读展示）
- 付款方式：线下银行转账（系统不处理资金，只做凭证管理）
- 截图不可删除、不可修改（只读存档）
- 全链每一层定金支付均需上传截图，均需上游确认收款
5.3 车辆安排与物流派车流程
flowchart TD
C1[全链订单闭合
系统推送F工作台] --> C2[F 联系叫车方
获取司机/车辆信息] C2 --> C3[F 录入车辆信息
司机姓名/电话/车牌/载重/照片/承运公司] C3 --> C4[系统将车辆信息关联至
主订单号下所有子订单] C4 --> C5[全链 A/B/C 均可查询
司机状态信息] C5 --> C6[进入在途监管流程] C3 -.->|车辆安排修改| C7{修改权限判定} C7 -->|原填写方| C8[经相关方同意后修改] C7 -->|F专管员| C9[直接修改
系统赋权无需其他确认]
系统推送F工作台] --> C2[F 联系叫车方
获取司机/车辆信息] C2 --> C3[F 录入车辆信息
司机姓名/电话/车牌/载重/照片/承运公司] C3 --> C4[系统将车辆信息关联至
主订单号下所有子订单] C4 --> C5[全链 A/B/C 均可查询
司机状态信息] C5 --> C6[进入在途监管流程] C3 -.->|车辆安排修改| C7{修改权限判定} C7 -->|原填写方| C8[经相关方同意后修改] C7 -->|F专管员| C9[直接修改
系统赋权无需其他确认]
车辆安排字段锁定规则：
- 初始状态：叫车方字段可空
- 一旦任意一方填写叫车人信息：字段锁定，不可自由修改
- 修改已锁定车辆安排：仅允许原填写方（经他方同意）或 F 专管员
5.4 在途物流监管流程
flowchart TD
D1[F 设置监管计划] --> D2{监管模式}
D2 -->|时间节点式| D3[每隔X小时要求上报状态]
D2 -->|地理节点式| D4[到达指定途经点上报]
D3 --> D5[是否要求GPS共享]
D4 --> D5
D5 --> D6[货物装车发出]
D6 --> D7[按监管计划触发提醒]
D7 --> D8[司机通过微信
发送照片/视频/位置截图/检疫证] D8 --> D9[F 接收微信信息
上传至系统物流档案] D9 --> D10[全链A/B/C可查看
物流档案（只读）] D10 --> D11{有在途异常?} D11 -->|无| D7 D11 -->|活体死亡| D12[F记录死亡数量/照片/时间] D11 -->|车辆故障| D13[F更新故障原因/预计恢复时间] D11 -->|配送延迟| D14[F记录延迟原因] D12 --> D15{超M设定损耗阈值?} D15 -->|是| D16[系统提醒M审批] D15 -->|否| D17[F记录在案
验收时按实际数量结算] D13 --> D18[系统通知全链各方] D14 --> D18 D10 --> D19[货物到达C方]
发送照片/视频/位置截图/检疫证] D8 --> D9[F 接收微信信息
上传至系统物流档案] D9 --> D10[全链A/B/C可查看
物流档案（只读）] D10 --> D11{有在途异常?} D11 -->|无| D7 D11 -->|活体死亡| D12[F记录死亡数量/照片/时间] D11 -->|车辆故障| D13[F更新故障原因/预计恢复时间] D11 -->|配送延迟| D14[F记录延迟原因] D12 --> D15{超M设定损耗阈值?} D15 -->|是| D16[系统提醒M审批] D15 -->|否| D17[F记录在案
验收时按实际数量结算] D13 --> D18[系统通知全链各方] D14 --> D18 D10 --> D19[货物到达C方]
重要约束：本系统为私域平台，司机无法登录系统，一切信息由 F 作为中间人（司机↔F↔系统 的唯一通道）。
5.5 到货验收、签收单与结算流程（三单三章）
flowchart TD
E1[货物到达C方] --> E2[C 核验货物
品种/数量/重量/质量/损耗] E2 --> E3[C 同步填写并电子签章] E3 --> E3A[① 收货确认书
实际品种/数量/重量/损耗/签收时间] E3 --> E3B[② 结算单
原始金额-损耗扣减-定金=余款] E3A --> E4[提交至L工作台] E3B --> E4 E4 --> E5[L 核验两份文件] E5 --> E6{核验结果} E6 -->|损耗超阈值| E7[系统提醒M审批 → M裁定] E6 -->|数量/金额异常| E8[走异常处理流程] E6 -->|核验通过| E9[L 在结算单上电子签章
代平台方核验] E7 --> E9 E9 --> E10[结算传导至上游中间商] E10 --> E11[系统通知B: 下游结算单已核验通过] E11 --> E12[B 对下游销售结算单电子签章
确认应收金额] E12 --> E13[系统自动生成上游采购结算单
金额=下游金额×1-毛利率%或-固定值] E13 --> E14[系统自动生成上游收货确认书
品种/数量/重量与下游一致] E14 --> E15[B 对上游采购结算单+收货确认书电子签章] E15 --> E16{已传导至A?} E16 -->|否| E10 E16 -->|是| E17[A 对采购结算单+收货确认书电子签章] E17 --> E18[全链三单三章闭合完成 ✅]
品种/数量/重量/质量/损耗] E2 --> E3[C 同步填写并电子签章] E3 --> E3A[① 收货确认书
实际品种/数量/重量/损耗/签收时间] E3 --> E3B[② 结算单
原始金额-损耗扣减-定金=余款] E3A --> E4[提交至L工作台] E3B --> E4 E4 --> E5[L 核验两份文件] E5 --> E6{核验结果} E6 -->|损耗超阈值| E7[系统提醒M审批 → M裁定] E6 -->|数量/金额异常| E8[走异常处理流程] E6 -->|核验通过| E9[L 在结算单上电子签章
代平台方核验] E7 --> E9 E9 --> E10[结算传导至上游中间商] E10 --> E11[系统通知B: 下游结算单已核验通过] E11 --> E12[B 对下游销售结算单电子签章
确认应收金额] E12 --> E13[系统自动生成上游采购结算单
金额=下游金额×1-毛利率%或-固定值] E13 --> E14[系统自动生成上游收货确认书
品种/数量/重量与下游一致] E14 --> E15[B 对上游采购结算单+收货确认书电子签章] E15 --> E16{已传导至A?} E16 -->|否| E10 E16 -->|是| E17[A 对采购结算单+收货确认书电子签章] E17 --> E18[全链三单三章闭合完成 ✅]
三单三章概念： 每一对买卖关系中，必须完成三份签章文件，缺一不可。
| 文件 | 签署时间 | 内容 |
|---|---|---|
| 订单 | 交易发起时 | 商品、数量、金额、交易条件 |
| 收货确认书（签收单） | 货物到达后 | 实际收货品种、数量、重量、损耗 |
| 结算单 | 收货确认后 | 应付金额（含损耗扣减） |
5.6 货款支付与对账台
flowchart TD
F1[全链结算单确认] --> F2[系统计算各层级余款
余款=结算金额-已付定金] F2 --> F3[各买方在对账台
查看待付款项+到期倒计时] F3 --> F4[买方线下银行转账] F4 --> F5[买方上传付款截图] F5 --> F6[卖方确认收款] F6 --> F7[该笔款项状态→已支付 ✅] F3 --> F8{T+N倒计时} F8 -->|到期前3天| F9[系统推送催款提醒
每日一次] F8 -->|逾期当天| F10[款项标红
通知L和M] F10 --> F11[L发催收通知
M记录催收日志]
余款=结算金额-已付定金] F2 --> F3[各买方在对账台
查看待付款项+到期倒计时] F3 --> F4[买方线下银行转账] F4 --> F5[买方上传付款截图] F5 --> F6[卖方确认收款] F6 --> F7[该笔款项状态→已支付 ✅] F3 --> F8{T+N倒计时} F8 -->|到期前3天| F9[系统推送催款提醒
每日一次] F8 -->|逾期当天| F10[款项标红
通知L和M] F10 --> F11[L发催收通知
M记录催收日志]
对账台视图：
| 字段 | 说明 |
|---|---|
| 子订单号 | 唯一标识 |
| 收/付款方 | 对应交易方名称 |
| 结算总额 | 结算单金额 |
| 已付定金 | 已支付定金金额 |
| 待付余款 | 结算总额 - 已付定金 |
| T+N（天） | 结算周期 |
| 到期日 | T + N 天 |
| 状态 | 待支付（绿）/ 即将到期（橙，≤3天）/ 已逾期（红）/ 已完成（灰） |
C 只有应付视图；A 只有应收视图；B1-B3 两个视图均有。
5.7 发票管理
flowchart TD
G1[结算单状态→已支付] --> G2[系统提醒卖方开具发票]
G2 --> G3[卖方线下开具增值税发票]
G3 --> G4[卖方上传发票照片/扫描件
点击已开票] G4 --> G5[买方确认收到发票] G5 --> G6[发票状态→已完结 ✅] G2 -.->|逾期未开票| G7[系统每日提醒卖方
L人工跟进] subgraph "运输发票池（F管理）" H1[车次完成] --> H2[F录入运输发票信息] H2 --> H3{发票状态管理} H3 --> H3A[已开具-已到手] H3 --> H3B[已开具-未到手] H3 --> H3C[待开具-已告知] H3 --> H3D[待开具-未告知] H3 --> H3E[代开中] end
点击已开票] G4 --> G5[买方确认收到发票] G5 --> G6[发票状态→已完结 ✅] G2 -.->|逾期未开票| G7[系统每日提醒卖方
L人工跟进] subgraph "运输发票池（F管理）" H1[车次完成] --> H2[F录入运输发票信息] H2 --> H3{发票状态管理} H3 --> H3A[已开具-已到手] H3 --> H3B[已开具-未到手] H3 --> H3C[待开具-已告知] H3 --> H3D[待开具-未告知] H3 --> H3E[代开中] end
运输发票池字段：
| 字段 | 说明 |
|---|---|
| 主订单号 | 关联批次货物 |
| 运费金额 | 该车次实际运费 |
| 承运人/司机 | 承运公司或司机姓名 |
| 开票主体名称 | 要求开票的公司 |
| 开票主体税号 | 对应税号 |
| 联系人及电话 | 发票对接人 |
| 发票状态 | 已开具（已到手/未到手）/ 待开具（已告知/未告知）/ 代开中 |
| 备注 | 特殊说明 |
5.8 异常处理流程
flowchart TD
EX[异常事件] --> EX1{异常类型}
EX1 -->|在途异常| T1[活体死亡/车辆故障/配送延迟]
T1 --> T2[F记录并上传]
T2 --> T3{超阈值?}
T3 -->|是| T4[M审批裁定]
T3 -->|否| T5[F记录在案
按实际数量结算] EX1 -->|验收异常| V1[数量不符/品种不符/质量问题] V1 --> V2[C提交证据] V2 --> V3[L核验] V3 --> V4[M审批裁定
退货/折价/补货] EX1 -->|订单异常| O1[取消订单/修改订单] O1 --> O2[发起方提交申请] O2 --> O3[对方确认] O3 --> O4[M审批] O4 --> O5[双方重新签章] EX1 -->|结算异常| S1[金额争议/损耗超阈值/逾期未付] S1 --> S2[争议方提交异议] S2 --> S3[L复核] S3 --> S4[M最终裁定] EX1 -->|合同异常| C1[变更/争议/终止] C1 -->|变更| C2[N上传补充协议→双方重签→M审批] C1 -->|争议| C3[争议方提交证据→M查看全链数据裁定] C1 -->|终止| C4[M独占操作] EX1 -->|发票异常| I1[货物发票逾期/运输发票缺失] I1 --> I2[系统提醒 + L/F人工跟进]
按实际数量结算] EX1 -->|验收异常| V1[数量不符/品种不符/质量问题] V1 --> V2[C提交证据] V2 --> V3[L核验] V3 --> V4[M审批裁定
退货/折价/补货] EX1 -->|订单异常| O1[取消订单/修改订单] O1 --> O2[发起方提交申请] O2 --> O3[对方确认] O3 --> O4[M审批] O4 --> O5[双方重新签章] EX1 -->|结算异常| S1[金额争议/损耗超阈值/逾期未付] S1 --> S2[争议方提交异议] S2 --> S3[L复核] S3 --> S4[M最终裁定] EX1 -->|合同异常| C1[变更/争议/终止] C1 -->|变更| C2[N上传补充协议→双方重签→M审批] C1 -->|争议| C3[争议方提交证据→M查看全链数据裁定] C1 -->|终止| C4[M独占操作] EX1 -->|发票异常| I1[货物发票逾期/运输发票缺失] I1 --> I2[系统提醒 + L/F人工跟进]
全局原则：
- 所有异常均有完整操作审计日志（谁操作/何时/做了什么/系统状态变化）
- M 为所有异常的最终裁定人
- M 可查看任意一笔交易的全链路完整数据
7
六、物流监管信息采集全景
说明： F 是司机与系统之间的唯一信息桥梁。由于系统为私域平台，司机无法登录系统，F 需要在多个业务节点从司机处采集大量信息并上传至系统。以下按业务节点逐一归纳。
节点一：车辆安排阶段
触发时机： 全链订单闭合后，F 工作台收到"待安排车辆"通知
| 序号 | 采集信息 | 信息来源 | 采集方式 | 上传位置 | 是否必填 |
|---|---|---|---|---|---|
| F-01 | 司机姓名 | 叫车方/司机本人 | 线下沟通 | 车辆信息表 | ✅ |
| F-02 | 司机联系电话 | 叫车方/司机本人 | 线下沟通 | 车辆信息表 | ✅ |
| F-03 | 司机身份证号 | 司机本人 | 微信发送 | 车辆信息表 | 可选 |
| F-04 | 车牌号码 | 叫车方/司机本人 | 线下沟通 | 车辆信息表 | ✅ |
| F-05 | 车辆载重（吨） | 司机/承运商 | 线下沟通 | 车辆信息表 | ✅ |
| F-06 | 车辆照片 | 司机微信发送 | F 转存上传 | 车辆信息表 | ✅ |
| F-07 | 承运公司名称 | 叫车方/承运商 | 线下沟通 | 车辆信息表 | ✅ |
节点二：在途监管计划设置
触发时机： 车辆信息录入完成后
| 序号 | 操作项 | 说明 | 是否必填 |
|---|---|---|---|
| F-08 | 选择监管模式 | 时间节点式（每X小时上报）或 地理节点式（到达指定地点上报） | ✅ |
| F-09 | 设置时间间隔/途经点 | 时间节点式填写小时数；地理节点式填写途经点名称 | ✅ |
| F-10 | 是否要求 GPS 实时共享 | 是/否。若是，需要求司机在微信开启实时位置共享 | ✅ |
节点三：在途定期上报（按监管计划循环执行）
触发时机： 每到达一个监管节点（时间节点或地理节点），由系统提醒 F 采集
| 序号 | 采集信息 | 信息来源 | 采集方式 | 上传位置 | 是否必填 |
|---|---|---|---|---|---|
| F-11 | 在途照片（货物状态照片） | 司机微信发送 | F 截图/保存后上传 | 物流档案 → 在途记录 | ✅ |
| F-12 | 在途视频（短视频） | 司机微信发送 | F 保存后上传 | 物流档案 → 在途记录 | 可选 |
| F-13 | GPS 位置截图 | F 截图微信 GPS 共享界面 | F 截图上传 | 物流档案 → 在途记录 | 视计划要求 |
| F-14 | GPS 轨迹截图 | F 截图微信 GPS 轨迹 | F 截图上传 | 物流档案 → 在途记录 | 可选 |
| F-15 | 当前所在位置描述 | 司机口述/微信文字 | F 手动录入 | 物流档案 → 在途记录 | ✅ |
| F-16 | 上报时间 | 系统自动记录 | 自动 | 物流档案 → 在途记录 | 自动 |
节点四：检疫证管理
触发时机： 司机装车出发后（或在途中获取）
| 序号 | 采集信息 | 信息来源 | 采集方式 | 上传位置 | 是否必填 |
|---|---|---|---|---|---|
| F-17 | 动物检疫合格证照片 | 司机微信发送照片 | F 保存后上传 | 物流档案 → 检疫证区 | ✅ |
| F-18 | 检疫证编号 | F 从照片中辨识 | F 手动录入 | 物流档案 → 检疫证区 | ✅ |
| F-19 | 发证机关 | F 从照片中辨识 | F 手动录入 | 物流档案 → 检疫证区 | 可选 |
| F-20 | 有效期 | F 从照片中辨识 | F 手动录入 | 物流档案 → 检疫证区 | 可选 |
节点五：在途异常记录
触发时机： 在途期间发生异常事件
| 序号 | 采集信息 | 信息来源 | 采集方式 | 上传位置 | 场景 |
|---|---|---|---|---|---|
| F-21 | 死亡/病伤数量 | 司机上报 | F 手动录入 | 异常记录区 | 活体死亡 |
| F-22 | 死亡/病伤照片 | 司机微信发送 | F 保存后上传 | 异常记录区 | 活体死亡 |
| F-23 | 死亡/病伤时间 | 司机上报 | F 手动录入 | 异常记录区 | 活体死亡 |
| F-24 | 死亡/病伤原因说明 | 司机上报/F判断 | F 手动录入 | 异常记录区 | 活体死亡 |
| F-25 | 故障原因描述 | 司机上报 | F 手动录入 | 异常记录区 | 车辆故障 |
| F-26 | 预计恢复时间 | 司机预估 | F 手动录入 | 异常记录区 | 车辆故障 |
| F-27 | 故障现场照片 | 司机微信发送 | F 保存后上传 | 异常记录区 | 车辆故障 |
| F-28 | 延迟原因说明 | 司机/F判断 | F 手动录入 | 异常记录区 | 配送延迟 |
| F-29 | 预计到达时间 | 司机预估 | F 手动录入 | 异常记录区 | 配送延迟 |
节点六：运输发票管理（车次完成后）
触发时机： 运输任务完成，货物已到达 C 方
| 序号 | 操作项 | 信息来源 | 采集方式 | 上传位置 | 是否必填 |
|---|---|---|---|---|---|
| F-30 | 运费金额 | 承运商/叫车方 | F 手动录入 | 运输发票池 | ✅ |
| F-31 | 开票主体名称 | 交易方要求 | F 手动录入 | 运输发票池 | ✅ |
| F-32 | 开票主体税号 | 交易方提供 | F 手动录入 | 运输发票池 | ✅ |
| F-33 | 发票联系人及电话 | 承运商/司机 | F 手动录入 | 运输发票池 | ✅ |
| F-34 | 发票状态 | F 跟踪更新 | F 手动选择 | 运输发票池 | ✅ |
| F-35 | 运输发票照片/扫描件 | 司机/承运商寄送 | F 拍照上传 | 运输发票池 | 到手后必传 |
| F-36 | 备注 | F 记录 | F 手动录入 | 运输发票池 | 可选 |
F 信息采集量统计汇总
| 业务节点 | 采集项数量 | 涉及信息类别 |
|---|---|---|
| 车辆安排 | 7 项 | 司机个人信息、车辆信息、承运商信息 |
| 监管计划设置 | 3 项 | 监管模式、时间/地理参数、GPS 要求 |
| 在途定期上报 | 6 项/次 | 照片、视频、GPS、位置描述 |
| 检疫证管理 | 4 项 | 检疫合格证照片及关键字段 |
| 在途异常 | 最多 9 项/次 | 死亡/故障/延迟的详细记录 |
| 运输发票 | 7 项 | 运费、开票主体、发票状态 |
| 合计（单次完整运输） | 约 36 项（不含循环上报） |
建议：鉴于 F 信息采集量大且场景多变，移动端应为 F 设计快速上传入口（一键拍照上传、批量图片上传、语音转文字录入等），降低操作负担。
8
七、各端功能一览
7.1 T 管理后台
| 功能模块 | 功能点 |
|---|---|
| 业务元数据管理 | 定义品种库（生猪/肉牛品种分类）、物流字段、主体字段、损耗字段 |
| 单据模板管理 | 创建/编辑/发布 订单模板、收货确认书模板、结算单模板 |
| 签章与识别服务管理 | 电子签章服务管理与测试、智能识别服务管理与测试 |
| 系统运行监控 | 系统运行状态、存储使用情况、服务健康检查 |
7.2 M 管理端（电脑 + 手机）
| 功能模块 | 电脑端 | 手机端 |
|---|---|---|
| 工作台（待审批/异常/逾期预警） | ✅ | ✅ |
| 权限配置（21 项可配置权限下放管理） | ✅ | ✅ |
| 风险阈值设置 | ✅ | ✅ |
| 统计看板（交易量/财务/发票） | ✅ | ✅ 重点 |
| 全链路数据查看 | ✅ | ✅ |
| 审批操作 | ✅ | ✅ |
| 催收日志 | ✅ | ✅ |
7.3 N 操作端
| 功能模块 | 说明 |
|---|---|
| 主体管理 | 录入/修改/查看 A/B/C 主体信息 |
| 拓扑关系 | 标注/查看上下游关系 |
| 合同管理 | 上传合同 → 智能识别 → 绑定模板 → 预置数据 → 协调签章 |
| 订单管理 | 代操作订单（M 授权场景）、跟进订单状态 |
| 工作台 | 待确认订单、待发起采购、待上传截图、合同到期提醒 |
7.4 F 物流端
| 功能模块 | 说明 |
|---|---|
| 承运商/司机库 | 维护承运商、司机、车辆信息 |
| 车辆安排 | 录入/修改车辆及司机信息 |
| 在途监管 | 设置监管计划、上传在途信息（照片/视频/GPS/检疫证） |
| 异常记录 | 在途异常（死亡/故障/延迟）的详细记录 |
| 运输发票池 | 录入/更新运输发票信息及状态 |
| 工作台 | 待安排车辆、待上传在途信息、待登记发票、异常记录 |
7.5 L 财务端
| 功能模块 | 说明 |
|---|---|
| 签收单核验 | 核验 C 方提交的收货确认书 |
| 结算单核验 | 核验 C 方提交的结算单，L 签章确认 |
| 结算传导 | 驱动生成上游采购结算单 |
| 对账台 | 查看全链应收/应付款项 |
| 催收管理 | 逾期账款催收跟进 |
| 发票跟进 | 催促卖方开票、确认收票 |
| 工作台 | 待核验、待传导、异常处理、逾期催收 |
7.6 A/B/C 交易方客户端
| 功能模块 | A（供货方） | B（中间商） | C（收货方） |
|---|---|---|---|
| 接收/发起订单 | ✅ 接收 | ✅ 接收+发起 | ✅ 发起 |
| 电子签章 | ✅ | ✅ | ✅ |
| 定金支付截图上传 | ✅ 向上游付 | ✅ 向卖方付 | |
| 确认收到定金 | ✅ | ✅ | |
| 查看物流档案 | ✅ 只读 | ✅ 只读 | ✅ 只读 |
| 验收货物+三单三章 | ✅ 发起方 | ||
| 签署结算单 | ✅ | ✅ | ✅ |
| 对账台（应收） | ✅ | ✅ | |
| 对账台（应付） | ✅ | ✅ | |
| 货物发票（开票/确认） | ✅ 开票 | ✅ 开票+确认 | ✅ 确认 |
| 申请运输发票 | ✅ | ✅ | ✅ |
9
八、工作台与经营看板
8.1 各角色工作台
每个平台角色拥有专属工作台，工作台以"待办事项数量徽标"组织，确保无遗漏、优先级清晰。
M 方工作台：
- 待审批（主体审核、合同变更、订单修改/取消、损耗超阈值）
- 异常待处理（验收异常、品种不符、质量问题）
- 逾期预警（逾期未付款列表，每日更新）
- 权限配置（随时可调整 N/F/L 权限）
N 方工作台：
- 待确认下游订单
- 待发起上游采购订单
- 待上传付款截图
- 合同即将到期提醒（≤30 天）
- 待审核主体信息（如 M 授权）
F 方工作台：
- 待安排车辆
- 待上传在途信息（按监管计划触发）
- 待登记运输发票
- 待跟进运输发票（已登记未到手）
- 异常在途记录
L 方工作台：
- 待核验收货确认书
- 待核验结算单
- 待驱动上游结算传导
- 异常结算待处理
- 逾期催收跟进列表
A/B/C 外部用户待办：
- 待确认订单
- 待签章（订单/结算单/收货确认书）
- 待上传付款截图
- 待确认收款
- 待确认货物（C 方专有）
- 对账台（应付/应收视图）
- 发票状态
8.2 M 端统计看板
M 通过手机端可查看以下统计看板（支持多维交叉筛选）：
维度筛选器：
- 按角色：A / B1 / B2 / B3 / C（可多选）
- 按品种：生猪 / 肉牛（可多选）
- 按时间：日 / 周 / 月 / 自定义日期区间
核心指标卡：
| 指标分类 | 指标项 |
|---|---|
| 交易量统计 | 采购量（头数/重量）、销售量（头数/重量）、在途数量（主订单维度） |
| 财务统计 | 平台总应收金额、平台总应付金额、今日到期金额、逾期金额及笔数、按交易方的余额明细 |
| 发票统计 | 货物发票开具率（已开/应开）、运输发票未到手金额汇总 |
10
九、项目实施路径
9.1 阶段划分
| 阶段 | 内容 | 产出物 |
|---|---|---|
| P0：基础建设 | 系统基础环境搭建与部署 | 可运行的基础环境 |
| P1：核心链路 | 合同管理、订单流转、定金支付、三单三章、结算传导 | 最小可用系统（MVP） |
| P2：物流+财务 | 车辆安排、在途监管、对账台、发票管理 | 完整业务闭环 |
| P3：管理+运营 | 权限配置、统计看板、异常处理、催收管理 | 管理工具完备 |
| P4：上线准备 | 数据迁移、模拟演练、用户培训 | 具备上线条件 |
9.2 上线前各角色准备任务
T（IT 管理员）：
- 定义全部业务元数据（品种库、物流字段、主体字段、损耗字段）
- 配置单据模板库（订单/收货确认书/结算单标准模板）
- 电子签章服务接入测试
- 智能合同识别服务测试（9 项关键字段提取准确率）
- 系统基础环境部署，数据备份策略验证
M（首席管理员）：
- 权限配置（21 项权限分配给 N/F/L）
- 风险阈值设置（最低定金比例、最大 T+N 天数、允许损耗范围）
- 审批规则定义
N（权限管理员）：
- 录入全部 A/B/C 主体信息（含银行账户）
- 标注拓扑关系
- 上传合同（智能识别+模板绑定+预置数据+协调签章）
- 协调 A/B/C 完成企业电子签章证书申请
F（物流专管员）：
- 录入承运商/司机数据库
- 测试移动端在现场的可用性（文件/图片上传）
- 与承运商/司机确认信息传递方式
9.3 上线前模拟演练（7 天）
| 日程 | 主导方 | 演练内容 |
|---|---|---|
| Day 1-2 | T | 验证系统环境/电子签章/智能识别服务正常；完成模拟合同智能识别+电子签章测试；单据模板预览确认 |
| Day 3 | M | 验证权限配置；验证风险阈值生效；走一遍审批流程 |
| Day 4-6 | N + F | 模拟完整业务链路（形态三 A→B1→C）：录入主体→拓扑→合同→订单→定金→车辆→在途→验收→结算→付款→发票 |
| Day 7 | 全员 | 并行业务测试（同时 2-3 笔业务）；异常场景测试（损耗超阈值）；问题汇总修正；M 宣布是否满足上线条件 |
11
十、投入与成本优势
10.1 多端覆盖，一次投入
系统采用一次开发、多端运行的设计策略，手机端（iOS + Android）与电脑端共享同一套业务逻辑和界面设计，避免为每个平台重复开发，大幅节省开发投入。
10.2 快速上线，免除行政审批
系统部署方案经过精心设计，省去了传统方案中耗时 2-4 周的网络备案审批流程及年度维护费用，项目可以更快投入使用。
10.3 零支付手续费
系统不接入第三方支付平台，所有资金往来通过线下银行转账完成，系统仅做凭证管理和对账。每笔交易零支付手续费，对于大额牲畜交易场景，长期节省金额可观。
10.4 企业微信替代短信，降低通知成本
业务通知（订单确认、签章请求、逾期催款、异常告警等）优先通过企业微信消息推送触达用户，大幅降低短信发送成本。短信仅作为兜底通道用于验证码和关键通知。
10.5 系统运维成本
系统上线后，月度基础设施运维成本约 ¥4,000 - 5,000 / 月，涵盖全部基础设施费用。随业务量增长可弹性扩展，按需付费。
12
附录：完整业务闭环流程图
以【形态三：A→B1→C】为例，展示从订单发起到全链发票完成的完整业务闭环。
flowchart TD
subgraph PHASE0["阶段零：前置准备（一次性）"]
P0A[T 配置字段/模板库] --> P0B[M 配置权限/风险阈值]
P0B --> P0C[N 录入主体 A/B1/C
标注拓扑 A→B1→C] P0C --> P0D[N 上传合同 A-B1
智能识别→模板绑定→电子签章→生效] P0C --> P0E[N 上传合同 B1-C
智能识别→模板绑定→电子签章→生效] end subgraph PHASE1["阶段一：订单发起+定金支付"] P1A[C 选择卖方 B1
填写订单 → 电子签章] --> P1B[C 线下转账定金
上传付款截图] P1B --> P1C[B1 确认收定金
确认叫车方 → 电子签章] P1C --> P1D[订单 B1-C 生效] P1D --> P1E[B1 向 A 发起采购订单
电子签章 + 转账定金] P1E --> P1F[A 确认收定金
确认叫车方 → 电子签章] P1F --> P1G[订单 A-B1 生效
全链订单闭合] end subgraph PHASE2["阶段二：车辆安排"] P2A[F 联系叫车方
获取司机/车辆信息] --> P2B[F 录入系统
关联至主订单号] P2B --> P2C[全链 A/B1/C
可查询司机信息] end subgraph PHASE3["阶段三：在途监管"] P3A[F 设置监管计划] --> P3B[货物装车发出] P3B --> P3C[按计划采集上传
照片/GPS/检疫证] P3C --> P3D{在途异常?} P3D -->|无| P3E[货物到达C方] P3D -->|有| P3F[F记录 → M审批] P3F --> P3E end subgraph PHASE4["阶段四：验收+三单三章"] P4A[C 核验货物] --> P4B[C 签章: 收货确认书+结算单] P4B --> P4C[L 核验 → 电子签章] P4C --> P4D[B1 签章确认
系统生成上游采购结算单+收货确认书] P4D --> P4E[A 签章确认
全链三单三章闭合] end subgraph PHASE5["阶段五：货款支付"] P5A[C 对账台查看余款
线下付款→上传截图] --> P5B[B1 确认收款] P5B --> P5C[B1 对账台查看对A余款
线下付款→上传截图] P5C --> P5D[A 确认收款] end subgraph PHASE6["阶段六：发票管理"] P6A[B1 为C开具增值税发票
C确认收到] --> P6B[A 为B1开具增值税发票
B1确认收到] P6B --> P6C[F 管理运输发票池] end PHASE0 --> PHASE1 PHASE1 --> PHASE2 PHASE2 --> PHASE3 PHASE3 --> PHASE4 PHASE4 --> PHASE5 PHASE5 --> PHASE6 PHASE6 --> DONE([业务闭环完成 ✅])
标注拓扑 A→B1→C] P0C --> P0D[N 上传合同 A-B1
智能识别→模板绑定→电子签章→生效] P0C --> P0E[N 上传合同 B1-C
智能识别→模板绑定→电子签章→生效] end subgraph PHASE1["阶段一：订单发起+定金支付"] P1A[C 选择卖方 B1
填写订单 → 电子签章] --> P1B[C 线下转账定金
上传付款截图] P1B --> P1C[B1 确认收定金
确认叫车方 → 电子签章] P1C --> P1D[订单 B1-C 生效] P1D --> P1E[B1 向 A 发起采购订单
电子签章 + 转账定金] P1E --> P1F[A 确认收定金
确认叫车方 → 电子签章] P1F --> P1G[订单 A-B1 生效
全链订单闭合] end subgraph PHASE2["阶段二：车辆安排"] P2A[F 联系叫车方
获取司机/车辆信息] --> P2B[F 录入系统
关联至主订单号] P2B --> P2C[全链 A/B1/C
可查询司机信息] end subgraph PHASE3["阶段三：在途监管"] P3A[F 设置监管计划] --> P3B[货物装车发出] P3B --> P3C[按计划采集上传
照片/GPS/检疫证] P3C --> P3D{在途异常?} P3D -->|无| P3E[货物到达C方] P3D -->|有| P3F[F记录 → M审批] P3F --> P3E end subgraph PHASE4["阶段四：验收+三单三章"] P4A[C 核验货物] --> P4B[C 签章: 收货确认书+结算单] P4B --> P4C[L 核验 → 电子签章] P4C --> P4D[B1 签章确认
系统生成上游采购结算单+收货确认书] P4D --> P4E[A 签章确认
全链三单三章闭合] end subgraph PHASE5["阶段五：货款支付"] P5A[C 对账台查看余款
线下付款→上传截图] --> P5B[B1 确认收款] P5B --> P5C[B1 对账台查看对A余款
线下付款→上传截图] P5C --> P5D[A 确认收款] end subgraph PHASE6["阶段六：发票管理"] P6A[B1 为C开具增值税发票
C确认收到] --> P6B[A 为B1开具增值税发票
B1确认收到] P6B --> P6C[F 管理运输发票池] end PHASE0 --> PHASE1 PHASE1 --> PHASE2 PHASE2 --> PHASE3 PHASE3 --> PHASE4 PHASE4 --> PHASE5 PHASE5 --> PHASE6 PHASE6 --> DONE([业务闭环完成 ✅])
文档版本：V1.0 | 编制日期：2026-03-03
如有修订，请在文档标题处更新版本号，并在此注明修订内容及日期。
汇牧通交易系统 · 项目汇报方案 V1.0 | 编制日期 2026-03-03