Ödeme işlemleri veri şablonunuz
Ödeme işlemleri veri şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- ACI Worldwide için veri çıkarma rehberi
Ödeme işlemleri öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Ödeme sürecinde gerçekleşen belirli adım veya durum değişikliği. | ||
| Açıklama Bu öznitelik, Ödeme isteği oluşturuldu veya Para aktarıldı gibi süreç haritasındaki olay düğümünü tanımlar. ACI sistemlerinde genellikle durum kodlarından, denetim günlüğü işlem türlerinden veya iş akışı durum değişikliklerinden elde edilir. Anlamlı görselleştirme için bu teknik durumları anlaşılır iş etkinlikleriyle doğru biçimde eşleştirmek önemlidir. Neden önemli? Süreç akışını tanımlar ve işlem sırasını görselleştirmek için gereklidir. Nereden alınır? Durum kodlarından (ör. 100=Oluşturuldu, 200=Doğrulandı) veya denetim günlüğündeki işlem sütunlarından elde edilir. Örnekler Ödeme talebi oluşturulduÖdeme yetkilendirildiÖdeme tamamlandıÖdeme başarısız | |||
| Ödeme İşlemi Kimliği PaymentTransactionId | ACI sistemindeki belirli ödeme talimatını tanımlayan benzersiz kimlik. | ||
| Açıklama Bu öznitelik, tek bir ödeme isteğiyle ilgili tüm olayları birbirine bağlayan ve Process Mining analizinin temelini oluşturan anahtardır. ACI Worldwide sistemlerinde (MTS veya UPP gibi), işlem sisteme girildiğinde atanan benzersiz referans numarasına karşılık gelir. İlk istekten doğrulama ve onaya, son mutabakata kadar ödeme yolculuğunun uçtan uca yeniden oluşturulmasını sağlar. Neden önemli? Ayrı olayları süreç örnekleri halinde gruplandırmak için gereken temel Vaka kimliğidir. Nereden alınır? İşlem başlığı tablolarında genellikle TRN_REF, REFERENCE_NUM veya UUID olarak adlandırılan alanları kontrol edin. Örnekler TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Olay zaman damgası EventTimestamp | Etkinliğin gerçekleştiği tarih ve saat. | ||
| Açıklama Bu öznitelik, ACI ortamında bir olayın gerçekleştiği tam zamanı kaydeder. Çevrim süreleri, onay süreleri ve işlem hacmi oranları dahil zamana dayalı tüm metrikleri hesaplamak için kullanılır. Hızlı otomatik adımları doğru sıralamak için milisaniye düzeyinde hassasiyet tercih edilir. 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 ya da 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 | |||
| Departman Department | Mevcut etkinlikten sorumlu kurum içi departman. | ||
| Açıklama EventUser veya kuyruğu Ödeme operasyonları, Uyumluluk ya da Hazine gibi daha geniş bir kurumsal birimle eşleştirir. Etkinliğe göre Darboğaz analizinde, süreci hangi ekiplerin yavaşlattığını görmeye yardımcı olur. Neden önemli? Performansı işlevlere göre toplulaştırır. Nereden alınır? Kullanıcı tablolarından veya kurumsal hiyerarşi eşlemesinden elde edilir. Örnekler OperasyonlarComplianceHazineBT desteği | |||
| Hata kodu ErrorCode | Ödeme başarısız olduğunda veya onarım gerektiğinde oluşturulan kod. | ||
| Açıklama Ödeme başarısız veya Ödeme hatası tespit edildi olaylarının belirli nedenini kaydeder. Ödeme başarısızlığı ve yeniden çalışma analizi Dashboardunda bu özniteliğe göre gruplama yaparak en yaygın temel başarısızlık nedenlerini (ör. Yetersiz bakiye, Geçersiz hesap) belirleyebilirsiniz. Neden önemli? Süreç başarısızlıklarının temel nedenlerini analiz etmek için gereklidir. Nereden alınır? Hata günlüklerinde veya durum nedeni sütunlarında, genellikle REASON_CODE ya da RETURN_CODE alanlarında bulunur. Örnekler R01AM04BE05TECH_ERR_001 | |||
| İşlem kanalı ProcessingChannel | Ödemenin başlatıldığı kanal. | ||
| Açıklama Ödemenin Mobil, Web Portalı, API veya Dosya Yükleme gibi hangi kanaldan başlatıldığını gösterir. Ödeme süreci varyant analizinde, bazı kanallarda hata veya gecikme olasılığının daha yüksek olup olmadığını görmeye yardımcı olur. Neden önemli? Performansı veri giriş yöntemine göre gruplandırır. Nereden alınır? İşlem başlığında, genellikle CHANNEL, SOURCE_TYPE veya INPUT_METHOD adlı sütunlarda bulunur. Örnekler SWIFTİnternet bankacılığıMobil uygulamaDosya yükleme | |||
| Ödeme para birimi PaymentCurrency | Ödeme tutarının ISO para birimi kodu. | ||
| Açıklama PaymentAmount değerinin hangi para biriminde olduğunu belirtir (ör. USD, EUR, GBP). Farklı bölgelerdeki hacimleri bir araya getiren Dashboardlarda verileri ortak bir ölçekte değerlendirmek için gereklidir. Sınır ötesi ödemelerin karmaşıklığını anlamaya yardımcı olur. Neden önemli? Ödeme tutarını doğru yorumlamak için gereklidir. Nereden alınır? İşlem ayrıntı tablolarında genellikle CCY, CURRENCY_CODE veya ISO_CODE gibi alanlarda bulunur. Örnekler USDEURGBPJPY | |||
| Ödeme türü PaymentType | Ödeme aracının sınıflandırması. | ||
| Açıklama Ödemeyi (ör. havale, ACH, SEPA, RTGS) kategorilere ayırır. Farklı ödeme türlerinin hizmet düzeyi taahhütleri ve süreç akışları büyük ölçüde değişebilir. Uçtan uca ödeme çevrim süresi Dashboardunda filtreleme için temel boyutlardan biridir. Neden önemli? Hızlı ve toplu ödeme akışlarını birbirinden ayırmak için önemlidir. Nereden alınır? İşlem başlığında, PMT_TYPE, INSTRUMENT_TYPE veya SERVICE_ID gibi alanlarda bulunur. Örnekler Yurt içi havaleUluslararası havaleACH alacak transferiAnlık ödeme | |||
| Ödeme tutarı PaymentAmount | Ödeme işleminin parasal değeri. | ||
| Açıklama Aktarılan tutarı gösterir. Ödeme işlem hacmini analiz etmek ve darboğazlara öncelik vermek için önemli bir bağlam bilgisidir. Yüksek tutarlı ödemeler, düşük tutarlı otomatik akışlara kıyasla genellikle daha ayrıntılı onay adımlarından geçer (varyant analizi). Neden önemli? Değere göre segmentasyon yapılmasını ve işlenen toplam hacmin hesaplanmasını sağlar. Nereden alınır? İşlem ayrıntı tablolarında genellikle AMT, TRANS_AMOUNT veya PRINCIPAL_AMOUNT gibi alanlarda bulunur. Örnekler 1500.00250000.5050.001000000.00 | |||
| Ödeme vadesi PaymentDueDate | Ödemenin zamanında yapılmış sayılması için sonuçlandırılması gereken tarih. | ||
| Açıklama Sözleşmede belirtilen veya talep edilen işlem tarihini kaydeder. Zamanında ödeme oranı KPI’ını hesaplamak ve Ödeme vadesi uyumluluğu Dashboardunu desteklemek için bu tarih, gerçek mutabakat tarihiyle karşılaştırılır. Neden önemli? Hizmet düzeyi taahhütlerine uyumu ve zamanında ödeme performansını ölçmek için referans alınır. Nereden alınır? İşlem talimatlarında genellikle VALUE_DATE, EXECUTION_DATE veya DUE_DATE alanlarında bulunur. Örnekler 2023-11-012023-11-05 | |||
| Olay kullanıcısı EventUser | Etkinlikten sorumlu kullanıcı kimliği veya sistem aracısı. | ||
| Açıklama İşlemi kimin yaptığını kaydeder: onay veren bir kullanıcıyı veya otomatik mutabakat yapan bir sistem hesabını gösterebilir. Belirli kullanıcıların ya da kuyrukların aşırı yüklenip yüklenmediğini belirlemek için Darboğaz analizi açısından önemlidir. Neden önemli? Kaynak analizini ve görevler ayrılığı denetimini mümkün kılar. Nereden alınır? Denetim günlüklerinde veya işlem tablolarındaki UpdatedBy sütunlarında bulunur. Örnekler SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Yeniden çalışma var mı IsRework | Ödemenin tekrarlanan etkinliklerden geçip geçmediğini belirten işaret. | ||
| Açıklama Veri işleme sırasında hesaplanan bir doğru/yanlış işaretidir. Ödeme ayrıntıları doğrulandı gibi etkinlikler birden fazla kez gerçekleştiğinde veya bir hata döngüsü tespit edildiğinde true olarak ayarlanır. Ödeme yeniden çalışma oranı KPI’ı bu işareti kullanır. Neden önemli? Karmaşık süreç sorguları oluşturmadan verimsiz vakaları hızla belirler. Nereden alınır? Her vaka için yinelenen etkinlikler kontrol edilerek veri hattında hesaplanır. Örnekler truefalse | |||
| İşlemin başlatıldığı bölge OriginatingRegion | Ödeme isteğinin başlatıldığı coğrafi bölge. | ||
| Açıklama İsteği gönderen kişinin fiziksel veya mantıksal konumunu belirtir. Ödeme süreci varyant analizinde, belirli bölgelerin standart dışı yollar izleyip izlemediğini veya daha yüksek ret oranlarıyla karşılaşıp karşılaşmadığını görmeye yardımcı olur. Neden önemli? Süreç performansına coğrafi bağlam kazandırır. Nereden alınır? İşlem başlığında, genellikle Şube Kodu veya Ülke Kodundan elde edilir. Örnekler Kuzey AmerikaAvrupa, Orta Doğu ve AfrikaAsya Pasifik | |||
| Kaynak sistem SourceSystem | Olay verilerinin geldiği sistemin adı. | ||
| Açıklama ACI Worldwide ekosistemindeki belirli uygulama veya modülü (ör. ACI MTS, ACI UPF) ya da akışta yer alan harici sistemleri belirtir. Birden fazla defterden veri birleştirirken veya ödeme harici takas kurumlarından geçerken özellikle önem taşır. Neden önemli? Verinin nereden çıkarıldığına ilişkin bağlam sunar ve veri kökenindeki sorunları ayıklamaya yardımcı olur. Nereden alınır? Veri çıkarımı sırasında sabit olarak atanır veya birden fazla örnek varsa SystemID sütunundan elde edilir. Örnekler ACI MTSACI UPPSAP GLSwift Gateway | |||
| Lehtar adı BeneficiaryName | Ödemeyi alan kuruluşun adı. | ||
| Açıklama İşlemdeki karşı tarafı belirtir. Bu alanı incelemek, yüksek yeniden çalışma oranları veya gecikmelerle ilişkili belirli tedarikçileri ya da müşterileri belirlemeye ve Ödeme başarısızlığı ve yeniden çalışma analizine katkı sağlamaya yardımcı olabilir. Neden önemli? Ödemenin alıcısını belirtir ve müşteri odaklı analizlerde kullanılabilir. Nereden alınır? Ödeme ayrıntı satırlarında, CREDITOR_NAME, BENE_NAME veya PAYEE gibi alanlarda bulunur. Örnekler Acme CorpGlobal Supplies LtdJohn Smith | |||
| Mutabakat kimliği ReconciliationId | Ödemeyi genel muhasebe defterine veya mutabakat kaydına bağlayan kimlik. | ||
| Açıklama Ödeme mutabakatı yapıldı etkinliği gerçekleştiğinde bu kimlik doldurulur. İşleme motorundaki ödemenin muhasebe sistemindeki kayıtla eşleşmesini sağlar. Sonuçlandırılmış ödemelerde bu kimliğin bulunmaması, mutabakat sorunlarına işaret eder. Neden önemli? Ödeme mutabakatı verimliliği Dashboardu için önemlidir. Nereden alınır? Mutabakat tablolarında veya RECON_REF ya da GL_REF gibi belirli alanlarda bulunur. Örnekler REC-9921GL-Entry-2023-11 | |||
| Ödeme gecikti mi IsPaymentLate | Ödemenin vade tarihinden sonra sonuçlandırılıp sonuçlandırılmadığını belirten işaret. | ||
| Açıklama Gerçek mutabakat tarihini PaymentDueDate ile karşılaştıran doğru/yanlış işaretidir. Ödeme vadesi uyumluluğu Dashboard metriklerini hesaplamak ve hizmet düzeyi ihlallerini belirlemek için kullanılır. Neden önemli? Uyumluluk raporlamasını kolaylaştırır. Nereden alınır? Hesaplama: SettlementDate > PaymentDueDate. Örnekler truefalse | |||
| Onay çevrim süresi ApprovalCycleTime | Onay aşamasında geçen süre. | ||
| Açıklama Ödeme onaya gönderildi ile Ödeme onaylandı (veya reddedildi) arasındaki süreyi hesaplar. Bu metrik, insan kararlarına bağlı adımlardaki gecikmeleri gösteren Ödeme onay çevrim süresi analizi Dashboardunda kullanılır. Neden önemli? Sürecin insan müdahalesine bağlı bölümünü ayrı olarak gösterir. Nereden alınır? Hesaplama: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Örnekler 4 saat15 dakika | |||
| Son veri güncellemesi LastDataUpdate | Kaydın veri modeline en son çıkarıldığı veya güncellendiği zaman damgası. | ||
| Açıklama Analizde kullanılan verinin güncelliğini izler. Bu, süreç olayının gerçekleştiği zamanı değil, verinin sisteme alındığı teknik zamanı gösterir. Analistlerin gerçek zamanlı veriye mi yoksa geçmiş bir anlık görüntüye mi baktığını anlamasını sağlar. Neden önemli? Verinin güncelliğini takip etmeyi ve Dashboardlardaki eski verileri belirlemeyi sağlar. Nereden alınır? ETL betiğinin çalıştırıldığı andaki sistem saati. Örnekler 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Ödeme işlemleri etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fonlar aktarıldı | Ödeme ağından, fonların ödeyenin hesabından başarıyla çekildiğine dair onay alındığını gösterir. Bu bilgi genellikle ağdan gelen bir durum mesajıyla kaydedilir. | ||
| Neden önemli? Ödemenin harici ağ tarafından başarıyla gerçekleştirildiğini doğrular. Ödeme tamamlama döneminin başlangıcını gösterir ve 'Ortalama Ödeme Tamamlama Süresi' KPI’ı için temel verilerden biridir. Nereden alınır? Ödeme kaydını güncelleyen gelen bir durum mesajıyla tetiklenen açık bir olaydır. Örneğin SWIFT’ten gelen MT103 mesajı veya ACH onayı bu olayı tetikleyebilir. Kaydedin Takas ağından harici onay mesajı alındığında kaydedilir. Olay türü explicit | |||
| Ödeme hatası tespit edildi | Sistemin, geçersiz veri veya uyumluluk uyarısı gibi bir nedenle ödemenin herhangi bir aşamasında sorun tespit ettiğini gösterir. Bu olay genellikle ilgili hata koduyla birlikte açıkça kaydedilir. | ||
| Neden önemli? Bu etkinlik, yeniden çalışma ve istisna yönetimi analizlerinin başlangıç noktasıdır. Ödeme başarısızlığı ve yeniden çalışma analizi ile Hata çözümleme çevrim süresi Dashboardları için gereklidir. Nereden alınır? Hata günlüğü tablosundaki açık kayıtları veya işlem tablosunda durumun Hata ya da Düzeltme gerekiyor olarak değiştiğini gösteren kayıtları bulun. Bu olaylar Ödeme İşlemi Kimliğiyle ilişkilendirilmelidir. Kaydedin Sistemin doğrulama veya işleme motoru bir hata belirlediğinde açık bir olay kaydedilir. Olay türü explicit | |||
| Ödeme onaylandı | Yetkili bir kullanıcının ödemeyi onaylayarak işlemin yürütülmesine izin verdiği önemli bir aşamadır. Onaylayan kişi sistem arayüzünde işlem yaptığında bu durum genellikle açık bir olay olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik önemli bir kontrol noktasıdır ve çoğu zaman ciddi bir darboğaz oluşturur. Bu adımdan önceki bekleme sürelerini ve onay çevrim süresini analiz etmek, ödemeleri hızlandırma fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Onay günlüğü tablosunda açık bir olay veya ana işlem tablosunda belirli bir kullanıcı işlemi ve zaman damgasıyla ilişkili 'Onaylandı' durum değişikliği arayın. Kaydedin Yetkili bir kullanıcı sistemde onay işlemini tamamladığında kaydedilir. Olay türü explicit | |||
| Ödeme talebi oluşturuldu | Bu etkinlik, ACI Worldwide sisteminde yeni bir ödeme işleminin başlatıldığını gösterir. Genellikle bir kullanıcı veya önceki bir sistem ödeme talebi gönderdiğinde kaydedilen açık bir olaydır. Bu işlem, benzersiz bir kimliğe sahip yeni bir kayıt oluşturur. | ||
| Neden önemli? Bu, ödeme sürecinin temel başlangıç olayıdır. Bu etkinlikten tamamlanmaya kadar geçen süreyi analiz etmek, genel süreç verimliliğini ölçmek için gerekli olan baştan sona çevrim süresini verir. Nereden alınır? Bu, büyük olasılıkla ana işlem tablosuna veya ACI’deki özel bir Event Loga açıkça kaydedilen bir olaydır. Ödeme İşlem Kimliğiyle ilişkili oluşturulma zaman damgasını bulun. Kaydedin Oluşturma kaydından veya işlem günlüğündeki açık bir 'Oluştur' olayından belirlenir. Olay türü explicit | |||
| Ödeme tamamlandı | Ödeme sürecinin tamamlandığını ve fonların alacaklının hesabına geçtiğini doğrulayan son aşamadır. İşlemi sonuçlandıran bu önemli olay, ödeme yaşam döngüsünün başarıyla tamamlandığını gösterir. | ||
| Neden önemli? Bu, sürecin temel başarı bitiş olayıdır. Genel çevrim süresini ve işlem hacmini hesaplamak için kullanılır ve baştan sona performansı gösteren Dashboardların neredeyse tamamı için gereklidir. Nereden alınır? Genellikle ağdan son ödeme onayı mesajı alındığında veya işlemin tamamlandığını göstermek için kurum içi defter güncellendiğinde açık bir olay olarak kaydedilir. Kaydedin Nihai mutabakat dosyası veya mesajı alındığında kaydedilir ve durum Güncellendi olarak değiştirilir. Olay türü explicit | |||
| Ödeme yetkilendirildi | İnsan onayından sonra sistemin ödemeye yetki vermesini ifade eder. Bu aşamada kullanılabilir fonlar doğrulanır veya dolandırıcılık kuralları kontrol edilir. Durum, açık bir günlük kaydıyla gösterilebilir ya da işlemin yürütülmeye hazır olduğunu belirten bir durum değişikliğinden çıkarılabilir. | ||
| Neden önemli? Fonların aktarılması talimatı verilmeden önceki önemli bir kontrol noktasıdır. Bu aşamadaki gecikmeler, sistem performansıyla veya uyumluluk ve dolandırıcılık kontrolü alt sistemleriyle ilgili sorunlara işaret edebilir. Nereden alınır? Sistem işleme veya güvenlik günlüğünde açık bir kayıt arayın. Alternatif olarak, durumun 'Onaylandı' aşamasından 'Ödeme için Yetkilendirildi' aşamasına geçmesinden çıkarılabilir. Kaydedin Son iç kontrolleri geçtikten sonra sistemin ödeme motoru tarafından kaydedilir. Olay türü explicit | |||
| Ödeme ayrıntıları doğrulandı | Alacaklı bilgileri ve banka kodları gibi ödeme ayrıntılarının doğruluğunu kontrol eden otomatik veya elle yapılan denetimlerin tamamlandığını gösterir. Bu etkinlik çoğu zaman işlem durumunun 'Yeni' durumundan 'Doğrulandı' veya 'Onay Bekliyor' durumuna geçmesinden çıkarılır. | ||
| Neden önemli? İlk veri doğrulama adımlarının verimliliğini izler. Bu aşamadaki gecikmeler önceki adımlarda darboğazlara yol açabilir ve sürecin ilerleyen aşamalarında ödeme hatası olasılığını artırabilir. Nereden alınır? Ana ödeme işlem tablosundaki durum değişikliği alanlarından çıkarılır. 'Oluşturuldu' durumu ile sonraki 'Doğrulandı' veya benzer bir durumun zaman damgalarını karşılaştırın. Kaydedin Ödeme durumu alanındaki değişiklikten, örneğin 'Girildi' durumundan 'Doğrulandı' durumuna geçişten çıkarılır. Olay türü inferred | |||
| Ödeme başarısız | Ödemenin çözülemeyen bir sorun nedeniyle tamamlanamadığını belirten son durumdur. Çözülebilir bir hatadan farklıdır ve sürecin kesin olarak başarısızlıkla sona erdiğini gösterir. | ||
| Neden önemli? Bu son olayı izlemek, genel ödeme başarısızlık oranını hesaplamak için önemlidir. Başarısızlık nedenlerini incelemek, veri kalitesini ve süreç kurallarını iyileştirmeye yardımcı olabilir. Nereden alınır? İşlem verilerinde yer alan ve sonrasında değişmeyen Başarısız, İptal Edildi veya Banka Tarafından Reddedildi gibi nihai bir durumdan çıkarılır. Kaydedin Ödeme kaydındaki nihai başarısızlık durumundan çıkarılır. Olay türü inferred | |||
| Ödeme hatası çözüldü | Daha önce tespit edilen bir hatanın kullanıcı tarafından düzeltildiği ve ödemenin yeniden işleme alındığı noktayı belirtir. Ödeme durumunun hata durumundan normal bir işleme durumuna dönmesiyle çıkarım yapılabilir. | ||
| Neden önemli? Bu etkinlik, istisna sürecini kapatır. Ödeme hatasının tespit edildiği an ile bu olay arasındaki süre, operasyonel verimliliğin önemli bir ölçütü olan hata çözümleme çevrim süresidir. Nereden alınır? Durumun Hata durumundan Onay bekliyor veya Doğrulandı gibi bir işleme durumuna geçmesinden çıkarılır. Kullanıcı işlemi günlüğünde açık bir kayıt olarak da yer alabilir. Kaydedin Bir düzeltme yapıldığını gösteren, hata durumundan çıkışa ilişkin durum değişikliğinden çıkarılır. Olay türü inferred | |||
| Ödeme mutabakatı yapıldı | ACI sisteminde kaydedilen ödeme işleminin banka ekstresi veya defter kayıtlarıyla eşleştirildiği son muhasebe adımını ifade eder. Bu, mutabakat modülünde açıkça kaydedilen bir olay olabilir veya durum değişikliğinden çıkarılabilir. | ||
| Neden önemli? Bu etkinlik, arka ofis mutabakat sürecinin verimliliğini ölçer. Buradaki gecikmeler finansal raporlamanın doğruluğunu etkileyebilir ve mutabakatı tamamlanmamış ödemelerin fark edilmesini zorlaştırabilir. Nereden alınır? Bu bilgi, ACI içindeki özel bir mutabakat modülünden veya harici bir ERP sisteminden gelebilir. Ödeme kaydındaki durumun Mutabakatı yapıldı olarak güncellenmesiyle yakalanabilir. Kaydedin Nihai Mutabakatı yapıldı durum güncellemesinden veya Ödeme Kimliğiyle birleştirilen mutabakat verilerinden çıkarılır. Olay türü inferred | |||
| Ödeme onaya gönderildi | Ödemenin ilk doğrulamadan geçtiğini ve gerekli yönetici veya finans onayına yönlendirildiğini gösterir. Bu durum genellikle ödeme iş akışındaki bir durum değişikliğiyle kaydedilir. | ||
| Neden önemli? Bu etkinlik, onay alt sürecinin başlangıcını gösterir. Bu noktadan 'Ödeme Onaylandı' adımına kadar geçen süreyi ölçmek, 'Ödeme Onay Çevrim Süresi Analizi' Dashboardu için önemlidir. Nereden alınır? İşlem verilerindeki ödeme durumu alanının, örneğin 'Onay Bekliyor' durumuna geçmesiyle belirlenir. Kaydedin 'Onay Bekliyor' veya benzer bir duruma geçiş ve buna karşılık gelen zaman damgasından çıkarılır. Olay türü inferred | |||
| Ödeme onaylandı | Ödemenin başarıyla işlendiğine ve onayın alındığına dair kurum içi teyidi ifade eder. Bu adım çoğu zaman alacaklıya veya diğer iç sistemlere bildirim gönderilmesini başlatır. | ||
| Neden önemli? Bu aşama, vade uyumunu ve zamanında ödeme oranını ölçmek için önemlidir. Kuruluşun ödemeyi başarılı saydığı zamanı açıkça gösteren bir zaman damgası sağlar. Nereden alınır? Harici ağdan onay alındıktan sonra ödeme işlem tablosundaki durumun 'Onaylandı' veya 'Tamamlandı' olarak değişmesinden çıkarılır. Kaydedin Durumun 'Onaylandı' veya 'İşlendi' olarak değişmesinden çıkarılır. Olay türü inferred | |||
| Ödeme reddedildi | Onaylayan kişi ödeme talebini reddettiğinde gerçekleşir. Genellikle düzeltme yapılıp talebin yeniden gönderilmesi gerekir. Bu açık olay, ödemenin ilerlemesini durdurur ve yeniden çalışma döngüsü başlatır. | ||
| Neden önemli? Yeniden çalışmaları ve süreç verimsizliklerini belirler. Ret sıklığını izlemek, ilk veri kalitesi veya başvuru politikalarıyla ilgili sorunları teşhis etmeye ve yeniden çalışma analizine yardımcı olur. Nereden alınır? Onay günlüğüne açık bir olay olarak veya işlem tablosunda durumun 'Reddedildi' olarak değişmesiyle kaydedilir. Olay, ret nedenini belirten bir kod içerebilir. Kaydedin Onaylayan kişi sistemde ret işlemini tamamladığında kaydedilir. Olay türü explicit | |||
| Ödeme talimatı gönderildi | Ödeme talimatının hazırlanıp SWIFT, ACH veya SEPA gibi harici bir ödeme ağına iletildiği noktayı gösterir. ACI sistemleri, denetim ve izleme amacıyla bu devir teslimi açıkça kaydeder. | ||
| Neden önemli? Birçok ödeme türünde bu, 'geri dönüşü olmayan nokta’dır. Bu adımı izlemek, harici bağımlılıklar devreye girmeden önceki iç işlem süresini ölçmeye yardımcı olur. Nereden alınır? Bu olay neredeyse her zaman ACI işlem veya mesaj günlüklerine açıkça kaydedilir ve çoğu zaman ağa özgü bir referans numarası içerir. Kaydedin Ödeme mesajı harici ağa gönderildiğinde açık bir günlük kaydı oluşturulur. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
Veritabanı ortamına erişin: ACI Postilion Realtime veritabanını barındıran SQL Server örneğinde SQL Server Management Studio (SSMS) veya uyumlu bir istemci kullanarak oturum açın.
Temel tabloları belirleyin:
post_tran(işlem günlüğü) vepost_tran_cust(özel veri uzantısı) tablolarını bulun. Bu nesneler içinSELECTizniniz olduğundan emin olun.Vaka tanımlayıcısını belirleyin: Bu veri çıkarma işleminde
retrieval_reference_nr,PaymentTransactionIdolarak kullanılır. Uygulamanızda farklı bir benzersiz anahtar (ör.system_trace_audit_nriletransmission_date_timebirleşimi) kullanılıyorsa sorgudaki seçimi buna göre düzenleyin.Filtre parametrelerini yapılandırın: Aşağıda verilen sorguyu açın. Betiğin başındaki
@StartDateve@EndDatedeğişkenlerini bulun. Performansı artırmak için bu değişkenleri istediğiniz veri çıkarma aralığına (ör. son 30 ila 90 gün) göre ayarlayın.Etkinlik mantığını gözden geçirin: Sorgu, ISO 8583 mesaj türlerini (ör. 0200, 0210) ve yanıt kodlarını gerekli 14 Process Mining etkinliğiyle eşleştirir.
CASEifadelerini inceleyerek ACI arayüz yapılandırmanızla uyumlu olduklarını doğrulayın.Sorguyu çalıştırın: Betiğin tamamını çalıştırın. Sorgu, farklı işlem durumlarını tek bir Event Log biçiminde birleştirmek için
UNION ALLkullanır.Veri çıktısını doğrulayın: Sonuçlarda gerekli sütunların bulunduğunu kontrol edin:
PaymentTransactionId,ActivityNameveEventTimestamp. Önemli alanlarda beklenmedikNULLdeğerleri olmadığından emin olun.Verileri dışa aktarın: SSMS’teki sonuç tablosuna sağ tıklayın ve çıktıyı CSV dosyası olarak kaydedin (ör.
ACI_Payments_EventLog.csv).ProcessMind için biçimlendirin: CSV dosyasını açın ve
EventTimestampdeğerlerinin standart biçimde (YYYY-MM-DD HH:MM:SS) olduğunu,PaymentAmountalanında ise yalnızca sayısal değerler bulunduğunu doğrulayın.Yükleyin: Doğruladığınız CSV dosyasını ProcessMind’e aktarın ve sütunları sırasıyla Vaka kimliği, Etkinlik ve Zaman damgası alanlarıyla eşleştirin.
Yapılandırma
- Tarih aralığı: ACI
post_trantabloları çok hızlı büyür. Veri çıkarmayı son 3 aylık dönemle sınırlamanız veya varsa bölüm değiştirme yöntemini kullanmanız önerilir. - Yanıt kodları: Sorgu,
rsp_code = '00'değerinin başarılı işlemi gösterdiğini varsayar. Kurumunuz onay/başarı için farklı kodlar (ör. '08' veya '10') kullanıyorsa filtreleri güncelleyin. - Mesaj türleri (ISO 8583): Betik, standart mesaj türlerini (İstekler için 0100/0200, Yanıtlar için 0210) kullanır.
source_node_nameyapılandırmanızda tanımlanan özel mesaj türleri için düzenleme gerekebilir. - Sistem performansı: Bu sorgu, canlı işlem akışının engellenmesini önlemek için
NOLOCKipuçlarını kullanır. Üretim ortamında bu ipuçlarını kaldırmayın. - Para birimleri: Tutarlar ham değerler olarak alınır. Analiz sırasında birden fazla para birimini standartlaştırmanız gerekiyorsa
tran_currency_codealanını kullanın.
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; Başlamaya hazır mısınız?
Ödeme işlemleri verilerinizi çıkarmaya başlamak için bu şablonu rehber olarak kullanın. Değerli içgörüler edinin ve finansal iş akışlarınızın verimliliğini bugün artırın.
Ödeme işlemlerini iyileştirin: Ücretsiz denemenizi şimdi başlatın
Ödeme istisnalarını ortadan kaldırın ve işlemlerin %98'ini doğrudan işleyin.
Kredi kartı gerekmez, kurulum birkaç dakika sürer