OA审批单与ERP工单双向同步时字段被覆盖，根因通常不在接口本身，而在于没有提前约定「每个字段由谁说了算」。当两边都能改写同一字段、又都按整单覆盖的方式写回时，后写入的一方会把对方的修改抹掉。排查时应先定位被覆盖的字段归属，再选择与之匹配的同步策略。
先判断场景：哪些字段天然容易冲突
不同字段的冲突概率差别很大，建议先把审批单和工单的字段分成三类，再讨论方案。这样能避免一上来就改接口，把问题复杂化。
- 审批侧主写字段：审批状态、审批人、审批时间、审批意见。这些字段在ERP侧一般只读。
- 业务侧主写字段：工单编号、计划开工时间、执行人、完成数量。这些字段在OA侧一般只展示。
- 双写字段：备注、优先级、附件、状态描述。这类字段两边都可能改，是覆盖的高发区。
把字段清单拉出来，逐项标注主写方与是否允许双写，是后续所有方案的基础。清单不确定时，可以先把同步范围收窄到必须字段，后续再扩。
方案一：单向主写，另一侧只读回显
最稳妥的做法是只保留一个写入方向。例如审批结果由OA写回ERP，ERP的工单进展由ERP单向推送到OA用于展示，OA侧对应字段置为只读。这样从结构上消除了互相覆盖的可能，排查成本也最低。
- 优点：实现简单，责任边界清晰，出现问题时容易判断是哪一侧写错。
- 优点：不需要复杂的变更检测，联调与验收都好推进。
- 代价：业务上如果确实需要两边都能改，单写方案会牺牲一部分操作灵活性。
- 代价：字段只读后，用户可能转而用线下方式改数据，反而带来新的对账问题。
适合审批流为主、ERP侧重执行的场景，例如制造与物流供应链中的工单审批。已有同类项目可参考物流与供应链方向的系统集成案例，思路是把审批权与执行权分开。
方案二：字段分组归属，按组写回
如果业务上必须双写，可以按字段分组划归属：每组字段只允许一个系统写，同步接口按组提交，而不是整单覆盖。写回时只携带本组字段，未变更的组不参与更新。
- 优点：保留双写能力，同时把覆盖范围限制在组内，冲突面明显缩小。
- 优点：字段归属可以写进接口文档，后续维护有据可依。
- 代价：需要维护一份字段归属表，组织或流程调整时要同步更新。
- 代价：如果组划得过粗，组内仍会互相覆盖；划得过细，接口数量和联调工作量都会上升。
字段分组通常要结合表单与流程定制一起梳理，国产OA的二次开发一般也在这个层面做适配。具体实施方式可以看我们的软件定制开发与系统集成服务，里面说明了从字段梳理到联调的交付过程。
方案三：版本号与变更检测，按字段合并
更彻底的做法是给记录加版本号或更新时间戳，写回前先比对版本，检测到对方已修改就拒绝覆盖或按字段合并。这种方式对接口设计能力要求更高，但能覆盖前两种方案顾不到的场景。
- 优点：能识别并发修改，冲突时给出明确提示，而不是静默覆盖。
- 优点：适合审批与执行节奏都很快、双写频繁的业务。
- 代价：两侧系统都要配合改造，老系统不一定方便加版本字段。
- 代价：出现冲突后的处理逻辑（提示、挂起或人工合并）需要业务方一起定，不能只靠技术侧决定。
这类改造涉及接口协议与数据模型的调整，建议先在POC阶段验证一条主流程，再逐步推广。政府与国企场景下还要考虑国产化环境下的中间件与数据库适配，可参考政府与国企国产化改造案例中的集成做法。
什么情况下不要选某种方案
选型不只是看哪种方案更强，也要看哪种方案在当前系统条件下不成立。
- ERP是成熟商业产品、不允许改数据结构时，不要选版本号合并方案，改造成本与风险都不在可控范围内。
- OA侧表单频繁调整、字段归属经常变化时，不要选粗粒度的字段分组，归属表很快会失真，反而制造新的覆盖问题。
- 业务明确要求两边都能实时改同一字段时，不要勉强做单向只读，用户会绕过系统操作，后续对账更麻烦。
- 没有明确的字段清单就开始联调时，不要急于上双向同步，先把主写方定下来更省事。
排查步骤：字段被覆盖时怎么定位
线上已经出现覆盖时，可以按下面的顺序缩小范围，避免在接口层反复猜测。
- 取一条被覆盖的记录，比对两侧的操作日志与更新时间，确认最后写入方。
- 核对同步接口的入参，判断是否携带了整单字段而非变更字段。
- 检查字段映射表，确认同一目标字段是否被两侧都映射。
- 查看是否有重试或补偿任务重复触发写回，导致旧值覆盖新值。
- 复现时用固定测试数据，逐字段修改，观察哪一次写回把值冲掉。
定位到具体字段后，再回到上面的方案中选一种落地。需要看更细的技术实现说明，可以翻阅我们整理的系统集成相关技术文章，里面有接口联调与验收的通用做法。
文字版对比清单
下面按「方案 → 适合谁 → 主要代价」列出三种方案的取舍，便于在评审会上快速对照。
- 单向主写 → 审批与执行职责清晰的团队 → 放弃部分双写灵活性，需推动用户改变操作习惯。
- 字段分组归属 → 业务上必须双写、字段边界可梳理的团队 → 维护字段归属表，组粒度需要反复调。
- 版本号与变更检测 → 双写频繁、系统可改造的团队 → 两侧都要改，冲突处理逻辑需要业务确认。
无论选哪种，验收时都建议确认：字段归属表已归档、同步接口只提交归属字段、重试任务有幂等控制、覆盖事件能被日志追溯。需要落地支持时，可以通过联系我们沟通具体场景。
常见问题
双向同步一定要做版本号吗？
不一定。版本号解决的是并发修改识别问题，如果业务上可以接受单向主写，版本号不是必需品。先看字段归属是否清晰，再决定要不要加。
字段分组后仍然被覆盖，通常是什么原因？
常见原因是接口仍按整单更新，或者补偿任务重放了旧数据。建议检查写回接口的更新范围，以及重试是否有幂等控制。
历史数据已经被覆盖，怎么处理？
一般以某一侧为准做一次对账修复，并在修复期间暂停双向写回，避免修复过程再次被冲掉。修复完成后补齐字段归属约定再恢复同步。
