面向坦桑尼亚 — 赞比亚走廊自营重卡车队（81 → 300 台）的运输管理系统建设，覆盖商业产品对标、开源可复用性、行业隐性知识与交付风险。
这不是"有难度"，是两个需求条款在技术上不可同时成立：
no_icp_domain 字段）唯一出路是境外主体小程序，但需海外子公司 + 使领馆认证 + 类目申请，2–4 周行政前置且结果不可控。
坦桑尼亚智能手机普及率仅 35–42%（TCRA 官方 2025）；赞比亚农村智能手机拥有率仅 21.0%（ITU/ZICTA 2025）——而跨境矿运路线多途经农村。坦桑 WhatsApp 占主导，微信在非洲已基本退出；98.6% 的小程序用户在中国大陆。
小程序切后台 5 秒挂起、30 分钟销毁 → 没有后台静默同步能力。需求书要求的"联网后自动增量同步"做不到。
推荐替代：uni-app（一套代码产出 Android APK + H5 + 小程序），司机端主推 Android APK（离线优先），管理端用 H5。
Statutory Instrument No. 35 of 2021（Citizens Economic Empowerment 条例）：
附表商品明确包含 Concentrates、Copper、Anode、Cobalt、Manganese、Cement、Clinker、Fertilizer —— 即本项目全部主力货种。
执行实证：FQM 旗下 Kalumbila Minerals 重新招标精矿运输合同，授予两家赞比亚公民所有的运输公司（Buks Haulage、JC Bousfield），合计 135 台车月运 9 万吨精矿，明确依据 Citizens Economic Empowerment Act。
【推断】这直接冲击客户的业务模式假设。如果实际运营是"中资主体 + 本地承运商分包"，那系统里的"自营车队"就变成了自营 + 分包混合，数据模型完全不同。
Data Protection Act, 2021（第 3 号法案）第 70 条：
含义：TMS 的 GPS 车辆/司机轨迹数据在赞比亚法律下很可能被视为个人数据 → "全部部署约翰内斯堡"的单区域方案违法。若移动端演进为人脸/指纹打卡，则触发"敏感个人数据"条款，完全无豁免空间。
坦桑尼亚 PDPA (2022) 同样要求：数据控制者须向 PDPC 注册；生物特征等敏感数据处理需事先书面同意。2026-01 已发最终宽限通牒。
需求书对这些只字未提。架构从"单节点"变成"多国分布式 + 数据同步"，是另一个量级的工作量。
SAP 官方《Indirect Access Guide》明文把 "Database link" 列入需许可的接入方式 —— 换接入方式不能规避。
【推断】需求书写的"深度对接 SAP HANA 服务器、双向实时数据互通"，若按字面理解为直连 HANA 数据库读写业务表，是反模式 + 许可风险。正确路径是走 SAP 标准接口（OData / SAP Gateway / Integration Suite），但需客户 SAP 侧配合与授权。
启动会必问：SAP 版本？S/4HANA 还是 ECC on HANA？谁维护？有无中间件？Digital Access 授权谁买单？
这个定位决定了对标对象和模块边界。八家企业级 TMS 中，真正有独立自营车队模块的只有三家：
| 产品 | 自营车队模块 | 关键能力 |
|---|---|---|
| Oracle OTM | ✅ 独立模块 | Driver Pay、HOS、Dispatch Board、Work Assignment、Fleet Aware Bulk Planning |
| Manhattan | ✅ 独立模块 | HOS + seniority（司机排班资历）、drivers/tractors/trailers 统一优化 |
| Descartes | ✅ 专门大类 | Fleet Performance Management、Route Planner "trusted by private fleets" |
| SAP TM | ⚠️ 无独立模块 | 把车辆/司机当 resource 融入统一规划 |
| Alpega / Transporeon | ❌ 完全没有 | 它们是撮合网络平台，服务对象是外部承运商网络 |
→ 对标应看 Oracle OTM 与 Manhattan，不要看 Alpega/Transporeon。Manhattan 的 "seniority" 字段（司机工龄排班约束）是自营车队工会排班的典型需求，说明它是真为自营车队设计的，不是货代产品的附赠。
两个全球最成熟的 TMS 给出了两种截然不同的答案，这是本项目最重要的单一架构决策。
| OTM 范式（leg 实体化） | SAP 范式（stage 内嵌） | |
|---|---|---|
| 做法 | 每条 leg 生成独立的 Order Movement 实体 | Freight Unit 内部持有 Stage 集合 |
| 官方原话 | "The order release is never split… Its movement is split among one or more shipments" | "In planning you refine this… the freight unit being transported from A to Z via B" |
| 优点 | 便于按段分权、分角色协作（官方场景就是出口/海运/进口三个 planner 各管一段） | 对象数少、追溯链短，实现成本低 |
| 代价 | 对象数量膨胀；拆分 ship unit 时要级联更新所有引用 | 跨段协作靠分配关系间接表达 |
本项目是「矿区装货 → 内陆运输 → 边境口岸 → 港口 → 海运」，且各段常由不同分公司（坦桑公司/赞比亚公司）负责，需求书还要求两国差异化审批与数据隔离。→ OTM 的 Order Movement 范式在组织协作上更贴合。
这是矿运特有的、也是最容易犯的设计错误。行业铁律：
矿产品按干吨（DMT）计价，按湿吨（WMT）付运费。
OECD/IGF 铜转让定价框架
| # | 字段 | 用途 |
|---|---|---|
| 1 | 矿区地磅净重（WMT） | 装货凭证 |
| 2 | 港口地磅净重（WMT） | 交货凭证，通常的结算基准 |
| 3 | 干吨 DMT | = WMT × (1 − 水分率)，可能再减 weight franchise（常见 0.5%） |
| 4 | 计费吨 | 合同约定以上述哪一个为准，并应用允差 |
现成范式：OTM 的 Shipment Ship Unit 有 ordered / booked / shipped / received 四层数量追踪 —— "shipped vs received" 的差额就是途损。
把这四个塞进一个 net_weight 字段，是这类项目最常见的设计事故。
因为等待成本高到无法忽略：
→ 每个阶段（空驶到矿 / 矿区装货 / 重车运输 / 港口卸货 / 返程）必须独立记录时间、里程、成本。
Wenco / Modular Mining DISPATCH / Hexagon 解决的是"矿坑里 3–8 km 的循环、每天几十趟"，本项目是"公共道路 2000 km、单程一周、跨两国海关"。两者在数据模型（cycle vs trip）、通信（矿区 WiFi vs 蜂窝+卫星）、优化目标上都不同。
→ 在矿区地磅这个交接点对接取数即可，不要试图替代。
调研了 5 家主流 FMS（Fleetio、Samsara、Geotab、Verizon Connect、Webfleet、Zonar、Motive、Trimble TMT 等）与 12 家非洲本土平台（Lori、Kobo360、Leta、Korridor、Trella、Wasoko 等），结论如下。
| 客户要求的模块 | 市场现状 | 结论 |
|---|---|---|
| 配件成本分摊至车辆/车次/项目 | 五家主流 FMS 无一家有"成本中心/内部分摊"原生模块 | ⛔ 纯自研 |
| 轮胎全生命周期管理 （CPK/翻新/轮位矩阵） | 五家均无。即便 Webfleet 母公司是 Bridgestone、Zonar 绑定 Continental，都停在 TPMS 胎压监测层 | ⛔ 纯自研 |
| 司机证件到期 / 跨境签证 / 出车补助核算 | 五家的"司机管理"都不是 HR 式档案管理（是安全/行为/合规口径） | ⛔ 无对标 |
| 矿产计量 （WMT/DMT/水分/途损/短溢） | 12 家非洲平台 + 5 家 FMS，无一家有 | ⛔ 完全空白 |
| 过磅站 / 轴重 / 路桥费 | 12 家非洲平台全部空白 | ⛔ 完全空白 |
| 偷油管控 | 12 家非洲平台全部空白（有人做油耗监控，无人做管控闭环） | ⛔ 完全空白 |
| 可配置多级审批引擎 | 八家企业级 TMS 中只有 SAP / Oracle 有产品化审批引擎 | ⚠️ 需自研 |
| 中英双语全量 | ruoyi-vue-pro 后端没有 i18n（全仓无 MessageSource/LocaleResolver） | ⚠️ 需自研 |
这张表是报价谈判的核心武器。客户/前供应商很可能默认这些是"配置一下"的事，实际上是全新开发。尤其"矿产计量"这一项——全球范围内所有商业物流平台都没做，目前完全由贸易商、第三方检验行和纸质流程覆盖。
【推断】欧美车队多为自营单一成本主体，成本分摊由 ERP/财务系统承接，所以 FMS 厂商没有动力做；轮胎全生命周期被轮胎厂商的服务体系（Bridgestone FleetCare、Continental ContiConnect 服务侧）吸走，软件方只提供数据入口。
非洲本土平台则是另一个原因：它们与司机是松散承包关系而非雇佣关系，没有立场也没有抓手管司机怎么加油。如果面对的是自营或强管控车队，这恰恰是现成的空白。
| 段落 | 里程 | 耗时 |
|---|---|---|
| Dar es Salaam → Tunduma | ~950 km | 12–15 小时 |
| Tunduma / Nakonde 过境 | — | 6–48 小时（月末/季末更长） |
| Nakonde → Ndola | ~650 km | 10–14 小时 |
| 合计 DSM–Lusaka | ~1,850 km | 纯驾驶 3–4 天；门到门建议按 7–10 个工作日规划 |
【推断】每吨 $40 的价差对应 7 天额外周转 → 在坦赞走廊上，时间就是钱的换算率极高。压缩边境与港口等待的信息化投入，回报周期很短。
推断依据：① 非洲司机工资远低于美国，分母中人工项大幅缩小；② 坦/赞柴油含税零售价 USD 1.55–1.58/L ≈ USD 5.9/gal，是美国的 1.5–1.7 倍；③ 路况差、坡道多、超载常态导致 L/100km 高于北美 20%+。
→ 1% 的油耗改善 ≈ 0.4% 的总成本改善；1% 的盗油 ≈ 直接吃掉 0.4% 净利。
坦/赞柴油当前 USD 价差仅 2%，但赞比亚单月波动达 12.5%（6 月 ZMW 32.11 → 7 月 28.11）—— 跨境加油套利方向逐月翻转，任何"固定在某一国加油"的静态策略都是错的。
三条独立证据指向同一结论：
DRC 境内有组织劫持（Tumbwe 地区，有警方、军方和安保人员配合）；车头可从警局"赎回"，代价 US$50,000；追回被劫铜料另收货值的 10%；Kasumbalesa 附近曾有士兵持枪抢劫司机随身携带的美元现金。
保险方的反应（IUMI 2024-12）：保单加入强制性保证条款 —— 要求有组织车队编队、武装押运、实时卫星追踪，并严格执行 48 小时内报案期限。
安全模块要做的不是"防盗"，而是"合规取证"：追踪数据的首要用途是保住理赔资格。产品应围绕"生成保险公司认可的证据链"设计，包括封条编号、边境时间戳、车队编队记录。
"不管你走的是鲸湾港、德班、贝拉还是达累斯萨拉姆，只要你的货是去 DRC 或赞比亚的，整个网络都是瘫的。"
Transist · Mike Fitzmaurice
→ 任何依赖上游 API 实时可用的设计都会周期性瘫痪。产品需要「离线单据缓存 + 手工兜底流程 + 排队位置与 ETA 重算」。
| 系统 | 国家 | 性质 |
|---|---|---|
| NTANCIS / TANESW | 坦桑 | 2025-01 生效，强制要求收货人 TIN 号，不合规将被系统拒绝 |
| ASYCUDA World | 赞比亚 | ZRA 唯一税款核定平台 |
| ECTS 电子货物追踪 | 坦桑 | 强制加装追踪设备与电子锁，覆盖散装货物（铜精矿属此类） |
| COMESA CVTFS / EAC RECTS | 区域 | COMESA 自己承认："各国系统各自为政，区域卡车司机需要安装 2-3 套不同的追踪系统" |
→ 这不是"要不要做"，而是政府强制的合规接口，应列为 P0 级集成需求。
坦桑尼亚与赞比亚都有现行有效的强制驾驶时长法规，且明确覆盖货运重卡。
| 国家 | 法源 | 核心规定 |
|---|---|---|
| 坦桑 | Traffic Regulations 规则 36 | 18 小时内驾驶 ≤10 小时；7 日内 ≤48 小时；"turn of driving duty" 包含途中装货、卸货、路边等候、换胎及任何其他延误时间 |
| 赞比亚 | SI 80 of 2016 | 一日内连续驾驶 ≤8 小时；7 日内 ≤48 小时；每驾驶 2 小时须有 ≥5 分钟休息；车主须在车内保存法定格式日志本 |
⚠️ 注意坦桑那条：边境排队计入法定驾驶勤务时长 —— 这与 Kasumbalesa 排队数日的现实直接冲突。
法定义务存在（必须记录并可举证），但没有 ELD/tachograph 电子强制，也没有指定技术载体。TMS 的电子工时记录可直接充当合规凭证，无准入壁垒。反之也意味着没有法定数据格式可依循，需自定义并做成可打印为路检可接受的簿册格式。
| 项目 | 金额 |
|---|---|
| 卡车司机最低基本月薪 | ZMW 4,000 |
| 跨境补助（无卧铺） | 不低于 USD 30 / 夜 |
| 跨境补助（车有卧铺） | USD 20 / 夜 |
| 境内外宿补助（无卧铺） | ZMW 390 / 夜 |
| 风险津贴（超限载荷/危险品）本地 | 不低于 ZMW 1.50 / 公里 |
| 风险津贴 国际 | 不低于 USD 0.10 / 公里 |
| 休假津贴 | 一个月基本工资的 30%，须在休假前支付 |
SI 106/2020 第 6 条还规定了法定薪资单的六个字段：司机姓名地址、职务、常规工时数、加班工时数、扣除前工资、扣除金额与实付工资 —— 这就是赞比亚司机结算单的最小字段集。
坦桑尼亚（GN 605A of 2025，2026-01-01 生效）：内陆运输服务最低 TZS 398,500/月；且法律强制要求为卡车司机支付涵盖 ① 里程、② 站外滞留、③ 装卸货 三类的津贴，金额由劳资协商。
【推断】坦桑法律实际上背书了"底薪 + 里程提成 + 等候补贴 + 装卸费"这一结构。TMS 的薪酬引擎应把这三项做成独立可配置的 pay component，而非合并进一个"提成"。
赞比亚：per diem 无金额门槛地免 PAYE（ZRA Practice Note 1/2025），可安全采用"低底薪 + 高过夜津贴"结构。
坦桑：必须满足 s.7(3)(d) 的"据实报销"要件才免税，且无论是否免 PAYE，SDL 3.5% 的基数都包含出差与差旅津贴。整笔包干津贴在坦桑是税务风险点。
| 判据 | 阈值 | 来源 |
|---|---|---|
| 油箱容量校验 | 加油量 > 登记容量的 110% | Geotab |
| 位置匹配 | 加油点与 GPS 轨迹距离 > 1000 m | WEX |
| 时间匹配 | 交易时戳与设备加油事件偏差 > 720 min | WEX |
| 油品匹配 | 交易油品 ≠ 车辆登记油品 | Geotab |
| 量差校验 | (单据量 − 油位上升量) / 单据量 > 8% | 【推断】需试点校准 |
"这些不匹配报表旨在识别待调查的数据异常，不能作为欺诈或不当行为的定论。这些报表关联的是车辆和油卡交易，不是个人，不应作为解雇、停职或纪律处分的主要依据。"
→ 产品必须把"异常标记"和"处罚决定"分成两个状态机，中间强制插入人工调查环节并留痕。直接用系统告警扣司机工资，在劳动纠纷中会成为不利证据。
"当超过 90% 的告警是误报时，运营团队不再关注告警。真正的盗窃反而被忽视。有些车队干脆彻底关掉盗油告警。"
"没有标定，即使是顶级传感器也会产生 5% 以上的误差。"
→ 告警质量是产品生死线。多信号交叉判定（净油位降 + 静止 + 时长 + 围栏 + 倾角 + 传感器健康度）比提升传感器精度更重要，且成本低得多。
Idling（怠速 >2 分钟，排除 PTO）/ Over speed / Cruise control / Coasting / High torque（扭矩 >90%） / Anticipation（松油门到刹车 <1 秒的次数） / Green band（经济转速区间）
关键字段：averageVehicleWeightKg 与 highGradePercentage —— Samsara 明确用"车重和地形"做归一化。本项目重载去程 vs 空载回程油耗差 30–40%，不做归一化的考核不公平。
| # | 借鉴点 | 用途 |
|---|---|---|
| 1 | ordered / booked / shipped / received 四层数量 | 矿运的计划量/订舱量/装货量/卸货量，差额=途损 |
| 2 | Shipment Cost 挂多个归属引用 + 明确优先级 | 配件成本分摊至车辆/车次/项目 |
| 3 | 计划成本 vs 实际成本的界定 | 预估来自计划阶段，实际来自已开凭证的发票行 —— 避免验收扯皮 |
| 4 | 费用叠加顺序号 Sequence Number | 自动计费引擎必须显式建模，否则金额算错 |
| 5 | Accessorial vs Special Service 二分 | 区分"影响能不能接单"与"只影响多少钱" |
| 6 | Charge Element 绑定发生地点以分国计税 | 坦桑段/赞比亚段税制币种不同 |
| 7 | Domain + Perspective 实现数据隔离 | 多租户 + 组织双层隔离 |
| 8 | Means-of-Transport Combinations | "车头 + 车挂"组合建模 |
| 9 | one-time location | 矿区临时装货点不必建主数据 |
| 10 | Seal（封条）字段 | 海关电子锁/铅封（坦桑法定要求，封识破损即出口许可失效） |
| 11 | ordered route vs actual route 二分 | 计划路线 vs 实际路线（绕路监控） |
| 12 | Rate-Level Validity Periods | 坦赞油价月月变，费率必须版本化 |
调研 26 个开源项目源码后的结论：star 数与建模质量严重脱钩。
| 项目 | star | 价值 |
|---|---|---|
| suxrobGM/logistics-app | 173 | Load × Trip × TripStop 多对多建模最优雅；一个 Load 在一个 Trip 中产生两条 TripStop（PickUp + DropOff）；收入统计只算 DropOff 避免重复；Terminal 字段支持跨段换车 —— 最接近本项目需求 |
| DominicFinn/open_tms | 6 | 唯一同时具备 Order/Shipment/Stop/Lane/Load/Tender 全套概念；OrderShipment 多对多连接表支撑拆分/合并；Order.deliveryStopId 解决"合并后哪单在第几站卸" |
| traccar/traccar | 7504 | GPS 接入层，支持 200+ GPS 协议（非洲廉价中国产 GPS 刚需）。但它不是 TMS，业务语义全靠 attributes JSON |
| fleetbase/fleetops | — | Order→Payload→Waypoint 三层；适合最后一公里，无法表达跨段换车 |
【推断】推荐架构：Traccar 做 GPS 接入层（tc_devices/tc_positions/tc_geofences/tc_events），自研 TMS 做业务层，通过 device.uniqueid ↔ vehicle.gps_device_id 关联。
| 红旗信号 | 本项目 |
|---|---|
| 技术要求精确匹配某竞对产品特性 | ⚠️ 命中（微信小程序、SAP HANA 等高度具体的选型） |
| 指定品牌/技术栈且无 "or equal" 条款 | ⚠️ 命中（微信小程序、Google Maps、MySQL、约堡节点） |
| 无法接触真实决策人 | ⚠️ 疑似（目前只对接一人） |
| 邀请介入的时间点在项目周期很晚 | ⚠️ 命中（已找过 3-4 家做完需求调研） |
判据：单一信号不代表死局，两个以上才是强烈预警。
资深从业者明确反对"看到红旗就不投"—— "Hardly any RFPs are actually wired"。客户已找 3-4 家说明处于多方对话阶段而非单一竞对锁定。
【推断】建议做法：提交 ① 响应需求书的合规部分（走正式流程，规避废标）+ ② 单独一份「问题诊断与差异化方案」（附加价值文档，不作为正式偏离投标）。
在采用 "Contract A" 招标法理的司法辖区（英联邦国家常见，坦桑、赞比亚均属），未获授权的替代方案会被判定为非合规反要约，直接废标。真实判例：Eastern Regional Health Authority v. Kannegiesser Canada。
→ P0：先确认客户采购流程是否允许「技术偏差说明/替代方案」，再决定能否 reframe。
范围明确、有硬截止日期时，固定价"几乎总是更优"；且采购流程可能不接受分阶段报价。
【推断】建议：不要按 400 人天清单硬拼低价。报 "Phase 1 付费 Discovery / MVP + 验证"，用真实数据重写报价基线。若客户要求一次性总价，则在总价框架内插入"里程碑验收 + 客户依赖条款"控制风险。
| # | 条款 | 理由 |
|---|---|---|
| 1 | Customer Dependencies 把 SAP/泛微 OA/GPS 厂商的配合责任划出去 | SAP 对接不上是最容易扯皮的。条款示例：若因客户未按期提供 SAP 侧接口文档/测试账号/技术对接人员配合，交付期限相应顺延且不承担违约责任 |
| 2 | 对账准确性量化为差异率阈值 | 客户核心诉求就是"拉报表"和"自动对账"，这是最容易扯皮的主观项。国内判例：甲方以"界面不够美观"拒付 48 万尾款（最终甲方败诉，但供应商经历漫长诉讼） |
| 3 | 7×24 运维加期限 | 需求书写"持续 BUG 修复、7×24 运维保障"但没说期限，典型无限期免费陷阱 |
| 4 | Deemed Acceptance （10-15 工作日默示验收） | 判例（Samia v. MRI）：客户未在窗口内书面提出异议，法院直接判供应商胜诉 |
| 案例 | 教训 |
|---|---|
| Hershey $100M 万圣节订单未履约 | 48 个月工期压缩到 30 个月，旺季前大爆炸上线 → 论证分期交付 |
| National Grid 预算 $3.84 亿 → $9.45 亿 | 飓风 Sandy 期间上线 → 论证上线窗口选择 |
| Target Canada 累计投入 $70 亿，破产 | 主数据错误 + 激进扩张时间表 → 论证基础数据初始化工作量不能压缩 |
| MillerCoors v. HCL 索赔超 $1 亿 | 7 次更换项目经理 + 2 次更换项目总监 → 我方主动承诺团队稳定性，这是差异化优势 |
网络流传的 "Gartner：70% ERP 实施无法达成目标" 无法追溯到官方原始报告。建议改用有原始出处的 Standish / Panorama / McKinsey 数据，以免被客户方 IT 或财务尽调质疑可信度。
不做"400 人天全包"，做"分期交付的自营车队 TMS"。
一期聚焦客户真正痛的两件事：拉得出报表 + 司机能上报数据。把 SAP 深度对接、多租户、微信小程序这三个高风险项拆到二期或重新定义。
| ✅ MVP 建议范围 | ⏸ 明确二期或不做 |
|---|---|
| 基础数据（车头/车挂/司机/线路/客户/费用规则） | SAP 双向实时同步 |
| 订单-车次-阶段模型（含四层数量与途损） | 多租户底层隔离 |
| GPS 接入（Traccar）+ 电子围栏 | 微信小程序 |
| 司机端 Android APK（离线优先：打卡、拍照、过磅单上传） | 无代码审批引擎 |
| 燃油管理（加油记录 + 三条对账规则） | 配件全生命周期 |
| 月度报表（单车月里程、每公里油耗、单趟成本） | 轮胎 CPK 管理 |
traccar · traccar-web · fleetbase · trenova · logistics-app-dotnet · ofbiz-framework · openboxes · axelor-open-suite · erpnext · jshERP · sl-express · timefold-solver · gmaps-route-optimization · ruoyi-vue-pro · JeecgBoot · warm-flow · flowable-engine · LogicFlow · liteflow · QLExpress · killbill · rxdb · WatermelonDB · JimuReport · cloud-sdk-js · node-hdb
本次调研全程遵循「事实与推断分离」原则。凡标注 【推断】 者为基于证据的分析判断，非来源事实。关键的方向性判断均已寻找反驳来源（如"分阶段报价更优"同时列出了"固定价更优"的论证）。多处标注了无法核实的知识缺口，未以推测填充。