泛微OA与ERP集成后出现单据号重复，通常不是单一原因：可能是号段分配在两侧各做各的、重试机制放大了重复提交，也可能是历史数据迁移时旧号与新规则撞车。排查要先把现象定下来：重复是发生在 OA 侧的单据主键，还是 ERP 侧的业务单号，还是同步表里的外部编号。不同位置的重复，根因和治理方式并不一样。
下面按「场景 → 候选方案 → 代价与边界 → 决策建议」展开三种常见做法，并说明什么情况下不要选它。需要具体落地协助时，可参考我们的软件定制开发与系统集成服务。
场景一：OA 先落单，ERP 后建单，号由 OA 生成
这是不少协同办公与业务系统对接时的默认做法：员工在 OA 发起申请，审批通过后由接口把单据推到 ERP，单号在 OA 提交瞬间就已确定。问题往往出在重试与补偿上——接口超时后调用方重发，ERP 侧无法识别这是同一张单，于是按新单处理；或者号段缓存没有落库，服务重启后重新发号。
- 优点：用户体验直接，提交即见号；OA 表单、打印模板、附件归档都以该号为主键，展示一致。
- 代价：号段分配必须持久化并加锁，否则并发或重启容易重复；ERP 侧需要接受外部单号，对已有编码规则有冲击。
- 适用边界：OA 是流程发起方，ERP 只负责后续执行，且单号不需要与 ERP 内部既有编码体系强绑定。
对应排查可先从“发号记录是否存在待确认状态”入手，核对重复单的创建时间与接口重试日志是否吻合。判断标准是：同一业务键（如申请人加业务类型加日期）在 ERP 侧是否已有同源记录。
场景二：ERP 生成正式单号，OA 回写
另一种常见做法是 OA 推送业务数据，ERP 按自身规则创建单据并返回正式编号，OA 再回写展示。这种方式单号归属清晰，但回写链路一旦失败或乱序，就会出现“ERP 有单、OA 无号”或重复回写覆盖号。
- 优点：ERP 内部编码规则完整保留，财务、仓储等下游系统不受影响。
- 代价：链路多一跳，回写失败需要补偿；如果 ERP 侧不按业务键判重，重试会直接创建多张单，形成事实上的重复。
- 适用边界：ERP 是主数据与正式凭证的管理方，OA 只做流程入口和展示。
这类场景的根治点在 ERP 接口层：要求创建动作具备幂等能力，可用业务唯一键做唯一约束，或由接口侧维护请求流水。我们做过的同类集成见同类项目案例，多为 OA 与 ERP、HR 双向对接的组合。
场景三：中间号池统一分配，两侧按号对齐
当两侧都已有成熟编号规则、短期无法改造成本较高时，可以设一个独立的号池服务或中间表，由它统一发号，OA 与 ERP 都向它申请。它的好处是单号来源唯一，问题是多了一个必须高可用的组件。
- 优点：号源单一，从机制上减少两侧各自发号产生的冲突；便于集中审计。
- 代价：引入新的依赖，号池本身要做持久化与并发控制；历史数据仍需一次性清洗。
- 适用边界：系统数量较多、集成关系复杂，且允许在两侧之外增加一个轻量的分配环节。
如果选这条路，建议先明确号池的受理边界：哪些单据类型走号池、哪些仍由原系统自增，不要一次性全量迁移，避免影响面上过大。
什么情况下不要选上述方案
方案是否合适，更多取决于业务约束而不是技术偏好。以下情况建议换思路：
- 不要为了统一单号去改动 ERP 的既有凭证编码规则，尤其是已经与财务、税务、审计口径关联的编号；这类改动影响面通常超出预期。
- 不要在 OA 表单上直接做自增序号来充当正式单号，并发和重启都会把它变成重复源头。
- 不要依赖“接口只调用一次”的假设，任何跨系统调用都要按可能重试来设计，否则补偿机制本身就是重复来源。
- 如果两侧系统都在国产化适配或升级窗口期，不要同时改号规则与接口逻辑，先把问题隔离到一处。
- 不要用数据库唯一索引之外的手段做“事后去重”，重复单据一旦进入审批或结算流程，清理成本会明显上升。
排查顺序与根治要点
排查建议按“定位重复位置 → 回溯发号路径 → 检查重试与并发 → 核对历史数据”的顺序做，每一步都留下可复核的记录。
- 抽样重复单据，确认重复的是 OA 主键、ERP 单号还是集成中间表记录，先缩小范围。
- 核对发号动作是否持久化，服务重启、缓存失效时是否会重新从起点发号。
- 检查接口重试策略：超时重试有没有带业务唯一键，接收方是否能识别重复请求。
- 核对历史迁移数据，旧号规则与新规则是否在同一字段上并存，必要时做映射表。
- 在接收端补唯一约束或幂等处理，并把失败记录落到可查询的日志表中。
验收时可以用重复提交、接口超时、服务重启三类场景做回归，观察单据数量与编号是否仍然唯一。需要看更多技术实现思路，可以翻阅我们的更多技术实现细节。
文字版对比清单
把三种方案放在一起，按“方案 → 适合谁 → 主要代价”逐行对照，便于开会时直接使用：
- OA 生成单号 → 适合流程发起在 OA、ERP 只做执行的场景 → 代价是号段要持久化加锁，ERP 需接受外部编号。
- ERP 生成单号 → 适合 ERP 作为主数据与凭证管理方的场景 → 代价是链路多一跳，回写失败要补偿，创建接口必须幂等。
- 中间号池统一分配 → 适合多系统集成、号源需要集中审计的场景 → 代价是新增高可用组件，历史数据要清洗。
常见问题
问：重复只出现在月末集中提交时段，是不是并发问题？
集中提交会放大并发和重试的概率，但根因仍要看发号是否原子。建议在接收端按业务唯一键做约束，发送端带请求标识，而不是只靠调大队列或延长超时。
问：历史重复单据能不能直接改号？
已经进入审批或结算流程的单据不建议直接改号，通常的做法是保留原流水，另建对照关系，新增业务走新规则。涉及财务口径时，先与使用方确认再动手。
问：集成中间表要不要也做唯一约束？
建议做。中间表是排查时最直接的证据来源，重复记录如果不拦住，会给后续对账带来额外解释成本。具体约束字段取决于业务键怎么定义。
不同系统组合下的方案取舍并没有统一答案，如果希望结合现有架构做一次评估，可以通过联系我们沟通。
