人事
升级内容 1:合同换签支持联动变更发薪组织与参保方案
业务场景&问题:
在合同变更审批中,适用范围信息(如法人公司)发生变更,无法联动变更发薪组织和参保方案
解决方案:
发薪组织自动变更
发薪组织设置页面,新增「自动变更规则」,点击弹出弹窗:
开关:自动变更发薪组织
默认关闭
变更逻辑:开关开启后,如果员工适用范围信息变化,则修改员工的「生效中」、「未来生效」的薪资档案的发薪组织。该变更会展示在变更记录中。另外,薪酬这边每日凌晨3点会通过定时任务刷新发薪组织,因此如果需要手动修改发薪组织,建议将此开关关闭。
举例:发薪组织的适用范围配置了法人公司,如果合同变更审批中,变更了法人公司,合同开始日期 = 10.30。则到达10.30,法人公司信息变更后,会立刻根据新的适用范围联动变更发薪组织。
「变更合同」审批接入参保信息分组
是否变更社保方案 | 默认填充为“否”。下方不展示内容
|
社保起缴月份 | 可选择具体的月份,默认赋值为「合同开始日期」的月份 审批通过后,将根据生效月份变更社保方案 |
社保缴纳地 | 默认填充为该员工的原社保缴纳地 若修改了社保缴纳地,会联动变更调整后-社保方案的下拉列表,展示当前社保缴纳地的社保方案 |
调整前-社保方案 | |
调整后-社保方案 | |
社保基数 | 默认填充为员工当前的社保基数,可编辑
|
是否变更公积金方案 |
|
公积金起缴月份 | 可选择具体的月份,默认赋值为「合同开始日期」 审批通过后,根据生效月份变更公积金方案 |
公积金缴存地 | 默认填充为该员工的原公积金缴存地 若修改了公积金缴存地,则需联动变更调整后公积金方案的下拉列表,展示当前公积金缴存地的公积金方案 |
调整前-公积金方案 | |
调整后-公积金方案 | |
公积金基数 | 默认填充为员工当前的公积金基数,可编辑
|
审批落地:根据社保起缴月份为社保方案添加「调出」「增员」记录,如果起缴月份当月的记录为调出,则只添加「增员」记录。公积金同理
升级内容 2:更新教育经历能同步更新个人概况(联系csm开通白名单)
业务场景&问题:
当前在花名册中编辑「教育经历」后,「个人信息」中的「最高学历」「毕业学校」等字段不会联动更新,导致 HR 需要再手动更新
解决方案:



在系统中更新员工的【履历信息 - 教育经历】时,同步更新【个人信息 - 个人概况】中以下几个字段,会在字段设置中提醒
最高学历
最高学位
毕业院校
所学专业
更新逻辑:
教育经历有多段,取多段中「学历」最高的一段,取该段中的各字段的值填入【个人概况】中
「学历」最高的逻辑:与花名册中「最高学历」Tag 的逻辑一致
若最高「学历」的教育经历有多段,则其中「开始日期」最晚的一段;若「开始日期」最晚的还有多段,则再取其中添加时间最晚的一段
若删除所有教育经历,也会同步将【个人概况】中上述 4 个字段置为空
由于【教育经历】和【个人概况】字段的必填可能设置得不一样,当联动更新时,【教育经历】中某个字段为空但【个人概况】中该字段必填,不要报错,依旧能正常将【个人概况】中该字段置为空
更新时机:由于更新员工信息有多个入口,以下入口均需支持:
花名册:
在花名册通过界面修改
导入:【设置 - 任务中心 - 导入平台 - 履历信息导入】
审批:【个人信息修改】、【自定义流程】
OpenAPI:添加/更新履历
移动端通过界面修改个人资料:
信息健康度
入职:
由于入职有多个入口(8 个入口),且没法统一收敛,故入职统一为在操作「确认入职」时触发联动更新
薪酬
升级内容 1:薪酬核算活动增加功能权限控制
业务场景&问题:
薪酬核算功能仅支持配置编辑和查看权限,无法按具体功能分别控制,导致配置时权限过大,目前有些敏感的功能需要单独控制,例如:调整结果、导出的权限
解决方案:
在【设置-账号权限-角色管理】薪酬核算的权限控制中增加了调整结果和导出相关的权限控制

