——基于 G7 易流 IoT 能力的城配 3PL 一体化架构一、方案定位为什么是小B城配 OWTB 3PL1.1 小B城配的业务画像小B 端城配餐饮连锁、便利店、生鲜店、社区团购网格仓、夫妻老婆店补货和干线/大B 完全是两个物种维度小B 城配干线/大B单量单小1~5 件/店、高频日配/半日配单大、低频温区常温冷藏冷冻混装常见单一温区为主网点单趟 20~80 个门店短半径 ≤50km点到点时效时段达午前/午后/夜配日级价格敏感度高按件/按方/按店计价按车/按吨3PL 模式统仓共配多货主拼一仓一车专仓专车1.2 3PL 做小B 城配的五个老痛点多货主隔离难一仓多客库存/费用/报表混货主不放心仓运配脱节OMS-WMS-TMS 三套系统三家 vendor订单→出库→派车靠人工计费对账复杂按件/按重/按方/按温区/按店/阶梯价/异常扣费Excel 算到哭履约不可视小B 货主要我的货到哪了、几点到店传统 3PL 答不上来IoT 成本高想做冷链温控轨迹被 G7/易流硬件SAAS 绑死毛利被吃1.3 OWTB 一体化要交付的价值Orders多货主 OMS 接单拆单路由 →Warehouse统仓共配 WMS越库按线路拣货 →Transport3PL 视角 TMS排线外协聚合在途 →Billing多计价模型 BMS自动计费异常扣费 定位一句话以 OWTB 四件套为业务内核G7 易流为 IoT 在途与冷链感知外包做小B 城配 3PL 的计划物流平台——计划二字指预约时段、波次统仓、排线计划、计费规则前置不是被动接单的 execution 系统。二、OWTB 四模块能力拆解3PL 多委托方视角2.1 OMS —— 多货主订单中枢小B 城配的 OMS 不是电商 OMS核心是预约 波次 路由多渠道接入货主 H5/小程序/Api对接货主 ERP 或简易 Excel 导入、门店要货端B2B 预约管理午前达/午后达/夜配/次日晨配按时段归集拆单与路由按温区拆、按仓拆多仓场景、按承运商拆外协波次计划按配送时段 线路预归类直接喂给 WMS 的按线路合并拣货多货主隔离数据/权限/库存/计价规则四级隔离货主门户可自查订单费用 小B 城配 OMS 最容易被低估的是预约时段聚合——这是后面 WMS 波次和 TMS 排线的输入源头乱了全盘散。2.2 WMS —— 统仓共配的仓内执行3PL 做小B统仓共配是毛利模型多货主拼仓拼车WMS 必须支持一仓多货主 按线路拣货多货主多仓一货主多仓、一仓多货主批次/SN/效期/温区精细化管理入库收货→质检→上架支持越库cross-docking小B 城配高频场景出库按线路合并拣货是核心不是按单拣也不是纯波次是按今夜排好的线路合并分播→复核→装车PDA 无纸化收货/拣货/复核/装车全扫码库存预警 效期管制生鲜/乳饮小B 货主硬需求G7 标注点复用仓点位、前置仓点位同步到 G7 物流地图做 geoserver 图层供 TMS 排线用2.3 TMS —— 3PL 视角≠ 车队视角这是跟 G7 易流财运通 TMS最容易打架的地方边界必须先划清能力咱自建G7 易流多委托方→多承运商聚合✅ 3PL 核心❌ G7 是车队视角智能排线VRP变量温区/时段/车型/载重/门店时间窗✅ 自研或接百度/阿里物流引擎❌ G7 不开放久久丫那套是自家用外协司机/承运商接入✅ 3PL 核心❌在途轨迹接 G7 MQTT✅ G7 核心价值冷链温湿/报警接 G7 MQTT Rest✅ G7 核心价值电子围栏进出店/停留接 G7 HTTP 推送✅回单/异常✅ 自建❌TMS 自研部分的能力清单运单生成OMS 波次→TMS 运单智能排线引擎车型/温区/时段/载重/门店时间窗多变量 VRP承运商池自有车 外协车队 众包司机司机小程序接单→提货→交货→回单拍照→异常登记在途可视化叠 G7 MQTT 轨迹 温湿 报警事件2.4 BMS —— 3PL 复杂度天花板独立商业层 关键认知BMS不是 WMS/TMS 的附属模块是独立的3PL tariff价目表引擎——参考 Cleverence 3PL Tariff Manager 思路。小B 城配 3PL 的计费维度仓储侧托盘/天、货格/周、立方/月、收货/拣选/包装/装卸操作费、增值贴标/组套/退货处理运输侧按件、按重、按方、按店、按温区加价、阶梯价、时段加价夜配溢价异常扣费迟到、温控超标G7 冷链报警事件直接喂 BMS 做扣费触发器、破损、少件BMS 能力合同价目表Tariff管理每货主一套按服务项×计量单位×费率×币种自动计费引擎从 OMS/WMS/TMS 捞作业量 → 套合同 → 出应收应付承运商/司机侧自动算对账货主确认→收款→财务异常扣费可追溯G7 报警事件作为证据链三、整体架构分层┌──────────────────────────────────────────────┐ │ 多端接入层 │ │ 货主H5/小程序 │ 司机小程序 │ 仓PDA │ 运营PC │ ├──────────────────────────────────────────────┤ │ 业务域层OWTB │ │ OMS(多货主/预约/波次) │ │ WMS(统仓共配/按线路拣货) │ │ TMS(排线/外协聚合/回单) ←→ G7 IoT 集成层 │ │ BMS(多计价/Tariff/异常扣费) │ ├──────────────────────────────────────────────┤ │ 中台层 │ │ 多租户(Party模型) │ 调度引擎 │ 计费引擎 │ │ 组织映射层委托方↔G7机构 ↔设备归属 │ ├──────────────────────────────────────────────┤ │ G7 易流集成层 │ │ MQTT(轨迹温湿) │ HTTP推送(围栏/报警) │ │ Rest(历史轨迹/温度报表/视频) │ │ 域模型映射org→委托方, truck→承运商车 │ ├──────────────────────────────────────────────┤ │ 基础设施 │ │ PostgreSQL PostGIS(网点/路网) │ │ Redis(Kafka 消费锁/排线缓存) │ │ Kafka(业务事件总线 G7 推送落地) │ └──────────────────────────────────────────────┘关键设计决策1. Party 模型多委托方 vs G7 org 的桥G7 的org是车队机构视角一 org 下一堆truck绑gpsno。3PL 是一委托方货主下可能有多家承运商每家承运商可能在 G7 有独立 org 或共用 org——所以平台内部 Party 模型要撑委托方(货主) → 合同 → 承运商A(→ G7 org A) / 承运商B(→ G7 org B) / 自有车(→ G7 org 自营)G7 开放平台按 AccessID 授权建议每个 G7 org 对应一个 AccessID平台做 AccessID 路由层不然 G7 那边机构权限串不了。2. 排线引擎不自建底层算法接第三方G7 不开放排线自写 VRP 不划算。建议百度地图货车路径规划 API或阿里物流排线引擎做底座自己包一层温区约束、时段窗、车型载重、多货主拼车规则——这部分是 3PL 的知识产权3. 事件驱动WMS 出库完成 → 发 Kafka → TMS 生成运单 → G7 MQTT 开始吐轨迹 → 报警事件 → BMS 扣费全链路事件化别走同步调用。四、G7 易流在本方案里的定位专节不是主体是IoT 感知 在途可视化供应商边界再钉一次G7 能力本平台用法不碰的原因轨迹 MQTTTMS 在途 tab 实时渲染—温湿 MQTT 报警BMS 异常扣费触发器 货主 SLA 告警—冷链历史 Rest货主对账时的合规凭证—标注点/geoserverWMS 仓点位 TMS 排线 POI—视频回放 Rest gmedia.js争议取证—财运通 TMS / 订运单中心❌ 不接绑 G7 硬件车队视角3PL 多委托方接不进去智能排线❌ 不接不开放接入三通道承接上轮定位温湿 →MQTT秒级城配趟次密进出电子围栏、停留、报警 →HTTP 推送接收即 return业务逻辑丢线程池历史轨迹、温度报表、视频地址 →Rest 拉域模型映射落地承接上轮画图G7 org → 平台承运商维度每个 org 对应一个 AccessID G7 truck → 平台车辆挂到承运商下 G7 gpsno → 平台设备编号1 truck : N gpsno挂车冷机分开 G7 标注点 → 平台网点(仓/门店)双向同步平台新建门店→写 G7 标注点⚠️ 坑G7 org 是车队粒度3PL 一个委托方可能对应 N 个承运商 N 个 G7 org也可能多个委托方共享一个承运商。所以平台内部的委托方→承运商→G7 org三层映射必须持久化不能指望 G7 侧的机构树。五、落地路线图Phase 1 · MVP月 1~3跑通一条线OMS货主 H5 下单 预约时段 波次归集WMS一仓多货主 按线路合并拣货 PDATMS运单生成 司机小程序 G7 MQTT 轨迹温湿最小可用接 1 个 G7 org 先做域映射验证BMS按件/按店最简计价 手动对账目标1 个仓、2~3 个货主、日单 200 内跑通Phase 2 · V1.0月 4~6排线 多货主计费TMS 排线引擎接入百度/阿里路径规划 自封装温区/时段约束BMS Tariff 引擎完整化仓储费运输费异常扣费G7 报警喂 BMS多货主门户库存/订单/费用自助查G7 HTTP 推送电子围栏/报警接进来目标3~5 仓、10 货主、外协承运商接入Phase 3 · V2.0月 7~12计划物流 网络效应多仓库存共享、就近发货前置仓/网格仓模式统仓共配算法优化拼车率↑冷链合规报表自动化G7 温度报表 BMS目标区域城配 3PL 标杆 case六、商业化一句话小B 城配 3PL 的毛利模型是统仓共配的拼车率 计费的透明度——OWTB 四件套解决拼得起来、算得清楚G7 易流解决冷链合规轨迹可视别自己造轮子。两者拼起来对 3PL 老板的交付物是仓容利用率↑、车辆满载率↑、对账人力↓、货主 SLA 可承诺。