Templat data pemrosesan pembayaran Anda
Templat data pemrosesan pembayaran Anda
- Atribut yang disarankan untuk analisis pembayaran
- Tahapan penting proses yang perlu dipantau
- Panduan teknis untuk mengekstrak data Fiserv
Atribut pemrosesan pembayaran
| Nama | Deskripsi | ||
|---|---|---|---|
|
ID Transaksi Pembayaran
PaymentTransactionId
|
Pengenal unik untuk instruksi pembayaran atau kasus transaksi tertentu. | ||
|
Deskripsi
Atribut ini menjadi kunci utama untuk menghubungkan semua aktivitas dalam satu siklus pembayaran. Analis dapat menelusuri proses sejak permintaan awal, validasi, dan persetujuan hingga penyelesaian atau pembatalan. Di lingkungan Fiserv, atribut ini biasanya menjadi kunci utama dalam tabel riwayat transaksi. Atribut ini penting untuk menyusun kembali alur proses dan memastikan peristiwa yang terpisah, seperti penyelesaian yang terjadi beberapa hari setelah otorisasi, tetap dikaitkan dengan objek bisnis yang sama.
Mengapa ini penting
Ini adalah ID Kasus utama yang diperlukan untuk mengelompokkan peristiwa ke dalam instans proses.
Sumber data
Lihat dokumentasi Fiserv untuk tabel Transaksi atau Header Pembayaran.
Contoh
TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
|
|||
|
Nama Aktivitas
ActivityName
|
Peristiwa atau perubahan status tertentu yang terjadi dalam proses pembayaran. | ||
|
Deskripsi
Atribut ini menjelaskan tahap yang dilakukan, seperti 'Permintaan Pembayaran Dibuat' atau 'Pembayaran Diselesaikan'. Atribut ini menentukan simpul dalam peta proses dan penting untuk memahami urutan operasional. Dengan menganalisis aktivitas yang berbeda, organisasi dapat melihat alur kerja, menemukan tahap yang terlewat, dan mendeteksi jalur yang tidak patuh karena validasi atau persetujuan wajib dilewati.
Mengapa ini penting
Menentukan peristiwa yang membentuk linimasa proses.
Sumber data
Log riwayat transaksi atau tabel audit perubahan status.
Contoh
Permintaan pembayaran dibuatPembayaran diotorisasiKesalahan pembayaran terdeteksiPembayaran DiselesaikanPembayaran Dibatalkan
|
|||
|
Stempel Waktu Peristiwa
EventTimestamp
|
Tanggal dan waktu persis saat aktivitas terjadi. | ||
|
Deskripsi
Atribut ini mencatat waktu persis terjadinya suatu peristiwa. Data ini menjadi dasar analisis waktu, termasuk waktu siklus, waktu penyelesaian, dan identifikasi hambatan. Di dasbor, data ini digunakan untuk menghitung durasi antar tahap, misalnya waktu dari 'Permintaan Pembayaran Dibuat' hingga 'Pembayaran Diotorisasi'. Stempel waktu yang akurat diperlukan untuk mengurutkan peristiwa yang terjadi dalam waktu berdekatan.
Mengapa ini penting
Diperlukan untuk mengurutkan peristiwa dan menghitung durasi kinerja proses.
Sumber data
Log audit atau kolom stempel waktu pembaruan transaksi.
Contoh
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
|
|||
|
Pembaruan Data Terakhir
LastDataUpdate
|
Stempel waktu saat data terakhir diekstrak atau diperbarui. | ||
|
Deskripsi
Menunjukkan seberapa baru data yang digunakan untuk analisis. Ini penting untuk mengetahui apakah dasbor menampilkan operasional terkini atau data historis. Informasi ini membantu pengguna memercayai metrik yang ditampilkan dan menghindari keputusan berdasarkan data lama, terutama saat memantau kepatuhan terhadap batas waktu atau hambatan yang sedang terjadi.
Mengapa ini penting
Memastikan data tetap terkini dan dapat diandalkan.
Sumber data
Waktu sistem saat ETL dijalankan.
Contoh
2023-10-27T12:00:00Z2023-10-28T06:00:00Z
|
|||
|
Sistem Sumber
SourceSystem
|
Nama sistem asal data. | ||
|
Deskripsi
Menunjukkan modul Fiserv atau sistem eksternal tertentu yang menghasilkan peristiwa. Ini berguna terutama dalam lanskap sistem yang kompleks, ketika pembayaran dapat dimulai melalui kanal front-end dan diselesaikan di sistem perbankan inti back-end. Analis dapat memfilter tampilan proses berdasarkan sistem asal, sehingga analisis dapat difokuskan pada lingkungan teknis atau titik integrasi tertentu.
Mengapa ini penting
Memberikan konteks teknis dan asal-usul data.
Sumber data
Diisi secara tetap saat ekstraksi atau diambil dari metadata sistem.
Contoh
Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
|
|||
|
Jumlah Pembayaran
PaymentAmount
|
Nilai uang dalam transaksi pembayaran. | ||
|
Deskripsi
Atribut ini menunjukkan nilai finansial pembayaran. Atribut ini menjadi dimensi utama untuk mengelompokkan analisis, sehingga pengguna dapat membedakan pembayaran strategis bernilai tinggi dari transaksi rutin bernilai rendah. Atribut ini penting untuk Tampilan Deteksi Pembayaran Ganda. Jumlah yang sama dengan detail pembayar atau penerima yang sama dapat menandakan potensi kesalahan. Atribut ini juga mendukung analisis otoritas persetujuan, karena pembayaran bernilai lebih tinggi sering mengikuti alur kerja yang berbeda.
Mengapa ini penting
Penting untuk analisis risiko keuangan dan deteksi pembayaran ganda.
Sumber data
Tabel header transaksi, kolom Amount.
Contoh
150.0025000.5010.991000000.00
|
|||
|
Kode Kesalahan
ErrorCode
|
Kode khusus yang dibuat saat pembayaran gagal divalidasi. | ||
|
Deskripsi
Mencatat kode kesalahan teknis atau bisnis yang terkait dengan aktivitas 'Kesalahan Pembayaran Ditemukan'. Atribut ini menjadi dasar Pelacak Kesalahan Validasi dan Pengerjaan Ulang. Dengan menghitung frekuensi setiap kode kesalahan, organisasi dapat menemukan masalah kualitas data yang berulang, seperti 'Nomor Perutean Tidak Valid', lalu memperbaiki logika validasi atau memberikan pelatihan yang sesuai.
Mengapa ini penting
Menunjukkan akar penyebab pengerjaan ulang.
Sumber data
Log kesalahan atau detail status transaksi.
Contoh
E-101INV_ACCNSF_ERRAUTH_FAIL
|
|||
|
Kode Mata Uang
CurrencyCode
|
Kode mata uang ISO untuk jumlah pembayaran. | ||
|
Deskripsi
Menentukan mata uang pembayaran, misalnya USD atau EUR. Atribut ini penting untuk dasbor Tren Volume berdasarkan Mata Uang dan Metode, yang membantu organisasi memantau eksposur terhadap berbagai mata uang asing. Atribut ini juga digunakan untuk menormalkan jumlah dalam pelaporan global dan memastikan pemeriksaan pembayaran ganda tidak keliru menandai transaksi dengan nilai angka sama tetapi mata uang berbeda.
Mengapa ini penting
Diperlukan untuk analisis pemrosesan multi-mata uang.
Sumber data
Tabel header transaksi, kolom Currency.
Contoh
USDEURGBPCADJPY
|
|||
|
Metode Pembayaran
PaymentMethod
|
Cara pembayaran dilakukan, misalnya Wire atau ACH. | ||
|
Deskripsi
Mengelompokkan transaksi berdasarkan jalur pemrosesannya. Atribut ini menjadi dasar Analisis Waktu Siklus Otorisasi, karena setiap metode memiliki prosedur operasional standar dan perjanjian tingkat layanan yang berbeda. Analisis variasi proses berdasarkan metode pembayaran membantu mengetahui apakah keterlambatan hanya terjadi pada kanal tertentu, seperti Wire internasional, atau di seluruh organisasi.
Mengapa ini penting
Mengelompokkan alur proses berdasarkan infrastruktur yang digunakan.
Sumber data
Kolom jenis transaksi atau kode instrumen.
Contoh
WireACHCekRTPTransfer Internal
|
|||
|
Nomor Rekening Pembayar
PayerAccountNumber
|
Nomor rekening sumber pendebitan dana. | ||
|
Deskripsi
Menunjukkan rekening sumber pembayaran. Atribut ini menjadi komponen penting dalam Tampilan Deteksi Pembayaran Ganda. Jika digabungkan dengan penerima, jumlah, dan waktu, atribut ini membentuk pola unik untuk mendeteksi pembayaran ganda yang tidak disengaja. Atribut ini juga memungkinkan analisis volume pembayaran berdasarkan rekening asal untuk mengetahui portofolio internal yang paling aktif.
Mengapa ini penting
Penting untuk deteksi pembayaran ganda dan analisis penipuan.
Sumber data
Detail transaksi, kolom Debit Account.
Contoh
123456789987654321ACC-001-992
|
|||
|
Nomor Rekening Penerima
PayeeAccountNumber
|
Nomor rekening tujuan pengkreditan dana. | ||
|
Deskripsi
Menunjukkan rekening tujuan. Seperti rekening pembayar, atribut ini penting untuk Tampilan Deteksi Pembayaran Ganda. Atribut ini memastikan analisis menyasar hubungan dengan penerima yang tepat. Dalam pemantauan kepatuhan terhadap batas waktu, informasi penerima dapat membantu memprioritaskan vendor strategis atau penyelesaian penting yang tidak boleh gagal.
Mengapa ini penting
Penting untuk deteksi pembayaran ganda dan analisis penerima.
Sumber data
Detail transaksi, kolom Credit Account atau Beneficiary.
Contoh
555000111222333444BEN-882-11
|
|||
|
Pemrosesan Langsung
IsStraightThroughProcessing
|
Penanda yang menunjukkan apakah pembayaran diproses tanpa campur tangan manual. | ||
|
Deskripsi
Atribut boolean hasil perhitungan yang bernilai benar jika kasus tidak mencakup tahap 'Kesalahan Pembayaran Ditemukan', 'Kesalahan Pembayaran Diselesaikan', atau 'Pembayaran Disetujui' secara manual, bergantung pada definisinya. Atribut ini mendukung KPI Tingkat Pemrosesan Langsung. Atribut ini memungkinkan proses dikelompokkan menjadi dua: alur yang sepenuhnya otomatis dan alur yang memerlukan campur tangan manusia. Dengan begitu, potensi otomatisasi terlihat jelas.
Mengapa ini penting
Metrik utama untuk efisiensi proses dan keberhasilan otomatisasi.
Sumber data
Dihitung saat transformasi data.
Contoh
truefalse
|
|||
|
Pengguna Pemroses
ProcessingUser
|
ID pengguna atau agen sistem yang bertanggung jawab atas aktivitas tersebut. | ||
|
Deskripsi
Menunjukkan siapa yang melakukan tindakan tertentu, baik pemberi persetujuan maupun bot otomatisasi sistem. Data ini mendukung dasbor Efisiensi Siklus Penyelesaian Kesalahan dan Throughput Otoritas Persetujuan. Dengan melacak pengguna, analis dapat mengetahui siapa yang memerlukan pelatihan karena sering melakukan kesalahan, atau menemukan hambatan saat pemberi persetujuan tertentu menerima terlalu banyak permintaan.
Mengapa ini penting
Mendukung analisis sumber daya dan identifikasi hambatan.
Sumber data
Log audit, kolom User ID.
Contoh
jdoeSYSTEM_BATCHmsmith_approverAPI_USER
|
|||
|
Tanggal Jatuh Tempo Pembayaran
PaymentDueDate
|
Tanggal batas pembayaran harus diproses. | ||
|
Deskripsi
Tanggal target penyelesaian pembayaran. Pemantau Kepatuhan Batas Waktu Pemrosesan menggunakan tanggal ini untuk menandai transaksi yang berisiko terlambat. Dengan membandingkan stempel waktu 'Pembayaran Diselesaikan' dengan atribut ini, organisasi dapat menghitung metrik ketepatan waktu dan menjaga kepercayaan penerima.
Mengapa ini penting
Acuan untuk mengukur kepatuhan terhadap SLA.
Sumber data
Detail instruksi pembayaran.
Contoh
2023-11-012023-11-15
|
|||
|
Bank Penerima
BeneficiaryBank
|
Nama atau pengenal bank penerima. | ||
|
Deskripsi
Menunjukkan lembaga keuangan yang menerima pembayaran. Informasi ini berguna untuk menganalisis keterlambatan penyelesaian, karena kecepatan pemrosesan dan masalah integrasi dapat berbeda di setiap bank penerima. Atribut ini menambah dimensi pada dasbor Jeda antara Penyelesaian dan Rekonsiliasi, sehingga organisasi dapat mengetahui apakah keterlambatan berasal dari pihak eksternal, seperti bank tertentu, atau dari proses internal.
Mengapa ini penting
Analisis ketergantungan eksternal.
Sumber data
Detail transaksi, kolom Bank ID atau Name.
Contoh
ChaseBank of AmericaWells FargoCitibank
|
|||
|
Batas Waktu Terlewat
IsCutoffMissed
|
Penanda yang menunjukkan apakah pembayaran dikirim setelah batas waktu harian bank. | ||
|
Deskripsi
Nilai boolean hasil perhitungan yang membandingkan waktu 'Instruksi Pembayaran Dikirim' dengan batas waktu harian untuk mata uang dan metode terkait. Atribut ini mendukung KPI Tingkat Kepatuhan terhadap Batas Waktu. Dengan mengetahui batas waktu yang terlewat, organisasi dapat menyelidiki penyebab keterlambatan, baik karena proses dimulai terlambat maupun pemrosesan internal yang lambat.
Mengapa ini penting
Penting untuk kepatuhan operasional dan pengelolaan likuiditas.
Sumber data
Dihitung dengan membandingkan EventTimestamp dengan tabel Cutoff Reference.
Contoh
truefalse
|
|||
|
Pengerjaan Ulang
IsRework
|
Penanda yang menunjukkan apakah aktivitas ini merupakan bagian dari siklus pengerjaan ulang. | ||
|
Deskripsi
Penanda boolean untuk aktivitas yang terjadi setelah kesalahan ditemukan tetapi sebelum diselesaikan, atau untuk aktivitas yang diulang. Atribut ini mendukung KPI Tingkat Pengerjaan Ulang Validasi Pembayaran. Analis dapat memfilter peta proses untuk hanya menampilkan 'alur normal', atau berfokus pada 'alur pengerjaan ulang' guna memahami penyebab kegagalan.
Mengapa ini penting
Memisahkan pekerjaan yang memberi nilai tambah dari pekerjaan perbaikan.
Sumber data
Dihitung berdasarkan siklus dalam proses.
Contoh
truefalse
|
|||
|
Tingkat Persetujuan
ApprovalLevel
|
Tingkat hierarki yang diperlukan atau digunakan untuk mengotorisasi pembayaran. | ||
|
Deskripsi
Menunjukkan senioritas atau tingkat kewenangan yang terkait dengan aktivitas 'Pembayaran Disetujui'. Dasbor Throughput Otoritas Persetujuan menggunakan data ini untuk menganalisis apakah pemberi persetujuan tingkat tinggi menjadi hambatan. Memahami sebaran pembayaran di setiap tingkat, misalnya Tingkat 1 dan Tingkat 3, membantu mengoptimalkan kebijakan pendelegasian wewenang.
Mengapa ini penting
Mengelompokkan hambatan persetujuan berdasarkan hierarki.
Sumber data
Tabel peran pengguna atau alur kerja persetujuan.
Contoh
Tingkat 1ManajerDirekturCFO
|
|||
|
Unit Bisnis
BusinessUnit
|
Departemen atau divisi yang memulai pembayaran. | ||
|
Deskripsi
Mengelompokkan pembayaran berdasarkan unit organisasi yang bertanggung jawab atas pengeluaran. Informasi ini membantu mengalokasikan biaya dan mengetahui bagian organisasi yang paling banyak menghasilkan pengerjaan ulang manual atau kesalahan. Informasi ini mendukung Audit Kepatuhan Jalur Pembayaran dengan memastikan setiap unit mematuhi persyaratan regulasi atau pengendalian internal yang berlaku.
Mengapa ini penting
Memberikan konteks organisasi untuk menilai kinerja.
Sumber data
Pemetaan pusat biaya atau kode departemen.
Contoh
Perbankan RitelKredit KomersialManajemen KekayaanOperasional
|
|||
Aktivitas pemrosesan pembayaran
| Aktivitas | Deskripsi | ||
|---|---|---|---|
|
Instruksi Pembayaran Dikirim
|
Pengiriman berkas pembayaran, misalnya batch ACH atau pesan Wire, ke jaringan eksternal atau lembaga kliring. Ini merupakan titik serah terima yang penting. | ||
|
Mengapa ini penting
Penting untuk 'Pemantau Kepatuhan Batas Waktu Pemrosesan'. Memastikan organisasi memenuhi batas waktu perbankan harian.
Sumber data
Log pemrosesan batch atau stempel waktu pembuatan berkas. Biasanya dicatat sebagai 'Batch Dibuat' atau 'Berkas Dikirim'.
Pengumpulan data
Dicatat saat berkas batch dibuat
Jenis peristiwa
explicit
|
|||
|
Pembayaran Direkonsiliasi
|
Pencocokan internal transaksi dengan rekening koran atau berkas penyelesaian. Tahap ini menuntaskan proses pencatatan akuntansi. | ||
|
Mengapa ini penting
Diperlukan untuk 'Jeda antara Penyelesaian dan Rekonsiliasi'. Memastikan pembukuan keuangan ditutup dengan akurat.
Sumber data
Log modul rekonsiliasi saat status berubah menjadi 'Cocok' atau 'Direkonsiliasi'.
Pengumpulan data
Dicatat saat transaksi berhasil dicocokkan dalam rekonsiliasi
Jenis peristiwa
explicit
|
|||
|
Pembayaran Diselesaikan
|
Perpindahan dana selesai dan dicatat dalam buku besar. Dari sudut pandang bank, tahap ini menandai penyelesaian transaksi secara finansial. | ||
|
Mengapa ini penting
Titik akhir utama untuk 'Tingkat Pemrosesan Langsung'. Menunjukkan bahwa dana benar-benar telah berpindah.
Sumber data
Status transaksi 'Diposting' atau adanya stempel waktu 'Tanggal Posting' di buku besar.
Pengumpulan data
Dicatat saat posting ke buku besar terjadi
Jenis peristiwa
explicit
|
|||
|
Pembayaran disetujui
|
Keputusan manual atau otomatis untuk melanjutkan pembayaran berdasarkan batas wewenang. Aktivitas ini tercatat saat pengguna berwenang atau aturan sistem memperbarui tanda persetujuan. | ||
|
Mengapa ini penting
Penting untuk 'Authorization Cycle Time Analysis'. Keterlambatan pada tahap ini menunjukkan hambatan dalam rantai persetujuan.
Sumber data
Log audit yang menunjukkan tindakan pengguna mengubah status dari 'Pending Approval' menjadi 'Approved'.
Pengumpulan data
Dicatat saat persetujuan diberikan
Jenis peristiwa
explicit
|
|||
|
Permintaan pembayaran dibuat
|
Instruksi pembayaran pertama kali dimasukkan ke sistem Fiserv. Aktivitas ini tercatat saat pengguna atau sistem eksternal memulai transaksi melalui API atau antarmuka. | ||
|
Mengapa ini penting
Menandai awal linimasa proses. Penting untuk menghitung waktu siklus total dan menemukan hambatan pada tahap penerimaan.
Sumber data
Stempel waktu pembuatan tabel riwayat transaksi. Cari catatan paling awal dengan Payment Transaction ID yang sesuai.
Pengumpulan data
Dicatat saat catatan transaksi dimasukkan
Jenis peristiwa
explicit
|
|||
|
Detail pembayaran divalidasi
|
Sistem memeriksa nomor rekening, nomor perutean, dan kesesuaian format. Aktivitas ini biasanya disimpulkan saat transaksi berhasil berubah dari status diterima menjadi tertunda atau disetujui tanpa memicu kesalahan. | ||
|
Mengapa ini penting
Menunjukkan bahwa pemeriksaan otomatis pertama telah dilewati. Kegagalan pada tahap ini menandakan masalah kualitas data, bukan masalah likuiditas atau persetujuan.
Sumber data
Disimpulkan dari perubahan status 'Received' menjadi 'Pending' atau 'Ready' dalam waktu singkat.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Kesalahan pembayaran diselesaikan
|
Menunjukkan bahwa transaksi yang sebelumnya mengalami kesalahan telah diperbaiki. Aktivitas ini disimpulkan saat status transaksi berubah dari kesalahan menjadi pemrosesan atau valid. | ||
|
Mengapa ini penting
Penting untuk menghitung 'Mean Time to Resolve Payment Errors'. Metrik ini membantu mengukur efisiensi tim operasional.
Sumber data
Disimpulkan saat status transaksi berubah dari kode kesalahan menjadi kode pemrosesan normal.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
|
Kesalahan pembayaran terdeteksi
|
Mencatat saat transaksi ditandai dengan status gagal atau kode pengecualian. Hal ini terjadi ketika aturan validasi gagal atau pemeriksaan eksternal memberikan respons negatif. | ||
|
Mengapa ini penting
Penting untuk dasbor 'Validation Error and Rework Tracker'. Volume yang tinggi menunjukkan masalah kualitas data pada tahap sebelumnya.
Sumber data
Kolom status transaksi berubah menjadi kode pengecualian, misalnya 'Invalid', 'Hold', atau 'Error'.
Pengumpulan data
Dicatat saat status berubah menjadi Error
Jenis peristiwa
explicit
|
|||
|
Notifikasi Pembayaran Dikirim
|
Sistem mengirim pemberitahuan melalui email atau SMS kepada pembayar atau penerima untuk mengonfirmasi transaksi. Ini membantu pelanggan mengetahui status transaksi. | ||
|
Mengapa ini penting
Mendukung 'Kecepatan dan Ketanggapan Notifikasi'. Jeda panjang setelah penyelesaian pembayaran dapat mengurangi kepercayaan pelanggan.
Sumber data
Log komunikasi atau tabel riwayat interaksi pelanggan yang terhubung dengan ID Transaksi.
Pengumpulan data
Dicatat saat email atau SMS dikirim
Jenis peristiwa
explicit
|
|||
|
Pembayaran Dibatalkan
|
Penghentian alur pembayaran sebelum penyelesaian, yang dimulai oleh pengguna atau aturan sistem. Setelah itu, pemrosesan tidak dilanjutkan. | ||
|
Mengapa ini penting
Menunjukkan pekerjaan yang terbuang dan ditinggalkan. Tingkat pembatalan yang tinggi setelah persetujuan dapat menandakan proses yang tidak efisien.
Sumber data
Status berubah menjadi 'Dibatalkan', 'Dihapus', atau 'Dihentikan'.
Pengumpulan data
Dicatat saat status berubah menjadi Dibatalkan
Jenis peristiwa
explicit
|
|||
|
Pembayaran Dijadwalkan
|
Terjadi saat pembayaran disetujui, tetapi ditahan hingga tanggal efektif di masa mendatang. Sistem mengantrekan transaksi sampai jendela pemrosesan dibuka. | ||
|
Mengapa ini penting
Menjelaskan waktu menganggur dalam proses. Membedakan keterlambatan akibat hambatan dari penantian yang disengaja hingga tanggal jatuh tempo.
Sumber data
Perbandingan 'Tanggal Entri' dengan 'Tanggal Efektif'. Status ini aktif jika Tanggal Efektif berada di masa mendatang.
Pengumpulan data
Ditentukan dengan membandingkan kolom X dan Y
Jenis peristiwa
calculated
|
|||
|
Pembayaran Dikonfirmasi
|
Penerimaan tanda terima positif (ACK) dari jaringan eksternal atau gateway. Ini mengonfirmasi bahwa entitas berikutnya telah menerima instruksi dengan benar. | ||
|
Mengapa ini penting
Memastikan 'Instruksi Pembayaran Dikirim' berhasil. Jika ada jeda di sini, kemungkinan terdapat masalah konektivitas jaringan atau format eksternal.
Sumber data
Log pemrosesan berkas masuk atau kode respons API yang mengonfirmasi penerimaan.
Pengumpulan data
Dicatat saat ACK diterima
Jenis peristiwa
explicit
|
|||
|
Pembayaran diotorisasi
|
Konfirmasi internal terakhir bahwa dana tersedia dan transaksi siap dilaksanakan. Tahap ini dapat berlangsung bersamaan dengan persetujuan atau sebagai pemeriksaan sistem tersendiri. | ||
|
Mengapa ini penting
Membedakan persetujuan manajerial dari otorisasi di tingkat sistem. Penting untuk dasbor 'Throughput Otoritas Persetujuan'.
Sumber data
Perubahan status yang menunjukkan 'Diotorisasi' atau 'Siap Diposting'.
Pengumpulan data
Bandingkan kolom status sebelum dan sesudah
Jenis peristiwa
inferred
|
|||
Panduan ekstraksi
Siap memulai?
Mulai optimalkan alur kerja keuangan dengan menerapkan templat ini pada lingkungan Fiserv Anda. Panduan kami membantu memastikan data yang Anda miliki tepat untuk menghasilkan perbaikan nyata pada arus kas dan kepatuhan operasional.
Optimalkan pemrosesan pembayaran dan capai STP 98% hari ini
Kurangi keterlambatan rekonsiliasi dan kendalikan alur kerja Fiserv Anda.
Tidak perlu kartu kredit. Siapkan dalam hitungan menit.