人事
升级内容 1：导入离职及无离职类型时支持发起离职办理流程
业务场景&问题：
导入的离职不支持手动发起离职办理流程
审批中的离职申请未填写离职类型时，无法发起离职办理流程
解决方案：
离职办理列表中，仅当前任职记录允许进行办理，若非当前任职记录时，按钮置灰并提示：历史任职记录不支持发起离职办理
判断是否可以【发起办理流程】的逻辑优化为离职异动记录【有离职审批来源】或者【有离职类型】
自动发起离职办理时，也会按新的规则自动发起符合发起离职办理的离职记录
升级内容 2：“ü” 统一替换成“v”
业务场景&问题：
目前系统内若是 “ü”对应的中文转化成拼音时会使用 “ü” ，但实际键盘是无法打出这个字符的，如：吕；这导致下游应用的时候无法使用，如客户邮箱的创建，IM对接等；
解决方案：
新的人员数据在从汉字转化为拼音时，存储时统一 “ü” 替换成“v”
数据查询时也统一将 “ü” 替换成“v”
升级内容 3：支持以入职日期生成工号
业务场景&问题：
工号规则不支持以入职日期为规则生成
（钉钉支持，所以大多数需求来源都是钉钉智能人事升级/切换客户）
解决方案：
【工号规则】
在前缀和数字位数中间，增加入职日期，单选，选项如下
不启用（默认选择）
年月日（YYYYMMDD）
年月日（YYMMDD）
年月（YYYYMM）
年月（YYMM）
年（YYYY）
年（YY）
并在下方根据格式回显当前日期，例如：20251023
入职日期选择不启用之外的选项，数字位数最大长度变更为10，否则为18
选择了入职日期后，数字仅支持自增，默认勾选【随入职日期重新生成】
提示【跟随入职日期的格式，如果是年，则每年1月1号重新生成，如果是年月，则每月1号重新生成，如果是年月日，则每天重新生成】
不勾选时，数字自增不重新生成
最新工号只读，展示当天的最新工号
组织
升级内容 1：组织架构审批调整发布失败提醒
业务场景&问题：
组织架构审批通过后发布失败没有通知
解决方案：
增加组织架构发布失败的通知：
通知标题：组织架构调整方案发布失败，请及时处理
通知内容：以下方案发布失败，请到组织架构调整页面修复方案或重新发布
XXX(发布失败的调整方案名称)
XXX(发布失败的调整方案名称)
按钮：去处理（PC端直接打开链接）
链接详情：跳转至组织架构调整列表，并定位到方案状态：发布失败
移动端访问时，会提示请通过PC端打开链接，并支持复制PC端链接
被通知人：方案创建人（创建人已离职后不再进行通知），若方案已转交给其他人，则不再给创建人发消息，需给被转交人发
通知时机：
审批通过后方案发布失败时，会立即通知当前发布失败的方案
每天10点，按通知人聚合所有当前还是发布失败状态的方案
注意：仅会查询最近7个自然日内发布的的组织架构调整方案
薪酬
升级内容 1：参保月报可直接编辑不依赖于导入
业务场景&问题：
参保月报只能导入修改，不能直接编辑
解决方案：
参保月报列表右侧操作增加直接修改参保月报的能力，按钮名称为【编辑】
单行数据点击【编辑】后打开抽屉，支持直接修改社保及公积金数据
字段顺序与列表中社保和公积金相关的字段保持一致，不含补缴的字段
字段展示以员工的月报数据对应的参保方案中是否有社保参保和公积金缴纳进行展示，即如果员工不缴纳公积金时，则不展示【公积金月报相关字段】，抽屉中需展示原数据
编辑时默认保留原来的值，可以仅修改1个数值，也可以填0，但不允许清空，若清空的数据则提示：请填写数据
小数点的处理保留跟参保月报和补缴的逻辑一致，逻辑为：1位小数和2位小数时，默认显示2位；3位小数和4位小数时，默认显示4位；超过位数时会报错提示：小数位不能超过4位
编辑按钮需跟【参保月报-编辑】权限对应，有权限才显示列表和顶部的编辑按钮
归档后不允许编辑，编辑按钮需置灰，提示：已归档无法编辑
批量操作按钮调整到页面上方【归档、取消归档、编辑、补缴】
以上按钮在更新参保月报时均不可以操作
批量编辑时如果没有任何数据可以编辑，需提示：选择的员工参保月报数据均已归档，无法编辑
点击批量【编辑】时，打开批量编辑页面，字段显示所有社保险种子类及公积金项目子类的字段（含个人缴纳、公司缴纳），字段组及字段顺序与参保月报列表一致；如： 养老保险个人、养老保险公司
点击批量编辑时，员工不存在的险种需显示“-”，无法编辑，若特殊情况填写了数值但实际保持时不支持该字段时，则在对应字段上定位阻断导入，报错提示：员工不存在该险种/公积金项目
点击批量编辑时，操作人若因特殊情况，进入批量编辑时有参保方案权限时，但保存时没有参保方案权限时需阻断导入，则在对应社保方案和公积金方案的字段上（有多名员工时，均需要定位上），报错提示为：当前无此参保方案的权限，请在参保方案上配置权限后再操作
页面顶部按钮名称调整，导入功能均在导入内，其中【导入更新账单】名称调整为【导入参保月报】
弹框名称调整为：导入参保月报
请先下载后的文案调整为：参保月报导入模板
下载的文件名称更新为：参保月报导入模板_{下载日期}
注意：编辑与导入参保月报的数据，若数据未归档，操作重新核算参保月报均会更新为系统计算值
升级内容 2：薪酬核算导入支持带数据导入
业务场景&问题：
数据导入的模板中缺少数据，客户还需要再导出数据后粘贴到表格中
解决方案：
【薪酬核算活动-数据准备-子类数据录入】时，批量导入的模板支持选择是否需要导出员工原有数据
模板中会默认有员工姓名，模板中的工号和证件号码则根据导入模式的选择进行展示
涉及的子类数据有：录入社保公积金、录入考勤结果、录入其他薪资项目数据、截止上月个税累计
注意：专项附加扣除累计的数据不支持，此项的数据模板需要到税局下载
算薪数据合并导入，也同步需要支持客户选择是否导出薪酬核算活动中的员工数据
升级内容 3：薪酬核算活动算税与算薪可分开
业务场景&问题：
客户的算薪场景是，有多个业务数据（比如考勤、提成等），各业务数据在统计周期结束时均要进行确认，所以会需要多次算薪。比如15号发工资，1号算上月考勤时先算薪，确认考勤有无问题，提成也是这样，一般需要在最终算薪前把各个业务的薪资先计算无误。
税前算薪的频次和优先级更高，在一个算薪周期内，可能会有多次算薪，一次算税，目前产品会同时进行算薪算税，算税依赖于税友接口，等待时间较久
解决方案：
开通了接口算税的租户，可选择计算全部薪资项目还是只计算税前薪资项目（未开通接口算税不显示）：
计算税前薪资项目：接口算税之后的数据不再进行计算（个税接口相关字段与实发工资）
计算全部薪资项目：和当前计算逻辑一样，全部薪资项目都进行计算
相关页面：
顶部增加“计算税前”：计算全部人员税前薪资项目
列表增加“计算税前”：计算该人员税前薪资项目
详情页增加“计算税前”：计算该人员税前薪资项目
数据对比结果页增加“计算税前”：计算该人员税前薪资项目
调整结果弹窗增加“计算税前”：计算该人员税前薪资项目
升级内容 4：增加定薪调薪停薪导入权限
业务场景&问题：
客户需要对定薪停薪调薪的导入权限做精细控制，有些角色可以查看页面但不能进行导入操作。目前系统没有将导入权限与页面查看权限做分割。
解决方案：
新增权限控制点
发薪人员-导入定薪：控制“导入定薪”按钮的显隐，勾选权限时展示按钮
停薪人员-导入停薪：控制“导入停薪”按钮的显隐，勾选权限时展示按钮
调薪管理-导入调薪：控制“导入调薪”按钮的显隐，勾选权限时展示按钮
IM
升级内容 1：支持一个 People 对接多个企微
业务场景&问题：
支持一个 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 部门&员工的同步范围
注意：若安装的代开发应用时，仅可以绑定员工不能同步员工，也不支持同步部门
2.1三方通讯录应用的初始化
初始化设置与当前相同，设置哪些部门、员工（含字段映射）需同步至该 IM，需要注意：
部门：同步子部门需先同步父部门（即往上一条链路上的父部门），但同步父部门无需同步下面全部子部门
员工：同步员工需先同步其所在的部门
每个IM需独立进行初始化，但同一个部门、员工均可同步至多个 IM。同步至多个 IM 后，该部门或员工会同时出现在多个 IM 中，消息通知待办等在多个 IM 中均会收到
字段映射的初始化时，每个 IM 需配置每个IM的对应的字段映射规则
员工初始化逻辑：
前提条件：同步员工至某个 IM，需先同步员工所在的部门至该 IM，页面有相应提示
可以只绑定不同步，但同步必须得先绑定
支持同一个员工绑定/同步至多个 IM
字段映射：根据字段映射配置，同步时更新 IM 中对应的字段值
后续消费：审批、IM 通知消息、IM 待办、假勤相关数据的同步均依赖员工绑定关系
员工绑定范围的可选项：
全体员工
与同步范围相同：默认选中此项
不绑定：当选择此项时，同步范围仅能选中「不同步」
当选择「与同步范围相同」时，圈选条件同理，仅影响初始化圈圈和新入职员工，初始化后存量员工不再受适用范围影响，管理员可以手动更改绑定、同步状态
注意：绑定范围需大于等于同步范围，目前技术已做相关限制
员工同步范围的可选项：
全体员工：当选择此项时，绑定范围仅能选中「全体员工」或「与同步范围相同」；默认选中此项
指定员工范围：当选择此项时，需配置「适用范围」，适用范围按员工最新的任职信息进行圈选
选择适用范围后，需要回显满足条件的人数，可以点击查看
不同步
注意：
设定范围后，完成初始化后依旧可以在IM对接中对应的企业微信IM上修改设置
无论选择什么范围，规则仅影响初始化首次圈选员工、新入职的员工，不影响完成初始化后已有员工的绑定、同步状态
若初始化后由于员工异动、或组织架构调整、或者调整了绑定、同步范围，导致：已同步的员工不再满足适用范围、或者未同步的员工重新满足适用范围，均不会自动触发取消同步 / 新增同步，绑定同理
2.2代开发应用的初始化
仅支持选择「员工绑定范围」
员工初始化逻辑：
支持同一个员工绑定至多个 IM
后续消费：审批、IM 通知消息、IM 待办、假勤相关数据的同步均依赖员工绑定关系
员工绑定范围：
全体员工：默认选中此项
指定员工范围：当选择此项时，需额外选择「适用范围」
适用范围按员工最新的任职信息进行圈选
选择适用范围后，需要回显满足条件的人数，可以点击查看
不同步
注意：
初始化后存量员工不再受适用范围影响，管理员可以手动更改绑定状态
关于绑定范围的全局逻辑说明：范围设定的哪些员工需要绑定，不是是否绑定；无论选择什么范围，规则仅影响初始化首次圈选员工、新入职的员工，不影响完成初始化后已有员工的绑定状态
若初始化后由于员工异动、或组织架构调整、或者调整了绑定范围，导致：已绑定的员工不再满足适用范围、或者未绑定的员工重新满足适用范围，均不会自动触发取消绑定 / 新增绑定
3、【People 后台】查看/修改每个 IM 同步的部门&员工
如下图：初始化设置完毕后，可以 by 每个 IM 管理同步其的部门、员工
3.1三方通讯录应用
支持查看部门的同步信息，支持修改部门的同步，支持修改IM的根部门
支持重新设置员工同步的【绑定和同步范围】
与初始化相同，需要选择「员工同步范围」和「员工绑定范围」，该两个范围仅会决定新入职的员工是否同步、绑定，修改后不影响已有员工的绑定或同步状态
手动操作取消绑定时，新增支持可选企业微信账号是否保留 / 禁用 / 删除
3.2代开发应用
仅支持查看和管理员工绑定情况，可以修改员工的绑定范围
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同步到people
打卡记录支持 by 每个 IM 进行设置是否需同步，若多个 IM 均开启了同步，且同一个员工同时在多个 IM 中，所有 IM 的打卡记录均会同步至people
若需要在 IM 中发送消息，则根据【消息和待办通知优先级设置】决定是所有 IM 都通知、还是只通知优先级最高的 IM
7、其他说明
安装 People 主应用、打卡应用需要在每个企业微信都安装（若需要），流程与当前一样
审批
升级内容 1：审批退回后重新审批时，支持自动通过
业务场景&问题：
审批退回后，过往审批过的审批人需要重新审批（即使表单内容相对他而言没有任何变化）
解决方案：
审批退回时，退回人可选「退回后，已审批的节点可自动通过」
逻辑说明：
生效条件：同一个节点 && 同一个审批人 && 审批表单内容对比上一次审批人（可见、可编辑）通过无变化
升级内容 2：提示文案过长优化
业务场景&问题：
由于组件长度受限以及早期设置长度约束不合理，导致用户配置内容过长，组件无法完全展示
解决方案：
优化提示文字配置时的默认文案内容：建议20字内，最多50个字
新增填写说明属性，
最多50字
配置后将在表单组件下方展示「填写说明」文案内容，仅编辑态可见
暂时先放开：单行文本、多行文本、数字类型，其他类型后续按需开放
升级内容 3：退回原因摘要字段展示优化
业务场景&问题：
被退回人看不到退回原因，操作退回的人能看到但意义不大
解决方案：
退回原因字段在退回消息中默认都展示
入职
升级内容 1：待入职阶段支持校验重复入职、黑名单
业务场景&问题：
不支持在待入职流程中提示重复入职、黑名单员工
解决方案：
本期支持场景：添加待入职审批、扫码入职
校验规则：
证件
姓名+个人电话
即：优先使用「证件」进行校验，若证件未填写，则使用「姓名+个人电话」进行校验
黑名单校验
添加待入职审批中支持黑名单校验
如果员工的信息和黑名单员工信息相同，则此处报错，不允许提交审批，需将员工移出黑名单后再进行提交
扫码入职列表、详情页，单个、批量进入待入职
黑名单相关操作（加入黑名单、查看黑名单员工、移出黑名单）可查看该文档：
重复入职校验
配置入口：设置-入职设置-入职信息设置-重复入职规则
默认选择不校验，则保持现有逻辑不变
选择「校验后提醒」，则在添加待入职审批、扫码入职处仅做提醒，仍然可以提交
选择「校验后提醒」，则在添加待入职审批、扫码入职处报错提示，阻断提交
电子签
升级内容 1：获取上一份合同协议逻辑优化
业务场景&问题：
上一份合同协议取的是合同子类，导致签署文件无法正确带出上一份合同协议的相关信息，如：上一份法人公司、上一份合同类型等
解决方案：
修改前 | 修改后 |
|
|
试用期
升级内容 1：试用期转正意见支持配置显示选项
业务场景&问题：
不支持针对试用期不同环节设置转正意见的选项的展示 / 隐藏
解决方案：
支持对试用期各环节配置转正意见的显示选项
操作路径：设置-人事设置-试用期设置-考核模板-内容权限
考核表内容中，「转正意见」分组下 新增「转正意见显示选项」
多选
如果环节已开启，则不允许修改考核模板副本的转正意见可选项
绩效
升级内容 1：AI辅助绩效面谈
业务场景&问题：
AI辅助记录面谈内容，并自动生成结构化纪要，帮助面谈者更专注于面谈过程本身
解决方案：
本期支持PC端，移动端下期上线。
入口
结果面谈环节，若配置了「面谈反馈」维度，则此处展示「AI面谈」入口
面谈前准备
点击后，需确保有录音权限，可以点击左下角「测试我的设备」
如果提示麦克风异常，可以查看解决方案，或点击「测试我的设备」进行测试
面谈过程
准备完毕，进入面谈，开启实时录制转写，可在「AI面谈」浮窗中查看实时转写的内容。
浮窗可最小化、可拖动到任意位置。
面谈过程中可以返回到系统其他页面，转写仍会正常进行
可根据需要，点击「暂停」，将会暂停录音与转写
如果关闭网页 / 断网，则会自动暂停，下次进入时可继续面谈
12h自动结束
最大录制时长：90分钟
同一员工的同一个结果面谈环节，仅可进行一次AI面谈
结束面谈
面谈结束，点击「结束」按钮结束面谈，此时可选择立即确认角色还是稍后确认
注意：需确认角色后，才能生成面谈纪要
确认角色后，会根据以下框架生成智能总结
1. 成果与亮点
2. 问题与差距
3. 行动与支持
点击「复制到面谈反馈」，可将智能总结的内容一键粘贴到面谈反馈中，在面谈反馈输入框中，仍可自己做修改。
面谈智能纪要与文字记录的查看
发起AI面谈的人，可在结果面谈页面点击「查看AI面谈总结」查看智能总结与对话记录
绩效活动-被评估人-绩效详情页-面谈记录
花名册-员工详情页-绩效结果-查看绩效详情 -> 面谈记录
权限
CSM后台设置了租户级别的开关，默认关闭，打开后则该租户支持使用AI面谈能力
设置-功能权限-绩效-被评估人：该路径下新增权限点「查看AI面谈总结」、「查看AI转写记录」
控制「绩效活动-被评估人-绩效详情页-面谈记录」页面中的AI智能总结和文字记录的展示
假勤
升级内容 1：加班打卡支持IM提醒
业务场景&问题：
需进行打卡结算的加班申请，在提交申请后，员工会忘记加班时间，导致结算时长不符合预期，后续校准的工作量大。常见于制造业集体加班或非本人提交加班的场景。
解决方案：
新增加班打卡提醒配置，非必填
仅加班结算方式为【申请时段内，按打卡时长结算】或【申请时长和打卡时长取最小值】出现该配置
加班开始提醒：加班申请的开始时间前N分钟提醒
时间范围默认为10分钟，可选择范围为0-60分钟
加班结束提醒：加班申请的结束时间后N分钟提醒
时间范围默认为10分钟，可选择范围为0-60分钟
以审批中和审批通过的加班记录为准，按加班开始-结束时间计算提示时间。
仅当修改规则的时间早于应发提醒的时间才会发送提醒。
可能存在消息挤压导致的延迟发送，若延迟超过5分钟后则不发送提醒
到提醒时间后，将发送打卡提醒，点击查看详情可跳转至打卡页面
升级内容 2：加班申请支持批量添加同一时段加班申请
业务场景&问题：
单个明细组内的加班日期不支持多选，若员工存在连续多天同一时段的加班，则需增加明细组，多次填写加班时间，填写效率较低
解决方案：
审批单设计中，加班日期字段可配置是否允许选择多个日期
仅加班审批模板支持，集体加班暂不支持
默认为仅支持选择1个日期。
允许添加多个日期后，在申请加班时，可一次性选择多个日期
单次最多可选择30个日期
日期选择将校验加班日期的加班规则、日历类型、班次设置是否一致，不一致时将阻断：YYYY-MM-DD、YYYY-MM-DD的加班规则/班次不同，需额外添加加班申请
选择的日期中，任意一个日期不满足提交时间限制时，将阻断提示：{工作日/公休日/节假日}加班最晚于{加班开始前/加班开始后N天内提交}
校验逻辑：
选择的开始/结束时间需在可统一申请加班的时间范围内
可统一申请加班的时间范围的具体逻辑：
若加班日当天和次日的日历类型不同的情况下，优先以次日为工作日的加班日期的有效加班时间记为统一申请加班的时间范围。
若加班日当天和次日的日历类型相同，或不存在次日为工作日的加班日期时，则每一天的有效加班时间范围一致，以第一个日期对应的有效加班时间记为统一申请加班的时间范围
若实际当天有效时间时间范围小于统一计算出的可申请时间范围，那么在申请时不阻断，在实际结算时将按实际有效加班时间范围结算。建议如果存在跨日历类型的加班时，可以拆分明细组进行提交。
例如员工周四的可加班时间范围为当天18:00-次日9:00，周五的可加班时间范围为当天18:00-次日00:00。员工申请周四、周五当天18：00-次日1:00的加班时，可正常提交，不会阻断，在实际结算时，周五的加班将仅结算当天18:00-次日00:00内的加班时长。
若填写的加班申请与其他明细组内或审批中/审批通过的加班申请重复时，则不允许提交
需校验加班风险预警，提示文案优化为：YYYY-MM-DD、...、YYYY-MM-DD「加班当天/加班当周/加班当月/加班当前考勤周期/加班所属季度」{加班类型}加班不可超过M小时，你已加班N小时」
选择日期和时间后会计算得出申请时长和申请时长和（预）结算时长，点击「加班明细」可查看每一天的申请时长和结算时长。点击「结算明细」可查看每一天详细的结算说明。
结算时长和结算明细，均为异步计算。因此，提交申请时，表单中及明细行中的申请时长和申请时长和（预）结算时长为申请首日的申请时长/结算时长*申请天数。提交申请后，审批中查看加班明细中的结算时长为按实际规则结算出的时长。
提交后，将按明细表中的加班日期对应生成多条加班记录，即一个明细组对应多条加班记录。
审批默认摘要中的加班日期，将取表单内最早~最晚的日期进行展示
审批通过后撤销、通过后修改，均需校验是否满足撤销或修改时间限制，所有明细表中的所有加班日期中任意一天不满足时间限制，则均不允许撤销或修改
修改时将校验是否满足加班申请时间范围，申请时长和结算时长也将自动更新
修改时若删除明细组后审批通过，则明细组内对应日期的加班记录状态均变为已撤销。同理，修改时增加明细组后审批通过，则明细组内对应日期的加班记录状态均变为已通过
升级内容 3：「根据家庭成员生日」发假时，按月折算逻辑优化
业务场景&问题：
当前「根据家庭成员生日」发假是，按月折算时，仅判断了被折算月满足条件的天数，是否大于等于配置天数，未判断是否满足一个月，导致当配置为31天时，2、4、6、9、11月一定会被折算，会导致发假数量不符合预期
解决方案：
当周期开始时间为「每年家庭成员生日」，且根据家庭成员生日时。特殊情况无论配置的是什么，均不折算。因为该配置下满足条件的天数/月份一定是满一年的
其他情况下，特殊情况、新员工入职折算、员工离职折算配置为按照当期满足条件的【月数】折算，不满一月的部分，若大于等于【N天】按一个月计算时
先判断需折算的月份（子女生日月、入职月、离职月）满足条件的天数是否满一整个月，不满足时再判断是否大于等于配置天数。
例如周期开始日期是每年1月1日，入职时发假。子女3周岁前每个周期享受5天假期。特殊情况、新员工入职、员工离职折算配置均为按月折算，不满足一个月的部分大于等于31天时按一个月计算。
员工子女生日为2022-02-01，员工2022年6月1日入职，申请2023年9月30日离职。
特殊情况折算的结果：该员工在2022周年内，2022-02为子女生日月，2月满足条件的天数为28天，已满一个月，因此2月不会被折算，2022周年发假天数应为11/12*5=4.6天
新员工入职折算的结果：该员工在2022周年内，2022-06为入职月，6月满足条件的天数为30天，已满一个月，因此6月将不会被折算，2022周年发假天数应为6/12*5=2.5天
员工离职折算的结果：该员工在2023周年内，2023-09为离职月，9月满足条件的天数为30天，已满一个月，因此9月将不会被折算，2023周年发假天数应为9/12*5=3.8天
折算结果不同时取发假数量的最小值——原逻辑，因此员工入职时2022周年的发假数量为2.5天，2023周年的发假数量为3.8天
通用
升级内容 1：邮件内容支持翻译
业务场景&问题：
邮件通知很多 HTML 消息，会有很多标签导致超长，会超过 AI 翻译的字符数上限导致超时，故当前 HTML 邮件消息未兼容多语言
解决方案：
翻译解析支持HTML 邮件消息
