Excel批量导入管理系统，怎样处理重复行、部分失败和重试

Excel 导入出错后，不能直接要求用户“改好再传一次”。系统应先说明哪些记录已经写入、哪些没有写入、哪些结果仍待确认，并按业务唯一标识识别重传。建议在软件开发需求中明确导入模式、提交单位和错误清单，这三项决定修正文件后会不会重复或覆盖已有业务。

新增、更新和跳过要在导入前选清楚

同一行遇到现有记录，可能需要报错、跳过或更新，不能由开发方凭文件内容猜测。唯一标识应使用业务认可的组合，例如“所属组织＋外部单号＋明细号”，不能使用 Excel 行号，也不能仅以客户名称判重。新旧文件排序变化后，业务身份仍应稳定。

更新模式还要列出允许覆盖的字段；空单元格究竟表示不修改还是清空，应单独约定。已审批、已关闭的记录是否允许导入修改，也要由服务端检查。整体接入方式可参阅企业数据接入说明，但“支持 Excel”本身没有回答这些写入规则。

预检结果不应成为永久有效的写入许可

建议预检文件结构、必填项、数据类型、同文件重复、系统内重复、关联对象与用户权限。编号中的前导零、日期格式、单位和小数精度应按模板定义保留，不能猜测转换。Microsoft 的 Excel 导入说明也列出了类型转换和重复键问题；这是产品实例，定制系统仍须制定自己的处理规则。

预检到正式提交之间，别人可能修改记录或撤销权限。提交时应重新核验会影响写入的条件；发生变化就返回具体冲突，而不是沿用旧的通过标记。若内容检查与落库规则不同，预检绿灯容易制造错误预期。

决定哪些内容必须一起成功

一份文件含多张订单时，通常需要先讨论“同一订单的主表与明细是否必须一起成功”。不能为了实现逐行成功，让订单只留下半套明细。以下是可选方案，需按业务关系确定，不以文件大小直接决定。

PostgreSQL 事务说明介绍了整体提交、回滚与保存点机制。能使用这些机制，不代表导入边界已经选对；数据库回滚也不能当作已发外部通知自动撤回的保证。验收时要同时核对记录及约定的后续动作。

用一份部分失败清单验证重试

假设一次导入 100 条独立记录，结果是 92 条已提交、5 条校验失败、3 条因响应中断待确认。任务页应保留任务号、原行号、业务标识、状态和原因。5 条可修正后重传；3 条应先查询该任务的真实结果，不能直接视为失败创建新记录。

建议错误文件只导出需要修正的行，同时保留原任务引用；用户若误传完整文件，已完成记录仍应按所选规则识别。记录修改前后值及新任务与原任务的关系。超时后恢复页面，应能找回任务，而不是只剩一个可再次上传的空入口。

交付时检查重传、并发和事后撤销

1. 同一文件连续提交两次，再调整行序重传，核对没有意外新增。
2. 修正失败行后重导，核对成功行未被重复执行或无意覆盖。
3. 预检后让另一账号修改同一记录，检查提交能识别约定的冲突。
4. 模拟任务中断，重新进入后核对已提交、未提交和待确认结果。

导入完成后的“撤销”也应限定：若记录已被审批或后续业务引用，不能简单删除整批。应确认允许撤销的状态，以及受影响记录如何单独处理。外部编码和关联记录的责任边界可参照跨系统对象与接口归属，把导入规则落实到实际业务对象上。