数据传输后如何逐条核对记录？

先明确要比较哪些记录

把表格导入另一个系统后看到成功提示，确实令人安心。但提示通常只表示技术操作已经结束。信息是否对应正确的客户、文件和日期，还需要另外检查。核对的含义，是按照同样的规则比较源数据中的预期结果与目标系统的实际记录。目的不是把每个差异都当作错误，而是能够解释每个差异。

开始前写明源文件版本、日期范围和记录类别。已取消的业务、空行和以前导入过的信息是否排除？如果事后改变这些决定，同一批数据也可能得出不同的检查结果。保留不再改动的源文件副本，并记录操作时间，有助于避免混淆。

结合记录标识理解行数

来源与目标行数相同，是有用的初步信号，却不是验证结论。某条记录可能重复写入，另一条完全遗漏，总数仍然相同。因此，需要确定能够区分记录的键，例如工作编号、单据编号，或者适合业务的多个字段组合。姓名可能重复，不能默认它唯一。

如果目标系统生成新编号，应保留新编号与源键的对应关系。这样才能追踪遗漏的位置，并知道重新运行时应更新哪条记录。源数据的键重复时，不要假定系统会正确合并。应与业务负责人事先确定合并、拒绝或分别建档的规则。

明确字段映射和转换规则

进行批量数据录入时，制作简短的源列与目标字段对照表。日期、数字、币种、单位和空值规则也应写入。去掉开头的零可能改变编码含义；误读小数分隔符则可能让看似有内容的单元格变成错误数值。

比较不一定要求逐字相同。经确认的规则可以去掉首尾空格，或者把日期换成含义相同的格式。关键是事先定义转换方式，不能在检查中临时增加规范化规则来掩盖意外差异。信息缺失、零和未知也不应视为同一个值。

检查汇总值及业务关系

对数值字段进行汇总检查很有用，但必须说明包含哪些记录。不同币种或计量单位不能直接合成一个总数。发生舍入时，要明确在哪一步进行。总数相等也不能替代逐条核对：两个错误值可能互相抵消。

还要检查关联关系。订单明细是否归属正确订单？附件是否挂在正确客户名下？标为已完成的工作是否真的具备全部必填信息？单看文件格式无法回答这些问题。把日常业务规则转化成可观察的检查项，并先在少量具有代表性的样本上试验。

记录异常，不要悄悄跳过

检查报告除了成功记录，还应展示被拒绝、未完成和需要复核的记录。每个异常应包含源键、相关字段、预期值、实际值及下一步操作。阅读者应能理解为什么需要重新查看该记录。涉及敏感信息时，应按需要限制报告的访问权限和展示细节。

例如，不导入地址缺失的记录，并在报告中清楚标明，可能是合理的设计选择。猜测地址并补齐则属于另一种操作，需要另行确认规则。保存技术错误信息，并补充业务人员能理解的简短说明。修正后，还应能看出哪些受影响记录已经重新检查。

注意：重新运行不能制造新重复

连接中断后，如果不知道哪些记录已经处理，重新发送整个文件可能生成重复数据。应能够区分成功、失败和待处理项。再次运行时，已有记录是更新、跳过还是停止？不能只在说明中写清楚，还应通过实际测试观察结果。

修改正式数据前，要确定回退方式和权限。测试样本中的个人或商业敏感信息应尽量减少或脱敏。不要把检查文件放到公开文件夹。如果检查期间源数据仍在变化，应固定数据，或写明如何计入这些变化，否则比较的是两个不同时间点。

传输开始前写好验收标准

最终报告不应只有“传输完成”，还应列出范围、已比较记录、已解释差异和剩余异常。可接受哪些差异，应由业务负责人提前确定。自动化验收测试中的原则同样适用：预期结果必须能够观察，也能用同一样本重新验证。

URIKEM从您的实际工作流程出发。请说明数据从哪个文件传到哪个系统，以及现在如何检查结果。范围确定后，可以一起设计传输和验证步骤。这样，交付内容不仅包括写入数据，还可以包括清楚说明软件完成了哪些操作的结果记录。

常见问题

行数相同就表示传输正确吗？

不是。重复和遗漏可能在数量上互相抵消，还需要比较唯一标识、字段及相关业务规则。

所有不同的值都是错误吗？

不是。提前确认的格式或舍入转换可能产生差异。应说明依据的规则，不能在检查中隐藏意外差异。

出错后应重新发送整个文件吗？

应先确认哪些记录已经处理，再测试源与目标的映射及更新或跳过规则，避免重复写入。