功能权限与薪酬核算活动的功能点对应关系如下:
权限点 | 对应功能 |
算薪数据合并导出:之前有薪酬核算活动查看权限的用户默认开启 |
|
调整结果:之前有薪酬核算活动编辑权限的用户默认开启,没有的不开启页面上也不展示该权限 |
|
导出薪资计算 :之前有薪酬核算活动查看权限的用户默认开启 |
|
导出发薪明细 :之前有薪酬核算活动查看权限的用户默认开启 |
|
升级内容 2:数据填报导入模板同步表单数据
业务场景&问题:
数据填报场景,填报人要完成自己的填报任务,可在线填写相关项目字段,数据量大时需要用到excel导入功能。
导入时需要先下载模板,如果之前没有点击右上角“暂存”按钮,下载的模板中无人员姓名、工号等基础数据,需要手动填充,用户体验差,多个用户吐槽。

解决方案:
点击右上角“导入”时,自动触发暂存功能,即用户后续下载的模板数据均与线上表单保持一致。
假勤
升级内容 1:支持结合班次弹性请假/外出/出差
业务场景&问题:
场景1:班次设置了有弹性的情况下,若员工已有打卡触发弹性考勤,应出勤时间会对应变更,但请假时没有结合弹性后的应出勤时间计算请假时长,导致考勤结算会有异常
场景2:员工已请假,此时已触发的弹性考勤,但再次请假时不会按班次弹性后的应出勤时间记录请假时间和请假时长
场景3:连续请假时,第1天的请假结束时间和最后1天的请假开始时间不是员工选的,目前默认会按是否触发弹性记录具体的请假时间,但实际客户业务场景存在希望按班次上班时间或按弹性最大时间记录,现在不支持配置
以上场景出差外出有相同的情况
解决方案:
班次管理中增加「出勤情况记录」的配置,位置在弹性考勤规则后
老客户默认均保持现在线上的系统默认逻辑:按天请假时请假时间按班次上下班时间记录,按小时请假时根据当前提交的请假记录及班次弹性规则综合计算
若客户希望单独配置,可根据业务场景进行【自定义配置】
注意:自由工时班次不支持配置

