您的支付处理数据模板
您的支付处理数据模板
- 建议收集的属性
- 需要追踪的关键活动
- 针对 ACI Worldwide 的数据提取指南
支付处理属性
| 名称 | 描述 | ||
|---|---|---|---|
| 事件timestamp EventTimestamp | 活动发生的具体日期和时间。 | ||
| 描述 此属性记录了 ACI 环境中 event 发生的准确时刻。它用于计算所有基于时间的指标,包括周期时间、审批时长和吞吐率。建议使用高精度(毫秒),以便准确排列快速自动步骤的顺序。 为何重要 对于事件排序和计算绩效时长至关重要。 获取方式 咨询交易历史或审计表中的“创建日期”或“更新日期”列。 示例 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| 支付交易 ID PaymentTransactionId | ACI 系统中特定支付指令的唯一标识符。 | ||
| 描述 此属性是流程挖掘分析的核心 key,它将与单个支付请求相关的所有 event 联系起来。在 ACI Worldwide 系统(如 MTS 或 UPP)中,这对应于交易进入时分配的唯一参考号。它能够还原从最初请求到验证、审批及最终结算的端到端支付路径。 为何重要 它是将离散事件分组为流程实例所需的基础 Case ID。 获取方式 检查交易表头,在主交易日志中通常标记为 TRN_REF、REFERENCE_NUM 或 UUID。 示例 TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| 活动名称 ActivityName | 支付生命周期中发生的特定步骤或状态变更。 | ||
| 描述 此属性定义了流程图中的 event 节点,例如“支付请求已创建”或“资金已转账”。在 ACI 系统中,这通常源自状态码、审计日志操作类型或 workflow 状态变更。将这些技术状态准确映射为易读的业务活动,对于实现有意义的可视化至关重要。 为何重要 它定义了流程流向,是可视化操作序列的必要条件。 获取方式 源自状态码(如 100=已创建,200=已验证)或审计日志操作列。 示例 支付请求已创建付款已授权付款已结算支付失败 | |||
| Event User EventUser | 负责该活动的员工 ID 或系统代理。 | ||
| 描述 捕获执行操作的主体——无论是人工用户(如进行审批)还是系统账户(如进行自动结算)。此属性对于“瓶颈分析”至关重要,可识别特定用户或队列是否超负荷。 为何重要 支持资源分析和职责分离审计。 获取方式 交易表中的审计日志或“UpdatedBy”列。 示例 SYSTEM_AGENT_01j.doeapprover_group_a批量处理 | |||
| 付款到期日 PaymentDueDate | 若要视为准时,支付必须完成结算的日期。 | ||
| 描述 存储合同规定或请求的执行日期。将此日期与实际结算日期进行对比,以计算“准时支付率”KPI,并为“支付到期日合规”dashboard 提供支持。 为何重要 衡量 SLA 合规性和准时绩效的基准。 获取方式 交易指令,通常为 VALUE_DATE、EXECUTION_DATE 或 DUE_DATE。 示例 2023-11-012023-11-05 | |||
| 付款类型 PaymentType | 支付工具的分类。 | ||
| 描述 对支付进行分类(如电汇、ACH、SEPA、RTGS)。不同支付类型的 SLA 和流程往往大不相同。此属性是过滤“端到端支付周期时间”仪表板的主要维度。 为何重要 对于区分高速支付流和批量支付流至关重要。 获取方式 交易抬头,例如 PMT_TYPE、INSTRUMENT_TYPE 或 SERVICE_ID 等字段。 示例 国内电汇国际电汇ACH 贷记即时支付 | |||
| 付款货币 PaymentCurrency | 支付金额的 ISO 货币代码。 | ||
| 描述 指定 为何重要 正确解析支付金额所必需的项。 获取方式 交易明细表,通常是 CCY、CURRENCY_CODE 或 ISO_CODE 等字段。 示例 美元EURGBPJPY | |||
| 处理渠道 ProcessingChannel | 发起支付的渠道。 | ||
| 描述 指示支付的入口,如移动端、Web 门户、API 或文件上传。这有助于进行“支付流程变体分析”,查看某些渠道是否比其他渠道更容易出现错误或延迟。 为何重要 按输入方式细分绩效。 获取方式 交易抬头,通常位于名为 CHANNEL、SOURCE_TYPE 或 INPUT_METHOD 的列中。 示例 SWIFT网银移动应用文件上传 | |||
| 支付金额 PaymentAmount | 支付交易的货币价值。 | ||
| 描述 指示转账的财务价值。这是分析“支付吞吐量”和排列瓶颈优先级的关键上下文字段。与低价值的自动化流程相比,高价值支付通常会经历更严格的审批路径(变体分析)。 为何重要 支持按数值细分并计算总处理量。 获取方式 交易明细表,通常是 AMT、TRANS_AMOUNT 或 PRINCIPAL_AMOUNT 等字段。 示例 1500.00250000.5050.001000000.00 | |||
| 是否返工 IsRework | 指示支付是否经历过重复 Activity 的标志。 | ||
| 描述 数据处理期间计算的布尔标志。如果“支付详情已验证”等 Activity 出现多次或检测到错误循环,则设为 true。该标志用于驱动“支付返工率”KPI。 为何重要 无需复杂的流程查询即可快速识别低效 case。 获取方式 在数据流水线中通过检查每个 Case 的重复 Activity 计算得出。 示例 truefalse | |||
| 端到端周期时间 EndToEndCycleTime | 从请求创建到结算的总时长。 | ||
| 描述 计算“支付请求已创建”与“支付已结算”之间的时间差。这是“平均支付交易周期时间”KPI 和整体效率分析的核心指标。 为何重要 衡量流程速度的核心指标。 获取方式 计算方式:Timestamp(Payment Settled) - Timestamp(Payment Request Created)。 示例 2 天 4 小时45分钟12 秒 | |||
| 部门 Department | 负责当前活动的内部部门。 | ||
| 描述 将 为何重要 按业务职能汇总绩效。 获取方式 源自用户表或组织架构映射。 示例 运营Compliance资金部IT支持 | |||
| 错误代码 ErrorCode | 支付失败或需要修复时生成的代码。 | ||
| 描述 捕获“支付失败”或“已识别支付错误”事件的具体原因。在“支付失败与返工分析”仪表板中按此属性分组,可以让业务部门识别最常见的失败根本原因(如“余额不足”、“账户无效”)。 为何重要 对于流程失败的根本原因分析 (Root Cause Analysis) 至关重要。 获取方式 错误日志或状态原因列,通常为 REASON_CODE 或 RETURN_CODE。 示例 R01AM04BE05TECH_ERR_001 | |||
| 最后数据更新 LastDataUpdate | 记录最后一次在 data 模型中提取或更新的 timestamp。 | ||
| 描述 追踪分析中所用 data 的新鲜度。这并不代表流程 event 时间,而是 data 摄取的术语时间。它确保分析师了解他们看到的是实时数据还是历史快照。 为何重要 确保数据时效性,帮助识别仪表板中的陈旧数据。 获取方式 执行 ETL 脚本时的系统时间。 示例 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| 受益人姓名 BeneficiaryName | 收款实体名称。 | ||
| 描述 标识交易中的对手方。分析此字段有助于识别与高返工率或延迟相关的特定供应商或客户,支持“支付失败与返工分析”。 为何重要 标识支付目标,对以客户为中心的分析非常有用。 获取方式 支付明细行,例如 CREDITOR_NAME、BENE_NAME 或 PAYEE 等字段。 示例 Acme公司Global Supplies Ltd约翰·史密斯 | |||
| 审批周期时间 ApprovalCycleTime | 审批阶段耗时。 | ||
| 描述 计算从“支付已送审”到“支付已批准”(或已拒绝)之间的时间。该指标会输入到“支付审批周期分析”仪表板中,重点展示人工决策环节的延迟。 为何重要 隔离出流程中依赖人工的部分。 获取方式 计算方式:Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval)。 示例 4 小时15 minutes | |||
| 对账 ID ReconciliationId | 将支付关联到总账或对账记录的标识符。 | ||
| 描述 当“支付已对账”活动发生时,会填充此 ID。它确保处理引擎中的支付与会计系统中的分录相匹配。已结算支付中若缺少此 ID,则表明对账失败。 为何重要 对于“支付对账效率”仪表板至关重要。 获取方式 对账表或特定字段,如 RECON_REF 或 GL_REF。 示例 REC-9921GL-Entry-2023-11 | |||
| 支付是否逾期 IsPaymentLate | 指示支付是否在截止日期后结算的标志。 | ||
| 描述 一个布尔标志,用于比较实际结算日期与 为何重要 简化合规报告流程。 获取方式 计算方式:SettlementDate > PaymentDueDate。 示例 truefalse | |||
| 源系统 SourceSystem | event data 来源系统的名称。 | ||
| 描述 标识 ACI Worldwide 生态系统中的特定应用或模块(如 ACI MTS、ACI UPF)或流程中涉及的外部系统。这在跨多个账本缝合数据或支付涉及外部清算中心时尤为重要。 为何重要 提供 data 提取来源的背景信息,有助于调试 data 血缘关系。 获取方式 提取期间硬编码,或在存在多个实例时从 SystemID 列衍生。 示例 ACI MTSACI UPPSAP GLSwift 网关 | |||
| 起始地区 OriginatingRegion | 发起支付请求的地理区域。 | ||
| 描述 指示请求者的物理或逻辑位置。这有助于“支付流程变体分析”,了解特定地区是否遵循非标准路径或经历更高的拒绝率。 为何重要 为流程绩效提供地理维度背景。 获取方式 交易抬头,通常源自网点代码或国家代码。 示例 北美欧洲、中东和非洲亚太 | |||
支付处理活动
| 活动 | 描述 | ||
|---|---|---|---|
| 付款已批准 | 一个关键里程碑,指授权用户批准支付,允许其进入执行阶段。这通常在审批人在系统用户界面执行操作时,作为显式事件被捕获。 | ||
| 为何重要 此活动是一个主要检查点,且往往是严重的瓶颈。分析该步骤前的等待时间以及审批周期的时长,有助于识别加速支付的机会。 获取方式 在审批日志表中查找显式事件,或者在主交易表中查找与特定用户操作和时间戳绑定的“已批准”状态变更。 捕获 在授权用户在系统中完成审批操作时记录。 事件类型 explicit | |||
| 付款已授权 | 代表人工审批后的系统级支付授权,包括验证资金或检查反欺诈规则。这可以是显式的日志条目,也可以从表示待执行的状态变更中推断。 | ||
| 为何重要 这是资金发出指令前的关键控制点。此阶段的延迟可能表明系统性能问题,或者合规及反欺诈检查子系统存在问题。 获取方式 在系统处理日志或安全日志中查看显式日志。或者,可以通过状态从“已批准”更新为“已授权支付”来推断。 捕获 支付引擎在通过最终内部检查后记录。 事件类型 explicit | |||
| 付款已结算 | 支付流程已完成且资金已记入收款人账户的最终确认,标志着交易结束。这是一个关键 event,代表支付生命周期的成功终点。 | ||
| 为何重要 这是流程的主要成功结束 event。它用于计算整体周期时间和吞吐量,对于几乎所有端到端绩效 dashboard 都至关重要。 获取方式 通常是当收到来自网络的最终结算确认消息,或内部总账更新以反映交易完成时记录的显式 event。 捕获 在收到最终结算文件或消息时记录,状态更新为“已结算”。 事件类型 explicit | |||
| 支付请求已创建 | 此活动标志着 ACI Worldwide 系统内新支付交易的启动。它通常是当用户或上游系统提交支付请求时记录的显式 event,同时会创建一个带有唯一 ID 的新交易记录。 | ||
| 为何重要 这是支付流程的主要开始 event。分析从该活动到完成的时间可得出端到端周期时间,这对于衡量整体流程效率至关重要。 获取方式 这很可能是 ACI 核心交易表或专用 event log 中记录的显式 event。请查找与支付交易 ID 关联的创建 timestamp。 捕获 通过创建记录或交易日志中的显式“创建”事件来识别。 事件类型 explicit | |||
| 支付错误已识别 | 表示系统在某个阶段检测到支付问题,如无效数据或合规警报。此事件通常会显式记录,并带有相关的错误代码。 | ||
| 为何重要 此活动是所有返工和异常处理分析的起点。它对于“支付失败与返工分析”以及“错误解决周期时间”dashboard 至关重要。 获取方式 在错误日志表中查找显式条目,或在交易表中查找“错误”或“需要更正”的状态变更。这些事件应与支付交易 ID 关联。 捕获 当系统验证或处理引擎标记错误时,会记录一个显式事件。 事件类型 explicit | |||
| 资金已转账 | 表示已收到支付网络的确认,资金已成功从付款人账户扣除。这通常是从来自网络的入站状态消息中捕获的。 | ||
| 为何重要 确认外部网络已成功执行支付。这标志着结算期的开始,是“平均支付结算时间”KPI 的关键输入。 获取方式 这是一个由传入的状态更新消息(例如来自 SWIFT 的 MT103 或 ACH 确认)触发的显式 event,用于更新支付记录。 捕获 在收到清算网络的外部确认消息时记录。 事件类型 explicit | |||
| 付款已对账 | 代表最后的会计步骤,即将 ACI 中记录的支付交易与银行对账单或分类帐分录进行匹配。这可以是来自对账模块的显式 event,也可以通过状态变更来推断。 | ||
| 为何重要 此活动衡量后台对账流程的效率。此处的延迟可能会影响财务报告的准确性,并掩盖未结算的支付问题。 获取方式 此信息可能来自 ACI 内部的专用对账模块或外部 ERP 系统。它将通过支付记录上“已对账”的状态更新来捕获。 捕获 通过最终的“已对账”状态更新,或通过按支付 ID 联接的对账数据推断。 事件类型 inferred | |||
| 支付失败 | 一种终态,表示由于不可恢复的问题导致支付无法完成。这与可解决的错误不同,代表了明确的失败终点状态。 | ||
| 为何重要 追踪此结束 event 对于计算整体支付失败率至关重要。分析失败原因有助于提高 data 质量和优化流程规则。 获取方式 通过交易数据中随后不再变更的最终终态推断,如“失败”、“已取消”或“被银行拒绝”。 捕获 通过支付记录中的终态失败状态推断。 事件类型 inferred | |||
| 支付已拒绝 | 当审批人拒绝支付请求时发生,通常需要更正并重新提交。这是一个显式事件,它会中断支付的后续进展并启动返工循环。 | ||
| 为何重要 识别返工和流程低效。追踪拒绝频率有助于诊断初始数据质量或提交政策的问题,支持返工分析。 获取方式 在审批日志中作为显式事件捕获,或在交易表中表现为状态变为“已拒绝”。该事件可能包含拒绝原因代码。 捕获 在审批人在系统中完成拒绝操作时记录。 事件类型 explicit | |||
| 支付已送审 | 表示支付已通过初步验证,并已路由至必要的管理或财务审批。这通常通过支付 workflow 内的状态变更来捕获。 | ||
| 为何重要 这标志着审批子流程的开始。衡量从该点到“支付已批准”的时间对于“支付审批周期时间分析”dashboard 至关重要。 获取方式 源自交易数据中支付状态字段的变更,例如变为“待审批”。 捕获 通过状态变更为“待审批”或类似状态以及对应的时间戳推断。 事件类型 inferred | |||
| 支付指令已发送 | 标志着支付指令被编译并传输到外部支付网络(如 SWIFT、ACH 或 SEPA)的节点。ACI 系统会显式记录此移交过程,用于审计和追踪。 | ||
| 为何重要 对于许多支付类型来说,这是“无法回头”的关键点。追踪这一点有助于衡量外部依赖项介入之前的内部处理时间。 获取方式 这几乎总是 ACI 交易或消息日志中记录的显式 event,通常包含特定于网络的参考号。 捕获 当支付消息发送到外部网络时,会创建一个显式日志条目。 事件类型 explicit | |||
| 支付详情已验证 | 代表自动或手动检查的完成,以确保支付详情(如收款人信息和银行代码)正确。该活动通常通过交易状态从“新建”变为“已验证”或“待审批”来推断。 | ||
| 为何重要 追踪初始 data 验证步骤的效率。此处的延迟可能会造成上游瓶颈,并增加流程后期出现支付错误的可能性。 获取方式 通过主支付交易表中的状态变更字段推断。比较“已创建”状态与随后的“已验证”或类似状态之间的时间戳。 捕获 通过支付状态字段的变更推断,例如从“已录入”变为“已验证”。 事件类型 inferred | |||
| 支付错误已解决 | 标志着用户更正了之前识别的错误,并重新提交支付进行处理。这通常在支付状态从错误态变回正常处理态时推断得出。 | ||
| 为何重要 此活动结束了异常循环。从“支付错误已识别”到此 event 之间的时间即为错误解决周期时间,这是衡量运营效率的关键指标。 获取方式 通过状态从“错误”态变更为处理态(如“待审批”或“已验证”)推断。也可以是显式的用户操作日志。 捕获 通过脱离错误状态的状态变更推断,表明已进行更正。 事件类型 inferred | |||
| 收款已确认 | 代表内部确认支付已成功处理并已收到确认。这通常作为通知收款人或其他内部系统的触发点。 | ||
| 为何重要 这一里程碑对于衡量截止日期合规性和准时支付率至关重要。它为组织何时认为支付已成功执行提供了一个明确的 timestamp。 获取方式 这通常是在收到外部网络确认后,根据支付交易表中状态变更为“已确认”或“已完成”来推断的。 捕获 通过状态变更为“已确认”或“已处理”推断。 事件类型 inferred | |||
提取指南
步骤
访问数据库环境:使用 SQL Server Management Studio (SSMS) 或兼容客户端登录托管 ACI Postilion Realtime 数据库的 SQL Server 实例。
识别核心表:找到
post_tran(交易日志)和post_tran_cust(自定义数据扩展)表。确保您拥有这些对象的SELECT权限。确定 Case ID:此提取过程使用
retrieval_reference_nr作为PaymentTransactionId。如果您的实现方案使用不同的唯一键(如system_trace_audit_nr结合transmission_date_time),请相应调整查询选择。配置过滤参数:打开下方提供的查询语句。在脚本顶部找到
@StartDate和@EndDate变量。将这些变量设置为所需的提取窗口(例如过去 30 到 90 天),以优化性能。审查 Activity 逻辑:查询会将 ISO 8583 消息类型(如 0200, 0210)和响应代码映射到所需的 14 个流程挖掘 Activity。请审查
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,分别将各列映射到 Case ID、Activity 和 Timestamp。
配置
- 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;