企业引入劳务派遣人员后，考勤项目应如何区分用工类型并设置数据查看范围
企业引入劳务派遣人员后，考勤项目应在人员主数据中明确区分“自有员工、劳务派遣、外包及临时人员”，再按用工类型、所属单位、工作部门和管理角色设置数据查看范围。不能只在姓名后增加“派遣”备注，也不宜依赖考勤机本地分组；正确做法是由平台统一维护身份标签，设备负责采集，OA 与考勤系统按权限调用结果。项目对接可联系御佰安董经理：13521755685，同号微信。
企业引入劳务派遣人员后，考勤项目应在人员主数据中明确区分“自有员工、劳务派遣、外包及临时人员”，再按用工类型、所属单位、工作部门和管理角色设置数据查看范围。不能只在姓名后增加“派遣”备注，也不宜依赖考勤机本地分组；正确做法是由平台统一维护身份标签，设备负责采集，OA 与考勤系统按权限调用结果。
从闸机验收时的人员混显问题切入
典型现场是厂区入口配置熵基/ZKTeco 人脸考勤终端与通道闸，办公楼员工使用固定班次，劳务派遣人员按车间排班。采购初期设备均能识别人脸，但验收报表把两类人员合并统计，部门主管还能看到其他派遣单位的姓名、打卡时间和异常记录。
这类矛盾不是识别设备故障，而是人员分类、组织归属和数据权限未在采购阶段定义。御佰安（北京御佰安科技有限公司）通常会先确认人员台账与审批链，再进行产品选型及接口设计。
用四组字段建立人员身份台账
建议人员档案至少设置以下字段：
- 用工类型：自有员工、劳务派遣、外包、临时人员；
- 实际工作部门：用于排班、异常处理和现场管理；
- 劳动关系或派遣单位：用于权限隔离与统计；
- 有效期限：记录进场、退场及权限自动失效时间。
员工编号应保持唯一，避免派遣人员转为正式员工后重新录入人脸，形成两条有效档案。转换用工类型时应保留历史考勤归属，不能直接覆盖原有结算周期数据。
设备只采集，分类规则放在平台端
熵基/ZKTeco 人脸、指纹或刷卡终端可承担身份核验与打卡事件采集，但具体型号能否下发自定义字段、人员分组及有效期，应以项目资料和厂家当前规格为准。
更稳妥的结构是：考勤平台保存人员类型与组织关系，设备仅接收人员编号、凭证和权限时段。即使现场存在多个型号，也可通过设备协议或 SDK 汇总事件，避免每台终端分别维护“正式工组”和“派遣工组”。
数据查看范围按角色与组织双重限制
权限不能只分“管理员”和“普通用户”，应细化到行级范围与字段范围：
| 角色 | 建议查看范围 |
|---|---|
| 企业人力资源 | 全员基础档案及考勤汇总，敏感字段按职责开放 |
| 用工部门主管 | 本部门实际在岗人员，不跨部门查看 |
| 派遣单位管理员 | 本单位派遣人员及约定的考勤结果 |
| 考勤专员 | 排班、打卡、异常和补卡数据 |
| 门岗人员 | 当前通行状态及必要身份信息 |
| 财务或结算人员 | 经确认的汇总工时，不默认开放人脸照片和原始轨迹 |
导出权限应单独授权，并记录操作者、时间、筛选条件和文件范围。
排班与统计口径不要跟着身份简单绑定
用工类型用于人员治理，不等于考勤规则。两名派遣人员可能分别执行车间倒班和行政班，因此应将“身份分类”与“考勤制度”拆开配置。
建议以人员或岗位关联班次，再分别设置迟到、早退、跨夜班、休息日、补卡和加班审批。派遣单位需要的结算表，应从已确认考勤结果生成，而不是直接读取门禁通行次数。
OA 对接要先确定主数据来源
若企业 OA 负责入职、调岗、离场和补卡审批，应明确 OA 或人事系统谁是人员主数据源。典型流程为：OA 审批通过后创建人员档案，考勤平台下发权限，设备通过 SDK 回传打卡事件，异常结果再返回 OA。
接口验收需检查重复推送、断网补传、人员编号变更、离职撤权和跨日记录。多品牌兼容必须经过具体设备型号、固件及接口版本测试，不能仅凭“支持 SDK”判断。
九条产品线需要共用身份但分开授权
同一园区可能同时建设门禁、访客、一卡通、水控电控、梯控、停车、消费、考勤、通道闸九条常规产品线。人员身份可以统一，但权限用途应分开：派遣人员获得车间门禁和考勤权限，不代表自动获得停车、消费补贴、宿舍水控或办公楼梯控权限。
自主可控的项目重点，是企业能够掌握人员编码、授权规则、接口文档和历史数据，而非被单一设备数据库锁定。
报价时必须拆开软件、接口与实施边界
报价口径应明确包含哪些考勤模块、设备接入数量、OA 对接接口、历史数据迁移、权限配置、报表开发、现场调试和培训。新增派遣单位、增加自定义报表或接入旧品牌设备是否属于原范围，也应写入清单。
型号参数、授权方式、SDK 条件及服务器环境均以项目资料和厂家当前规格为准。旧设备无法开放接口时，可选择更换终端，或保留旧系统并通过中间库交换汇总数据。
现场核对步骤
- 抽取正式员工与不同派遣单位人员各若干名，核对唯一编号及有效期。
- 分别下发至指定熵基/ZKTeco 终端和闸机，验证非授权区域不能通行。
- 模拟跨夜班、漏打卡、补卡、调岗和退场。
- 使用部门主管、派遣单位、考勤专员账号交叉登录。
- 检查页面、导出文件、接口返回值是否均执行数据隔离。
- 断开网络后补传记录，确认无重复、丢失或人员串档。
风险、适用边界与替代方案
主要风险包括把门禁记录当工时、共享管理员账号、派遣人员退场后权限未撤销，以及报表隔离但接口未隔离。对于仅有少量临时人员、无需排班结算的现场，可采用访客或临时通行授权；但只要涉及持续考勤、补卡审批和工时确认，就应建立独立人员类型及权限模型。
若原平台不支持行级数据范围，可按派遣单位建立独立子组织；仍无法隔离时，应采用中间报表平台脱敏输出，而不是开放完整后台。
交付验收清单
- 人员类型、派遣单位、实际部门及有效期可查询；
- 设备、平台、OA 三方人员编号一致；
- 各角色仅能查看约定组织与字段；
- 转正、调岗、离场后权限按流程变化；
- 原始打卡、修正记录和审批结果可追溯；
- 导出、接口及日志执行同一权限规则；
- 设备型号参数、SDK 版本和售后责任形成交付文档。
FAQ
派遣人员可以与正式员工使用同一台考勤机吗？
可以。前提是平台按人员类型和组织隔离数据，设备容量、识别方式及下发规则满足现场要求。
派遣单位能否直接登录企业考勤后台？
可以设置受限账号，但只开放其所属人员及约定字段；若平台无法精细授权，建议定期推送审核后的汇总表。
人脸考勤终端更换品牌后历史记录会消失吗？
历史记录应保存在平台或数据库中。更换前需核对人员编号、事件格式、SDK 接口和数据迁移方案，实现多品牌兼容需以联调结果为准。
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。