支払い処理データテンプレート
支払い処理データテンプレート
- 収集を推奨する属性
- 記録すべき主なアクティビティ
- ACI Worldwideからのデータ抽出ガイド
支払い処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 支払いのライフサイクルで発生した具体的なステップまたはステータス変更です。 | ||
| 説明 この属性は、プロセスマップ上のイベントノードを定義します。たとえば「支払い依頼の作成」や「資金の振替」などです。ACIシステムでは、ステータスコード、監査ログの操作種別、ワークフローの状態変更から取得されることがよくあります。技術的な状態を、業務で理解しやすいアクティビティに正確に対応付けることが、意味のある可視化には欠かせません。 重要な理由 プロセスの流れを定義し、操作の順序を可視化するために必要です。 入手先 ステータスコード(例:100=作成、200=検証済み)または監査ログのアクション列から取得します。 例 支払依頼の作成支払の認可支払決済完了支払い失敗 | |||
| イベントのタイムスタンプ EventTimestamp | アクティビティが発生した具体的な日時です。 | ||
| 説明 この属性には、ACI環境でイベントが発生した正確な時刻が記録されます。サイクルタイム、承認所要時間、処理率など、時間に関するすべての指標の算出に使われます。自動処理のステップが短時間に連続して発生する場合も正確に順序付けられるよう、ミリ秒単位の精度が推奨されます。 重要な理由 イベントの順序付けと処理時間の算出に必要です。 入手先 取引履歴テーブルまたは監査テーブルの「作成日」や「更新日」列を確認します。 例 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| 支払い取引ID PaymentTransactionId | ACIシステム内で個々の支払い指示を識別する一意のIDです。 | ||
| 説明 この属性はプロセスマイニング分析の中心となるキーで、1件の支払い依頼に関連するすべてのイベントを紐付けます。ACI Worldwideのシステム(MTSやUPPなど)では、取引の入力時に割り当てられる一意の参照番号に相当します。これにより、最初の依頼から検証、承認、最終決済まで、支払いの一連の流れを再構成できます。 重要な理由 個々のイベントをプロセスインスタンスごとにグループ化するために必要な基本のケースIDです。 入手先 取引ヘッダーテーブルを確認します。メインの取引ログでは、TRN_REF、REFERENCE_NUM、UUIDなどの名前が付いていることがよくあります。 例 TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| イベント実行者 EventUser | アクティビティを実行したユーザーIDまたはシステムエージェントです。 | ||
| 説明 承認を行う人間のユーザーか、自動決済を行うシステムアカウントかを問わず、操作の実行者を記録します。特定のユーザーやキューに負荷が集中していないかを「ボトルネック分析」で特定するうえで重要な属性です。 重要な理由 リソース分析や職務分掌の監査に役立ちます。 入手先 監査ログ、または取引テーブルの「UpdatedBy」列です。 例 SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| エラーコード ErrorCode | 支払いが失敗した場合や修正が必要な場合に生成されるコードです。 | ||
| 説明 「支払い失敗」または「支払いエラーの検出」イベントの具体的な理由を記録します。「支払い失敗と手戻り分析」ダッシュボードでこの属性ごとに集計すると、「残高不足」や「口座情報の誤り」など、失敗の主な原因を特定できます。 重要な理由 プロセス失敗の根本原因分析に欠かせません。 入手先 エラーログまたはステータス理由の列です。REASON_CODEやRETURN_CODEなどがよく使われます。 例 R01AM04BE05TECH_ERR_001 | |||
| 処理チャネル ProcessingChannel | 支払いが開始されたチャネルです。 | ||
| 説明 モバイル、Webポータル、API、ファイルアップロードなど、支払いの受付経路を示します。「支払いプロセスのバリアント分析」で、特定のチャネルでエラーや遅延が発生しやすいかを確認できます。 重要な理由 入力方法別にパフォーマンスを比較できます。 入手先 取引ヘッダーのCHANNEL、SOURCE_TYPE、INPUT_METHODなどの列です。 例 SWIFTインターネットバンキングモバイルアプリファイルアップロード | |||
| 手戻りの有無 IsRework | 支払いで同じアクティビティが繰り返されたかどうかを示すフラグです。 | ||
| 説明 データ処理時に算出する真偽値フラグです。「支払い詳細の検証」などのアクティビティが複数回発生した場合や、エラーのループが検出された場合にtrueになります。「支払い手戻り率」KPIの算出に使われます。 重要な理由 複雑なプロセスクエリを作成せずに、非効率なケースをすばやく特定できます。 入手先 データパイプラインで、ケースごとに重複するアクティビティがあるかを確認して算出します。 例 truefalse | |||
| 支払い種別 PaymentType | 支払い手段の分類です。 | ||
| 説明 電信送金、ACH、SEPA、RTGSなど、支払いの種別を分類します。種別によって、適用されるSLAやプロセスの流れは大きく異なることがあります。「エンドツーエンドの支払いサイクルタイム」ダッシュボードで絞り込む際の主要な属性です。 重要な理由 高速処理と一括処理の支払いフローを区別するうえで重要です。 入手先 取引ヘッダーのPMT_TYPE、INSTRUMENT_TYPE、SERVICE_IDなどのフィールドです。 例 国内電信送金国際電信送金ACH入金即時支払い | |||
| 支払い通貨 PaymentCurrency | 支払い金額を表すISO通貨コードです。 | ||
| 説明
重要な理由 支払い金額を正しく解釈するために必要です。 入手先 取引明細テーブルのCCY、CURRENCY_CODE、ISO_CODEなどのフィールドです。 例 USDEURGBPJPY | |||
| 支払い金額 PaymentAmount | 支払い取引の金額です。 | ||
| 説明 振替対象となる金額を示します。「支払い処理量」の分析やボトルネックの優先順位付けに欠かせないコンテキスト情報です。高額の支払いは、少額の自動処理と比べて、より厳格な承認経路(バリアント分析)を経ることがよくあります。 重要な理由 金額別の分類や、処理済み総額の算出に利用できます。 入手先 取引明細テーブルのAMT、TRANS_AMOUNT、PRINCIPAL_AMOUNTなどのフィールドです。 例 1500.00250000.5050.001000000.00 | |||
| 支払期日 PaymentDueDate | 期日どおりの支払いとみなされるために、決済を完了する必要がある日付です。 | ||
| 説明 契約上または依頼上の実行日を記録します。この日付と実際の決済日を比較して「期日どおりの支払い率」KPIを算出し、「支払期日のコンプライアンス」ダッシュボードで確認します。 重要な理由 SLAの遵守状況と期日どおりの処理を測る基準です。 入手先 取引指示のVALUE_DATE、EXECUTION_DATE、DUE_DATEなどです。 例 2023-11-012023-11-05 | |||
| 部門 Department | 現在のアクティビティを担当する社内の部門です。 | ||
| 説明
重要な理由 業務機能ごとにパフォーマンスを集計できます。 入手先 ユーザーテーブルまたは組織階層の対応表から取得します。 例 業務部門Compliance財務ITサポート | |||
| ソースシステム SourceSystem | イベントデータの取得元となるシステムの名前です。 | ||
| 説明 ACI Worldwideのエコシステム内の特定のアプリケーションやモジュール(ACI MTS、ACI UPFなど)、またはプロセスに関与する外部システムを識別します。複数の元帳にまたがるデータを結合する場合や、支払いが外部のクリアリング機関を経由する場合に特に重要です。 重要な理由 データの抽出元を把握できるため、データの流れを追跡する際の問題調査に役立ちます。 入手先 抽出時に固定値を設定するか、複数のインスタンスがある場合はSystemID列から取得します。 例 ACI MTSACI UPPSAP GLSwift ゲートウェイ | |||
| 最終データ更新日時 LastDataUpdate | レコードが最後に抽出された日時、またはデータモデルで最後に更新された日時です。 | ||
| 説明 分析に使うデータの鮮度を追跡します。プロセスイベントの発生時刻ではなく、データを取り込んだ技術上の時刻を示します。分析担当者は、リアルタイムのデータを見ているのか、過去のスナップショットを見ているのかを確認できます。 重要な理由 データが最新かどうかを確認し、ダッシュボード上の古いデータを見つけるのに役立ちます。 入手先 ETLスクリプトの実行時点におけるシステム時刻です。 例 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| 受取人名 BeneficiaryName | 支払いを受け取る組織または個人の名前です。 | ||
| 説明 取引相手を識別します。このフィールドを分析すると、手戻り率の高さや遅延に関係する特定の仕入先や顧客を特定でき、「支払い失敗と手戻り分析」に役立ちます。 重要な理由 支払い先を識別し、顧客を軸にした分析に役立ちます。 入手先 支払い明細のCREDITOR_NAME、BENE_NAME、PAYEEなどのフィールドです。 例 Acme CorpGlobal Supplies LtdJohn Smith | |||
| 承認サイクルタイム ApprovalCycleTime | 承認段階にかかった時間です。 | ||
| 説明 「支払いの承認依頼」から「支払い承認済み」(または却下)までの時間を算出します。この指標は「支払い承認サイクルタイム分析」ダッシュボードに反映され、人による判断が必要なステップの遅延を明らかにします。 重要な理由 人の判断が必要なプロセス部分を切り分けて測定できます。 入手先 算出式:Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval)。 例 4時間15分 | |||
| 支払い遅延の有無 IsPaymentLate | 支払いが期日後に決済されたかどうかを示すフラグです。 | ||
| 説明 実際の決済日と 重要な理由 コンプライアンス報告を簡素化できます。 入手先 算出式:SettlementDate > PaymentDueDate。 例 truefalse | |||
| 照合ID ReconciliationId | 支払いを総勘定元帳または照合記録に紐付けるIDです。 | ||
| 説明 「支払い照合済み」アクティビティの発生時に設定されます。処理エンジン上の支払いと会計システムの記録が一致していることを確認できます。決済済みの支払いにこのIDがない場合、照合に失敗した可能性があります。 重要な理由 「支払い照合効率」ダッシュボードに欠かせません。 入手先 照合テーブル、またはRECON_REFやGL_REFなどのフィールドです。 例 REC-9921GL-Entry-2023-11 | |||
| 発生地域 OriginatingRegion | 支払い依頼が発生した地理的な地域です。 | ||
| 説明 依頼者の物理的または論理的な所在地を示します。「支払いプロセスのバリアント分析」で、特定の地域が標準外の経路をたどっているか、却下率が高いかを確認できます。 重要な理由 プロセスのパフォーマンスを地理的な観点から把握できます。 入手先 取引ヘッダーの支店コードまたは国コードから取得することがよくあります。 例 北米欧州・中東・アフリカアジア太平洋 | |||
支払い処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 支払いエラーの検出 | 無効なデータやコンプライアンス上の警告など、支払い処理のいずれかの段階でシステムが問題を検出したことを示します。通常、このイベントは関連するエラーコードとともに明示的に記録されます。 | ||
| 重要な理由 このアクティビティは、手戻りや例外処理の分析の起点となります。「支払い失敗と手戻り分析」および「エラー解決サイクルタイム」のダッシュボードに欠かせません。 入手先 エラーログテーブルの明示的な記録、または取引テーブルのステータスが「エラー」や「修正が必要」に変わった記録を確認します。これらのイベントは、支払い取引IDに紐付ける必要があります。 記録 システムの検証エンジンまたは処理エンジンがエラーを検出すると、イベントが明示的に記録されます。 イベントタイプ explicit | |||
| 支払の認可 | 人による承認後、資金の有無や不正検知ルールへの該当を確認して、システムが支払いを認可した状態を示します。明示的なログ記録、または実行可能な状態を示すステータス変更から推定できます。 | ||
| 重要な理由 資金移動の指示を出す前の重要な管理ポイントです。この段階の遅延は、システムのパフォーマンスやコンプライアンス・不正検知サブシステムの問題を示している場合があります。 入手先 システム処理ログまたはセキュリティログの明示的な記録を確認してください。または、ステータスが「承認済み」から「支払認可済み」に変わったことから推定できます。 記録 最終的な内部チェックを通過した後、システムの支払エンジンによって記録されます。 イベントタイプ explicit | |||
| 支払依頼の作成 | このアクティビティは、ACI Worldwideのシステムで新しい支払取引が開始されたことを示します。通常、ユーザーまたは上流システムが支払依頼を送信した際に明示的なイベントとして記録され、一意のIDを持つ新しい取引レコードが作成されます。 | ||
| 重要な理由 これは支払プロセスの主な開始イベントです。このアクティビティから完了までの時間を分析すると、プロセス全体のサイクルタイムがわかり、全体的な効率を測定できます。 入手先 通常、コア取引テーブルまたは専用のイベントログに明示的なイベントとして記録されます。支払取引IDに関連付けられた作成タイムスタンプを確認してください。 記録 作成レコード、または取引ログに明示的に記録された「作成」イベントで特定します。 イベントタイプ explicit | |||
| 支払承認 | 権限を持つユーザーが支払いを承認し、実行に進められる状態になったことを示す重要な節目です。通常、承認者がシステムのユーザーインターフェースで操作した際に、明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティは重要な確認ポイントであり、大きなボトルネックになることも少なくありません。この段階の前の待ち時間と承認サイクルの所要時間を分析すると、支払いを迅速化する機会を特定できます。 入手先 承認ログテーブルの明示的なイベント、または特定のユーザー操作とタイムスタンプに関連付けられた、メイン取引テーブルの「承認済み」へのステータス変更を確認してください。 記録 権限を持つユーザーがシステムで承認操作を完了した際に記録されます。 イベントタイプ explicit | |||
| 支払決済完了 | 支払プロセスが完了し、受取人の口座に資金が入金されたことを示す最終確認です。取引を完了させる重要なイベントであり、支払ライフサイクルが正常に終了したことを表します。 | ||
| 重要な理由 プロセスの主な正常終了イベントです。全体のサイクルタイムと処理量の算出に使われ、プロセス全体のパフォーマンスを示すほぼすべてのダッシュボードで必要となります。 入手先 通常、ネットワークから最終決済確認メッセージを受信した際、または取引の完了を示すために内部台帳が更新された際に、明示的なイベントとして記録されます。 記録 最終決済ファイルまたはメッセージの受信時に記録され、ステータスが「決済済み」に更新されます。 イベントタイプ explicit | |||
| 資金移動 | 支払ネットワークから、支払人の口座から資金が正常に引き落とされたことを示す確認を受信した状態です。通常、ネットワークから届くステータスメッセージで記録されます。 | ||
| 重要な理由 外部ネットワークによる支払いの実行が完了したことを確認します。決済期間の開始を示し、「支払決済時間の平均」の重要業績評価指標(KPI)を算出するための重要なデータとなります。 入手先 SWIFTのMT103やACHの確認メッセージなど、受信したステータス更新メッセージによって発生する明示的なイベントです。メッセージを受けて支払レコードが更新されます。 記録 清算ネットワークから外部確認メッセージを受信した際に記録されます。 イベントタイプ explicit | |||
| 支払いエラーの解決 | 以前に検出されたエラーをユーザーが修正し、支払いが再処理のために再送信された時点を示します。支払いのステータスがエラー状態から通常の処理状態に戻った記録から推定することがよくあります。 | ||
| 重要な理由 このアクティビティによって例外処理が完了します。「支払いエラーの検出」からこのイベントまでの時間がエラー解決サイクルタイムとなり、業務効率を測る重要な指標です。 入手先 ステータスが「エラー」から「承認待ち」や「検証済み」などの処理状態に変わった記録から推定します。ユーザー操作ログに明示的に記録される場合もあります。 記録 エラー状態から別のステータスに変わった記録から推定し、修正が行われたことを示します。 イベントタイプ inferred | |||
| 支払い失敗 | 復旧できない問題により支払いを完了できなかったことを示す最終ステータスです。解決可能なエラーとは異なり、失敗が確定した終了状態を表します。 | ||
| 重要な理由 この終了イベントを追跡することは、支払い失敗率全体の算出に欠かせません。失敗の理由を分析することで、データ品質やプロセスルールの改善につながります。 入手先 取引データの「失敗」「キャンセル済み」「銀行による拒否」など、以後変更されない最終ステータスから推定します。 記録 支払い記録の最終的な失敗ステータスから推定します。 イベントタイプ inferred | |||
| 支払い照合済み | ACIに記録された支払い取引を銀行明細または元帳の記録と照合する、会計処理の最終段階を表します。照合モジュールのイベントとして明示的に記録される場合と、ステータスの変更から推定される場合があります。 | ||
| 重要な理由 このアクティビティから、バックオフィスの照合プロセスの効率を測定できます。ここで遅延が発生すると、財務報告の正確性に影響し、未決済の支払い問題が見えにくくなる可能性があります。 入手先 この情報は、ACI内の専用照合モジュールまたは外部ERPシステムから取得できる場合があります。支払い記録のステータスが「照合済み」に更新された時点で記録されます。 記録 最終ステータスが「照合済み」に更新された記録、または支払いIDで結合した照合データから推定します。 イベントタイプ inferred | |||
| 支払を承認に回付 | 支払いが初期検証を通過し、必要な管理者または財務担当者の承認に回されたことを示します。通常、支払ワークフロー内のステータス変更として記録されます。 | ||
| 重要な理由 承認サブプロセスの開始を示します。この時点から「支払承認」までの時間は、「支払承認サイクルタイム分析」ダッシュボードで重要な指標となります。 入手先 取引データの支払ステータスが「承認待ち」などに変わったことから判定します。 記録 対応するタイムスタンプとともに、ステータスが「承認待ち」などに変わったことから推定します。 イベントタイプ inferred | |||
| 支払却下 | 承認者が支払依頼を却下した際に発生し、多くの場合、修正して再申請する必要があります。支払いの進行を止め、手戻りの流れを開始する明示的なイベントです。 | ||
| 重要な理由 手戻りやプロセスの非効率を特定できます。却下の頻度を追跡すると、初期データの品質や申請方針に関する問題を診断し、手戻り分析に役立てられます。 入手先 承認ログの明示的なイベント、または取引テーブルのステータスが「却下」に変わった記録として取得されます。却下理由コードがイベントに含まれる場合もあります。 記録 承認者がシステムで却下操作を完了した際に記録されます。 イベントタイプ explicit | |||
| 支払指示の送信 | 支払指示が作成され、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を使い、異なる取引状態を1つのイベントログ形式に統合します。出力データの確認:
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%のストレートスルー処理を実現しましょう。
クレジットカード不要、数分で設定できます。