请假、出差、外出均可分别自定义配置,以下以请假为例进行说明,出差和外出同理
配置一:按天请假时,请假开始时间及结束时间按什么时间记录:
选项1:班次上下班时间(班次管理配置的上下班时间,多段班次为第1段的上班时间~最后1段的下班时间):默认选中该选项
info说明:每天实际请假的时间会按班次设置的上下班时间记录,多段班次为第1段的上班时间~最后1段的下班时间,若为半天请假则按班次设置的半天时间记录;例如:班次时间为09:00-18:00,晚走60分钟内,晚到相应时间,半天设置时间为14:00,申请9月20日下午-9月21日下午,则9月20日实际记录的请假时间为14:00-18:00,9月21日实际记录的请假时间为09:00-18:00,请假时长为1.5天
选项2:应出勤时间(为当天的应出勤最早时间到应出勤最晚时间,会结合晚走补偿、特殊考勤,已有的打卡记录,已通过及审批中的请假记录,综合计算的实际应出勤时间进行记录):
info说明:请假提交时,会结合员工每天的晚走补偿、特殊考勤设置、已有的打卡记录,已通过、审批中、及当前表单中的请假记录,综合计算的应出勤时间进行记录,若为半天请假则按半天时间记录;例如:班次时间为09:00-18:00,晚走60分钟内,晚到相应时间,半天设置时间为14:00,员工9月20日已打卡09:10,申请9月20日下午-9月21日下午,则9月20日实际记录的请假时间为14:00-18:10,9月21日实际记录的请假时间为09:00-18:00,请假时长为1.5天
选项3:最大弹性上下班时间(按班次弹性的最大时间范围记录,仅班次开通了任意弹性考勤规则时才可选)
info说明:每天的实际请假时间会按班次设置的最大弹性上下班时间记录,多段班次为第1段的上班时间~最后1段的下班时间,若为半天请假则按班次设置的半天时间记录;例如:班次时间为09:00-18:00,晚走60分钟内,晚到相应时间,半天设置时间为14:00,申请9月20日下午-9月21日下午,则9月20日实际记录的请假时间为14:00-19:00,9月21日实际记录的请假时间为09:00-19:00,请假时长为1.5天
case举例:
班次设置:09:00-18:30,休息时间是12:00-13:30半天时间13:30,晚到30分钟内晚走固定30分钟
员工9月24日提交:9月24日下午到9月26日上午的请假
若配置「班次上下班时间」
9月24日请假记录拆分的具体时刻为:13:30-18:30,请假时长0.5天
9月25日请假记录拆分的具体时刻为 9:00-18:30 ,请假时长1天
9月26日请假记录拆分后的具体时刻为:9:00-13:30,请假时长0.5天
若配置「应出勤时间」
9月24日的结束时间:
若员工9月24日已经打卡9:10,则请假拆分的具体时刻为:13:30-19:00,请假时长0.5天 请假小时数5.5小时
若9月24日没有打卡或者打卡时间早于9:00,则请假拆分的具体时刻记录为13:30-18:30,请假时长0.5天,请假小时数5小时
引发情况:若一开始未打卡,后续打卡或补卡了9:10,考勤会异常,需重新核算请假记录
补充case:员工请假9月24日上午:
若员工9月24日已经打卡9:10,则请假拆分的具体时刻为:09:00-13:30,请假时长0.5天,请假小时数5.5小时
若9月24日没有打卡或者打卡时间早于9:00,则请假拆分的具体时刻记录为9:00-13:30,请假时长0.5天,4.5小时
9月25日请假具体时刻为 9:00-18:30 ,请假时长1天
9月26日请假具体时刻为:9:00-13:30,请假时长0.5天
若配置「最大弹性上下班时间」
9月24日请假记录的拆分的具体时刻为:13:30-19:00,请假时长0.5天
若请假按天请,但扣除按小时扣除,则请假小时数5.5小时,请假若按小时扣假期账户额度时,扣除为5.5小时
若同一天分开请假上下午半天时,请假小时数不可超过班次时长,需要结合一请假的记录,扣除第二次的请假时长,若第一条请假记录撤销,第二条记录需要重新核算;
9月25日请假请假记录的拆分具体时刻为 9:00-19:00 ,请假时长1天,请假小时数8小时
9月26日请假记录的拆分的具体时刻为:9:00-13:30,请假时长0.5天,请假小时数3.5数
配置二:按小时/分钟提交连续多天的请假时,首日的请假结束时间、最后1天的开始时间及中间日期的时间按什么时间记录
选项1:班次上下班时间(班次管理配置的上下班时间,多段班次为第1段的上班时间~最后1段的下班时间):
info说明:员工没有明确选择时间时,每天的实际请假时间会按班次设置的上下班时间记录,多段班次为第1段的上班时间~最后1段的下班时间;例如:班次时间为09:00-18:00,12:00-13:00休息,晚到60分钟内,晚走相应时间,申请9月20日15:00-9月22日15:00,则9月20日实际记录的请假时间为15:00-18:00,请假时长3小时,9月21日实际记录的请假时间为09:00-18:00,请假时长8小时,9月22日实际记录的请假时间为09:00-15:00,请假时长5小时,总请假时长为16小时
选项2:应出勤时间(为当天的应出勤最早时间到应出勤最晚时间,会结合晚走补偿、特殊考勤,已有的打卡记录,已通过及审批中的请假记录,综合计算的实际应出勤时间进行记录):默认选中该选项
info说明:请假提交时,员工没有明确选择时间时,会结合员工每天的晚走补偿、特殊考勤设置、已有的打卡记录,已通过、审批中、及当前表单中的请假记录,综合计算的应出勤时间进行记录;例如:班次时间为09:00-18:00,12:00-13:00休息,晚到60分钟内,晚走相应时间,员工09月20日已有09:30的打卡,申请9月20日15:00-9月22日15:00,则9月20日实际记录的请假时间为15:00-18:30,请假时长3.5小时,9月21日实际记录的请假时间为09:00-18:00,请假时长8小时,9月22日实际记录的请假时间为09:00-15:00,请假时长5小时,总请假时长为16.5小时
选项3:最大弹性上下班时间(按班次弹性的最大时间范围记录,仅班次开通了任意弹性考勤规则时才可选)
info说明:员工没有明确选择时间时,每天的实际请假时间会按班次设置的上下班时间记录,多段班次为第1段的上班时间~最后1段的下班时间;例如:班次时间为09:00-18:00,12:00-13:00休息,晚到60分钟内,晚走相应时间,申请9月20日15:00-9月22日15:00,则9月20日实际记录的请假时间为15:00-19:00,请假时长4小时,9月21日实际记录的请假时间为09:00-19:00,请假时长8小时,9月22日实际记录的请假时间为09:00-15:00,请假时长5小时,总请假时长为17小时
case举例:
班次设置:09:00-18:30,半天时间13:30,晚到30分钟内晚走固定30分钟
员工9月24日提交:9月24日13:30-9月26日18:30的请假
若配置「应出勤时间」
9月24日的结束时间:
若员工9月24日已经打卡9:10,则请假时间为:13:30-19:00 5.5小时
若9月24日没有打卡或者打卡时间早于9:00,则请假时间记录为13:30-18:30 5小时
引发情况:若一开始未打卡,后续打卡或补卡了9:30,考勤异常,需重新核算请假记录
补充case:员工请假9月24日9:00-13:30:
若员工9月24日已经打卡9:10,则请假拆分的具体时刻为:09:00-13:30,请假时长0.5天,请假小时数5.5小时
若9月24日没有打卡或者打卡时间早于9:00,则请假拆分的具体时刻记录为9:00-13:30,请假时长0.5天,4.5小时
9月25日开始到结束时间 9:00-18:30 8小时 请假时长
若9月25日打卡9:10,后去重新核算请假记录,请假拆分记录为会变更:09:10-19:00
9月26日的开始时间 9:00-18:30
应出勤时间的影响范围,班次早到早走,班次上班卡缺卡的情况
若配置「最大弹性上下班时间」
不论员工是否已打卡,9月24日的结束时间 19:00 13:00-19点的时长
9月25日开始到结束时间 9:00-19:00 请假时长8小时
9月26日的开始时间 9:00-18:30的时长
其他相关影响:
请假记录对应的每天的拆分时间会按配置的时间记录:
填写请假申请时,请假时长需按班次时间拆分的记录进行计算
按天请假时,请假时长依然计算为0.5天的倍数统计,但实际的请假时间需按班次时间记录,考勤核算按请假的实际拆分时间进行计算
按小时、分钟请假时,需按实际拆分的请假时间计算请假时长,若请假时长不符合单位时长需对应报错
注意:
连续请假时,若每天的班次的请假记录规则不同时,需分别按每天的班次的规则进行拆分
例如:请假9月1日上午-9月2日下午,两天班次时间一样均9-18点,且晚到晚走60分钟,但请假记录规则配置不同,第一天请假按班次时间记录时则记录为9-18点,第2天按弹性最大时间时则为9-19点
请假一旦提交(审批中或审批通过),请假记录已完成拆分,有其他出勤情况下(如打卡触发弹性变更了应出勤时间),请假的拆分记录、请假时长等均不会自动变更,若希望变更,需要重新核算请假记录
班次规则中请假记录规则的变更了,需要重新核算
重新核算请假记录时,需要按班次上配置的最新的规则,以及重新核算时员工的实际应出勤时间重新计算请假时长及重新拆分请假记录
出差、外出的时间记录若进行的自定义配置,则会按配置的时间进行记录,但出差和外出不支持重新核算,若调整了规则已产生的出差外出希望按最新的规则计算需要撤销后重新提交
IM
升级内容 1:支持1个租户对接多个飞书组织
业务场景&问题:
当前 People 只能集成一个飞书,对于多飞书的客户来说,无法使用
使用场景
同一个客户同时在使用多套飞书,但需要用一个 Moka People 租户进行人力资源管理,故需要一个 Moka People 集成多个飞书租户。
使用该功能,可以实现将不同的部门、员工与不同的飞书租户进行对接、同步。
系统路径
设置 - 服务对接 - IM 对接
注意
2023-09-01 后创建的租户,可以直接对接多个飞书
2023-09-01 前创建的老租户,请与客户经理或实施同学确认,是否可以对接多个飞书
使用教程
1、【CSM 后台安装】People 租户集成 IM
请与实施同学确认,提供飞书组织相应信息,实施同学将在后台中将 Moka People 租户与飞书组织进行绑定安装
2、【People 后台】初始化设置每个 IM 的同步范围
如下图,当在 CSM 后台绑定好 IM 后,则可进入 People 后台,初始化设置每个 IM 部门&员工的同步范围

