您的支付处理数据模板
您的支付处理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- ACI Worldwide数据提取指南
支付处理属性
| 名称 | 说明 | ||
|---|---|---|---|
| 事件时间戳 EventTimestamp | 活动发生的具体日期和时间。 | ||
| 说明 此属性记录事件在ACI环境中发生的准确时刻,用于计算所有基于时间的指标,包括周期时间、审批时长和吞吐率。为准确排列快速自动化步骤的顺序,建议使用高精度时间戳(毫秒)。 为什么重要 用于排列事件顺序和计算绩效时长。 获取位置 查看交易历史表或审计表中的“Created Date”或“Update Date”列。 示例 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| 付款交易ID PaymentTransactionId | ACI系统中用于标识特定付款指令的唯一标识符。 | ||
| 说明 此属性是流程挖掘分析的核心键,用于关联单笔付款请求的所有事件。在ACI Worldwide系统(如MTS或UPP)中,它对应交易录入时分配的唯一参考编号。借助该标识符,可以重建从初始请求、验证、审批到最终结算的端到端付款旅程。 为什么重要 这是将离散事件归入流程实例所需的基础Case ID。 获取位置 检查交易头表,主交易日志中通常标记为TRN_REF、REFERENCE_NUM或UUID。 示例 TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| 活动名称 ActivityName | 付款生命周期中发生的具体步骤或状态变更。 | ||
| 说明 此属性定义流程图中的事件节点,例如“Payment Request Created”或“Funds Transferred”。在ACI系统中,通常根据状态码、审计日志操作类型或工作流状态变更生成。将这些技术状态准确映射为易读的业务活动,是实现有效可视化的关键。 为什么重要 该字段定义流程顺序,是可视化操作顺序的必要信息。 获取位置 根据状态码(例如100=Created、200=Validated)或审计日志中的Action列生成。 示例 创建付款请求授权付款付款已结算付款失败 | |||
| 事件用户 EventUser | 负责执行活动的用户ID或系统代理。 | ||
| 说明 记录操作执行者,可能是人工用户(例如审批人员),也可能是系统账户(例如自动结算账户)。此属性对于“瓶颈分析”至关重要,可用于识别特定用户或队列是否超负荷。 为什么重要 支持资源分析和职责分离审计。 获取位置 审计日志或交易表中的“UpdatedBy”列。 示例 SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| 付款到期日 PaymentDueDate | 付款必须完成结算才能被视为按时完成的日期。 | ||
| 说明 存储合同约定或请求的执行日期。该日期与实际结算日期进行比较,用于计算“On-Time Payment Rate”KPI,并支持“Payment Due Date Compliance”仪表板。 为什么重要 衡量SLA合规性和按时绩效的基准。 获取位置 交易指令中的日期字段,通常为VALUE_DATE、EXECUTION_DATE或DUE_DATE。 示例 2023-11-012023-11-05 | |||
| 付款币种 PaymentCurrency | 付款金额对应的ISO货币代码。 | ||
| 说明 指定 为什么重要 正确解读付款金额所必需。 获取位置 交易明细表,通常包含CCY、CURRENCY_CODE或ISO_CODE等字段。 示例 USDEURGBPJPY | |||
| 付款类型 PaymentType | 付款工具的分类。 | ||
| 说明 用于对付款进行分类(例如Wire、ACH、SEPA、RTGS)。不同付款类型的SLA和流程通常差异很大。此属性是“End-to-End Payment Cycle Time”仪表板的主要筛选维度。 为什么重要 对于区分高速付款流程和批量付款流程至关重要。 获取位置 交易头信息,字段包括PMT_TYPE、INSTRUMENT_TYPE或SERVICE_ID。 示例 境内电汇国际电汇ACH贷记即时支付 | |||
| 付款金额 PaymentAmount | 付款交易的货币价值。 | ||
| 说明 表示转移的资金价值,是分析“Payments Throughput”和确定瓶颈优先级的重要上下文字段。与低金额自动化流程相比,高金额付款通常需要经过更严格的审批路径(变体分析)。 为什么重要 支持按金额分段,并计算已处理总量。 获取位置 交易明细表,通常包含AMT、TRANS_AMOUNT或PRINCIPAL_AMOUNT等字段。 示例 1500.00250000.5050.001000000.00 | |||
| 处理渠道 ProcessingChannel | 发起付款所使用的渠道。 | ||
| 说明 表示付款入口,例如移动端、Web门户、API或文件上传。通过“Payment Process Variant Analysis”,可以判断某些渠道是否更容易出现错误或延迟。 为什么重要 按输入方式细分绩效。 获取位置 交易头信息,通常位于CHANNEL、SOURCE_TYPE或INPUT_METHOD列。 示例 SWIFT网上银行移动应用文件上传 | |||
| 是否返工 IsRework | 标记付款是否经历了重复活动。 | ||
| 说明 在数据处理过程中计算的布尔标记。如果“Payment Details Validated”等活动发生多次,或检测到错误循环,则设为true。该字段用于驱动“Payment Rework Rate”KPI。 为什么重要 无需编写复杂流程查询,即可快速识别低效案例。 获取位置 在数据管道中通过检查每个案例是否存在重复活动来计算。 示例 truefalse | |||
| 部门 Department | 负责当前活动的内部部门。 | ||
| 说明 将 为什么重要 按业务职能汇总绩效。 获取位置 根据用户表或组织层级映射生成。 示例 运营Compliance资金管理IT支持 | |||
| 错误代码 ErrorCode | 付款失败或需要修复时生成的代码。 | ||
| 说明 记录“Payment Failed”或“Payment Error Identified”事件的具体原因。在“Payment Failure and Rework Analysis”仪表板中按此属性分组,可帮助业务识别最常见的失败根因(例如“Insufficient Funds”“Invalid Account”)。 为什么重要 流程失败根因分析所必需。 获取位置 错误日志或状态原因列,通常为REASON_CODE或RETURN_CODE。 示例 R01AM04BE05TECH_ERR_001 | |||
| 付款是否逾期 IsPaymentLate | 标记付款是否在到期日之后完成结算。 | ||
| 说明 通过将实际结算日期与 为什么重要 简化合规报告。 获取位置 计算方式:SettlementDate > PaymentDueDate。 示例 truefalse | |||
| 最后数据更新时间 LastDataUpdate | 记录在数据模型中最后一次提取或更新的时间戳。 | ||
| 说明 用于跟踪分析数据的新鲜度。它不代表流程事件发生时间,而是数据摄取的技术时间,帮助分析人员判断当前查看的是实时数据还是历史快照。 为什么重要 确保数据及时更新,并帮助识别仪表板中的过期数据。 获取位置 ETL脚本执行时的系统时间。 示例 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| 发起地区 OriginatingRegion | 付款请求发起的地理区域。 | ||
| 说明 表示请求方所在的物理或逻辑位置。通过“Payment Process Variant Analysis”,可以判断特定地区是否遵循非标准路径或经历更高的拒绝率。 为什么重要 为流程绩效提供地理背景。 获取位置 交易头信息,通常根据分支机构代码或国家代码生成。 示例 北美欧洲、中东和非洲亚太地区 | |||
| 审批周期时间 ApprovalCycleTime | 审批阶段所耗费的时长。 | ||
| 说明 计算从“Payment Sent For Approval”到“Payment Approved”(或Rejected)之间的时间。该指标用于“Payment Approval Cycle Time Analysis”仪表板,突出显示人工决策环节中的延迟。 为什么重要 隔离流程中依赖人工的部分。 获取位置 计算方式:Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval)。 示例 4小时15分钟 | |||
| 对账ID ReconciliationId | 将付款与总账或对账记录关联的标识符。 | ||
| 说明 发生“Payment Reconciled”活动时填充此ID,用于确保处理引擎中的付款与会计系统中的分录相匹配。已结算付款缺少此ID,表示对账失败。 为什么重要 “Payment Reconciliation Efficiency”仪表板的关键字段。 获取位置 对账表或RECON_REF、GL_REF等特定字段。 示例 REC-9921GL-Entry-2023-11 | |||
| 收款方名称 BeneficiaryName | 接收付款的实体名称。 | ||
| 说明 用于标识交易对手方。分析此字段有助于识别与高返工率或延迟相关的特定供应商或客户,并支持“Payment Failure and Rework Analysis”。 为什么重要 标识付款对象,适用于以客户为中心的分析。 获取位置 付款明细行,字段包括CREDITOR_NAME、BENE_NAME或PAYEE。 示例 Acme公司Global Supplies有限公司John Smith | |||
| 源系统 SourceSystem | 事件数据来源系统的名称。 | ||
| 说明 用于标识ACI Worldwide生态中的具体应用或模块(例如ACI MTS、ACI UPF),以及流程涉及的外部系统。当需要整合多个分类账的数据,或付款经过外部清算机构时,该属性尤为重要。 为什么重要 提供数据提取位置的上下文,有助于排查数据血缘问题。 获取位置 在提取时硬编码,或在存在多个实例时根据SystemID列生成。 示例 ACI MTSACI UPPSAP GLSwift Gateway | |||
支付处理活动
| 活动 | 说明 | ||
|---|---|---|---|
| 付款已结算 | 这是付款流程完成且资金已记入收款人账户的最终确认,标志着交易结束。这是一个关键事件,代表付款生命周期成功终止。 | ||
| 为什么重要 这是流程主要的成功结束事件。它用于计算整体周期时间和吞吐量,也是几乎所有端到端绩效仪表板的关键数据。 获取位置 通常在收到网络发来的最终结算确认消息,或内部分类账更新以反映交易完成时,记录为明确事件。 采集 收到最终结算文件或消息后记录,并将状态更新为“Settled”。 事件类型 explicit | |||
| 创建付款请求 | 此活动表示在ACI Worldwide系统中发起新的付款交易。通常,当用户或上游系统提交付款请求时,系统会记录一个明确事件,并创建带有唯一ID的新交易记录。 | ||
| 为什么重要 这是付款流程的主要开始事件。分析从此活动到流程完成的时间,可以得到端到端周期时间,这是衡量整体流程效率的关键指标。 获取位置 这通常是ACI核心交易表或专用事件日志中记录的明确事件。请查找与Payment Transaction ID关联的创建时间戳。 采集 通过创建记录或交易日志中的明确“Create”事件识别。 事件类型 explicit | |||
| 批准付款 | 这是一个关键里程碑:授权用户批准付款,使其能够进入执行阶段。通常,当审批人在系统用户界面中执行操作时,系统会记录一个明确事件。 | ||
| 为什么重要 此活动是重要检查点,也常常是显著瓶颈。分析此步骤前的等待时间和审批周期时长,有助于发现加快付款的机会。 获取位置 请在审批日志表中查找明确事件,或在主交易表中查找与特定用户操作和时间戳关联的“Approved”状态变更。 采集 授权用户在系统中完成审批操作时记录。 事件类型 explicit | |||
| 授权付款 | 表示人工审批后系统对付款进行授权,包括验证资金或根据反欺诈规则进行检查。它可以是明确的日志记录,也可以根据表示付款已准备执行的状态变更推断。 | ||
| 为什么重要 这是资金发出转移指令前的关键控制点。此阶段的延迟可能表明系统性能问题,或合规与欺诈检查子系统存在问题。 获取位置 请在系统处理日志或安全日志中查找明确记录。也可以根据状态从“Approved”更新为“Authorized for Payment”进行推断。 采集 通过最终内部检查后,由系统的支付引擎记录。 事件类型 explicit | |||
| 识别付款错误 | 表示系统在某个阶段检测到付款问题,例如数据无效或触发合规警报。通常会以带有关联错误代码的明确事件记录。 | ||
| 为什么重要 此活动是所有返工和异常处理分析的起点,对于“Payment Failure and Rework Analysis”和“Error Resolution Cycle Time”仪表板至关重要。 获取位置 请在错误日志表中查找明确记录,或在交易表中查找状态变更为“Error”或“Requires Correction”的事件。这些事件应与Payment Transaction ID关联。 采集 系统校验或处理引擎标记错误时,会记录明确事件。 事件类型 explicit | |||
| 资金已转移 | 表示已收到支付网络的确认,付款方账户中的资金已成功扣除。通常根据网络发来的入站状态消息记录。 | ||
| 为什么重要 确认外部网络已成功执行付款。它标志着结算周期开始,也是“Average Payment Settlement Time”KPI的重要输入。 获取位置 这是由入站状态更新消息触发的明确事件,例如SWIFT发送的MT103或ACH确认消息,该消息会更新付款记录。 采集 收到清算网络发来的外部确认消息后记录。 事件类型 explicit | |||
| 付款失败 | 表示付款因无法恢复的问题而无法完成的终止状态。它不同于可解决的错误,代表明确的失败结束状态。 | ||
| 为什么重要 跟踪这一结束事件对于计算整体付款失败率至关重要。分析失败原因有助于改进数据质量和流程规则。 获取位置 根据交易数据中的最终终止状态推断,例如“Failed”“Cancelled”或“Rejected by Bank”,且该状态之后不再变化。 采集 根据付款记录中的终止失败状态推断。 事件类型 inferred | |||
| 付款已对账 | 表示最终的会计处理步骤,即将ACI中记录的付款交易与银行对账单或分类账分录进行匹配。该事件可以来自对账模块的明确记录,也可以根据状态变更推断。 | ||
| 为什么重要 此活动用于衡量后台对账流程的效率。此处的延迟可能影响财务报告的准确性,并掩盖尚未结算的付款问题。 获取位置 该信息可能来自ACI内部的专用对账模块或外部ERP系统,通常通过将付款记录更新为“Reconciled”状态来采集。 采集 根据最终的“Reconciled”状态更新,或通过Payment ID关联的对账数据推断。 事件类型 inferred | |||
| 发送付款指令 | 表示付款指令已编制完成,并传输至SWIFT、ACH或SEPA等外部支付网络。ACI系统会明确记录这一交接,以便审计和跟踪。 | ||
| 为什么重要 对于许多付款类型,这是“不可逆点”。跟踪该节点有助于衡量外部依赖接管前的内部处理时间。 获取位置 这几乎总是ACI交易日志或消息日志中的明确事件,通常还包括网络专用参考编号。 采集 付款消息发送至外部网络时,会创建明确的日志记录。 事件类型 explicit | |||
| 拒绝付款 | 当审批人拒绝付款请求时发生,通常需要更正后重新提交。这是一个明确事件,会中断付款的正常推进,并启动返工循环。 | ||
| 为什么重要 用于识别返工和流程低效。跟踪拒绝频率有助于诊断初始数据质量或提交政策问题,并支持返工分析。 获取位置 在审批日志中记录为明确事件,或在交易表中记录为“Rejected”状态变更。事件可能包含拒绝原因代码。 采集 审批人在系统中完成拒绝操作时记录。 事件类型 explicit | |||
| 提交付款以供审批 | 表示付款已通过初始校验,并已提交至必要的管理或财务审批环节。通常通过付款工作流中的状态变更记录。 | ||
| 为什么重要 这标志着审批子流程的开始。从此时到“Payment Approved”的时间,对于“Payment Approval Cycle Time Analysis”仪表板至关重要。 获取位置 根据交易数据中的付款状态字段变化推断,例如状态变为“Pending Approval”。 采集 根据状态变更为“Pending Approval”或类似状态,并结合对应时间戳推断。 事件类型 inferred | |||
| 确认付款 | 表示系统内部确认付款已成功处理并已收到确认。这通常会触发通知收款人或其他内部系统。 | ||
| 为什么重要 这一里程碑对于衡量到期日合规性和On-Time Payment Rate至关重要。它提供了组织认定付款成功执行的明确时间戳。 获取位置 通常根据收到外部网络确认后,付款交易表中的状态变更为“Confirmed”或“Completed”进行推断。 采集 根据状态变更为“Confirmed”或“Processed”推断。 事件类型 inferred | |||
| 解决付款错误 | 标记此前识别的错误已由用户修正,且付款已重新提交处理的节点。通常可根据付款状态从错误状态恢复为正常处理状态来推断。 | ||
| 为什么重要 此活动结束异常处理闭环。从“Payment Error Identified”到此事件之间的时间即为错误解决周期时间,是衡量运营效率的关键指标。 获取位置 根据状态从“Error”变更为“Pending Approval”或“Validated”等处理状态推断。也可能是明确记录的用户操作日志。 采集 根据状态从错误状态变更来推断,表示错误已得到修正。 事件类型 inferred | |||
| 验证付款详情 | 表示自动或人工检查已完成,以确保收款人信息、银行代码等付款详情准确无误。通常可通过交易状态从“New”变为“Validated”或“Pending Approval”来推断此活动。 | ||
| 为什么重要 用于跟踪初始数据校验步骤的效率。此处的延迟可能形成上游瓶颈,并增加流程后续发生付款错误的可能性。 获取位置 根据主付款交易表中的状态变更字段推断。比较“Created”状态与后续“Validated”或类似状态之间的时间戳。 采集 根据付款状态字段的变化推断,例如从“Entered”变为“Validated”。 事件类型 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、活动和时间戳。
配置
- Date Range:ACI的
post_tran表增长非常快。强烈建议将提取范围限制为滚动3个月,或在可用时使用分区切换。 - Response Codes:查询假设
rsp_code = '00'表示成功。如果您的机构使用其他批准/成功代码(例如'08'或'10'),请更新筛选条件。 - Message Types(ISO 8583):脚本依赖标准消息类型(0100/0200表示请求,0210表示响应)。在
source_node_name配置中定义的自定义消息类型可能需要调整。 - System Performance:查询使用
NOLOCK提示以避免阻塞实时交易处理。在生产环境中请勿删除这些提示。 - Currencies:金额以原始数值提取。如需在分析中进行多币种标准化,请确保使用
tran_currency_code。
a 示例查询 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%的直通式处理。
无需信用卡,几分钟即可完成设置