人事
升级内容 1:增加花名册的证件类型
业务场景&问题:
花名册的证件类型不全,导致个税无法申报,如:港澳居民居住证
海外员工没有适配的证件类型,统一用「其他」适配
解决方案:
花名册的证件类型增加以下类型
台湾居民居住证
港澳居民居住证
外国人工作许可证
其他

薪酬-人员报送适配新类型:

薪酬-接口算税时,对于台湾居民居住证和港澳居民居住证时,要求必须传入其他证件类型,人员报送时需要在「薪酬-人员报送-编辑」中填写必填的信息
注意:「外国人工作许可证」对应接口中的「中华人民共和国外国人工作许可证(A类)」


人事相关的页面支持新的证件类型:
导入、导出待入职人员/花名册
添加新员工、审批添加待入职、ATS发起待入职
确认入职
花名册人事信息编辑
Openapi查询、添加、更新待入职;Openapi查询、更新员工信息
信息采集、花名册信息健康度
通用列表查询
电子签支持新的证件类型的发起
升级内容 2:成本中心人力填报生效时间优化
业务场景&问题:
成本中心填报时的默认生效日期为填报活动创建的日期,导致员工填报时成本中心填写不对
解决方案:
成本中心人力填报时,生效日期默认为填报活动创建时间,需调整为默认生效时间为:填报周期的第一天,若员工第一天没有入职是应该默认是员工的入职日期
即若为月的则填月初1号,若为季度则为季度的1号

升级内容 3:合同到期通知支持单条通知
业务场景&问题:
当前只有合同到期聚合通知,缺少合同到期单条通知
解决方案:
通知模板-所属分类名称变更:
原名称
修改后
合同到期通知
合同到期-聚合通知
入职单条通知
入职-单条通知
入职聚合通知
入职-聚合通知
通知模板新增所属分类:合同到期-单条通知。以下为通知模板内容
单条通知
说明
通知模板名称
限制24字以内
所属分类
合同到期-单条通知
发送方式
邮件
IM消息
发件人/短信签名
用户输入
邮件标题/标题
快捷字段:姓名、工号、合同类型、剩余期限
通知内容/消息摘要
支持引用字段,字段信息为合同到期员工的信息
支持的字段分组:任职信息、离职信息、基本信息、联系方式、个人概况、紧急联系人、银行卡信息、合同协议、自定义分组
「合同协议」分组新增字段:剩余期限、合同管理系统链接
快捷字段:姓名、工号、部门、职务、合同类型、预计终止日期、剩余期限、法人公司
注意:合同到期-单条通知中,所有引用字段的取值都是合同到期员工的信息;但在合同到期-聚合通知中,只有「合同到期信息」分组的取值是合同到期员工的字段,其他分组的取值为通知接受人的信息。
合同到期通知
操作路径:合同管理-合同到期通知-通知模板-选择通知模板
合同到期通知 增加「通知类型」:可选择单条通知、聚合通知
若选择单条通知
则通知模板的「系统默认文案」为单条通知的文案,可在「通知方式」处预览各个渠道的默认通知文案
通知模板-选择通知模板:支持选择所属类型为「合同到期-单条通知」的通知模板
若选择聚合通知
则通知模板的「系统默认文案」为聚合通知的文案,可在「通知方式」处预览各个渠道的默认通知文案
通知模板-选择通知模板:支持选择所属类型为「合同到期-聚合通知」的通知模板

升级内容 4:重新入职员工自定义分组字段需继承
业务场景&问题:
二次入职员工的自定义分组信息无法继承
解决方案:
注意:该能力设置了白名单,按需开放
本次改造范围:个人信息、其他信息
继承规则:整组继承,若二次入职时未填写分组内容,则取历史任职的自定义分组数据;若填写了,则以填写的为准。
个人信息-预置分组:自定义字段不继承
个人信息-自定义分组:若二次入职时填写了自定义分组内的字段,则整组不继承
其他信息:若填写了自定义分组的内容,则整组不继承。
涉及场景:确认入职
薪酬
升级内容 1:薪资计划公式关联字段支持同步更新
业务场景&问题:
薪资计划的A字段编辑了,B字段本身没有编辑,但B是依据A计算时,目前B字段不会更新
薪资计划会更新生效中的薪资档案,需要排除生效中为停薪记录的薪资档案
解决方案:
薪资计划编制时,需查询所有存在本次薪资计划变更的字段A(含增加、编辑、删除),是否有应用在其他字段B的公式中,需要按下方规则同步联动进行更新
若公式联动的字段为原有字段B,且本身字段没有更新,变更类型为【编辑】,需根据客户选择的编辑是否联动更新进行更新,且提示文案需要优化

若字段中引用的工资项目字段被删除了,增加校验,阻断提示

薪资计划更新员工的范围,去掉当前生效中为【停薪记录】的档案,员工列表中也不展示

增加薪资标准项目的操作记录的显示