初始化设置与当前相同,设置哪些部门、员工(含字段映射)需同步至该 IM,需要注意:
部门:同步子部门需先同步父部门(即往上一条链路上的父部门),但同步父部门无需同步下面全部子部门
员工:同步员工需先同步其所在的部门
每个IM需独立进行初始化,但同一个部门、员工均可同步至多个 IM。同步至多个 IM 后,该部门或员工会同时出现在多个 IM 中,消息通知待办等在多个 IM 中均会收到

字段映射的初始化时,每个 IM 需配置每个IM的对应的字段映射规则

员工初始化逻辑:
前提条件:同步员工至某个 IM,需先同步员工所在的部门至该 IM,页面有相应提示
可以只绑定不同步,但同步必须得先绑定
支持同一个员工绑定/同步至多个 IM
字段映射:根据字段映射配置,同步时更新 IM 中对应的字段值
后续消费:审批、IM 通知消息、IM 待办、假勤相关数据的同步均依赖员工绑定关系
员工绑定范围的可选项:
全体员工
与同步范围相同:默认选中此项
不绑定:当选择此项时,同步范围仅能选中「不同步」
当选择「与同步范围相同」时,圈选条件同理,仅影响初始化圈圈和新入职员工,初始化后存量员工不再受适用范围影响,管理员可以手动更改绑定、同步状态
注意:绑定范围需大于等于同步范围,目前技术已做相关限制
员工同步范围的可选项:
全体员工:当选择此项时,绑定范围仅能选中「全体员工」或「与同步范围相同」;默认选中此项
指定员工范围:当选择此项时,需配置「适用范围」,适用范围按员工最新的任职信息进行圈选
选择适用范围后,需要回显满足条件的人数,可以点击查看
不同步
注意:
设定范围后,完成初始化后依旧可以在IM对接中对应的飞书IM上修改设置
无论选择什么范围,规则仅影响初始化首次圈选员工、新入职的员工,不影响完成初始化后已有员工的绑定、同步状态
若初始化后由于员工异动、或组织架构调整、或者调整了绑定、同步范围,导致:已同步的员工不再满足适用范围、或者未同步的员工重新满足适用范围,均不会自动触发取消同步 / 新增同步,绑定同理
3、【People 后台】查看/修改每个 IM 同步的部门&员工
如下图:初始化设置完毕后,可以 by 每个 IM 管理同步其的部门、员工



