入职
升级内容 1:入职列表支持展示工号
业务场景&问题:
已入职员工已生成工号,在入职列表中无法看到其工号
解决方案:
入职列表支持展示工号
确认入职后生成了工号、在花名册修改工号,均会自动更新此处的工号

注意:功能上线后,历史已入职员工的工号需要手动从花名册更新


升级内容 2:修改入职日期后,相关字段联动优化
业务场景&问题:
ATS修改入职日期,只会联动修改PP的合同开始日期,不会联动变更合同预计终止日期和试用截止日期
待入职阶段修改入职日期,不会联动变更司龄起算日期
解决方案:
表格中前几列为系统现状,最后一列为本次修改的内容
场景 | 合同开始日期 | 合同预计终止日期 | 试用截止日期 | 司龄起算日期 | 示意图 | 本期修改/新增 |
ATS-offer表单联动 | 入职日期(可修改) | 入职日期+合同期限-1 | 入职日期+试用期月数-1 | 无联动 |
| 合同预计终止日期 = 合同开始日期 + 合同期限 - 1 司龄起算日期 = 入职日期 |
ATS-发起入职表单联动 | 入职日期(可修改) | 合同开始日期+合同期限-1 | 入职日期+试用期月数-1 | 无联动 |
| 司龄起算日期 = 入职日期 |
PP-入职详情页联动 | 入职日期(可修改) | 合同开始日期+合同期限-1 | 入职日期+试用期月数-1 | 无联动 |
| 司龄起算日期 = 入职日期 |
PP-添加待入职审批中的联动 | 入职日期(可修改) | 合同开始日期+合同期限-1 | 入职日期+试用期月数-1 | 无联动 |
| 司龄起算日期 = 入职日期 |
在ATS修改后,PP的联动 | 入职日期 | 无联动 | 无联动 | 无联动 |
| |
在PP修改后,ATS的联动 | 在入职信息设置处开启「变更同步招聘」,则会同步数据 |
| ||||
名称统一
入职详情页,上方的「预计入职」名称统一修改为「入职日期」。

人事
升级内容 1:试用截止日期写入规则优化
业务场景&问题:
试用期转正审批中写入试用截止日期,手动填写的值会被自动计算覆盖,联动逻辑不清晰
提前转正员工,试用截止日期无法根据转正日期自动计算
解决方案:
试用期转正审批:
表单联动逻辑:试用截止日期 = 入职日期 + 试用期月数 - 1
若修改了试用截止日期,则以修改后的为准
花名册导入、待入职导入:
若填写了试用截止日期,则以填写的为准
若未填写试用截止日期
若填写了「转正日期」,则试用截止日期 = 转正日期 - 1
若未填写「转正日期」,则试用截止日期 = 入职日期 + 试用期月数 + 增加月/减少月 - 1
如果手动填写了试用截止日期,审批提交/导入成功 后,会自动计算出试用期月数的 增加/减少 时间,展示在「员工详情页-修正试用截止日期」中,例如:
员工信息:入职日期 = 08-01;试用期月数 = 3个月;试用截止日期 = 10-31
场景:员工提前转正,在审批中填写了转正日期 = 10-30,修改了试用截止日期 = 10-29
结果:审批通过后,员工详情中,试用期月数修正展示为 「减少 2 日」

升级内容 2:重新入职支持不展示历史任职合同
业务场景&问题:
重新入职的员工,历史合同信息会默认继承,希望不展示
解决方案:
新增角色功能权限:查看历史任职合同
路径:人事-合同管理-合同信息-查看历史任职合同
默认勾选,即默认所有角色可查看历史任职合同
影响范围:员工详情页-合同记录的查看、合同管理列表合同记录的查看、合同记录导出
注意:报表中如果希望不展示历史任职合同,需配置数据源筛选条件,筛选出当前任职阶段的合同。
例如:合同协议.合同开始日期 大于等于(字段比较) 员工当前任职信息.入职日期

升级内容 3:项目组工时填报可限制不打卡员工
业务场景&问题:
不打卡的员工填报项目组工时时,无法对其填报内容做限制
解决方案:
项目组人力填报规则
操作路径:【项目组填报-人力填报规则-日工时限制】
日工时限制支持下拉选择以下四种限制
不限制
不可超过指定字段值
可选择出勤日报中,统计频次为「按天统计,按月汇总」的字段
默认选择「实际出勤小时数」
不可超过指定时长
可输入限制时长
必须等于指定时长
可输入限制时长
举例:希望限制日工时填写的所有项目时长总和不得超过班次时长+加班时长-请假时长-外出时长
配置出勤日报自定义字段:不打卡员工应出勤小时数 = 班次时长 + 加班时长 - 请假时长-外出时长
在项目组人力填报规则,设置「日工时限制 = 不可超出「不打卡员工应出勤小时数」」

限制员工的日工时最大值为所选的出勤日报字段的值
如果员工在多个项目组都有工时,则其总和不能超过所选的出勤日报字段的值
如果超出,则报错不允许提交
如果填报日期是未来日期,出勤日报字段没有值,则报错不允许提交
如果所选的出勤日报字段被所有考勤组删除,则报错不允许提交
现状:自定义字段创建后,即使删除了也会一直存在;如果只为部分考勤组创建了自定义字段,所有考勤组的员工都会计算该自定义字段
升级内容 4:合同终止日期与离职日期联动变化
业务场景&问题:
合同终止日期没有联动离职状态和离职日期自动变更
解决方案:
离职记录失效时,合同终止日期需要联动清空
含以下场景:离职审批流程撤销通过、在异动记录中删除离职记录
变更信息会对应显示在操作记录上
离职日期变更时,若合同终止日期等于离职日期,会同步更新合同终止日期
含以下场景:离职办理流程中离职日期更新,审批通过更新离职日期时;任职记录、异动记录中直接修改员工的离职日期、花名册导入更新离职日期、接口更新
变更信息会对应显示在操作记录上
升级内容 5:员工已签署合同附件在移动端和PC端展示统一
业务场景&问题:
员工一页纸和花名册员工详情中,员工的合同附件展示不一致。一页纸中会展示线下签署的文件,而花名册员工详情展示「签署状态 = 已签署」 并且 「签署方式 = 电子签」的文件
解决方案:
展示逻辑:「签署状态 = 已签署」 并且 「签署方式 = 电子签」
分类 | 场景 | 图片 |
一页纸(本次修改) | 移动端-我的-个人资料-合同信息-合同附件 |
|
移动端-团队成员-员工详情-合同信息-合同附件 | 同上 | |
PC端-个人资料-合同信息-合同附件 |
| |
花名册(不变) | 花名册-员工详情-合同信息-合同附件 |
|
花名册-员工详情-签署文件 |
|
薪酬
升级内容 1:调薪导入优化
业务场景&问题:
不同的薪资计划不支持同一个导入模板一起更新
导入前后薪资计划薪资标准项目有差异,新的薪资计划中的新薪资标准项目,如果没有维护值,不会显示;
调薪导入的逻辑不清晰
解决方案:
调薪导入支持选择多个薪资计划,一次性导入
选择薪资计划后对应展示已选薪资计划中启用的薪资标准项目

