Kredi yönetimi ve tahsilat için Veri Templateiniz
Kredi yönetimi ve tahsilat için Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- Süreç keşfi için izlenecek temel etkinlikler
- Veri çıkarma adımları
Kredi yönetimi ve tahsilat öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Kredi yönetimi sürecinde belirli bir anda gerçekleşen iş olayının veya görevin adı. | ||
| Açıklama Bu öznitelik, fatura yaşam döngüsündeki Fatura oluşturuldu, Tahsilat prosedürü başlatıldı veya Ödeme alındı gibi tek bir adımı tanımlar. Her etkinlik, vakayı bir sonraki aşamaya taşıyan ayrı bir olayı temsil eder. Etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining’in temelini oluşturur. Gerçek süreç akışını ortaya çıkarmaya, vakaların beklediği darboğazları belirlemeye, etkinliklerin tekrarlandığı yeniden çalışma döngülerini tespit etmeye ve gerçek süreci tasarlanan ya da ideal süreçle karşılaştırmaya yardımcı olur. Etkinlik adı, süreç haritaları oluşturmak ve adımlar arasındaki geçiş sürelerini hesaplamak için temel bir özniteliktir. Neden önemli? Bu öznitelik, süreç haritasındaki adımları tanımlar ve fatura yaşam döngüsünü baştan sona görselleştirip analiz etmenizi sağlar. Nereden alınır? Bu, Oracle Fusion Financials içindeki çeşitli iş olaylarından türetilen kavramsal bir alandır. Genellikle Alacaklar (AR) ve Advanced Collections gibi modüllerdeki işlem durumları, olay tarihleri veya belirli işlemler eşleştirilerek oluşturulur. Örnekler Fatura oluşturulduTahsilat prosedürü başlatıldıÖdeme alındıİtiraz kaydedildi | |||
| Fatura numarası InvoiceNumber | Her müşteri faturasını benzersiz biçimde tanımlayan ve kredi yönetimi sürecinin temel vaka tanımlayıcısı olarak kullanılan numara. | ||
| Açıklama Fatura numarası, tek bir alacakla ilgili tüm olayları ve etkinlikleri, faturanın oluşturulmasından son ödemenin alınmasına veya silinmesine kadar birbirine bağlayan temel anahtardır. Faturanın yaşam döngüsünü baştan sona görmenizi sağlar. Process Mining analizinde bu öznitelik, her faturanın yolculuğunu yeniden oluşturmak için kullanılır. Analistler, ilgili tüm etkinlikleri tek bir fatura numarası altında gruplayarak süreç akışlarını görselleştirebilir, yaygın ve farklı yolları belirleyebilir, tüm süreç veya itiraz çözümü ya da ödemenin kaydedilmesi gibi belirli aşamalar için çevrim sürelerini ölçebilir. Neden önemli? Bu temel Vaka kimliği, ilgili tüm süreç adımlarını birbirine bağlar ve her faturanın kesilmesinden kapanmasına kadar olan yolculuğunu yeniden oluşturup analiz etmenizi sağlar. Nereden alınır? Bu tanımlayıcı, Oracle Fusion Financials’ta genellikle RA_CUSTOMER_TRX_ALL tablosundaki TRX_NUMBER alanında bulunur. Örnekler INV-1005679884321AR-2023-04-112 | |||
| Olay zamanı EventTime | Etkinliğin gerçekleştiği kesin tarih ve saat, yani olayın zaman damgası. | ||
| Açıklama Olay zamanı veya zaman damgası, bir etkinliğin gerçekleştiği kesin anı kaydeder. Doğru bir süreç akışı oluşturmak için olayları kronolojik sıraya koymada gereklidir. Zaman damgaları doğru değilse olayların sırası belirlenemez. Analizde bu öznitelik, etkinlikler arasındaki süreleri ve çevrim sürelerini hesaplamak için kullanılır; performansı ölçmek açısından önemlidir. Örneğin İtiraz Çözüm Çevrim Süresi veya Fatura Ödeme Çevrim Süresi gibi KPI’ları hesaplamayı sağlar. Ayrıca süreç performansındaki eğilimleri farklı zaman aralıklarında incelemenize yardımcı olur. Neden önemli? Bu zaman damgası, olayları sıralamak, çevrim sürelerini ve süreleri hesaplamak, süreç performansını zaman içinde analiz etmek için gereklidir. Nereden alınır? Oracle Fusion Financials tablolarındaki çeşitli tarih alanlarından türetilir. Örneğin fatura oluşturma için RA_CUSTOMER_TRX_ALL tablosundaki TRX_DATE veya bir tahsilat işleminin oluşturulma tarihi kullanılır. Örnekler 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Kaynak sistem SourceSystem | Verinin alındığı sistem. | ||
| Açıklama Bu öznitelik, olay verilerinin kaydedildiği kaynak uygulamayı belirtir. Karmaşık bir BT ortamında tek bir uçtan uca süreç birden fazla sistemi kapsayabilir. Kaynak sistemi belirtmek, veri yönetişimi ve sorun giderme açısından, ayrıca verinin bağlamını anlamak için önemlidir. Birden fazla sistemden gelen olaylar tek bir süreç görünümünde birleştirildiğinde, olayların kaynağını ayırt etmeye ve veri kökeninin izlenebilir olmasına yardımcı olur. Neden önemli? Verinin kaynağını netleştirir. Bu bilgi, veriyi doğrulamak, yönetişimi sağlamak ve sürecin teknolojik bağlamını anlamak için önemlidir. Nereden alınır? Kayıtların kaynağını belirtmek için genellikle veri çıkarma sırasında eklenen sabit bir değerdir. Örnekler Oracle Fusion FinancialsOracle AROracle Collections | |||
| Son veri güncellemesi LastDataUpdate | Bu olaya ait verilerin kaynak sistemden en son ne zaman yenilendiğini veya çıkarıldığını gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, en son veri çıkarma işleminin tarih ve saatini belirtir. İş sürecinin parçası olmayan bir meta veri alanıdır; ancak analiz edilen verilerin ne kadar güncel olduğunu anlamak için önemlidir. Analistler bu zaman damgasını, güncel bilgilerle çalıştıklarını doğrulamak ve verilerin hangi tarihe kadar olan dönemi kapsadığını anlamak için kullanır. Veri yönetişimi ve Dashboardlarda ya da raporlarda sunulan verilerin güncelliğine ilişkin beklentileri yönetmek açısından gereklidir. Neden önemli? Verilerin güncelliğini göstererek analistlerin ve paydaşların verilerin ne zaman alındığını ve hâlâ geçerli olup olmadığını anlamasını sağlar. Nereden alınır? Bu değer, veri çıkarma ve yükleme (ETL) işlemi sırasında oluşturulur ve her kayda eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Fatura tutarı InvoiceAmount | Faturanın toplam parasal değeri. | ||
| Açıklama Fatura tutarı, müşteriye kesilen mal veya hizmetlerin toplam değerini gösterir. Sürecin finansal etkisini anlamak için önemli bir özniteliktir. Analizde fatura tutarı, tahsilat girişimlerine öncelik vermek ve tutarı yüksek, vadesi geçmiş faturalara odaklanmak için kullanılır. Ayrıca işlem tutarına göre ödeme davranışlarını incelemeye ve silinen faturaların finansal etkisini hesaplamaya yardımcı olur. Fatura Silme Oranı Analizi gibi Dashboardlar, finansal kayıpların boyutunu değerlendirmek için bu değerden yararlanır. Neden önemli? Sürecin finansal boyutunu göstererek tutarı yüksek faturalara öncelik vermenizi ve süreç verimsizliklerinin parasal etkisini analiz etmenizi sağlar. Nereden alınır? Bu bilgi, fatura için ödenecek tutarı saklayan AR_PAYMENT_SCHEDULES_ALL tablosundan alınabilir. Örnekler 5000.001250.75250000.00 | |||
| İhtar düzeyi DunningLevel | Faturaya uygulanan ihtar prosedürünün aşaması veya düzeyi. | ||
| Açıklama İhtar düzeyi, tahsilat hatırlatmasının yoğunluğunu gösterir. Bu yoğunluk genellikle zaman içinde artar. Örneğin 1. düzeyde nazik bir e-posta hatırlatması gönderilirken 3. düzeyde resmî bir mektup gönderilebilir veya telefon edilebilir. Süreci ihtar düzeyine göre analiz etmek, ihtar stratejisinin ne kadar etkili olduğunu değerlendirmeye yardımcı olur. İhtar etkinliği Dashboardu, her ihtar adımından ödemeye geçiş oranlarını görselleştirmek için bu özniteliği kullanır. Böylece işletme, hangi ihtar adımlarının daha etkili olduğunu belirleyebilir ve tahsilatı artırmak için hatırlatmaların zamanlamasını ve içeriğini iyileştirebilir. Neden önemli? Tahsilat girişimlerinin hangi aşamada olduğunu izler ve ihtar stratejisinin etkinliğini değerlendirmeye yardımcı olur. Nereden alınır? Bu veri, Oracle Advanced Collections modülünde yönetilir. IEX_DUNNINGS gibi ihtar geçmişiyle ilgili tablolarda bulunabilir. Örnekler 1. düzey: Hatırlatma2. düzey: Uyarı3. düzey: Son bildirim | |||
| Kullanıcı User | Etkinliği gerçekleştiren kullanıcı veya sistem kimliği. | ||
| Açıklama Bu öznitelik, kredi limitini onaylama, ödeme kaydetme veya itirazı çözme gibi bir etkinliği gerçekleştiren çalışanı ya da otomatik sistem kullanıcısını belirtir. Etkinlikleri kullanıcıya göre analiz etmek, iş yükünün dağılımını, bireysel performansı ve uyumluluğu anlamak açısından önemlidir. Otomatik etkinliklerde sistem süreçlerinin katkısını izlemeye yardımcı olur. Kullanıcı davranışlarını izleyerek eğitim ihtiyaçlarını veya olası dolandırıcılık faaliyetlerini belirlemek için de kullanılabilir. Neden önemli? Süreç etkinliklerini belirli kişilere veya otomatik sistemlere bağlayarak performans takibi, iş yükü analizi ve denetim olanağı sağlar. Nereden alınır? Oracle Fusion Financials genelindeki çeşitli işlem ve geçmiş tablolarında bulunan 'CREATED_BY' veya 'LAST_UPDATED_BY' sütunlarından alınır. Örnekler jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Müşteri grubu CustomerSegment | Müşterinin büyüklük, sektör veya stratejik önem gibi ölçütlere göre tanımlanmış bir gruba atanması. | ||
| Açıklama Müşteri grubu, müşterileri ortak özelliklerine göre sınıflandıran kategorik bir özniteliktir. Gruplar Stratejik, KOBİ veya Enterprise gibi ölçütlere ya da Üretim ve Perakende gibi sektörlere göre tanımlanabilir. Bu öznitelik, karşılaştırmalı analizlerde kullanılır. Analistler farklı gruplardaki süreç performansını karşılaştırarak örneğin bir grupta itiraz oranının daha yüksek veya ödeme çevrim süresinin daha uzun olup olmadığını görebilir. Bu içgörüler, her grubun ihtiyaçlarına ve risklerine uygun kredi politikaları ve tahsilat stratejileri belirlemeye yardımcı olur. Müşteri Grubuna Göre Fatura Silme Oranı Analizi gibi Dashboardları destekler. Neden önemli? Farklı müşteri gruplarındaki süreç performansını ve riskleri karşılaştırarak aralarındaki farkları ortaya çıkarır. Nereden alınır? Genellikle müşteri ana verilerinde (HZ_CUST_ACCOUNTS veya ilişkili tablolar) tutulur ya da gelir ve sektör gibi müşteri özniteliklerinden türetilir. Örnekler Büyük kuruluşKüçük ve orta ölçekli işletmeKamu kuruluşuStratejik iş ortağı | |||
| Müşteri numarası CustomerNumber | Faturayla ilişkili müşteriyi benzersiz biçimde tanımlayan numara. | ||
| Açıklama Müşteri numarası, faturayı belirli bir müşteri hesabına bağlar. Böylece kredi ve tahsilat sürecini müşteri özniteliklerine göre gruplandırıp analiz edebilirsiniz. Analistler müşteri numarasını kullanarak bazı müşterilerin ödemelerini sürekli geciktirip geciktirmediğini, daha fazla itirazda bulunup bulunmadığını veya daha fazla tahsilat girişimi gerektirip gerektirmediğini inceleyebilir. Bu bilgi, müşteriye özel tahsilat stratejileri oluşturmak, kredi koşullarını düzenlemek ve yüksek riskli müşteri gruplarını belirlemek için önemlidir. Müşteri Grubuna Göre Fatura Silme Oranı Analizi gibi analizleri doğrudan destekler. Neden önemli? Süreci müşterilere göre gruplandırarak örüntüleri, riskleri ve müşteriye özel tahsilat stratejisi fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Genellikle RA_CUSTOMER_TRX_ALL tablosundaki BILL_TO_CUSTOMER_ID alanında bulunur ve HZ_CUST_ACCOUNTS tablosuna bağlanır. Örnekler CUST-0012389455ACME-CORP-US | |||
| Tahsilat sorumlusu Collector | Faturaya atanmış tahsilat sorumlusunun adı veya kimliği. | ||
| Açıklama Tahsilat sorumlusu, vadesi geçmiş bir faturanın tahsilat faaliyetlerini yürüten kişi veya ekiptir. Bu atama, tahsilat iş akışının önemli bir adımıdır. Bu öznitelik, tahsilat ekibinde performans yönetimi ve kaynak planlaması açısından önemlidir. Yöneticiler, sonuçları tahsilat sorumlusu bazında analiz ederek etkinliği değerlendirebilir, eğitim ihtiyaçlarını belirleyebilir ve iş yükünü dengeleyebilir. Tahsilat Sorumlusu Atama Etkinliği Dashboardu, farklı tahsilat sorumlularının başarı oranlarını ve çevrim sürelerini karşılaştırmak için doğrudan bu özniteliği kullanır. Neden önemli? Tahsilat sorumlularının veya ekiplerinin performansını analiz etmeye, kaynakları daha iyi dağıtmaya ve genel tahsilat verimliliğini artırmaya yardımcı olur. Nereden alınır? Bu bilgiler genellikle Oracle Advanced Collections modülünde, IEX_CASES_ALL_B gibi tablolarda veya ilgili atama tablolarında tutulur. Örnekler John SmithJane DoeTahsilat Ekibi A | |||
| Vade tarihi DueDate | Fatura ödemesinin yapılması gereken tarih. | ||
| Açıklama Vade tarihi, ödeme için sözleşmeyle belirlenen önemli bir tarihtir. Ödemenin zamanında yapılıp yapılmadığını ölçmek için esas alınır. Bu öznitelik, vadesi geçmiş faturaları belirlemek ve gecikme gün sayısını hesaplamak için gereklidir. İhtar prosedürlerinin ne zaman başlatılacağını belirlemede temel alınır ve Satışların Tahsilat Süresi (DSO) gibi KPI’ların hesaplanmasında kullanılır. Ayrıca ödenmemiş borçları sınıflandıran yaşlandırma raporlarının hazırlanmasına da yardımcı olur. Neden önemli? Faturanın vadesinin geçip geçmediğini belirlemek için esas alınır; tahsilat çalışmalarını başlatır ve yaşlandırma analizine olanak tanır. Nereden alınır? AR_PAYMENT_SCHEDULES_ALL tablosunda DUE_DATE alanında bulunur. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Bitiş zamanı EndTime | Süreli bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
| Açıklama Belirgin bir başlangıç ve bitiş zamanı olan etkinliklerde bu öznitelik, tamamlanma zamanını kaydeder. Process Mining analizindeki birçok olay anlık gerçekleşse de 'İtiraz incelemesi' gibi bazıları belirli bir süreye yayılabilir. Ayrı bir bitiş zamanı, etkinliklerin işlem sürelerini doğru hesaplamayı sağlar. Özellikle etkinlikler arasında bekleme süresi olduğunda, süreyi sonraki etkinliğin başlangıç zamanından çıkarsamaktan daha doğru sonuç verir. Kaynak kullanımını analiz etmek ve süreçte en çok zaman alan adımları belirlemek açısından önemlidir. Neden önemli? Belirli etkinliklerin ne kadar sürdüğünü doğru hesaplayarak darboğazlar ve kaynak kullanımı hakkında daha ayrıntılı bilgi sağlar. Nereden alınır? Bu genellikle kavramsal bir özniteliktir. Kaynak tablolardaki etkinliğe karşılık gelen 'son güncelleme' zaman damgasından veya belirli bir 'kapanış tarihi' alanından alınabilir. Örnekler 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Fatura durumu InvoiceStatus | Faturanın yaşam döngüsündeki mevcut durumu. | ||
| Açıklama Fatura durumu, faturanın süreçteki mevcut konumunu gösterir. Yaygın durumlar arasında 'Açık', 'Ödendi', 'İtiraz edildi', 'Vadesi geçmiş' ve 'Tahsil edilemez olarak kaydedildi' yer alır. Bu öznitelik, alacakların genel durumunu görmenizi sağlar. Process Mining analizinde bu öznitelik, vadesi geçmiş tüm açık faturalar gibi belirli gruplara odaklanmak için vakaları filtrelemeye yarar. Vadesi geçmiş faturaların yaşlandırma ve durum Dashboardunda temel bir boyut olarak kullanılır. Fatura portföyünün mevcut durumunu anında görmenizi ve tahsilat çalışmalarına öncelik vermenizi sağlar. Neden önemli? Faturanın mevcut durumunu hızlıca görmenizi, tahsilat çalışmalarını kolayca filtreleyip önceliklendirmenizi sağlar. Nereden alınır? Genellikle AR_PAYMENT_SCHEDULES_ALL tablosunda STATUS adlı alanda bulunur. Örnekler AçıkKapalıİtiraz edildiTahsilat sürecinde | |||
| Fatura para birimi InvoiceCurrency | Fatura tutarının belirtildiği para birimi. | ||
| Açıklama Bu öznitelik, faturanın USD, EUR veya GBP gibi para birimini belirtir. Çok uluslu kuruluşlarda faturalar genellikle farklı para birimleriyle kesilir. Birden fazla para birimindeki verileri analiz ederken dikkatli olmak gerekir. Bu öznitelik, süreç görünümünü para birimine göre filtrelemenizi veya konsolide finansal raporlama için doğru döviz kurlarını uygulamanızı sağlar. Böylece parasal değerler doğru yorumlanır ve tutarlar aynı ölçüt üzerinden karşılaştırılır. Neden önemli? Birden fazla para biriminin kullanıldığı ortamlarda finansal verileri doğru yorumlamak ve analiz sonuçlarının doğruluğunu sağlamak için gereklidir. Nereden alınır? Genellikle RA_CUSTOMER_TRX_ALL tablosundaki INVOICE_CURRENCY_CODE alanında bulunur. Örnekler USDEURGBPJPY | |||
| Gecikme gün sayısı DaysOverdue | Faturanın vade tarihini kaç gün geçtiği. | ||
| Açıklama Bu hesaplanan metrik, ödenmemiş bir faturanın kaç gün geciktiğini gösterir. Açık faturalar için geçerli tarih ile vade tarihi, kapalı faturalar içinse ödeme tarihi ile vade tarihi arasındaki fark alınarak hesaplanır. Gecikme gün sayısı, yaşlandırma analizi ve tahsilat çalışmalarına öncelik vermek için önemli bir ölçüttür. Vadesi geçmiş faturaların yaşlandırma ve durum Dashboardunda temel metriktir. Faturalar gecikme süresine göre gruplandırılır, örneğin 1-30 gün ve 31-60 gün. Böylece tahsilat ekibi, en eski ve en yüksek riskli borçlara odaklanabilir. Neden önemli? Ödeme gecikmelerinin boyutunu gösterir; tahsilata öncelik vermek ve yaşlandırma analizi yapmak için temel bir metriktir. Nereden alınır? Hesaplanan bir alandır. Açık faturalar için mantık CurrentDate - DueDate, kapalı faturalar içinse PaymentDate - DueDate şeklindedir. Örnekler 1545920 | |||
| İş birimi BusinessUnit | Faturayı düzenleyen belirli iş birimi veya kuruluş. | ||
| Açıklama Büyük kuruluşlarda operasyonlar genellikle birden fazla iş birimine ayrılır. Bu öznitelik, faturanın hangi iş birimiyle ilişkili olduğunu gösterir. Süreci iş birimine göre analiz etmek, kuruluşun farklı bölümlerindeki performansı karşılaştırmanızı sağlar. Kredi ve tahsilat politikalarının uygulanmasındaki farklılıkları ortaya çıkarabilir ve hangi iş birimlerinin alacaklarını daha etkili yönettiğini gösterebilir. Böylece iyi uygulamalar paylaşılabilir ve gerektiğinde süreçler standartlaştırılabilir. Neden önemli? Kuruluşun farklı birimlerindeki performansı karşılaştırmaya, iyi uygulamaları ve iyileştirme alanlarını belirlemeye yardımcı olur. Nereden alınır? Kuruluş yapısına bağlanan ORG_ID alanı aracılığıyla RA_CUSTOMER_TRX_ALL tablosunda bulunur. Örnekler Kuzey Amerika iş birimiEMEA iş birimiKüresel Hizmetler Bölümü | |||
| İtiraz nedeni DisputeReason | Müşterinin faturaya itiraz ederken bildirdiği neden. | ||
| Açıklama Müşteri faturaya itiraz ettiğinde genellikle 'Yanlış fiyatlandırma', 'Hasarlı ürün' veya 'Mükerrer fatura' gibi bir neden belirtir. Bu öznitelik, bildirilen nedeni kaydeder. İtiraz nedenlerini analiz etmek, sorunun temel nedenlerini bulmaya yardımcı olur. Ödeme gecikmelerine yol açan sipariş yönetimi veya faturalandırma gibi önceki süreçlerdeki tekrarlayan sorunları belirlemeyi sağlar. İşletme, farklı itiraz nedenlerini sınıflandırıp ne sıklıkta görüldüklerini izleyerek bu sorunları gidermeye yönelik adımlar atabilir. Böylece itiraz çözüm çevrim süresini kısaltma hedefine katkı sağlanır. Neden önemli? Fatura itirazlarının temel nedenlerini belirlemeye yardımcı olur ve yeni itirazları önlemek için önceki süreçlerde iyileştirmeler yapılmasını sağlar. Nereden alınır? İtiraz yönetimi resmîleştirilmişse bu bilgiler genellikle Oracle Advanced Collections veya Oracle Channel Revenue Management modüllerinde kaydedilir. AR_DISPUTE_HISTORY gibi tablolarda bulunabilir. Örnekler Yanlış miktarFiyat uyuşmazlığıHasarlı ürünHizmet sunulmadı | |||
| Kredi limiti tutarı CreditLimitAmount | Müşteri için onaylanan en yüksek kredi tutarı. | ||
| Açıklama Kredi limiti tutarı, bir şirketin belirli bir müşteri için üstlenmeyi kabul ettiği toplam kredi riskini gösterir. Bu tutar, kredi inceleme sürecinde belirlenir. Bu öznitelik, kredi limiti kararlarının etkisini gösteren Dashboard için gereklidir. İşletme, onaylanan kredi limitini sonraki ödeme davranışları ve tahsil edilemeyen borçlarla karşılaştırarak kredi riski politikalarının etkinliğini değerlendirebilir. Analiz, aşırı yüksek kredi limitlerinin tahsil edilemeyen borçları artırıp artırmadığını ortaya çıkarabilir ve kredi onay sürecini iyileştirmeye yardımcı olur. Neden önemli? Onaylanan kredi limitini ödeme sonuçları ve tahsil edilemeyen borçlarla karşılaştırarak kredi riski politikalarının etkinliğini değerlendirmeye yardımcı olur. Nereden alınır? Oracle Credit Management içinde yönetilir ve genellikle HZ_CUST_PROFILE_AMTS gibi müşteri kredi profili tablolarında tutulur. Örnekler 10000.0050000.00250000.00 | |||
| Ödeme koşulları PaymentTerms | Ödemenin ne zaman yapılacağını belirleyen, üzerinde anlaşılmış koşullar. | ||
| Açıklama Ödeme koşulları, müşterinin ödemeyi hangi şartlarda yapmasının beklendiğini belirtir. Örneğin '30 gün net' veya '60 gün net' gibi koşullar, faturanın vade tarihini hesaplamak için kullanılır. Ödeme performansını ödeme koşullarına göre analiz etmek, dikkat çekici örüntüleri ortaya çıkarabilir. Örneğin, vadesi daha kısa olan müşteriler ödemelerini daha sık geciktirebilir. Bu bilgi, kredi politikalarını gözden geçirip iyileştirmek ve müşterileri farklı tahsilat stratejilerine göre gruplandırmak için kullanılabilir. Ayrıca bazı faturaların neden vadesini geçtiğini anlamaya yardımcı olur. Neden önemli? Üzerinde anlaşılmış ödeme planını gösterir ve farklı kredi koşullarındaki ödeme davranışlarını analiz etmenizi sağlar. Nereden alınır? RA_TERMS tablosunda tutulur ve fatura işlemiyle ilişkilendirilir. Örnekler 30 gün net60 gün netTeslim alındığında ödenir | |||
| Ödeme sözü tarihi PromiseToPayDate | Müşterinin ödeme yapmayı taahhüt ettiği tarih. | ||
| Açıklama Tahsilat çalışmaları sırasında müşteri, ödemeyi ileride belirli bir tarihte yapacağını taahhüt edebilir. Bu taahhüdü izlemek için 'Ödeme sözü tarihi' kaydedilir. Bu öznitelik, tahsilat iş akışlarını yönetmek ve müşteri taahhütlerinin ne kadar güvenilir olduğunu değerlendirmek açısından önemlidir. Tahsilat ekipleri, ödeme sözü tarihini ödemenin alındığı tarihle karşılaştırarak bu taahhütlerin ne ölçüde yerine getirildiğini görebilir. Ayrıca nakit akışını daha doğru tahmin etmeye ve verilen söz tutulmadığında tahsilat çalışmalarını ne zaman üst düzeye çıkaracaklarına karar vermeye yardımcı olur. Neden önemli? Müşterilerin ödeme taahhütlerini izleyerek nakit girişlerini tahmin etmeye ve tahsilat görüşmelerinin etkinliğini yönetmeye yardımcı olur. Nereden alınır? Oracle Advanced Collections modülünde, muhtemelen IEX_PROMISES_T gibi tablolarda tutulur. Örnekler 2023-06-102023-06-252023-07-05 | |||
| Tahsil edilemez olarak kaydedildi mi IsWrittenOff | Faturanın tahsil edilemeyen borç olarak kaydedilip kaydedilmediğini belirten bir doğru/yanlış göstergesi. | ||
| Açıklama Bu türetilmiş gösterge, şirketin tahsil edilemez saydığı ve aktif alacaklarından çıkardığı faturaları belirler. Bu, genellikle bir fatura için en son ve istenmeyen sonuçtur. Bu öznitelik, fatura zarar yazma oranı KPI’ını hesaplamak ve ilgili analiz Dashboardunu hazırlamak için gereklidir. Analistler, başarısız tahsilatları ayırarak müşteri segmenti veya fatura tutarı gibi zarar yazma riskiyle ilişkili olabilecek ortak özellikleri belirleyebilir. Bu bilgiler, kredi politikalarını ve tahsilat stratejilerini iyileştirmek için kullanılır. Neden önemli? Tahsilatın başarısız olduğu vakaları açıkça belirler; tahsil edilemeyen borçların temel nedenlerini analiz etmek ve zarar yazma oranlarını hesaplamak için gereklidir. Nereden alınır? Hesaplanan bir alandır. Vaka için 'Fatura zarar yazıldı' etkinliğinin bulunup bulunmadığı veya fatura durumunun 'Tahsil edilemez olarak kaydedildi' olup olmadığı kontrol edilerek belirlenir. Örnekler truefalse | |||
| Vadesi geçti mi IsOverdue | Faturanın ödeme vadesini geçip geçmediğini belirten bir doğru/yanlış göstergesi. | ||
| Açıklama Bu türetilmiş öznitelik, faturanın vadesinin geçip geçmediğini doğru veya yanlış olarak gösterir. Genellikle geçerli tarih (veya ödeme tarihi) ile faturanın vade tarihi karşılaştırılarak hesaplanır. Bu gösterge, analizde filtreleme ve gruplandırma için çok kullanışlıdır. Analistlerin vadesi geçmiş faturaları hızla ayırıp bu faturaların süreç akışlarını, tahsilat çalışmalarının etkinliğini ve diğer özelliklerini incelemesini sağlar. Vadesi geçmiş borçların yönetimine odaklanan Dashboard ve KPI’ların, örneğin vadesi geçmiş faturaların yaşlandırma ve durum Dashboardunun hazırlanmasını kolaylaştırır. Neden önemli? Vadesi geçmiş tüm faturaları belirlemek ve analiz etmek için açık ve anlaşılır bir gösterge sunar. Bu faturalar, tahsilat sürecinin temel odağıdır. Nereden alınır? Hesaplanan bir alandır. Mantık şöyledir: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Örnekler truefalse | |||
Kredi yönetimi ve tahsilat etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura oluşturuldu | Oracle Fusion Financials’ta fatura işlem kaydının oluşturulduğunu belirtir. Bu, alacaklar modülünde faturanın yaşam döngüsünün resmî başlangıcıdır ve analiz için temel başlangıç noktasıdır. | ||
| Neden önemli? Bu, fatura yolculuğunun temel başlangıç olayıdır. Satışların Tahsilat Süresi (DSO) ve fatura ödeme çevrim süresi gibi sonraki tüm çevrim süresi hesaplamaları bu ilk zaman damgasına bağlıdır. Nereden alınır? Bu, belirli bir TRX_NUMBER (Invoice Number) için RA_CUSTOMER_TRX_ALL tablosundaki CREATION_DATE veya TRX_DATE sütunundan alınan açık bir olaydır. Kaydedin Olayın zaman damgası, RA_CUSTOMER_TRX_ALL tablosundaki CREATION_DATE değeridir. Olay türü explicit | |||
| Fatura silindi | Tahsilat girişimlerini durdurma ve fatura tutarını tahsil edilemeyen borç olarak kaydetme yönündeki resmî kararı ifade eder. Fatura bakiyesini sıfırlayan açık bir finansal işlemdir. | ||
| Neden önemli? Bu, tahsilat sürecinin başarısızlıkla sonuçlandığı önemli bir bitiş noktasıdır. Müşteri grubu, bölge veya kredi limiti bazında silinen faturaları analiz etmek, kayıpları azaltmak için kredi politikalarını ve tahsilat stratejilerini iyileştirmeye yardımcı olur. Nereden alınır? AR_ADJUSTMENTS_ALL tablosunda, RECEIVABLES_TRX_ID alanı tahsil edilemeyen borç veya fatura silme etkinliğini gösteren bir düzeltme kaydı oluşturulduğunda açıkça kaydedilir. Kaydedin Fatura silme etkinliği türüne sahip AR_ADJUSTMENTS_ALL kaydının oluşturulma tarihi. Olay türü explicit | |||
| Ödeme alındı | Müşteriden ödeme alındığını belirtir. Ödeme henüz belirli bir faturayla eşleştirilmemiş olabilir. Sistemde bir nakit tahsilat işlemi oluşturulduğunda kaydedilir. | ||
| Neden önemli? Bu, tahsilat sürecinde nakdin alındığını gösteren önemli bir dönüm noktasıdır. Bu olayla ödemenin faturayla eşleştirilmesi arasındaki süre, kurum içi işlem verimliliğini ölçer. Nereden alınır? AR_CASH_RECEIPTS_ALL tablosundaki RECEIPT_DATE alanından açıkça alınır. Tahsilat daha sonra AR_RECEIVABLE_APPLICATIONS_ALL üzerinden eşleştirildiği faturayla ilişkilendirilebilir. Kaydedin AR_CASH_RECEIPTS_ALL tablosundaki RECEIPT_DATE değeri, eşleştirme tabloları üzerinden ilişkilendirilir. Olay türü explicit | |||
| Ödeme faturayla eşleştirildi | Alınan ödemenin belirli bir faturayla eşleştirilmesini ve faturanın kalan bakiyesinin azaltılmasını ifade eder. Bu adım, ödemeyi faturaya resmen bağlar. | ||
| Neden önemli? Bu etkinlik, faturanın ödendiğini belirlemek için gereklidir. Satışların Tahsilat Süresi (DSO) hesabının ve ödeme kaydetme döngüsünün gerçek bitiş noktasıdır. Nereden alınır? Bu, AR_RECEIVABLE_APPLICATIONS_ALL tablosundaki APPLY_DATE alanından alınan açık bir olaydır. Bu tablo, nakit tahsilatını bir müşteri işlemine (faturaya) bağlar. Kaydedin İlgili fatura için AR_RECEIVABLE_APPLICATIONS_ALL tablosundaki APPLY_DATE değeri. Olay türü explicit | |||
| Ödeme vadesi geçti | Faturanın tamamı ödenmeden geçerli tarih vade tarihini geçtiğinde oluşan hesaplanmış bir olaydır. Bu olay, faturanın güncel durumdan vadesi geçmiş duruma geçtiğini gösterir. | ||
| Neden önemli? Bu, tahsilat ve ödeme hatırlatma süreçlerini başlatan önemli bir dönüm noktasıdır. Vadesi geçen faturaların sayısını ve tutarını analiz etmek, işletme sermayesini yönetmek ve kredi riskini değerlendirmek için gereklidir. Nereden alınır? Bu olay, STATUS değeri 'OP' (Open) olan faturalar için sistemin geçerli tarihinin AR_PAYMENT_SCHEDULES_ALL tablosundaki DUE_DATE değeriyle karşılaştırılmasıyla hesaplanır. Kaydedin Hesaplanan olay: SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE olduğunda gerçekleşir. Olay türü calculated | |||
| Tahsilat prosedürü başlatıldı | Vadesi geçmiş bir fatura için tahsilat sürecinin resmen başladığını gösterir. Genellikle ilk resmî tahsilat bildiriminin gönderilmesini içerir. Bu olay, faturanın dahil olduğu bir tahsilat toplu işlemi çalıştırıldığında kaydedilir. | ||
| Neden önemli? Bu etkinliği izlemek, tahsilat hatırlatmalarının etkinliğini ve politikalara uyumu ölçmek için önemlidir. Tahsilat girişiminin ödeme alınmasını ne kadar sürede sağladığını ölçmek için başlangıç noktası sunar. Nereden alınır? Oracle Advanced Collections modülünde kaydedilir. İşlem kimliğiyle ilişkilendirilmiş IEX_DUNNINGS gibi tablolardaki tahsilat kaydının oluşturulma tarihi bu olayı gösterir. Kaydedin Faturayla ilişkili IEX_DUNNINGS tablosundaki kaydın oluşturulma tarihi. Olay türü explicit | |||
| Fatura kapatıldı | Ödeme, kredi notu eşleştirmesi veya düzeltme sonucunda faturanın kalan bakiyesi sıfırlandığında gerçekleşir. Faturanın yaşam döngüsünün başarıyla tamamlandığını gösterir. | ||
| Neden önemli? Bu olay, sürecin başarıyla tamamlandığını gösteren temel bitiş noktalarından biridir. Alacak portföyünün genel durumunu anlamak için faturaların kapanışını izlemek gerekir. Nereden alınır? AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS değerinin 'CL' (Closed) olarak değişmesinden çıkarılır. Bu değişikliğin zaman damgası LAST_UPDATE_DATE değeridir. Kaydedin Fatura için AR_PAYMENT_SCHEDULES_ALL.STATUS değerinin 'CL' olduğunu tespit edin. Olay türü inferred | |||
| Fatura müşteriye gönderildi | Faturanın müşteriye elektronik ortamda veya basılı olarak resmî biçimde iletildiğini belirtir. Bu olay, bir teslimat modülünde açıkça kaydedilmiş olabilir veya fatura yazdırma tarihinden çıkarılabilir. | ||
| Neden önemli? Bu etkinlik, müşterinin ödeme süresinin başladığı noktayı gösterir. Bu bilgiyi izlemek, vadesi geçen gün sayısını doğru hesaplamaya ve faturanın oluşturulmasıyla müşteriye bildirilmesi arasındaki gecikmeleri incelemeye yardımcı olur. Nereden alınır? RA_CUSTOMER_TRX_ALL tablosundaki LAST_PRINTED_DATE alanından alınabilir. Alternatif olarak e-posta teslimat sistemleriyle veya diğer iletişim platformlarıyla yapılan entegrasyonların günlüklerinden çıkarılabilir. Kaydedin RA_CUSTOMER_TRX_ALL tablosundaki LAST_PRINTED_DATE alanını veya teslimat günlüğündeki durumu kullanın. Olay türü inferred | |||
| İtiraz çözüldü | Kaydedilmiş bir itirazın incelendiğini ve çözüme ulaşıldığını belirtir. Faturanın itirazlı durumu kaldırıldığında kaydedilir. | ||
| Neden önemli? Bu olay, itiraz çözüm döngüsünün sonunu gösterir. İtirazın kaydedilmesiyle bu olay arasındaki süre, operasyonel verimliliği ve nakit akışına etkisini ölçen önemli bir KPI’dır. Nereden alınır? AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS değeri, itirazın ardından 'DS' (Disputed) durumundan 'OP' (Open) veya kredi notu ya da düzeltme sonrasında 'CL' (Closed) durumuna döndüğünde çıkarılır. Kaydedin AR_PAYMENT_SCHEDULES_ALL.STATUS değerinin 'DS' durumundan başka bir duruma geçtiğini tespit edin. Olay türü inferred | |||
| İtiraz kaydedildi | Müşterinin faturanın tamamına veya bir kısmına resmen itiraz ettiğini belirtir. Bu durum genellikle faturanın ödeme planındaki bir durum değişikliğiyle kaydedilir. | ||
| Neden önemli? Bu etkinlik, itiraz çözüm sürecinin başlangıç noktasıdır. Kayıt ile çözüm arasındaki süreyi analiz etmek, tahsilatı geciktiren darboğazları belirlemeye yardımcı olur. Nereden alınır? AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS alanının 'DS' (Disputed) olarak değişmesinden çıkarılır. Zaman damgası denetim tablolarından veya son güncelleme tarihinden alınabilir. Kaydedin Fatura için AR_PAYMENT_SCHEDULES_ALL.STATUS değerinin 'DS' olarak değiştiğini tespit edin. Olay türü inferred | |||
| Kredi incelemesi tamamlandı | Faturayla ilişkili müşteri için kredi değerlendirmesinin tamamlandığını gösterir. Bu olay genellikle fatura oluşturma tarihini, müşteri hesabına ait en son kredi incelemesinin tamamlanma tarihiyle ilişkilendirerek belirlenir. Böylece kredi analizleri için bir başlangıç noktası oluşturulur. | ||
| Neden önemli? Kredi incelemesinden siparişin verilmesine kadar geçen süreyi analiz etmek, Siparişten Tahsilata döngüsünün ilk aşamalarındaki gecikmeleri belirlemeye yardımcı olur. Bu analiz, Kredi Onay Çevrim Süresi KPI’ını ölçmek ve kredi kararlarının etkisini anlamak için temel oluşturur. Nereden alınır? Faturadaki müşteri için HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE alanı sorgulanarak belirlenir (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Olayın zaman damgası, faturanın CREATION_DATE tarihinden önceki en son LAST_CREDIT_REVIEW_DATE değeridir. Kaydedin Faturayı, fatura oluşturulmadan önceki en son kredi inceleme tarihiyle ilişkilendirin. Olay türü inferred | |||
| Ödeme taahhüdü oluşturuldu | Müşterinin belirli bir tarihte ödeme yapmayı taahhüt ettiğini gösteren ve sisteme kaydedilen resmî bir anlaşmadır. Tahsilat faaliyetlerinin önemli sonuçlarından biridir. | ||
| Neden önemli? Ödeme taahhütlerini ve taahhütlerin yerine getirilme oranını izlemek, tahsilat sorumlularının performansını ölçmek için önemli bir göstergedir. Vadesi geçmiş alacaklardan sağlanacak nakit akışını tahmin etmeye ve tahsilat sorumlularının etkinliğini değerlendirmeye yardımcı olur. Nereden alınır? Oracle Advanced Collections içinde açıkça oluşturulur. Oluşturulma tarihi IEX_PROMISE_DETAILS tablosundan alınır. Kaydedin İlgili fatura için IEX_PROMISE_DETAILS tablosundaki oluşturulma tarihi. Olay türü explicit | |||
| Tahsilat sorumlusunun işlemi tamamlandı | Tahsilat sorumlusunun yaptığı telefon görüşmesi, e-posta gönderimi veya etkileşim notu kaydı gibi manuel bir işlemi ifade eder. Bu işlemler, tahsilat modülünde genellikle etkinlik veya etkileşim olarak kaydedilir. | ||
| Neden önemli? Tahsilat sorumlularının işlemlerini izlemek, manuel tahsilat iş akışının verimliliğini ve etkinliğini ölçmeye yardımcı olur. Etkinlik sıklığını ve bunun ödeme başarısıyla ilişkisini analiz etmenizi sağlar. Nereden alınır? Oracle Advanced Collections içindeki JTF_IH_ACTIVITIES gibi etkileşim veya etkinlik geçmişi tablolarından alınır. Müşteriyle ve gerektiğinde ilgili faturayla ilişkilendirilir. Kaydedin JTF_IH_ACTIVITIES içindeki ilgili sonuç veya neden koduna sahip kayıtların oluşturulma zaman damgası. Olay türü explicit | |||
| Tahsilat stratejisi atandı | Vadesi geçmiş faturaya veya müşteriye otomatik bir tahsilat stratejisi atandığında gerçekleşir. Bu strateji, sistemin veya tahsilat sorumlusunun izleyeceği adımları ve etkinlikleri belirler. | ||
| Neden önemli? Bu olay, tahsilat sürecinin ne ölçüde otomatikleştirildiğini gösterir. Atanan stratejileri ve sonuçlarını analiz etmek, farklı müşteri grupları için tahsilat yöntemlerini iyileştirmeye yardımcı olur. Nereden alınır? Oracle Advanced Collections modülünde kaydedilir. Genellikle IEX_STRATEGIES gibi tablolardaki veya ilişkili nesnelerdeki strateji atama kaydının oluşturulma tarihi incelenerek bulunur. Kaydedin Müşteriyle veya işlemle ilişkilendirilmiş tahsilat tablolarındaki strateji iş öğesinin oluşturulma tarihi. Olay türü explicit | |||
Veri çıkarma rehberleri
Adımlar
- Oracle BI Publisher’a erişin: Oracle Fusion Financials ortamınızda oturum açın. Navigator simgesine tıklayın, ardından Tools > Reports and Analytics’i seçerek Reports and Analytics alanına gidin.
- Yeni bir veri modeli oluşturun: Reports and Analytics bölmesinde 'Browse Catalog' düğmesine tıklayın. Katalogda 'New' açılır menüsüne tıklayın ve 'Data Model’i seçin.
- SQL Query Veri Seti’ni tanımlayın: Data Model düzenleyicisinde '+' simgesine tıklayarak yeni bir Veri Seti ekleyin ve 'SQL Query’yi seçin.
- Veri kaynağını yapılandırın: Yeni Veri Seti penceresinde Veri Setinize açıklayıcı bir ad verin; örneğin, 'CreditCollectionsEventLog'. Veri kaynağı olarak 'FSCM’yi veya uygun Oracle Fusion uygulama veritabanını seçin. SQL türünü 'Standard SQL' olarak ayarlayın.
- SQL sorgusunu girin: Bu belgenin 'query' bölümünde verilen SQL sorgusunun tamamını kopyalayıp SQL Query metin alanına yapıştırın.
- Sorgu parametrelerini tanımlayın: Sorgu, tarih aralığını filtrelemek için
:P_START_DATEve:P_END_DATEgibi parametreler kullanır. BI Publisher bunları otomatik olarak algılar. Veri türlerini 'Date' olarak ayarlayıp kullanıcı istemi şeklinde yapılandırabilirsiniz. - Veri modelini kaydedip test edin: Veri modelini paylaşılan veya özel bir klasöre kaydedin. Sorgunun çalıştığını doğrulamak için 'Data' sekmesine gidin, örnek parametre değerleri girin (örneğin, yakın tarihli bir aralık) ve örnek çıktıyı görmek için 'View’a tıklayın. Tüm sütunların doğru göründüğünü kontrol edin.
- Yeni bir rapor oluşturun: Kataloğa geri dönün, 'New' açılır menüsüne tıklayın ve 'Report’u seçin. 'Create Report' iletişim kutusunda 'Use Data Model' seçeneğini belirleyin ve az önce kaydettiğiniz veri modelini bulun.
- Rapor özelliklerini yapılandırın: Rapor düzenleyicisinde veri çıkarmak için basit bir tablo düzeni yeterlidir. Varsayılan çıktı biçimini ayarlayın. Process Mining için CSV önerilir. Bunun için 'View a List’e tıklayın, 'Output Formats' listesinde 'CSV’yi bulun ve kutusunu işaretleyin. Kullanımı kolaylaştırmak için diğer biçimlerin işaretini kaldırabilirsiniz.
- Raporu kaydedin: Raporu veri modelinizle aynı klasöre kaydedin.
- Veri çıkarımını zamanlayın: Çıkarımı otomatikleştirmek için raporu zamanlayabilirsiniz. Raporu açın, 'Actions’a tıklayın ve 'Schedule’ı seçin. Zamanlama sıklığını (örneğin, günlük) yapılandırın, çıktı biçimini CSV olarak belirleyin ve içerik sunucusu dizini ya da FTP üzerinden harici bir sunucu gibi teslim hedefini tanımlayın.
Yapılandırma
- Ön koşullar: Raporu oluşturan ve çalıştıran kullanıcının uygun BI rollerine (örneğin, 'BI Administrator' veya 'BI Author') ve temel Financials tablolarına (AR, IEX, HZ, JTF) erişmek için veri güvenliği izinlerine sahip olması gerekir.
- Veri kaynağı: Sorgu, genellikle 'FSCM' olarak adlandırılan ana uygulama veritabanında çalıştırılmalıdır.
- Tarih aralığı parametreleri: Veri hacmini sınırlamak için
:P_START_DATEve:P_END_DATEparametrelerini kullanmanız önemlidir. İlk testte bir ay gibi kısa bir aralık seçin. Üretim çalıştırmalarında genellikle 3 ila 6 aylık hareketli bir dönem kullanılır. - Filtreleme: Büyük kuruluşlarda, verileri her seferinde tek bir iş birimi için işlemek üzere
invoices_baseortak tablo ifadesindekiWHEREkoşulunaBU_NAME(İş birimi adı) parametresini eklemeyi değerlendirin. - Performansla ilgili noktalar: Sorgu, büyük işlem tablolarını birleştirir. Geniş bir tarih aralığında filtresiz çalıştırılması, BI Publisher’da uzun çalışma sürelerine veya zaman aşımına neden olabilir. Raporu yoğun olmayan saatlerde çalışacak şekilde zamanlayın.
- Çıktı biçimi: Varsayılan veya zamanlanmış çıktı biçiminin CSV olduğundan emin olun. Bu biçim, Process Mining araçlarının kolayca kullanabileceği, alanları ayrılmış bir dosya sunar. Ayırıcı ve karakter kodlamasının doğru ayarlandığını doğrulamak için CSV çıktı özelliklerini kontrol edin.
a Örnek sorgu sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Başlamaya hazır mısınız?
Verilerinizi analize hazırlamak ve kredi yönetimi ile tahsilat süreciniz hakkında değerli bilgiler edinmek için bu Templatei kullanın. Süreçlerinizi optimize etmeye bugün başlayın.
Kredi yönetimi ve tahsilat süreçlerinizi bugün optimize etmeye başlayın
Oracle Fusion’da çevrim süresini %30 azaltın ve finansal sağlığınızı iyileştirin.
Kredi kartı gerekmez. Dakikalar içinde başlayın.