Ödeme İşlemleri Data Template'iniz
Ödeme İşlemleri Data Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- ACI Worldwide için veri çıkarma rehberliği
Ödeme İşlemleri Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet Adı ActivityName | Ödeme yaşam döngüsünde meydana gelen belirli adım veya durum değişikliği. | ||
| Açıklama Bu öznitelik, süreç haritasındaki Neden önemli Süreç akışını tanımlar ve işlemlerin sırasını görselleştirmek için gereklidir. Nereden alınır Durum Kodlarından (örn. 100=Oluşturuldu, 200=Doğrulandı) veya Denetim Kaydı Eylem sütunlarından türetilmiştir. Örnekler Ödeme Talebi OluşturulduÖdeme YetkilendirildiÖdeme SonuçlandıÖdeme Başarısız Oldu | |||
| Ödeme İşlem Kimliği PaymentTransactionId | ACI sistemi genelindeki belirli ödeme talimatı için benzersiz tanımlayıcı. | ||
| Açıklama Bu öznitelik, tek bir ödeme talebiyle ilgili tüm Neden önemli Ayrık olayları süreç örnekleri halinde gruplandırmak için gerekli temel Case ID'dir. Nereden alınır Ana işlem log'unda genellikle TRN_REF, REFERENCE_NUM veya UUID olarak etiketlenmiş işlem başlığı tablolarını kontrol edin. Örnekler TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Olay Zaman Damgası EventTimestamp | Faaliyetin gerçekleştiği belirli tarih ve saat. | ||
| Açıklama Bu öznitelik, bir Neden önemli Olayları sıralamak ve performans sürelerini hesaplamak için gereklidir. Nereden alınır İşlem geçmişi veya denetim tablolarındaki 'Oluşturulma Tarihi' veya 'Güncelleme Tarihi' sütunlarına bakın. Örnekler 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Bölüm Department | Mevcut aktiviteden sorumlu dahili departman. | ||
| Açıklama
Neden önemli İş fonksiyonuna göre performansı bir araya getirir. Nereden alınır Kullanıcı tablolarından veya Organizasyonel Hiyerarşi eşlemesinden türetilmiştir. Örnekler OperasyonlarComplianceHazineBT Desteği | |||
| Hata Kodu ErrorCode | Bir ödeme başarısız olduğunda veya onarım gerektirdiğinde oluşturulan kod. | ||
| Açıklama 'Ödeme Başarısız Oldu' veya 'Ödeme Hatası Tespit Edildi' olayının belirli nedenini yakalar. Bu özniteliğe göre 'Ödeme Başarısızlık ve Yeniden İşleme Analizi' dashboard'unda gruplama, işletmenin en yaygın başarısızlık temel nedenlerini (örn. 'Yetersiz Fonlar', 'Geçersiz Hesap') belirlemesini sağlar. Neden önemli Süreç başarısızlıklarının Temel Neden Analizi için gereklidir. Nereden alınır Hata log'ları veya durum nedeni sütunları, genellikle REASON_CODE veya RETURN_CODE. Örnekler R01AM04BE05TECH_ERR_001 | |||
| İşleme Kanalı ProcessingChannel | Ödemenin başlatıldığı kanal. | ||
| Açıklama Ödemenin giriş noktasını gösterir (örn. Mobil, Web Portalı, API veya Dosya Yükleme). Bu, 'Ödeme Süreci Varyant Analizi'nde belirli kanalların diğerlerinden daha fazla hataya veya gecikmeye yatkın olup olmadığını görmek için yardımcı olur. Neden önemli Giriş yöntemine göre performansı segmentlere ayırır. Nereden alınır İşlem başlığı, genellikle CHANNEL, SOURCE_TYPE veya INPUT_METHOD adlı sütunlarda. Örnekler SWIFTİnternet BankacılığıMobil UygulamaDosya Yükleme | |||
| Ödeme Para Birimi PaymentCurrency | Ödeme tutarı için ISO para birimi kodu. | ||
| Açıklama
Neden önemli Ödeme Tutarını doğru bir şekilde yorumlamak için gereklidir. Nereden alınır İşlem detay tabloları, genellikle CCY, CURRENCY_CODE veya ISO_CODE gibi alanlar. Örnekler USDEURGBPJPY | |||
| Ödeme Türü PaymentType | Ödeme aracının sınıflandırılması. | ||
| Açıklama Ödemeyi kategorize eder (örn. Havale, ACH, SEPA, RTGS). Farklı ödeme türlerinin genellikle çok farklı SLA'ları ve süreç akışları vardır. Bu öznitelik, 'Uçtan Uca Ödeme Döngü Süresi' dashboard'unu filtrelemek için birincil bir boyuttur. Neden önemli Yüksek hızlı ve toplu ödeme akışları arasında ayrım yapmak için kritiktir. Nereden alınır İşlem başlığı, PMT_TYPE, INSTRUMENT_TYPE veya SERVICE_ID gibi alanlar. Örnekler Yurtiçi HavaleUluslararası HavaleACH CreditAnında Ödeme | |||
| Ödeme Tutarı PaymentAmount | Ödeme işleminin parasal değeri. | ||
| Açıklama Aktarılan finansal değeri gösterir. Bu, 'Ödeme Verimliliği'ni analiz etmek ve darboğazları önceliklendirmek için kritik bir bağlam alanıdır. Yüksek değerli ödemeler, düşük değerli otomatik akışlara kıyasla genellikle daha titiz onay yollarından (varyant analizi) geçer. Neden önemli Değere göre segmentasyona ve toplam işlenen hacmin hesaplanmasına olanak tanır. Nereden alınır İşlem detay tabloları, genellikle AMT, TRANS_AMOUNT veya PRINCIPAL_AMOUNT gibi alanlar. Örnekler 1500.00250000.5050.001000000.00 | |||
| Olay Kullanıcısı EventUser | Aktiviteden sorumlu kullanıcı kimliği veya sistem aracısı. | ||
| Açıklama Eylemi kimin gerçekleştirdiğini yakalar; ister bir insan kullanıcı (örn. onaylar için) ister bir sistem hesabı (örn. otomatik mutabakat için) olsun. Bu öznitelik, belirli kullanıcıların veya kuyrukların aşırı yüklenip yüklenmediğini belirlemek için 'Darboğaz Analizi' için hayati öneme sahiptir. Neden önemli Kaynak analizini ve görev ayrılığı denetimini sağlar. Nereden alınır İşlem tablolarındaki denetim kayıtları veya 'UpdatedBy' sütunları. Örnekler SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Son Ödeme Tarihi PaymentDueDate | Ödemenin zamanında kabul edilmesi için mutabakatın yapılması gereken tarih. | ||
| Açıklama Sözleşmeli veya talep edilen yürütme tarihini saklar. Bu tarih, 'Zamanında Ödeme Oranı' KPI'ını hesaplamak ve 'Ödeme Vade Tarihi Neden önemli SLA Nereden alınır İşlem talimatları, genellikle VALUE_DATE, EXECUTION_DATE veya DUE_DATE. Örnekler 2023-11-012023-11-05 | |||
| Uçtan Uca Döngü Süresi EndToEndCycleTime | Talep oluşturmadan mutabakata kadar olan toplam süre. | ||
| Açıklama 'Ödeme Talebi Oluşturuldu' ve 'Ödeme Yapıldı' arasındaki zaman farkını hesaplar. Bu, 'Ortalama Ödeme İşlem Döngüsü Süresi' KPI'sı ve genel verimlilik analizi için birincil metrik olarak hizmet eder. Neden önemli Süreç hızı için en üst düzey metrik. Nereden alınır Hesaplandı: Zaman Damgası(Ödeme Yapıldı) - Zaman Damgası(Ödeme Talebi Oluşturuldu). Örnekler 2 gün 4 saat45 minutes12 saniye | |||
| Yeniden İşleme mi? IsRework | Ödemenin tekrarlayan faaliyetlere maruz kalıp kalmadığını gösteren bayrak. | ||
| Açıklama Veri işleme sırasında hesaplanan bir boolean bayrağıdır. 'Ödeme Detayları Doğrulandı' gibi etkinlikler birden fazla kez gerçekleşirse veya bir hata döngüsü tespit edilirse true olarak ayarlanır. Bu, 'Ödeme Yeniden İşleme Oranı' KPI'sını besler. Neden önemli Karmaşık süreç sorgularına gerek kalmadan verimsiz Nereden alınır Veri pipeline'ında her durum için yinelenen etkinlikleri kontrol ederek hesaplanır. Örnekler truefalse | |||
| Kaynak Sistem SourceSystem | `event` `data`'sının kaynaklandığı sistemin adı. | ||
| Açıklama ACI Worldwide ekosistemi içindeki belirli uygulamayı veya modülü (örn. ACI MTS, ACI UPF) veya akışa dahil olan harici sistemleri tanımlar. Bu, özellikle birden fazla muhasebe defterinde verileri birleştirirken veya ödeme harici takas evlerine dokunduğunda önemlidir. Neden önemli
Nereden alınır Çıkarma sırasında sabit kodlanmış veya birden fazla örnek varsa bir SystemID sütunundan türetilmiştir. Örnekler ACI MTSACI UPPSAP GLSwift Ağ Geçidi | |||
| Lehtar Adı BeneficiaryName | Ödemeyi alan varlığın adı. | ||
| Açıklama İşlemdeki karşı tarafı tanımlar. Bu alanı analiz etmek, yüksek yeniden işleme oranları veya gecikmelerle ilişkili belirli tedarikçileri veya müşterileri belirlemeye yardımcı olabilir ve 'Ödeme Başarısızlık ve Yeniden İşleme Analizi'ni destekler. Neden önemli Ödemenin hedefini belirler, müşteri odaklı analizler için faydalıdır. Nereden alınır Ödeme detay satırları; CREDITOR_NAME, BENE_NAME veya PAYEE gibi alanlar. Örnekler Acme CorpGlobal Supplies LtdCan Demir | |||
| Menşe Bölgesi OriginatingRegion | Ödeme talebinin kaynaklandığı coğrafi bölge. | ||
| Açıklama Talep sahibinin fiziksel veya mantıksal konumunu belirtir. Bu, 'Ödeme Süreci Varyant Analizi'nde belirli bölgelerin standart dışı yolları izleyip izlemediğini veya daha yüksek reddetme oranları yaşayıp yaşamadığını görmek için faydalıdır. Neden önemli Süreç performansına coğrafi bağlam sağlar. Nereden alınır İşlem başlığı, genellikle Şube Kodu veya Ülke Kodu'ndan türetilir. Örnekler Kuzey AmerikaEMEAAPAC | |||
| Mutabakat Kimliği ReconciliationId | Ödemeyi genel muhasebe veya mutabakat kaydına bağlayan tanımlayıcıdır. | ||
| Açıklama Bu kimlik, 'Ödeme Uzlaştırıldı' aktivitesi gerçekleştiğinde doldurulur. İşleme motorundaki ödemenin muhasebe sistemindeki Neden önemli 'Ödeme Mutabakat Verimliliği' dashboard'u için kritiktir. Nereden alınır Mutabakat tabloları veya RECON_REF veya GL_REF gibi belirli alanlar. Örnekler REC-9921GL-Entry-2023-11 | |||
| Ödeme Gecikti mi IsPaymentLate | Ödemenin vadesinden sonra yapılıp yapılmadığını gösteren bayrak. | ||
| Açıklama Gerçek mutabakat tarihini Neden önemli
Nereden alınır Hesaplandı: MutabakatTarihi > ÖdemeVadeTarihi. Örnekler truefalse | |||
| Onay Çevrim Süresi ApprovalCycleTime | Onay aşamasında geçirilen süre. | ||
| Açıklama 'Ödeme Onaya Gönderildi' ve 'Ödeme Onaylandı' (veya Reddedildi) arasındaki süreyi hesaplar. Bu özel metrik, 'Ödeme Onay Döngüsü Süresi Analizi' dashboard'unu besleyerek insan karar alma adımlarındaki gecikmeleri vurgular. Neden önemli Sürecin insan bağımlı kısmını izole eder. Nereden alınır Hesaplandı: Zaman Damgası(Ödeme Onaylandı) - Zaman Damgası(Ödeme Onaya Gönderildi). Örnekler 4 saat15 dakika | |||
| Son Veri Güncellemesi LastDataUpdate | Kaydın `data model`'de en son çıkarıldığı veya güncellendiği `timestamp`. | ||
| Açıklama Analizde kullanılan Neden önemli Veri güncelliğini sağlar ve dashboard'lardaki eski verileri belirlemeye yardımcı olur. Nereden alınır ETL Örnekler 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Ödeme İşlemleri Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fon Aktarıldı | Fonların ödeyen hesaptan başarılı bir şekilde çekildiğine dair ödeme ağından onay alındığını gösterir. Bu genellikle ağdan gelen bir gelen durum mesajından yakalanır. | ||
| Neden önemli Ödemenin harici ağ tarafından başarılı bir şekilde yürütüldüğünü onaylar. Mutabakat döneminin başlangıcını işaret eder ve 'Ortalama Ödeme Mutabakat Süresi' KPI'sı için önemli bir girdidir. Nereden alınır Bu, ödeme kaydını güncelleyen gelen bir Yakala Takas ağından harici bir onay mesajının alınması üzerine log'lanır. Event tipi explicit | |||
| Ödeme Hatası Tespit Edildi | Sistemin ödemeyle ilgili bir aşamada, örneğin geçersiz veri veya bir uyumluluk uyarısı gibi bir sorun tespit ettiğini gösterir. Bu olay, genellikle ilişkili bir hata koduyla açıkça log'lanır. | ||
| Neden önemli Bu aktivite, tüm yeniden işleme ve Nereden alınır Bir hata log tablosunda açık girdiler veya işlem tablosunda 'Hata' veya 'Düzeltme Gerekiyor' durum değişikliği arayın. Bu olaylar Ödeme İşlem Kimliği ile bağlantılı olmalıdır. Yakala Sistemin doğrulama veya işleme motoru bir hata bayrağı kaldırdığında açık bir olay kaydedilir. Event tipi explicit | |||
| Ödeme Onaylandı | Yetkili bir kullanıcının ödemeyi onaylayarak yürütmeye devam etmesini sağlayan önemli bir dönüm noktasıdır. Bu, genellikle onaylayanın sistemin kullanıcı arayüzünde bir eylem gerçekleştirmesiyle açık bir olay olarak kaydedilir. | ||
| Neden önemli Bu aktivite önemli bir kontrol noktası ve genellikle önemli bir Nereden alınır Bir onay log tablosunda açık bir olay veya ana işlem tablosunda belirli bir kullanıcı eylemi ve zaman damgasıyla bağlantılı 'Onaylandı' durum değişikliği arayın. Yakala Yetkili bir kullanıcı sistemde onay eylemini tamamladığında log'lanır. Event tipi explicit | |||
| Ödeme Sonuçlandı | Ödeme sürecinin tamamlandığına ve fonların alıcıya yatırıldığına dair son onaydır, işlemi sonuçlandırır. Bu, ödeme yaşam döngüsünün başarılı bir şekilde sona erdiğini temsil eden kritik bir `event`'tir. | ||
| Neden önemli Bu, süreç için birincil başarılı bitiş Nereden alınır Genellikle ağdan nihai bir mutabakat onay mesajı alındığında veya dahili defter işlemin tamamlanmasını yansıtacak şekilde güncellendiğinde kaydedilen açık bir Yakala Nihai bir mutabakat dosyası veya mesajının alınması üzerine log'lanır ve durumu 'Yapıldı' olarak günceller. Event tipi explicit | |||
| Ödeme Talebi Oluşturuldu | Bu aktivite, ACI Worldwide sistemi içinde yeni bir ödeme işleminin başlatıldığını işaret eder. Genellikle bir kullanıcının veya bir üst sistemin bir ödeme talebi gönderdiğinde kaydedilen açık bir `event`'tir ve benzersiz bir kimliğe sahip yeni bir işlem kaydı oluşturur. | ||
| Neden önemli Bu, ödeme süreci için birincil başlangıç Nereden alınır Bu, muhtemelen çekirdek işlem tablosunda veya ACI'daki özel bir Yakala İşlem log'undaki oluşturma kaydı veya açık bir 'Oluştur' olayı ile tanımlanır. Event tipi explicit | |||
| Ödeme Yetkilendirildi | İnsan onayından sonra ödemenin sistem düzeyinde yetkilendirilmesini temsil eder; fonları doğrular veya sahtekarlık kurallarına karşı kontrol eder. Bu, açık bir log girişi olabilir veya yürütme için hazır olduğunu gösteren bir durum değişikliğinden çıkarılabilir. | ||
| Neden önemli Bu, fonların hareket etmesi talimatı verilmeden önceki kritik bir kontrol noktasıdır. Bu aşamadaki gecikmeler, sistem performans sorunlarını veya Nereden alınır Bir sistem işleme veya güvenlik log'unda açık bir log kaydı arayın. Alternatif olarak, 'Onaylandı' durumundan 'Ödeme için Yetkilendirildi' durumuna yapılan bir güncellemeden çıkarılabilir. Yakala Sistemin ödeme motoru tarafından nihai dahili kontrollerden geçtikten sonra log'lanır. Event tipi explicit | |||
| Ödeme Başarısız Oldu | Ödemenin kurtarılamaz bir sorun nedeniyle tamamlanamadığını gösteren nihai bir durumdur. Bu, çözülebilir bir hatadan farklıdır ve kesin bir başarısızlık son durumunu temsil eder. | ||
| Neden önemli Bu bitiş Nereden alınır İşlem verilerindeki 'Başarısız Oldu', 'İptal Edildi' veya 'Banka Tarafından Reddedildi' gibi nihai, terminal bir durumdan çıkarılmıştır ve bu durum daha sonra değişmez. Yakala Ödeme kaydındaki nihai bir başarısızlık durumundan çıkarılmıştır. Event tipi inferred | |||
| Ödeme Detayları Doğrulandı | Otomatik veya manuel kontrollerin tamamlandığını temsil eder; bu kontroller, alıcı bilgileri ve banka kodları gibi ödeme detaylarının doğru olduğundan emin olmak için yapılır. Bu aktivite genellikle işlemin durumunun 'Yeni'den 'Doğrulandı'ya veya 'Onay Bekliyor'a değişmesinden çıkarılır. | ||
| Neden önemli İlk Nereden alınır Ana ödeme işlem tablosundaki durum değişikliği alanlarından çıkarılmıştır. 'Oluşturuldu' durumu ile sonraki 'Doğrulandı' veya benzeri bir durum arasındaki zaman damgalarını karşılaştırın. Yakala Ödeme durum alanındaki bir değişiklikten, örneğin 'Girildi'den 'Doğrulandı'ya geçişten çıkarılmıştır. Event tipi inferred | |||
| Ödeme Hatası Çözüldü | Daha önce tespit edilen bir hatanın bir kullanıcı tarafından düzeltildiği ve ödemenin işleme için yeniden gönderildiği noktayı işaretler. Bu, genellikle bir ödemenin durumunun bir hata durumundan normal bir işleme durumuna geri döndüğünde çıkarılır. | ||
| Neden önemli Bu aktivite istisna döngüsünü kapatır. 'Ödeme Hatası Tespit Edildi' ile bu Nereden alınır Bir 'Hata' durumundan 'Onay Bekliyor' veya 'Doğrulandı' gibi bir işleme durumuna geçişten çıkarılmıştır. Ayrıca açık bir kullanıcı eylem log'u da olabilir. Yakala Bir hata durumundan çıkan bir durum değişikliğinden çıkarılmıştır, bu da bir düzeltmenin yapıldığını gösterir. Event tipi inferred | |||
| Ödeme Mutabakatı Yapıldı | ACI'da kaydedilen ödeme işleminin banka ekstreleri veya defter kayıtları ile eşleştirildiği son muhasebe adımını temsil eder. Bu, bir mutabakat modülünden gelen açık bir `event` olabilir veya bir durum değişikliği ile çıkarılabilir. | ||
| Neden önemli Bu aktivite, arka ofis mutabakat sürecinin verimliliğini ölçer. Buradaki gecikmeler, finansal raporlamanın doğruluğunu etkileyebilir ve ödenmemiş ödeme sorunlarını gizleyebilir. Nereden alınır Bu bilgi, ACI içindeki özel bir mutabakat modülünden veya harici bir ERP sisteminden gelebilir. Ödeme kaydında 'Mutabakatı Yapıldı'ya yapılan bir Yakala Nihai bir 'Mutabakat Edildi' durum güncellemesinden veya Ödeme Kimliği ile birleştirilen mutabakat verilerinden çıkarılmıştır. Event tipi inferred | |||
| Ödeme Onaylandı | Ödemenin başarıyla işlendiğine ve bir onayın alındığına dair dahili onayı temsil eder. Bu genellikle alıcıyı veya diğer dahili sistemleri bilgilendirmek için bir tetikleme noktası görevi görür. | ||
| Neden önemli Bu kilometre taşı, Nereden alınır Bu, genellikle harici ağ onayı alındıktan sonra ödeme işlem tablosundaki bir Yakala Durum değişikliğinden 'Onaylandı' veya 'İşlendi' olarak çıkarılmıştır. Event tipi inferred | |||
| Ödeme Reddedildi | Bir onaylayıcı ödeme talebini reddettiğinde meydana gelir, genellikle düzeltme ve yeniden gönderme gerektirir. Bu, ödemenin ilerlemesini durduran ve bir yeniden işleme döngüsü başlatan açık bir olaydır. | ||
| Neden önemli Yeniden işleme ve süreç verimsizliklerini belirler. Reddetme sıklığını takip etmek, ilk veri kalitesi veya gönderim politikalarıyla ilgili sorunları teşhis etmeye yardımcı olur ve yeniden işleme analizini destekler. Nereden alınır Onay log'unda açık bir olay olarak veya işlem tablosunda 'Reddedildi' durum değişikliği olarak yakalanır. Olay, ret için bir neden kodu içerebilir. Yakala Bir onaylayıcı sistemde reddetme eylemini tamamladığında log'lanır. Event tipi explicit | |||
| Ödeme Talimatı Gönderildi | Ödeme talimatının derlenip SWIFT, ACH veya SEPA gibi harici bir ödeme ağına iletildiği noktayı işaretler. ACI sistemleri, denetim ve takip amaçları için bu teslimi açıkça log'lar. | ||
| Neden önemli Bu, birçok ödeme türü için 'geri dönüşü olmayan nokta'dır. Bunu takip etmek, dış bağımlılıklar devralmadan önceki dahili işleme süresini ölçmeye yardımcı olur. Nereden alınır Bu, neredeyse her zaman ACI'nın işlem veya mesajlaşma loglarında kaydedilen açık bir Yakala Ödeme mesajı harici ağa gönderildiğinde açık bir log kaydı oluşturulur. Event tipi explicit | |||
| Onay İçin Ödeme Gönderildi | Ödemenin ilk doğrulamayı geçtiğini ve gerekli yönetsel veya finansal onay için yönlendirildiğini gösterir. Bu, tipik olarak ödeme workflow'u içindeki bir durum değişikliği ile yakalanır. | ||
| Neden önemli Bu, onay alt sürecinin başlangıcını işaret eder. Bu noktadan 'Ödeme Onaylandı'ya kadar geçen süreyi ölçmek, 'Ödeme Onay Döngüsü Süresi Analizi' Nereden alınır İşlem verilerindeki ödeme durumu alanındaki bir değişiklikten, örneğin 'Onay Bekliyor' durumuna geçişten türetilmiştir. Yakala 'Onay Bekliyor' veya benzeri bir durum değişikliğinden ve buna karşılık gelen bir zaman damgasından çıkarılmıştır. Event tipi inferred | |||
Veri Çekim Kılavuzları
Adımlar
Veritabanı Ortamına Erişim: SQL Server Management Studio (SSMS) veya uyumlu bir istemci kullanarak ACI Postilion Realtime veritabanını barındıran SQL Server örneğine giriş yapın.
Temel Tabloları Belirleyin:
post_tran(işlem günlüğü) vepost_tran_cust(özel veri uzantısı) tablolarını bulun. Bu nesneler üzerindeSELECTizinlerinizin olduğundan emin olun.Durum Tanımlayıcısını Belirleyin: Bu çıkarma,
retrieval_reference_nrdeğeriniPaymentTransactionIdolarak kullanır. Uygulamanız farklı bir benzersiz anahtar (örneğin,system_trace_audit_nriletransmission_date_timebirleşimi gibi) kullanıyorsa, sorgu seçimini buna göre ayarlayın.Filtre Parametrelerini Yapılandırın: Aşağıda sağlanan sorguyu açın. Betiğin üst kısmında
@StartDateve@EndDatedeğişkenlerini bulun. Performansı optimize etmek için bunları istediğiniz çıkarma penceresine (örneğin, son 30 ila 90 gün) ayarlayın.Etkinlik Mantığını İnceleyin: Sorgu, ISO 8583 mesaj türlerini (örneğin, 0200, 0210) ve yanıt kodlarını gerekli 14 süreç madenciliği etkinliğine eşler. Belirli ACI arayüz yapılandırmalarınızla uyumlu olduklarından emin olmak için
CASEifadelerini gözden geçirin.Sorguyu Çalıştırın: Tüm betiği yürütün. Sorgu, farklı işlem durumlarını tek bir olay günlüğü biçimine normalleştirmek için
UNION ALLkullanır.Veri Çıkışını Doğrulayın: Gerekli sütunlar için sonuçları kontrol edin:
PaymentTransactionId,ActivityNameveEventTimestamp. Hiçbir kritik alanın beklenmedik şekildeNULLdeğerler içermediğinden emin olun.Veriyi Dışa Aktarın: SSMS'deki sonuçlar tablosuna sağ tıklayın ve çıktıyı bir CSV dosyası olarak kaydedin (örneğin,
ACI_Payments_EventLog.csv).ProcessMind için Biçimlendirme: CSV dosyasını açın ve
EventTimestamp'ın standart bir biçimde (YYYY-MM-DD HH:MM:SS) olduğunu vePaymentAmount'ın yalnızca sayısal değerler içerdiğini doğrulayın.Yükleme: Doğrulanmış CSV dosyasını ProcessMind'e yükleyin, sütunları sırasıyla Case ID, Activity ve Timestamp olarak eşleştirin.
Konfigürasyon
- Tarih Aralığı: ACI
post_trantabloları çok hızlı büyür. Çekimi 3 aylık kayan bir pencereyle sınırlamanız veya mümkünse bölüm geçişi kullanmanız şiddetle tavsiye edilir. - Yanıt Kodları: Sorgu,
rsp_code = '00'değerinin başarılı olduğunu varsayar. Kuruluşunuz onay/başarı için farklı kodlar kullanıyorsa (örn. '08' veya '10'), filtreleri güncelleyin. - Mesaj Türleri (ISO 8583): Betik, standart mesaj türlerine (İstekler için 0100/0200, Yanıtlar için 0210) dayanır.
source_node_nameyapılandırmanızda tanımlanan özel mesaj türleri ayarlamalar gerektirebilir. - Sistem Performansı: Bu sorgu, canlı işlem sürecini engellemeyi önlemek için
NOLOCKipuçları kullanır. Üretim ortamında bu ipuçlarını kaldırmayın. - Para Birimleri: Tutarlar ham rakamlar olarak çekilir. Analiz sırasında çoklu para birimi normalleştirmesi gerekiyorsa
tran_currency_codekullanıldığından emin olun.
a Örnek Sorgu 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;