您的付款处理数据模板
您的付款处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ACI Worldwide数据提取指南
付款处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 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货币代码。 | ||
| 说明 指定 重要性 正确解读付款金额所必需的信息。 获取途径 交易明细表中的字段,通常为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 | 负责当前活动的内部部门。 | ||
| 说明 将 重要性 按业务职能汇总绩效。 获取途径 根据用户表或组织层级映射生成。 示例 运营Compliance资金管理IT支持 | |||
| 错误代码 ErrorCode | 付款失败或需要修复时生成的代码。 | ||
| 说明 记录“付款失败”或“发现付款错误”事件的具体原因。在“付款失败与返工分析”仪表板中按此属性分组,可帮助业务团队找出最常见的失败根因(例如“资金不足”“账户无效”)。 重要性 分析流程失败根因的重要依据。 获取途径 错误日志或状态原因列,通常为REASON_CODE或RETURN_CODE。 示例 R01AM04BE05TECH_ERR_001 | |||
| 付款是否逾期 IsPaymentLate | 用于标记付款是否在到期日之后完成结算。 | ||
| 说明 通过比较实际结算日期与 重要性 简化合规报告。 获取途径 计算方式: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 | |||
付款处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已批准 | 这是一个关键里程碑:授权用户批准付款后,交易即可进入执行阶段。通常,审批人通过系统界面执行操作时会记录明确事件。 | ||
| 重要性 此活动是一个重要检查点,也常常是显著的瓶颈。分析此步骤前的等待时间和审批周期时长,有助于发现加快付款处理的机会。 获取途径 请查找审批日志表中的明确事件,或主交易表中与特定用户操作和时间戳关联的“已批准”状态变更。 采集 授权用户在系统中完成审批操作时记录。 事件类型 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 | |||
数据提取指南
步骤
访问数据库环境:使用SQL Server Management Studio(SSMS)或兼容客户端,登录承载ACI Postilion Realtime数据库的SQL Server实例。
查找核心表:找到
post_tran(交易日志)和post_tran_cust(自定义数据扩展)表。确保您对这些对象拥有SELECT权限。确定案例标识符:此提取方案使用
retrieval_reference_nr作为PaymentTransactionId。如果您的实现使用其他唯一键(例如system_trace_audit_nr与transmission_date_time组合),请相应调整查询中的字段选择。配置筛选参数:打开下方提供的查询,找到脚本顶部的
@StartDate和@EndDate变量。将其设为所需的提取时间范围(例如最近30至90天),以优化性能。检查活动逻辑:查询会将ISO 8583消息类型(例如0200、0210)和响应代码映射为所需的14项流程挖掘活动。检查
CASE语句,确保其符合您的ACI接口配置。运行查询:执行完整脚本。查询使用
UNION ALL将不同交易状态统一为单一事件日志格式。验证输出数据:检查结果是否包含所需列:
PaymentTransactionId、ActivityName和EventTimestamp。确认关键字段没有意外出现NULL值。导出数据:在SSMS中右键单击结果网格,将输出保存为CSV文件(例如
ACI_Payments_EventLog.csv)。整理ProcessMind所需格式:打开CSV,确认
EventTimestamp采用标准格式(YYYY-MM-DD HH:MM:SS),且PaymentAmount仅包含数值。上传:将验证后的CSV导入ProcessMind,分别将列映射到案例ID、活动和时间戳。
配置
- 日期范围:ACI的
post_tran表增长很快。强烈建议将提取范围限制为滚动3个月,或在可用时使用分区切换。 - 响应代码:查询假定
rsp_code = '00'表示成功。如果您的机构使用其他批准/成功代码(例如'08'或'10'),请更新筛选条件。 - 消息类型(ISO 8583):脚本使用标准消息类型(请求为0100/0200,响应为0210)。如果
source_node_name配置中定义了自定义消息类型,可能需要调整。 - 系统性能:此查询使用
NOLOCK提示,避免阻塞实时交易处理。在生产环境中请勿移除这些提示。 - 币种:提取的金额为原始数值。如需在分析中统一多种币种,请确保使用
tran_currency_code。
查询示例 sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; 精简付款处理流程:立即开始免费试用
减少付款异常,实现98%的直通式处理。
无需信用卡,几分钟即可完成设置