调薪导入模板的逻辑优化
增加了「调整后的薪资计划」:单选
导入时会校验薪资标准项目的是否适用于选择的薪资计划时,会阻断提示:员工调薪后适用的薪资计划不存在{薪资标准项目,请调整对应薪资标准项目数据或调整薪资计划
模版中未录入薪资计划中存在的薪资标准项目的数据时:
非公式计算的薪资标准项目:根据生效日期获取前一条薪资档案记录,若有相同的薪资标准项目,则数据进行填充,若没有则默认为0
公式计算的薪资标准项目:根据已填写的信息自动计算值
注意事项更新:
1.系统根据工号和姓名进行员工匹配,请确保维护正确数据
2.调薪日期请按照yyyy/mm/dd格式填写,例如:2025/06/01
3.员工已定薪才可导入调薪,若员工存在审批中的调薪记录时无法导入
4.调整后的薪资标准项目数据以填写的数据进行记录,若希望更新为0请填写0;若数据未填写时:若薪资标准项目按公式计算时,会根据表单中已填写的数据自动计算薪资;若薪资标准项目非公式计算时,若员工原薪资计划有该薪资标准项目时则会沿用原薪资数据,若员工原薪资计划没有该字段时则会默认为0;
5.调整后的薪资计划可不填,不填时默认员工的薪资计划沿用原薪资计划

升级内容 2:支持变更历史任职记录的成本中心及成本分摊支持按历史任职成本中心计算
业务场景&问题:
历史任职记录的成本中心不支持导入、变更和查看
成本分摊不支持计算历史任职的成本中心的分摊结果
解决方案:
员工所属成本中心支持导入历史任职记录
导入成本中心时,根据【生效日期】匹配员工的任职记录,生效日期的匹配逻辑:入职日期≤生效日期<下一段入职日期,若为历史任职记录则记录在历史任职记录上
成本中心的生效时间范围不允许跨任职记录,且任职记录的成本中心的失效日期需< 下一段任职记录的入职日期
若生效日期<所有任职记录的入职日期,则无法导入成功,会阻断报错:「yyyy-mm-dd」生效日期不能早于所有任职记录的入职日期「yyyy-mm-dd」
例如:员工第一段任职记录:2024年9月1日入职,员工第2段任职记录:2025年9月1日~
若导入24年12月1日的成本中心记录,则记录在上一段任职记录上
员工详情页的所属成本中心,支持展示历史任职的成本中心,且支持添加、编辑、删除历史任职的成本中心


成本分摊结果的列表中,需支持查询和计算历史任职记录的成本分摊数据
会按当月最后一天员工的任职信息所属的任职记录进行数据计算及展示
注意:若当月离职又再次入职的,则按最新入职信息展示和计算,上一段任职记录的成本分摊则无法计算
在计算时,需要根据员工的当月所属任职记录下的成本中心进行成本分摊的计算,计算逻辑为:
读取当月月初到月末,员工当月对应的任职记录下,所有生效的成本中心,先根据生效时间进行比例计算,再得到对应成本中心的分摊比例
当前分摊周期下,员工有效的在职天数,需要计算多段的任职记录下的每个成本中心生效时间记录综合计算;
例如:员工10月20日离职,11月26日重新入职;10月成本分摊为上一段任职有效的在职天数为:10月1日~20日;11月的有效在职天数为:11月26日~11月30日,5天
员工第1段任职记录的成本中心及分摊比例为:A中心60%,B中心为40%;员工第2段任职记录的成本中心及分摊比例为:B中心50%,C中心为50%;
则分摊比例结果应为:
10月:A中心:10月1日~20日,20天,60%,比例:20/31*0.6=0.387;B中心:10月1日~20日,20天,40%, 20/31*0.4=0.258
11月:B中心:11月26日~30日,5天,50%,比例:5/30 0.5 =0.0833;C中心:11月26日~30日,5天,50%,比例:5/30 0.5 =0.0833
成本分摊导入时,支持员工历史任职记录成本分摊结果的导入

升级内容 3:导入参保月报支持可选参考数据
业务场景&问题:
参保月报-导入更新账单,部分字段是仅用于查看的,就算导入了数据也不更新原数据,但目前无提示说明
解决方案:
参保月报导入时可选择是否下载参考字段

参保月报导入模板增加注意事项说明
注意事项:
1.请勿修改模版内导出的人员基本信息(如:姓名/工号),修改后可能导致数据导入失败;
2.员工不存在的社保险种和公积金项目无法导入
3.部分字段仅用于查看和筛选数据用,包含:法人公司、部门、工作地点、户籍类型、社保缴纳地、公积金缴存地、社保方案、公积金方案、社保基数、公积金基数、社保缴纳方式、公积金缴纳方式、证件类型、证件号码、社保开始日期、公积金开始日期;若需要更新请在员工任职记录或参保方案中修改
4.参保月报导入后若在页面点击重新核算月报,将会以系统设置的数据重新计算参保月报
升级内容 4:参保月报缺少员工的部门、法人公司信息
业务场景&问题:
参保月报统一按参保方案最早的生成时间统一生成,员工的信息数据按最早的方案生成时间获取数据,导致新入职的员工若入职日期晚于方案生成时间时,数据为空
解决方案:
员工按照所属方案生成月报的时间生成员工数据,且按方案生成时间读取员工数据;若员工在方案生成日期还未入职,则按入职日期取数;
例如:参保方案A生成月报时间为5号,参保方案B生成月报的时间为10号,且均设置15号及之前入职的员工当月起缴。则在5号时生成方案A关联的人员的月报数据(以5号读取相关数据),6-15日入职的员工按入职日期取数;10号生成关联方案B的人员数据(以10号读取相关数据),11-15号入职的员工按员工的入职日期取数。
参保方案设置时增加相关说明:

对于入职人员的起缴日期比方案生成日期晚时,增加预警提示:

升级内容 5:薪资项目编辑或增加项目后不覆盖客户原有年度总收入公式计算逻辑
业务场景&问题:
薪资计划中,若用户使用的是系统生成的年度总收入公式,当薪资构成增加薪资项目后,年度总收入公式会自动变更,导致薪酬计算结果不符合预期。
解决方案:
年度总收入公式中增加系统公式、自定义公式两个选项
系统公式为默认选项,且仅支持复制,不可编辑
自定义公式支持复制和编辑,薪资项目变更时不会自动变更

升级内容 6:薪酬核算数据对比调整结果优化
业务场景&问题:
薪酬核算数据对比,选择人员后快速调整差异时,由于调整结构页面存在分页,需要手动向下滑动加载。目前仅支持计算页面加载出来的数据,未加载出来的不会参与计算,导致计算后的结果不符合预期。
解决方案:
点击“快速调整差异”后,页面展示保持现有的分页逻辑
点击确认并计算后,计算时,
页面加载出来的数据以页面编辑的结果为准
页面未加载出来的数据以数据对比页面的数据为准。即当前计算结果=该项目的本期值,调整为=该字段的excel结果,调整原因为:Excel结果覆盖
组织
升级内容 1:人员异动时支持带编异动
业务场景&问题:
人员异动不支持带编异动到新部门,如果异动前后的部门均满编的情况下,需要HR手动先增加调整后部门的计划编制数,异动完成后再减去异动前部门的计划编制数
解决方案:
1、异动审批
异动审批中增加【带编异动】字段
字段默认不启用,如需使用请在审批定义中增加字段
字段仅支持提交时编辑,审批中不允许编辑
字段支持作为审批流程的分支判断条件

提交异动审批时,【带编异动】若选择「否」则保持原逻辑进行校验,若选择「是」时,提交异动审批、审批中、审批通过时不会校验部门的计划编制数,审批通过后会根据员工「异动生效日期」自动变更异动前后对应部门及上级部门的计划编制数,细分维度的计划编制数也会对应变更
若表单中无该字段,则统一按「否」处理
【带编异动】选择「是」时,页面会有相应的提示影响的提示信息
注意:无论编制方案设置的是异动发起时占编或异动审批通过后占编,带编异动选择是时,部门的计划编制数的调整时机均为异动审批通过后且到员工的异动生效日期到了才会变更


【带编异动】记录审批通过后,具体的影响逻辑为:
根据员工异动前后的「部门、职务、工作地点、员工类型、职级」的差异,在异动日期≤当前日期时更新,会更新生效日期对应编制周期及未来的编制周期对应的编制维度的计划编制数;异动前计划编制数-1,异动后的计划编制数+1;即异动生效日期为未来日期时,需要到生效日期后才下调整计划编制数
注意:
根据员工的异动生效日期与编制周期的周期范围进行匹配调整,若异动生效日期内无对应的编制周期,则不会调整;
若调整前部门或调整后的部门未启动编制计划,则对应的部门及上级部门不会调整
若员工不符合「异动日期对应的编制周期中的编制规则中的占编员工范围」,则编制计划数不会调整
异动前后若部门有调整时,调整前后部门的计划编制数:
相同的上级部门无影响
不同的上级部门,调整前的部门计划编制数-1,调整后的部门计划编制数+1
调整前后,不论是否调整了部门,细分维度的计划编制数的变化逻辑如下:
员工异动前的细分维度的计划编制数均-1,员工异动后的细分维度的计划编制数均+1
若异动前后部门无调整时,仅需要根据当前部门的编制计划中启用的编制的细分维度进行调整,即调整前的细分维度的计划编制数-1,调整后的细分维度的计划编制数+1
例如:员工职级从P6调整为P7,部门未调整,则部门的计划编制数无需变化,仅细分维度中P6的计划编制数-1,P7的计划编制数+1
部门中的编制周期存在周期拆解时:
根据异动审批落地的时间及异动生效日期,A部门对应编制的拆分周期及未来的拆分周期的计划编制数均-1,B部门对应编制周期的计划编制数均+1
特殊情况:
若员工的异动记录的生效日期为历史日期,但异动记录对当前员工的任职信息无任何影响,则不会对计划编制产生影响
若员工同一天有多条异动记录,则任意一条【带编异动】为「是」时,则需要处理对计划编制数进行调整
异动记录撤销通过(或直接删除异动记录)时,具体的影响逻辑为:
若异动生效日期>撤回的时间,或异动日期生效当天,但编制还未变更,则撤销无需任何调整
若异动生效日期<撤回日期,或异动生效日期=操作日期但编制已变更, 计划编制数需回退处理,且需要再变更记录中记录;
需根据员工异动前后的「部门、职务、工作地点、员工类型、职级」的差异,异动前的对应编制周期及未来周期下对应的编制维度的计划编制数+1,异动后的对应编制周期及未来周期下的对应编制维度的计划编制数-1;
若删除异动记录对其他异动记录产生了影响,需要根据被影响的异动记录中选择的是否带编异动的记录,对相应记录进行更新
例如:员工从A到B异动带编,后续又从B到C异动带编,后续删除了A到B的异动记录时,A到B的异动记录的编制计划和B到C的编制计划的变更已产生的数据均需要撤回,然后再根据A到C的异动记录是否带编,进行编制计划调整
特殊情况:若员工的异动记录的撤销对当前任职信息无任何影响,则不对计划编制数产生影响;若有影响则才会回退
异动审批撤销时,有相应的撤销提示说明

部门的计划编制数因异动审批影响时,在「编制-部门编制-变更记录」中可以查看

2、批量异动
批量异动时,若客户组织中开启了【编制管理】功能,支持配置是否【带编异动】

在线编制及导入时均支持选择具体员工的异动调整是否带编异动


批量带编异动需要审批通过后,员工对应的异动生效日期生效后,部门的计划编制数会对应调整,具体逻辑同异动审批;
部门的编制的变更记录中可查看具体变更原因及信息,点击可直接打开对应的审批单

3、任职记录数据调整、编辑异动记录
客户组织中开启了【编制管理】功能,在员工的任职信息编辑时,添加异动记录可选择是否带编异动

编辑、删除异动记录时,若部门有变更,会根据异动记录上的「带编异动」的信息对应变更,即异动记录的「带编异动」为「是」会更新对应的计划编制数,若为「否」时则不会变更
部门的编制的变更记录中可查看具体变更原因及信息

4、导入异动记录
若客户组织中开启了【编制管理】功能,异动选择为【添加异动记录】导入模板中增加【带编异动】字段
更新异动记录的模板中不需要增加
带编异动字段的数据填写仅支持下拉选择「是」或者「否」,非必填,不填时按否处理


5、组织架构调整中的人员异动时,支持选择
若客户组织中开启了【编制管理】功能,若在批量组织架构调整中,选择了变更员工到该部门时,需要选择是否「带编异动」,非必填,不填按否处理

若在批量组织架构调整中停用了部门,选择了变更员工到其他部门时,需要选择是否「带编异动」,非必填,不填按否处理

6、异动记录写入接口支持带编异动字段传入
异动写入接口支持传入带编异动字段,非必填
升级内容 2:组织架构调整时编制计划优化
业务场景&问题:
组织架构调整部门编制时,不支持自动向上增加编制
组织架构调整部门时,不支持支持带编调整
组织架构调整的部门编制问题,编制的调整会校验部门的时间轴,导致组织架构调整失效
解决方案:
1、组织架构调整时编制联动变化
组织架构调整添加子部门时,只要客户启用了编制,且生效日期有所属的编制周期,则无论生效日期是否是未来日期,均可以同时添加编制计划

点击同时添加编制计划时,会打开添加编制计划的信息

添加编制计划页面也可从组织架构调整中对已有部门点击「添加编制计划」

增加「上级部门编制」字段,默认不选中
若选中:则会联动增加所有上级部门的计划编制数,并显示对应的变更范围
若不选,则按原逻辑进行校验,即:上级部门编制不够或者未配置编制计划时,会阻断提示

变更部门编制计划时,支持联动更新上级部门的计划编制数,均会显示变更范围
若当前部门的计划编制增加,支持可选择是否联动增加上级部门的计划编制
若当前部门的计划编制减少,支持可选择是否联动减少上级部门的计划编制
若选择「减少全部上级编制」:将当前部门的「计划编制数」减少量都扣除到所有上级部门的「计划编制数」中
即上级部门减少的编制的变更数量:即:若子部门从90调整为80,则减少量为10

变更部门信息且变更了上级部门时,可联动变更前后上级部门的计划编制数,若选中后会显示对应的变更范围
注意:变更前后的部门的相同的上级部门的计划编制不会变更

移动、拖动部门时,可联动变更前后上级部门的计划编制数,若选中后会显示对应的变更范围
注意:变更前后的部门的相同的上级部门的计划编制不会变更

停用部门时,若部门开启了编制,支持选择是否联动减少上级部门的编制

上级部门编制的校验及联动更新的详细逻辑:
编制计划的变更需要根据组织架构调整的生效日期的所属编制周期,在生效日期生效,且更新的计划编制数以组织架构方案提交审批时的数据进行更新
若生效日期≤当前日期,则立即变更当前编制周期及未来已配置编制计划的编制周期,未来没有配置的不更新
若生效日期>当前日期,则需要到生效日期后才变更当前编制周期的计划编制数,若生效日期有多条数据时,以后更新的为准。及未来已配置编制计划的编制周期
生效日期之前的编制周期下及未来的编制周期的部门的编制是否符合计划编制数,均不做校验;仅校验生效日期到生效日期当前所属编制周期的结束日期
同一个部门的同类操作,以最后一次操作选择的编制的调整为准,同类操作指:
变更:变更了上级部门、变更了当前部门的计划编制
添加:增加了部门
停用:停用了部门
注意:若为未来生效的组织架构调整,中间不建议再去调整组织架构或者计划编制数,否则数据可能不准
2、组织架构调整编制页面及预览页面增加编制信息
【组织架构调整-编辑方案-列表】增加计划编制数的展示

预览-调整后架构
增加展示编制有调整的详细信息如下
若当前部门下有添加子部门、或调入子部门、或有子部门的计划编制增加,当前部门的编制信息中,相应详细信息会展示
若当前部门下有子部门调出、有子部门的计划编制有减少、停用,需增加相应的减少的详细
若当前部门下有增加有减少的情况,最后汇总实际计划编制数据的增加或减少情况,
注意:若为0对应显示,也可穿透查看
综合增加和减少的计划编制的情况,最终得到当前部门实际的计划编制的调整情况
例如:
A部门原来为计划编制是28,列表页面上就显示32
穿透后弹框显示详细内容:
计划编制增加4,具体调整内容:
因B部门调入,全部上级部门计划编制联动增加 10
因C部门调出,全部上级部门计划编制联动减少6

PC端审批表单中支持查看详情的变更信息

3、变更记录
部门的计划编制数若因组织架构调整产生了变更,在变更记录中会显示具体的来源及原因

升级内容 3:停用部门取消待入职校验
业务场景&问题:
组织架构批量调整时,无法调整待入职员工,但停用部门时会校验待入职员工
解决方案:

操作路径:设置-组织设置-部门信息设置-部门设置
名称修改:原「部门层级自动化设置」更名为「部门设置」
新增配置项:部门停用规则。默认规则:部门下存在在职员工、待转入员工时,不允许停用。支持以下选项
部门下存在待入职员工,则不允许停用:默认勾选,可取消
部门下存在子部门,则不允许停用:默认勾选,可取消 -> 如果取消该选项,且勾选「部门下存在待入职员工,则不允许停用」,则停用部门时,如果部门下的子部门均不存在在职/待转入/待入职员工,则允许停用部门,并联动停用该部门下的子部门。
影响范围:部门停用、组织架构批量调整、接口
停用部门不校验待入职员工的影响:
停用部门后,待入职员工的部门会展示为:xx部门(已停用)
确认入职时,会校验员工的部门是否已停用,如果已停用,将会报错
团队自助
升级内容 1:员工概览页培训信息支持管理控制
业务场景&问题:
员工概览页中培训信息不支持停用,且需要接入字段权限
解决方案:
在【自助服务设置-员工概览页设置】中增加【培训信息】的管理,位置在【履历信息】上方
支持停用:历史数据默认均启用,可自行停用
支持排序
不支持编辑:提示为系统组件禁止编制
对应控制【员工概览页-培训信息】是否展示

员工profile页的【概览中的培训信息】,需要根据培训信息的字段权限进行控制,有任意字段权限则会展示该模块

注意:培训统一受「设置-基础设置-功能设置-人事】中的【培训信息】开关控制

升级内容 2:员工概览页增加其他信息分组tab
业务场景&问题:
当前员工概览页中仅支持员工档案中的部分tab,其他信息页签下的分组和字段无法展示到员工概览页中,导致员工无法在移动端查看或修改其他信息下的字段内容
解决方案:
员工概览页中增加其他信息页签,其他信息页签下的自定义分组无需新增自定义页签即可展示在员工概览页
升级内容 3:我的团队中员工生日按偏好展示
业务场景&问题:
目前我的团队中,员工关怀板块展示的员工生日默认为公历的出生日期,无法按照员工偏好进行展示。报表中也无法获取公历对应本年生日日期
解决方案:
规则设置中增加本年生日日期设置
计算员工生日日期所需字段包括
出生日期——对应系统字段仅可选择员工个人信息分组下的日期类型字段,不包括家庭成员分组下的字段
生日偏好是否为农历——对应系统字段仅可选择员工个人信息分组下的是非类型字段,不包括家庭成员分组下的字段

计算逻辑
「生日偏好是否为农历』=是:出生日期转换为出生年份对应农历日期,再计算今年对应的农历日期对应的公历日期,得出本年生日日期。
若农历日历对应为闰月,则按第一个月计算。
例如员工出生日期为1990年6月23日,对应农历日期为闰五月初一,2025年的本年生日日期用五月初一计算,对应公历日期为2025年5月27日。
若农历日历对应为非闰月,则按对应农历日期进行计算
例如员工出生日期为1980年10月20日,对应农历日期为九月十二,再计算2025年九月十二对应公历日期2025年11月1日,得出本年生日日期为2025 年11月1日
「生日偏好是否为农历」=否:今年对应的出生日期
例如员工出生日期为1980年10月20日,本年生日日期为2025年10月20日
计算时机
每年正月初一自动计算本年生日日期
出生日期(映射字段)、生日偏好是否为农历(映射字段)的值存在变化时,自动计算
本年生日日期的展示和应用
开启后,员工详情页、概览页中增加「本年生日日期」字段
位置在出生日期映射字段下方
任意字段值为空,展示“-”
若偏好为农历,则展示本年生日的公历日期和农历日期
不支持编辑

我的团队看板「员工关怀」板块、移动端「近期关注」板块
若员工生日偏好为农历,将展示农历标签和农历生日
若当员工「本年生日日期」为空时(字段被停用、关联字段非必填时),优先展示出生日期

员工花名册中增加「本年生日日期」字段
若生日偏好为农历,则字段展示对应农历日期
该字段支持日期筛选,仅可按公历日期进行筛选,不支持筛选农历日期

员工关怀通知配置
【员工生日卡片】和【员工生日提醒】中,生日偏好支持选择「本年生日日期」,选择后隐藏「公历/农历」的选项

假勤
升级内容 1:出差、外出记录支持重新核算
业务场景&问题:
出差、外出目前不支持重新核算。当班次设置或考勤组规则变更后,无法按最新规则重新核算,需要撤销原来的记录重新提交,会增加员工和审批者的工作量。
解决方案:
出差、外出记录支持重新核算
功能权限拆分
【查看】权限,拆分为查看和导出,历史有查看权限的员工,默认勾选上【查看】和【导出】
【编辑】权限,拆分为添加、导入,历史有编辑权限的员工,默认勾选上【添加】和【导入】
新增【重新核算】权限。默认不勾选,需要手动开启

拥有【重新核算】权限的员工,在出差/外出记录页面限制重新核算按钮,点击后弹出重新核算窗口
核算范围为当前列表展示的所有出差/外出记录。可通过左侧筛选确定需要重新核算的出差/外出记录
上方提示本次重新核算的条数:
若选择的数据均不是「已通过」:已选择X行,但全部都不满足操作条件。重新核算失败时可查看「重新核算异常说明」进行排查
若选择的数据部分为「已通过」: 已选择X行,可执行Y行。重新核算失败时可查看「重新核算异常说明」进行排查
若选择的数据均为「已通过」:将重新核算X行出差记录。
X-Y为状态为审批中、已撤销、已驳回的数量。
点击确认立即开始重新核算,重新核算完成后将告知成功和失败的条数,可查看「重新核算异常说明」进行排查
被重新核算过的出差/外出记录,将会展示「已重新核算」的标记



重新核算计算逻辑:
出差记录重新核算逻辑:将依据员工「出差申请开始日期」对应的最新出差规则,以及「出差时间」对应的班次(公休日和节假日以休息班次记录时间为准,若无记录时间,则按9:00-17:00),重新核算考勤周期内的出差时长。
外出记录重新核算逻辑:将依据外出规则,以及「外出时间」对应的班次(公休日和节假日以休息班次记录时间为准,若无记录时间,则按00:00-次日00:00),重新核算考勤周期内的外出时长。
仅支持重新核算审批通过的出差/外出记录,核算失败的异常情况说明如下
异常情况 | 异常说明 | |
出差记录 | 员工无考勤组 | 查询到存在员工出差开始日期没有考勤组规则了,则不重新核算 |
出差单位不符 | 若出差记录与查询到的出差规则单位不一致时,则不重新核算 | |
外出记录 | 员工无考勤组 | 查询到存在员工外出记录的开始/结束日期没有考勤组规则了,则不重新核算 |
出差记录补充优化
出差记录展示和导出中的地址字段,包括但不限于出发城市、目的城市等,需要和审批表单中的地址展示一致,展示全路径

升级内容 2:请假时间可按个人信息进行限制
业务场景&问题:
系统目前暂不支持根据个人信息限制请假日期,该场景下采用人工审核的方式,工作量大且存在合规风险。例如:
婚假:浙江、山东等省份规定,职工选择休婚假的,应当自登记结婚之日起一年内休婚假
哺乳假:国家层面的《女职工劳动保护特别规定》明确,申请该时间的期限为婴儿未满 1 周岁期间。
解决方案:
请假设置中,新增请假时间限制。可基于任职信息、个人信息中的日期类型字段配置限制规则。最多可添加5条规则
请假日期{不可早于/不可晚于}{自选字段}{当天/前/后}
自选字段下拉选项范围:任职信息、个人信息中的日期类型字段,包含自定义字段和家庭成员中的字段,例如成员生日。
若选择的是家庭成员中的日期类型字段,需选择某个成员关系日期中最早或最晚的日期。
例如育儿假,需配置不可晚于「成员生日(子女)」「最晚日期」「12」「月」
选择前或后时,还需要选择{N}{单位}
选择天时,N的范围为1-999,默认为1
选择月时,N的范围为1-99,默认为1

请假规则校验逻辑
该配置仅对员工申请生效,管理员添加、导入、接口写入的请假记录不生效。
员工申请时,选择请假日期后,将校验请假日期是否符合规则。不符合时报错:请假日期{不可早于}{自选字段}{当天/前/后}({具体日期})

试用期
升级内容 1:试用期多轮考核可不限制上一轮结束才开启下一轮
业务场景&问题:
试用期多轮考核必须在上一轮结束后才能开启下一轮,无法只按照时间开启。
解决方案:
新增「轮次开启设置」
转正方案中,如果设置了多个考核轮次,则展示配置「轮次开启设置」
上一轮考核结束时,方可进入下一轮考核:默认选择该选项,必须在上一轮结束后才能开启下一轮
仅根据发起时间开启考核:若选择该选项,则到达发起时间就会开启考核,不校验上一轮是否结束。

在「试用期管理-管理考核规则与轮次」中,也可为单个员工修改「轮次开启设置」

对自动操作的影响
若选择「仅根据发起时间开启考核」,将会对以下场景有影响
自动终止考核:将在达成条件的轮次结束后,终止所有进行中轮次的考核
例如(条件配置如图所示):轮次1进行中,轮次2转正意见为「提前转正」且已结束,需终止后续轮次考核,轮次1直接终止
自动追加考核:以考核轮次定义的最后一轮为准,无影响。
自动发起转正审批:
以任意一轮的意见 / 等级触发,则达成条件后立即触发。例如:
第一轮进行中,第二轮满足自动转正,则在第二轮结束后,发起转正审批,审批通过后,两轮被一起归档
第一轮、第二轮进行中,第一轮满足自动转正,则在第一轮结束后,发起转正审批,审批通过后,两轮被一起归档
若配置 以最后一轮的意见 / 等级或按照时间触发,则无影响。

转正意见的继承
现状:默认填充上轮考核填写的转正意见;若上次没填写,则默认为空。可在内容权限中配置由环节执行人填写。
继承关系:继承自上一轮考核的转正意见
继承时机:在当前轮次的转正意见填写之前,若上一轮产生了转正意见,则需继承;若上一轮未产生转正意见,则继续向前序轮次查询。
case1:第一轮考核未产生转正意见时,第二轮考核填写了转正意见为“正常转正”;之后第一轮考核产生了转正意见“不通过”,第二轮考核将不会继承第一轮考核的转正意见。
case2:第一轮考核已产生转正意见“正常转正”,第二轮考核尚未填写转正意见,则在填写时,会继承第一轮的转正意见“正常转正”
试用期管理列表
现状:列表中的字段、操作都是针对「当前轮次」
操作:调整执行人、调整考核结果、导出员工目标详情(默认当前轮次,可选择其他轮次)、导出员工考核结果(默认当前轮次,可选择其他轮次)、发起目标确认签署(默认当前轮次,可选择其他轮次)
调整执行人、调整考核结果:本次支持选择轮次,默认为当前轮次,可选择其他轮次。
当前轮次定义:最早未完成的轮次
例如:轮次1已完成,轮次2考核中,轮次3考核中。则「当前轮次」为轮次2
考核状态计算逻辑:
待考核:员工未开启试用期考核。
考核中:员工已开启试用期考核,至少有一个轮次处于考核中。
考核完成:员工所有轮次均考核完成。
已终止:员工所有轮次均终止。
终止考核:本轮次及后续轮次考核(包括后续进行中的轮次)都被终止,考核数据保留,未完成的待办都被取消。
可重启考核,重启时需将本轮次及后续轮次被终止的考核都重启
升级内容 2:历史离职员工的试用期考核状态支持立即更新
业务场景&问题:
定时任务在每天凌晨1点 将离职员工的 试用期考核状态 修改为「已终止」 。但是对于历史离职日期的已离职员工,也需要等到凌晨1点才能更新考核状态,存在滞后性。
解决方案:
增加自动终止考核的时机:若为历史离职员工,则离职审批落地后就自动将试用期考核终止。
电子签
升级内容 1:电子签法人公司走权限
业务场景&问题:
发起签署时,法人公司下拉列表未受权限控制
电子签设置的法人公司列表展示未受权限控制
解决方案:
以下场景的法人公司展示会受「组织字段可选范围」控制,操作路径:账号权限-账号管理-组织字段可选范围

发起签署-法人公司下拉列表

服务对接-电子签-法人公司电子签设置,法人公司列表

OpenAPI
升级内容 1:新增获取员工招聘信息接口
业务场景&问题:
目前缺失招聘信息的查询接口
解决方案:

新增【招聘信息查询】
基本信息
请求地址:https://api.mokahr.com/api-platform/hcm/oapi/v1/recruitmentInfo/batchGetEmployeeRecruitmentInfo
请求频率:3次/秒/企业, 60次/分钟/企业
请求方式:POST
请求头 Header
字段 | 必填 | 类型 | 描述 |
Authorization | 是 | Basic | 略,"鉴权验证说明"部分已经明确说明 |
请求参数 Query Param
字段 | 必填 | 类型 | 描述 |
entCode | 是 | String | 租户的唯一ID;由CSM(客户成功经理)提供 |
apiCode | 是 | String | 租户配置的api应用对应的唯一ID 是Moka People系统"设置" - "对外接口设置"的【接口编码】字段,数据源=【获取员工招聘信息】 |
nonce | 是 | String | 每次请求的随机字符串,由客户自己随机生成;长度不超过8位,由数字和不区分大小写的英文字母构成 |
timestamp | 是 | Long | 时间戳;精确到毫秒 |
sign | 是 | String | 在"验签说明"里有详细说明 |
请求体 Request Body
字段 | 必填 | 类型 | 描述 |
uuidList | 否 | Array | 员工ID集合,item为每个要查询的员工ID,Long类型,不能超过2000条 |
employeeNoList | 否 | Array | 员工工号集合,item为每个要查询的员工工号,String类型,不能超过2000条 |
pageNum | 否 | Integer | 页码,默认为1 |
pageSize | 否 | Integer | 每页大小,默认为200,最大200 |
注:1、uuidList 和 employeeNoList 不能同时传入,请二选一 2、uuidList 和 employeeNoList 至少传入一个,且不能为空
响应体 Response Body
字段 | 必填 | 类型 | 描述 |
code | 是 | Integer | 响应状态码,200表示成功 |
msg | 是 | String | 响应消息 |
data | 是 | Object | 响应数据 |
data.pageNum | 是 | Integer | 当前页码 |
data.pageSize | 是 | Integer | 每页大小 |
是 | Long | 总记录数 | |
data.list | 是 | Array | 员工招聘信息列表 |
data.list[].uuid | 是 | Long | 员工唯一标识ID |
data.list[].jobName | 否 | String | 应聘职位名称 |
data.list[].jobNumber | 否 | String | 招聘编号 |
data.list[].type | 否 | String | 招聘类型(如:校招、社招等) |
data.list[].source | 否 | String | 招聘来源(如:猎聘、智联等) |
data.list[].sourceType | 否 | String | 来源类型(如:主动投递、推荐等) |
data.list[].jobManager | 否 | Long | 招聘负责人员工ID |
data.list[].referrer | 否 | Long | 推荐人员工ID |
data.list[].referrerEmail | 否 | String | 推荐人邮箱 |
data.list[].referrerPhone | 否 | String | 推荐人电话 |
data.list[].others | 否 | Object | 其他自定义字段信息,key为字段ID |
data.list[].interview | 否 | Array | 面试资料附件列表 |
data.list[].interview[].id | 是 | Long | 附件ID |
data.list[].interview[].name | 是 | String | 附件名称 |
data.list[].interview[].url | 是 | String | 附件URL |
data.list[].resume | 否 | Array | 简历附件列表 |
data.list[].resume[].id | 是 | Long | 附件ID |
data.list[].resume[].name | 是 | String | 附件名称 |
data.list[].resume[].url | 是 | String | 附件URL |
data.list[].backgroundCheckReport | 否 | Array | 背调报告附件列表 |
data.list[].backgroundCheckReport[].id | 是 | Long | 附件ID |
data.list[].backgroundCheckReport[].name | 是 | String | 附件名称 |
data.list[].backgroundCheckReport[].url | 是 | String | 附件URL |
data.list[].assessmentResults | 否 | Array | 测评结果附件列表 |
data.list[].assessmentResults[].id | 是 | Long | 附件ID |
data.list[].assessmentResults[].name | 是 | String | 附件名称 |
data.list[].assessmentResults[].url | 是 | String | 附件URL |
data.list[].candidateInformation | 否 | Array | 候选人信息附件列表 |
data.list[].candidateInformation[].id | 是 | Long | 附件ID |
data.list[].candidateInformation[].name | 是 | String | 附件名称 |
data.list[].candidateInformation[].url | 是 | String | 附件URL |
data.list[].offerDocument | 否 | Array | Offer文档附件列表 |
data.list[].offerDocument[].id | 是 | Long | 附件ID |
data.list[].offerDocument[].name | 是 | String | 附件名称 |
data.list[].offerDocument[].url | 是 | String | 附件URL |
data.list[].offerElectronicSignature | 否 | Array | Offer电子签名附件列表 |
data.list[].offerElectronicSignature[].id | 是 | Long | 附件ID |
data.list[].offerElectronicSignature[].name | 是 | String | 附件名称 |
data.list[].offerElectronicSignature[].url | 是 | String | 附件URL |
data.list[].otherDocument | 否 | Object | 其他自定义附件,key为字段ID,value为附件数组 |
data.list[].otherDocument.{fieldId}[] | 否 | Array | 自定义字段对应的附件列表 |
data.list[].otherDocument.{fieldId}[].id | 是 | Long | 附件ID |
data.list[].otherDocument.{fieldId}[].name | 是 | String | 附件名称 |
data.list[].otherDocument.{fieldId}[].url | 是 | String | 附件URL |
绩效
升级内容 1:绩效指标数据填报
业务场景&问题:
绩效管理的核心目的是确保企业经营目标可达成,这就意味着绩效考核内容通常会跟业务数据关联,而且绩效考核时间通常会非常集中,一般会在3天-3周内完成,绩效考核频次越高时间周期越短,尤其是业务部门的绩效大多数月度,就需要用户不断重复的将业务数据录入到绩效系统中来完成目标跟进或者绩效考核。
痛点:
人工录入数据
员工自己录入,无法保证数据准确性
运营来录入,目前无法控制录入范围,以及当前导入的使用效率比较低
HR后台来录入,增加了沟通成本且增加了HR的工作量,以及当前导入的模板易用性比较低
通过接口自动回写数据,开发成本高,且业务指标会不断变化,需要不断调整回写逻辑,运营成本也高
解决方案:



【绩效活动】
增加绩效指标填报,第五步,默认不开启
开关说明:【如需要外部角色,如运营、财务等,进行员工考核指标的目标值或者完成值填写,可开启规则自动生成填报任务或者在活动中手动分配填报任务。】
活动复制时,支持复制绩效指标填报规则
【绩效指标填报规则】
填报内容:
必填
可选指标:支持选择活动下所有评估组下的指标类型的固定指标或者指标库的指标,支持多选
填报字段:选择对应指标后可选择要填写的字段(暂不支持附件类型和多选类型字段)
谁来填写
支持选择组织职责、自定义角色、员工任职上的员工字段、在职员工
填报范围:
全员:默认选择
指定员工:适用范围
增加说明:填报范围会按照填写人角色权限和可填写指标进行过滤
开始时间:
绩效周期开始时间(XXX具体时间)后 X天(1~99,默认空白) X时(00:00~24:00,每30分钟一个间隔,默认10:00)
选择后需要在下方回显具体日期和时间
绩效周期结束时间(XXX具体时间)后 X天(1~99,默认空白) X时(00:00~24:00,每30分钟一个间隔,默认10:00)
选择后需要在下方回显具体日期和时间
指定时间(可选择今天及以后的任意时间), X时(00:00~24:00,每30分钟一个间隔,默认10:00)
绩效活动复制时,如果选择的是指定时间,需要清空,让客户重新选择
截止时间:
默认开始后3天,支持修改1~99范围内的数字
审批流程
可选择所有启用的数据填报的审批流程
数据填报活动创建后,对应的填报规则不允许编辑

新增【指标填报】页签
列表展示(复用绩效填报活动列表):
填报活动、所属年月、截止日期、状态、未完成人数、已完成人数、开始时间、截止时间、备注
筛选内容:
填报活动名称、所属年月、填报创建人、状态
操作:
绩效填报活动(详情、编辑、删除)、添加绩效指标填报

【添加绩效指标填报】
填报内容:
必填
可选指标:支持选择活动下所有评估组下指标类型的指标或者指标库的指标,以及按指标类型+指标名称去重的自定义指标,支持多选
填报字段:选择对应指标后可选择要填写的字段,支持多选(暂不支持附件类型字段)
谁来填写
支持选择组织职责、自定义角色、员工任职上的员工字段、在职员工
填报范围:
全员:默认选择
指定员工:适用范围
增加说明:填报范围会按照填写人角色权限和可填写指标进行过滤
开始时间:
默认立即开始
截止时间:可选择今天以后得任意时间
审批流程:
可选择所有启用的数据填报的审批流程


【数据填报活动创建】
活动名称:绩效活动名称的指标填报-顺序号
填报维度:员工+指标类型+指标名称
展示字段:员工、工号、部门、职务、指标类型、指标名称
填报字段:绩效中设置的填写字段
活动管理员:默认为绩效活动管理员
备注(本次新增,非必填,多行文本,2000字):将填报内容传入
【补偿机制】
定时开启时,如果活动中有评估组未开启,则不创建指标填报活动,次日相同时间会再次补偿,支持页面手动补偿
页面增加提示【由于评估组暂未启动,绩效指标填报活动创建失败】,增加重试按钮

PS:不支持在填报过程中再手动添加人员,如有需要可以手动发起新的填报活动
【数据落地】
指标填报可能再任意时间完成或者进行多轮,根据后落地生效的机制修改数据
绩效绩效指标填报审批通过后,更新员工指标相关的值,并触发指标得分自动计算、维度得分自动计算、总评/绩效结果自动计算
仅数值变化的字段,修改数据需要产生操作记录,来源:绩效指标填报,操作人:填报人
填报落地后,若有草稿,则进行对应指标的更新,若草稿无法更新,则删除草稿,并给出提示【指标信息发生变更,需要重新填写】

【角色管理】
新增绩效指标填报,具备【查看】和【添加指标数据填报】的操作权限
勾选查看时,联动勾选【基础应用-数据填报-查看】
勾选【创建绩效指标填报】时,联动勾选【基础应用-数据填报-查看、编辑、删除】
角色管理-基础应用-数据填报,新增【绩效指标填报】,查看、编辑、删除
升级内容 2:360环评支持基于飞书问答智能总结(该功能仅针对对接飞书租户且非全量上线,开通联系客户成功经理。若涉及到飞书AI包的试用,如需开通内部联系产品跟进)
业务场景&问题:
绩效季的 deadline 近在眼前,核心工程师李明的眉头却越皱越紧 —— 作为跨部门协作的关键角色,他要完成 8 位上下游同事的 360 环评打分。可年底正是业务冲刺的关键期,手头项目排期已经压得喘不过气,挤不出整块时间应付环评,光是想想就头大。
更棘手的是协作场景的复杂性:有的同事仅在几次需求评审会上匆匆对接,对其工作细节一无所知;有的协作已是半年前的旧项目,关键表现早已模糊;还有的高频协作却琐事繁杂,零散的对接片段根本凑不成完整的评价依据。为了找客观佐证,他不得不抽碎片时间翻找资料,回忆各种细节,可要么毫无有效信息,要么需要耗时半天甚至更久的时间逐条去翻找聊天记录、会议基于,但又害怕耽误核心工作。
两难之下,李明只能凭着模糊印象写下 “认真负责”“沟通顺畅” 这类空泛评语,甚至偶尔掺杂人情分。可这样的反馈没有任何事实支撑,既帮不到被评估人精准成长,也让 360 环评彻底沦为形式 —— 耗费大量精力,却没发挥任何实质作用,反而变成了一场 “人脉考核”。
解决方案:

【绩效-绩效模板-内容权限】
360评估环节,参考信息,如果客户有安装飞书IM,新增【智能总结】
增加说明:【可基于飞书知识问答,智能总结360环评人与被评估人绩效周期下共同的聊天记录、会议记录、知识库文档,使用前需要确认已购买飞书AI包】
新模板默认开启,旧模板默认关闭,支持在活动中编辑模板时,手动开启


【绩效待办】
360环评,如果开启了【智能总结】,默认展开参考信息
如果客户未购买飞书AI,则给出示例,并提示【请联系HR购买飞书AI包】
【对接流程和提示词】
知识问答接口:https://open.feishu.cn/document/search-v2/knowledge_qa/answer?appId=cli_a870b7f963be900e
总结内容:
默认文案:帮我总结和工号为XXX的XXX(被评估人姓名)(此段文案不允许修改),在N时间段(绩效周期内)协作内容,列最重点的3项
问题长度不能超过1000字
重新提问后也仅回显并记录最新一次的问答内容,并增加回答内容的链接,链接文案统一为【来源:飞书知识问答智能总结】
飞书知识问答参数说明:
不展示图片
默认搜索企业内知识
知识库搜索范围:云空间问答、知识库文档、消息、comment文档备注
模型:默认doubao_auto_thinking
升级内容 3:数字字段单位随着完成值目标值设为必填即必填
业务场景&问题:
数字字段设置了必填,但是单位仍是非必填,最终查看目标信息时,容易产生误解
解决方案:

【设置-绩效设置-目标填写设置】
数字类型字段,新增【单位】的设置
可选择:非必填(默认)、字段必填时必填、字段有值时必填
如果选择了【字段必填时必填】、【字段有值时必填】,则所有待办需要增加校验
规则变化会影响在途的流程,如果当前节点有数字字段的编辑权限,单位未输入时,需要进行必填校验
升级内容 4:绩效待办交互优化
业务场景&问题:
绩效横视图/纵视图模式,存在较多体验不佳的交互,需要进行优化
移动端绩效评估时,评价标准需要手动点开
解决方案:
场景 | 现状 | 解决方案 |
横视图 |
|
横视图中,输入内容时,输入框支持自动撑高 |
横视图 |
|
横视图中,行高支持根据内容自动调整(去掉最多展示4行的限制) |
横视图 |
|
横视图中,自动隐藏所有指标均为空的字段,支持在自定义列再次打开 |
横视图 |
|
横视图中,支持自定义展示列 |
横视图 |
横视图中,始终展示滚动箭头 | |
HR端产看考核表 |
|
支持简洁模式 |
移动端评价规则 |
|
填写中:显示完整参考+等级匹配 |
审批
升级内容 1:薪资计划只读时,审批表单加载优化
业务场景&问题:
由于部分客户薪资计划内容较多,导致相关的审批单打开卡顿,加载慢
解决方案:
优化薪资计划在审批表单中只读时的渲染逻辑,不额外挂载多余数据。
特殊说明:
该方案仅能优化部分审批人场景的打开表单慢问题。如遇到客户反馈,可引导客户将不需要操作薪资计划的「审批节点-薪资计划」字段设为只读,可大幅优化
发起人场景以及审批人有需要修改薪资计划的场景,暂无法解决
升级内容 2:支持设置任务办理人是否可见抄送、无人审批、审批意见内容
业务场景&问题:
审批意见、抄送节点、无人审批节点是否可见仅支持设置对「发起人」、「申请人」、「抄送人」。部分客户需要对「任务办理人」生效

解决方案:
在以上场景中新增「任务办理人」选项,可配
升级内容 3:文件模版中,新增「实际流程」明细组
业务场景&问题:
多家客户使用「自定义审批打印模版」能力时有反馈,希望可支持一个实际审批流程的封装变量,使用「自定义审批打印模版」时,只需要引用一个变量就可以获取到整个审批单实际流转流程。
现状:
只能在「文件模版」中提前定义好每个节点名称,然后逐个关联「审批流程」分组内容。但往往很难提前在文件模版预置准确的节点信息和实际流转路径,导致场景不太可用或配置复杂
如:

模版:

解决方案:
在文件模版中新增「实际流程」明细组,在表单中插入明细组字段后,可按明细组方式直接渲染对应审批流程相关字段(如:审批节点、审批人)的全部信息

渲染结果示例:

IM
升级内容 1:【旗舰版】支持外部浏览器打开
业务场景&问题:
旗舰版部分客户希望可以在本地浏览器打开系统
解决方案:
浏览器访问:https://oa.dingtalk.com
注意事项:由于钉钉框架问题,第一次访问需要授权登录两次(先登录钉钉OA域名,再单点登录旗舰版),后续无须重新授权,可直接登录
升级内容 2:支持使用工号作为飞书同步userId(需要该功能联系客户成功经理开通,内部联系产品)
业务场景&问题:
客户自研系统或者其他三方系统对接了飞书并且使用了工号作为userId,但People同步员工时,不支持自定义userId
解决方案:
入口:IM对接-飞书-员工同步-查看详情-飞书账号生成规则

参考企微弹窗:

升级内容 3:钉钉企业账号转移给其他员工后,员工重新绑定后无法登录
业务场景&问题:
客户企业账号是继承的,A员工离职后,B员工修改原有企业账号的手机号继续绑定使用,这样会涉及过往员工如果没能解绑账号的话,B员工绑定后单点登录报权限错误,无法登录成功
解决方案:
新员工继承企业账号后,第一次同步时,自动解绑老绑定关系后,重新绑定到该员工
升级内容 4:导入平台支持直接使用飞书多维表作为数据源导入
业务场景&问题:
打通飞书多维表和业务场景的数据同步。
场景示例:
批量组织架构调整
1.部门数据源同步BI同步到飞书多维表(升级内容5)
2.飞书多维表上调整部门组织架构
3.导入-部门更新-飞书多维表(步骤1)
解决方案:
约束条件声明:
仅IM绑定飞书用户可用
操作同步时,需要操作人具备飞书IM绑定关系 && 当前操作人在多维表文档协作人列表内
暂仅支持「个人云文档-飞书多维表」同步 (知识库-飞书多维表类型:暂时规划1月支持)
什么是「个人云文档-飞书多维表」? 链接中包含 ...feishu.cn/base...的url
什么是「知识库-飞书多维表」? 链接中包含 ...feishu.cn/wiki...的url


不支持多维表列类型为:单向关联、双向关联、附件、群组、地理位置等列类型的内容同步到系统
单次最大支持4000行内容同步
支持范围说明:
【容易引起吐槽,后续看资源治理】不支持老导入,仅支持标准对接的新导入
什么是老导入?最简单的区别,看界面,老导入示例:

为什么有些看着是新导入,但是不支持?非标准方式对接,后续计划迁移
具体范围参考PRD说明:https://wiki.mokahr.com/pages/viewpage.action?pageId=201979238
操作说明:
打开任意已支持的导入,选择「数据源类型 == 飞书多维表」,填写云文档-飞书多维表链接。如:部门导入

设置「飞书多维表」列和「导入模版」列映射关系(默认按列名预匹配)

点击「开始导入」,等待飞书多维表数据抓取完成。

抓取完成后将自动创建导入任务

升级内容 5:支持报表同步到飞书多维表
业务场景&问题:
打通飞书多维表和业务场景的数据对外同步。
场景示例:
批量组织架构调整
1.部门数据源同步BI同步到飞书多维表(升级内容5)
2.飞书多维表上调整部门组织架构
3.导入-部门更新-飞书多维表(步骤1)
解决方案:
约束条件声明:
仅IM绑定飞书用户可用
操作同到指定多维表时,需要操作人具备飞书IM绑定关系 && 当前操作人在多维表文档协作人列表内
暂仅支持「个人云文档-飞书多维表」同步 (知识库-飞书多维表类型:暂时规划1月支持)
什么是「个人云文档-飞书多维表」? 链接中包含 ...feishu.cn/base...的url
什么是「知识库-飞书多维表」? 链接中包含 ...feishu.cn/wiki...的url
创建新的多维表,将默认将当前操作人添加到多维表管理员
数据同步上限取决于客户飞书购买规格:

操作说明:
打开任意报表,右上角「同步至多维表」

同步方式说明:
创建新的多维表和数据表:在操作人个人云文档中创建一个新的多维表&&数据表,数据写入到数据表
同步至指定多维表,更新已有数据表:将按自定义的「更新规则」(如:姓名+工号),优先更新已有数据然后追加未匹配到的数据
特殊逻辑说明:
如果按「更新规则」在多维表中匹配到多条数据(即条件不唯一),仅更新多维表第一条
如果按报表内数据按「更新规则」也存在多条数据,将按报表数据顺序依次更新(即实际结果 == 报表内该规则最后一条数据)
同步至指定多维表,新建数据表:在对应多维表下新增一个数据表,并将数据写入到新增数据表
自动同步规则说明:
开启「自动同步」设置后,将按自定义同步周期,定时同步数据到飞书多维表
如同步规则 == 同步至指定多维表,更新已有数据表 ,每次触发时都先更新再追加
如同步规则 == 同步至指定多维表,新建数据表,每次同步新增一个数据表并写入当期内容
BI
升级内容 1:BI接入法人公司电子签实体
解决方案:
【实体】法人公司信息
字段
字段类型
是否连接字段
备注
法人公司ID
数字
是
编码
文本
是
公司名称
文本
是
公司全称
文本
是
公司简称
文本
否
公司英文名
文本
否
公司英文简称
文本
否
法人姓名
文本
是
法人编码
文本
否
公司性质
选项
否
注册日期
日期(年月日)
否
统一社会信用代码
文本
是
注册地址
文本
是
经营地址
文本
是
邮政编码
文本
是
描述
文本
否
使用状态
选项
否
电子签状态
单选
否
未开通
开通中
已开通
委托书链接
文本
否
委托书名称
文本
否
委托书模板ID
数字
否
委托书审核状态
选项
否
0-待上传、1-审核中、2-审核通过、3-审核不通过
委托书审核原因
文本
否
e签宝法人主体授权应用id
数字
否
印章授权状态
选项
否
0-待授权、1-授权成功
印章授权数据状态
选项
否
1-有效,0-无效
创建人ID
文本
是
更新人ID
文本
是
创建时间
时间(到秒)
否
更新时间
时间(到秒)
否
【实体】法人公司印章信息
字段
字段类型
是否连接字段
备注
法人公司ID
数字
是
法人公司名称
文本
是
印章类型
选项
否
1-公章 2-人名章 3-合同章 4-法人章 5-人事章
印章ID
数字
是
印章简称
文本
是
印章创建日期
日期(年月日)
否
印章授权失效日期
日期(年月日)
否
印章状态
选项
否
1-可用 0-不可用
印章数据状态
选项
否
1-有效,0-无效
创建人ID
数字
是
创建时间
时间(到秒)
否
更新人ID
数字
是
更新时间
时间(到秒)
否
























