您的付款处理数据模板

ACI Worldwide
您的付款处理数据模板

您的付款处理数据模板

此模板为准备付款处理数据以供分析提供了结构化方法,列出需要收集的关键属性、需要跟踪的重要活动,以及从系统中提取这些信息的实用指南。按照这些建议,您可以为发现低效环节、优化财务运营打好基础。
  • 建议收集的属性
  • 需要跟踪的关键活动
  • ACI Worldwide数据提取指南
刚接触事件日志?了解 如何创建流程挖掘事件日志.

付款处理属性

以下是建议纳入事件日志的数据字段,可用于全面分析付款处理流程。
3 必填 9 建议填写 7 选填
名称 说明
事件时间戳
EventTimestamp
活动发生的具体日期和时间。
说明

此属性记录事件在ACI环境中发生的准确时刻,用于计算所有基于时间的指标,包括周期时间、审批时长和吞吐率。建议使用毫秒级精度,以准确排列快速自动化步骤的顺序。

重要性

用于排列事件顺序并计算处理时长。

获取途径

请查看交易历史记录或审计表中的“创建日期”或“更新日期”列。

示例
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
付款交易ID
PaymentTransactionId
用于在ACI系统中唯一标识特定付款指令。
说明

此属性是流程挖掘分析的核心标识,可将同一付款请求的所有事件关联起来。在ACI Worldwide系统(如MTS或UPP)中,它对应于交易录入时分配的唯一参考编号。借助此编号,可以还原付款从初始请求、验证和审批到最终结算的端到端过程。

重要性

这是将离散事件归入各个流程实例所需的基本案例ID。

获取途径

请检查交易主表,相关字段通常命名为TRN_REF、REFERENCE_NUM或UUID,位于主交易日志中。

示例
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
活动名称
ActivityName
付款生命周期中发生的具体步骤或状态变更。
说明

此属性用于定义流程图中的事件节点,例如“已创建付款请求”或“资金已转出”。在ACI系统中,通常根据状态代码、审计日志操作类型或工作流状态变更生成。准确地将这些技术状态映射为易读的业务活动,是有效可视化的关键。

重要性

此属性定义流程顺序,是可视化操作顺序的必要条件。

获取途径

根据状态代码(例如100=已创建、200=已验证)或审计日志中的操作列生成。

示例
已创建付款请求付款已授权付款已结算付款失败
事件用户
EventUser
负责执行该活动的用户ID或系统代理。
说明

记录操作执行者,可能是人工用户(例如审批人员),也可能是系统账户(例如自动结算账户)。此属性对于“瓶颈分析”至关重要,可用于识别工作负荷过重的特定用户或队列。

重要性

支持资源分析和职责分离审计。

获取途径

审计日志或交易表中的“UpdatedBy”列。

示例
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
付款到期日
PaymentDueDate
付款必须完成结算才能视为按时的日期。
说明

记录合同约定或请求的执行日期。将此日期与实际结算日期比较,可计算“按时付款率”KPI,并支持“付款到期日合规”仪表板。

重要性

衡量SLA合规情况和按时绩效的基准。

获取途径

交易指令中的字段,通常为VALUE_DATE、EXECUTION_DATE或DUE_DATE。

示例
2023-11-012023-11-05
付款币种
PaymentCurrency
付款金额所用的ISO货币代码。
说明

指定PaymentAmount使用的币种(例如USD、EUR、GBP)。在汇总不同地区交易量的仪表板中,必须使用此属性对数据进行标准化。它也有助于了解跨境付款的复杂性。

重要性

正确解读付款金额所必需的信息。

获取途径

交易明细表中的字段,通常为CCY、CURRENCY_CODE或ISO_CODE。

示例
USDEURGBPJPY
付款类型
PaymentType
付款工具的类别。
说明

对付款进行分类(例如电汇、ACH、SEPA、RTGS)。不同付款类型的SLA和流程往往差异很大。此属性是筛选“端到端付款周期时间”仪表板的主要维度。

重要性

对于区分高速付款流程和批量付款流程至关重要。

获取途径

交易主表中的字段,例如PMT_TYPE、INSTRUMENT_TYPE或SERVICE_ID。

示例
境内电汇国际电汇ACH贷记即时付款
付款金额
PaymentAmount
付款交易的金额。
说明