支持修改IM的根部门

支持重新设置员工同步的【绑定和同步范围】
与初始化相同,需要选择「员工同步范围」和「员工绑定范围」,该两个范围仅会决定新入职的员工是否同步、绑定,修改后不影响已有员工的绑定或同步状态


手动操作取消绑定时,新增支持可选飞书账号是否保留 / 禁用 / 删除

4、【People 后台】字段映射规则位置迁移
如下图:同步员工时,字段映射规则的位置,从左侧菜单中调整至每个 IM 下,可以 by 每个 IM 设置字段映射规则

5、【People 后台】员工异动后账号关停规则
调整后逻辑:「飞书」账号关停规则如下图,新增异动后账号处理规则:
触发条件:员工异动后且更换了部门
是否开通新飞书账号:若异动后的新部门同步至其他飞书、且该员工满足该新飞书的适用范围,则该员工也会默认同步至该新飞书
当前飞书账号是否停用:取决于异动后的新部门是否依旧同步至当前飞书:
若依旧同步,则员工账号不受影响
若不同步,则员工账号会取消同步,但是否删除/禁用/保留账号可配置
默认值:保留飞书账号

举例:以下例子格式:IM(同步的部门,同步的员工)
例 1:飞书 1(产品部,张三),飞书 2(销售部),张三从产品部 → 销售部,且张三满足飞书 2 的适用范围,则异动后的效果:张三开通飞书 2 下的账号,取消同步并禁用/删除/保留飞书 1 下的账号
例 2:飞书 1(产品部、销售部,张三),张三从产品部 → 销售部,则:张三飞书 1 下的账号不受影响
例 3:飞书 1(产品部、销售部,张三),飞书 2(销售部),张三从产品部 → 销售部,且满足飞书 2 的适用范围,则:张三开通并同步飞书 2 下的账号,飞书 1 下的账号不受影响
6、【People 后台】审批、飞书待办、消息、请假外出出差记录同步至 IM
如下图,审批、飞书待办、消息通知、请假外出出差记录同步至 IM 等也是 by 每个 IM 进行设置是否需同步
若多个 IM 均开启了同步,且同一个员工同时在多个 IM 中,则会同时同步至多个 IM,审批或待办等在任意一个 IM 中操作了,所有 IM 中的完成状态均会同步更新

