绩效

升级内容 1：绩效结果员工侧增加时效性控制

业务场景&问题：

● 员工本人查看历史绩效结果时，过久的结果长期暴露会带来信息留存风险。

● 现有展示口径需要按入口做时效控制，但不删除或修改绩效结果数据本身。

解决方案：

● 在员工本人查看历史绩效结果的两个入口增加时效判断：绩效待办中的历史绩效结果、右上角头像进入个人资料后的绩效结果。

● 当绩效活动归档时间超过 2 个自然月后，该活动下员工本人可见的绩效结果不再展示。

● 花名册/员工档案、团队档案、报表、导出、审批记录、操作记录等入口保持原有展示规则，不受本次控制。

升级内容 2：OpenAPI增加工作总结接口

业务场景&问题：

● 第三方系统需要直接读取员工已提交的绩效工作总结，用于周报、月报等分析。

● 原有能力不足时，外部系统需要额外解析页面或模板，接入成本较高。

解决方案：

● 新增绩效工作总结读取开放接口，支持按员工、活动、总结周期和分页查询已提交工作总结。

● 接口返回总结正文、目标进展摘要、提醒查看人、可见范围信息，图片和附件通过独立下载链接返回。

● 不新增写入、修改、删除或推送能力，仅补充读取能力。

升级内容 3：绩效最终评分支持评估周期日期折算

业务场景&问题：

● 中途入职员工在绩效最终评分中需要按在职天数折算，否则容易高估或低估实际得分。

● 原有最终评分公式无法直接引用绩效活动的评估周期日期，配置折算公式不够顺手。

解决方案：

● 在最终评分自定义公式中新增活动级日期字段：绩效评估开始日期、绩效评估截止日期。

● 复用现有 Days() 函数，支持按周期总天数和员工在职天数计算折算系数。

● 当活动缺少评估开始日期、评估截止日期或员工入职日期时，系统阻断计算并提示补齐信息。

人事Eva&BPEva

升级内容 1：支持一个应用多个人使用Eva

业务场景&问题：

● 当前一个应用仅能支持一个用户使用，多个人使用需要创建多个应用，安装配置过程麻烦，无法大规模推广使用。

解决方案：

1. 新增网关层，支持企业只创建一个应用，为所需使用的人员增加可见范围，其余创建开通流程不变，绑定人员后用户即可共用这一个应用对话自己的Eva。

2. 人事Eva和BPEva需分别创建应用。

假勤

升级内容 1：支持多时区考勤

业务场景&问题：

● 当前假勤系统大量时间口径默认按北京时间或GMT+8处理。随着企业存在跨国家、跨地区办公、外派、海外出差、远程办公等场景，员工实际打卡所在地、设备时区、企业考勤管理口径可能不一致。

解决方案：

1. 新增租户级多时区开关

2. 开启后：

1. 员工信息设置-个人信息-基本信息中增加「所在时区」字段

2. 员工个人信息中的所在时区仅影响员工本人页面的当前时间展示、相对日期、日期默认值，不参与考勤核算

3. 可在个人功能权限中设置修改是否需要审核

4. 考勤组增加「考勤时区」字段，字段类型为单选。

1. 「考勤时区」为必填字段；默认填充北京/上海（UTC+08:00）

2. 考勤组考勤时区变更后，仅影响后续未生成日期的员工每日考勤时区。需手动核算历史出勤日报才变更历史日期的考勤时区

3. 部分时区存在冬令时和夏令时之分，考勤时区上会汇总展示，但具体到每一天会有具体的UTC偏移量记录

3. 出勤日报、打卡记录展示时区信息

2. 我的出勤中增加考勤时区字段，若我的出勤中启用了考勤时区字段，则员工在我的出勤中可见当天的考勤时区

2. 员工打卡页面增加展示时区信息

2.

2. 若员工当前设备所在时区和考勤时区不一致时，增加提示和打卡的二次确认提醒

2. 将以考勤时区进行记录和卡片核算

2.

2. 打卡完成后，会展示对应打卡记录的打卡所在时区

2. 出勤日报右上角增加【考勤时区设置】，支持批量修正员工历史的考勤时区

2. 点击后右侧抽屉内展示历史变更记录，且有添加按钮

2. 点击添加后可添加变更考勤时区

2. 手动为员工变更考勤时区后，员工不会随考勤组设置中的考勤时区的变更而自动调整

2. 变更员工历史日期的考勤时区后，出勤数据不会自动计算，若需要立即核对考勤数据，需在「出勤日报」进行「重新核算」。且参与当前考勤核算的打卡记录对应的考勤时区和

2.

2.

3. 多时区考勤

3. 打卡记录保存规则

3. 员工每次打卡时，系统保存打卡发生的标准时间。再根据员工和考勤日期读取当日考勤时区表，根据时区+标准时间回算员工考勤时区的打卡时间，用于页面展示和考勤核算。

