xst
5e4e978cd5
- 原型评估_滇中好运物流云_20260917/：物流云原型评估产物（含核对表与字段对比表） - requirements/小象开票收款方创建需求.md + prototypes/小象开票原型.html：小象开票建司机/车辆/收款信息需求 - requirements.txt：Execute 战区依赖调整（移除 pytest/allure-pytest/requests，改用 pytest-html，Appium 默认注释） - .claude/launch.json：新增物流公司管理原型预览服务（wuliu-proto:8138） - .agents/skills：agent 技能定义
7.6 KiB
7.6 KiB
03 与运八项目契合度对比
运八侧事实来源：
output/菜单清单.md（运八管理后台 423 个可见菜单，ntocc.sys_resource 导出）、tests/api/test_yun8_transport_flow.py（24 步全链路：货源→接单→装货→卸货→核算→审核→油卡充值→司机打款→货主打款→回单→ETC 发票）。
1. 两个系统的定位差
| 维度 | 运八（网络货运平台） | 原型·物流云（统一调度协同平台） |
|---|---|---|
| 法律角色 | 网络货运承运人（承担承运责任、开票、资金、监管上报） | 调度协同中枢（不对托运人承担承运责任） |
| 核心资产 | 合规链路：监管上报（司机/车辆/路单/资金）、多渠道发票（浙样红/满货达/滇运通/三十六匠/小象/ETC）、税务管理、真实资金（光大/快钱/分账/提现） | 业务链路：计划→配载→运单→履约→凭证→核算→结算的协同与管控 |
| 运力来源 | 社会运力为主（司机/车队注册、审核、评价、投诉） | 中闽自营车队 + 准入承运商（含运八） |
| 货源组织 | 货源大厅、发布货源、项目货源 | 呈钢 ERP 计划、货主发货计划、客户自提 |
| 强项 | 四流合一（合同/货物/资金/票据）、监管口径 | 计划调度颗粒度（拆分/合并/配载/资质门禁）、三方协同流程、权责划分 |
结论：互补大于竞争。 原型自己也是这么设计的——运八在原型中不是被替代的对象，而是运力池里的承运商租户和"授权代录"数据来源。
2. 原型已为运八预留的契合点
- 承运商租户位：运力池/资质管理按"准入承运商"设计，
carrier-yunba 云南运八物流科技有限公司已在演示数据中。 - 代录通道：发货计划来源类型支持"运八调度→运八授权代录"（与"中闽人工代录""平台人工代录"并列），说明产品规划中运八是上游计划的一个合法来源。
- 核算规则复用：核算管理声明"仅复用运八已评审核算规则，并适配呈钢、昆铁和中闽现有业务对象"——两边的运费核算口径同源，结算对账有共同语言。
- 接口中心已就位：接口配置/接口任务模块（发送/回执/失败重试/补偿记录）就是为外部系统接入准备的，目前仅接了呈钢 ERP，接入运八只是配置层面的事（产品上已留好位置）。
- 凭证中心：按运单节点管理回单文件+版本+审核链，与运八的回单签收/电子回单可以一一映射。
3. 功能重叠与双轨风险（需要明确归属）
| 领域 | 运八已有 | 原型也有 | 风险 | 建议归属 |
|---|---|---|---|---|
| 运单 | 运单管理/跟踪/轨迹/补录，是监管上报的路单来源 | driverTasks 全生命周期+waybill-center | 双轨运单：同一票货两边各生成运单号，监管口径以运八路单为准，金额/里程不一致即监测系统异常 | 运单主数据放物流云（调度视角），合规运单以运八为准；物流云运单向运八推送生成路单，回传路单号绑定 |
| 司机/车辆资质 | 司机审核/车辆审核/核验审核+监管上报（司机上报/车辆上报） | 单人+单车资质组合、OCR 机审、装车门禁 | 双重审核、口径不一（如从业资格证字段、4.5 吨以下豁免） | 物流云做准入门禁（可派判断），运八做合规审查与上报；资质结果双向同步，避免司机重复提交 |
| 轨迹 | 运单轨迹、轨迹导出、（对接监测系统的驾驶员位置上传） | 高德 Mock 轨迹+装卸打卡 | 原型无真实轨迹源 | 轨迹一律取运八/北斗侧，物流云只消费展示 |
| 回单 | 回单签收/电子回单 | 凭证中心（版本链/审核退回/补传） | 双侧上传、重复归档 | 司机 App 上传入口收敛为一处，另一方同步镜像 |
| 结算/资金 | 运费核算→审核→油卡充值→司机打款→货主打款→分账/提现（真实资金） | 核算→结算申请→结算→付款批次（线下登记，不执行真实资金） | 原型已声明不动资金，天然无冲突，但要防业务员误以为走了系统=付了钱 | 金额口径在物流云核对，支付指令全部走运八；物流云付款批次仅做台账并与运八流水勾稽 |
| 发票 | 多渠道代开（专票/普票/ETC/红冲）+税务管理 | 进/销项线下登记（Mock，不连税务） | 原型发票模块定位是"线下结果登记"，与运八开票是上下游而非竞争 | 运八开票，物流云登记勾稽（原型已有"发票分配到付款批次"的勾稽设计，方向正确） |
| 油卡/能源 | 加油管理、能源卡、万金油、油费预付 | 中闽油卡管理（自营资产）、在途费用（电费/ETC 等 6 类报销） | 两种语义（资产卡 vs 平台代购燃料）。注意新办法第十二条：平台自购燃料交付需承运人同意；第十八条要求燃料全流程留痕 | 平台代购燃料（若有）必须在运八侧做全流程留痕；物流云油卡仅限中闽自有 |
| 异常 | 客服运维（运输异常/投诉/评价/预警/撤单） | 异常管理（责任岗位/复核闭环）+履约预警 | 处置口径分叉 | 运营异常协同在物流云，投诉举报类按新办法第十七条必须建在承运平台（运八）并对外公示 |
4. 契合度总评
- 业务流程契合：高。原型的发货计划→装车计划→运单→回单→核算→结算链条与运八 24 步链路几乎同构（接单/装卸/核算/打款/回单/ETC 发票都能对上），且核算规则同源。
- 角色契合：中高。原型把货主、承运商、调度、财务分系统分角色投影，运八作为承运商/调度来源都有位；但运八没有像中闽那样的独立工作系统，若运八要在物流云上做调度协同，目前只能用"运输公司调度"泛化角色，颗粒度不够。
- 数据契合：中。租户/主体/凭证/导出等主数据模型齐备，但运单、资质、结算三个核心对象双方都要"最终裁定权"，必须提前定归属，否则监测系统（运八上报）与协同平台（物流云）数据打架。
- 合规契合：天然的上下游。物流云缺的监管能力恰好是运八的长项（监管上报/发票/资金），运八弱的调度协同恰好是物流云的长项。"物流云管业务，运八管合规"是阻力最小的组合。
5. 落地建议（给评审/立项用）
- 明确一句话定位：物流云 = 计划调度与协同管控；运八 = 合规承运与资金票据通道。中闽 = 自营运力执行方（原型已按此设计，保持）。
- 接口清单（在原型"接口配置"模块中立项，本期已排除、后续应纳入）：
- 下行：物流云装车计划/运单 → 运八生成合规运单（路单）；
- 上行：运八回传路单号、轨迹、回单、打款流水、发票状态 → 物流云履约监控/凭证中心/付款批次勾稽；
- 资质：运八审核结果 ↔ 物流云门禁状态同步。
- 三个"唯一"原则：运单号以运八路单为准、支付以运八通道为准、开票以运八为准；物流云所有对应模块降级为"登记+勾稽"，这与原型现有声明（不动真实资金、不连税务）完全一致，改造成本最低。
- 测试关注点（本仓库视角）：若立项对接，建议在
tests/api/增加"物流云↔运八"接口造数用例，复用现有 24 步链路的 yun8_pipeline，把物流云侧计划/运单造数串进来，重点验证运单号绑定、资质状态同步、结算金额对平三条断言。