报错：根据分录候选键phone, email找到重复值XXXX，请修改候选键! 问题解析

执行日志报错信息如下：

根据分录候选键phone, email找到重复值XXXXXXX，请修改候选键!

RpcRequest-10.224.20.127:20880-thread-247/traceId:426942df06a32255/time:1731566994687/serverId:7@10.224.20.127

kd.isc.iscb.util.except.IscBizException: 

at kd.isc.iscb.platform.core.connector.self.DoBizAction.filterEntry(DoBizAction.java:935)

at kd.isc.iscb.platform.core.connector.self.DoBizAction.updateEntry(DoBizAction.java:814)

at kd.isc.iscb.platform.core.connector.self.DoBizAction.setDynamicObjectValues(DoBizAction.java:765)

at kd.isc.iscb.platform.core.connector.self.DoBizAction.update(DoBizAction.java:491)

at kd.isc.iscb.platform.core.connector.self.DoBizAction.bizAction(DoBizAction.java:229)

at kd.isc.iscb.platform.core.connector.self.DoBizAction.execute(DoBizAction.java:83)

at kd.isc.iscb.platform.core.connector.self.SelfConnectionFactory.doBizAction(SelfConnectionFactory.java:336)

at kd.isc.iscb.connector.ierp.svc.DoBizActionService.exec(DoBizActionService.java:35)

at kd.isc.iscb.util.connector.server.AbstractCommandExecutor.exec(AbstractCommandExecutor.java:15)

at kd.isc.iscb.util.connector.server.CommandDispatcher.execute(CommandDispatcher.java:171)

at kd.isc.iscb.util.connector.server.CommandDispatcher.access$100(CommandDispatcher.java:30)

at kd.isc.iscb.util.connector.server.CommandDispatcher$1.run(CommandDispatcher.java:147)

at kd.isc.iscb.connector.ierp.IerpTaskExecutor$1.run(IerpTaskExecutor.java:16)

at kd.isc.iscb.platform.core.task.TaskWorker.innerExecute(TaskWorker.java:161)

at kd.isc.iscb.platform.core.task.TaskWorker.execute(TaskWorker.java:142)

at kd.isc.iscb.platform.core.task.TaskWorker.access$400(TaskWorker.java:35)

报错原因：目标系统数据已存在，且该数据分录中存在很多相同候选键值的历史分录数据

问题解析：通过日志堆栈可以看到，执行的逻辑时：目标数据的更新操作，在执行分录更新逻辑前，会拉取该条目标系统数据的所有已存在的分录信息，此时，若该历史数据的分录已存在相同候选键/组合候选键值的分录信息，则会抛出该异常信息。

解决办法：

1. 判断所选候选键是否合理。

2. 确认是否为垃圾数据，先修复目标系统中的历史数据。修复好数据后，重新执行同步。

分析思路：

首先，通过方案配置的表头候选键值，去目标系统中搜索对应数据，确认其分录是否已存在上述问题。

可能有客户发现通过候选键值查询目标系统数据实际不存在，但通过日志看是走了更新逻辑。此时，需要查看集成方案的字段映射具体配置，若目标系统为星瀚（苍穹）系统，且目标集成对象为实体类型，如果方案中配置了id映射，即id->id，则会优先已ID作为判断目标系统数据走更新还是新增逻辑，也就是此时排查时需要通过ID查询目标系统数据，这时若存在数据，则排查该条数据的分录信息即可。

但造成上述候选键值查询目标系统数据不存在，但通过ID查询存在的原因，可能有如下几个：

1. 目标系统历史存在数据，恰好和原系统数据ID一致，此类场景在方案初始化前应判断好目标系统是否存在存量数据的场景，并优化方案配置；

2. 目标系统本不存在存量历史数据，数据均由方案执行同步到目标系统，但初始化同步后，后续人为在原系统中篡改了对应数据的候选键值，如单据编码等，此类作为候选键的属性信息本就应该唯一且不允许修改，这类应规范现场操作，不应随意篡改候选键属性信息，极易导致数据混乱。

注：

数据同步过程走的实体类型操作，且配置了id映射时，如果源系统数据为：AAA（id=001），初始化同步到目标系统后，目标数据也是：AAA（id=001），如果后续人为在源系统中篡改了源候选键AAA->BBB，这时由于配置了ID映射，也会以对应id优先查询判断更新还是修改。