3. 考勤日期以员工打卡时的考勤时区计算的当地打卡时间对应的日期为准

3. 例如员工打卡时，当前系统标准时间（UTC+00:00）为9月1日23:00，且当前员工所在考勤组时区为北京/上海（UTC+8:00），此时按照该时区的时间为9月2日07:00，该打卡记录将被记录为9月2日07:00

3. 三方平台和 API 写入的打卡时间按东八区理解，再按每日考勤时区转换为页面展示时间和核算时间。

3. 示例

3.

3. 考勤核算

3. 同一个员工同一个考勤日只能存在一个考勤时区。

3. 即员工上午设备在 UTC+04:00 地区打卡、晚上设备切换到 UTC+08:00 地区，系统仍以当日每个考勤日期的考勤时区统一展示和核算。

3. 示例：员工打卡时，员工的考勤时区（UTC+04:00），在当地时间 2026-07-13 09:01 移动端打卡。

3.

3. 假勤事件的时间处理

3. 用户在提交请假、出差、外出、加班审批或添加的页面填写的开始日期、结束日期、开始时间、结束时间，就是后续保存、展示和核算使用的业务时间。系统不因员工考勤时区、操作人时区、设备时区不同，对申请时间做自动时区转换。

3. 补卡记录增加原补卡时区字段，记录员工在提交补卡申请时对应的考勤时区

3. 若后续变更了当前的考勤时区，原补卡时区不变化

3.

3. 在提交请假、出差、外出、加班、补卡审批时，若限制了申请时间、撤销时间或修改时间限制，则以员工当前考勤组所在时区定义“今天”

3. 例如员工申请年假，规则配置为：在休假开始日期前1天提交

3. 员工提交请假时，考勤组时区为北京/上海（UTC+08:00），且按照该时区，当前时间为9月2日06:00，员工可提交9月3号及之后的请假申请

3. 若变更员工考勤组时区为巴黎（UTC+01:00）,按照该时区，当前时间为9月1日23:00，此时员工可提交9月2日及之后的请假申请

升级内容 2：支持节假日管理

业务场景&问题：

● 部分海外员工需要按照当地的法定节假日进行考勤管理，或是部分客户存在公司内部的工作日管理，当前不支持设置节假日模板，当考勤组较多时配置较复杂

解决方案：

1. 新增节假日管理

   1. 功能权限中增加【节假日管理】功能点，有权限的用户可在假勤设置中查看和编辑节假日规则

   2. 

   3. 系统预置了2026年的中国大陆法定节假日、新加坡法定节假日、马来西亚法定节假日、中国香港法定节假日删

      1. 预置模板也支持用户编辑

      2. 当存在关联的考勤组时，规则不可停用

      3. 

   4. 支持添加节假日模板

      1. 支持选择多个日期并变更为工作日、公休日或节假日

      2. 变更后将展示变更记录

      3. 

      4. 

2. 新增节假日规则后，可在考勤组中进行引用

   1. 

   2. 关联后也可针对该考勤组单独调整工作日历

      1. 在考勤组中调整后不影响节假日规则

薪酬

升级内容 1：员工薪酬核算规则查询接口返回参数增加核算规则id

业务场景&问题：

● 客户存在外部系统需要关联薪酬核算活动的核算规则ID进行匹配，当前该查询接口暂未返回规则ID

解决方案：

员工薪酬核算规则查询接口返回的核算活动关联的核算规则id

升级内容 2：26年8月个税算税接口更新：算税和申报增加公积金上限校验

【将影响住房公积金项目超出当地公积金上限的核算活动的个税申报和计算】

官方个税接口更新时间：08-28晚

Moka系统适配上线时间：09-02晚灰度，09-03晚全量（旗舰版跟随全量时间上线）

升级内容

● 税友调整内容

● 住房公积金计算&申报逻辑调整

○ 升级后，所有地区住房公积金项目增加强校验，算税和申报数据中的「住房公积金」字段不能超过当地公积金上限，否则会导致算税或申报失败。

○ 超出上限的部分需填入「住房公积金调整」项目

● 【薪酬核算规则-更多设置-正常工资薪金所得】中增加「住房公积金调整」项目

○

○ 住房公积金调整项目的金额会被累计到「累计其他扣除合计」

● 工资表结构中增加「公积金上限」「累计其他扣除合计」，用于客户参考员工所在报税主体的公积金上限，不直接参与个税的计算

○ 分组属于「个税累计信息」，当核算规则为接口算税时，该字段的取值方式为接口获取

○

○ 实际验证中发现「住房公积金调整」也存在上限限制，暂无接口可获取住房公积金调整的上限

○

权限

升级内容 1：任职关系角色支持停用

业务场景&问题：

