跳至主要内容
Administrator Guide
上次更新时间 :2024-03-08
概念:短期休假余额存储指导原则

概念:短期休假余额存储指导原则

当员工访问您租户中的短期休假任务和报告时,Workday 会根据短期休假计划规则动态计算短期休假计划余额和应计额。Workday 会在后台访问从特定时间点开始运行计算的报告,以获得余额值。
所有员工都具有短期休假历史记录。Workday 会将许多事件提取到员工个人资料中,包括短期休假事件、累计应计额,以及余额期间之间的结转。Workday 对相同信息的访问速度有所不同,具体取决于您是否将 Workday 配置为存储余额:
  • 如果您未将租户配置为存储余额,则处理时间会长得多。如果没有可供参考的特定时间点,Workday 会从您首次在 Workday 中输入余额的时间开始运行计算。Workday 必须回溯到员工的初始历史记录,才能计算所有休假构成,并输出员工的休假余额结果。
  • 相比之下,如果您按一定的时间间隔来存储余额,则在员工访问其短期休假计划余额时,Workday 会根据最近存储的余额显示计算结果。此时 Workday 使用的是较近的日期,因此处理速度要快得多,可以提供更好、更高效的用户体验。
要优化性能,您可以排定流程时间表,定期为跟踪余额的所有短期休假计划存储余额。如果您使用“为短期休假余额计算流程排定时间表”
任务来存储 91 天或更长时间的余额和应计,则 Workday 会使用存储的余额和应计额作为后续动态计算的起点。
您可以存储截止到短期休假计划的期间表内任意期间开始日期的余额。您无法存储将来日期的余额。
如果您遇到与休假相关的性能问题,请使用
“查看短期休假余额计算流程的时间表”
报告检查您是否有用于存储短期休假余额的时间表。如果没有,请进行创建。

提高性能的最佳做法

为确保维持最低水平的性能,Workday 每月检查一次短期休假计划,确认它是否已存储截至过去 13 个月内的某个日期的余额。如果没有存储,则 Workday 会自动存储截至该月第三个星期日之前 13 个月的余额。但是,Workday 建议您手动排定根据您的短期休假计划和业务需求定制的流程。
我们建议您:
  • 不要存储截至今日的余额。
  • 针对 91 天前或更早的日期运行“为短期休假余额计算流程排定时间表”
    。存储余额时,Workday 使用从计划的期间表派生的期间开始日期。
  • 运行“为短期休假余额计算流程排定时间表”
    的频率不要高于期间表的频率。示例:如果短期休假计划的期间表频率为:
    • 双周。您可以每两周运行一次该流程,不要每周运行一次该流程。
    • 每月。您可以每月运行一次该流程,也可以超过一个月时间运行一次,不要每周或每两周运行一次该流程。
    • 每季度。每 3 个月运行一次该流程。不要每周、每两周或每月运行一次该流程。
    不要针对当前期间运行该流程。请将“运行日期之前的天数”
    值设置为大于零的数字。最佳做法是将其设置为 91 天或更长时间。将该值设置为 91 天或更长时间的主要好处是可以确保 Workday 储存应计,从而进一步提高性能。
  • 编辑作业的时间表,以减少同时处理的计划数量或增大重复发生频率。
  • 将该流程安排在晚上运行。
    对于初始 Workday 部署项目或合并和收购,请考虑操作顺序,因为这会影响处理计算时花费的时间。为获得最佳性能,在将离职员工的余额加载到 Workday 租户时,Workday 建议按以下顺序执行以下步骤:
    1. 加载短期休假
    2. 存储余额
    3. 员工离职
  • 对于每次加载超过 2000 行的大批量记录事务,为短期休假和休假使用“导入”Web 服务。
  • 注意报告时间表并将其同步。请务必在运行已排定时间表的短期休假余额计算流程之前运行报告。每季度运行一次报告,并至少每季度计算一次存储的余额。为计算余额提供起点有助于报告框架调用相关信息。如果您要按季度运行公司范围内的休假应计报告,则最好在您近期已排定时间表的已存储余额运行之后尽快运行。自定义报告和已编制索引的数据源(例如 Workers for HCM Reporting)是提高性能的关键因素,有助于更高效地调用存储的休假余额。
  • 如果您的组织中处于有效状态的 HCM 员工人数超过 100,000 名,则您应该检查租户性能,因为您可能拥有大量事务。要为此等规模的员工提供支持,可能需要额外注意评估租户运行时间和最终用户体验。
  • 在员工完成该期间的短期休假输入后,运行“为短期休假余额计算流程排定时间表”
    流程。
    示例:等到员工在年末输入短期休假后,再针对 12 月份运行该流程。此方法可减少 Workday 必须根据追溯性条目重新计算和存储余额的次数。