若需要在 IM 中发送消息,则根据【消息和待办通知优先级设置】决定是所有 IM 都通知、还是只通知优先级最高的 IM


7、其他说明
装 People 主应用、打卡应用需要在每个飞书都安装(若需要),流程与当前一样
飞书多维表暂不支持一对多飞书
培训
升级内容 1:绚星(云学堂)支持对接入职培训任务
业务场景&问题:
通过people展示培训计划,闭环用户的培训体验,HR可快速查看员工的培训结果
解决方案:
若客户安装了「绚星云学习平台」培训应用时,且客户开通了「招测培发」,「入职设置-入职任务」中预置对应的入职培训任务
入职培训任务包含:员工试用期间所有的培训子任务
可以对预置的入职任务进行编辑:
任务名称:可修改
任务类别:不可修改,默认为【外部培训】
适用计划:初始化时空,可以修改
触发条件:确认入职:默认该选项,不可修改
负责人:不支持在mokapeople设置,能力以培训平台设置为准
任务详情:不支持在mokapeople设置,能力以培训平台设置为准
分配时间:不支持在mokapeople设置,能力以培训平台设置为准
发送方式:不支持在mokapeople设置,能力以培训平台设置为准
通知选项:不支持在mokapeople设置,能力以培训平台设置为准
到期日:不支持在mokapeople设置,能力以培训平台设置为准
催办:不支持在mokapeople设置,能力以培训平台设置为准

入职人员列表中支持查看对应培训任务的状态
任务列表跟绚星的培训列表保持一致
任务列表下会展示员工试用期已经加入的培训任务:点击任务可以跳转云学堂

入职培训任务状态有:
未分配:Moka自行处理,绚星的入职培训任务和岗位学习地图在Moka还未到分配时间
分配成功:Moka自行处理,外部培训任务已经触发,但培训平台未接收成功,包括未接收、或培训平台接收成功了,但没有成功分配任务的情况
员工对应的培训子任务的状态与绚星上任务状态保持一致,状态分类有:未开始、学习中、已完成、逾期完成
审批
升级内容 1:撤销节点展示问题优化
业务场景&问题:
审批单中途被审批人撤回后,目前逻辑将新增一个末端节点「已中途撤销」以及同时在当前审批人节点展示「已撤销」。导致审批管理员以及相关人查阅时,第一直觉以为是当前审批人进行的撤销
如图:

解决方案:
撤销前的当前审批节点不再展示对应状态icon

绩效
升级内容 1:审核类待办通过时也需校验必填
业务场景&问题:
当前在审核类的待办中(目标审核、360 确认、校准),会默认进只读态,若内容权限中设置了某个字段在该环节必填,也不会校验必填(例如在目标审核时,下属指标的「目标值」由上级制定),导致缺失了必要信息的填写
解决方案:


在完成以下待办时:目标审核、360 确认、校准只读态时(未点击「调整」):
当操作「通过」时也需校验内容权限中设置为「必填」的字段,若字段值为空则报错:
报错后需滚动对应位置
点击报错文案中的「调整」,可直接进入编辑态,并激活对应字段
当操作「驳回」时,无需校验必填
当操作「调整」时,逻辑与线上一样

