ERP同步记录处理：失败原因、关联单据与再次同步｜云上订货系统
云上订货 · 更新于 2026-10-08
同步记录先辨原业务与首个反馈，消息登记、执行状态和原单结果逐层回查，再决定怎样接续。
1. 从ERP原业务进入本条同步记录
处理ERP同步问题，先找到本企业对应ERP连接和原同步记录，保记录编号、业务类型、状态、时间及关联单据，再解释本次失败。这里处理的是ERP库存、订单及回调业务记录，不能把OpenAPI渠道的签名授权问题、商城付款结果或一张普通订单截图当成同一条同步日志。
管理端从应用中的ERP数据同步进入对应连接设置，再查看同步记录页。参数、仓库、商品与记录分别承接不同工作；没有看到记录时先核当前企业、连接和岗位实际可见范围，不把另一企业的日志或另一连接的时间带过来。历史应用卡片只辨认原业务，不证明当前入口可用或任何同步已经成功。
保留异常发生时的原条件和已经形成的原单，据此判断是尚未收到消息、消息已登记未执行、处理失败，还是已处理但业务结果与预期不同。对接人员先保脱敏反馈，仓库或业务岗位核原对象，不能一开始便重试整批数据、补新单或调整库存使表面数字相等。
图1：历史PC ERP数据同步卡片仅辨原业务，不是本次失败记录、再次同步或原单完成证。
2. 业务类型状态触发方式和时间分别读
本页实际列出同步类型、同步状态、失败原因、关联单据与同步时间。同步类型指库存同步、订单上传、订单取消以及库存、取消、物流、售后等回调业务，不能与定时或手动触发方式混成一组。先选对应业务类型，再读当前结果，避免在库存日志里寻找一张售后退货单。
状态区分未同步、同步成功与同步失败。未同步可以表示原消息已登记等待后续处理，不等已经执行后失败；成功也只代表该处理分支的反馈，不自然包含库存、审核、退款和银行到账全部闭环。定时、手动是原记录的另一项来源，不能仅凭列表的同步类型名称推定是谁触发。
同步时间是本条记录的创建时点，并不是各原订单或盘点单完成时间。上次同步时间也不是专取最后成功记录，时间更新后仍要回看对应原日志状态。本页没有通用成功数量汇总或任意业务日期选择的承诺，分页和类型条件按当前真实范围核，不借不存在的筛选控件宣布已查全所有失败。
图2：同步日志字段图：日志业务类型、同步状态、原因单据与时间分层核。
3. 失败原因先辨原消息再找首次真实反馈
失败原因栏先辨内容来自哪里。金蝶库存失败记录可保存此次处理的异常说明；回调登记则可能把原消息内容留在同一栏。执行后状态改变，并不保证原因栏已被改成最后一次执行错误。因此不能见一大段原消息就认定它是错误原因，也不能看到空白就认定没有异常。
如果有明确首条提示，保提示发生的时间、原记录编号和原对象，按它核对应资料。没有可读错误时，继续查本次实际业务反馈及同时间窗的脱敏处理记录，不猜测账号、仓库、数量或资金必有哪一种错误。原内容含客户联系方式、地址、凭据或业务明细时，不公开整段复制，保排障所需的非敏感关联即可。
应先解释第一处阻断，再看后续状态。例如没有可以同步库存的仓库，与外部没有可同步数量不是同一问题；原订单找不到，与物流公司编号不存在也不能同样处理。修正对应对象后重新核原反馈，不能同时改多套映射而失去最初原因，旧原因栏仍显示时保前后真实状态分别判断。
图3：同步失败原因核对图：原消息内容、首个业务反馈与失败对象逐项对应。
4. 关联单据按库存订单物流和售后定位
关联单据要按业务类型定位。金蝶库存差异可生成对应仓库盘点单，成功日志保存这些盘点编号；一条记录可能关联多张，也可能因没有差异而没有新单。先对原仓库、规格和明细，不把空关联栏当成同步失败，也不认为只要有盘点号便说明全部外部规格都匹配了。
订单上传或取消记录可保原订单编号，物流回调要追原订货明细、出库和运单，售后回调要对原订单及退货数量。回调刚登记时不保证关联单据已经填齐，本页也不能承诺每条关联编号都有一键跳单按钮；缺直接入口时依据原编号到对应业务查实际保存状态。
失败前可能已有部分业务结果。保原日志、原消息对象及已存订单或盘点关系，核哪些明细已处理、哪些尚未匹配；同商品名称、同数量或同金额不能代原编号相同。不要重建一张新单来补齐日志字段，随后又把新单误当原同步结果；原外码后来修改时也要回到当次实际关联解释。
图4：同步关联单据图：库存盘点、原订单物流退货及空关联的不同核法。
5. 再次同步按原回调类型和已办结果判断
再次同步按钮承接的是所选原记录的消息处理，不是所有ERP对象的通用重试。库存、订单取消、物流和售后四类回调分别进入对应业务处理；普通金蝶库存同步、订单上传和普通取消记录，不能据同一个按钮名称推为全部重新执行原任务。
操作前先确认这条原记录是否确属可承接的回调、消息内容是否有效、对应业务是否已经保存。不能假定按钮只有失败状态才可用，也不能对成功或未同步记录反复点击求数字一致。界面存在操作不代表重复执行一定安全，更不等重复执行一定不会再生成退货或改变库存。
修正仓库外码、规格外码、原订单或物流资料后，先保修正前的映射及原结果，再由授权岗位沿实际类型办理。再次同步并不自动使用一套新消息替换原消息，也不能通过修改列表文字修复外部对象。若是原类型没有对应执行分支，保原反馈并回到该业务自己的触发和查询流程，不借回调按钮覆盖所有连接。
图5：原回调再次处理图：四类原回调与普通ERP日志的实际范围分开。
6. 消息登记执行回写与刷新分层验结果
回调处理分为接收登记、实际执行、状态回写与查询显示。外部收到成功反馈可能只说明消息已经登记，初始仍未同步；业务执行后又有独立成功或失败结果。列表刷新动作与状态回写之间也有先后，不把刚点击后的旧行当成最后结果。
再次同步的请求返回与实际业务结果不是一张统一成功证明：执行异常可能被记录到处理反馈，后续状态另行更新，而界面操作返回并不自然包含每一明细的最终结果。保原记录编号，再查本次真实返回、最后处理状态以及原业务单，不只看按钮无报错或列表颜色改变。
处理后原因栏还可能保原内容，需要把旧原因、本次首条反馈和状态更新时点分开。若查询失败，原列表或旧资料仍显示不能当成新成功；若状态暂未变化，也先核是否仍在回写，不反复重放。没有实际运行资料的自动任务或消息调度保持待核，不能只凭旧任务说明认定当前同步任务运行正常。
图6：同步消息接续图：消息登记、业务执行、状态回写与本次回查分层。
7. 各业务原数量状态和资金结果分别查
库存分支核原映射规格、仓库、基本单位、差异盘点和系统数量。金蝶只有匹配且有差异才形成盘点明细，未匹配不等自动新增商品；聚水潭库存回调也可能因缺仓库或缺匹配而没有变化，成功状态不能代外部每条数量均已落地。可用库存还受占用影响，应与系统库存分开核。
取消分支回到本企业原订单和实际状态，不把取消反馈成功等同客户退款已经到账。物流分支核原明细、发货数量及单位、运单号和发货状态，保存发货资料不等客户签收。售后先查原订单及外部规格对应的订货清单，核原退货数量和保存结果，再分别看审核、退货入库和退款办理。
这些结果不能由日志成功一项互相替代；资金到账仍按原资金和通道结果核，不凭ERP反馈重付或补退款。对于已有原单的记录，先对原关系和已办明细，再决定未办部分怎样接续。若只有局部实际依据，明确未覆盖对象，不承诺再次同步能够自动补齐全部后续状态。
图7：各类同步业务结果图：库存、取消、物流、售后各自业务结果与完成边界。
8. 修正后单条核验及扩大范围保原证据
修正前留一份原记录条件、首条反馈、对应映射和已存业务结果，区分已办与未办。对缺仓库、缺规格、错企业订单或物流编码分别核实际对象；不是任何失败都应换令牌，也不是重新保存参数就等于原消息已重新处理。对没有新盘点的成功记录，先查是否无差异，再决定是否仍有遗漏。
核验以单条原结果为单位：对原消息对象、前后业务状态、数量单位、关联单据和本次反馈，确认实际改变了什么。页面时间变新、状态成功、按钮返回或某张单据保存，均不能独立代完整验收。金蝶手动同步还有频繁操作限制，遇此提示先保原日志及最近操作，不连续点击绕过。
扩大范围之前逐条保剩余差异及真实办理依据，不把一条局部成功扩成整批数据、所有连接或每日任务已通过。当前部署、完整岗位权限、调度和同数据结果仍需实际核；历史画面只用于识别当时字段，不代本次实际处理结果。接续交接保原编号与未覆盖节点，避免重复同步、补单或调库存制造一致。
图8：同步修正接续图：失败资料修正前后、单条原结果及扩大范围分别验收。
下一步学习
- ERP与OpenAPI数据对接：同步范围、配置与结果核对｜云上订货系统
- 外部ERP库存映射：仓库与规格编码匹配及同步核对｜云上订货系统