表示转账金额,是分析“付款吞吐量”和优先呈现瓶颈的重要背景信息。与低金额的自动化流程相比,高金额付款通常需要经过更严格的审批路径(变体分析)。

重要性

支持按金额分组,并计算已处理总额。

获取途径

交易明细表中的字段,通常为AMT、TRANS_AMOUNT或PRINCIPAL_AMOUNT。

示例
1500.00250000.5050.001000000.00
处理渠道
ProcessingChannel
发起付款所使用的渠道。
说明

表示付款的入口,例如移动端、Web门户、API或文件上传。通过“付款流程变体分析”,可以比较不同渠道的错误率和延误情况。

重要性

按输入方式细分绩效。

获取途径

交易主表中的字段,通常命名为CHANNEL、SOURCE_TYPE或INPUT_METHOD。

示例
SWIFT网上银行移动应用文件上传
是否返工
IsRework
用于标记付款是否经历了重复活动。
说明

在数据处理过程中计算的布尔标记。如果“付款详细信息已验证”等活动发生多次,或检测到错误循环,则设为true。此标记用于计算“付款返工率”KPI。

重要性

无需编写复杂的流程查询,即可快速识别效率低下的案例。

获取途径

在数据管道中检查每个案例是否存在重复活动后计算得出。

示例
truefalse
部门
Department
负责当前活动的内部部门。
说明

将EventUser或队列映射到更广泛的组织单位(例如“付款运营”“合规”“资金管理”)。通过“按活动分析瓶颈”,可以查看哪些团队拖慢了流程。

重要性

按业务职能汇总绩效。

获取途径

根据用户表或组织层级映射生成。

示例
运营Compliance资金管理IT支持
错误代码
ErrorCode
付款失败或需要修复时生成的代码。
说明

记录“付款失败”或“发现付款错误”事件的具体原因。在“付款失败与返工分析”仪表板中按此属性分组,可帮助业务团队找出最常见的失败根因(例如“资金不足”“账户无效”)。

重要性

分析流程失败根因的重要依据。

获取途径

错误日志或状态原因列,通常为REASON_CODE或RETURN_CODE。

示例
R01AM04BE05TECH_ERR_001
付款是否逾期
IsPaymentLate
用于标记付款是否在到期日之后完成结算。
说明

通过比较实际结算日期与PaymentDueDate计算得出的布尔标记。用于计算“付款到期日合规”仪表板指标并识别SLA违约情况。

重要性

简化合规报告。

获取途径

计算方式:SettlementDate > PaymentDueDate。

示例
truefalse
发起地区
OriginatingRegion
付款请求的发起地区。
说明

表示请求方所在的实际或逻辑位置。通过“付款流程变体分析”,可以查看特定地区是否采用非标准路径或拒绝率较高。

重要性

为流程绩效提供地理背景信息。

获取途径

交易主表中的信息,通常根据分支机构代码或国家代码生成。

示例
北美欧洲、中东和非洲亚太地区
审批周期时间
ApprovalCycleTime
审批阶段所用的时长。
说明

计算“付款已提交审批”到“付款已批准”(或被拒绝)之间的时长。此指标用于“付款审批周期时间分析”仪表板,突出显示人工决策环节的延误。

重要性

单独衡量依赖人工的流程环节。

获取途径

计算方式:Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval)。

示例
4小时15分钟
对账ID
ReconciliationId
用于将付款关联到总账或对账记录的标识符。
说明

发生“付款已对账”活动时填入此ID,用于确保处理引擎中的付款与会计系统中的记录相匹配。已结算付款缺少此ID,表示对账可能失败。

重要性

“付款对账效率”仪表板的重要依据。

获取途径

对账表中的字段,例如RECON_REF或GL_REF。

示例
REC-9921GL-Entry-2023-11
收款方名称
BeneficiaryName
接收付款的实体名称。
说明

标识交易对手。分析此字段有助于找出返工率较高或延误较多的特定供应商或客户,为“付款失败与返工分析”提供依据。

重要性

标识付款对象,便于开展以客户为中心的分析。

获取途径

付款明细行中的字段,例如CREDITOR_NAME、BENE_NAME或PAYEE。

示例
Acme CorpGlobal Supplies LtdJohn Smith
数据最后更新时间
LastDataUpdate
记录上次提取或在数据模型中更新的时间戳。
说明

用于跟踪分析所用数据的新鲜度。它不代表流程事件发生的时间,而是数据载入的技术时间,帮助分析人员判断查看的是实时数据还是历史快照。

