Kredi ve Tahsilat Yönetimi Veri Template'inuz
Kredi ve Tahsilat Yönetimi Veri Template'inuz
- Detaylı analiz için önerilen özellikler
- Süreç keşfi için izlenecek temel aktiviteler
- Adım adım veri veri çekme kılavuzu
Kredi Yönetimi ve Tahsilat Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite 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 süreç 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. Aktivite Adı, süreç haritaları oluşturmak ve adımlar arasındaki geçiş sürelerini hesaplanmasında temel rol oynar. Neden Önemli?dir? Bu öznitelik, süreç haritasındaki adımları tanımlayarak, fatura süreç döngüsünün baştan sona görselleştirilmesini ve analizini sunar. 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şturulduDunning Prosedürü BaşlatıldıÖdeme AlındıAnlaşmazlık Kaydedildi | |||
| Fatura Numarası InvoiceNumber | Her müşteri faturası için benzersiz tanımlayıcı, kredi yönetimi süreci için birincil vaka tanımlayıcısı olarak olarak kullanılır. | ||
| 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 temel rol oynar. Fatura süreç döngüsünün eksiksiz, uçtan uca görmenizi sunar. 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?dir? 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 Case ID'dir. 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 tam tarih ve saat, olayın zaman damgası (zaman damgası) olarak olarak kullanılır. | ||
| Açıklama Olay Zamanı veya zaman damgası (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 gereklidir. 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 sunar. Neden Önemli?dir? Bu zaman damgası (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 gereklidir. 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 | Verinin 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 izlenebilirliğinın net olmasını sağlayarak olayları ayırt etmeye yardımcı olur. Neden Önemli?dir? 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 sunar. 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 olaya ait verinin en son ne zaman yenilendiğini veya kaynak sistemden çıkarıldığını gösteren zaman damgası (zaman damgası)dır. | ||
| 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ı (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 gereklidir. Neden Önemli?dir? Verinin güncelliğini gösterir, analistlerin ve paydaşların verinin zamanlaması ve uygunluğu hakkında bilgi sahibi olmasını sunar. 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?dir? Sürece finansal bağlam sağlayarak, yüksek değerli faturaların önceliklendirilmesini ve süreç verimsizliklerinin parasal etkisinin analiz edilmesini sunar. 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 sunar. Neden Önemli?dir? İ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 gereklidir. Otomatik etkinlikler için, sistem süreçlerinin katılımını takip etmenizi sunar. 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?dir? Süreç faaliyetlerini belirli kişilere veya otomatik sistemlere atfederek performans takibini, iş yükü analizini ve denetimi sunar. 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 niteliklerine dayalı olarak kredi ve tahsilat sürecinin segmentasyonunu ve analizini sunar. 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 önemlidir. Müşteri Segmentine Göre Fatura İptal Oranı Analizi gibi analizleri doğrudan destekler. Neden Önemli?dir? 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 sunar. Bu önemli bilgi, 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?dir? 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 sunar. 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 niteliklerinden türetilir. Örnekler::::::: Büyük İşletmeKüçü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 büyük önem taşır. 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?dir? Bireysel tahsildarların veya ekiplerin performans analizini sağlayarak, 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ı hesaplanmasında temel rol oynar. İ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?dir? Bir faturanın vadesi geçmiş olup olmadığını belirlemek, tahsilat faaliyetlerini tetiklemek ve yaşlandırma analizini güçlüak 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ş Zamanı EndTime | Süresi olan bir etkinliğin ne zaman tamamlandığını gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Belirgin bir başlangıcı ve sonu olan faaliyetler için bu öznitelik, tamamlanma zamanını yakalar. Process Miningndeki 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ı sunar. 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 büyük önem taşır. Neden Önemli?dir? Belirli faaliyetlerin ne kadar sürdüğünün doğru hesaplanmasını sağlayarak, darboğazlar ve kaynak kullanımı hakkında daha derinlemesine önemli bilgi sunar. Nereden Alınır?? Bu genellikle kavramsal bir özniteliktir. Etkinliğe karşılık gelen kaynak tablolarda 'son güncelleme' zaman damgası (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 süreç döngüsündeki mevcut durumu. | ||
| Açıklama Fatura Durumu, faturanın süreçteki mevcut konumunun bir güncel durumunu gösterir. 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. Process Miningnde 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 sunar ve tahsilat faaliyetlerini önceliklendirmeye yardımcı olur. Neden Önemli?dir? Bir faturanın güncel durumuna hızlı bir genel bakış sağlayarak, tahsilat çabalarının kolayca filtrelenmesini ve önceliklendirilmesini sunar. Nereden Alınır?? Genellikle AR_PAYMENT_SCHEDULES_ALL tablosunda STATUS adlı bir alanda mevcuttur. Örnekler::::::: AçıkKapalıUyuşmazlıkTahsilatta | |||
| 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 sunar. Parasal değerlerin doğru yorumlanmasını ve miktarların karşılaştırmalarının benzer temelde yapılmasını sunar. Neden Önemli?dir? Çoklu para birimi ortamında finansal verileri doğru yorumlamak ve doğru finansal analizi güçlüak için gereklidir. 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 sunar. 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?dir? Farklı organizasyonel birimler arasında performans karşılaştırmasına sunar, 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 | |||
| Kayıttan Düşüldü IsWrittenOff | Faturanın tahsil edilemeyen alacak olarak kayıtlardan düşülüp düşülmediğini gösteren bir boolean değeri. | ||
| 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'u hesaplamak için gereklidir. Analistlerin başarısız tahsilat popülasyonunu izole etmelerine sunar ve müşteri segmenti veya fatura değeri gibi daha yüksek iptal riskiyle ilişkili olabilecek ortak özellikleri belirlemelerine yardımcı olur. Bu önemli bilgi, kredi politikalarını ve tahsilat stratejilerini iyileştirmek için kullanılır. Neden Önemli?dir? 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 büyük önem taşır. 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?dir? Onaylanmış kredi limitini ödeme sonuçları ve kayıttan düşmelerle ilişkilendirerek kredi riski politikalarının etkinliğini değerlendirmek için büyük önem taşır. 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 Koşulları 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 iyileştirmek, 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 sunar. Neden Önemli?dir? Farklı kredi koşullarında ödeme davranışının analiz edilmesini sağlayarak, üzerinde anlaşılan ödeme takvimi hakkında bağlam sunar. Nereden Alınır?? Bu, RA_TERMS tablosunda depolanır ve fatura işlemine bağlanır. Örnekler::::::: Net 30 GünNet 60 GünMakbuzda Vadesi Gelen | |||
| Ö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?dir? 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 | |||
| Uyuşmazlık Nedeni DisputeReason | Müşteri tarafından bir faturaya itiraz etmek için belirtilen 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, kök 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?dir? 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ı sunar. 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 vadesi geçtikten 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'un birincil metriğidir. Bu, tahsilat ekibinin en eski ve en yüksek riskli borçlara odaklanmasına yardımcı olur. Neden Önemli?dir? Ödeme gecikmelerinin boyutunu niceliksel olarak belirleyerek, tahsilatları önceliklendirmek ve yaşlandırma analizi yapmak için temel bir metrik olarak olarak kullanılır. 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 değeri. | ||
| 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 sunar. Gecikmiş Borç Yaşlandırma ve Durum Dashboard'ı gibi Panellerin oluşturulmasını basitleştirir. Neden Önemli?dir? Tahsilat sürecinin birincil odağı olan tüm gecikmiş faturaları tanımlamak ve analiz etmek için basit ve net bir işaret sunar. 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 | ||
|---|---|---|---|
| Dunning 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?dir? Bu etkinliği takip etmek, ihtar etkinliğini ve ihtar politikalarına uyumu ölçmek için büyük önem taşır. Bir ihtarın ödeme ile sonuçlanmasının ne kadar sürdüğünü ölçmek için bir temel sunar. 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 | |||
| Fatura Oluşturuldu | Oracle Fusion Financials'ta fatura işlem kaydının oluşturulmasını işaret eder. Bu, fatura süreç döngüsünün alacaklar modülündeki resmi başlangıcıdır ve analiz için birincil başlangıç noktası olarak olarak kullanılır. | ||
| Neden Önemli?dir? 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ı (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ı (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?dir? 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 | |||
| Ö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?dir? 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?dir? Bu etkinlik, bir faturanın ödendiğini tanımak için büyük önem taşır. 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 | |||
| Ödeme Vadesi 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?dir? 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 gereklidir. 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 | |||
| Anlaşmazlık 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?dir? 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 büyük önem taşır. 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 | |||
| Fatura Kapatıldı | Faturanın ödenmemiş bakiyesi ödeme, kredi notu uygulaması veya ayarlama yoluyla sıfırlandığında meydana gelir. Bu, fatura süreç döngüsünün başarılı bir şekilde tamamlandığını işaret eder. | ||
| Neden Önemli?dir? Bu olay, süreç için birincil başarılı bitiş noktası olarak olarak kullanılır. Faturaların kapatılmasını izlemek, alacak portföyünün genel sağlığını anlamak için büyük önem taşır. 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?dir? 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 | |||
| 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 sunar. | ||
| Neden Önemli?dir? 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ı (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?dir? 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?dir? Ö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?dir? Bu olay, tahsilat sürecinin otomasyonuna ilişkin önemli bilgi sunar. 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 | |||
| Tahsilat Uzmanı 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?dir? 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 sunar. 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ı (zaman damgası)dır. Event tipi explicit | |||
Veri Çıkarma 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. Process Mining 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 büyük önem taşır. İ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 sunar. 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'