您的支付处理数据模板
您的支付处理数据模板
这是我们针对付款处理中的通用流程挖掘数据模板。使用我们针对特定系统的模板以获得更具体的指导。
选择特定系统- 交易跟踪的完整字段定义
- 支付生命周期的通用活动映射
- 兼容各种财务系统的可扩展数据结构
支付处理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 事件timestamp EventTimestamp | 活动或状态变更发生的具体日期和时间。 | ||
| 描述 此属性记录了支付系统中 event 发生的准确时刻。它作为流程的时间锚点,确保 case 内部的事件顺序正确。 在分析中,此 timestamp 是所有基于时间的计算的基础。它用于确定活动之间的持续时间、总体的端到端周期时间以及服务水平协议 (SLA) 的遵守情况。准确的 timestamp 对于识别瓶颈发生的时间至关重要。 高精度是首选,特别是对于毫秒必争的高频交易或自动支付系统。如果只有日期而没有时间,则在对同一天发生的活动进行排序时,可能需要二次排序逻辑。 为何重要 对于事件排序和计算所有基于时长的 KPI(如周期时间)至关重要。 获取方式 位于交易日志、历史表或系统审计追踪中。 示例 2023-10-15T08:30:00Z2023-10-15 14:45:12.5502023-11-01T09:00:00+00:0010/15/2023 08:30:00 PM2023-10-16 10:15:00 | |||
| 最后数据更新 LastDataUpdate | 指示记录上次提取或刷新的 timestamp。 | ||
| 描述 此属性追踪分析中使用的数据的新鲜度。它反映了数据加载到流程挖掘工具的时间,或源数据库中记录最后修改的时间。 掌握此信息对于数据治理和信任至关重要。它让分析师知道他们查看的是实时数据还是前一天的快照。这对于监控可能卡在待处理状态的活跃付款尤为重要。 虽然不直接用于流程流计算,但它作为元数据控制字段,确保仪表板显示的是支付业务的最新状态。 为何重要 确保数据新鲜度,并有助于调试数据管道延迟问题。 获取方式 在数据提取或 ETL 过程中生成。 示例 2023-10-27T12:00:00Z2023-10-27 23:59:592023-10-28 06:00:0010/27/20232023-11-01 01:00:00.000 | |||
| 支付交易 ID PaymentTransactionId | 代表特定支付指令或交易案例的唯一标识符。 | ||
| 描述 此属性作为关联单个付款生命周期内所有活动的核心键。它允许流程挖掘工具重建付款从发起至最终结算或失败的端到端路径。 在分析中,此标识符用于将不同的 event 分组到单个 case 实例中。它实现了流程流的可视化,对于计算每笔交易的周期时间至关重要。如果没有唯一的 ID,就无法区分系统中成千上万笔同时进行的付款。 此字段在付款的整个生命周期内通常保持不变。但在涉及多个系统的复杂场景中,这可能需要是一个复合键,或者从唯一的端到端参考编号进行映射。 为何重要 它是创建流程模型和跟踪特定支付所需的基础“案例 ID”。 获取方式 通常位于交易抬头、付款指令表或主分类账日志中。 示例 TRX-8859201PAY-2023-X9910029384f47ac10b-58cc-4372-a567-0e02b2c3d479INSTR-5542 | |||
| 活动名称 ActivityName | 支付生命周期中发生的具体步骤、状态变更或事件。 | ||
| 描述 此属性描述了付款在特定时间点所经历的操作或状态更改。示例包括创建请求、验证检查、授权步骤或最终结算。 流程挖掘依靠此属性来定义流程图中的节点。通过分析这些活动的顺序,分析师可以识别常见的变体、付款被返工的循环,以及付款长时间滞留的瓶颈。 为了创建连贯的流程视图,通常需要对来自不同源系统的名称进行标准化。例如,一个系统可能将某个步骤称为“Auth”,而另一个系统称之为“Authorization”,在数据转换过程中应将它们统一。 为何重要 它定义了流程图中的节点,支持对流程流向和变体进行分析。 获取方式 位于审计日志、状态历史表或事件跟踪表中。 示例 已创建支付付款已授权支付失败结算已确认验证错误 | |||
| 源系统 SourceSystem | 事件数据来源的应用或系统名称。 | ||
| 描述 此属性标识记录的技术来源。在端到端的付款流程中,数据通常流经多个系统,例如前端网关、欺诈检测引擎和后端账本。 按系统分析数据允许用户隔离技术问题。例如,如果延迟始终出现在欺诈引擎而非账本中,则可以更有效地进行针对性的根本原因分析。这也有助于在合并多个数据源时验证数据完整性。 如果源数据中没有明确存在此字段,通常在提取和转换过程中添加。它作为血缘标记,用于审计和调试目的。 为何重要 对于多系统分析以及识别导致延迟或错误的组件至关重要。 获取方式 通常在 ETL 过程中硬编码,或位于系统元数据中。 示例 PaymentGateway_01CoreBankingSystemFraudEngineSwiftInterfaceERP_SAP | |||
| 付款到期日 PaymentDueDate | 预计或要求支付结算的日期。 | ||
| 描述 此属性代表付款的目标截止日期。它允许系统衡量“准时付款率”并确定是否满足了服务水平协议 (SLA)。 将实际完成的 timestamp 与此到期日期进行比较,可以为流程性能提供明确的衡量指标。在此日期之后完成的付款被视为逾期,这可能会导致罚款或损害业务关系。 此字段对于应付账款流程或有保障的服务交付合同尤为重要,因为时间在其中是一项合同义务。 为何重要 计算 SLA 达成率和准时支付率所必需。 获取方式 位于发票抬头或支付请求指令中。 示例 2023-10-302023-11-012023-10-152023-12-312024-01-01 | |||
| 付款方式 PaymentMethod | 用于执行支付的具体工具或机制。 | ||
| 描述 此属性按执行类型(如电汇、ACH、信用卡或即时支付)对付款进行分类。每种方式通常遵循不同的流程路径,且在时间预期和成本上有所差异。 通过使用此属性对数据进行细分,分析师可以对比不同支付通道的性能。例如,与自动化的 ACH 批处理相比,电汇可能需要更多的手动审批步骤。 了解支付方式的组合有助于进行容量规划,并识别客户行为的变化,例如从传统支票转向数字即时支付。 为何重要 对于区分具有不同 SLA 的流程变体(如即时转账与电汇)至关重要。 获取方式 位于支付指令详情中。 示例 电汇ACH信用卡SEPA 贷记转账实时支付 | |||
| 处理人 ProcessingUser | 负责执行该活动的用户 ID 或系统代理。 | ||
| 描述 此属性标识谁或什么执行了付款流程中的特定步骤。它可以是指执行人工审核的人员,也可以是指执行自动化任务的系统账号。 这些数据对于分析资源利用率和瓶颈至关重要。它有助于区分自动化处理(直通式处理)和人工干预。人工参与率高通常意味着更高的成本和更长的周期时间。 在合规性方面,此字段有助于职责分离分析,确保创建付款的人与审批付款的人不是同一个人。 为何重要 支持分析自动化率(STP)和资源生产率。 获取方式 位于交易表的审计日志或元数据列中。 示例 SystemAgent_01jdoeAPPROVER_GROUP_AAutoReconcilerAPI_User | |||
| 支付金额 PaymentAmount | 与支付交易关联的货币价值。 | ||
| 描述 此属性代表正在转移的财务价值。它是衡量流程效率低下所产生影响的主要数值指标。例如,一笔百万美元付款的延迟通常比一笔十美元付款的延迟更关键。 在分析中,此字段用于汇总交易量、计算总流动性需求以及按价值区间对付款进行细分。高额支付通常遵循与低额支付不同的审批工作流,此属性有助于区分这些路径。 必须将此属性与货币代码配对,以确保具有可比性。如果不进行货币转换或分离就汇总金额,可能会导致误导性的财务报告。 为何重要 支持财务影响分析,并能区分高价值与低价值交易。 获取方式 位于交易详情或财务入账表中。 示例 150.0010000.5025.995000000.01 | |||
| 货币代码 CurrencyCode | 表示支付货币的 3 位 ISO 代码。 | ||
| 描述 此属性指定付款金额的货币单位,例如 USD、EUR 或 GBP。它对于准确的财务报告和触发特定的跨境工作流至关重要。 分析通常需要按货币进行过滤,以了解区域性能或外汇处理时间。不同的货币可能有不同的截止时间、结算周期和监管要求,这些都会直接影响流程流。 没有此属性,“付款金额”字段将是不明确的。此字段可以将不同的金额转换为单一报告货币,以便进行全球化的仪表板展示。 为何重要 对于规范财务价值和识别跨境流程变体非常必要。 获取方式 位于交易表中的支付金额旁。 示例 美元EURGBPJPYCAD | |||
| 错误代码 ErrorCode | 支付失败或被拒绝时生成的特定代码或原因。 | ||
| 描述 该属性记录了流程失败的技术或业务原因。当支付被拒绝、验证失败或遇到传输错误时,系统会填充此字段。 分析错误代码是降低“支付失败率”和“返工率”的主要方法。对常见的错误代码进行分组有助于识别系统性问题,例如主数据不准确或与外部清算机构的技术连接问题。 在“顺畅路径”(Happy Path)场景下,此字段通常为空。它的出现往往意味着流程偏离了理想状态,并触发了异常处理子流程。 为何重要 用于失败和返工根本原因分析的主要属性。 获取方式 位于错误日志、拒绝消息或响应负载中。 示例 余额不足账号无效FRAUD_SUSPICIONTIMEOUTDUPLICATE_REF | |||
| 处理渠道 ProcessingChannel | 发起支付的接口或渠道。 | ||
| 描述 此属性指示付款指令的入口点,例如移动应用、Web 门户、API 或文件上传。它提供了对客户行为和渠道使用情况的洞察。 按渠道分析流程性能可以凸显技术差异。例如,通过 API 发起的付款可能会立即处理,而文件上传可能需要等待批处理窗口。这有助于了解不同平台上的用户体验。 它还可用于分析从传统渠道(如手动输入或传真)向数字渠道的转变,为数字化转型计划提供支持。 为何重要 有助于分析不同入口点(如移动端与网页端)的业务趋势和绩效差异。 获取方式 位于交易抬头或会话元数据中。 示例 移动应用网络门户H2H 文件APIPOS 终端 | |||
| 收款人名称 BeneficiaryName | 接收付款的实体或个人名称。 | ||
| 描述 此属性标识收款人。在 B2B 场景中是供应商;在 P2P 场景中则是个人接收者。它提供了支付对象的背景信息。 按受益人分析付款可以揭示特定模式,例如频繁向高风险实体付款或特定供应商的集中风险。这对于欺诈分析也很有用,可以识别是否存在多个小额付款正流向同一个意料之外的受益人。 此处常见数据质量问题,例如拼写差异(如“Inc.”与“Incorporated”)。为了准确聚合,通常需要清理这些数据。 为何重要 对供应商分析、欺诈检测和风险分析非常有用。 获取方式 位于支付指令的收款人详细信息部分。 示例 Acme公司Global Services Ltd约翰·史密斯Azure Cloud Services税务机关 | |||
| 风险评分 RiskScore | 表示欺诈可能性或合规风险的数值分数。 | ||
| 描述 此属性是由欺诈检测引擎或风险模型生成的值。分数越高通常表示该交易是欺诈或高风险的可能性越大。 在流程分析中,此分数有助于解释为什么某些付款会进入漫长的审核循环。高风险分数的付款通常会触发人工干预,从而增加周期时间。将风险分数与最终结果(批准或拒绝)相关联,有助于微调风险规则的效率。 并非所有系统都会生成数字分数;有些系统可能只提供状态标志。然而,对于现代支付网关,这是决策的标准指标。 为何重要 解释流程偏差,例如人工审查和因欺诈检查导致的暂扣。 获取方式 来自欺诈检测系统或风险引擎的输出。 示例 08512.5994 | |||
支付处理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款已批准 | 授权用户或系统规则授予支付继续进行的内部里程碑。这不同于外部财务授权,代表了组织内部的签字认可。 | ||
| 为何重要 由于手动工作流和人为延迟,通常是主要的瓶颈来源。 获取方式 记录在工作流审批日志中,或当审批标志设为 true 时。 捕获 记录最终审批动作提交到数据库的时间戳。 事件类型 explicit | |||
| 付款已授权 | 确认资金已预留或可用于交易的财务确认。这通常是与核心银行系统、发卡行或授信机构的交互。 | ||
| 为何重要 在资金实际转移前,确认授权是一个关键控制点。 获取方式 位于网关响应日志或核心银行系统的授权表中。 捕获 提取正向授权响应代码的时间戳。 事件类型 explicit | |||
| 付款已结算 | 财务划转成功完成,资金已记入收款人账户。这是支付交易最主要的成功结束状态。 | ||
| 为何重要 用于计算完整周期时间,并且是流程的主要成功标准。 获取方式 通常由特定的结算状态、确认报告或总账过账指示。 捕获 提取处理结算确认的日期和时间。 事件类型 explicit | |||
| 已创建支付 | 系统中支付交易记录的初始创建。该事件捕捉了支付请求首次记录的时间戳,无论是用户手动输入还是通过 API 调用生成。 | ||
| 为何重要 确立端到端支付周期的起始时间,并作为业务量分析的基准。 获取方式 通常位于主交易表的创建 timestamp 或新记录的专用审计日志条目中。 捕获 提取与支付交易 ID 关联的最早时间戳。 事件类型 explicit | |||
| 支付失败 | 表示支付因无法恢复的技术或财务问题而无法完成的终止状态。这标志着流程实例的彻底结束。 | ||
| 为何重要 衡量可靠性的核心指标;分析此处的模式有助于减少交易中断。 获取方式 从最终失败状态码或严重错误日志中获取。 捕获 识别进入最终失败状态的交易。 事件类型 explicit | |||
| 支付指令已发送 | 将最终确定的支付文件或消息传输至外部支付网络或清算机构。这标志着从内部系统到外部环境的交接。 | ||
| 为何重要 这是一个关键里程碑,用于区分内部处理时间与外部结算时间。 获取方式 在生成文件、向网络发送 API 调用或状态更改为“已传输”时记录。 捕获 识别外发 API 调用或文件传输事件的时间戳。 事件类型 explicit | |||
| 付款已取消 | 用户或管理员在支付结算前进行的有意终止。这会使该笔交易失效。 | ||
| 为何重要 区分“取消”与“失败”对于理解用户行为与系统错误之间的差异非常重要。 获取方式 在执行取消指令或状态变为“作废”时明确记录。 捕获 捕捉取消指令的时间戳。 事件类型 explicit | |||
| 付款已对账 | 将支付系统记录与银行对账单或外部账簿进行匹配的会计过程。这确保了记录系统与实际情况相符。 | ||
| 为何重要 表示交易的管理性关闭和财务完整性。 获取方式 位于对账模块中,或在交易被分配匹配 ID 时推断得出。 捕获 将交易关联至对账表的时间戳。 事件类型 calculated | |||
| 已识别支付错误 | 表示系统或外部验证器标记了支付问题(如余额不足或数据无效)。该事件标志着异常处理循环的开始。 | ||
| 为何重要 对于计算返工率和识别上游数据录入环节的质量问题至关重要。 获取方式 从错误日志、异常表或表示失败/挂起的状态代码中获取。 捕获 根据错误代码或状态更新进行筛选,标记出需要修复的交易。 事件类型 explicit | |||
| 支付已退回 | 发生在已结算支付被冲正时,资金将退回付款人。此活动通常发生在主流程名义上结束后。 | ||
| 为何重要 退款率是衡量底层业务服务或产品质量的关键指标。 获取方式 从关联的退款交易或表示冲正的状态变更中获取。 捕获 识别与原始支付 ID 关联的退款事件。 事件类型 explicit | |||
| 支付被拒绝 | 内部审批人或外部守门人明确拒绝支付请求的事件。这会中止当前流程,并可能触发对发起人的通知。 | ||
| 为何重要 对于分析拒绝原因和减少支付管道中的干扰因素至关重要。 获取方式 在工作流历史中明确记录,或从“已拒绝”等最终状态更新中推断得出。 捕获 捕捉用户或系统创建拒绝事件的具体动作。 事件类型 explicit | |||
| 支付错误已解决 | 标志着对先前识别问题的修正,使支付能够返回正常处理流程。这通常涉及人工干预或自动重试机制。 | ||
| 为何重要 对于衡量解决支付异常所花费的时间和精力至关重要。 获取方式 当交易从错误状态返回处理中或就绪状态时推断得出。 捕获 检测从错误代码恢复到有效处理状态的状态转换。 事件类型 inferred | |||
| 支付验证完成 | 完成对支付指令的自动检查,如格式语法、账号有效性和合规性筛查。该步骤确保数据在进入审批或执行环节之前是准确无误的。 | ||
| 为何重要 此环节耗时过长可能表明外部验证服务缓慢或合规规则复杂。 获取方式 通常在状态从草稿变为已验证时记录,或从验证成功的日志中推断。 捕获 识别表示验证成功的状态变更,或来自合规引擎的特定日志条目。 事件类型 inferred | |||
| 收款已确认 | 收到来自外部网络的系统确认,表示指令已接收且格式有效。这证实了支付已进入外部处理管道。 | ||
| 为何重要 验证向网络的移交是否成功,以及交易是否正在等待结算。 获取方式 从供应商发送的确认消息 (ACK) 或 Webhook 中获取。 捕获 记录接收外部系统确认消息的时间。 事件类型 explicit | |||