关联该薪资计划的员工,均为在薪资档案中展示薪资计划最新的字段
通用
升级内容 1:填报支持同步到IM待办
业务场景&问题:
目前填报只有系统内的待办,没有发送IM待办,无法及时收到通知
解决方案:
钉钉/飞书 IM 对接后,对应的 IM 卡片的「待办数据同步」增加「填报待办」设置
待办推送需要客户手动打开
对应所有的填报类型:薪酬填报、部门人力填报、成本中心人力填报、项目组人力填报、员工信息填报、考勤填报

开启设置后,创建完填报活动,推送给填报人待办时,需同步创建IM待办
待办完成后IM的待办也会更新为已完成状态
若待办的截止日期修改了,会重新推送新的待办到IM,截止日期按新的截止日期展示
若待办到截止日期还未完成,会更新为已逾期的状态
若已逾期后,HR修改了截止日期,会重新打开IM的待办
若删除了填报活动,会同步删除IM的待办


假勤
升级内容 1:支持补卡记录写入接口
业务场景&问题:
客户需要在外部系统完成补卡流程后,将补卡记录写入MOKA,目前不支持补卡记录写入接口,每月通过导入完成,导致HR工作量大且时效性较差。
解决方案:
增加补卡记录写入接口
接口说明:通过此接口,可以将已审批通过的单条补卡记录写入到考勤系统。接口支持写入最近半年的补卡信息。
基本信息
请求地址:
请求频率:1次/秒/企业,60次/分钟/企业
请求方式:POST
请求头 Header
字段 | 必填 | 类型 | 描述 |
Authorization | 是 | Basic<base64("username:password")></base64("username:password")> | 略,"鉴权验证说明"部分已经明确说明 |
请求参数 Query Param
字段 | 必填 | 类型 | 描述 |
entCode | 是 | String | 租户的唯一ID;由CSM(客户成功经理)提供 |
apiCode | 是 | String | 租户配置的api应用对应的唯一ID 是Moka People系统"设置" - "对外接口设置"的【接口编码】字段,数据源=【补卡记录添加信息】 |
nonce | 是 | String | 每次请求的随机字符串,由客户自己随机生成;长度不超过8位,由数字和不区分大小写的英文字母构成 |
timestamp | 是 | String | 时间戳;精确到毫秒 |
sign | 是 | String | 在"验签说明"里有详细说明, |
请求体 Request Body
字段 | 类型 | 必填 | 描述 |
employeeUniqueIdentifier | String | 是 | 员工的唯一标识,由uniqueIdentifierType指定,目前支持六种,六选一 |
uniqueIdentifierType | int | 是 | 枚举类型
|
| String | 是 | 补卡日期,格式:yyyy-mm-dd |
| String | 是 | 补卡时间 格式:HH:mm |
isNextDay | Boolean | 否 | 补卡时间是否为补卡日期的次日,默认为否 1:是 2:否 |
| String | 否 | 补卡类型 1:个人原因 2:公司原因 3:外出补卡 4:出差补卡 5:加班补卡 |
| Integer | 是 | 上班卡/下班卡: 1:上班卡 2:下班卡 |
reason | String | 否 | 补卡原因,最长200个字符 |
thirdPartyId | String | 是 | 补卡的唯一标识,最大长度 32 位 |
响应体 Response Body
字段 | 类型 | 描述 |
code | String | 返回结果的状态码 |
msg | String | 返回结果的状态信息 |
data | Json |
【接口验证内容】
错误校验 | 校验内容 | 提示信息 |
必填校验 | 必填字段是否校验 | 请求失败,XXX必填字段内容缺失 |
员工 | 是否存在 | 请求失败,员工不存在 |
补卡日期 | 员工在补卡日期没有出勤规则 | 请求失败,员工在补卡日期无出勤规则。 |
员工补卡日期所在考勤组未开启允许补卡 | 请求失败,员工所在考勤组不允许补卡。 | |
员工补卡日期的考勤状态不允许补卡 | 请求失败,补卡日期的考勤状态为{员工考勤日期所属考勤组补卡设置的类型}时允许补卡。 | |
补卡时间晚于当前时间 | 请求失败,不可提交未来时间的补卡记录。 |
【展示优化】
考勤组补卡设置中,补卡类型、补卡次数限制、补卡申请时间限制、补卡撤销时间限制规则增加info提示:仅员工发起的申请受此限制,接口写入补卡记录时不受限制。

补卡记录中,接口写入的【查看流程】不可点击,增加提示:接口写入的记录无审批流程

审批
升级内容 1:信息采集(新模版)支持按申请人所属管理范围找人
业务场景&问题:
旧信息采集模板升级至新审批后,无法按申请人所属管理范围自动匹配审批人,导致客户迁移受阻。

