您的薪资处理数据模板
您的薪资处理数据模板
- 薪资分析的标准数据属性
- UKG Pro 中需追踪的关键流程里程碑
- 系统集成的技术提取指南
薪资处理属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Timestamp
EventTimestamp
|
活动发生的日期和时间。 | ||
|
描述
此属性记录活动发生的准确时刻。它对于正确排列事件顺序以及计算步骤之间的持续时间至关重要。为了区分快速连续发生的自动化步骤,建议使用高精度时间戳。 在薪资场景中,这驱动了“周期时间分布”和“SLA 合规性”仪表板的分析。如果没有准确的时间戳,就无法衡量“总额到净额”计算的速度,也无法衡量“工时表审批”的延迟情况。
为何重要
这是必填的“开始时间”(StartTime)属性,用于对事件进行排序。
获取方式
与交易状态变更关联的日期/时间列
示例
2023-10-01T09:15:00Z2023-10-01T14:30:45Z2023-10-03T08:00:00Z
|
|||
|
最后更新日期
LastUpdateDate
|
数据行最近一次修改的时间戳。 | ||
|
描述
此属性指示数据库中记录的最后更改时间。虽然它与事件时间戳相似,但专门用于增量数据加载和数据完整性检查。 它确保流程挖掘模型反映薪资记录的最真实状态,捕获薪资专员所做的任何后期调整或溯及既往的更正。
为何重要
增量 Data 刷新的强制性属性。
获取方式
系统元数据列(如 LastModifiedDate)
示例
2023-10-05T17:00:00Z2023-10-06T09:00:00Z
|
|||
|
活动
ActivityName
|
薪资流程中执行的特定事件或步骤。 | ||
|
描述
此属性捕获薪资工作流中发生的步骤名称,例如“工时表已提交”、“总工资已计算”或“支付已执行”。它定义了流程图的走向。 这些值通常从 UKG Pro 环境内的审计日志、系统状态变更表或带时间戳的交易更新中提取。在数据转换过程中,我们会应用一致的命名规范,以确保流程图的可读性。
为何重要
这是必填的“活动”(Activity)属性,用于定义流程图中的节点。
获取方式
系统审计日志、工作流历史或交易时间戳列
示例
工时表已提交总薪资已计算已执行付款
|
|||
|
源系统
SourceSystem
|
数据记录系统。 | ||
|
描述
此属性识别数据记录的来源。在本场景下,该值被静态设置为 UKG Pro(如果存在多个实例,则为特定的实例名称)。这对于多系统流程挖掘至关重要,因为薪资数据可能会与来自 ERP 的总账数据混合。 它允许分析师过滤视图,以仅显示严格源自薪资平台的步骤,而非那些可能从外部考勤系统集成的步骤。
为何重要
Data 血缘和多系统分析的强制性属性。
获取方式
静态值或系统配置表
示例
UKG ProUltiPro 旧版时间管理系统
|
|||
|
薪资记录
PayrollRecordId
|
代表特定薪资期内特定员工的唯一标识符。 | ||
|
描述
薪资记录(Payroll Record)在流程挖掘分析中充当核心的“个案标识符”(Case ID)。它在概念上是通过组合员工 ID 和薪资期结束日期(或薪资组实例)构建的。这确保了单个员工的每个薪资周期都被视为一个独立的个案,从而允许分析随时间推移的重复性流程。 在 UKG Pro 中,这通常是源自薪资报头表或类似交易记录的复合键。按此 ID 分组,分析师可以重构从工时表提交到最终支付和税务申报的全流程路径。
为何重要
这是必填的“个案 ID”(Case ID),用于将所有薪资活动分组以形成流程实例。
获取方式
衍生自 UKG Pro Payroll Header 或 Employee Pay History 表
示例
EMP001-20231015EMP492-20231031EMP883-20231115
|
|||
|
SLA 截止日期
SlaProcessingDeadline
|
支付执行完成的目标日期/时间。 | ||
|
描述
此属性定义了完成薪资流程以确保及时进行银行转账的内部或外部截止日期。它是“SLA 合规性与截止日期监控”仪表板的核心属性。 通过将实际的“支付已执行”时间戳与此截止日期进行对比,可以计算准时绩效率,并帮助确定风险记录的优先级。
为何重要
计算 SLA 达成率的参考点。
获取方式
薪资日历,或根据发薪日期减去银行处理天数得出
示例
2023-10-13T16:00:00Z2023-10-28T16:00:00Z
|
|||
|
周期时间(天)
CycleTimeDays
|
从初始化到支付执行的总持续时间。 | ||
|
描述
此持续时间属性衡量每个记录的端到端流程时间。它是“薪资周期时间分布”仪表板的基础。 分析不同薪资组或部门之间“周期天数”的差异,可以揭示效率低下的环节,并帮助量化人工更正对整体流程速度的影响。
为何重要
流程效率的核心指标。
获取方式
计算方式:付款 Timestamp - 初始化 Timestamp
示例
3.55.01.2
|
|||
|
存在审计异常
HasAuditException
|
指示是否触发了审计异常的标志。 | ||
|
描述
此布尔属性标记该个案是否发生过“审计异常已标记”活动。它支持“薪资首检准确率”KPI。 它允许分析师快速将“干净”个案与需要干预的个案分开,从而简化“审计异常与更正趋势”仪表板中的返工原因分析。
为何重要
识别需要人工干预的 Case。
获取方式
衍生自“标记审计异常”活动的存在
示例
truefalse
|
|||
|
总薪资额
GrossPayAmount
|
扣除税费前的计算总工资。 | ||
|
描述
此属性代表为记录计算的总工资金额。它被映射到 ActivityAmount,以实现基于成本的流程分析。 分析总工资金额有助于“总额到净额计算速度”仪表板。虽然该仪表板主要衡量时间,但将时间与支付的复杂程度(及金额)相关联,可以揭示高价值或复杂的佣金计算是否是性能问题的根源。
为何重要
支持价值流分析和异常值检测。
获取方式
薪资结果或薪资登记表
示例
2500.0010500.50480.00
|
|||
|
成本中心
CostCenter
|
用于财务分配的成本中心代码。 | ||
|
描述
成本中心(Cost Center)属性定义了总账中薪资费用的分配位置。虽然与部门(Department)类似,但它通常提供更精细的财务视角。 此属性用于“工时追踪审批绩效”仪表板,以识别特定成本中心是否存在审批层级过慢的问题。它还有助于验证在“总额到净额”计算阶段,薪资费用是否流向了正确的财务科目。
为何重要
支持财务分析并按预算单位识别瓶颈。
获取方式
员工职位或分配表
示例
CC-5001CC-9002总部管理费
|
|||
|
是否为非周期性
IsOffCycle
|
指示薪酬运行是否超出标准计划的标志。 | ||
|
描述
此布尔属性识别薪资记录是否属于周期外运行。它用于计算“周期外薪资量”KPI。 周期外运行通常成本更高,且更多涉及人工操作。通过此标志过滤“流程变体路径分析”仪表板,可以突出显示为纠错或发放临时款项而采取的非标准路径。
为何重要
分析流程偏差和返工的关键过滤器。
获取方式
薪资报头“支票日期”与“周期结束日期”逻辑
示例
truefalse
|
|||
|
是否发生SLA违约
IsSlaBreached
|
指示付款是否在截止日期后执行的标志。 | ||
|
描述
此布尔属性是一个计算指标,用于比较“支付已执行”时间戳与“SLA 截止日期”。它是“薪资 SLA 达成率”KPI 的直接驱动因素。 预先计算好该值可以立即过滤仪表板以仅显示有问题的个案,从而方便对错过截止日期的原因进行根本原因分析。
为何重要
合规监控的 KPI 驱动因素。
获取方式
计算方式:付款时间 > SLA 截止日期
示例
truefalse
|
|||
|
税务管辖区
TaxJurisdiction
|
税务申报的主要州或地区。 | ||
|
描述
此属性识别与薪资记录关联的主要税务管辖区。它对于“多州税务申报时间线”仪表板至关重要。 通过基于税务管辖区分析流程流,合规团队可以发现特定州的申报完成时间是否持续偏慢,或者多州员工是否比单州员工触发了更多的审计异常。
为何重要
对于合规监控和地理分布分析至关重要。
获取方式
税务所在地或员工税表
示例
CA纽约TX
|
|||
|
薪资专员
PayrollSpecialist
|
处理该记录的人员的用户 ID 或姓名。 | ||
|
描述
此属性识别负责批准记录、执行数据更正或执行支付运行的特定薪资管理员或专员。它被映射到通用用户(Generic User)属性。 这些数据对于“专员工作量与吞吐量”仪表板至关重要。它使管理层能够直观地了解工作在团队中的分配情况,并识别特定人员是否负担过重或在审批阶段成为了瓶颈。
为何重要
实现资源分析和工作负载平衡洞察。
获取方式
审计日志或交易表中的“ModifiedBy”列
示例
jsmithmdoesystem_admin
|
|||
|
薪资期结束日期
PayPeriodEndDate
|
正在处理的薪资期的最后一天。 | ||
|
描述
此属性标记薪资周期的关闭日期。它是确定提交是否延迟的关键参考点。 它与“工时表已提交”活动的开始时间(StartTime)配合使用,以确定滞后时间,并且是“薪资周期时间分布”仪表板的关键分组项。
为何重要
薪资周期的时间锚点。
获取方式
薪资报头或时段配置
示例
2023-09-302023-10-15
|
|||
|
薪资组
PayGroup
|
薪资处理中员工的逻辑分组。 | ||
|
描述
薪资组(Pay Group)是 UKG Pro 中的一项基础配置,它规定了一组员工的发薪频率(每周、每两周)和处理规则,并作为主要的批次标识符。 此属性对于“薪资周期时间分布”仪表板至关重要。通过它,您可以对比不同群体(如行政薪资与工厂计时工人)的处理绩效,从而识别特定配置是否导致了系统性滞后。
为何重要
用于薪资绩效分组和对比的主要维度。
获取方式
薪资报头或薪资组配置表
示例
美国-双周付CA-周薪高管-月薪
|
|||
|
部门
DepartmentCode
|
与员工关联的部门代码。 | ||
|
描述
此属性将薪资记录链接到特定的组织单位。它对于“审计异常与更正趋势”仪表板必不可少,使组织能够看到哪些部门经常产生错误或需要人工干预。 通过按部门(Department)细分数据,分析师可以识别特定经理是否需要针对工时表审批流程进行培训,或者某些业务单元是否因复杂的薪资规则导致了计算延迟。
为何重要
对于组织细分和根本原因分析至关重要。
获取方式
员工主数据或职位历史表
示例
DEPT-100财务-01OPS-WEST
|
|||
|
员工类型
EmployeeType
|
员工分类(例如:全职、兼职、承包商)。 | ||
|
描述
此属性对与薪资记录关联的个人进行分类,并用于“工时追踪审批绩效”仪表板。 不同类型的员工往往具有不同的工时表提交行为和审批工作流。按此属性进行细分,有助于区分系统性流程问题与特定员工群体特有的行为模式。
为何重要
按劳动力类别进行细分分析。
获取方式
员工主表
示例
全职兼职合同工
|
|||
|
更正类别
CorrectionCategory
|
执行的数据更正类型(例如:时间、费率、扣款)。 | ||
|
描述
当发生“已执行数据更正”活动时,此属性捕获更正的性质。这对于“人工数据更正率”KPI 至关重要。 了解更正是主要与“工时录入”还是“福利扣款”有关,可以让企业针对特定的上游系统或团队进行流程改进。
为何重要
提供关于返工原因的详细信息。
获取方式
审计日志“字段变更”列
示例
工时录入调整溯及既往工资(补发工资)税码更新
|
|||
|
激励来源
IncentiveSource
|
激励数据来源(例如 SalesForce、Excel 导入)。 | ||
|
描述
此属性识别导入薪资记录的任何激励或佣金数据的来源。它支持“激励数据导入准确性”仪表板。 通过将此属性与“激励数据返工频率”KPI 相关联,团队可以确定特定的上游文件(如“东北区销售报告”)是否经常容易出现格式错误或数据质量问题。
为何重要
将质量问题追溯到外部数据提供商。
获取方式
导入日志文件名或批次 ID 描述
示例
销售佣金馈送手动奖金上传高管薪酬系统
|
|||
薪资处理活动
| 活动 | 描述 | ||
|---|---|---|---|
|
已执行付款
|
生效日期或实际向员工转账的日期。这标志着薪酬义务的履行。 | ||
|
为何重要
用于验证“SLA 合规性”,确保员工在承诺日期拿到工资。
获取方式
使用已完成薪资报头记录中的“支票日期”或“通知日期”字段。
捕获
执行 payment_post 交易时记录
事件类型
explicit
|
|||
|
税务申报已完成
|
成功将税务数据提交给相关的管辖区(联邦、州、地方)。这通常发生在支付之后。 | ||
|
为何重要
对于“多州税务申报时间线”仪表板至关重要,旨在确保符合监管要求并避免罚款。
获取方式
在税务申报界面或支付服务日志中捕获指示“已申报”或“已接受”的状态更新。
捕获
执行 tax_file_transmit 交易时记录
事件类型
explicit
|
|||
|
薪资记录已初始化
|
在新的薪资组实例中为员工创建特定的发薪行项目。这标志着员工处于活跃状态并已关联到当前的处理周期。 | ||
|
为何重要
标记核心系统内薪酬处理阶段的正式开始。对于区分工时采集时长与实际薪酬处理时长至关重要。
获取方式
在特定发薪日的员工薪酬或支票表头表中识别记录插入时的 Timestamp。
捕获
执行 pay_period_create 交易时记录
事件类型
explicit
|
|||
|
薪资记录已批准
|
对个人记录或整个薪资组的最终签核。此操作将锁定记录以防进一步更改,并将其排队等待支付生成。 | ||
|
为何重要
区分工作阶段与最终完成阶段的关键里程碑。用于计算“银行转账文件提前期”。
获取方式
在发薪周期控制表中捕获薪酬组或个人支票记录状态变更为“已批准”或“已锁定”的情况。
捕获
执行 approve_pay_group 交易时记录
事件类型
explicit
|
|||
|
工时表已批准
|
经理对提交工时的批准,验证其可用于支付处理。这一步会解锁数据,以便将其导入薪资计算引擎。 | ||
|
为何重要
此步骤的瓶颈分析揭示了由管理层审核导致的延迟,这直接影响了薪酬专员处理 Data 的可用时间窗口。
获取方式
从 Time Management 历史记录中捕获状态变更为“已批准”或“已签核”的记录。
捕获
执行 time_card_approve 交易时记录
事件类型
explicit
|
|||
|
工时表已提交
|
员工或经理提交该发薪期考勤卡的事件。这标志着原始工时数据进入更广泛的薪资工作流,尽管这些数据可能源于时间管理模块,然后再流向核心薪资系统。 | ||
|
为何重要
确立端到端薪酬周期的最早开始 Timestamp。对于衡量工作绩效与薪酬 Data 摄取之间的延迟至关重要。
获取方式
从 Time Management 审计日志或工时卡历史表中捕获状态字段变更为“已提交”的记录。
捕获
执行 time_card_submit 交易时记录
事件类型
explicit
|
|||
|
工资单已发布
|
工资结算单在自助服务门户中对员工可见。这完成了整个沟通过程。 | ||
|
为何重要
虽然这不是一个阻碍性的技术步骤,但延迟发布会增加服务台的咨询量并影响员工满意度。
获取方式
根据薪酬组配置中的“支票日期”或特定的“Self Service 发布日期”设置推断得出。
捕获
通过对比 check_date 与 release_policy 字段得出
事件类型
inferred
|
|||
|
已应用福利扣除
|
系统将税前和税后福利扣款(如医疗保险、401k)应用于总工资。此逻辑通常在确定总工资后立即运行。 | ||
|
为何重要
此处的错误往往需要手动更正。隔离此步骤有助于确定延迟是由福利引擎还是配置问题引起的。
获取方式
根据计算批次的 Timestamp 或通过观察员工扣除历史表中的创建 Timestamp 推断得出。
捕获
通过对比 calculation_stage 字段得出
事件类型
inferred
|
|||
|
已执行数据更正
|
在初始计算之后、最终批准之前,对薪酬记录进行的手动修改(例如:调整工时、冲销税费)。 | ||
|
为何重要
这是衡量返工的主要指标。追踪此项可启用“人工数据更正率”KPI。
获取方式
在审计日志中捕获对员工薪酬详情或扣除表进行的更新,且用户 ID 非“系统”的情况。
捕获
执行 update_pay_detail 交易时记录
事件类型
explicit
|
|||
|
总薪资已计算
|
初始计算运行,系统根据工时、费率和激励数据确定总收入。这发生在应用扣款和税收之前。 | ||
|
为何重要
衡量从此处到“Taxes Calculated”的时间,可提供系统性能分析所需的“从税前到税后计算速度”指标。
获取方式
根据系统作业日志中计算批处理过程的“开始时间”推断得出。
捕获
对比计算作业开始前后的状态字段
事件类型
inferred
|
|||
|
标记审计异常
|
系统或用户识别出差异,例如负工资、缺失税码或 SLA 警告。这将使记录进入需要关注的状态。 | ||
|
为何重要
直接为“审计异常与更正趋势”仪表板提供 Data。此处的高频率代表上游 Data 质量存在问题。
获取方式
在系统警告日志或发薪周期消息表中识别与特定员工 ID 关联的记录。
捕获
创建 validation_warning 交易时记录
事件类型
explicit
|
|||
|
激励数据已导入
|
导入外部薪酬数据,如佣金、奖金或一次性支付。这与常规工时不同,通常涉及批量文件上传。 | ||
|
为何重要
此活动之后出现的高失败率或返工,表明 Data 映射或外部文件质量存在问题,这是薪酬延迟的常见原因。
获取方式
从系统日志或批量导入历史中捕获文件类型涉及“激励”或“额外薪资”的记录。
捕获
执行 import_batch_data 交易时记录
事件类型
explicit
|
|||
|
税费已计算
|
计算引擎的最后阶段,在此应用多州税务逻辑以确定净工资。这标志着自动化计算阶段的完成。 | ||
|
为何重要
完成“从税前到税后”的序列。此处耗时较长可能意味着税务引擎存在性能问题,或存在复杂的多司法管辖区配置。
获取方式
根据系统作业日志中计算批处理过程的“结束时间”或员工税务表上的 Timestamp 推断得出。
捕获
对比计算作业结束前后的状态字段
事件类型
inferred
|
|||
|
薪资结果已预览
|
用户打开薪酬登记簿或预览报表以验证计算结果。这代表了从自动化处理到人工审核的转变。 | ||
|
为何重要
指示验证阶段的开始。计算与预览之间的时间间隔过长,可能意味着存在资源可用性问题。
获取方式
从审计日志中捕获用户访问“Payroll Register”或“Pre-Check”报表的记录。
捕获
执行 report_view_preview 交易时记录
事件类型
explicit
|
|||
|
银行转账文件已生成
|
技术层面生成用于传输至银行的 NACHA 或直接存款文件。这为资金转移做好了准备。 | ||
|
为何重要
此处的延迟会直接导致错过银行截止时间的风险。支持“银行转账生成速度”仪表板。
获取方式
在系统作业日志中捕获 ACH/直接存款文件创建作业完成时的 Timestamp。
捕获
执行 create_ach_file 交易时记录
事件类型
explicit
|
|||