人事
升级内容 1：工号支持大小写去重
业务场景&问题：
● HR 在 People 侧新增、编辑或导入员工工号时，如果系统把 A001 和 a001 当成两个不同工号，同一租户内就可能出现大小写仅不同的重复工号。
● 入职确认环节也会填写待入职员工工号。如果待入职员工工号与在职、离职员工仅大小写不同，旧逻辑可能出现漏拦截，导致入职确认和 People 侧规则不一致。
● 外部系统通过 OpenAPI 创建、更新或校验员工工号时，也需要和内部业务链路使用同一套判重规则，否则容易造成上下游工号不一致。
解决方案：
1. 工号判重统一改为大小写不敏感
● 工号在写入、查询、重复校验、批量导入、OpenAPI 写入等链路中统一按大小写不敏感规则判断。
● 系统会基于去除首尾空格并统一大小写后的值做判重；只要标准化后的工号相同，就视为同一个工号。
● 页面展示、导出和提示文案仍保留用户原始输入的工号，不强制把用户看到的工号改成小写。
● 编辑员工工号时，会排除当前员工自身，避免把“自己原本的工号”误判为重复。
2. People、入职确认、OpenAPI 使用同一口径
● People 侧员工工号新增、编辑、导入、查询和搜索统一使用标准化工号做校验与命中。
● 入职确认前会对待入职工号做同样的标准化处理，再与待入职、在职、离职员工工号统一判重。
● OpenAPI 的批量创建、批量更新和重复查询会复用同一套规则。同批次内如果出现 A001 / a001这类大小写不同但标准化后相同的工号，会被识别为重复并返回明确原因。
升级内容2：项目组人力明细列表支持展示项目组编号
业务场景&问题：
● 企业使用项目组管理人力时，项目组名称可能相似、重名，或随着项目阶段变更名称。
● HR、项目负责人和财务在核对员工人力明细时，单看项目组名称不一定能快速确认是哪一个项目组。
● 项目组本身已有编号，但旧版项目组人力明细列表未提供该字段，用户需要跳转到项目组资料或导出后再核对。
解决方案：
1. 自定义列新增“项目组编号”
● 在“员工人力明细-项目组人力明细”列表的自定义列中新增“项目组编号”字段。
● 用户可按需勾选展示该字段。
● 字段取值为项目组资料中的项目组编号。
组织
升级内容 1：职务新增、变更、查询接口支持所属部门
业务场景&问题：
● 部分客户的组织管理逻辑要求先有部门，再有岗位或职务；岗位/职务需要与部门关联，外部系统也需要识别这层关系。
● 在职务模式下，如果接口无法写入或返回职务适用部门，外部系统只能拿到职务本身，无法判断该职务适用于哪些部门。
● 这会影响组织主数据同步、外部组织树校验、岗位体系联动等场景。
解决方案：
1. 职务查询接口支持返回适用部门
● OpenAPI 职务查询接口支持在返回参数配置中勾选部门适用范围。
● 勾选后返回 departmentList，包含部门 ID、名称、编码、启停状态等展示信息。
● 未勾选时不返回该字段，保持接口返回的按需口径。
2. 职务新增/变更接口支持写入适用部门
● OpenAPI 新增职务、变更职务接口支持写入职务适用部门。
● 请求中只需传部门 ID 或部门编码，系统会校验部门并补齐名称、状态后写入组织模型。
● 职务可关联多个适用部门；未关联部门时返回空值。
3. 职位接口按现有模型兼容
● 职位仍按组织现有一对一所属部门模型处理。
● 新增/变更职位继续使用既有部门字段，不扩展为职位一对多适用部门。
● 接口文档同步补充查询返回和新增/变更入参说明，降低外部系统接入理解成本。
升级内容 2：添加编制审批支持选择部门
业务场景&问题：
● HR 可以从部门列表中发起添加编制，也可以从页面上方的“添加编制”按钮发起。
● 旧逻辑中，添加编制审批的部门字段是只读的。从部门列表发起时可以带出部门；但从顶部按钮发起时部门为空且不可编辑。
● 这会导致从顶部按钮进入的添加编制审批无法正常填写和提交。
解决方案：
1. 添加编制审批中的部门字段改为可编辑
● 在“组织-编制-添加编制审批”页面，部门字段由只读改为可编辑。
● 当从顶部“添加编制”按钮发起且部门为空时，用户可以主动选择部门。
● 当从部门列表发起并已带入部门时，用户也能根据实际需要调整。
2. 可在审批流程设计页面，配置该字段对于审批各个节点的查看、编辑权限
升级内容 3：关闭编制管理增加确认提醒
业务场景&问题：
● 编制管理开关关闭后，与在途占编、待入职占编、编制释放相关的部分后续处理可能不再继续执行。
● 线上问题中曾出现员工已经入职、待入职页面也没有对应人员，但编制板块仍显示该员工为在途占编。
● 根因与编制开关关闭后在途数据未被清理有关。对 HR 来说，关闭开关前如果没有明确提醒，很容易把它当成普通配置项误关。
解决方案：
1. 关闭编制管理时增加二次确认
● 用户关闭编制管理前，系统增加确认弹窗。
● 弹窗提醒关闭后可能影响在途占编、待入职占编等编制相关数据处理。
● 用户确认后才真正关闭，降低误操作概率。
2. 不改变编制数据本身的业务规则
● 本次主要补充关闭前提醒，不放宽或重写编制数据清理规则。
● 已经出现异常的历史在途占编数据，仍需按客户数据情况单独处理或通过既有修复逻辑纠正。
● 开关保持开启时，编制相关在途数据继续按原规则流转。
升级内容 4：编制审批提交/通过时校验最新数据
业务场景&问题：
● 企业可能同时存在多个编制变更审批。审批 A 已经通过并更新了某部门编制数，但审批 B 仍基于旧快照发起或继续通过。
● 例如根部门计划编制数已从 926 变更为 927，后续审批仍显示 926，并在通过后再次加 1，最终造成编制数异常。
● 旧逻辑没有在审批提交或通过前充分感知最新编制数据，导致多个审批之间发生数据时点不一致。
解决方案：
1. 审批提交/通过前感知最新编制数据
● 编制审批在关键节点增加最新数据校验。
● 当审批中的编制快照与当前最新数据存在冲突时，系统会识别并阻止继续按旧数据提交或通过。
● 用户需要基于最新数据重新发起或调整审批，避免旧方案继续落地。
2. 避免并发审批重复叠加
● 对同一部门或父级范围存在多个编制审批时，后发起、后通过的审批必须感知此前已生效的数据。
● 系统不再简单使用审批发起时的旧快照直接落地。
● 这能减少“两个审批看起来都只加 1，但最终叠加成多加”的问题。
3. 历史异常需按数据情况修复
● 本次修复面向后续审批流程，防止新审批继续产生类似异常。
● 对已生成的历史异常编制数，仍需要根据客户实际数据确认修正方式。
升级内容 5：兼岗主管去除入职日期校验
业务场景&问题：
● 企业维护兼岗信息时，会为员工选择兼岗主管。
● 旧逻辑会校验“兼岗开始日期 >= 兼岗主管入职日期”。但兼岗主管本质是组织管理关系字段，不一定适合用主管本人的入职日期限制员工兼岗开始时间。
● 在历史组织任命、兼岗补录、跨组织调整等场景中，该校验会误拦截正常业务。
解决方案：
1. 去除兼岗主管字段的入职日期校验
● 对“兼岗主管”字段，去掉“兼岗开始日期必须晚于或等于兼岗主管入职日期”的校验。
● 本次只影响“兼岗主管”字段，不改变兼岗员工本人、兼岗部门、兼岗开始/结束日期等其他字段的既有规则。
2. 覆盖多个使用兼岗主管的入口
● 员工详情页编辑兼岗信息时，不再用兼岗主管入职日期拦截。
● 兼岗审批发起和审批落地时，不再因兼岗主管入职日期早晚阻断。
● 导入兼岗、组织架构调整中的批量调整兼岗也同步去除该校验。
一体化
升级内容 1：Offer 人员选项搜索支持精准匹配
业务场景&问题：
● 招聘 HR 在 ATS Offer 链路中选择人员时，经常会输入员工姓名、手机号或邮箱来定位目标人员。
● 旧逻辑主要依赖模糊搜索。员工数量较多、存在同名员工、姓名相近或拼音相近时，完全匹配的员工不一定排在最前，HR 需要在下拉结果中继续人工核对。
● Offer 人员搜索只服务 ATS 调用场景，不应影响 People 内其他普通员工搜索入口。
解决方案：
1. Offer 人员搜索精确结果优先展示
● ATS Offer 人员搜索接口启用精准匹配模式。
● 当搜索关键词与员工姓名完全一致时，系统优先返回完全匹配的人员。
● 精确匹配结果之后，再按姓名、拼音、手机号、邮箱、工号等规则补充模糊搜索结果。
入职
升级内容 1：信息采集支持跨页联动
业务场景&问题：
● HR 配置信息采集表单时，常会将候选人基础信息、证件信息、银行卡信息、紧急联系人等内容拆到不同页面或分组中填写。
● 旧版联动规则对字段选择存在分组限制，导致第一页字段不能直接控制第二页字段。例如，某个是非字段在第一页，想控制第二页某组字段显示或隐藏时无法配置。
● 对复杂入职表单而言，这会迫使实施或 HR 拆分表单、减少分组，或用额外说明替代系统联动，表单体验和配置效率都受影响。
解决方案：
1. 条件字段和动作字段支持跨页选择
● 同一个信息采集表单内，联动规则的条件字段可跨页选择。
● 动作字段也可跨页选择，支持用第一页字段控制第二页字段。
● 字段展示时继续按明细组、非明细组分组，避免字段量变大后难以查找。
2. 保留原有字段类型和联动动作限制
● 条件字段仍沿用原有可选范围：默认字段，以及字段类型符合要求的自定义字段。
● 动作字段仍沿用原有动作能力，包括显示、隐藏、赋值、值联动。
升级内容 2：入职信息设置组合字段填写联动
业务场景&问题：
● 入职信息设置中，证件属于组合字段。HR 可能只勾选其中某个子字段用于候选人或 HR 填写。
● 但证件字段实际落地时，证件类型和证件号码是一组关键数据
● 如果只开启了组合字段中的某些其他子字段，而关键子字段没有同步开启，后续在待入职详情、扫码入职、确认入职或数据落地时容易出现字段缺失、页面加载异常或保存失败。
解决方案：
1. 证件组合字段自动联动必要子字段
● 在入职信息设置中，只要打开“证件”组合字段下任一字段的填写开关，系统会自动打开同一组合字段下的“证件类型”和“证件号码”填写开关。
● 被联动打开的“证件类型”和“证件号码”默认必填。
● 这样能保证后续入职链路拿到完整的证件主数据，避免只采集到非关键子字段。
升级内容 3：扫码入职进入待入职支持银行卡完整落地
业务场景&问题：
● 员工通过扫码入职填写资料后，HR 会将其转入待入职继续管理。
● 旧逻辑中，证件组合字段已经支持落地，但银行卡组合字段的部分自定义子字段仍可能在“扫码入职进入待入职”时丢失，例如开户支行等子字段被清空。
● 这会让员工已经填写过的信息在待入职阶段消失，HR 需要重新向员工确认或手工补录。
解决方案：
1. 扫码入职进入待入职时支持组合字段完整落地
● 扫码入职进入待入职时，系统支持银行卡组合字段整体落地。
● 支持范围包括证件、银行卡等组合字段的预置子字段和自定义子字段。
● 银行卡组合字段中的开户支行、自定义文本等子字段，不再因为进入待入职而被清空。
2. 覆盖单个和批量进入待入职入口
● 本次覆盖两个操作入口：单个进入待入职、批量进入待入职。
● 两个入口都按同一套组合字段落地规则处理，避免批量和单个处理结果不一致。
3. 与入职信息设置保持一致
● 组合字段是否在待入职各场景展示和落地，仍受入职信息设置中的“发起时填写”配置影响。
● 建议后续在入职信息设置中将组合字段按整组开关管理，减少只开部分子字段造成的数据结构不完整问题。
● 历史已进入待入职且字段缺失的数据不自动补齐；重新进入或重新保存时按新规则处理。
多语言
升级内容 1：支持租户级翻译修正
业务场景&问题：
● 当前系统已具备统一翻译能力，但翻译结果是平台级统一结果。不同租户对同一个组织/人事概念的使用习惯不同，例如「部门」在某些租户中希望展示为 Department，在另一些租户中希望展示为
● Team。
解决方案：
● 新增翻译工作台配置，支持被授权用户维护系统预置字段的租户级译文，包含英文与繁体中文
○ 功能权限配置：设置-公共设置-翻译工作台
○
● 被授权用户可在添加/编辑表单中从系统预置字段库选择标准字段并填写译文，也可点击「导入」批量新增字段。
○ 保存时系统校验同一租户、同一字段只能存在一条启用配置。
○
○
● 点击「导入」后打开导入弹窗，默认导入模式为「添加字段」，选择数据源并上传模板文件。
○ 导入时，校验导入字段是否与已有标准字段重复，重复时默认覆盖现有翻译结果
■ 仅覆盖填写的译文，若对应译文为空则不覆盖现有内容
■ 例如标准字段”部门“已有英文译文”Team“，导入时仅填写了繁体中文译文”團隊“，则导入后不影响已有的英文译文
○ 导入时若英文译文和繁体中文译文均为空，则忽略这条数据
● 保存或导入成功后，翻译服务刷新租户字段缓存，标准字段被删除后，展示则回退到通用翻译结果
○
绩效
升级内容 1：绩效/试用期全部考核环节支持绩效变更记录
业务场景&问题：
绩效考核和试用期考核推进过程中，不同处理人需要了解员工在本次考核内的完整过程记录，例如提交、驳回、调整、评估、校准、确认等操作。此前绩效侧仅在校准环节支持查看绩效变更记录，其他考核环节和试用期考核缺少统一入口，处理人需要跨页面查证，影响问题定位和审批判断效率。
解决方案：
在绩效模板和试用期考核模板的内容权限中，所有考核环节的参考信息均支持配置「绩效变更记录」。开关开启后，处理人在 PC 端待办详情右侧参考信息中可查看「绩效变更记录」页签；移动端待办详情展示「变更记录」入口，进入后查看当前员工本次考核的全部过程记录。
详细功能：
【绩效/试用期考核-模板设置-内容权限】
● 在「内容权限 > 选择考核环节 > 参考信息」中新增「绩效变更记录」开关，支持目标制定、目标审核、评估、校准、结果确认等所有考核环节。
● 每个考核环节独立配置，默认关闭；老模板、存量模板和历史考核没有配置值时均按关闭处理。
● 复制模板时，如果原模板已配置该开关，则随模板复制；没有配置值时按关闭处理。
● 如果考核流程中不包含某个环节，则该环节不展示也不保存该配置。
● 本次不新增待办、不新增通知，不影响导出、报表和 OpenAPI，也不回刷历史数据。
【绩效/试用期考核-PC/H5 待办详情】
● PC 端：当前环节开启「绩效变更记录」后，在待办详情右侧参考信息中展示「绩效变更记录」页签。
● 移动端：当前环节开启「绩效变更记录」后，在待办详情展示「变更记录」入口，进入后页面标题为「绩效变更记录」。
● 记录范围为当前考核活动、当前员工、本次考核内的过程记录，按时间倒序展示。
● 展示内容包括操作人、操作时间、操作类型、操作说明和可见的变更内容。
● 无记录时展示空态；加载失败时支持失败提示和重试。
● 无待办查看/处理权限的用户不能通过入口或 URL 查看；字段级内容仍遵循当前环节的内容可见权限，不通过变更记录绕过权限。
升级内容 2：绩效待办总评自动计算支持前端函数插槽
业务场景&问题：
部分客户的绩效结果计算规则不只依赖系统模板中配置的默认总评分、总评级规则，还会包含更复杂的企业口径，例如某个结果类别的分数需要结合其他结果类别二次计算，或绩效系数需要联动分数、等级后再得出。此前绩效待办中的总评自动计算主要按后端标准规则返回结果，遇到租户差异化计算口径时，无法在不改动标准逻辑的前提下灵活扩展。
解决方案：
在 PC 端和移动端绩效待办总评自动计算链路中新增前端函数插槽。系统仍先按模板配置调用标准自动算分逻辑，再允许通过插槽对返回的总评分、推荐评级等结果进行二次转换。未配置插槽或插槽执行失败时，自动回退为后端原始计算结果，保证原有绩效待办流程不受影响。
详细功能：
【绩效-PC/H5 待办总评自动计算】
● 支持按绩效模板、被考核人、结果类别等条件命中特定租户或特定场景。
● 支持基于多个结果类别的分数，自定义计算某个结果类别的总评分，并同步返回匹配的推荐评级。
● 覆盖 PC 端绩效待办的横向详细模式、纵向简洁模式、批量评估，以及移动端待办详情中的总评自动计算链路。
● 插槽转换后的总评分和推荐评级会回显到表单，并随待办提交一并上报。
【兼容与边界】
● 仅在编辑态、且结果类别配置为「自动计算」时触发；只读态、已提交待办、手动打分的结果类别不触发。
● 后端判断无需计算或没有返回计算结果时，不执行插槽转换。
● 未配置插槽、加载失败、执行超时或返回结果不合法时，系统静默使用后端原始计算结果，保持开槽前行为一致。
● 本次不改变标准自动算分规则本身，不新增待办、不新增通知，也不影响报表、导出和 OpenAPI。
● 本次能力覆盖 PC 端绩效待办横向/纵向视图、PC 批量评估和移动端待办详情；双端使用同一套输入输出契约、校验规则和回退口径。
升级内容 3：组织绩效、分支条件、固定考核方案全量开放
业务场景&问题：
组织绩效、分支条件、固定考核方案三个能力此前按租户节奏逐步开放。部分客户已具备对应管理场景，需要在绩效活动配置和流程规则中直接使用这些能力。
解决方案：
功能会针对租户级逐步放量，组织绩效、分支条件、固定考核方案三个功能全量开放。全量后默认可使用；如个别租户暂不需要使用，可按租户单独关闭，不影响其他绩效功能。
薪酬
升级内容 1：报税主体管理中任职受雇从业日期和离职日期可切换配置
业务场景&问题：
● 客户不在系统内申报，自行在线下进行申报，需要按照实际合同日期作为任职受雇从业日期和离职日期进行报送
解决方案：
● 增加AB名单控制，名单内的租户在添加或编辑报税主体时两个配置，以及按实际日期的子选项都可选
●
● 变更风险【务必知晓后再开通名单】
● 当个税所属期=发生所属年月时，即当月薪当月税
○ 选择两个配置的结果是一致的，即任职受雇从业日期与离职日期与个税所属期均一致。
● 当个税所属期是发薪所属年月的次月时，即当月薪次月税时
○ 根据税局26年1月属期起变更的规则，若任职受雇从业日期与离职日期按照员工实际日期，即实际合同开始日期或结束日期进行报送时，会影响该主体的个税申报。
○ 对于新入职员工来说，例如员工A 5月15号入职，首次发薪为5月的薪金，6月的个税所属期。需要在7月15号之前进行申报。
■ 若企业严格按照先申报上月的个税，再创建当月的薪酬核算活动时，此时不会产生影响
● 例如该主体在6月15日申报完成4月薪金5月个税之后，6月16日再创建了包含该主体下员工的薪酬核算活动。
■ 若企业在未申报完成上月个税的情况下，就创建了当月的薪酬核算活动时，在下个月申报当月税款的时候会被阻断。
● 例如该主体未完成4月薪金5月个税的申报时，就创建了5月薪金6月个税的薪酬核算活动，此时该活动中已包含员工A，已进行报送且任职受雇从业日期为5月15日。
○ 在申报4月薪金5月个税时，税局记录中已有员工A，此时会被阻断，会被提示5月的个税申报中不包含员工A
■ 此时的解决方案：
● 1、手动变更员工的任职受雇从业日期到6月内（非个税所属期内），再重新申报5月个税。若还是预期按照实际日期进行申报，那么在申报6月个税时仍需手动变更回来
● 2、为员工A单独创建一个4月薪5月税的核算活动，再重新进行申报，此时员工的累计减除费用和累计专项附加扣除费用会多1个月
○ 对于离职员工来说，例如员工B 7月15日离职，最后发薪月是7月薪金8月个税。
■ 此时在申报8月个税时，由于员工的实际离职日期月份（7月）小于个税所属期（8月），在申报时会被阻断，会提示8月属期不应该有这个员工
● 此时的解决方案：
○ 1、手动将离职日期变更为8月内（个税所属期内）重新进行申报
○ 2、将「是否离职后补发工资」改为“是”并填写「实际补发工资的月份」
PS:该功能为白名单功能，需要的企业需要知悉变更风险后联系客户成功经理或技术同学后开通