解决方案:
功能入口:设置 > 审批设置 > 审批流程设计 > 审批节点 > 指定角色
功能说明:开启“根据申请人所属管理范围匹配审批人”后,系统将自动查找对应审批人。
功能截图:见上方图片
特殊逻辑:仅适用于“信息采集”类模版且使用新审批平台的客户;历史数据兼容,无需开关控制。
IM
升级内容 1:IM同步字段名变更后同步失败时,支持手动刷新
业务场景&问题:
IM中开启员工同步并且设置字段映射规则后,由于系统内字段名称变更或者飞书通讯录中字段变更可能(非绝对)导致字段同步失败。
场景说明:
-系统字段:岗位EN
-初始同步关系:岗位EN(业务) - 岗位EN(飞书) →成功
-修改业务字段:岗位EN → 岗位*
-当前实际同步关系:
后端同步:岗位id - 岗位EN(飞书) →成功
前端展示:岗位EN(业务) - 岗位EN(飞书) → ❌
同步结果:正常同步,只是前端展示不一致
-如,同时修改飞书字段:岗位EN → 岗位*
后端同步:岗位id - 岗位EN(飞书) →❌
前端展示:岗位EN(业务) - 岗位EN(飞书) → ❌
同步结果:同步失败
解决方案:
优化系统字段列始终展示为系统内最新结果
针对当前飞书字段label与系统字段不一致时,增加标记tip提醒和支持手动刷新为一致

特殊说明:
不是所有不一致的都要刷新,如果同步没问题可以不用刷新(比如:系统内字段名称变更后,只要飞书通讯录那边未修改,依旧可以正常同步。但刷新成一致就可能导致同步失败,这会儿就需要客户手动去飞书通讯录把原映射字段名称改成和系统内一样才可以同步)
升级内容 2:钉钉企业账号新员工继承后无法登录问题优化
业务场景&问题:
客户企业账号在上一个老员工离职后交接给新员工后,新员工无法建立im绑定关系,导致无法登录。
场景示例:
老员工A → 绑定企业账号 → mobile&& 平台 存生态绑定关系
老员工A离职 -> mobile 解绑→ 平台不解绑 → 员工A离职后,离职原因和离职日期的修改可以被同步
新员工B入职,要使用企业账号123
客户钉钉操作:新员工B企业账号set = 123
系统内绑定生态关系:mobile双写平台的时候报错,原因:123已被A绑定
解决方案:
企业账号在新员工绑定时,根据规则,自动释放原绑定关系。
规则如下:
约束条件:type = 企业账号 && 企业账号id被离职员工绑定
处理顺序:
1.解绑企业账号id原平台绑定关系(A userid && 企业账号 123)
2.set新绑定关系(B→新员工userid)
绩效
升级内容 1:支持评分联动评语必填
业务场景&问题:
评语不是所有情况都需要填写,过高或者过低进行评语必填的限制,来确保有足够的信息给到后续环节
解决方案:
修改点 | 示意图 | 修改逻辑 |
【设置-绩效设置-评价规则】 |
|
|
【设置-绩效设置-绩效等级】 |
|
PS:多个绩效结果时,任意绩效结果等级匹配都会联动总评语必填 |
【绩效-绩效模板-权限】 |
|
|
【绩效-绩效待办】 |
|
|
升级内容 2:支持按照排名生成绩效等级
业务场景&问题:
部分企业绩效按照相对优秀来绩效绩效排名,存在强制分布,希望基于分数排名生成绩效等级
解决方案:




【绩效待办】
【批量异动】、【批量校准】入口增加【按评分排名生成评级】
【按评分排名生成评级】
如果是多绩效结果,仅强制分布的绩效结果支持【按评分排名生成评级】
生成比例
存在多个绩效等级统一管控且没有各自比例时,按组合让用户填写每一个绩效等级的比例,需要确保每个等级的比例加和等于组合比例
如果一个等级仅有一个比例,默认填充对应比例,支持手动修改,比例符合条件即可
支持调整比例或者调整人反算比例,最终校验人数分布一致
可能会多次操作按评分排名,比例默认填充上一次保存内容(按执行人保存)
提示说明:
【将按照总评分排名,为X名 被评估人自动分配总评级。总评分相同时会按入职日期倒序进行排序,请设置各级比例或人数(计算时向下舍去),确认后将覆盖当前等级。】
如果有人没有评分,则不支持确认,hover提示【所有被评估人完成总评分后,方可自动生成评级】
如果是评估环节,点击确认后,增加按排名生成等级列表
展示,姓名、工号、排名、总评分、总评级、变更信息(当前值和初始值不一致展示)、部门(与待办列表展示逻辑一致)、入职日期(与待办列表展示逻辑一致)、操作
列表提示:修改总评分后,请点击【按评分排名生成评级】重新生成
如果是校准环节,需要展示总评级和按排名生成总评级不一致的员工明细,确认后覆盖数据
展示,姓名、工号、排名、总评分、总评级、变更信息、部门(与待办列表展示逻辑一致)、入职日期(与待办列表展示逻辑一致)、操作
输入字段校准原因:默认文案为【按排名校准】,支持手动修改
由于绩效校准环节,存在校准后,校准原因必填的限制
提示文案:如有特殊需要修改,可在确认后通过【调整绩效结果】手动修改
生成逻辑:
按照分布规则,根据绩效等级的排序从高到低进行匹配计算
根据每个等级的比例,按照总评分+入职日期倒序排序,生成对应的等级








