系统集成架构 · 参考RMIS第1章 + 各系统接口文档
五大数据链路
示例ERP系统→金蝶、示例ERP系统→小程序、小程序→京美饿、融讯→示例ERP系统、示例ERP系统→浦发
②同步方式待明确
大部分链路的同步方式（实时/定时/手动）仍待确认
③同步失败补偿
每条链路需有自动重试、告警、排队机制
④对账脚本覆盖
定期比对两端数据总量和关键字段，防止悄悄不一致
① 五大数据链路
| 链路 | 传递内容 | 同步方式 | 核心风险 |
|---|---|---|---|
| 示例ERP系统 → 金蝶 | 应收应付、收入成本、库存金额 | 待确认（接口/手动导出） | 数据不一致时排查三端（示例ERP系统+接口+金蝶） |
| 示例ERP系统 → 微信小程序 | 品名、价格、库存、图片 | 待确认（实时/定时） | 促销过期线上还在卖、库存不准超卖 |
| 小程序 → 京美饿 | 订单、配送信息、支付状态 | 平台接口 | 漏单、延迟、平台接口变更 |
| 融讯AI秤 → 示例ERP系统 | 商品识别结果、重量、价格 | 待确认（手动/自动） | 回传中断导致示例ERP系统库存不准 |
| 示例ERP系统 → 浦发银行 | 消费记录、余额变更 | 待确认 | 银行侧数据延迟、结算差异 |
② 同步方式不明确的链路最多
⚠️ 五条中三条待确认
五条核心链路中，除小程序→京美饿确认是平台接口外，其余链路的同步方式（实时推送 vs 定时批量 vs 手动导出导入）大多待确认。实时同步的问题是故障影响即时，定时同步的问题是延迟窗口内数据不一致。需要逐条确认。
③ 同步失败怎么办
🔄 容错缺失
每条链路都应该有同步失败的补偿机制：失败了是否自动重试？重试几次？是否有失败告警？失败期间的数据是排队等待还是直接丢弃？没有补偿机制的链路，一次故障就可能造成数据永久不一致。
④ 对账脚本覆盖
📊 最后防线
每条链路建议配备对账脚本：定期比对两端数据总量和关键字段，发现差异自动生成报告。当前示例ERP系统↔金蝶有对账流程，但小程序、京美饿、融讯秤的对账覆盖可能还不到位。这是防止"数据悄悄不一致"的最后防线。