重要性

确保数据保持最新,并帮助识别仪表板中的过期数据。

获取途径

ETL脚本运行时的系统时间。

示例
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
源系统
SourceSystem
事件数据来源系统的名称。
说明

用于标识ACI Worldwide生态系统中的具体应用或模块(例如ACI MTS、ACI UPF),以及流程涉及的外部系统。在整合多个分类账的数据,或付款涉及外部清算机构时,这一属性尤为重要。

重要性

说明数据的提取来源,有助于排查数据血缘问题。

获取途径

提取时硬编码,或在存在多个实例时根据SystemID列生成。

示例
ACI MTSACI UPPSAP GLSwift Gateway
必填 建议填写 选填

付款处理活动

以下是建议记录在事件日志中的关键流程步骤和里程碑,可帮助准确发现付款处理流程。
6 建议填写 8 选填
活动 说明
付款已批准
这是一个关键里程碑:授权用户批准付款后,交易即可进入执行阶段。通常,审批人通过系统界面执行操作时会记录明确事件。
重要性

此活动是一个重要检查点,也常常是显著的瓶颈。分析此步骤前的等待时间和审批周期时长,有助于发现加快付款处理的机会。

获取途径

请查找审批日志表中的明确事件,或主交易表中与特定用户操作和时间戳关联的“已批准”状态变更。

采集

授权用户在系统中完成审批操作时记录。

事件类型 explicit
付款已授权
表示人工审批后系统对付款进行授权,并验证资金或检查欺诈规则。系统可能会记录明确日志,也可以根据表示付款已准备执行的状态变更推断。
重要性

这是指示资金转出的关键控制点。此阶段的延误可能表明系统性能存在问题,或合规与欺诈检查子系统运行异常。

获取途径

请检查系统处理日志或安全日志中的明确记录。也可以根据状态从“已批准”变为“已授权付款”推断。

采集

支付引擎通过最终内部检查后记录。

事件类型 explicit
付款已结算
这是付款流程完成且资金已记入收款人账户的最终确认,标志着交易结束。这是一个关键事件,代表支付生命周期成功完成。
重要性

这是流程的主要成功结束事件,用于计算整体周期时间和处理量,也是几乎所有端到端绩效仪表板的重要数据。

获取途径

通常在收到网络发来的最终结算确认消息,或内部分类账更新以反映交易完成时,记录明确事件。

采集

收到最终结算文件或消息时记录,并将状态更新为“已结算”。

事件类型 explicit
发现付款错误
表示系统在某个阶段检测到付款问题,例如数据无效或触发合规警报。通常会明确记录此事件,并附带相应的错误代码。
重要性

此活动是分析返工和异常处理的起点,也是“付款失败与返工分析”和“错误解决周期时间”仪表板的重要依据。

获取途径

请查找错误日志表中的明确记录,或交易表中状态变为“错误”或“需要更正”的记录。这些事件应关联到付款交易ID。

采集

系统的验证或处理引擎发现错误时,会明确记录相应事件。

事件类型 explicit
已创建付款请求
此活动表示在ACI Worldwide系统中发起了一笔新的支付交易。通常,用户或上游系统提交付款请求时会记录明确事件,并创建带有唯一ID的新交易记录。
重要性

这是支付流程的主要开始事件。分析从此活动到流程完成的时间,可以得出端到端周期时间,这是衡量整体流程效率的重要指标。

获取途径

这通常是ACI核心交易表或专用事件日志中记录的明确事件。请查找与付款交易ID关联的创建时间戳。

采集

可通过创建记录或交易日志中的明确“创建”事件识别。

事件类型 explicit
资金已转出
表示已收到支付网络的确认,付款方账户中的资金已成功扣除。通常会根据网络发来的状态消息记录此活动。
重要性

确认外部网络已成功执行付款。此活动标志着结算周期开始,也是“付款平均结算时间”关键绩效指标的重要数据。

获取途径

这是由收到的状态更新消息触发的明确事件,例如SWIFT发送的MT103或ACH确认消息,并会更新付款记录。

采集

收到清算网络发来的外部确认消息时记录。

事件类型 explicit
付款失败
表示付款因无法恢复的问题而无法完成的终止状态。这不同于可解决的错误,代表流程以明确失败告终。
重要性

跟踪此结束事件对于计算整体付款失败率至关重要。分析失败原因有助于提升数据质量并改进流程规则。

