Kredi Yönetimi ve Tahsilat Veri Şablonunuz
Kredi Yönetimi ve Tahsilat Veri Şablonunuz
- Kapsamlı analiz için önerilen özellikler
- Süreç keşfi için izlenecek temel faaliyetler
- Adım adım veri çıkarma rehberliği
Kredi Yönetimi ve Tahsilat Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet Adı ActivityName | Kredi yönetimi süreci içinde belirli bir zamanda gerçekleşen iş olayı veya görevin adı. | ||
| Açıklama Bu öznitelik, fatura yaşam döngüsündeki 'Fatura Oluşturuldu', 'İhtar Prosedürü Başlatıldı' veya 'Ödeme Alındı' gibi tek bir adımı tanımlar. Her etkinlik, vakayı ileriye taşıyan ayrı bir olayı temsil eder. Etkinliklerin sırasını ve sıklığını analiz etmek, Process Mining'in özüdür. Gerçek süreç akışını ortaya çıkarmaya, vakaların takıldığı darboğazları belirlemeye, etkinliklerin tekrarlandığı yeniden işleme döngülerini tespit etmeye ve gerçek süreci tasarlanan veya 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 temeldir. Neden önemli Bu öznitelik, süreç haritasındaki adımları tanımlayarak, fatura yaşam döngüsünün baştan sona görselleştirilmesini ve analizini sağlar. Nereden alınır Bu, Oracle Fusion Financials içindeki çeşitli iş olaylarından türetilmiş kavramsal bir alandır, genellikle Alacaklar (AR) ve Advanced Collections gibi modüllerden işlem durumları, olay tarihleri veya belirli eylemler eşleştirilerek oluşturulur. Örnekler Fatura Oluşturulduİhtar Prosedürü BaşlatıldıÖdeme Alındıİtiraz Kaydedildi | |||
| Fatura Numarası InvoiceNumber | Her müşteri faturası için kredi yönetimi sürecinin birincil vaka tanımlayıcısı olarak hizmet veren benzersiz tanımlayıcı. | ||
| Açıklama Fatura Numarası, tek bir alacakla ilgili tüm olayları ve etkinlikleri, oluşturulmasından nihai mutabakatına veya iptaline kadar birbirine bağlayan merkezi anahtardır. Fatura yaşam döngüsünün eksiksiz, uçtan uca bir görünümünü sağlar. Process Mining analizinde, bu öznitelik her faturanın yolculuğunu yeniden yapılandırmak için kullanılır. Tüm ilgili etkinlikleri tek bir Fatura Numarası altında gruplandırarak, analistler süreç akışlarını görselleştirebilir, ortak ve sapma gösteren yolları belirleyebilir ve tüm süreç veya anlaşmazlık çözümü veya ödeme kaydı gibi belirli aşamalar için döngü sürelerini ölçebilir. Neden önemli Bu, her faturanın düzenlenmesinden kapanışına kadar olan yolculuğunun yeniden yapılandırılmasını ve analizini sağlayan, ilgili tüm süreç adımlarını birbirine bağlayan temel Vaka Kimliğidir. Nereden alınır Bu tanımlayıcı genellikle Oracle Fusion Financials'taki RA_CUSTOMER_TRX_ALL tablosunda TRX_NUMBER olarak bulunur. Örnekler INV-1005679884321AR-2023-04-112 | |||
| Olay Zamanı EventTime | Etkinliğin gerçekleştiği kesin tarih ve saat, olayın zaman damgası olarak hizmet eder. | ||
| 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 olarak sıralamak esastır. Doğru zaman damgaları olmadan, olayların sırası doğru bir şekilde belirlenemez. Analizde, bu öznitelik, performans ölçümü için kritik olan etkinlikler arasındaki süreleri ve döngü sürelerini hesaplamak için kullanılır. Örneğin, Anlaşmazlık Çözüm Döngü Süresi veya Fatura Ödeme Döngü Süresi gibi KPI'ları hesaplamak için kullanılır. Ayrıca, farklı zaman dilimlerinde süreç performans eğilimlerinin analiz edilmesini de sağlar. Neden önemli Bu zaman damgası, olayları sıralamak, döngü sürelerini ve süreleri hesaplamak ve zaman içindeki süreç performansını analiz etmek için esastır. Nereden alınır RA_CUSTOMER_TRX_ALL'daki TRX_DATE gibi Oracle Fusion Financials tablolarındaki çeşitli tarih alanlarından veya bir tahsilat eyleminin oluşturulma tarihinden türetilir. Örnekler 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Kaynak Sistem SourceSystem | Verilerin kaynaklandığı sistem. | ||
| Açıklama Bu öznitelik, olay verilerinin kaydedildiği kaynak uygulamayı tanımlar. Karmaşık bir BT ortamında, tek bir uçtan uca süreçte birden fazla sistem yer alabilir. Kaynak sistemi belirtmek, veri yönetimi, sorun giderme ve verilerin bağlamını anlamak için önemlidir. Farklı sistemlerden gelen olayların tek bir süreç görünümünde birleştirilmesi durumunda, veri soy ağacının net olmasını sağlayarak olayları ayırt etmeye yardımcı olur. Neden önemli Veri doğrulama, yönetişim ve sürecin teknolojik bağlamını anlamak için çok önemli olan veri kökeni hakkında netlik sağlar. Nereden alınır Bu, genellikle kayıtların kaynağını belirlemek için veri çıkarma sırasında eklenen statik bir değerdir. Örnekler Oracle Fusion FinancialsOracle AROracle Collections | |||
| Son Veri Güncellemesi LastDataUpdate | Bu event'e ait verinin en son ne zaman yenilendiğini veya kaynak sistemden çıkarıldığını gösteren timestamp. | ||
| Açıklama Bu öznitelik, en son veri çıkarma işleminin tarihini ve saatini işaretler. İş sürecinin kendisinin bir parçası olmayan ancak analiz edilen verilerin güncelliğini anlamak için kritik olan bir meta veri alanıdır. Analistler bu zaman damgasını, güncel bilgilerle çalıştıklarını doğrulamak ve verilerin kesme noktasını anlamak için kullanır. Veri yönetimi ve Dashboard'lar ve raporlardaki veri güncelliği hakkındaki kullanıcı beklentilerini yönetmek için esastır. Neden önemli Verinin güncelliğini gösterir, analistlerin ve paydaşların verinin zamanlaması ve uygunluğu hakkında bilgi sahibi olmasını sağlar. Nereden alınır Bu değer, veri çıkarma ve yükleme (ETL) süreci sırasında her kayda oluşturulur ve damgalanır. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Fatura Tutarı InvoiceAmount | Faturanın toplam tutarıdır. | ||
| Açıklama Fatura Tutarı, müşteriye fatura edilen mal veya hizmetlerin toplam değerini temsil eder. Bu, sürecin parasal etkisini anlamak için kritik bir finansal özniteliktir. Analizde, Fatura Tutarı tahsilat çabalarını önceliklendirmek, yüksek değerli gecikmiş faturalara odaklanmak için kullanılır. Ayrıca işlem değerine dayalı ödeme davranışlarını analiz etmek ve iptallerin finansal etkisini hesaplamak için de kullanılır. Fatura İptal Oranı Analizi gibi Dashboard'lar, finansal kayıpların büyüklüğünü değerlendirmek için bu değere dayanır. Neden önemli Sürece finansal bağlam sağlayarak, yüksek değerli faturaların önceliklendirilmesini ve süreç verimsizliklerinin parasal etkisinin analiz edilmesini sağlar. Nereden alınır Bu bilgi, bir fatura için ödenecek tutarı saklayan AR_PAYMENT_SCHEDULES_ALL tablosundan türetilebilir. Örnekler 5000.001250.75250000.00 | |||
| İhtar Seviyesi DunningLevel | Faturaya uygulanan ihtar prosedürünün aşaması veya seviyesi. | ||
| Açıklama İhtar Seviyesi, tahsilat hatırlatıcısının yoğunluğunu gösterir ve bu yoğunluk genellikle zamanla artar. Örneğin, Seviye 1 nazik bir e-posta hatırlatıcısı olabilirken, Seviye 3 resmi bir mektup veya telefon araması olabilir. Süreci İhtar Seviyesine göre analiz etmek, ihtar stratejisinin etkinliğini değerlendirmeye yardımcı olur. İhtar Etkinliği Dashboard'ı, her ihtar adımından ödemeye dönüşüm oranlarını görselleştirmek için bu özniteliği kullanır. Bu, işletmenin hangi ihtar eylemlerinin en etkili olduğunu belirlemesine ve tahsilatları en üst düzeye çıkarmak için hatırlatıcıların zamanlamasını ve içeriğini ayarlamasına olanak tanır. Neden önemli İhtar stratejisinin etkinliğini değerlendirmek için kritik olan tahsilat çabalarının aşamalandırılmasını takip eder. Nereden alınır Bu veri, Oracle Advanced Collections modülü içinde yönetilir. IEX_DUNNINGS gibi ihtar geçmişiyle ilgili tablolarda bulunabilir. Örnekler Seviye 1: HatırlatmaSeviye 2: UyarıSeviye 3: Son Uyarı | |||
| Kullanıcı User | Etkinliği gerçekleştiren kullanıcı veya sistem kimliği. | ||
| Açıklama Bu öznitelik, kredi limitini onaylama, ödeme kaydetme veya anlaşmazlığı çözme gibi bir etkinliği yürütmekten sorumlu belirli çalışanı veya otomatik sistem kullanıcısını tanımlar. Etkinlikleri kullanıcıya göre analiz etmek, iş yükü dağılımını, bireysel performansı ve uyumluluğu anlamak için esastır. Otomatik etkinlikler için, sistem süreçlerinin katılımını izlemeye yardımcı olur. Ayrıca, kullanıcı davranışını izleyerek eğitim ihtiyaçlarını veya potansiyel dolandırıcılık faaliyetlerini belirlemek için de kullanılabilir. Neden önemli Süreç faaliyetlerini belirli kişilere veya otomatik sistemlere atfederek performans takibini, iş yükü analizini ve denetimi mümkün kılar. Nereden alınır Oracle Fusion Financials'taki çeşitli işlem ve geçmiş tablolarındaki 'CREATED_BY' veya 'LAST_UPDATED_BY' sütunlarından alınır. Örnekler jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Müşteri Numarası CustomerNumber | Faturayla ilişkili müşteri için benzersiz bir tanımlayıcı. | ||
| Açıklama Müşteri Numarası, bir faturayı belirli bir müşteri hesabına bağlar. Bu, müşteri özniteliklerine dayalı olarak kredi ve tahsilat sürecinin segmentasyonunu ve analizini sağlar. Müşteri Numarası'nı dahil ederek, analistler belirli müşterilerin sürekli geç ödeme yapıp yapmadığını, daha fazla anlaşmazlık çıkarıp çıkarmadığını veya daha fazla tahsilat çabası gerektirip gerektirmediğini araştırabilir. Bu bilgi, müşteriye özel tahsilat stratejileri oluşturmak, kredi koşullarını ayarlamak ve yüksek riskli müşteri segmentlerini belirlemek için hayati önem taşır. Müşteri Segmentine Göre Fatura İptal Oranı Analizi gibi analizleri doğrudan destekler. Neden önemli Sürecin müşteriye göre segmentasyonunu sağlayarak, özel tahsilat stratejileri için desenleri, riskleri ve fırsatları belirlemeye yardımcı olur. Nereden alınır Genellikle RA_CUSTOMER_TRX_ALL tablosunda, HZ_CUST_ACCOUNTS'a bağlanan BILL_TO_CUSTOMER_ID olarak bulunur. Örnekler CUST-0012389455ACME-CORP-US | |||
| Müşteri Segmenti CustomerSegment | Müşterinin büyüklük, sektör veya stratejik önem gibi tanımlanmış bir gruba sınıflandırılması. | ||
| Açıklama Müşteri Segmenti, müşterileri paylaşılan özelliklere göre gruplayan kategorik bir özniteliktir. Segmentler 'Stratejik', 'KOBİ', 'Kurumsal' gibi faktörlere veya 'Üretim' veya 'Perakende' gibi sektörlere göre tanımlanabilir. Bu öznitelik, karşılaştırmalı analizler için güçlüdür. Analistlerin, örneğin bir segmentin daha yüksek itiraz oranına veya daha uzun ödeme döngüsüne sahip olup olmadığını görmek için farklı segmentler arasındaki süreç performansını karşılaştırmasına olanak tanır. Bu içgörü, Kredi Kayıttan Düşme Oranı Analizi gibi Dashboard'ları destekleyerek kredi politikalarının ve tahsilat stratejilerinin her segmentin özel ihtiyaçlarına ve risklerine göre uyarlanmasına yardımcı olur. Neden önemli Süreç performansının ve risklerin farklı müşteri grupları arasında nasıl değiştiğini ortaya koyan güçlü karşılaştırmalı analizlere olanak tanır. Nereden alınır Genellikle müşteri ana verilerinde (HZ_CUST_ACCOUNTS veya ilgili tablolar) yönetilir veya gelir veya sektör gibi müşteri özniteliklerinden türetilir. Örnekler Büyük KurumsalKüçük ve Orta Ölçekli İşletmelerHükümetStratejik Ortak | |||
| Tahsilatçı Collector | Faturaya atanan tahsilat görevlisinin adı veya kimliği. | ||
| Açıklama Tahsilatçı, gecikmiş bir fatura için tahsilat faaliyetlerini yönetmekten sorumlu kişi veya ekiptir. Bu atama, tahsilat iş akışında önemli bir adımdır. Bu öznitelik, tahsilat departmanındaki performans yönetimi ve kaynak tahsisi için çok önemlidir. Yöneticiler, tahsilatçı başına sonuçları analiz ederek tahsilatçı etkinliğini değerlendirebilir, eğitim ihtiyaçlarını belirleyebilir ve iş yüklerini dengeleyebilir. Tahsilatçı Atama Etkinliği Dashboard'ı, farklı tahsilatçılar arasındaki başarı oranlarını ve döngü sürelerini karşılaştırmak için doğrudan bu özniteliğe dayanır. Neden önemli Bireysel tahsildarların veya ekiplerin performans analizini mümkün kılarak, kaynak tahsisini optimize etmeye ve genel tahsilat verimliliğini artırmaya yardımcı olur. Nereden alınır Bu bilgi genellikle Oracle Advanced Collections modülünde, sıklıkla IEX_CASES_ALL_B veya ilgili atama tablolarında depolanır. Örnekler Can DemirAyşe YılmazTahsilat Ekibi A | |||
| Vade Tarihi DueDate | Fatura ödemesinin vadesinin dolduğu tarih. | ||
| Açıklama Vade Tarihi, ödeme için sözleşmeyle üzerinde anlaşılan kritik bir tarih özniteliğidir. Ödeme zamanlılığının ölçüldüğü temel noktadır. Bu öznitelik, gecikmiş faturaları tanımlamak ve bir faturanın vadesi geçen gün sayısını hesaplamak için temeldir. İhtar prosedürlerinin ne zaman başlatılacağını belirlemek için birincil girdidir ve Days Sales Outstanding (DSO) gibi KPI'ları hesaplamada kullanılır. Ayrıca, ödenmemiş borçları sınıflandıran yaşlandırma raporları oluşturmak için de gereklidir. Neden önemli Bir faturanın vadesi geçmiş olup olmadığını belirlemek, tahsilat faaliyetlerini tetiklemek ve yaşlandırma analizini sağlamak için bir temel görevi görür. Nereden alınır AR_PAYMENT_SCHEDULES_ALL tablosunda DUE_DATE olarak mevcuttur. Örnekler 2023-05-302023-06-152023-07-01 | |||
| Bitiş Saati EndTime | Süresi olan bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası. | ||
| Açıklama Belirgin bir başlangıcı ve sonu olan faaliyetler için bu öznitelik, tamamlanma zamanını yakalar. Süreç madenciliğindeki birçok olay anlık olsa da, 'İtiraz İncelemesi' gibi bazıları belirli bir zaman dilimine yayılabilir. Ayrı bir Bitiş Zamanına sahip olmak, aktivite işleme sürelerinin kesin olarak hesaplanmasını sağlar. Bu, özellikle boşta kalma süreleri olduğunda, süreyi bir sonraki aktivitenin başlangıç zamanından çıkarmaktan daha doğrudur. Kaynak kullanımını analiz etmek ve sürecin hangi belirli adımlarının en çok zaman aldığını belirlemek için çok önemlidir. Neden önemli Belirli faaliyetlerin ne kadar sürdüğünün doğru hesaplanmasını sağlayarak, darboğazlar ve kaynak kullanımı hakkında daha derinlemesine içgörü sunar. Nereden alınır Bu genellikle kavramsal bir özniteliktir. Etkinliğe karşılık gelen kaynak tablolarda 'son güncelleme' zaman damgası 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 konumunun bir anlık görüntüsünü sağlar. Yaygın durumlar arasında 'Açık', 'Ödendi', 'İtiraz Edildi', 'Vadesi Geçmiş' veya 'Kayıttan Düşüldü' bulunur. Bu öznitelik, alacakların durumu hakkında üst düzey bir genel bakış sunar. Süreç madenciliğinde bu öznitelik, tüm açık vadesi geçmiş faturalar gibi belirli popülasyonlara odaklanmak için vakaları filtrelemede kullanışlıdır. Vadesi Geçmiş Fatura Yaşlandırma ve Durum Dashboard'ında önemli bir boyut olup, fatura portföyünün mevcut durumuna anında görünürlük sağlar ve tahsilat faaliyetlerini önceliklendirmeye yardımcı olur. Neden önemli Bir faturanın güncel durumuna hızlı bir genel bakış sağlayarak, tahsilat çabalarının kolayca filtrelenmesini ve önceliklendirilmesini sağlar. Nereden alınır Genellikle AR_PAYMENT_SCHEDULES_ALL tablosunda STATUS adlı bir alanda mevcuttur. Örnekler AçıkKapalıİtiraz EdildiTahsilatta | |||
| Fatura Para Birimi InvoiceCurrency | Fatura tutarının belirlendiği para birimi. | ||
| Açıklama Bu öznitelik, faturanın para birimini belirtir; örneğin USD, EUR veya GBP. Çok uluslu kuruluşlarda, faturalar genellikle çeşitli para birimlerinde düzenlenir. Birden fazla para birimi içeren verileri analiz etmek dikkatli işlem gerektirir. Bu öznitelik, süreç görünümünü para birimine göre filtrelemeye veya konsolide finansal raporlama için doğru döviz kurlarını uygulamaya olanak tanır. Parasal değerlerin doğru yorumlanmasını ve miktarların karşılaştırmalarının benzer temelde yapılmasını sağlar. Neden önemli Çoklu para birimi ortamında finansal verileri doğru yorumlamak ve doğru finansal analizi sağlamak için esastır. Nereden alınır Genellikle RA_CUSTOMER_TRX_ALL tablosunda INVOICE_CURRENCY_CODE olarak bulunur. Örnekler USDEURGBPJPY | |||
| İş Birimi BusinessUnit | Faturayı düzenleyen belirli iş birimi veya organizasyonel varlık. | ||
| Açıklama Büyük kuruluşlarda, operasyonlar genellikle birden fazla iş birimine ayrılır. Bu öznitelik, faturayla hangi iş biriminin ilişkili olduğunu belirler. Süreci İş Birimine göre analiz etmek, organizasyonun farklı bölümleri arasında performans karşılaştırmasına olanak tanır. Kredi ve tahsilat politikalarının nasıl uygulandığındaki tutarsızlıkları vurgulayabilir ve hangi iş birimlerinin alacaklarını yönetmede daha etkili olduğunu ortaya çıkarabilir. Bu, en iyi uygulamaları paylaşmaya ve gerektiğinde süreçleri standartlaştırmaya yardımcı olur. Neden önemli Farklı organizasyonel birimler arasında performans karşılaştırmasına olanak tanır, en iyi uygulamaları ve iyileştirme alanlarını belirlemeye yardımcı olur. Nereden alınır RA_CUSTOMER_TRX_ALL tablosunda, organizasyon yapısına bağlanan ORG_ID alanı aracılığıyla mevcuttur. Örnekler BU North AmericaBU EMEAGlobal Services Division | |||
| İşlem Süresi ProcessingTime | Bir faaliyet üzerinde aktif olarak çalışılan süre. | ||
| Açıklama İşlem süresi, belirli bir görev için bekleme veya boşta kalma süresi hariç, aktif çalışma süresini ölçer. Bir etkinliğin Bitiş Zamanı ile Başlangıç Zamanı arasındaki fark olarak hesaplanır. Bu metrik, bir dava üzerinde aktif olarak çalışılan süre ile başka bir şeyin olmasını bekleyerek geçirilen süreyi ayırt etmeye yardımcı olduğu için performans analizi için çok değerlidir. Örneğin, anlaşmazlığın atanmayı beklediği zamandan ayrı olarak 'Anlaşmazlık Çözümü' etkinliğindeki verimsizlikleri vurgulayabilir. Bu, Tahsilat İş Akışı Verimliliği gibi Dashboard'ları destekler. Neden önemli Etkinliklerin fiili çalışma süresini ölçerek, sadece aralarındaki süreyi değil, belirli görevlerdeki verimsizlikleri belirlemeye yardımcı olur. Nereden alınır Bu, EndTime'dan StartTime'ı çıkararak (EndTime - StartTime) türetilen hesaplanmış bir metriktir. Örnekler 864003600604800 | |||
| Kayıttan Düşüldü IsWrittenOff | Faturanın tahsil edilemeyen alacak olarak kayıtlardan düşülüp düşülmediğini gösteren bir boolean bayrağı. | ||
| Açıklama Bu, şirketin tahsil edilemez olarak değerlendirdiği ve aktif alacaklarından çıkardığı faturaları tanımlayan türetilmiş bir işarettir. Bu genellikle bir fatura için son ve istenmeyen sonuçtur. Bu öznitelik, Fatura İptal Oranı KPI'sını ve ilgili analiz Dashboard'ını hesaplamak için esastır. Analistlerin başarısız tahsilat popülasyonunu izole etmelerine olanak tanır ve müşteri segmenti veya fatura değeri gibi daha yüksek iptal riskiyle ilişkili olabilecek ortak özellikleri belirlemelerine yardımcı olur. Bu içgörü, kredi politikalarını ve tahsilat stratejilerini iyileştirmek için kullanılır. Neden önemli Tahsilat başarısızlığı vakalarını açıkça belirler, bu da kötü alacakların temel nedenlerini analiz etmek ve kayıttan düşme oranlarını hesaplamak için çok önemlidir. Nereden alınır Bu, bir davanın 'Fatura İptal Edildi' etkinliğinin olup olmadığını veya fatura durumunun 'İptal Edildi' olup olmadığını kontrol ederek türetilen hesaplanmış bir alandır. Örnekler truefalse | |||
| Kredi Limiti Miktarı CreditLimitAmount | Müşteri için onaylanan maksimum kredi miktarı. | ||
| Açıklama Kredi Limiti Tutarı, bir şirketin belirli bir müşteriyle sahip olmaya istekli olduğu toplam kredi riskidir. Bu, kredi inceleme süreci sırasında belirlenir. Bu öznitelik, Kredi Limiti Karar Etkisi Dashboard'ı için gereklidir. Onaylanan kredi limitini sonraki ödeme davranışları ve iptallerle ilişkilendirerek, işletme kredi risk politikalarının etkinliğini değerlendirebilir. Analiz, aşırı yüksek kredi limitlerinin daha yüksek şüpheli alacak oranlarına katkıda bulunup bulunmadığını ortaya çıkarabilir ve kredi onay sürecini iyileştirmeye yardımcı olabilir. Neden önemli Onaylanmış kredi limitini ödeme sonuçları ve kayıttan düşmelerle ilişkilendirerek kredi riski politikalarının etkinliğini değerlendirmek için çok önemlidir. Nereden alınır Bu, Oracle Credit Management'ta yönetilir ve genellikle HZ_CUST_PROFILE_AMTS gibi müşteri kredi profilleriyle ilgili tablolarda depolanır. Örnekler 10000.0050000.00250000.00 | |||
| Ödeme Sözü Tarihi PromiseToPayDate | Bir müşterinin ödeme yapmayı taahhüt ettiği tarih. | ||
| Açıklama Tahsilat faaliyetleri sırasında, bir müşteri gelecekte bir ödeme yapma taahhüdünde bulunabilir. Bu 'Ödeme Sözü Tarihi', bu taahhüdü izlemek için kaydedilir. Bu öznitelik, tahsilat iş akışlarını yönetmek ve müşteri taahhütlerinin güvenilirliğini değerlendirmek için önemlidir. Ödeme Sözü Tarihi'ni gerçek Ödeme Alındı tarihiyle karşılaştırarak, tahsildarlar bu sözlerin başarı oranını değerlendirebilirler. Bu, nakit akışını daha doğru tahmin etmeye ve bir sözün bozulması durumunda tahsilat çabalarını ne zaman artıracağına karar vermeye yardımcı olur. Neden önemli Müşteri ödeme taahhütlerini takip ederek, nakit girişlerini tahmin etmeye ve tahsilat müzakerelerinin etkinliğini yönetmeye yardımcı olur. Nereden alınır Oracle Advanced Collections modülü içinde, muhtemelen IEX_PROMISES_T gibi tablolarda depolanır. Örnekler 2023-06-102023-06-252023-07-05 | |||
| Ödeme Vadeleri PaymentTerms | Ödemenin ne zaman yapılacağını belirten üzerinde anlaşılmış koşullar. | ||
| Açıklama Ödeme Koşulları, bir müşterinin örneğin 'Net 30' veya 'Net 60' gibi hangi koşullar altında ödeme yapmasının beklendiğini tanımlar. Bu koşullar fatura son ödeme tarihini hesaplamak için kullanılır. Ödeme koşullarına göre ödeme performansını analiz etmek ilginç kalıpları ortaya çıkarabilir. Örneğin, daha kısa süreli müşteriler gecikmeli ödeme yapmaya daha yatkın olabilir. Bu bilgi, kredi politikalarını gözden geçirmek ve optimize etmek, ayrıca farklı tahsilat stratejileri için müşterileri segmentlere ayırmak için kullanılabilir. Belirli faturaların neden geciktiğini anlamak için değerli bir bağlam sağlar. Neden önemli Farklı kredi koşullarında ödeme davranışının analiz edilmesini sağlayarak, üzerinde anlaşılan ödeme takvimi hakkında bağlam sağlar. Nereden alınır Bu, RA_TERMS tablosunda depolanır ve fatura işlemine bağlanır. Örnekler Net 30 GünNet 60 GünTeslimatta Ödenecek | |||
| Uyuşmazlık Nedeni DisputeReason | Müşteri tarafından bir faturaya itiraz etmek için verilen neden. | ||
| Açıklama Bir müşteri faturaya itiraz ettiğinde, genellikle 'Yanlış Fiyatlandırma', 'Hasarlı Ürünler' veya 'Yinelenen Fatura' gibi bir neden belirtir. Bu öznitelik bu nedeni yakalar. Anlaşmazlık nedenlerini analiz etmek, temel neden analizinin anahtarıdır. Ödeme gecikmelerine yol açan sipariş yönetimi veya faturalandırma gibi yukarı akış süreçlerindeki tekrarlayan sorunları belirlemeye yardımcı olur. Farklı anlaşmazlık nedenlerinin sıklığını kategorize ederek ve takip ederek, bir işletme bu temel nedenleri düzeltmek için hedefe yönelik eylemler yapabilir, bu da Anlaşmazlık Çözüm Döngü Süresini kısaltma hedefini destekler. Neden önemli Fatura itirazlarının temel nedenlerini belirlemeye yardımcı olur, gelecekteki itirazları önlemek için yukarı akış süreçlerinde proaktif iyileştirmeler yapılmasını sağlar. Nereden alınır Bu bilgi genellikle anlaşmazlık yönetimi resmileştirildiyse Oracle Advanced Collections veya Oracle Channel Revenue Management modüllerinde yakalanır. AR_DISPUTE_HISTORY gibi tablolarda bulunabilir. Örnekler Yanlış MiktarFiyat FarkıHasarlı MallarHizmet Verilmedi | |||
| Vadesi Geçmiş Günler DaysOverdue | Bir faturanın son ödeme tarihinden sonra geçen gün sayısı. | ||
| Açıklama Bu hesaplanan metrik, ödenmemiş bir faturanın ne kadar geciktiğini niceliksel olarak belirler. Mevcut tarih (açık faturalar için) veya ödeme tarihi (kapalı faturalar için) ile vade tarihi arasındaki fark olarak hesaplanır. Gecikmiş Günler, yaşlandırma analizi ve tahsilat çabalarını önceliklendirmek için kritik bir ölçüttür. Faturaların yaşlandırma gruplarına (örn. 1-30 gün, 31-60 gün) ayrıldığı Gecikmiş Fatura Yaşlandırma ve Durum Dashboard'ının birincil metriğidir. Bu, tahsilat ekibinin en eski ve en yüksek riskli borçlara odaklanmasına yardımcı olur. Neden önemli Ödeme gecikmelerinin boyutunu niceliksel olarak belirleyerek, tahsilatları önceliklendirmek ve yaşlandırma analizi yapmak için temel bir metrik olarak hizmet eder. Nereden alınır Bu hesaplanmış bir alandır. Mantığı şudur: Açık faturalar için Güncel Tarih - Vade Tarihi veya kapalı faturalar için Ödeme Tarihi - Vade Tarihi. Örnekler 1545920 | |||
| Vadesi Geçti mi? IsOverdue | Faturanın ödeme vadesinin geçip geçmediğini gösteren bir boolean bayrağı. | ||
| Açıklama Bu, bir faturanın gecikmiş durumuna ilişkin basit bir doğru veya yanlış göstergesi sağlayan türetilmiş bir özniteliktir. Genellikle mevcut tarih (veya ödeme tarihi) ile faturanın vade tarihini karşılaştırarak hesaplanır. Bu işaret, analizde filtreleme ve segmentasyon için son derece kullanışlıdır. Analistlerin gecikmiş faturaların popülasyonunu hızlı bir şekilde izole etmelerine, süreç yollarını, tahsilat faaliyetlerinin etkinliğini ve diğer özelliklerini incelemelerine olanak tanır. Gecikmiş Borç Yaşlandırma ve Durum Dashboard'ı gibi Dashboard'ların oluşturulmasını basitleştirir. Neden önemli Tahsilat sürecinin birincil odağı olan tüm gecikmiş faturaları tanımlamak ve analiz etmek için basit ve net bir işaret sağlar. Nereden alınır Bu hesaplanmış bir alandır. Mantığı şudur: Eğer Güncel Tarih > Vade Tarihi VE Durum != 'Ödendi' ise DOĞRU, aksi takdirde YANLIŞ. Örnekler truefalse | |||
Kredi Yönetimi ve Tahsilat Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura Oluşturuldu | Oracle Fusion Financials'ta fatura işlem kaydının oluşturulmasını işaret eder. Bu, fatura yaşam döngüsünün alacaklar modülündeki resmi başlangıcıdır ve analiz için birincil başlangıç noktası olarak hizmet eder. | ||
| Neden önemli Bu, fatura yolculuğu için kritik başlangıç olayıdır. Days Sales Outstanding (DSO) ve fatura ödeme döngü süresi gibi tüm sonraki döngü süresi hesaplamaları bu ilk zaman damgasına bağlıdır. Nereden alınır Bu, belirli bir TRX_NUMBER (Fatura Numarası) için RA_CUSTOMER_TRX_ALL tablosundaki CREATION_DATE veya TRX_DATE sütunundan yakalanan açık bir olaydır. Yakala Olay zaman damgası, RA_CUSTOMER_TRX_ALL tablosundaki CREATION_DATE'dir. Event tipi explicit | |||
| Fatura Silindi | Tahsilat çabalarını durdurma ve fatura tutarını şüpheli alacak olarak kabul etme resmi kararını temsil eder. Bu, fatura bakiyesini sıfıra ayarlayan açık bir finansal işlemdir. | ||
| Neden önemli Bu, tahsilat süreci için kritik bir başarısızlık bitiş noktasıdır. Müşteri segmenti, bölge veya kredi limitine göre iptalleri analiz etmek, kayıpları en aza indirmek için kredi politikalarını ve tahsilat stratejilerini iyileştirmeye yardımcı olur. Nereden alınır RECEIVABLES_TRX_ID'si kötü bir alacak veya kayıttan düşme faaliyetini işaret eden AR_ADJUSTMENTS_ALL tablosunda bir düzeltmenin oluşturulmasından açıkça yakalanır. Yakala Kayıttan düşme aktivite tipiyle AR_ADJUSTMENTS_ALL tablosundaki bir kaydın oluşturulma tarihi. Event tipi explicit | |||
| İhtar Prosedürü Başlatıldı | Gecikmiş bir fatura için ihtar sürecinin resmi başlangıcını temsil eder, genellikle ilk resmi ihtar mektubunun gönderilmesini içerir. Bu genellikle bir ihtar toplu işlemi çalıştığında ve faturayı içerdiğinde kaydedilir. | ||
| Neden önemli Bu etkinliği takip etmek, ihtar etkinliğini ve ihtar politikalarına uyumu ölçmek için çok önemlidir. Bir ihtarın ödeme ile sonuçlanmasının ne kadar sürdüğünü ölçmek için bir temel sağlar. Nereden alınır Oracle Advanced Collections modülüne giriş yapıldı. İşlem kimliği ile bağlantılı IEX_DUNNINGS gibi tablolardaki bir ihtar kaydının oluşturulma tarihi bu olayı işaret eder. Yakala Faturayla ilişkili IEX_DUNNINGS tablosundaki kaydın oluşturulma tarihi. Event tipi explicit | |||
| Ödeme Alındı | Bir müşteriden henüz belirli bir faturaya uygulanmamış fonların alındığını işaret eder. Bu, sistemde bir nakit tahsilat işlemi oluşturulduğunda kaydedilir. | ||
| Neden önemli Bu, tahsilat sürecinde nakit alındığını gösteren önemli bir kilometre taşıdır. Bununla ödeme uygulaması arasındaki süre, iç işlem verimliliğinin bir ölçüsüdür. Nereden alınır AR_CASH_RECEIPTS_ALL tablosundaki RECEIPT_DATE'den açıkça yakalanır. Tahsilat daha sonra AR_RECEIVABLE_APPLICATIONS_ALL aracılığıyla uygulandığı faturaya bağlanabilir. Yakala Uygulama tabloları aracılığıyla bağlanan AR_CASH_RECEIPTS_ALL'dan RECEIPT_DATE. Event tipi explicit | |||
| Ödeme Uygulandı | Alınan bir ödemenin belirli bir faturaya uygulanmasını, faturanın ödenmemiş bakiyesini azaltmasını temsil eder. Bu, bir ödemeyi bir faturaya resmi olarak bağlayan adımdır. | ||
| Neden önemli Bu etkinlik, bir faturanın ödendiğini tanımak için kritik öneme sahiptir. Days Sales Outstanding (DSO) hesaplaması ve ödeme kaydı döngüsü için gerçek bitiş noktasıdır. Nereden alınır Bu, bir nakit makbuzunu bir müşteri işlemine (fatura) bağlayan AR_RECEIVABLE_APPLICATIONS_ALL tablosundaki APPLY_DATE'ten yakalanan açık bir olaydır. Yakala İlgili fatura için AR_RECEIVABLE_APPLICATIONS_ALL tablosundaki APPLY_DATE. Event tipi explicit | |||
| Son Ödeme Tarihi Geçti | Mevcut tarihin, fatura tamamen ödenmeden, faturanın vadesini geçtiği zaman meydana gelen hesaplanmış bir olaydır. Bu olay, bir faturanın 'mevcut' durumdan 'vadesi geçmiş' duruma geçişini işaretler. | ||
| Neden önemli Bu, tahsilat ve ihtar süreçlerini tetikleyen önemli bir kilometre taşıdır. Vade tarihini aşan faturaların hacmini ve değerini analiz etmek, işletme sermayesini yönetmek ve kredi riskini değerlendirmek için esastır. Nereden alınır Bu olay, sistemin mevcut tarihi ile AR_PAYMENT_SCHEDULES_ALL tablosundaki 'OP' (Açık) durumlu faturalar için DUE_DATE karşılaştırılarak hesaplanır. Yakala Hesaplanmış olay: SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE olduğunda gerçekleşir. Event tipi calculated | |||
| Fatura Kapatıldı | Faturanın ödenmemiş bakiyesi ödeme, kredi notu uygulaması veya ayarlama yoluyla sıfırlandığında meydana gelir. Bu, fatura yaşam döngüsünün başarılı bir şekilde tamamlandığını işaret eder. | ||
| Neden önemli Bu olay, süreç için birincil başarılı bitiş noktası olarak hizmet eder. Faturaların kapatılmasını izlemek, alacak portföyünün genel sağlığını anlamak için temeldir. Nereden alınır AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS'un 'CL' (Kapalı) olarak değiştiği bir durum değişikliğinden çıkarılır. Zaman damgası, bu değişikliğin LAST_UPDATE_DATE'idir. Yakala Fatura için AR_PAYMENT_SCHEDULES_ALL.STATUS 'CL' olduğunda tespit edin. Event tipi inferred | |||
| İhtilaf Çözüldü | Kayıtlı bir itirazın incelendiğini ve bir çözüme ulaşıldığını gösterir. Bu, faturanın itirazlı durumu kaldırıldığında yakalanır. | ||
| Neden önemli Bu olay, anlaşmazlık çözüm döngüsünün sonunu işaret eder. 'Anlaşmazlık Kaydedildi' ile bu olay arasındaki süre, operasyonel verimliliği ve nakit akışı üzerindeki etkisini ölçmek için temel bir KPI'dır. Nereden alınır AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS, bir kredi notu veya düzeltme sonrası 'DS' (İtiraz Edilmiş) durumundan 'OP' (Açık) veya 'CL' (Kapalı) durumuna değiştiğinde çıkarılır. Yakala AR_PAYMENT_SCHEDULES_ALL.STATUS 'DS' durumundan başka bir duruma değiştiğinde tespit edin. Event tipi inferred | |||
| İtiraz Kaydedildi | Müşterinin faturaya kısmen veya tamamen resmi olarak itiraz ettiğini gösterir. Bu genellikle faturanın ödeme planındaki bir durum değişikliği ile yakalanır. | ||
| Neden önemli Bu etkinlik, anlaşmazlık çözüm sürecinin başlangıç noktasıdır. Kayıttan çözüme kadar geçen süreyi analiz etmek, nakit tahsilatını geciktiren darboğazları belirlemek için kritiktir. Nereden alınır AR_PAYMENT_SCHEDULES_ALL tablosundaki STATUS alanının 'DS' (İtiraz Edilmiş) olarak değiştiği bir durum değişikliğinden çıkarılır. Zaman damgası, denetim tablolarından veya son güncelleme tarihinden alınabilir. Yakala Fatura için AR_PAYMENT_SCHEDULES_ALL.STATUS 'DS' durumuna değiştiğinde tespit edin. Event tipi inferred | |||
| Kredi İncelemesi Tamamlandı | Faturayla ilişkili müşteri için bir kredi değerlendirmesinin tamamlanmasını temsil eder. Bu olay genellikle fatura oluşturma tarihini o müşteri hesabı için en son kredi incelemesi tamamlanma tarihine bağlayarak çıkarılır ve krediyle ilgili analiz için bir temel sağlar. | ||
| Neden önemli Kredi incelemesinden siparişin verilmesine kadar geçen süreyi analiz etmek, siparişten nakite döngüsünün ilk aşamalarındaki gecikmeleri belirlemeye yardımcı olur. Kredi Onay Süresi KPI'ını ölçmek ve kredi kararı etkisini anlamak için temel teşkil eder. Nereden alınır Faturadaki müşteri için HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE sorgulanarak çıkarılır (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Olay zaman damgası, faturanın CREATION_DATE'inden önceki LAST_CREDIT_REVIEW_DATE'dir. Yakala Faturayı, müşteri için fatura oluşturulmadan önceki en son kredi inceleme tarihiyle bağlayın. Event tipi inferred | |||
| Müşteriye Fatura Gönderildi | Faturanın müşteriye elektronik olarak veya yazılı olarak resmi olarak teslim edildiğini gösterir. Bu olay, bir teslimat modülü tarafından açıkça kaydedilebilir veya fatura basım tarihinden çıkarılabilir. | ||
| Neden önemli Bu etkinlik, müşterinin ödeme vadesi süresinin başlangıcını işaret eder. Bunu takip etmek, gecikmiş günleri doğru bir şekilde hesaplamaya ve fatura oluşturma ile müşteri bildirimi arasındaki gecikmeleri analiz etmeye yardımcı olur. Nereden alınır RA_CUSTOMER_TRX_ALL tablosundaki LAST_PRINTED_DATE alanından yakalanabilir. Alternatif olarak, e-posta teslim sistemleri veya diğer iletişim platformlarıyla entegrasyon günlüklerinden çıkarılabilir. Yakala RA_CUSTOMER_TRX_ALL'dan LAST_PRINTED_DATE veya bir teslimat log'undan durumu kullanın. Event tipi inferred | |||
| Ödeme Taahhüdü Oluşturuldu | Sistemde kayıtlı, bir müşterinin belirli bir tarihte ödeme yapmayı taahhüt ettiği resmi bir anlaşmayı temsil eder. Bu, tahsilat faaliyetlerinin önemli bir sonucudur. | ||
| Neden önemli Ödeme taahhütlerini ve bunların yerine getirme oranlarını takip etmek, tahsilatçılar için temel bir performans göstergesidir. Gecikmiş alacaklardan nakit akışını tahmin etmeye ve tahsilatçı etkinliğini değerlendirmeye yardımcı olur. Nereden alınır Oracle Gelişmiş Tahsilatlar'da açıkça oluşturulur. Oluşturulma tarihi IEX_PROMISE_DETAILS tablosundan yakalanır. Yakala İlgili fatura için IEX_PROMISE_DETAILS tablosundan oluşturulma tarihi. Event tipi explicit | |||
| Tahsilat Stratejisi Atandı | Gecikmiş faturaya veya müşteriye otomatik bir tahsilat stratejisi atandığında meydana gelir. Bu, sistemin veya tahsilatçının izleyeceği adım ve etkinlik serisini tanımlar. | ||
| Neden önemli Bu olay, tahsilat sürecinin otomasyonuna ilişkin içgörü sağlar. Hangi stratejilerin atandığını ve sonuçlarını analiz etmek, farklı müşteri segmentleri için tahsilat yaklaşımlarını optimize etmeye yardımcı olur. Nereden alınır Oracle Advanced Collections modülünde oturum açıldı. Bu olay genellikle IEX_STRATEGIES veya ilgili nesneler gibi tablolarda bir strateji atamasının oluşturulma tarihine bakılarak bulunur. Yakala Müşteriye veya işleme bağlı tahsilat tablolarındaki strateji iş öğesinin oluşturulma tarihi. Event tipi explicit | |||
| Tahsildar Eylemi Tamamlandı | Bir tahsilatçı tarafından telefon araması yapmak, e-posta göndermek veya etkileşim notu kaydetmek gibi manuel bir eylemi temsil eder. Bunlar tahsilat modülü içinde 'etkinlik' veya 'etkileşim' olarak kaydedilir. | ||
| Neden önemli Tahsilatçı eylemlerini izlemek, manuel tahsilat iş akışının verimliliğini ve etkinliğini ölçmeye yardımcı olur. Etkinlik sıklığının ve bunun ödeme başarısıyla korelasyonunun analiz edilmesine olanak tanır. Nereden alınır JTF_IH_ACTIVITIES gibi Oracle Gelişmiş Tahsilatlar'daki etkileşim veya aktivite geçmişi tablolarından, müşteriye ve potansiyel olarak belirli faturaya bağlı olarak yakalanır. Yakala JTF_IH_ACTIVITIES'deki ilgili bir sonuç veya neden koduyla kayıtların oluşturulma zaman damgası. Event tipi explicit | |||
Veri Çekim Kılavuzları
Adımlar
- Oracle BI Publisher'a Erişin: Oracle Fusion Financials ortamınıza giriş yapın. Gezgin simgesine tıklayarak Raporlar ve Analizler alanına gidin, ardından Araçlar > Raporlar ve Analizler'i seçin.
- Yeni Bir Veri Modeli Oluşturun: Raporlar ve Analizler panelinde 'Kataloğa Göz At' düğmesine tıklayın. Katalogda, 'Yeni' açılır menüsüne tıklayın ve 'Veri Modeli'ni seçin.
- SQL Sorgu Veri Setini Tanımlayın: Veri Modeli düzenleyicisinde, yeni bir veri seti eklemek için '+' simgesine tıklayın ve 'SQL Sorgusu'nu 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' veya uygun Oracle Fusion uygulama veritabanını seçin. SQL Türünü 'Standart SQL' olarak ayarlayın.
- SQL Sorgusunu Girin: Bu belgenin 'sorgu' bölümünde verilen SQL sorgusunun tamamını kopyalayın ve SQL Sorgu 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ılayacaktır. Bunları kullanıcı istemleri olarak yapılandırabilir, veri tiplerini 'Tarih' olarak ayarlayabilirsiniz. - Veri Modelini Kaydedin ve Test Edin: Veri modelini paylaşılan veya özel bir klasöre kaydedin. Sorgunun çalıştığını doğrulamak için 'Veri' sekmesine gidin, örnek parametre değerleri girin (örn. yakın bir tarih aralığı) ve çıktı verilerinin bir örneğini görmek için 'Görünüm'e tıklayın. Tüm sütunların doğru göründüğünden emin olun.
- Yeni Bir Rapor Oluşturun: Kataloğa geri dönün, 'Yeni' açılır menüsüne tıklayın ve 'Rapor'u seçin. 'Rapor Oluştur' iletişim kutusunda 'Veri Modeli Kullan' seçeneğini seçin ve yeni kaydettiğiniz veri modelini bulun.
- Rapor Özelliklerini Yapılandırın: Rapor düzenleyicisinde, veri çıkarma için basit bir tablo düzeni yeterlidir. Varsayılan çıktı formatını ayarlayın. Süreç madenciliği için CSV önerilen formattır. Bunu yapmak için 'Bir Liste Görüntüle'ye tıklayın, 'Çıktı Formatları' listesinde 'CSV'yi bulun ve kutuyu işaretleyin. Kullanıcı deneyimini basitleştirmek için diğer formatların işaretini kaldırabilirsiniz.
- Raporu Kaydedin: Raporu veri modelinizle aynı klasöre kaydedin.
- Çıkarma İşlemini Zamanlayın: Çıkarma işlemini otomatikleştirmek için raporu zamanlayabilirsiniz. Raporu açın, 'Eylemler'e tıklayın ve 'Zamanla'yı seçin. Zamanlamanın sıklığını (örn. günlük) yapılandırın, çıktı formatını CSV olarak belirtin ve içerik sunucusu dizini veya FTP aracılığıyla harici bir sunucu gibi teslimat hedefini tanımlayın.
Konfigürasyon
- Ön Koşullar: Raporu oluşturan ve çalıştıran kullanıcının, temel Finansal tablolarına (AR, IEX, HZ, JTF) erişim için uygun BI rollerine (örneğin, 'BI Yöneticisi' veya 'BI Yazarı') ve veri güvenlik yetkilerine sahip olması gerekir.
- Veri Kaynağı: Sorgu, genellikle 'FSCM' olarak adlandırılan ana uygulama veritabanına karşı çalıştırılmalıdır.
- Tarih Aralığı Parametreleri: Veri hacmini sınırlamak için
:P_START_DATEve:P_END_DATEparametrelerini kullanmak kritik öneme sahiptir. İlk testler için bir ay gibi küçük bir aralık kullanın. Üretim çalıştırmaları için 3 ila 6 aylık bir sürekli dönem tipiktir. - Filtreleme: Büyük kuruluşlar için,
invoices_baseortak tablo ifadesindekiWHEREmaddesineBU_NAME(İş Birimi Adı) için bir parametre eklemeyi düşünün, böylece veriler bir seferde tek bir iş birimi için işlenebilir. - Performans Hususları: Sorgu, birden fazla büyük işlem tablosunu birleştirir. Geniş bir tarih aralığı için filtreler olmadan çalıştırmak, BI Publisher'da uzun yürütme sürelerine veya zaman aşımlarına yol açabilir. Raporu yoğun olmayan saatlerde çalışacak şekilde zamanlayın.
- Çıktı Formatı: Varsayılan veya zamanlanmış çıktı formatının CSV olduğundan emin olun. Bu, süreç madenciliği araçları tarafından kolayca tüketilebilen temiz, sınırlanmış bir dosya sağlar. Ayırıcı ve karakter kodlamasının doğru ayarlandığından emin olmak 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'