Templat data pemrosesan pembayaran Anda
Templat data pemrosesan pembayaran Anda
- Atribut yang disarankan untuk dikumpulkan
- Aktivitas utama yang perlu dilacak
- Panduan ekstraksi untuk ACI Worldwide
Atribut pemrosesan pembayaran
| Nama | Deskripsi | ||
|---|---|---|---|
| ID Transaksi Pembayaran PaymentTransactionId | Pengenal unik untuk instruksi pembayaran tertentu di seluruh sistem ACI. | ||
| Deskripsi Atribut ini menjadi kunci utama untuk analisis process mining karena menghubungkan semua peristiwa yang terkait dengan satu permintaan pembayaran. Di sistem ACI Worldwide, seperti MTS atau UPP, atribut ini berupa nomor referensi unik yang diberikan ke transaksi saat dicatat. Dengan atribut ini, perjalanan pembayaran dari awal hingga akhir dapat direkonstruksi, mulai dari permintaan awal, validasi, dan persetujuan hingga penyelesaian akhir. Mengapa ini penting Atribut ini menjadi Case ID utama untuk mengelompokkan peristiwa terpisah ke dalam satu instans proses. Sumber data Periksa tabel header transaksi. Nama kolomnya sering berupa TRN_REF, REFERENCE_NUM, atau UUID di log transaksi utama. Contoh TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Nama Aktivitas ActivityName | Langkah atau perubahan status tertentu yang terjadi dalam siklus pembayaran. | ||
| Deskripsi Atribut ini menentukan simpul peristiwa pada peta proses, seperti 'Permintaan Pembayaran Dibuat' atau 'Dana Ditransfer'. Di sistem ACI, atribut ini sering diturunkan dari kode status, jenis operasi di log audit, atau perubahan status alur kerja. Pemetaan status teknis ke aktivitas bisnis yang mudah dipahami sangat penting agar visualisasi bermakna. Mengapa ini penting Atribut ini menentukan alur proses dan diperlukan untuk memvisualisasikan urutan operasional. Sumber data Ditentukan dari kode status, misalnya 100=Dibuat, 200=Divalidasi, atau kolom tindakan di log audit. Contoh Permintaan Pembayaran DibuatPembayaran DiotorisasiPembayaran DiselesaikanPembayaran Gagal | |||
| Stempel Waktu Peristiwa EventTimestamp | Tanggal dan waktu persis saat aktivitas terjadi. | ||
| Deskripsi Atribut ini mencatat waktu persis terjadinya peristiwa di lingkungan ACI. Data ini digunakan untuk menghitung semua metrik berbasis waktu, termasuk waktu siklus, durasi persetujuan, dan tingkat throughput. Presisi tinggi hingga milidetik disarankan agar urutan langkah otomatis yang berlangsung cepat dapat ditentukan dengan akurat. Mengapa ini penting Penting untuk mengurutkan peristiwa dan menghitung durasi kinerja. Sumber data Periksa kolom 'Tanggal Dibuat' atau 'Tanggal Diperbarui' di riwayat transaksi atau tabel audit. Contoh 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Departemen Department | Departemen internal yang bertanggung jawab atas aktivitas saat ini. | ||
| Deskripsi Memetakan Mengapa ini penting Menggabungkan data kinerja berdasarkan fungsi bisnis. Sumber data Ditentukan dari tabel pengguna atau pemetaan hierarki organisasi. Contoh OperasionalComplianceTresuriDukungan TI | |||
| Jenis Pembayaran PaymentType | Klasifikasi instrumen pembayaran. | ||
| Deskripsi Mengelompokkan pembayaran, misalnya Wire, ACH, SEPA, atau RTGS. Setiap jenis pembayaran biasanya memiliki SLA dan alur proses yang sangat berbeda. Atribut ini menjadi dimensi utama untuk memfilter dashboard 'Waktu Siklus Pembayaran Menyeluruh'. Mengapa ini penting Penting untuk membedakan alur pembayaran berkecepatan tinggi dan pembayaran yang diproses secara berkelompok. Sumber data Header transaksi, dengan kolom seperti PMT_TYPE, INSTRUMENT_TYPE, atau SERVICE_ID. Contoh Transfer DomestikTransfer InternasionalKredit ACHPembayaran Instan | |||
| Jumlah Pembayaran PaymentAmount | Nilai uang dalam transaksi pembayaran. | ||
| Deskripsi Menunjukkan nilai dana yang ditransfer. Informasi ini penting untuk menganalisis 'Throughput Pembayaran' dan menentukan prioritas hambatan. Pembayaran bernilai tinggi sering melewati tahapan persetujuan yang lebih ketat dibandingkan alur otomatis untuk pembayaran bernilai rendah. Mengapa ini penting Memungkinkan pengelompokan berdasarkan nilai dan penghitungan total volume yang diproses. Sumber data Tabel detail transaksi, biasanya dengan kolom seperti AMT, TRANS_AMOUNT, atau PRINCIPAL_AMOUNT. Contoh 1500.00250000.5050.001000000.00 | |||
| Kanal Pemrosesan ProcessingChannel | Kanal yang digunakan untuk memulai pembayaran. | ||
| Deskripsi Menunjukkan jalur masuk pembayaran, seperti Mobile, Portal Web, API, atau Unggah File. Informasi ini membantu analisis 'Variasi Proses Pembayaran' untuk mengetahui apakah kanal tertentu lebih sering mengalami kesalahan atau keterlambatan. Mengapa ini penting Mengelompokkan kinerja berdasarkan metode input. Sumber data Header transaksi, biasanya di kolom bernama CHANNEL, SOURCE_TYPE, atau INPUT_METHOD. Contoh SWIFTPerbankan InternetAplikasi SelulerUnggah File | |||
| Kode Kesalahan ErrorCode | Kode yang dibuat saat pembayaran gagal atau perlu diperbaiki. | ||
| Deskripsi Mencatat alasan spesifik untuk peristiwa 'Pembayaran Gagal' atau 'Kesalahan Pembayaran Teridentifikasi'. Pengelompokan berdasarkan atribut ini di dashboard 'Analisis Kegagalan dan Pengerjaan Ulang Pembayaran' membantu bisnis menemukan penyebab utama kegagalan yang paling sering terjadi, misalnya 'Dana Tidak Cukup' atau 'Rekening Tidak Valid'. Mengapa ini penting Penting untuk menganalisis akar penyebab kegagalan proses. Sumber data Log kesalahan atau kolom alasan status, biasanya REASON_CODE atau RETURN_CODE. Contoh R01AM04BE05TECH_ERR_001 | |||
| Mata Uang Pembayaran PaymentCurrency | Kode mata uang ISO untuk jumlah pembayaran. | ||
| Deskripsi Menentukan mata uang yang digunakan untuk nilai Mengapa ini penting Diperlukan agar Jumlah Pembayaran dapat ditafsirkan dengan benar. Sumber data Tabel detail transaksi, biasanya dengan kolom seperti CCY, CURRENCY_CODE, atau ISO_CODE. Contoh USDEURGBPJPY | |||
| Mengalami Pengerjaan Ulang IsRework | Penanda yang menunjukkan apakah pembayaran melewati aktivitas yang berulang. | ||
| Deskripsi Penanda boolean yang dihitung saat pemrosesan data. Nilainya menjadi true jika aktivitas seperti 'Detail Pembayaran Divalidasi' terjadi lebih dari sekali atau jika terdeteksi rangkaian kesalahan berulang. Data ini digunakan untuk menghitung KPI 'Tingkat Pengerjaan Ulang Pembayaran'. Mengapa ini penting Membantu menemukan kasus yang tidak efisien dengan cepat tanpa kueri proses yang rumit. Sumber data Dihitung di pipeline data dengan memeriksa aktivitas duplikat pada setiap kasus. Contoh truefalse | |||
| Pengguna Peristiwa EventUser | ID pengguna atau agen sistem yang bertanggung jawab atas aktivitas. | ||
| Deskripsi Mencatat pelaku tindakan, baik pengguna manusia, misalnya untuk persetujuan, maupun akun sistem, misalnya untuk penyelesaian otomatis. Atribut ini penting untuk 'Analisis Hambatan' agar Anda dapat mengetahui apakah pengguna atau antrean tertentu kelebihan beban. Mengapa ini penting Memungkinkan analisis sumber daya dan audit pemisahan tugas. Sumber data Log audit atau kolom 'UpdatedBy' di tabel transaksi. Contoh SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Tanggal Jatuh Tempo Pembayaran PaymentDueDate | Tanggal batas penyelesaian pembayaran agar dianggap tepat waktu. | ||
| Deskripsi Menyimpan tanggal eksekusi yang disepakati atau diminta. Tanggal ini dibandingkan dengan tanggal penyelesaian aktual untuk menghitung KPI 'Tingkat Pembayaran Tepat Waktu' dan mendukung metrik di dashboard 'Kepatuhan terhadap Tanggal Jatuh Tempo Pembayaran'. Mengapa ini penting Menjadi acuan untuk mengukur kepatuhan terhadap SLA dan kinerja ketepatan waktu. Sumber data Instruksi transaksi, biasanya pada kolom VALUE_DATE, EXECUTION_DATE, atau DUE_DATE. Contoh 2023-11-012023-11-05 | |||
| ID Rekonsiliasi ReconciliationId | Pengenal yang menghubungkan pembayaran dengan buku besar atau catatan rekonsiliasi. | ||
| Deskripsi ID ini diisi saat aktivitas 'Pembayaran Direkonsiliasi' terjadi. ID ini memastikan pembayaran di mesin pemrosesan cocok dengan entri di sistem akuntansi. Jika ID ini tidak ada pada pembayaran yang sudah diselesaikan, kemungkinan terjadi kegagalan rekonsiliasi. Mengapa ini penting Penting untuk dashboard 'Efisiensi Rekonsiliasi Pembayaran'. Sumber data Tabel rekonsiliasi atau kolom khusus seperti RECON_REF atau GL_REF. Contoh REC-9921GL-Entry-2023-11 | |||
| Nama Penerima BeneficiaryName | Nama pihak yang menerima pembayaran. | ||
| Deskripsi Menunjukkan pihak lawan transaksi. Analisis atribut ini dapat membantu menemukan vendor atau pelanggan tertentu yang terkait dengan tingginya tingkat pengerjaan ulang atau keterlambatan, serta mendukung 'Analisis Kegagalan dan Pengerjaan Ulang Pembayaran'. Mengapa ini penting Menunjukkan penerima pembayaran dan berguna untuk analisis yang berfokus pada pelanggan. Sumber data Baris detail pembayaran, dengan kolom seperti CREDITOR_NAME, BENE_NAME, atau PAYEE. Contoh Acme CorpGlobal Supplies LtdJohn Smith | |||
| Pembaruan Data Terakhir LastDataUpdate | Stempel waktu saat catatan terakhir diekstrak atau diperbarui dalam model data. | ||
| Deskripsi Melacak kebaruan data yang digunakan dalam analisis. Ini bukan waktu terjadinya peristiwa proses, melainkan waktu teknis saat data dimasukkan. Informasi ini membantu analis mengetahui apakah data yang dilihat bersifat real-time atau historis. Mengapa ini penting Memastikan data tetap mutakhir dan membantu menemukan data usang di dashboard. Sumber data Waktu sistem saat skrip ETL dijalankan. Contoh 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| Pembayaran Terlambat IsPaymentLate | Penanda yang menunjukkan apakah pembayaran diselesaikan setelah tanggal jatuh tempo. | ||
| Deskripsi Penanda boolean yang membandingkan tanggal penyelesaian aktual dengan Mengapa ini penting Mempermudah pelaporan kepatuhan. Sumber data Dihitung dengan rumus: SettlementDate > PaymentDueDate. Contoh truefalse | |||
| Sistem Sumber SourceSystem | Nama sistem asal data peristiwa. | ||
| Deskripsi Menunjukkan aplikasi atau modul tertentu dalam ekosistem ACI Worldwide, seperti ACI MTS atau ACI UPF, maupun sistem eksternal yang terlibat dalam alur. Informasi ini sangat penting saat menggabungkan data dari beberapa buku besar atau saat pembayaran melewati lembaga kliring eksternal. Mengapa ini penting Menunjukkan asal ekstraksi data dan membantu menelusuri alur data saat melakukan debug. Sumber data Diisi dengan nilai tetap saat ekstraksi atau diturunkan dari kolom SystemID jika ada beberapa instans. Contoh ACI MTSACI UPPSAP GLSwift Gateway | |||
| Waktu Siklus Persetujuan ApprovalCycleTime | Durasi yang dihabiskan dalam tahap persetujuan. | ||
| Deskripsi Menghitung waktu antara 'Pembayaran Dikirim untuk Persetujuan' dan 'Pembayaran Disetujui' atau ditolak. Metrik ini digunakan di dashboard 'Analisis Waktu Siklus Persetujuan Pembayaran' untuk menyoroti keterlambatan pada tahap yang memerlukan keputusan manusia. Mengapa ini penting Memisahkan bagian proses yang bergantung pada manusia. Sumber data Dihitung dengan rumus: Stempel Waktu(Pembayaran Disetujui) - Stempel Waktu(Pembayaran Dikirim untuk Persetujuan). Contoh 4 jam15 menit | |||
| Wilayah Asal OriginatingRegion | Wilayah geografis asal permintaan pembayaran. | ||
| Deskripsi Menunjukkan lokasi fisik atau logis pemohon. Informasi ini berguna untuk analisis 'Variasi Proses Pembayaran' guna mengetahui apakah wilayah tertentu mengikuti jalur yang tidak standar atau mengalami tingkat penolakan lebih tinggi. Mengapa ini penting Memberikan konteks geografis untuk kinerja proses. Sumber data Header transaksi, biasanya ditentukan dari Kode Cabang atau Kode Negara. Contoh Amerika UtaraEMEAAPAC | |||
Aktivitas pemrosesan pembayaran
| Aktivitas | Deskripsi | ||
|---|---|---|---|
| Dana Ditransfer | Menunjukkan bahwa jaringan pembayaran telah mengonfirmasi keberhasilan pendebitan dana dari rekening pembayar. Biasanya, konfirmasi ini diterima melalui pesan status masuk dari jaringan. | ||
| Mengapa ini penting Mengonfirmasi bahwa jaringan eksternal berhasil memproses pembayaran. Tahap ini menandai dimulainya periode penyelesaian dan menjadi masukan penting untuk KPI 'Rata-rata Waktu Penyelesaian Pembayaran'. Sumber data Peristiwa ini dipicu secara eksplisit oleh pesan pembaruan status yang masuk, misalnya MT103 dari SWIFT atau konfirmasi ACH, yang memperbarui catatan pembayaran. Pengumpulan data Dicatat saat pesan konfirmasi eksternal diterima dari jaringan kliring. Jenis peristiwa explicit | |||
| Kesalahan Pembayaran Teridentifikasi | Menandakan bahwa sistem mendeteksi masalah pada pembayaran di salah satu tahap, misalnya data tidak valid atau peringatan kepatuhan. Peristiwa ini biasanya dicatat secara eksplisit beserta kode kesalahan. | ||
| Mengapa ini penting Aktivitas ini menjadi titik awal untuk menganalisis pengerjaan ulang dan penanganan pengecualian. Data ini penting untuk dashboard 'Analisis Kegagalan dan Pengerjaan Ulang Pembayaran' serta 'Waktu Siklus Penyelesaian Kesalahan'. Sumber data Cari entri yang jelas pada tabel log kesalahan atau perubahan status menjadi 'Kesalahan' atau 'Perlu Diperbaiki' di tabel transaksi. Hubungkan peristiwa ini dengan ID Transaksi Pembayaran. Pengumpulan data Peristiwa dicatat secara eksplisit saat mesin validasi atau pemrosesan sistem menandai adanya kesalahan. Jenis peristiwa explicit | |||
| Pembayaran Diotorisasi | Menandai otorisasi pembayaran di tingkat sistem setelah persetujuan manusia. Sistem memverifikasi dana atau memeriksa aturan pencegahan penipuan. Peristiwa ini dapat tercatat secara eksplisit atau disimpulkan dari perubahan status yang menunjukkan kesiapan untuk diproses. | ||
| Mengapa ini penting Ini adalah titik kontrol penting sebelum instruksi pemindahan dana dikirim. Keterlambatan pada tahap ini dapat menunjukkan masalah kinerja sistem atau kendala pada subsistem kepatuhan dan pemeriksaan penipuan. Sumber data Cari catatan eksplisit di log pemrosesan sistem atau log keamanan. Anda juga dapat menyimpulkannya dari perubahan status 'Disetujui' menjadi 'Pembayaran Diotorisasi'. Pengumpulan data Dicatat oleh mesin pembayaran sistem setelah pemeriksaan internal akhir berhasil dilewati. Jenis peristiwa explicit | |||
| Pembayaran Diselesaikan | Konfirmasi akhir bahwa proses pembayaran telah selesai dan dana telah masuk ke rekening penerima. Peristiwa penting ini menandai keberhasilan akhir siklus pembayaran. | ||
| Mengapa ini penting Ini adalah peristiwa akhir utama yang menandai keberhasilan proses. Data ini digunakan untuk menghitung waktu siklus dan kapasitas pemrosesan secara keseluruhan, serta penting bagi hampir semua dashboard kinerja dari awal hingga akhir. Sumber data Biasanya tercatat sebagai peristiwa eksplisit saat pesan konfirmasi penyelesaian akhir diterima dari jaringan atau saat buku besar internal diperbarui untuk menunjukkan bahwa transaksi telah selesai. Pengumpulan data Dicatat saat file atau pesan penyelesaian akhir diterima, lalu status diperbarui menjadi 'Selesai'. Jenis peristiwa explicit | |||
| Pembayaran Disetujui | Tahap penting ketika pengguna berwenang menyetujui pembayaran agar proses dapat dilanjutkan. Biasanya, sistem mencatat peristiwa ini secara eksplisit saat pemberi persetujuan mengambil tindakan melalui antarmuka pengguna. | ||
| Mengapa ini penting Aktivitas ini merupakan titik pemeriksaan penting dan sering menjadi hambatan yang signifikan. Analisis waktu tunggu sebelum tahap ini dan durasi siklus persetujuan membantu menemukan peluang untuk mempercepat pembayaran. Sumber data Cari peristiwa yang tercatat secara eksplisit di tabel log persetujuan, atau perubahan status menjadi 'Disetujui' di tabel transaksi utama yang terkait dengan tindakan dan stempel waktu pengguna tertentu. Pengumpulan data Dicatat saat pengguna berwenang menyelesaikan tindakan persetujuan di sistem. Jenis peristiwa explicit | |||
| Permintaan Pembayaran Dibuat | Aktivitas ini menandai dimulainya transaksi pembayaran baru di sistem ACI Worldwide. Biasanya, sistem mencatat peristiwa ini secara eksplisit saat pengguna atau sistem hulu mengirimkan permintaan pembayaran. Catatan transaksi baru dengan ID unik pun dibuat. | ||
| Mengapa ini penting Ini adalah peristiwa awal utama dalam proses pembayaran. Dengan menganalisis waktu dari aktivitas ini hingga proses selesai, Anda dapat menghitung waktu siklus dari awal hingga akhir. Angka ini penting untuk mengukur efisiensi proses secara keseluruhan. Sumber data Peristiwa ini kemungkinan tercatat secara eksplisit di tabel transaksi utama atau log peristiwa khusus di ACI. Cari stempel waktu pembuatan yang terkait dengan ID Transaksi Pembayaran. Pengumpulan data Dikenali dari catatan pembuatan atau peristiwa 'Buat' yang tercatat secara eksplisit di log transaksi. Jenis peristiwa explicit | |||
| Detail Pembayaran Divalidasi | Menandai selesainya pemeriksaan otomatis atau manual untuk memastikan detail pembayaran, seperti informasi penerima dan kode bank, sudah benar. Aktivitas ini sering disimpulkan dari perubahan status transaksi, misalnya dari 'Baru' menjadi 'Tervalidasi' atau 'Menunggu Persetujuan'. | ||
| Mengapa ini penting Mengukur efisiensi tahap validasi data awal. Keterlambatan pada tahap ini dapat menimbulkan hambatan di tahap berikutnya dan meningkatkan kemungkinan kesalahan pembayaran. Sumber data Disimpulkan dari perubahan kolom status pada tabel transaksi pembayaran utama. Bandingkan stempel waktu status 'Dibuat' dengan status berikutnya, seperti 'Tervalidasi'. Pengumpulan data Disimpulkan dari perubahan kolom status pembayaran, misalnya dari 'Dimasukkan' menjadi 'Tervalidasi'. Jenis peristiwa inferred | |||
| Instruksi Pembayaran Dikirim | Menandai saat instruksi pembayaran disusun dan dikirim ke jaringan pembayaran eksternal seperti SWIFT, ACH, atau SEPA. Sistem ACI mencatat serah terima ini secara eksplisit untuk keperluan audit dan pelacakan. | ||
| Mengapa ini penting Untuk banyak jenis pembayaran, tahap ini menjadi titik setelahnya proses sulit dibatalkan. Pelacakan tahap ini membantu mengukur waktu pemrosesan internal sebelum proses bergantung pada pihak eksternal. Sumber data Hampir selalu tercatat secara eksplisit di log transaksi atau pesan ACI, sering kali disertai nomor referensi khusus jaringan. Pengumpulan data Catatan eksplisit dibuat saat pesan pembayaran dikirim ke jaringan eksternal. Jenis peristiwa explicit | |||
| Kesalahan Pembayaran Diselesaikan | Menandai saat pengguna memperbaiki kesalahan yang sebelumnya teridentifikasi dan pembayaran dikirim ulang untuk diproses. Peristiwa ini sering disimpulkan dari perubahan status pembayaran, dari status kesalahan kembali ke status pemrosesan normal. | ||
| Mengapa ini penting Aktivitas ini menutup rangkaian penanganan pengecualian. Waktu antara 'Kesalahan Pembayaran Teridentifikasi' dan peristiwa ini menjadi waktu siklus penyelesaian kesalahan, salah satu ukuran utama efisiensi operasional. Sumber data Disimpulkan dari perubahan status dari 'Kesalahan' ke status pemrosesan seperti 'Menunggu Persetujuan' atau 'Tervalidasi'. Peristiwa ini juga dapat dicatat secara eksplisit sebagai tindakan pengguna. Pengumpulan data Disimpulkan dari perubahan status keluar dari status kesalahan, yang menandakan bahwa perbaikan telah dilakukan. Jenis peristiwa inferred | |||
| Pembayaran Dikirim untuk Persetujuan | Menunjukkan bahwa pembayaran telah lolos validasi awal dan diteruskan untuk mendapatkan persetujuan manajerial atau keuangan. Biasanya, perubahan status ini tercatat dalam alur kerja pembayaran. | ||
| Mengapa ini penting Aktivitas ini menandai dimulainya subproses persetujuan. Mengukur waktu dari tahap ini hingga 'Pembayaran Disetujui' penting untuk dashboard 'Analisis Waktu Siklus Persetujuan Pembayaran'. Sumber data Disimpulkan dari perubahan kolom status pembayaran dalam data transaksi, misalnya saat status berubah menjadi 'Menunggu Persetujuan'. Pengumpulan data Disimpulkan dari perubahan status menjadi 'Menunggu Persetujuan' atau status serupa, beserta stempel waktunya. Jenis peristiwa inferred | |||
| Pembayaran Dikonfirmasi | Menandai pengakuan internal bahwa pembayaran berhasil diproses dan konfirmasi telah diterima. Tahap ini sering memicu pemberitahuan kepada penerima pembayaran atau sistem internal lainnya. | ||
| Mengapa ini penting Tahap ini penting untuk mengukur kepatuhan terhadap tanggal jatuh tempo dan tingkat pembayaran tepat waktu. Stempel waktunya menunjukkan dengan jelas kapan organisasi menganggap pembayaran berhasil diproses. Sumber data Biasanya disimpulkan dari perubahan status di tabel transaksi pembayaran menjadi 'Dikonfirmasi' atau 'Selesai' setelah konfirmasi dari jaringan eksternal diterima. Pengumpulan data Disimpulkan dari perubahan status menjadi 'Dikonfirmasi' atau 'Diproses'. Jenis peristiwa inferred | |||
| Pembayaran Direkonsiliasi | Menandai tahap akhir akuntansi, saat transaksi pembayaran yang tercatat di ACI dicocokkan dengan rekening koran atau entri buku besar. Peristiwa ini dapat dicatat secara eksplisit oleh modul rekonsiliasi atau disimpulkan dari perubahan status. | ||
| Mengapa ini penting Aktivitas ini mengukur efisiensi proses rekonsiliasi di bagian back-office. Keterlambatan dapat memengaruhi keakuratan laporan keuangan dan membuat masalah pembayaran yang belum diselesaikan luput dari perhatian. Sumber data Informasi ini dapat berasal dari modul rekonsiliasi khusus di ACI atau sistem ERP eksternal. Data dapat direkam melalui pembaruan status pembayaran menjadi 'Direkonsiliasi'. Pengumpulan data Disimpulkan dari pembaruan status akhir menjadi 'Direkonsiliasi' atau dari data rekonsiliasi yang digabungkan berdasarkan ID Pembayaran. Jenis peristiwa inferred | |||
| Pembayaran Ditolak | Terjadi saat pemberi persetujuan menolak permintaan pembayaran. Pembayaran biasanya perlu diperbaiki dan diajukan kembali. Peristiwa ini tercatat secara eksplisit, menghentikan proses pembayaran, dan memulai siklus pengerjaan ulang. | ||
| Mengapa ini penting Menunjukkan adanya pengerjaan ulang dan ketidakefisienan proses. Melacak frekuensi penolakan membantu menemukan masalah pada kualitas data awal atau kebijakan pengajuan, serta mendukung analisis pengerjaan ulang. Sumber data Dicatat sebagai peristiwa eksplisit di log persetujuan atau sebagai perubahan status menjadi 'Ditolak' di tabel transaksi. Peristiwa ini mungkin menyertakan kode alasan penolakan. Pengumpulan data Dicatat saat pemberi persetujuan menyelesaikan tindakan penolakan di sistem. Jenis peristiwa explicit | |||
| Pembayaran Gagal | Status akhir yang menandakan pembayaran tidak dapat diselesaikan karena masalah yang tidak bisa dipulihkan. Status ini berbeda dari kesalahan yang masih dapat diperbaiki dan menandai kegagalan definitif. | ||
| Mengapa ini penting Melacak peristiwa akhir ini penting untuk menghitung tingkat kegagalan pembayaran secara keseluruhan. Analisis penyebab kegagalan dapat membantu meningkatkan kualitas data dan aturan proses. Sumber data Disimpulkan dari status akhir seperti 'Gagal', 'Dibatalkan', atau 'Ditolak oleh Bank' pada data transaksi, yang tidak berubah lagi setelahnya. Pengumpulan data Disimpulkan dari status kegagalan akhir pada catatan pembayaran. Jenis peristiwa inferred | |||
Panduan ekstraksi
Langkah
Akses lingkungan database: Masuk ke instans SQL Server yang menampung database ACI Postilion Realtime menggunakan SQL Server Management Studio (SSMS) atau klien yang kompatibel.
Temukan tabel utama: Cari tabel
post_tran(log transaksi) danpost_tran_cust(ekstensi data khusus). Pastikan Anda memiliki izinSELECTuntuk objek tersebut.Tentukan pengenal kasus: Ekstraksi ini menggunakan
retrieval_reference_nrsebagaiPaymentTransactionId. Jika implementasi Anda menggunakan kunci unik lain (seperti gabungansystem_trace_audit_nrdantransmission_date_time), sesuaikan pemilihan kolom dalam kueri.Atur parameter filter: Buka kueri di bawah. Cari variabel
@StartDatedan@EndDatedi bagian atas skrip. Atur rentang ekstraksi yang diinginkan (misalnya, 30 hingga 90 hari terakhir) untuk mengoptimalkan kinerja.Tinjau logika aktivitas: Kueri memetakan jenis pesan ISO 8583 (misalnya, 0200, 0210) dan kode respons ke 14 aktivitas process mining yang diperlukan. Tinjau pernyataan
CASEuntuk memastikan pemetaannya sesuai dengan konfigurasi antarmuka ACI Anda.Jalankan kueri: Eksekusi seluruh skrip. Kueri menggunakan
UNION ALLuntuk menyatukan berbagai status transaksi ke dalam satu format log peristiwa.Periksa hasil data: Pastikan hasil memuat kolom yang diperlukan:
PaymentTransactionId,ActivityName, danEventTimestamp. Periksa apakah ada kolom penting yang tanpa diduga berisi nilaiNULL.Ekspor data: Klik kanan kisi hasil di SSMS, lalu simpan sebagai file CSV (misalnya,
ACI_Payments_EventLog.csv).Siapkan data untuk ProcessMind: Buka file CSV dan pastikan
EventTimestampmenggunakan format standar (YYYY-MM-DD HH:MM:SS) sertaPaymentAmounthanya berisi nilai numerik.Unggah: Impor file CSV yang sudah diverifikasi ke ProcessMind, lalu petakan kolom masing-masing ke Case ID, Activity, dan Timestamp.
Konfigurasi
- Date Range: Tabel ACI
post_tranberkembang sangat cepat. Sebaiknya batasi ekstraksi pada rentang bergulir 3 bulan atau gunakan partition switching jika tersedia. - Response Codes: Kueri menganggap
rsp_code = '00'sebagai tanda berhasil. Jika institusi Anda menggunakan kode persetujuan/keberhasilan lain (misalnya, '08' atau '10'), perbarui filternya. - Message Types (ISO 8583): Skrip menggunakan jenis pesan standar (0100/0200 untuk permintaan, 0210 untuk respons). Jenis pesan khusus yang ditentukan dalam konfigurasi
source_node_namemungkin perlu disesuaikan. - System Performance: Kueri ini menggunakan petunjuk
NOLOCKuntuk mencegah pemblokiran pemrosesan transaksi aktif. Jangan hapus petunjuk ini di lingkungan produksi. - Currencies: Jumlah diekstrak sebagai angka mentah. Pastikan
tran_currency_codedigunakan jika analisis memerlukan normalisasi berbagai mata uang.
Contoh kueri 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; Siap memulai?
Gunakan templat ini sebagai panduan untuk mulai mengekstrak data pemrosesan pembayaran Anda. Dapatkan wawasan berharga dan tingkatkan efisiensi alur kerja keuangan Anda.
Sederhanakan pemrosesan pembayaran: mulai uji coba gratis sekarang
Kurangi pengecualian pembayaran dan capai pemrosesan langsung 98%.
Tidak perlu kartu kredit, penyiapan hanya beberapa menit