決済処理データテンプレート
決済処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- 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システム全体における特定の支払い指示に対する一意の識別子。 | ||
| 説明 この属性は、プロセスマイニング分析の中心キーとして機能し、単一の支払いリクエストに関連するすべてのイベントをリンクします。ACIワールドワイドシステム(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 | |||
| エンドツーエンドサイクルタイム EndToEndCycleTime | リクエスト作成から決済までの合計期間。 | ||
| 説明 「支払リクエスト作成」から「支払決済完了」までの時間差を計算します。これは「平均支払トランザクションサイクルタイム」KPIおよび全体的な効率分析の主要なメトリクスとして機能します。 その重要性 プロセス速度のトップレベル指標。 取得元 Computed: Timestamp(Payment Settled) - Timestamp(Payment Request Created). 例 2日4時間45 minutes12秒 | |||
| 処理チャネル ProcessingChannel | 支払いが開始されたチャネル。 | ||
| 説明 モバイル、Webポータル、API、ファイルアップロードなど、支払の入力元を示します。これは「支払プロセスバリアント分析」において、特定のチャネルが他のチャネルよりもエラーや遅延が発生しやすいかどうかを確認するのに役立ちます。 その重要性 入力方法別にパフォーマンスをセグメント化します。 取得元 トランザクションヘッダー、多くの場合CHANNEL、SOURCE_TYPE、またはINPUT_METHODという名前の列。 例 SWIFTインターネットバンキングモバイルアプリファイルアップロード | |||
| 手戻り IsRework | 支払が反復的なアクティビティを経たかどうかを示すフラグ。 | ||
| 説明 データ処理中に計算されるブール値フラグです。「支払詳細検証済み」のようなアクティビティが複数回発生した場合、またはエラーがループしていることが検出された場合にtrueに設定されます。これにより、「支払手戻り率」KPIが算出されます。 その重要性 複雑なプロセス検索なしに非効率なケースを迅速に特定します。 取得元 データパイプラインにおいて、ケースごとの重複アクティビティをチェックすることで算出されます。 例 truefalse | |||
| 支払い通貨 PaymentCurrency | 支払い金額のISO通貨コード。 | ||
| 説明 PaymentAmountが建てられている通貨(例:USD、EUR、GBP)を指定します。これは、異なる地域間の取引量を集計するダッシュボードでデータを正規化するために不可欠です。国際決済の複雑性を理解するのに役立ちます。 その重要性 支払い金額を正しく解釈するために必要です。 取得元 トランザクション詳細テーブル、通常CCY、CURRENCY_CODE、またはISO_CODEなどのフィールド。 例 USDEURGBPJPY | |||
| 支払タイプ PaymentType | 支払い手段の分類。 | ||
| 説明 支払を分類します(例: Wire, ACH, SEPA, RTGS)。異なる支払タイプは、SLAやプロセスフローが大きく異なることがよくあります。この属性は、「エンドツーエンド支払サイクルタイム」ダッシュボードをフィルタリングするための主要なディメンションです。 その重要性 高速支払フローとバッチ支払フローを区別するために不可欠です。 取得元 トランザクションヘッダー、PMT_TYPE、INSTRUMENT_TYPE、またはSERVICE_IDなどのフィールド。 例 国内送金国際送金ACHクレジット即時支払 | |||
| 支払期日 PaymentDueDate | 支払いが期日内と見なされるために決済されるべき日付。 | ||
| 説明 契約上または要求された実行日を格納します。この日付は、実際の決済日と比較され、「支払い期日遵守率」KPIを計算し、「支払い期日遵守」ダッシュボードをサポートするために使用されます。 その重要性 SLA遵守と期日内パフォーマンスを測定するためのベンチマーク。 取得元 トランザクション指示、通常VALUE_DATE、EXECUTION_DATE、またはDUE_DATE。 例 2023-11-012023-11-05 | |||
| 支払金額 PaymentAmount | 支払いトランザクションの金額。 | ||
| 説明 送金される財務価値を示します。これは「支払スループット」の分析とボトルネックの優先順位付けにとって重要なコンテキストフィールドです。高額な支払は、低額の自動化されたフローと比較して、より厳格な承認経路(バリアント分析)を経ることがよくあります。 その重要性 値によるセグメンテーションと、処理された総量の計算を可能にします。 取得元 トランザクション詳細テーブル、通常AMT、TRANS_AMOUNT、またはPRINCIPAL_AMOUNTなどのフィールド。 例 1500.00250000.5050.001000000.00 | |||
| 部署 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などのフィールド。 例 アクメ株式会社Global Supplies LtdJohn Smith | |||
| 承認サイクルタイム ApprovalCycleTime | 承認フェーズで費やされた期間。 | ||
| 説明 「支払承認依頼」から「支払承認済み」(または却下済み)までの時間を計算します。この特定のメトリクスは「支払承認サイクルタイム分析」ダッシュボードに反映され、人間の意思決定ステップにおける遅延を浮き彫りにします。 その重要性 プロセスにおける人間依存の部分を分離します。 取得元 Computed: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). 例 4時間15分 | |||
| 支払遅延あり IsPaymentLate | 支払が期日後に決済されたかどうかを示すフラグ。 | ||
| 説明 実際の決済日を その重要性 コンプライアンス報告を簡素化します。 取得元 Computed: SettlementDate > PaymentDueDate. 例 truefalse | |||
| 照合ID ReconciliationId | 支払を総勘定元帳または照合記録にリンクする識別子。 | ||
| 説明 このIDは「支払い照合済み」アクティビティが発生したときに設定されます。これにより、処理エンジン内の支払いが会計システムのエントリと一致することが保証されます。決済済み支払いにおけるこのIDの欠如は、照合失敗を示します。 その重要性 「支払照合効率」ダッシュボードにとって不可欠です。 取得元 照合テーブル、またはRECON_REFやGL_REFなどの特定のフィールド。 例 REC-9921GL-Entry-2023-11 | |||
| 発信元地域 OriginatingRegion | 支払いリクエストが発信された地理的地域。 | ||
| 説明 リクエスターの物理的または論理的な場所を示します。これは「支払プロセスバリアント分析」において、特定の地域が非標準の経路をたどったり、高い却下率を経験したりするかどうかを確認するのに役立ちます。 その重要性 プロセスパフォーマンスに地理的コンテキストを提供します。 取得元 トランザクションヘッダー、多くの場合支店コードまたは国コードから導出されます。 例 北米EMEAAPAC | |||
決済処理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 支払いエラー特定済み | システムが支払のいずれかの段階で、無効なデータやコンプライアンスアラートなどの問題を検出したことを示します。このイベントは通常、関連するエラーコードとともに明示的にログに記録されます。 | ||
| その重要性 このアクティビティは、すべての手戻りおよび例外処理分析の出発点です。「支払い失敗と手戻り分析」および「エラー解決サイクルタイム」ダッシュボードにとって不可欠です。 取得元 エラーログテーブル内の明示的なエントリ、またはトランザクションテーブル内の「エラー」または「修正が必要」へのステータス変更を探してください。これらのイベントはPayment Transaction IDにリンクされている必要があります。 取得 システムの検証または処理エンジンがエラーを検出した際に、明示的なイベントがログに記録されます。 イベントタイプ explicit | |||
| 支払いリクエスト作成済み | このアクティビティは、ACIワールドワイドシステム内で新しい支払いトランザクションの開始を示します。通常、ユーザーまたは上位システムが支払いリクエストを送信したときに記録される明示的なイベントであり、一意のIDを持つ新しいトランザクションレコードを作成します。 | ||
| その重要性 これは支払いプロセスの主要な開始イベントです。このアクティビティから完了までの時間を分析することで、エンドツーエンドのサイクルタイムが提供され、これは全体的なプロセス効率を測定するために不可欠です。 取得元 これは、コアトランザクションテーブルまたはACI内の専用イベントログに記録される明示的なイベントである可能性が高いです。決済トランザクションIDに関連付けられた作成タイムスタンプを探してください。 取得 作成レコード、またはトランザクションログ内の明示的な「作成」イベントによって識別されます。 イベントタイプ explicit | |||
| 支払実行許可 | 人間による承認後、資金の検証や不正防止ルールのチェックを行う、支払いに対するシステムレベルの承認を表します。これは明示的なログエントリであるか、または実行準備完了を示すステータス変更から推測される場合があります。 | ||
| その重要性 これは資金移動が指示される前の重要な管理ポイントです。この段階での遅延は、システムパフォーマンスの問題や、コンプライアンスおよび不正チェックサブシステムの問題を示す可能性があります。 取得元 システム処理ログまたはセキュリティログに明示的なログがないか確認します。あるいは、「承認済み」から「支払承認済み」へのステータス更新から推測することもできます。 取得 最終的な内部チェックを通過した後、システムの支払エンジンによってログに記録されます。 イベントタイプ explicit | |||
| 支払承認 | 承認されたユーザーが支払いを承認し、実行に進める主要な節目です。これは通常、承認者がシステムのユーザーインターフェースでアクションを実行した際に、明示的なイベントとして捕捉されます。 | ||
| その重要性 このアクティビティは主要なチェックポイントであり、多くの場合重要なボトルネックとなります。このステップ前の待ち時間と承認サイクルの期間を分析することで、支払いを加速する機会を特定するのに役立ちます。 取得元 承認ログテーブル内の明示的なイベント、または特定のユーザーアクションとタイムスタンプに紐づけられたメインのトランザクションテーブル内の「承認済み」へのステータス変更を探してください。 取得 承認されたユーザーがシステムで承認アクションを完了した際にログに記録されます。 イベントタイプ explicit | |||
| 支払決済完了 | 支払いプロセスが完了し、資金が受取人に貸方記入されたことの最終確認であり、トランザクションを完了させます。これは、支払いライフサイクルの成功裏の終了を表す重要なイベントです。 | ||
| その重要性 これはプロセスの主要な成功終了イベントです。全体的なサイクルタイムとスループットを計算するために使用され、ほとんどすべてのエンドツーエンドパフォーマンスダッシュボードにとって不可欠です。 取得元 通常、ネットワークから最終決済確認メッセージが受信されたとき、または内部元帳がトランザクションの完了を反映するように更新されたときに記録される明示的なイベント。 取得 最終決済ファイルまたはメッセージの受信時にログに記録され、ステータスが「決済済み」に更新されます。 イベントタイプ explicit | |||
| 送金を完了 | 支払ネットワークから、資金が支払人口座から正常に引き落とされたという確認が受信されたことを示します。これは通常、ネットワークからの受信ステータスメッセージから捕捉されます。 | ||
| その重要性 外部ネットワークによる支払の正常な実行を確認します。これは決済期間の開始を示し、「平均支払決済時間」KPIの主要な入力値となります。 取得元 これは、支払いレコードを更新する受信ステータス更新メッセージ(例:SWIFTからのMT103、またはACH確認)によってトリガーされる明示的なイベントです。 取得 クリアリングネットワークからの外部確認メッセージの受信時にログに記録されます。 イベントタイプ explicit | |||
| 支払いエラー解決済み | 以前に特定されたエラーがユーザーによって修正され、支払が処理のために再提出される時点を示します。これは、支払いのステータスがエラー状態から通常の処理状態に戻ったときに推測されることがよくあります。 | ||
| その重要性 このアクティビティは例外ループを閉じます。「支払いエラー特定済み」からこのイベントまでの時間は、エラー解決サイクルタイムであり、運用効率の主要な尺度です。 取得元 「エラー」状態から「承認待ち」や「検証済み」のような処理状態へのステータス変更から推測されます。これは明示的なユーザーアクションログである場合もあります。 取得 エラー状態からのステータス変更から推測され、修正が行われたことを示します。 イベントタイプ inferred | |||
| 支払い失敗 | 回復不能な問題により支払いが完了できなかったことを示す最終ステータスです。これは解決可能なエラーとは異なり、明確な失敗の最終状態を表します。 | ||
| その重要性 この終了イベントを追跡することは、全体的な支払い失敗率を計算するために不可欠です。失敗の原因を分析することは、データ品質とプロセスルールを改善するのに役立ちます。 取得元 トランザクションデータ内の「失敗」、「キャンセル済み」、「銀行により却下済み」のような、その後に変化しない最終的なターミナルステータスから推測されます。 取得 支払レコードにおける最終的な失敗ステータスから推測されます。 イベントタイプ inferred | |||
| 支払い承認待ち | 支払が初期検証に合格し、必要な管理者または財務承認のためにルーティングされたことを示します。これは通常、支払ワークフロー内のステータス変更によって捕捉されます。 | ||
| その重要性 これは承認サブプロセスの始まりを示します。この時点から「支払い承認済み」までの時間を測定することは、「支払い承認サイクルタイム分析」ダッシュボードにとって不可欠です。 取得元 トランザクションデータの支払ステータスフィールドの変更(例:「承認待ち」への移行)から派生します。 取得 「承認待ち」またはそれに類するステータス変更と、対応するタイムスタンプから推測されます。 イベントタイプ inferred | |||
| 支払い拒否 | 承認者が支払リクエストを却下した際に発生します。多くの場合、修正と再提出が必要です。これは、支払の進行を停止させ、手戻りループを開始する明示的なイベントです。 | ||
| その重要性 手戻りやプロセス非効率性を特定します。却下の頻度を追跡することで、初期データ品質や提出ポリシーの問題を診断するのに役立ち、手戻り分析をサポートします。 取得元 承認ログ内の明示的なイベント、またはトランザクションテーブル内の「却下済み」へのステータス変更として捕捉されます。このイベントには、却下の理由コードが含まれる場合があります。 取得 承認者がシステムで却下アクションを完了した際にログに記録されます。 イベントタイプ explicit | |||
| 支払い指示送信済み | 支払指示がコンパイルされ、SWIFT、ACH、SEPAなどの外部支払ネットワークに送信される時点を示します。ACIシステムは、監査および追跡目的でこのハンドオフを明示的にログに記録します。 | ||
| その重要性 これは多くの支払いタイプにとって「後戻りできない点」です。これを追跡することで、外部依存関係が引き継ぐ前の内部処理時間を測定するのに役立ちます。 取得元 これはほぼ常に、ACIのトランザクションまたはメッセージングログに記録される明示的なイベントであり、多くの場合、ネットワーク固有の参照番号が含まれます。 取得 支払メッセージが外部ネットワークに送信された際に、明示的なログエントリが作成されます。 イベントタイプ explicit | |||
| 支払い消込済み | ACIに記録された支払いトランザクションが、銀行取引明細書または元帳エントリと照合される最終的な会計処理ステップを表します。これは、照合モジュールからの明示的なイベントであるか、またはステータス変更によって推測される場合があります。 | ||
| その重要性 このアクティビティは、バックオフィス照合プロセスの効率性を測定します。ここでの遅延は、財務報告の正確性に影響を与え、未決済の支払い問題を隠す可能性があります。 取得元 この情報は、ACI内の専用照合モジュールまたは外部ERPシステムから取得される可能性があります。支払いレコードのステータスを「照合済み」に更新することで捕捉されます。 取得 最終的な「照合済み」ステータス更新、または支払IDによって結合された照合データから推測されます。 イベントタイプ inferred | |||
| 支払い確認済み | 支払いが正常に処理され、確認が受信されたことに対する内部承認を表します。これは多くの場合、受取人や他の内部システムへの通知のトリガーポイントとして機能します。 | ||
| その重要性 このマイルストーンは、期日遵守と期日内支払い率を測定するために不可欠です。組織が支払いが正常に実行されたと見なす時点の明確なタイムスタンプを提供します。 取得元 これは通常、外部ネットワーク確認が受信された後、支払いトランザクションテーブルのステータスが「確認済み」または「完了済み」に変わることから推測されます。 取得 「確認済み」または「処理済み」へのステータス変更から推測されます。 イベントタイプ 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が使用されていることを確認してください。
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;