在列表入口操作批量通过时,若通过的被评估人含有未填写的必填字段,则批量通过时无法通过这些被评估人,并在批量操作的 double check 弹窗中新增提示,如下图红框:
升级内容 2:参与结果计算的环节支持可以跳过
业务场景&问题:
客户会区分多个考核维度,一个是跨部门考核的维度,一个是同部门考核的维度,跨部门的是用的按指标指定评估人;结果计算上,用“以不同评估人的评分加权计算得到结果”,其中按指标评估节点在跨部门维度占比100%
实际业务操作上:存在部分人员的部分月份,其跨部门考核指标无,其权重就为空了,这个时候,希望按实际的权重计算得分(比如跨部门指标权重为0,其他指标各有权重,然后根据实际存在的指标和权重计算得分,跨部门指标(按指标制定评估人)环节为空跳过)
解决方案:

仅评估型环节显示该配置,包括:单人评估、多人评估(by 每个执行角色单独配置)、360 评估、按指标评估
仅当该环节(或者多人评估中的某个执行角色)的执行人配置了某种条件时自动跳过时才显示该配置,否则不显示
自动跳过:包括执行人为空跳过、执行人为本人跳过、环节间执行人重复跳过
仅当当前环节或执行人参与结果计算时(包含该执行人的总评语作为「最终评语」的情况),方触发该配置
选项:
依旧保持跳过:即参与结果计算也会跳过
跳过后结果计算逻辑:
若是以该环节的总评作为绩效结果,则绩效结果为空
若跳过的环节是参与计算的环节之一,则该环节按 0 分计入结果
配置时显示提示:跳过后将不计入结果
不跳过:
若是因为执行人为空或本人的异常,则会在活动中对应的异常列表中显示
若是因为环节间执行人重复,则该环节正常进行
配置时显示提示:若是因为执行人重复,则环节正常进行;若是因为执行人为空或者为本人,则需 HR 在活动中手动处理
活动中的模板是否能修改该配置:
若环节未开启,则可以随时修改
若环节已开启,则不可再修改
【多人评估】
对于多人评估环节环节内跳过的处理:
当前逻辑:
若重复的执行人参与结果计算:
则保留参与结果计算的执行人,跳过不参与结果计算的执行人
若有多个参与结果计算的执行人,则仅保留序号最靠后的执行人,被跳过的执行人权重自动累加至保留的执行人权重中
对于多轨制,该多人评估下某个执行人是否能跳逻辑与之前类同:即该执行人在每个轨都能跳过,方可跳过
保持以上当前逻辑
【结果计算提示】

当参与结果计算的环节配置了「依旧保持跳过」时,在第四步结果计算进行提示
仅当该环节参与结果计算、且在第三步配置为「参与结果计算时依旧保持跳过」方提示
单人的总评作为绩效结果的提示:
需要注意:除去「结果计算」卡片内,「最终评语」也包含
提示文案:{XX环节}{为空时/为本人/与后续评估环节执行人相同}时将自动跳过,跳过后结果将为空
{XX环节}:
若是单人评估、360 评估、按指标评估环节设置为跳过,则显示:{环节名称}
若是多人评估环节的某个评估角色设置为跳过,则显示:{环节名称 - 被跳过评估角色}
多评估人加权计算绩效结果的提示:
需要注意:除去「结果计算」卡片内,「最终评语」也包含
提示文案:{XX环节}{为空时/为本人/与后续评估环节执行人相同}时将自动跳过,跳过后将不计入结果
{XX环节}:
若是单人评估、360 评估、按指标评估环节设置为跳过,则显示:{环节名称}
若是多人评估环节的某个评估角色设置为跳过,则显示:{环节名称 - 被跳过评估角色}
升级内容 3:批量评估指标得分计算优化
业务场景&问题:
批量评估时,指标得分是自动计算的,但需要点一下才会计算出来
解决方案:

若指标得分是根据公式字段计算,进入批量评估页面时即进行计算,无需用户点一次,与详情页一样
升级内容 4:导出单人绩效样式优化
业务场景&问题:
当前导出单人的绩效详情的 Word 用于线下打印,样式有以下问题导致 HR 需要手动调整,效率低下:
1、在换页时,考核表中比较容易有比较大的空行,如下图:

