支払処理データテンプレート
支払処理データテンプレート
- 収集を推奨する属性
- 追跡すべき主要アクティビティ
- ACI Worldwide向け抽出ガイド
決済処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 支払いライフサイクルで発生した具体的なステップまたはステータス変更です。 | ||
| 説明 この属性は、「支払いリクエスト作成」や「資金振替」など、プロセスマップ上のイベントノードを定義します。ACIシステムでは、ステータスコード、監査ログの操作種別、ワークフロー状態の変更から導出されることがよくあります。技術的な状態を読みやすい業務アクティビティに正確に対応付けることは、意味のある可視化に欠かせません。 重要な理由 プロセスフローを定義し、操作の順序を可視化するために必要です。 入手先 ステータスコード(例:100=作成済み、200=検証済み)または監査ログのAction列から導出されます。 例 支払い依頼を作成支払いを承認済みに設定支払決済完了支払失敗 | |||
| イベントタイムスタンプ EventTimestamp | アクティビティが発生した具体的な日時です。 | ||
| 説明 ACI環境内でイベントが発生した正確な時点を記録する属性です。サイクルタイム、承認所要時間、スループットなど、時間に基づくすべての指標の計算に使われます。自動処理のステップを正確に並べるため、ミリ秒単位の高い精度が推奨されます。 重要な理由 イベントの順序付けと処理時間の計算に欠かせません。 入手先 取引履歴または監査テーブルの「作成日」または「更新日」列を確認してください。 例 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| 支払い取引ID PaymentTransactionId | ACIシステム全体で特定の支払い指図を一意に識別する識別子です。 | ||
| 説明 この属性はプロセスマイニング分析の中心キーとして機能し、1件の支払いリクエストに関連するすべてのイベントを結び付けます。ACI Worldwideのシステム(MTSやUPPなど)では、取引の入力時に割り当てられる一意の参照番号に相当します。初回のリクエストから検証、承認、最終決済まで、支払いのエンドツーエンドの流れを再構成できます。 重要な理由 個別のイベントをプロセスインスタンスごとにグループ化するために必要な基本的なCase 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 | 支払い手段の分類です。 | ||
| 説明 支払いを分類します(Wire、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 Gateway | |||
| 最終データ更新 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がない場合、照合に失敗したことを示します。 重要な理由 「支払い照合効率」ダッシュボードに欠かせません。 入手先 照合テーブル、またはRECON_REFやGL_REFなどの専用フィールドです。 例 REC-9921GL-Entry-2023-11 | |||
| 発生地域 OriginatingRegion | 支払いリクエストが発生した地理的地域です。 | ||
| 説明 リクエスト元の物理的または論理的な場所を示します。「支払いプロセスのバリアント分析」で、特定の地域が標準外の経路をたどっているか、拒否率が高いかを確認できます。 重要な理由 プロセスパフォーマンスを地理的な観点から把握できます。 入手先 取引ヘッダーにあり、Branch CodeまたはCountry Codeから導出されることがよくあります。 例 北米EMEAAPAC | |||
決済処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 支払いを承認 | 権限を持つユーザーが支払いを承認し、実行に進められるようになる重要なマイルストーンです。通常は、承認者がシステムのユーザーインターフェースで操作した際に、明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティは主要なチェックポイントであり、大きなボトルネックになることも少なくありません。このステップの前の待ち時間と承認サイクルの所要時間を分析することで、支払いを迅速化する機会を特定できます。 入手先 承認ログテーブルにある明示的なイベント、または特定のユーザー操作とタイムスタンプに紐づく、メイン取引テーブルの「Approved」へのステータス変更を確認してください。 取得 権限を持つユーザーがシステム上で承認操作を完了した際に記録されます。 イベントタイプ explicit | |||
| 支払いを承認済みに設定 | 人による承認後に、システムレベルで支払いが承認されたことを示します。資金の有無を確認したり、不正検知ルールに照合したりする処理です。明示的なログエントリとして記録される場合と、実行可能な状態を示すステータス変更から推定される場合があります。 | ||
| 重要な理由 これは、資金移動の指示を出す前の重要な管理ポイントです。この段階での遅延は、システム性能の問題や、コンプライアンスおよび不正検知サブシステムの問題を示している可能性があります。 入手先 システム処理ログまたはセキュリティログに明示的な記録があるか確認します。記録がない場合は、「Approved」から「Authorized for Payment」へのステータス更新から推測できます。 取得 最終的な内部チェックを通過した後、システムの決済エンジンによって記録されます。 イベントタイプ explicit | |||
| 支払い依頼を作成 | ACI Worldwideのシステム内で新しい支払い取引が開始されたことを示すアクティビティです。通常は、ユーザーまたは上流システムが支払い依頼を送信した際に記録される明示的なイベントで、一意のIDを持つ新しい取引レコードが作成されます。 | ||
| 重要な理由 これは支払いプロセスの主な開始イベントです。このアクティビティから完了までの時間を分析することで、エンドツーエンドのサイクルタイムを把握できます。プロセス全体の効率を測定するうえで欠かせない指標です。 入手先 ACIの中核取引テーブルまたは専用のイベントログに記録される明示的なイベントである可能性が高い項目です。Payment Transaction IDに関連付けられた作成タイムスタンプを確認してください。 取得 作成レコード、または取引ログ内の明示的な「Create」イベントによって特定します。 イベントタイプ explicit | |||
| 支払エラー特定 | 無効なデータやコンプライアンスアラートなど、システムが支払のいずれかの段階で問題を検知したことを示します。通常、関連するエラーコードとともに明示的に記録されます。 | ||
| 重要な理由 このアクティビティは、手戻りと例外処理の分析を始める起点です。「支払失敗・手戻り分析」および「エラー解決サイクルタイム」ダッシュボードに欠かせません。 入手先 エラーログテーブルの明示的なエントリ、または取引テーブルのステータスが「Error」や「Requires Correction」に変わった記録を探します。これらのイベントはPayment Transaction IDに関連付ける必要があります。 取得 システムの検証エンジンまたは処理エンジンがエラーを検出すると、明示的なイベントが記録されます。 イベントタイプ explicit | |||
| 支払決済完了 | 支払プロセスが完了し、受取人の口座に資金が入金されたことを示す最終確認です。取引を完了させる重要なイベントであり、支払ライフサイクルが正常に終了したことを表します。 | ||
| 重要な理由 通常、プロセスにおける主要な正常終了イベントです。全体のサイクルタイムとスループットの計算に使われ、エンドツーエンドのパフォーマンスダッシュボードのほぼすべてに欠かせません。 入手先 通常、ネットワークから最終決済確認メッセージを受信した時点、または取引の完了を示すように内部元帳が更新された時点で記録される明示的なイベントです。 取得 最終決済ファイルまたはメッセージを受信し、ステータスが「Settled」に更新された時点で記録されます。 イベントタイプ explicit | |||
| 資金移動完了 | 支払人の口座から資金が正常に引き落とされたことを、決済ネットワークから受信した確認情報によって示します。通常は、ネットワークから受信したステータスメッセージに記録されます。 | ||
| 重要な理由 外部ネットワークによる決済が正常に実行されたことを確認します。決済期間の開始点となり、「平均決済完了時間」KPIの主要な入力値です。 入手先 支払レコードを更新する受信ステータス更新メッセージ(SWIFTのMT103やACH確認など)によって発生する明示的なイベントです。 取得 クリアリングネットワークから外部確認メッセージを受信した時点で記録されます。 イベントタイプ explicit | |||
| 支払いを却下 | 承認者が支払い依頼を拒否した際に発生し、修正と再申請が必要になることが多くあります。支払いの前進を止め、やり直しのループを開始する明示的なイベントです。 | ||
| 重要な理由 やり直しとプロセスの非効率を特定します。却下の頻度を追跡することで、初期データの品質や申請ポリシーに関する問題を診断し、やり直しの分析に役立てられます。 入手先 承認ログの明示的なイベント、または取引テーブルの「Rejected」へのステータス変更として記録されます。却下理由コードが含まれる場合もあります。 取得 承認者がシステム上で却下操作を完了した際に記録されます。 イベントタイプ explicit | |||
| 支払いを承認に回付 | 支払いが初期検証を通過し、必要な管理者または財務担当者の承認に回付されたことを示します。通常は、支払いワークフロー内のステータス変更として記録されます。 | ||
| 重要な理由 承認サブプロセスの開始点です。この時点から「Payment Approved」までの時間を測定することは、「Payment Approval Cycle Time Analysis」ダッシュボードにとって重要です。 入手先 取引データの支払いステータスフィールドが、「Pending Approval」などに変わったことから導出します。 取得 対応するタイムスタンプとともに、「Pending Approval」などへのステータス変更から推定します。 イベントタイプ inferred | |||
| 支払い情報を検証済み | 受取人情報や銀行コードなど、支払い情報が正しいことを確認する自動または手動のチェックが完了したことを示します。このアクティビティは、取引のステータスが「New」から「Validated」または「Pending Approval」に変わったことから推定される場合が多くあります。 | ||
| 重要な理由 初期データ検証ステップの効率を追跡します。ここで遅延が発生すると、上流のボトルネックが生じ、プロセス後半で支払いエラーが発生する可能性が高まります。 入手先 支払い取引のメインテーブルにあるステータス変更フィールドから推定します。「Created」ステータスと、その後の「Validated」などのステータスのタイムスタンプを比較してください。 取得 支払いステータスフィールドが、たとえば「Entered」から「Validated」に変わったことから推定します。 イベントタイプ inferred | |||
| 支払い照合済み | ACIに記録された支払い取引を銀行取引明細または元帳の記録と照合する、最終的な会計処理のステップを表します。照合モジュールから明示的に記録されたイベントの場合もあれば、ステータス変更から推定される場合もあります。 | ||
| 重要な理由 このアクティビティでは、バックオフィスの照合プロセスの効率を測定します。ここでの遅延は、財務報告の正確性に影響し、未決済の支払いに関する問題を見えにくくする可能性があります。 入手先 この情報は、ACI内の専用照合モジュールまたは外部ERPシステムから取得される場合があります。支払いレコードのステータスが「照合済み」に更新された情報として記録されます。 取得 最終的な「照合済み」ステータスへの更新、またはPayment IDで結合された照合データから推定されます。 イベントタイプ inferred | |||
| 支払エラー解決 | 以前に特定されたエラーをユーザーが修正し、支払いが処理のために再送信された時点を示します。通常は、支払いのステータスがエラー状態から通常の処理状態へ戻ったことから推定します。 | ||
| 重要な理由 このアクティビティによって例外処理が完了します。「支払いエラーの特定」からこのイベントまでの時間は、業務効率を測る重要な指標であるエラー解決サイクルタイムです。 入手先 「エラー」状態から「承認待ち」や「検証済み」などの処理状態へ変化したことから推定します。ユーザーによる明示的な操作ログが記録される場合もあります。 取得 エラー状態からのステータス変更に基づき、修正が行われたことを示します。 イベントタイプ inferred | |||
| 支払失敗 | 回復できない問題により支払を完了できなかったことを示す終端ステータスです。解決可能なエラーとは異なり、確定した失敗終了状態を表します。 | ||
| 重要な理由 この終了イベントを追跡することは、全体の支払失敗率を計算するうえで重要です。失敗理由を分析することで、データ品質とプロセスルールの改善につなげられます。 入手先 取引データの「Failed」、「Cancelled」、「Rejected by Bank」など、以降変更されない最終的な終端ステータスから推測されます。 取得 支払レコードの終端失敗ステータスから推測されます。 イベントタイプ inferred | |||
| 支払指示送信 | 支払指示がまとめられ、SWIFT、ACH、SEPAなどの外部決済ネットワークへ送信される時点を示します。ACIシステムでは、監査と追跡のため、この引き渡しを明示的に記録します。 | ||
| 重要な理由 多くの決済種別における「後戻りできない時点」です。これを追跡することで、外部依存先に処理が移る前の内部処理時間を測定できます。 入手先 ほぼ常に、ACIの取引ログまたはメッセージログに明示的なイベントとして記録され、ネットワーク固有の参照番号が含まれることもあります。 取得 支払メッセージが外部ネットワークへ送信されると、明示的なログエントリが作成されます。 イベントタイプ explicit | |||
| 支払確認済み | 支払が正常に処理され、確認を受信したことを示す内部確認です。受取人やその他の内部システムへの通知を開始するトリガーになることがよくあります。 | ||
| 重要な理由 このマイルストーンは、支払期日のコンプライアンスと期限内支払率を測定するうえで重要です。組織が支払を正常に実行したと判断した時点を、明確なタイムスタンプで示します。 入手先 通常、外部ネットワークから確認を受信した後、支払取引テーブルのステータスが「Confirmed」または「Completed」に変わることで推測されます。 取得 ステータスが「Confirmed」または「Processed」に変わったことから推測されます。 イベントタイプ 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へインポートし、列をそれぞれ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; 始める準備はできていますか?
このテンプレートをガイドとして、支払処理データの抽出を始めます。価値ある情報を見つけ出し、財務ワークフローの効率を高めてください。
支払処理を効率化:今すぐ無料トライアルを開始
支払の例外処理をなくし、98%のストレートスルー処理を実現します。
クレジットカード不要、数分で設定できます