一家商贸企业已经用ERP管采购、仓库和财务，又希望客户在手机商城自主查价下单。老板最担心两件事：多一套系统要重复维护商品、客户和库存；客户在商城下了单，ERP没接到或接成两张，最后仍要员工手工补录。判断新增订货平台是否值得，不是先看接口菜单有多少，而是先明确现有ERP擅长什么、外部客户订货在哪里断链，再用一张客户原单打通“商品可见—客户成交—ERP接单—发货回传—日终对账”。
这篇按项目实施顺序说明数据主责、编码映射、订单同步结果和异常重试。文章中的“100单、ERP接收98单”仅为对账示例，不代表现成接口的实际性能；能否对接某一ERP的特定字段、同步方向和回写状态，必须以双方版本、接口文档及真实数据测试为准。已有ERP不意味着订货平台要取代它，两套系统各做什么应由业务边界决定。
先找现有ERP尚未覆盖的外部协作，不重复建设内部账
企业先画一张现状图：商品由谁建，客户由谁审批，业务员如何报单，ERP何时扣库存，仓库在哪里打出库单，财务以什么单据收款。若ERP本身已有客户下单入口、可按客户展示价格、支持手机复购，并且能让客户查订单进度，再上另一套商城的收益就需要仔细测算。若ERP主要服务内部，客户仍靠微信传清单，报价、促销、可见货盘和售后查询分散在业务员个人手机里，订货平台可以补外部协作入口；但它的价值应以客户自助下单比例、员工重复录入工时、订单错漏及回款跟进衡量，而不只是“又有一个系统”。
系统应用中心的真实页面列有“ERP对接”“开放平台数据接口”等应用入口，说明产品提供相关接入方向。这个截图只能证明应用入口存在，不代表任何ERP开箱即用、所有字段均可双向同步，尤其不能把界面上的“数据实时同步”宣传文案直接当成某客户的上线验收结果。采购、仓储和财务仍在原ERP时，第一阶段可只打通客户订单进入ERP，再按需要扩充库存、价格和出库状态；不要一开始就把全部主数据和历史业务搬迁。
图1：真实界面展示可用的对接应用入口；具体ERP版本、字段、刷新频率和回写范围要通过项目测试确认。
如果企业提出“不要重新建商品”，还要问清它想避免的是二次录入商品名称，还是希望商品新增、停用、规格修改都在ERP发起。前者可通过初始数据导入减轻，后者才涉及持续同步与冲突控制。库存也是如此：客户下单时需知道“可卖多少”，未必需要商城复制ERP全部仓库流水；若ERP不能及时提供可售量，就得决定展示库存的刷新频率、超卖处理和业务员人工确认边界。先找到真正影响成交与履约的缺口，才知道对接投入值不值。
商品、客户、价格、库存各自指定主责，避免两边改了又改
“ERP是主系统”这句话过于笼统。商品编码和规格可能由ERP商品管理员负责，但商城面向客户的展示图片、卖点、上下架和营销标签可能由运营维护。客户主体、税务资料可能在ERP，客户对应业务员、商城货盘和等级价可能在订货平台。价格尤其要区分ERP基础销售价、商城显示价、客户协议价、促销价以及订单最终成交价；同一个数字在不同场景的名称相同，责任却不相同。企业应逐类字段列“谁创建、谁修改、谁审核、同步到哪里、冲突时以谁为准”。
图2：矩阵是实施讨论样例；真实主责随企业ERP能力与业务组织确定，避免两端同时修改同一字段。
商品映射不能只靠名称。ERP编码A100的“原味牛奶24瓶/箱”与商城编码M001，必须有稳定的外部编码关系；改名字不应让下一次同步误判为新商品。单位换算更关键：ERP按瓶计库存、商城按箱售，客户订2箱应对应48瓶，不能把“2”原样写进ERP的瓶数。客户也应使用稳定身份映射，避免ERP已存在的客户被商城再次导入成第二个往来单位。首次导入前抽一组有多规格、多单位、不同价和停用状态的商品，与真实老客户、多个收货地址一起验证，不能只用一个最简单SKU宣称建档完成。
如果双方允许同一字段都能修改，会出现覆盖循环：运营在商城把商品规格改成12瓶，ERP下一次同步又覆盖回24瓶；业务员在ERP把客户等级改为VIP，商城仍按普通价成交。合理的做法是一个字段只有一个更正责任人，另一端只能提变更申请或维护本端专属字段。重要变更保留生效时间，历史订单保留成交时的规格和价格，不能因主档后来变更就重算已确认订单。
一张订单沿原编号进入ERP，返回的是业务结果而非网络成功提示
客户在手机商城提交订单时，平台生成原订单号、客户、地址、商品行、单位、数量、单价、优惠、运费、付款条件和成交时间。推送ERP时要把商城订单号作为唯一外部业务键，让ERP知道“这条消息属于哪张原单”。网络超时后平台可能重发同一张订单；ERP不能再新建第二张销售单。接口返回“收到了请求”，也不代表商品编码匹配、客户有效、库存足够或单据已审核。至少区分已提交、传输中、ERP已接收、业务校验失败和最终ERP单据号。
图3：沿商城原订单号和ERP业务单号双向追溯；重复发送不能重复建单，拒绝需留错误原因与待办。
订单常见失败有四类。第一，商城商品无对应ERP商品编码或单位不同，接入端应拦截并交商品管理员修复。第二，客户在商城已获下单资格，ERP客户档案未审核或已停用，需要客户管理员处理，不能临时把单挂在“默认客户”名下。第三，商城促销后成交价与ERP价不同，应决定以商城成交价传入并保留优惠依据，还是下单前由ERP校验；不能到账时才发现差额。第四，ERP库存不足或信用控制不通过，必须回到原订单给客服和客户一个可处理状态，不能只在接口日志里留一条技术错误。
订单取消、修改和退款不能当作简单覆盖。客户提交后尚未进入ERP，取消可结束原单；ERP已建销售单但尚未发货，需按两端业务状态协调取消；已发货则进入退货或售后流程。接口同步的内容应是明确的业务事件和状态，已经出库的历史单不能因为前端点击“取消”就从ERP消失。若企业需要分批发货，ERP每一批出库结果与商城原订单的数量余额要对应，客户才能知道余货何时到。
异常重试必须沿原订单，不能为了让数字相等重新造单
项目试运行至少准备正常下单、同单重复发送、客户编码不存在、商品单位换算错误、ERP拒绝及取消后重推六组样本。正常样本要能在商城原订单找到唯一ERP业务单，并能从ERP单号反查客户原单。故意中断一次网络后再发送，若ERP出现两张销售单，就必须解决幂等问题后再放大范围；人工删除其中一张只是把测试痕迹藏起来，不是修复接口。
假设当天商城有100张有效订单，ERP接到98张。不能报告“同步成功率98%，基本完成”，而要找到缺的2张原订单号，判断是未传、传输失败、ERP业务拒绝，还是重复合并。修正客户或商品映射后对原单重试，保留重试时间、操作人、错误前后原因及ERP最终单号。若又新建两张人工订单补数，日终数量可能变成100，但商城原单与ERP单之间仍断链，后续出库、退款和售后会再暴露问题。
对接口密钥、客户联系方式和价格数据，应由授权岗位保管和查看；运维排障记录可以显示脱敏业务编号、时间与失败类型，不应在报告或公开文章贴出密钥、完整电话和原始敏感响应。技术对接由双方开发人员处理，订单是否可继续履约、是否通知客户由业务负责人确认。一个“HTTP成功”与一个“客户准时收到货”，中间隔着商品匹配、ERP审单、仓库出库和物流签收，任何一段失联都需有接手人。
用数量、金额和状态三组对账验证对接，而非只盯同步成功数
日终对账先固定同一时间窗口和订单状态。商城100张“有效”订单是否包括待审、已取消、已退款？ERP的98张是否包括昨晚延迟入账或今天重复收到的单？两端不先统一状态，单数相等也可能是错抵。第二层核订单行、规格和数量：两张单号都在，若一张2箱被ERP解释为2瓶，数量和库存仍错。第三层核成交金额、优惠、运费、税费和付款条件：ERP销售单金额与商城客户实际确认金额不同，要追具体哪一行价、哪种抵扣，而不是手工调总金额。
图4：对账先查缺单和重复，再看单位数量、实际成交金额及取消退货状态；差异留在可处理清单。
对账频率也要分场景。每天一次适合复核结果，不足以保障高频当日配送；紧急订单需更短的异常发现间隔，至少让客服在截单前看见ERP拒绝。库存同步若每小时一次，商城应明示或内部掌握更新时间，并对高风险商品设下单校验与人工审核；报表显示“有货”不能替代仓库实际出库。发现同步失败后，应有失败告警、负责人、处理时限和重试记录，不能等客户催货才打开接口日志。
上线评估可以用一组实际业务算投入：上平台前每日员工重复录入100单、平均每单3分钟，即300分钟；对接后若仍有大量订单因映射错误要人工修复，省下的时间并没有想象的大。再看客户自助查价和复购减少了多少咨询、仓库错拣是否下降、客户能否查交付进度、维护两个系统的新增成本是多少。若关键闭环跑通，再扩展商品、客户与库存；若对接质量不稳，先保持少量试点并修复，不能为了“全量上线”让员工在两套系统里同时记账。
上线验收用同一张客户原单跨两端走到底
选一位真实授权客户和一件有箱瓶换算、客户价及库存约束的商品，在手机商城下单，再到ERP查唯一业务单、商品数量、价格、应收和出库，最后回商城查交付状态。随后测试取消、重复推送、缺库存与一笔退货，确认原单贯穿全程且业务岗位能解释差异。每类数据的维护责任、同步方向、失败重试和日终核账都有具体负责人，才算“已有ERP”的企业真正获得了新增订货入口，而没有付出一份重复维护的代价。