租户设置

检查“休假”Worklet 显示余额时的性能。如果您注意到加载时间过长,或者该 Worklet 需要很长时间才能填充信息,建议访问“编辑租户设置 - HCM”
任务并导航至“短期休假”
版块。选择“禁用‘休假’Worklet 的余额”
选项。当员工查看自己的休假或申请休假时,他们仍可在日历上查看余额信息。
检查 Workday Payroll 的租户设置。访问“编辑租户设置 - 薪资”
任务,导航至“工资单”
版块,然后启用“Persist Absence Data for Payslips”
选项,以提高工资单和“Get Payroll Payslips”
Web 服务的性能。在薪资计算到薪资支付完成这一期间内,系统会保存相应数据。Workday 会从薪资结果中查看已保存的休假数据,除非薪资在您启用该选项之前已经支付完成。

性能影响因素

以下因素增加了短期休假余额计算的复杂性。请考虑您是否必须比较频繁地为部分或全部计划运行该流程:
  • 期间表频率。示例:每周或每月。不要在短期休假计划中使用每日期间表。Workday 建议您至少选择每周时间表。
  • 限额:上限、下限和结转。
  • 与余额关联的多个应计。
  • 与计划关联的多个短期休假。
  • 依赖于另一个计划余额的计划余额。
  • 期间表中已处理的期间数。
  • 符合计划条件的员工数。配置短期休假计划或节假日日历的国家/地区适用资格。
  • 重设和调整的数量。
  • 通过 Workday Time Tracking 输入的带时间计算的短期休假申请数量。
  • 通过 Web 服务加载的短期休假和更正的数量。
下面是一些常规建议:
  • 仅将每个计划包含在 1 个期间表中。
  • 对于复杂的应计以及使用滚动应计的应计,建议存储余额。如果不这样做,可能会对租户结果和运行时间产生负面影响。
  • 确保将期间表范围限定为员工加载余额所需的时间长度。如果期间表的创建时间太过久远,也没有持续地存储这些余额,则会导致 Workday 花费更长的时间来动态计算余额。
  • 确保使用高级查询表计算。
  • 使用“带薪短期休假”
    休假构成相关计算 (ACRC) 时,这些计算还需要进行其他计算(例如计算下限)才能返回值。通常,如果计划使用下限和“允许的无薪短期休假最大单位数”
    验证,则无需使用此休假构成相关计算。如果可能,请改用“短期休假总计”
    休假构成相关计算,因为此项计算不需要进行其他计算。
  • 检查安全配置。休假相关域和业务流程安全策略的复杂配置可能会影响对任务和业务流程的访问。

集成

许多集成都使用报告框架来为外部 Web 服务检索数据。如果未存储余额,则在 Web 服务运行时,可能会影响已排定时间表的集成的运行时间。请考虑租户推送或拉取转入和转出事务信息对性能的影响。
对于转出事务,请检查集成是否基于时段访问余额。数据量和时间段可能会影响性能。如有可能,请尝试限制这些时间段。如果您知道某个集成需要较长的运行时间,请考虑另择时间运行该集成,或者考虑存储余额能否加快该集成的运行速度。