获取途径

根据交易数据中的“失败”“已取消”或“银行拒绝”等最终终止状态推断,且此后状态不再变化。

采集

根据付款记录中的终止失败状态推断。

事件类型 inferred
付款已对账
表示会计处理的最后一步,即将ACI中记录的付款交易与银行对账单或分类账分录进行匹配。此事件可以由对账模块明确记录,也可以根据状态变更推断。
重要性

此活动用于衡量后台对账流程的效率。延误可能影响财务报告的准确性,也可能掩盖尚未结算的付款问题。

获取途径

此信息可能来自ACI专用对账模块或外部ERP系统,可通过将付款记录的状态更新为“已对账”来记录。

采集

根据最终状态更新为“已对账”推断,或通过付款ID关联对账数据推断。

事件类型 inferred
付款已拒绝
审批人拒绝付款请求时会发生此活动,通常需要更正后重新提交。这是一个明确事件,会中断付款流程的正常推进并触发返工循环。
重要性

用于识别返工和流程低效问题。跟踪拒绝频率有助于诊断初始数据质量或提交政策方面的问题,为返工分析提供依据。

获取途径

此活动会作为明确事件记录在审批日志中,或通过交易表中的“已拒绝”状态变更记录。事件中可能包含拒绝原因代码。

采集

审批人完成拒绝操作时记录。

事件类型 explicit
付款已提交审批
表示付款已通过初步验证,并已提交给管理人员或财务人员审批。通常会通过付款工作流中的状态变更记录此活动。
重要性

这标志着审批子流程的开始。从此时到“付款已批准”的耗时,是“付款审批周期时间分析”仪表板的重要指标。

获取途径

可根据交易数据中的付款状态字段变更推断,例如状态变为“待审批”。

采集

可根据状态变为“待审批”或类似状态及相应时间戳推断。

事件类型 inferred
付款已确认
表示系统内部确认付款已成功处理并收到确认消息。此活动通常会触发向收款人或其他内部系统发送通知。
重要性

这一里程碑对于衡量付款到期日达成情况和按时付款率至关重要。它明确记录了组织认定付款已成功执行的时间。

获取途径

通常可根据收到外部网络确认后,付款交易表中的状态变为“已确认”或“已完成”推断。

采集

可根据状态变为“已确认”或“已处理”推断。

事件类型 inferred
付款指令已发送
表示付款指令已编制完成并发送至SWIFT、ACH或SEPA等外部支付网络。ACI系统会明确记录这一交接,以便审计和跟踪。
重要性

对于许多付款类型,这是“不可逆转的节点”。跟踪此活动有助于衡量外部依赖方接手前的内部处理时间。

获取途径

这几乎总是ACI交易日志或消息日志中的明确事件,通常还包含网络专用参考编号。

采集

付款消息发送至外部网络时会生成明确的日志记录。

事件类型 explicit
付款详情已验证
表示已完成自动或人工检查,以确保收款人信息、银行代码等付款详情准确无误。通常可根据交易状态从“新建”变为“已验证”或“待审批”推断此活动。
重要性

用于跟踪初始数据验证步骤的效率。此处的延误可能造成上游瓶颈,并增加流程后续环节发生付款错误的可能性。

获取途径

可根据主付款交易表中的状态变更字段推断。比较“已创建”状态与后续“已验证”或类似状态的时间戳。

采集

可根据付款状态字段的变化推断,例如从“已录入”变为“已验证”。

事件类型 inferred
付款错误已解决
标记用户更正先前发现的错误并重新提交付款进行处理的时间点。通常可根据付款状态从错误状态恢复为正常处理状态来推断。
重要性

此活动标志着异常处理闭环。 “发现付款错误”到此事件之间的时长即为错误解决周期时间,是衡量运营效率的重要指标。

获取途径

可根据状态从“错误”变为“待审批”或“已验证”等处理状态来推断,也可以依据明确记录的用户操作推断。

采集

根据状态从错误状态变更为其他状态推断,表明错误已更正。

事件类型 inferred
建议填写 选填

数据提取指南

如何从ACI Worldwide获取数据

准备好开始了吗?

使用此模板开始提取付款处理数据。立即发掘有价值的洞察,提升财务工作流效率。

精简付款处理流程:立即开始免费试用

减少付款异常,实现98%的直通式处理。

开始免费试用

无需信用卡,几分钟即可完成设置