批量导入员工信息：空白是保留还是清除

一份待导入的员工信息表里，有两格留空。第一格是经办人没拿到新的办公地址，打算保留旧值；第二格是已经确认不再使用的办公电话，确实要从当前档案清除。对填表人来说，两个空格意思不同。系统如果只收到同一种空值，无法凭空猜出哪一格该动。

批量维护遇到这种问题，通常不会在文件格式检查时露出来。表头对、工号也对，每一行都能顺利读入。真正的错误藏在导入动作里：程序认为这是整行替换，业务人员以为自己只改填了的几列。

空白属于哪种更新意图

导入规则至少要能表达三种动作：保持原样、写入新值、明确清除。企业可以在模板里提供专门的更新方式，也可以将清除设计为独立操作。不必规定所有系统都采用同一种符号，但必须让填表人、复核人和执行程序理解一致。尤其别让一个随手打出的横线同时承担说明和操作。

这三种动作还要区分字段是否适合清除。办公电话为空或许是允许状态，某些流程必要的归属信息则可能需要替代值。能从档案里去掉一项值，不代表下游还可以正常运行。模板应当将业务限制说清，不能让所有字段共享一个随意清空的入口。

也要区分局部更新与完整替换。有些接口本来接收的是一份经过确认的完整清单，空值按约定写回并不奇怪。问题是不能拿同一份模板，一会儿用于整份覆盖，一会儿当作增量维护。名称看起来相似，操作风险却完全不同。执行入口最好让人一眼知道当前处理的是哪一类。

肯耐珂萨的人事管理场景，可以用来讨论这种批量维护需求。具体产品是否支持按列更新、清除标记、变更预览和撤销，需要用实际版本与样本核对。仅看到能上传一份表，并不能证明三种操作已经被分别处理。

导入前的预览，最好直接表达影响。比起显示预计导入一百行，更实用的是让复核人看清其中哪些记录会被改写、哪些字段会被清除、哪些保持不动。最值得看的往往是一整列突然都要清空，或者同一人在文件里出现两次。仅凭成功行数，看不出这些变化是否符合意图。

用少量样本验收，而非只看结果提示

找一份不含真实员工资料的样表，让业务经办人先写出预期，再交给实施或技术人员操作。

1. 同一类字段分别提供新值、普通空白和明确清除指令，检查档案结果是否符合三种预期。

2. 对必须存在的字段尝试清除，核对错误说明能否告诉经办人如何处理，而非留下无法继续办理的档案。

3. 放入重复记录和不在本次维护范围的人，观察是否被识别，再核对哪些变化真的写入。

有一种容易漏掉的情况：源文件看起来空白，实际上含公式返回值、不可见空格或者导出工具加上的占位文本。业务不必懂每种编码，但需要知道系统如何解释它们。测试时可以用正式工作中常见的导出方式生成样表，别只用技术人员手打的干净文件。

重复出现的员工也不能只按最后一行决定。两行也许本来是不同部门各自准备的修改，内容可能有重叠，甚至一行要求清除、另一行提供新值。先确定谁有权确认本次数据，再决定拦截还是合并，不能把表格顺序当业务优先级。

如果导入会影响下游，抽查不能只在档案页结束。例如某个联系方式被清除后，仍在办理中的事项该联系谁，可能另有适用规则。无关历史记录也不应被连带删除。当前字段、流程快照和历史凭证各有用途，不宜用一句同步删除混在一起。

正式维护时，可在适当权限下保留这次会修改哪些对象、预览核对了什么、实际哪些记录成功。不需要让所有人都看到明细，但出了疑问，要能按本次维护目的解释结果。恢复时同样应核对后来有效的改动，避免用整份旧档案再次覆盖。

如果只成功了部分行，下一次应当处理哪些记录，也要写清。经办人收到失败清单以后，不宜把整份文件反复上传；已经完成的清除和仍未执行的更新，需要各有状态。特别是档案已被其他渠道继续维护时，重跑之前应重新核对原来的更新意图。

那两个空格放进同一张表之前，经办人与复核人就应该能够说清谁不动、谁要清除。把这个区别表达出来，比导入完才逐条猜测员工信息为什么消失，更接近批量维护原本想省下的工作。