● 自动化流程中，开通了“自动创建任职关系角色”的租户，在系统角色中会出现任职信息中的人员类型角色。但不是所有的人员类型字段都需要赋予角色，需要用户手动停用部分角色

解决方案：

1. 系统角色操作列增加停用按钮
   

   1. 仅任职关系角色支持停用，其他角色的停用不可停用

   2. 

2. 点击停用后出现二次确认弹窗

   1. 

3. 后续新开通自动化流程的租户，创建角色时不创建直接上级

人事

升级内容 1：修改异动记录支持不联动更新后续字段

业务场景&问题：

● 修改历史异动记录时，部分字段原本会继续同步到后续异动记录。

● 当用户只想修正当前记录的历史事实时，联动更新可能改变后续已经确认的数据。

解决方案：

1. 保存时增加“修改范围”

● 在保存历史异动记录时增加确认弹窗，“修改范围”为必选项。

● 默认选中“更新后续异动记录未变更的字段”，保持原有操作习惯。

2. 支持仅修改当前记录

● 选择“仅更新当前异动记录”时，只保存当前异动记录，不更新后续异动记录的数据。

● 后续异动记录中的变更明细也不会被本次操作改写。

升级内容 2：增加海外证件类型

业务场景&问题：

● 海外员工通常使用护照或其他境外证件，原有证件类型选项无法覆盖实际用证场景。

● 证件类型不完整会影响入职资料采集、员工档案维护、批量导入及上下游系统同步。

解决方案：

1. 证件类型增加海外常用选项

● 证件类型新增 “社会保障号码” 选项。

● 具体选项以租户当前版本的证件类型字典为准；已有“居民身份证”等国内证件选项继续保留。

2. 覆盖员工与入职场景

● 员工档案、待入职信息和入职确认页面均可选择新增证件类型。

● 批量导入、信息采集和 OpenAPI 写入沿用同一证件类型字典，避免页面与接口口径不一致。

3. 保持证件号码数据规则

● 证件类型只决定可选证件名称，不改变员工证件号码的展示和存储方式。

● 原有证件号必填、唯一性校验及权限控制继续按租户配置执行；历史员工证件类型不会被自动修改。

组织

升级内容 1：更新部门接口支持清空字段值

业务场景&问题：

● 企业通过 OpenAPI 同步组织架构时，需要清除已废弃的部门负责人、HRBP 或自定义字段。

● 原接口把空字符串或null统一按“无变化”处理，调用方无法表达“清空字段”。

解决方案：

1. 新增空值处理参数

接口：POST /oapi/v1/org/department/batchUpdate

请求体新增以下参数

2. 兼容原有接口行为

● 未传emptyCellHandleMode或传1时，空值仍代表无变化。

● 传2时，仅清空非必填字段；必填字段不会被清空，按接口校验规则处理。

● 参数只对当前请求生效，不影响其他调用方。

电子签

升级内容 1：签署中心新增列和筛选

业务场景&问题：

● 签署中心按文件展示时，HR 难以判断多份文件是否属于同一签署流程。

● 文件数量较多时，仅依靠文件名和状态查找目标记录效率较低。

解决方案：

新增以下字段

● 「离职日期、离职类型、离职审批状态、离职办理状态」只对在职员工生效

● 「部门全路径、合同开始日期」对待入职、在职员工都生效

● 「合同开始日期」为签署文件关联的合同开始日期

入职

升级内容 1：在入职页面隐藏本年生日日期字段

业务场景&问题：

● “本年生日日期”属于系统根据生日信息计算的结果，并非入职办理时需要填写的原始资料。

● 在入职页面展示该字段，容易让 HR 或员工误以为需要手工维护。

解决方案：

1. 入职页面隐藏计算字段

● 入职信息采集和确认页面不再展示“本年生日日期”字段。

● 原始生日字段及其他入职字段的填写、校验和保存规则不变。

2. 不影响已有数据使用

● 仅调整页面展示，不清空员工已有的生日日期数据。

● 员工关怀生日提醒等依赖生日信息的功能不受影响。

升级内容 2：待入职接口增加“招聘信息”

业务场景&问题：

● 外部系统在获取待入职员工时，还需要知道其招聘来源或关联招聘记录。

● 原待入职接口字段不足，客户需要再调用招聘相关接口或人工补录，增加对接成本。

解决方案：

1. 待入职查询接口增加招聘信息分组

● 在现有待入职员工数据查询接口中增加“招聘信息”字段分组。

● 字段按 OpenAPI 字段配置返回；未勾选或无权限时不返回，保持现有字段配置机制。

● 本次升级不改变待入职员工的招聘数据，仅补充对外读取能力。

2. 招聘信息子字段待以接口文档为准

● 当前仅从 Jira 标题确认“招聘信息”分组，无法在未登录状态下核对具体子字段名称、类型和枚举值。