人事
升级内容 1:单People支持添加黑名单
业务场景&问题:
● 单People租户不支持添加黑名单
● 拉黑ATS员工存在问题,也无法只在people侧拉黑员工
解决方案:
1. 一体化租户——花名册添加黑名单时新增「拉黑 ATS 候选人」选项
● 默认选择「是」:系统会尝试将员工同步加入 ATS 候选人黑名单,用于招聘环节和待入职环节拦截。
● 选择「否」:仅加入 People 黑名单,用于待入职环节拦截。
● 管理员可以按实际业务需要选择是否同步 ATS。
flowchart TD
A["花名册添加黑名单"] --> B{"是否拉黑 ATS 候选人"}
B -->|是| C["匹配或创建 ATS 候选人"]
C --> D["加入 ATS 候选人黑名单"]
D --> E["招聘环节 + 待入职环节拦截"]
B -->|否| F["仅加入 People 黑名单"]
F --> G["待入职环节拦截"]
1. 导入黑名单
● 导入黑名单时也增加「拉黑 ATS 候选人」选项。
● 选择「是」时,本次导入的人员会按规则同步处理 ATS 候选人黑名单。
● 选择「否」时,本次导入仅写入 People 黑名单。
1. 单 People 租户不再依赖 ATS 候选人映射
● 对于单 People 租户,添加黑名单不再因为没有 ATS 候选人映射而失败。
● 只要满足 People 黑名单所需的基础校验,即可完成拉黑。
2. 个人邮箱校验更符合实际场景
● 当选择不拉黑 ATS 候选人时,主要校验个人电话。
● 若个人电话未填写,提示补充个人电话。
● 若个人电话已填写,即使个人邮箱为空,也可以完成 People 侧拉黑。
● 当选择拉黑 ATS 候选人时,仍按 ATS 候选人黑名单逻辑进行校验和同步。
3. 入职环节消费黑名单校验
● 添加待入职审批表单:字段失焦时提醒,提交时拦截。
● 扫码入职详情页:字段红色提醒,「进入待入职」按钮置灰。
● 扫码入职列表:增加提示图标,鼠标悬停展示原因。
● 单个进入待入职:命中黑名单时按钮置灰。
● 批量进入待入职:批量操作时统一拦截。
● 招聘端发起入职表单:字段失焦提醒,点击确认发起时拦截。
升级内容 2:信息健康度支持单次更新
业务场景&问题:
● 当前信息健康度更偏向周期性更新,适合按固定频率提醒员工补充或更新信息。
● 但在实际使用中,HR 经常会遇到一次性采集场景,例如临时要求一批员工更新证件、手机号、住址、紧急联系人等信息。
解决方案:
1. 信息健康度规则新增「单次更新」
○ 管理员创建信息健康度规则时,触发频率支持选择「单次更新」。
○ 选择「单次更新」后,发送时间默认为立即发送,不支持编辑。
○ 选择「周期性更新」时,仍保持原有周期配置能力。
○ 历史更新类规则默认按「周期性更新」展示,不影响已有规则。
flowchart LR
A["创建信息健康度规则"] --> B{"触发频率"}
B --> C["单次更新"]
B --> D["周期性更新"]
C --> E["保存后立即发送待办"]
D --> F["按原周期配置发送"]
2. 单次更新支持设置截止日期
○ 规则中新增截止日期配置。
○ 员工在截止日期前完成提交后,即完成本次采集。
○ 如果配置了审批,则审批通过后视为采集完成。
○ 截止日期当天 24 点后,未完成的待办会被删除。
3. 单次更新发起后的规则编辑范围更清晰
○ 已生成采集任务后,以下字段不可编辑:适用范围、采集方式、采集频率、发送时间。
○ 以下字段仍可编辑:规则名称、是否自动发起采集、截止日期、是否需要审批、管理员。
○ 若规则已截止,将截止日期修改为未来时间后,系统会重新给仍处于采集中的员工发送待办。
4. 信息健康度卡片增加单次更新相关展示
○ 卡片展示规则内人数、采集字段、适用范围。
○ 单次更新规则额外展示截止日期。
○ 已开启状态下支持查看详情、催办、修改截止日期。
○ 已截止状态下支持查看详情、修改截止日期。
升级内容 3:试用期管理列表优化
业务场景&问题:
● 试用期员工数量较多时,HR 或 SSC 很难在列表中快速判断每个人当前处于哪个考核环节。
● 当前如果想看某个员工的轮次、执行人、环节进度,往往需要进入详情页逐个查看。
● 客户希望试用期管理像绩效活动一样,能在列表中更清晰地查看流程进度。
● 对于停留时间较长的环节,管理员希望可以筛选出来,便于催办和排查流程卡点。
解决方案:
1. 自定义列支持更多试用期字段
○ 新增「环节开启时间」:展示当前进行中环节开始执行的时间。
○ 新增「环节停留时长」:展示当前环节已停留天数,例如 5 天。
○ 新增「进行中轮次」:展示员工当前有几个进行中的考核轮次。
○ 新增「当前审批人」:展示当前转正审批节点的审批人。
○ 环节开启时间、环节停留时长、进行中轮次、花名支持排序;当前审批人不支持排序。
○ 新增「花名」:支持在姓名+花名模式下展示和搜索员工花名。
2. 筛选能力增强
○ 新增当前执行人筛选。
○ 新增环节开启时间筛选。
○ 新增环节停留时长筛选。
○ 新增进行中轮次筛选。
○ 审批状态新增「未提交」选项。
○ 搜索支持按花名模糊搜索。
3. 审批状态展示优化
○ 列表中原本为空的审批状态,统一展示为「未提交」灰色标签。
○ 「未提交」表示尚未提交转正审批,因此不支持点击穿透查看审批。
4. 新租户试用期列表默认字段更贴近管理场景
○ 默认字段包括姓名、工号、部门、职务、试用截止日期、转正方案、当前轮次、当前环节、当前执行人、考核状态、最终评级、最终评分、转正意见、审批状态、转正日期。
○ 如果租户开启电子签能力,再展示考核结果签署、目标确认签署相关字段。
升级内容 4:项目组导入“上级项目组”格式优化
业务场景&问题:
● 当前项目组导入模板中,添加根节点项目组时,上级项目组需要填写 /。
● 添加非根节点项目组时,上级项目组需要填写 /根节点/一级项目组/...。
● 该格式不符合用户直觉,用户容易漏填或多填 /,导致导入失败。
● 用户更习惯用 根节点/一级项目组/... 表示项目组路径。
解决方案:
1. 根节点项目组支持上级项目组置空
● 添加根节点项目组时,上级项目组可以直接置空。
● 旧格式 / 仍然兼容,可以继续识别为根节点。
2. 非根节点项目组支持自然路径格式
● 添加非根节点项目组时,上级项目组支持填写 根节点/一级项目组/...。
● 旧格式 /根节点/一级项目组/... 仍然兼容。
flowchart TD
A["填写上级项目组"] --> B{"填写内容"}
B -->|置空| C["识别为根节点"]
B -->|/| D["兼容旧格式,识别为根节点"]
B -->|"Moka/人事"| E["按新格式匹配父级"]
B -->|"/Moka/人事"| F["兼容旧格式匹配父级"]
C --> G["导入成功"]
D --> G
E --> G
F --> G
3. 导入模板说明更新
● 根节点项目组:上级项目组请置空。
● 非根节点项目组:上级项目组请填写 根节点/一级项目组/...。
● 示例:Moka/人事。
4. 错误提示更明确
● 当上级项目组不存在时,提示正确填写格式和示例。
● 提示中说明添加根节点项目组时可置空,帮助用户快速修正文件。
升级内容 5:导入编制取消计划编制数大于等于每月明细编制的限制
业务场景&问题:
● 部分客户的编制管理是动态的,例如暑假、旺季、项目高峰期编制数较大,年底或淡季编制数较小。
● 当前导入编制时,系统强制要求计划编制数大于或等于每月明细编制数。
● 当客户需要导入较小的计划编制数时,系统会阻断导入,HR 只能逐条手动调整,耗时较长。
● 添加或变更编制审批中类似场景只是提醒,不阻断提交;导入场景过于严格。
解决方案:
1. 编制导入取消大小关系强校验
● 导入时不再校验「计划编制数必须大于或等于每月明细编制数」。
● 允许计划编制数小于某月明细编制数时正常导入。
● 系统仍保留基础数据校验。
2. 保留必要基础校验
● 文件格式错误仍会提示错误。
● 必填字段仍需填写。
● 编制数仍需为数字。
● 编制数不能为负数。
3. 导入模板说明需同步调整
● 模板中不应继续提示计划编制数必须大于或等于明细编制数。
● 避免用户仍按旧规则理解导入限制。
升级内容 6:职务接口支持返回适用部门信息
业务场景&问题:
● 客户使用职务模式,且职务会关联适用部门。
● 下游系统需要通过接口获取职务下的部门信息,用于账号、权限、组织同步等场景。
● 当前职务接口不返回部门字段,下游系统需要额外调用部门接口并自行匹配,开发成本较高,也容易产生数据不一致。
解决方案:
1. 职务查询接口新增适用部门信息
● 职务接口返回数据中新增适用部门列表。
● 支持返回部门 ID、部门名称、部门编码、部门状态。
● 若职务未关联部门,则部门信息返回为空。
● 若职务关联多个部门,则以列表形式返回。
2. 对外接口设置支持勾选「适用部门」
● 在对外接口设置中,数据源选择「职务信息」时,新增字段「适用部门」。
● 勾选后,接口返回结果中包含适用部门列表。
● 不勾选时,不影响原有接口返回内容。
3. 对已有接口调用保持兼容
● 本次为新增字段,不删除或修改原有字段。
● 已对接客户如果不使用该字段,可以保持现有逻辑不变。
绩效
升级内容 1:目标地图增加组织目标展示&员工可对齐组织目标
业务场景&问题:
整新增了组织绩效的功能但是还未支持组织目标在地图中展示,用户无法看到组织目标的整体情况,员工目标无法对齐组织目标,导致管理断层。
解决方案:
在目标地图中增加组织目标的展示,员工目标支持对齐组织目标,在目标地图中可展开对齐的组织目标。
该功能需要开启组织绩效的白名单(有组织绩效功能则可以使用该功能,需要联系请联系客户成功经理或者是支持同学)
详细功能:
【绩效-目标地图】
● 顶部筛选项增加了‘我负责组织的目标’,点击后可下拉选择我作为组织绩效活动中的组织负责人的组织,选择组织后展示该组织的组织目标。
● 地图中向左可展示当前目标对齐的员工目标和组织目标,向右可展开对齐当前目标的员工目标和组织目标。
● 组织目标可见性同样受组织绩效活动中可见范围的控制,不在可见范围中将无法看到和对齐组织目标。
● 在其他目标中可搜索部门目标和项目组目标,按名称搜索数据权限范围内的部门名称、项目组名称。
【绩效-绩效模板-内容权限】
在目标制定内容权限-参考信息中,可开启执行人对齐组织目标,可选择对齐部门目标、项目组目标,开关默认关闭。
【绩效-绩效待办-目标制定】
● 模板中开启了权限后目标制定时参考目标中可选择对齐目标类型为部门目标、项目目标,可选择参考对象和周期查看对应的目标。
● 模板中开启了权限后目标制定时点击对齐目标可在浮窗中选择部门目标、项目组目标,搜索部门名称、项目组名称后可对齐对应组织下的目标。
升级内容 2:员工绩效模板增加KR删除权限
业务场景&问题:
目前绩效模板中有移除已有目标权限点,但存在BUG,导致用户未勾选配置后员工仍然能删除已有目标,权限控制未实际生效。同时目前配置中只支持控制删除已有目标,不支持单独控制删除已有KR,导致实际用户在使用中无法很好的控制权限,用户希望能够允许员工删除KR但不能删除O。
解决方案:
修复删除O权限未生效的BUG,并新增删除KR权限点控制。
详细功能:
【绩效-员工绩效模板-内容权限】
● 对于OKR型的目标制定环节的内容权限中,修复了未勾选‘移除已有目标’权限点时员工侧的已有目标将不展示删除按钮。
● 新增了‘移除已有目标的关键结果’权限,默认与原‘移除已有目标’权限勾选状态一致,新建模板时默认不勾选。
● 若勾选了‘移除已有目标’则会默认勾选‘移除已有目标的关键结果’不可取消。
● 同时勾选时员工将能删除O与KR,只勾选‘移除已有目标的关键结果’、不勾选‘移除已有目标’时员工将只能删除KR,都不勾选时员工不能删除O与KR。
【Breaking Change】
此次修复了未勾选‘移除已有目标’权限点时员工侧的已有目标将不展示删除按钮。而原有BUG存在的情况下客户的员工可能习惯了能够自行删除O与KR,修复后对于未勾选‘移除已有目标’权限点的客户的员工将无法自行删除O与KR,若客户有诉求允许员工自行删除,则需提前对模板以及现有活动中的镜像模板中的‘移除已有目标’权限点进行勾选,以免造成客户误解为系统出错。
升级内容 3:OKR支持按权重根据KR进度自动更新O进度
业务场景&问题:
对于定量的OKR目标O的进度实际是根据各个KR进度按权重计算,但是目前员工需要分别手动填KR的进度和O的进度,操作比较繁琐,希望能根据KR的进度和权重自动计算O的进度。
解决方案:
在目标制定和目标跟进的时候对于OKR类目标增加更新方式配置点,对于自动更新的O根据KR权重和进度自动计算O的进度。
详细功能:
【绩效-绩效待办-目标制定】
● 对于OKR类目标在制定时在O行支持选择更新方式,默认手动更新,可切换为自动更新。
【绩效-目标更近-更新进展】
● 对于OKR类目标在目标跟进更新O的进展的时候可以修改更新方式,对于自动更新的O的进度会置灰不可填写。
● 对于自动更新的O会根据KR更新的进度和权重自动更新O的进度。
升级内容 4:按指标评估空维度无权重自动忽略
业务场景&问题:
对于按指标评估的活动若有多个被评估维度,若其中一个维度未创建任何指标、权重、被评估人,而配置了参与最终结果计算,那么在按指标评估环节会卡住,提示执行人为空,最终导致无法计算出绩效结果。
解决方案:
按指标评估时对于未填写的指标自动忽略,不提示执行人为空,计算时能正常计算。
详细功能:
【绩效-员工绩效活动-按指标评估环节】
● 按指标评估时对于未填写的指标自动忽略,不提示执行人为空,计算时按已有指标的权重正常计算。
图中为升级前情况,升级后不会提示执行人为空。
升级内容 5:评估组列表按数据权限过滤展示
业务场景&问题:
对于一个绩效活动下有数十个评估组的租户来说不同的BP只负责其中几个评估组的人员,但是在评估组列表中能看到所有评估组的信息,即便其中的人员信息通过数据权限过滤了,但评估组本身仍保留展示了,导致BP想寻找自己负责的评估组的人员时非常困难。
解决方案:
根据用户数据权限过滤无对应管理人员的评估组,在列表中不展示。
详细功能:
【绩效-员工绩效活动-评估组列表】
● 在评估组列表中,若用户对一个评估组下所有被评估人都无数据权限则不展示该评估组。
升级内容 6:新增提交后是否可撤回的权限点控制
业务场景&问题:
当前绩效模板中各个环节均未控制撤回权限,默认执行人均可撤回,导致进入后续流程后执行人又撤回流程,影响流程进度。
解决方案:
对每个有撤回操作的环节都增加允许提交后撤回的权限点控制,默认开启,租户可自行关闭权限控制执行人无法撤回。
详细功能:
【绩效-组织绩效模板-流程配置】
● 在各个环节的环节设置中增加了‘允许提交后撤回’的权限点,默认勾选,历史模板均默认勾选,与现有配置一致,配置时可取消勾选,取消勾选后在对应活动中执行人在待办中无撤回按钮。
● 目前支持控制撤回权限的环节有:目标制定、目标审核、单人评估、多人评估、确认360邀请、结果面谈、校准环节。
● 特殊的,对于目标制定环节,原有‘允许审核通过后撤回’权限点,此权限点现作为‘允许提交后撤回’的子权限点,即:勾选‘允许提交后撤回’才可选择是否勾选‘允许审核通过后撤回’;勾选了‘允许审核通过后撤回’就不可取消勾选‘允许提交后撤回’。
● 对于目标制定环节,均不勾选代表执行人提交后无法撤回;勾选‘允许提交后撤回’不勾选‘允许审核通过后撤回’代表执行人提交后在目标审核中时可撤回,审核通过后不可撤回;均勾选代表执行人在审核通过后仍可撤回;
BI
升级内容 1:公式支持计算工作日天数
业务场景&问题:
目前自定义字段公式配置中只支持时间差-天day_diff()的公式,在需要统计距离某日期还剩多少工作日时无法支撑统计,所以需要增加支持计算剩余多少工作日。
解决方案:
增加时间差-工作日workday_diff()计算公式。
详细功能:
【报表-增加自定义字段】
● 增加时间差-工作日workday_diff()计算公式,可计算括号中两个字段的工作日时间差,单位为天。
● 目前仅支持2007年及以后的日期进行工作日时间差计算。
● 目前暂不支持海外和 tc数仓服务对应的租户计算工作日时间差。
假勤
升级内容 1:支持在假期账户明细中编辑发假记录
业务场景&问题:
● HR需要变更员工的发假记录时,不能直接在假期账户中的发假记录中直接进行编辑和撤销操作,必须到发假明细列表中找到对应的发假记录再进行编辑和撤销,操作路径较长且不符合使用习惯,
解决方案:
● 管理端假期账户-当前余额-发假记录列表增加操作列,包括编辑、撤销和变更记录
○ 编辑、撤销按钮的弹窗和操作逻辑均和发假明细操作列的逻辑保持一致
■ 编辑权限受「假勤-发假明细-编辑」功能权限控制
■ 撤销权限受「假勤-发假明细-撤销」功能权限控制
○ 变更记录的查看权限与发假明细操作列的变更记录查看的功能权限和数据权限的控制逻辑一致
○
薪酬
升级内容 1:税友升级同步
1. 个税申报接口优化
a. 升级之前:针对“任职受雇从业类型不是其他”的“居民身份证类型”的人员来说,符合填写收入条件的就必须填写对应收入,即便没有发放收入,也必须填写一条0收入
b. 升级后:“任职受雇从业类型不是其他”的“居民身份证类型”的已离职人员【即:填写的离职日期小于申报税款所属期,是否离职后补发工资填写为是,补发税款所属月份填写为申报的税款所属期】,补发收入的场景来说,不强制要求必须填写正常工资薪金所得/证券经纪人佣金收入/保险营销员佣金收入/其他连续劳务报酬对应的0收入记录了,不阻断申报。
c. 例如,已离职的雇员,后续只补发全年一次性奖金或者解除劳动合同离职补偿金,不存在补发正常工资薪金所得时,不强制要求填写正常工资薪金所得必须填写0收入了,只需要直接填写全年一次性奖金或者解除劳动合同离职补偿金即可进行申报了。
2. 【人员报送】“补发税款所属月份”变更为“实际补发工资的月份”
a. “实际补发工资的月份”仅支持录入系统当前时间所在月份、(系统当前时间-1)月份。不能小于等于离职日期所在月份。
b.
审批
升级内容 1:审批抄送节点支持同步到飞书「抄送我的」
业务场景&问题:
● 过去抄送节点只触发消息应用通知,不会同步到飞书OA审批-抄送我的 分组下。本次支持
解决方案:
注意:钉钉和企微均由于openAPI接口能力限制无法支持该场景
OpenAPI
升级内容 1:增加参保月报查询接口
业务场景&问题:
● 客户通过第三方系统管理参保月报,但当前参保月报未提供查询接口,导致客户业务受阻
解决方案:
接口说明:通过此接口,可以查询指定年月的参保月报数据,包含参保人数、费用合计、字段说明和明细列表。
基本信息
请求地址:https://api.mokahr.com/api-platform/hcm/oapi/v1/salary/social/month-report/search
请求频率:20次/秒/企业,1200次/分钟/企业
请求方式:POST
请求头 Header
字段 | 必填 | 类型 | 描述 |
Authorization | 是 | Basic | 略,"鉴权验证说明"部分已经明确说明 |
请求参数 Query Param
字段 | 必填 | 类型 | 描述 |
entCode | 是 | String | 租户的唯一ID;由CSM(客户成功经理)提供 |
apiCode | 是 | String | 租户配置的api应用对应的唯一ID 是Moka People系统"设置" - "对外接口设置"的【接口编码】字段,数据源=【参保月报查询接口】 |
nonce | 是 | String | 每次请求的随机字符串,由客户自己随机生成;长度不超过8位,由数字和不区分大小写的英文字母构成 |
timestamp | 是 | Long | 时间戳;精确到毫秒 |
sign | 是 | String | 在"验签说明"里有详细说明,https://people.mokahr.com/docs/api/view/v1.html#-6 |
请求体 Request Body
字段 | 必填 | 类型 | 描述 |
year | 是 | int | 查询年份 |
month | 是 | int | 查询月份,取值范围1-12 |
pageNum | 是 | int | 页码,从1开始 |
pageSize | 是 | int | 分页大小,不超过200 |
响应体 Response Body
字段 | 类型 | 描述 | 备注 |
code | String | 返回结果的状态码 |
|
msg | String | 返回结果的状态信息 |
|
data | Json | 见下面data |
|
返回结果data说明
字段 | 类型 | 描述 | 备注 |
pageNum | int | 当前页码 |
|
pageSize | int | 分页大小 |
|
total | Long | 总条数 |
|
pages | int | 总页数 |
|
insuredEmployeeCount | int | 参保人数 |
|
totalAmount | String | 总合计(元) |
|
insuranceIndividualTotal | String | 个人社保合计(元) |
|
insuranceCompanyTotal | String | 公司社保合计(元) |
|
fundIndividualTotal | String | 个人公积金合计(元) |
|
fundCompanyTotal | String | 公司公积金合计(元) |
|
tableTailValue | Json | 动态列合计,key为字段标识,value为合计值 |
|
labelList | JsonArray | 字段说明,详情见下面labelList |
|
list | JsonArray | 参保月报明细列表;明细字段为动态字段,具体字段以labelList返回为准 |
|
data.labelList 字段说明
字段 | 类型 | 描述 | 备注 |
dataIndex | String | 字段key |
|
title | String | 字段名称 |
|
notSuffix | boolean | 是否不要后缀 |
|
children | JsonArray | 子字段,结构同labelList项 |
|
data.list 字段说明
参保月报明细列表按字段key返回,字段集合存在租户差异,建议根据labelList展示字段名称。
字段 | 类型 | 描述 | 备注 |
employeeId | Long | 员工ID |
|
employeeName | String | 员工姓名 |
|
employeeNo | String | 员工工号 |
|
insuranceIndividualTotal | String | 个人社保合计(元) |
|
insuranceCompanyTotal | String | 公司社保合计(元) |
|
fundIndividualTotal | String | 个人公积金合计(元) |
|
fundCompanyTotal | String | 公司公积金合计(元) |
|
totalAmount | String | 总合计(元) |
|
… |
| … | 其他动态字段 |


