员工福利资格文件为什么不能只交新增名单：以Wellhub为例

员工福利平台接入时，一份只有几行的表格也可能造成误解：人事人员认为自己只是提交本周新增员工，接收方却按完整资格名单理解。问题不在表格大小，而在双方对文件范围的定义是否一致。

Wellhub开发文档把Full File解释为包含全部符合资格员工的文件；此前符合资格、后来不再符合的人应从下一份文件中去除，新取得资格的人则加入下一份文件。文档同时说明，哪些人员符合资格由公司决定。[1] 因此，不能把其他公司的人员范围直接当作自家福利政策。

用一组虚构数据说明：上次名单是甲、乙、丙，本次丙退出，丁加入。如果对接约定为全量文件，那么此次表达的集合应是甲、乙、丁；只交丁这一个名字，表达的就是另一件事。这里仅演示集合含义，不代表某个接口已经执行删除，更不是对真实员工权益的判定。

编号格式是另一个容易被忽略的细节。官方FAQ提醒，在CSV中保留数字字段的前导零。假设内部编号为00027，把它显示成27可能让两个系统对不上同一条记录。准备资料时，可用一两个虚构编号检查保存后的文本，确认软件没有自作主张改变标识。

文档也区分空字段与空格，并说明字段内容如果包含分隔符，应使用引号包围。[1] 例如部门名称本身含有分号，而文件又用分号分列，就需要按约定处理，不能仅凭电子表格看起来整齐便认定输出格式正确。阅读导出的文本样本，能帮助发现这种显示层与文件层的差异。

不过，格式正确与人员范围正确是两道检查。前者关注编号和列有没有变化，后者关注谁应在名单里。人事资格决策、数据整理和技术发送可以由不同岗位负责，但最终交接时应说明这是全量还是增量、采用哪个时点的名单。不要以一次上传成功代替人员范围确认。

本文围绕公开文档提出资料准备思路，没有调用Wellhub接口，也没有读取或展示真实员工个人信息。实际更新频率、字段要求和资格规则，应以企业自己的服务配置及当前官方对接说明为准。把集合范围和数据格式同时说清楚，才不会让一张福利名单承担与原意不同的含义。