2、展示指标明细时,当前是一个字段占 2 行,导致指标由大量空白,屏效低,如下图:

解决方案:
1、去掉换页时的空行 如下图红框,尽量去掉在换页时的空行:
尝试有效方法 1:生成文档后,在 “查找和替换” 中输入 “pp” 替换为空,批量删除空行
2、提高指标明细字段屏效 在展示指标、O、KR、评估项、价值观的明细字段时:
当前展示样式:每个字段 label + value 各一行,总共展示两行
优化后展示样式: 非多行文本、单行文本字段:label 和 value 在一行展示,多个字段也在一行展示,字段之间间隔 5 个空行,字段多一张展示不下自然换行即可 多行文本、单行文本字段:不与其他字段一行,单独一行展示,label 和 value 在一行展示,label + value 过长一行展示不下自然换行即可
3、优化签字样式 当前签字样式如下图,用边框透明表格,员工左对齐,直接上级右对齐:
优化显示样式如下:用边框透明表格,员工和直接上级均左对齐,列均分;第一行可以空一行,加大行间距
业务场景&问题:
当前导出单人的绩效详情的 Word 用于线下打印,样式有以下问题导致 HR 需要手动调整,效率低下:
1、在换页时,考核表中比较容易有比较大的空行,如下图:

2、展示指标明细时,当前是一个字段占 2 行,导致指标由大量空白,屏效低,如下图:

解决方案:
1、去掉换页时的空行 如下图红框,尽量去掉在换页时的空行:
尝试有效方法 1:生成文档后,在 “查找和替换” 中输入 “pp” 替换为空,批量删除空行
2、提高指标明细字段屏效 在展示指标、O、KR、评估项、价值观的明细字段时:
当前展示样式:每个字段 label + value 各一行,总共展示两行
优化后展示样式: 非多行文本、单行文本字段:label 和 value 在一行展示,多个字段也在一行展示,字段之间间隔 5 个空行,字段多一张展示不下自然换行即可 多行文本、单行文本字段:不与其他字段一行,单独一行展示,label 和 value 在一行展示,label + value 过长一行展示不下自然换行即可
3、优化签字样式 当前签字样式如下图,用边框透明表格,员工左对齐,直接上级右对齐:
优化显示样式如下:用边框透明表格,员工和直接上级均左对齐,列均分;第一行可以空一行,加大行间距
OpenAPI
升级内容 1:拖动调整部门上下级关系支持触发部门变更事件
业务场景&问题:
部分部门变更场景未支持API主动推送
解决方案:
【部门消息推送】
目前支持新增部门、编辑部门、停用部门的消息推送
推送场景如下:
事件 | 场景 |
新增部门 |
|
编辑部门 |
上述变更当前生效版本时触发,历史版本变更无需通知 |
停用部门 |
|
一体化
升级内容 1:离职详细原因不回写人才库(需要联系csm开通白名单)
业务场景&问题:
离职详细原因包含敏感信息,不希望回写到ATS的候选人信息
解决方案:
场景 | 现状 | 优化后 |
候选人信息 | 通过【入职信息设置】,从ATS映射过来的信息可选择变更是否回写,暂不支持明细组 | - |
转正信息同步人才库 | 转正状态和转正日期会同步 | - |
离职信息同步人才库 | 离职日期、离职类型、离职详细原因同步至ATS详细原因 | 离职类型同步ATS,支持离职详细原因是否同步(白名单) |
AI
升级内容 1:AI识人(一期内测+共创客户)
业务场景&问题:
解决业务场景中系统筛选查询条件不足或无法具象系统查询规则的企业内找人(如:想要组建一个AI新团队,哪些人可以胜任?)
解决方案:
上线后需内测一段时间,用于调校提词和AI查询路径优化,暂时不考虑全租户开放。同时,诚邀共创客户参与,大家手上有体验意愿的客户可联系CSM开放该能力
工具使用:
1.描述具体找人相关条件(如:有外企工作经验的员工)

2.等待AI找人结果

3.确认结果











