Siparişten Tahsilata - satış siparişi işleme Veri Templateiniz
Siparişten Tahsilata - satış siparişi işleme Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel etkinlikler
- Veri çıkarma hakkında pratik bilgiler
Siparişten Tahsilata - satış siparişi işleme öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Satış siparişi SalesOrder | Satış siparişinin benzersiz tanımlayıcısıdır ve Siparişten Tahsilata sürecindeki ana vaka olarak kullanılır. | ||
| Açıklama Satış siparişi numarası, her müşteri siparişini yaşam döngüsü boyunca benzersiz biçimde tanımlar. İlk oluşturma ve onaydan teslimat, faturalama ve son ödemeye kadar ilgili tüm etkinlikleri birbirine bağlayan ana referanstır. Process Mining çalışmalarında bu öznitelik, ilgili tüm olayları tek bir vakada gruplandırmak için gereklidir. Süreci satış siparişine göre inceleyerek uçtan uca görünüm elde edebilir, toplam çevrim sürelerini hesaplayabilir, sipariş bazındaki süreç çeşitlerini belirleyebilir ve siparişin farklı departmanlar ile sistemlerdeki ilerleyişini izleyebilirsiniz. Neden önemli? Bu, Vaka kimliğidir. Tüm süreç olaylarını birbirine bağlayarak tek bir müşteri siparişinin uçtan uca yolculuğunu izlemenizi sağlar. Nereden alınır? Bu tanımlayıcı genellikle Oracle Fusion satış siparişi başlık tablosunda, örneğin DOO_HEADERS_ALL içinde bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler SO-100567SO-100568SO-100569 | |||
| Etkinlik adı ActivityName | Satış siparişi sürecinde gerçekleşen belirli iş olayının veya görevin adı. | ||
| Açıklama Bu öznitelik, satış siparişi için belirli bir anda gerçekleştirilen adımı tanımlar. Örneğin, Satış siparişi oluşturuldu, Ürünler sevk edildi veya Ödeme alındı. Bu etkinliklerin sıralaması, her vaka için süreç akışını oluşturur. ActivityName özniteliğini incelemek Process Mining çalışmalarının temelini oluşturur. Süreç haritasını görselleştirmenizi, farklı süreç çeşitlerini keşfetmenizi ve vakaların biriktiği darboğazları belirlemenizi sağlar. Adımlar arasındaki geçiş sürelerini hesaplamaya ve Siparişten Tahsilata sürecindeki operasyon sırasını anlamaya yardımcı olur. Neden önemli? Bu öznitelik, süreç haritasındaki adımları tanımlar ve süreç akışını görselleştirip incelemenizi sağlar. Nereden alınır? Bu, türetilmiş bir özniteliktir. Çeşitli Oracle Fusion tablolarındaki işlem durumları veya olay türleri, standart bir etkinlik adı listesiyle eşleştirilerek oluşturulur. Örneğin sipariş, sevkiyat ve fatura durumları kullanılır. Örnekler Satış siparişinin oluşturulmasıMalların sevk edilmesiFaturanın oluşturulmasıÖdeme alındı | |||
| Olay zamanı EventTime | Bir satış siparişi için belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, süreçteki her etkinliğin tarih ve saatini vererek olayların kronolojik sırasını belirler. Süreç analizinin zaman temelini oluşturur ve her adımın tam olarak ne zaman gerçekleştiğini kaydeder. Process Mining çalışmalarında EventTime; çevrim sürelerini, etkinlikler arasındaki süreleri ve vakaların toplam tamamlanma süresini hesaplamak için gereklidir. Performans analizini, bekleme sürelerine göre darboğaz tespitini ve zamanında hizmet düzeyi anlaşmalarına (SLA) uyumluluğun izlenmesini sağlar. Zamana dayalı tüm KPI’lar ve Dashboardlar bu özniteliğin doğruluğuna bağlıdır. Neden önemli? Olayları kronolojik sıraya koymak ve çevrim süreleri ile süreler gibi zamana dayalı tüm metrikleri hesaplamak için bu zaman damgası gereklidir. Nereden alınır? Bu, türetilmiş bir özniteliktir. Sipariş oluşturma tarihi, sevkiyat tarihi, fatura tarihi ve ödeme tarihi gibi farklı Oracle Fusion tablolarındaki zaman damgası alanlarından alınır. Örnekler 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Gerçek teslimat tarihi ActualDeliveryDate | Ürünlerin müşteriye gerçekten teslim edildiği tarih. | ||
| Açıklama Bu öznitelik, sürecin teslimat aşamasının tamamlandığını gösteren son teslimat tarihini kaydeder. Planlanan veya talep edilen tarihlerle karşılaştırılacak gerçek sonucu belirtir. Zamanında teslimat performansını hesaplamak için bu tarih RequestedDeliveryDate ile karşılaştırılır. Zamanında teslimat oranı KPI’ı ve Teslimat SLA Dashboardu için temel bir girdidir; lojistik ve tedarik zinciri performansını açıkça ölçmenizi sağlar. Neden önemli? Zamanında teslimat oranlarını hesaplamak ve teslimat performansını müşteri taleplerine göre değerlendirmek için kullanılan gerçek sonuç tarihidir. Nereden alınır? Oracle Fusion sevkiyat ve teslimat işlem tablolarından alınır. Oracle Fusion Financials belgelerine başvurun. Örnekler 2023-05-202023-06-032023-05-25 | |||
| Kullanıcı adı UserName | Etkinliği gerçekleştiren kullanıcının adı veya kimliği. | ||
| Açıklama Bu öznitelik, belirli bir süreç adımını gerçekleştirmekten sorumlu çalışanı veya sistem kullanıcısını tanımlar. Kullanıcı bazında performansı, iş yükü dağılımını ve standart prosedürlere uyumu incelemek için kullanılabilir. Kullanıcı bazında analiz; eğitim ihtiyaçlarını belirlemeye, yüksek performans gösteren kişileri veya ekipleri fark etmeye ve belirli kullanıcıların neden olduğu sapmaları araştırmaya yardımcı olur. Ayrıca kimin hangi işlemi yaptığını izleyerek uyumluluk ve denetim çalışmalarını destekler. Neden önemli? Kullanıcı bazında performans ve iş yükü dağılımı analizini, ayrıca kişilere bağlı manuel yeniden çalışma örüntülerinin belirlenmesini sağlar. Nereden alınır? Genellikle Oracle Fusion işlem tablolarındaki CREATED_BY veya LAST_UPDATED_BY gibi alanlardan alınır ve çoğu zaman FND_USER gibi bir kullanıcı ana tablosuyla ilişkilendirilir. Örnekler john.smithjane.doesystem_batch_user | |||
| Müşteri adı CustomerName | Satış siparişini veren müşterinin adı. | ||
| Açıklama Bu öznitelik, satış siparişiyle ilişkili müşteri hesabının yasal adını tanımlar. Süreci müşteri odaklı incelemek ve gruplandırmak için temel bir boyuttur. Müşteri bazında analiz, bazı müşterilerin daha uzun çevrim süreleriyle, daha fazla yeniden çalışmayla veya belirli süreç sapmalarıyla karşılaşıp karşılaşmadığını gösterir. Bu içgörü, müşteri hizmetlerini iyileştirmek, önemli müşterilere özel süreçler tasarlamak ve müşteri memnuniyetini etkileyen sorunları araştırmak için kullanılabilir. Neden önemli? Belirli müşterileri etkileyen süreç sorunlarını belirlemek ve müşteri memnuniyetini artırmak için müşteri odaklı analiz yapmanızı sağlar. Nereden alınır? Müşteri ana veri tablolarından, örneğin HZ_PARTIES tablosundan alınır ve müşteri kimliği aracılığıyla satış siparişiyle ilişkilendirilir. Örnekler Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Ödeme vadesi tarihi PaymentDueDate | Müşterinin fatura ödemesini yapması gereken son tarih. | ||
| Açıklama Ödeme vadesi tarihi, fatura tarihine ve müşteriyle kararlaştırılan ödeme koşullarına göre hesaplanır. Ödemenin zamanında tahsil edilmesi için son tarihi belirler. Bu öznitelik, Zamanında ödeme tahsilat oranı KPI’ı için önemlidir. Sistem, PaymentDueDate ile ödemenin fiilen alındığı tarihi karşılaştırarak ödemenin zamanında mı yoksa geç mi yapıldığını belirleyebilir. Böylece alacak hesapları performansı izlenebilir ve nakit akışı yönetilebilir. Neden önemli? Nakit akışı verimliliğinin temel ölçütlerinden biri olan zamanında ödeme oranlarını hesaplamak için son tarihi belirler. Nereden alınır? Oracle Fusion içindeki alacak hesapları veya fatura tablolarında, örneğin AR_PAYMENT_SCHEDULES_ALL tablosunda bulunur. Örnekler 2023-06-192023-07-012023-06-25 | |||
| Otomatik mi IsAutomated | Bir etkinliğin sistem tarafından otomatik olarak mı yoksa kullanıcı tarafından manuel olarak mı gerçekleştirildiğini belirten işaret. | ||
| Açıklama Bu mantıksal öznitelik, sistem tarafından yürütülen olayları, örneğin otomatik kredi kontrolünü veya sistemin oluşturduğu faturayı, kullanıcıların manuel işlemlerinden ayırır. Genellikle etkinlikle ilişkili kullanıcı adına göre türetilir; genel bir sistem kimliği otomasyonu gösterir. Bu özniteliği inceleyerek süreçteki otomasyon düzeyini ölçebilir ve Manuel yeniden işlenen siparişlerin yüzdesi KPI’ını hesaplayabilirsiniz. En çok zaman alan veya hataya açık manuel adımları göstererek otomasyon fırsatlarını ortaya çıkarabilir. Neden önemli? Süreçteki otomasyon düzeyini ölçmeye ve maliyetli manuel müdahaleleri azaltma fırsatlarını belirlemeye yardımcı olur. Nereden alınır? Bu, genellikle UserName özniteliğine uygulanan bir kurala göre türetilen bir alandır. Örneğin kullanıcı SYSTEM veya BATCH ise bu işaret true olarak ayarlanır. Örnekler truefalse | |||
| Satış kanalı SalesChannel | Satış siparişinin alındığı kanal. | ||
| Açıklama Bu öznitelik, satış siparişinin kaynağını Web, Doğrudan satış, İş ortağı veya EDI gibi kategorilerle belirtir. Siparişin kuruluşa nasıl ulaştığı hakkında bilgi verir. Süreci satış kanalına göre gruplandırmak, Satış kanalı performansına genel bakış Dashboardu için önemlidir. Farklı kanalların verimliliğini, çevrim sürelerini ve hata oranlarını karşılaştırarak hangilerinin daha etkili olduğunu, hangilerinde süreç iyileştirmesi veya daha fazla otomasyon gerektiğini belirlemenize yardımcı olur. Neden önemli? Kanal bazında performans analizini destekleyerek sipariş işlemede en verimli ve en az verimli kanalları belirlemenizi sağlar. Nereden alınır? Bu bilgi, satış siparişi başlığında ayrılmış bir alanda saklanabilir. Oracle Fusion Financials belgelerine başvurun. Örnekler Doğrudan satışWeb portalıEDIBayi | |||
| Satış siparişinin toplam tutarı SalesOrderTotalAmount | Satış siparişinin toplam parasal değeri. | ||
| Açıklama Bu öznitelik, satış siparişinin tamamı için müşteriden tahsil edilen toplam tutarı gösterir. İndirimler uygulanmadan önce tüm kalemlerin, vergilerin ve diğer ücretlerin toplamını içerir. Süreç analizinde bu öznitelik, değere göre Process Mining yapmak için gereklidir. Siparişleri değerlerine göre gruplandırarak, örneğin yüksek ve düşük tutarlı siparişleri karşılaştırarak farklı süreç yolları izleyip izlemediklerini veya çevrim sürelerinin değişip değişmediğini görebilirsiniz. Ayrıca süreç iyileştirme çalışmalarını finansal açıdan en yüksek değere sahip vakalara önceliklendirmeye yardımcı olur. Neden önemli? Finansal etki analizini destekler; yüksek tutarlı siparişlerde süreç iyileştirmelerine öncelik vermenizi ve maliyet etkenlerini anlamanızı sağlar. Nereden alınır? Genellikle Oracle Fusion satış siparişi başlık tablolarında bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler 5250.00125000.75980.50 | |||
| Talep edilen teslimat tarihi RequestedDeliveryDate | Müşterinin sipariş için talep ettiği teslimat tarihi. | ||
| Açıklama Bu öznitelik, müşterinin ürünleri teslim almak istediği tarihi kaydeder. Siparişten Tahsilata sürecinin teslimat aşaması için temel bir performans hedefidir. Bu tarih, Zamanında teslimat oranı KPI’ını hesaplamak ve Teslimat hizmet düzeyi anlaşması (SLA) Dashboardunu desteklemek için gereklidir. Kuruluş, bu tarihi ActualDeliveryDate ile karşılaştırarak müşteri beklentilerini ne ölçüde karşıladığını ölçebilir ve teslimat gecikmelerinin temel nedenlerini belirleyebilir. Neden önemli? Zamanında teslimat performansını ve müşteri hizmet düzeyi anlaşmasına (SLA) uyumluluğu ölçmek için başlangıç noktasıdır. Nereden alınır? Genellikle Oracle Fusion satış siparişi kalem tablolarında bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler 2023-05-202023-06-012023-05-25 | |||
| Fatura düzeltildi mi IsInvoiceCorrected | Faturanın ilk oluşturulmasından sonra düzeltilip düzeltilmediğini gösteren bir işaret. | ||
| Açıklama Bu boole özniteliği, olay günlüğünde Fatura Düzeltildi etkinliği bulunduğunda, faturanın bir düzeltme döngüsünden geçtiğini belirtmek için true değerini alır. Faturalama aşamasında yeniden çalışma gerektiren vakaları işaretler. Bu alan, Fatura doğruluğu ve yeniden işleme analizi Dashboardu ile Fatura yeniden işleme oranı KPI’ı için temel girdilerden biridir. Faturalama hatalarının boyutunu ölçmenize ve düzeltme gereksinimlerinin nedenlerini belirlemek üzere kök neden analizi yapmanıza yardımcı olur. Böylece manuel işi ve ödeme gecikmelerini azaltabilirsiniz. Neden önemli? Faturaların yeniden işlenmesini belirler. Bu, süreç verimsizliğinin, veri kalitesi sorunlarının ve olası ödeme gecikmelerinin önemli bir göstergesidir. Nereden alınır? Bu, hesaplanan bir alandır. Genellikle olay günlüğünde Fatura Düzeltildi etkinliği bulunan vakalarda true değerini alır. Örnekler falsetrue | |||
| Fatura numarası InvoiceNumber | Müşteri faturasının benzersiz tanımlayıcısı. | ||
| Açıklama Bu öznitelik, satış siparişinden oluşturulan faturaya atanan benzersiz numaradır. Satış ve teslimat etkinliklerini sürecin finansal tahsilat aşamasına bağlar. Satış siparişi ana vaka kimliği olsa da fatura numarası, faturalama ve ödeme alt süreçlerini incelemek için önemlidir. Fatura düzeltmelerini, itirazları ve ödeme durumunu izlemek; Fatura doğruluğu ve yeniden işleme analizi gibi Dashboardları desteklemek için gereklidir. Neden önemli? Alacak hesapları süreciyle önemli bir bağlantı sağlar; fatura yeniden çalışmasını ve ödeme çevrimlerini incelemek için gereklidir. Nereden alınır? Oracle Fusion içindeki alacak hesapları işlem tablolarında, örneğin RA_CUSTOMER_TRX_ALL tablosunda bulunur. Örnekler INV-93485INV-93486INV-93487 | |||
| İş birimi BusinessUnitName | Satış siparişinden sorumlu iç iş biriminin adı. | ||
| Açıklama Bu öznitelik, şirket içindeki işlemin sahibi olan belirli bölümü veya operasyon birimini gösterir. Kuruluşun farklı bölümlerindeki performansı karşılaştırmanızı sağlar. Süreci iş birimine göre gruplandırmak, şirket genelindeki verimlilik, maliyet ve uyumluluk farklılıklarını belirlemeye yardımcı olur. Bu analiz, yüksek performanslı birimlerdeki iyi uygulamaların paylaşılmasını sağlayabilir veya hedefli süreç iyileştirmesi gereken birimleri ortaya çıkarabilir. Neden önemli? Farklı kuruluş birimleri arasında performans kıyaslaması yapmayı ve süreç tutarlılığını incelemeyi sağlar. Nereden alınır? Genellikle satış siparişi başlığında bulunur ve Oracle Fusion’da tanımlanan kuruluş yapısıyla ilişkilendirilir. Örnekler BU-North AmericaBU-EMEAGlobal Services | |||
| Kaynak sistem SourceSystemIdentifier | Olay verilerinin hangi kaynak sistemden çıkarıldığını belirtir. | ||
| Açıklama Bu öznitelik, verinin kaynağını belirtir. Siparişten Tahsilata sürecinde birden fazla sistemin kullanıldığı ortamlarda özellikle yararlıdır. Örneğin sipariş verileri Oracle Fusion’dan, sevkiyat verileri ise üçüncü taraf bir lojistik sisteminden gelebilir. Analiz sırasında veri kökenini anlamanıza yardımcı olur ve süreç görünümünü belirli sistemlerden gelen olaylara göre filtrelemek için kullanılabilir. Veri doğrulama ve farklı BT ortamları arasındaki süreç parçalanmasını belirleme açısından önemlidir. Neden önemli? Veri kaynağı hakkında bağlam sağlar; birden fazla sistemin kullanıldığı ortamlarda veri yönetişimi ve sorun giderme için önemlidir. Nereden alınır? Genellikle veri çıkarma ve dönüştürme sırasında Veri Seti’nin kaynağını belirtmek için eklenen sabit bir değerdir. Örnekler Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Müşteri ülkesi CustomerCountry | Müşterinin bulunduğu ülke. | ||
| Açıklama Bu öznitelik, müşterinin sevkiyat veya fatura adresindeki ülkeyi belirtir. Coğrafi analiz için temel bir boyuttur. Süreci ülkeye göre gruplandırmak, bölgelere göre süreç performansı, çevrim süreleri veya ödeme davranışındaki farklılıkları ortaya çıkarabilir. Bu bilgi, yerel düzenlemelerin, lojistik zorlukların ve piyasa koşullarının Siparişten Tahsilata sürecine etkisini anlamaya yardımcı olur. Neden önemli? Süreç verimliliği, uyumluluk ve müşteri davranışındaki bölgesel farklılıkları belirlemek için coğrafi analiz yapmanızı sağlar. Nereden alınır? Satış siparişiyle ilişkilendirilen müşteri ana veri tablolarından (HZ_LOCATIONS, HZ_PARTY_SITES) alınır. Örnekler USAAlmanyaJaponya | |||
| Ödeme gecikti mi IsLatePayment | Ödeme vadesinden sonra tahsilat yapıldıysa true değerini alan hesaplanmış bir işaret. | ||
| Açıklama Bu mantıksal öznitelik, ödemenin fiilen alındığı tarih ile PaymentDueDate karşılaştırılarak türetilir. Faturanın zamanında ödenip ödenmediğini açıkça gösterir. Bu öznitelik, Zamanında ödeme oranı KPI’ını hesaplamak için kullanılır. Zamanında ve geciken ödemeleri kolayca gruplandırarak geç ödeme yapan müşterilerin özelliklerini, gecikmelerin yaygın nedenlerini ve işletme sermayesi üzerindeki finansal etkileri incelemenizi sağlar. Neden önemli? Ödeme tahsilatının etkinliğini doğrudan ölçer ve vadesi geçmiş ödemelerin analizini kolaylaştırır. Nereden alınır? Bu, hesaplanan bir alandır. Mantığı şöyledir: PaymentReceivedDate > PaymentDueDate. Örnekler falsetrue | |||
| Ödeme koşulları PaymentTerms | Müşteri ödemesi için üzerinde anlaşmaya varılan koşullar. | ||
| Açıklama Bu öznitelik, müşterinin faturasını hangi koşullarda ödemesinin beklendiğini belirtir; örneğin 30 gün net veya 60 gün net. Ödeme vadesi tarihi bu koşullara göre hesaplanır. Ödeme koşullarına göre gruplandırma, ödeme çevrim sürelerindeki farklılıkları açıklamaya yardımcı olur. Farklı koşullar doğal olarak farklı ödeme davranışlarına yol açtığından, Zamanında ödeme oranı KPI’ına bağlam sağlar. Bu bilgi, kredi politikasına ve nakit akışı tahminlerine yön verebilir. Neden önemli? Ödeme davranışını incelemek için gerekli bağlamı sağlar ve fatura ile ödeme arasındaki çevrim sürelerindeki farklılıkları açıklamaya yardımcı olur. Nereden alınır? Oracle Fusion’da satış siparişi veya müşteri hesabı düzeyinde bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler 30 gün net60 gün netTeslimatta ödenir | |||
| Sevkiyat yöntemi ShippingMethod | Ürünleri müşteriye göndermek için kullanılan yöntem veya taşıyıcı. | ||
| Açıklama Bu öznitelik, teslimatta kullanılan lojistik taşıyıcıyı veya hizmet düzeyini, örneğin kara yolu taşımacılığı, hava ekspresi veya yerel kurye hizmetini belirtir. Bu bilgi, Sevkiyat yöntemi teslimat uyumluluğu Dashboardu için gereklidir. Farklı yöntem ve taşıyıcıların zamanında teslimat performansını ve sevkiyat maliyetlerini karşılaştırarak lojistik stratejisini ve tedarikçi seçimini iyileştirmenize yardımcı olur. Neden önemli? Farklı sevkiyat taşıyıcılarının ve yöntemlerinin performansını karşılaştırarak lojistik analizini doğrudan destekler. Nereden alınır? Oracle Fusion içindeki sevkiyat ve teslimat tablolarında bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler FedEx GroundUPS Next Day AirDHL International | |||
| Sipariş türü OrderType | Standart sipariş veya iade siparişi gibi satış siparişlerini sınıflandıran tür. | ||
| Açıklama Sipariş türü, satış siparişlerini iş amaçlarına göre sınıflandırmak için kullanılır. Yaygın türler arasında standart satış, hizmet siparişi, iade malzeme yetkilendirmesi (RMA) ve iç sipariş bulunur. Farklı sipariş türlerinin süreç akışları ve performans hedefleri de farklı olabileceğinden, süreci sipariş türüne göre incelemek önemlidir. Bu gruplandırma, kasıtlı ve beklenen süreç farklılıklarını anlamanıza ve bunları sapma olarak değerlendirmekten kaçınmanıza yardımcı olur. Neden önemli? Standart siparişler ile iadeler gibi farklı ve geçerli süreç akışlarını ayrı gruplarda inceleyerek adil ve doğru analiz yapmanızı sağlar. Nereden alınır? Genellikle Oracle Fusion satış siparişi başlık tablosunda bir alan olarak bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler Standart satış siparişiİade yetkilendirmesiHizmet siparişi | |||
| Son veri güncellemesi LastUpdateDate | Bu olaya ait verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, verilerin Process Mining Veri Seti’nden en son ne zaman çıkarıldığını veya güncellendiğini kaydeder. İncelenen verilerin ne kadar güncel olduğunu gösterir. Bu bilgi, kullanıcıların süreç analizinin güncelliğini anlamasına yardımcı olur. Verilerin ne kadar yeni olduğuna ilişkin beklentileri yönetmeyi ve veri yenileme takvimlerini oluşturup izlemeyi kolaylaştırır. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizlerinin ne kadar yeni olduğunu anlamasını sağlar. Nereden alınır? Bu değer, her veri çıkarma ve dönüştürme döngüsünde oluşturulur ve Veri Seti’ne eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Ürün adı ProductName | Satılan ürünün veya hizmetin adı. | ||
| Açıklama Bu öznitelik, satış siparişi kalemindeki ürünü belirtir. Bir siparişte birden fazla kalem varsa vaka kalem düzeyinde incelenebilir veya bu öznitelik başlık düzeyinde bir araya getirilebilir. Ürün bazında analiz, sık teslimat gecikmeleri veya ödeme sorunları gibi daha karmaşık ya da sorunlu süreç akışlarıyla ilişkili ürünleri anlamaya yardımcı olur. Bu bilgi, ürün yönetimi ve tedarik zinciri stratejilerine yön verebilir. Neden önemli? Farklı ürünlerin süreç performansını incelemeyi ve teslimat ya da faturalama akışları karmaşık olabilecek ürünleri belirlemeyi sağlar. Nereden alınır? Satış siparişi kalem tablolarından alınır ve ürün ana tablosuyla birleştirilir. Oracle Fusion Financials belgelerine başvurun. Örnekler Standard Widget X1Premium Service PackageComponent Y2-B | |||
| Zamanında teslim edildi mi IsOnTimeDelivery | Gerçek teslimat talep edilen teslimat tarihinde veya daha önce gerçekleştiyse true değerini alan hesaplanmış bir işaret. | ||
| Açıklama Bu mantıksal öznitelik, ActualDeliveryDate ile RequestedDeliveryDate karşılaştırılarak türetilir. Teslimat performansını vaka düzeyinde gösteren basit bir işaret sağlar. Bu işaret, toplam Zamanında teslimat oranı KPI’ının hesaplanmasının temelini oluşturur. Filtreleme ve analizi kolaylaştırarak geciken tüm siparişleri hızla ayırmanıza ve gecikmelere yol açan etkenleri araştırmanıza imkân verir. Neden önemli? Teslimat performansını müşteri beklentilerine göre doğrudan ölçer ve geciken siparişlerin analizini kolaylaştırır. Nereden alınır? Bu, hesaplanmış bir alandır. Mantık şöyledir: ActualDeliveryDate <= RequestedDeliveryDate. Örnekler truefalse | |||
Siparişten Tahsilata - satış siparişi işleme etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Faturanın oluşturulması | Bu etkinlik, genellikle sevkiyat onayı olayıyla başlatılan Alacaklar modülünde müşteri faturasının oluşturulmasını ifade eder. Benzersiz numarası ve oluşturulma tarihi olan bir fatura kaydı oluşturulur. | ||
| Neden önemli? Tahsilat döngüsünün resmen başladığını gösterir. 'Faturadan ödemeye kadar geçen süre’yi ve genel nakit akışı verimliliğini ölçmenin temelini oluşturur. Nereden alınır? Oracle Alacaklar (AR) modülünde açıkça kaydedilen bir olaydır. RA_CUSTOMER_TRX_ALL tablosunda işlem tarihiyle birlikte bir fatura kaydı oluşturulur. Kaydedin AR modülündeki fatura işleminin oluşturulma tarihinden alınır. Olay türü explicit | |||
| Malların sevk edilmesi | Bu etkinlik, malların depodan çıkıp müşteriye doğru yola çıktığı anı gösterir. Oracle Shipping’de sevkiyat onayı işlemi yapıldığında kaydedilir. | ||
| Neden önemli? Bu önemli aşama, sürecin sipariş karşılama bölümünün tamamlandığını gösterir ve faturalandırmayı başlatır. Zamanında sevkiyat ve teslimat sürelerini ölçmek için gereklidir. Nereden alınır? Oracle Shipping Execution’da açıkça kaydedilen bir olaydır. Sevkiyat onayı işlemi, sevkiyat tarihiyle birlikte WSH_DELIVERY_DETAILS gibi sevkiyat tablolarında bir kayıt oluşturur. Kaydedin Sipariş satırıyla ilişkili teslimat ayrıntısı kaydındaki 'gerçek sevkiyat tarihi' zaman damgasından alınır. Olay türü explicit | |||
| Ödeme alındı | Bu etkinlik, müşterinin ödemesinin alındığını ve Alacak Hesapları bölümünde faturaya işlendiğini gösterir. Nakit tahsilatın faturaya mahsup edilmesi kaydedildiğinde sisteme yansır. | ||
| Neden önemli? Toplam Siparişten Tahsilata çevrim süresini ve zamanında ödeme oranını ölçmek için önemli bir kilometre taşıdır. Satışın nakde dönüşmesini ifade eder. Nereden alınır? Oracle Accounts Receivable içinde açıkça kaydedilen bir olaydır. Tahsilat faturaya mahsup edildiğinde AR_RECEIVABLE_APPLICATIONS_ALL gibi nakit tahsilat tablolarına işlenir. Kaydedin AR içindeki nakit tahsilat mahsup kaydının apply date zaman damgasından alınır. Olay türü explicit | |||
| Satış siparişinin oluşturulması | Bu etkinlik, Oracle Fusion’a yeni bir satış siparişinin girildiği anı gösterir ve satış siparişi sürecinin başlangıcını işaretler. Genellikle Kullanıcı Sipariş Yönetimi modülünde yeni bir sipariş kaydını kaydettiğinde açıkça kaydedilir. | ||
| Neden önemli? Sürecin başlangıcını gösteren bu etkinlik, genel Siparişten Tahsilata çevrim süresini ölçmek ve alınan sipariş hacmini analiz etmek için gereklidir. Nereden alınır? Sipariş Yönetimi Cloud’da satış siparişi kaydı oluşturulduğunda açıkça kaydedilir. DOO_HEADERS_ALL tablosundaki oluşturulma zaman damgalarını inceleyin. Kaydedin Satış siparişi üstbilgi kaydının oluşturulma zaman damgasından alınır. Olay türü explicit | |||
| Sipariş kapatıldı | Süreçteki son etkinliktir. Satış siparişindeki tüm kalemlerin teslim edildiğini, faturalandırıldığını ve kapatıldığını gösterir. Sipariş başlığının durumu Closed olarak güncellenir. | ||
| Neden önemli? Bu etkinlik, satış siparişi yaşam döngüsünün başarıyla tamamlandığını gösterir. Uçtan uca süreç sürelerini hesaplamak ve hiç kapanmayan atıl siparişleri belirlemek için gereklidir. Nereden alınır? DOO_HEADERS_ALL tablosunda satış siparişi başlığının durumunun Closed olarak değişmesinden anlaşılır. Son durum değişikliğinin zaman damgası, olay zamanını belirtir. Kaydedin Satış siparişi başlığının durumunun Closed olarak değiştiği zaman damgasından hesaplanır. Olay türü inferred | |||
| Siparişin onaylanması | Bu önemli aşama, satış siparişinin kredi onayı dahil ilk kontrollerin tümünü geçtiğini ve artık karşılanmak üzere onaylandığını gösterir. Sipariş durumu 'Sevkiyat bekleniyor' veya 'Planlandı' gibi bir aşamaya geçtiğinde genellikle bu durumdan çıkarılır. | ||
| Neden önemli? Bu etkinlik, 'Ortalama sipariş onay süresi’ni hesaplamak için önemli bir aşamadır ve sipariş girişinden sipariş karşılama sürecine devir teslimi gösterir. Nereden alınır? Satış siparişi üstbilgisinin veya satırının durumu, siparişin karşılanmaya hazır olduğunu gösteren bir değere (ör. 'Sevkiyat bekleniyor') geçtiğinde bu etkinlik çıkarılır. DOO_HEADERS_ALL veya DOO_FULFILL_LINES_ALL tablolarındaki durum sütunlarını inceleyin. Kaydedin Sipariş durumunun onaylandı veya planlandı olarak değiştiği zaman damgasından elde edilir. Olay türü inferred | |||
| Envanterin rezerve edilmesi | Bu etkinlik, satış siparişi satırını karşılamak için fiziksel envanterin tahsis edilmesini veya rezerve edilmesini ifade eder. Sistem belirli stokları sipariş için ayırır ve sipariş toplanmaya hazır olduğunda kullanılabilir olmalarını sağlar. | ||
| Neden önemli? Bu etkinliği izlemek, 'Envanter tahsis süresi' KPI’ını analiz etmeye ve siparişin onaylanmasıyla ürünlerin güvence altına alınması arasındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? Bu olay genellikle envanter veya tedarik zinciri yürütme modüllerinde kaydedilir. Sipariş karşılama satırının durum güncellemelerinden, envanterin ayrıntılandırıldığı veya rezerve edildiği anlaşılabilir. Kaydedin Envanter rezervasyonu veya planlamasıyla ilgili sipariş karşılama satırı durumu değişikliklerinden çıkarılır. Olay türü inferred | |||
| Faturanın düzeltilmesi | Daha önce oluşturulmuş bir faturada hata veya müşteri itirazı nedeniyle değişiklik yapıldığında, fatura yeniden düzenlendiğinde ya da alacak dekontu kesildiğinde gerçekleşir. Bu durum genellikle bir alacak dekontu oluşturularak veya faturanın yeni bir sürümü hazırlanarak kaydedilir. | ||
| Neden önemli? Fatura düzeltmelerini izlemek, Fatura yeniden çalışma oranı KPI’ı için önemlidir. Bu gösterge, ödemeleri geciktirebilen ve idari maliyetleri artırabilen faturalama sürecindeki sorunları ortaya çıkarır. Nereden alınır? RA_CUSTOMER_TRX_ALL tablosunda, asıl faturaya bağlı bir alacak dekontu oluşturulmasından veya aynı faturanın sonraki bir sürümünün hazırlanmasından anlaşılır. Kaydedin Önceki bir fatura işlemine atıfta bulunan alacak dekontları veya faturalar belirlenerek hesaplanır. Olay türü inferred | |||
| Kredi blokajının uygulanması | Kredi kontrolünün başarısız olması veya krediyle ilgili başka bir sorun nedeniyle satış siparişinin otomatik ya da manuel olarak beklemeye alınmasıyla bu etkinlik gerçekleşir. Genellikle sistemde siparişin bekletilme durumunun değişmesiyle kaydedilir. | ||
| Neden önemli? Kredi blokajlarını izlemek, sipariş işlemlerindeki gecikmelerin nedenlerini belirlemek ve blokajı kaldırma sürecinin verimliliğini ölçmek için önemlidir. Nereden alınır? Satış siparişine blokaj uygulanmasından çıkarılır. Bu işlem genellikle siparişle bağlantılı DOO_HOLDS_ALL gibi blokaj tablolarına kaydedilir. Kaydedin Sipariş blokajı tablosunda 'Kredi' türünde bir blokaj kaydı oluşturulmasından çıkarılır. Olay türü inferred | |||
| Kredi kontrolünün yapılması | Müşterinin kredi değerliliğini ölçmek için hesabında kredi kontrolü yapılmasını ifade eder. Sipariş iş akışında bu adım otomatik veya manuel olarak yürütülebilir; tamamlandığı genellikle bir durum güncellemesi ya da tamamlanmış görev olarak kaydedilir. | ||
| Neden önemli? Kredi kontrollerinin ne kadar sürdüğünü analiz etmek, sipariş onayındaki darboğazları belirlemeye yardımcı olur. Bu süre, 'Kredi kontrolünden onaya kadar geçen süre' KPI’ı için önemlidir. Nereden alınır? Satış siparişinin durumunun 'Kredi onayı bekleniyor' olarak değişmesinden veya kredi yönetimi işlevindeki açık bir olay günlüğü kaydından çıkarılabilir. Kaydedin Sipariş durumundaki değişikliklerden veya kredi inceleme görevleriyle ilişkili zaman damgalarından çıkarılır. Olay türü inferred | |||
| Malların teslim edilmesi | Müşterinin sevkiyatı teslim aldığını gösterir. Bu bilgi genellikle harici taşıyıcıdan gelir ve Oracle Fusion’a aktarılır. Alternatif olarak, sevkiyat tarihine standart taşıma süresi eklenerek tahmin edilebilir. | ||
| Neden önemli? Bu etkinlik, 'Zamanında teslimat oranı' KPI’ını doğru hesaplamak ve müşteri hizmetleri düzeyini ölçmek için önemlidir. Nereden alınır? Bu olay çoğu zaman Oracle’da yerleşik olarak bulunmaz. Taşıyıcı entegrasyonu varsa kaydedilebilir veya 'Malların sevk edilmesi' tarihine standart taşıma süresi eklenerek hesaplanabilir. Sistem analizi gerektirir. Kaydedin Taşıyıcı veri akışlarından çıkarılır veya sevkiyat tarihine ortalama taşıma süresi eklenerek hesaplanır. Olay türü inferred | |||
| Malların toplanması | Siparişi karşılamak için malların depodan fiziksel olarak toplanmasını ifade eder. Lojistik sürecinin önemli bir adımıdır ve genellikle depo yönetimi veya sevkiyat modülüne kaydedilir. | ||
| Neden önemli? Bu etkinlik, depo operasyonlarının görünürlüğünü sağlar. Envanterin rezerve edilmesiyle malların toplanması arasındaki gecikmeler, depodaki kaynak veya süreç darboğazlarına işaret edebilir. Nereden alınır? Oracle Fusion Cloud SCM (Tedarik Zinciri Yönetimi) modüllerinde kaydedilir. Satış siparişi satırıyla ilişkili toplama dalgasının veya toplama fişinin durum değişikliğinden çıkarılabilir. Kaydedin SCM modüllerindeki toplama işleminin tamamlanma zaman damgasından çıkarılır. Olay türü inferred | |||
| Sipariş iptal edildi | Satış siparişinin tümüyle sevk edilmeden önce iptal edilmesini ifade eder. Farklı nedenlerle gerçekleşebilir ve siparişin son durumu Cancelled olur. | ||
| Neden önemli? Bu, önemli bir istisna akışıdır. İptal edilen siparişleri inceleyerek stok tükenmesi, fiyatlandırma sorunları veya müşterinin karar değiştirmesi gibi temel nedenleri belirleyebilir ve süreç iyileştirmelerine yön verebilirsiniz. Nereden alınır? Satış siparişi başlığının veya kaleminin durumunun Cancelled olarak değişmesinden anlaşılır. Olayı kaydetmek için bu durum değişikliğinin zaman damgası kullanılır. Kaydedin Sipariş başlığının veya kaleminin durumunun Cancelled olarak değiştiği zaman damgasından hesaplanır. Olay türü inferred | |||
| Sipariş kalemi kapatıldı | Tek bir satış siparişi kaleminin tamamen sevk edilip faturalandırıldığını ve başka işlem beklenmediğini gösteren son kapanış adımıdır. Sistem, kalem durumunu Closed olarak günceller. | ||
| Neden önemli? Sipariş kalemlerinin kapatılması, ilgili ürün için tüm sözleşme yükümlülüklerinin tamamlandığını gösterir. Bu adımı inceleyerek teslimat ve ödeme tamamlandıktan uzun süre sonra hâlâ açık kalan siparişleri belirleyebilirsiniz. Nereden alınır? DOO_FULFILL_LINES_ALL tablosunda teslimat kalemi durumunun Closed olarak değişmesinden anlaşılır. Durum değişikliğinin zaman damgası olayı işaretler. Kaydedin Teslimat kaleminin durumunun Closed olarak değiştiği zaman damgasından hesaplanır. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Oracle BI Publisher’a gidin: BI Administrator veya BI Author yetkilerine sahip bir kullanıcıyla Oracle Fusion ortamınızda oturum açın. Navigator menüsünden Tools > Reports and Analytics bölümüne gidin. Business Intelligence Catalog’u açmak için Browse Catalog düğmesine tıklayın.
- Yeni bir veri modeli oluşturun: BI Catalog’da uygun bir klasöre gidin (ör. Shared Folders > Custom). New açılır menüsüne tıklayın ve Data Model’i seçin.
- SQL Query Veri Seti’ni tanımlayın: Data Model düzenleyicisinde + simgesine tıklayarak yeni bir Veri Seti oluşturun ve SQL Query’yi seçin. Bir iletişim kutusu açılır. Veri Seti’ne bir ad verin (ör. OrderToCash_EventLog), Data Source olarak Oracle BI EE’yi, SQL türü olarak da Standard SQL’i seçin.
- SQL sorgusunu girin: Bu belgenin query bölümünde verilen SQL sorgusunun tamamını kopyalayıp SQL Query metin alanına yapıştırın. Sorguda başlangıç ve bitiş tarihleri için parametreler (:p_start_date ve :p_end_date) bulunur; BI Publisher bunları otomatik olarak tanır.
- Veri modeli özelliklerini yapılandırın: Sorguyu yapıştırdıktan sonra OK’e tıklayın. Veri modeli düzenleyicisinin sol bölmesindeki Properties bölümüne gidin. Include Parameter Tags seçeneğinin işaretli olduğundan emin olun. İsterseniz tarih parametreleri için varsayılan değerler de belirleyebilirsiniz.
- Veri modelini görüntüleyin ve kaydedin: Data sekmesine tıklayın. Tarih parametreleri için değer girmeniz istenebilir. Test etmek için kısa bir tarih aralığı girin. Örnek verileri görmek için View’e tıklayın. Veriler doğru görünüyorsa kaydetme simgesine tıklayıp açıklayıcı bir ad vererek veri modelini kaydedin (ör. OrderToCash_EventLog_DM).
- Veri modelinden rapor oluşturun: Veri modelini kaydettikten sonra sağ üst köşedeki Create Report düğmesine tıklayın. Rapor oluşturma sihirbazı açılır.
- Raporu yapılandırın: Sihirbazda Use Data Model seçeneğini belirleyin. Sihirbaz, düzen ayarlarında size yol gösterir. Basit bir CSV dışa aktarımı için Table düzenini seçebilirsiniz. Tüm sütunları tabloya sürükleyip bırakın. Next’e tıklayın, ardından Show Grand Totals Row seçeneğinin işaretini kaldırın. Raporu kaydetmek için Finish’e tıklayın. OrderToCash_EventLog_Report gibi bir ad verin.
- Raporu çalıştırın: Yeni oluşturduğunuz raporu açın. Verileri çıkarmak için başlangıç ve bitiş tarihlerini girmeniz istenir. İstediğiniz tarih aralığını belirtin.
- Verileri dışa aktarın: Rapor çalıştıktan sonra View açılır menüsüne tıklayın ve View Report gibi başka bir görünüm seçeneğini belirleyin. Ardından Export bağlantısını veya simgesini bulun ve dışa aktarma biçimi olarak CSV’yi seçin. Olay günlüğü dosyası indirilir.
- Yüklemeye hazırlanın: İndirdiğiniz CSV dosyasını açın. Sütun başlıklarının gerekli özniteliklerle eşleştiğini doğrulayın: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate ve IsAutomated. Dosya artık Process Mining aracına yüklenmeye hazırdır.
Yapılandırma
- Kullanıcı yetkileri: BI Publisher veri modeli ve rapor oluşturma yetkilerine sahip bir rolünüz olmalıdır. Örneğin BI Administrator veya BI Author rolü.
- Veri kaynağı: Sorgu, işlem veritabanına (Fusion Apps) bağlanan standart Oracle BI EE uygulama veri kaynağı için tasarlanmıştır. Genellikle özel bir yapılandırma gerekmez.
- Tarih aralığı parametreleri: Sorgu, verileri filtrelemek için :p_start_date ve :p_end_date olmak üzere iki parametre kullanır. Rapor zaman aşımını ve performans sorunlarını önlemek için verileri 3 ila 6 aylık dönemler gibi yönetilebilir gruplar halinde çıkarmanız önerilir.
- İş birimi filtresi: Veri çıkarma kapsamını sınırlamak için sorgudaki BaseOrders CTE’ye belirli bir İş birimi kimliğine göre filtre uygulayan bir WHERE koşulu ekleyebilirsiniz (ör. AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID])).
- Sipariş türü filtresi: BaseOrders CTE’deki dhead.SOURCE_ORDER_TYPE_CODE alanına koşul ekleyerek belirli satış siparişi türlerine göre de filtre uygulayabilirsiniz.
- Performans: Birkaç yıla yayılan çok büyük Veri Setleri için bu tek sorgulu yaklaşım yavaş çalışabilir. Sorguyu yoğun olmayan saatlerde çalıştırmayı veya veri çıkarmayı daha küçük, aylık gruplara bölmeyi değerlendirin. Karmaşık UNION sorgularını etkileyebileceğinden, veri modelinde Enable SQL Pruning özelliğinin seçili olmadığından emin olun.
Örnek sorgu sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' Adımlar
- BICC konsoluna erişin: BICC_ADMINISTRATOR rolüne sahip bir kullanıcıyla Oracle Fusion Applications örneğinizde oturum açın. Tools bölümüne gidin ve menüden Business Intelligence Cloud Connector’ı seçin.
- Yeni bir aktarım yapılandırması oluşturun: BICC konsolunda Configure External Storage’a tıklayarak hedef konumunuzu belirleyin. Hedef olarak Oracle Universal Content Management (UCM) veya OCI Object Storage bucket kullanabilirsiniz. Bağlantı bilgilerinizin ve kimlik bilgilerinizin doğru olduğundan emin olun.
- Yeni bir veri çıkarma işi başlatın: Manage Extract Jobs bölümüne gidin. Yeni iş oluşturmak için + simgesine tıklayın. İşe ProcessMind_O2C_SalesOrder_Extract gibi açıklayıcı bir ad verin.
- Data Store’ları (PVO’ları) seçin: İş yapılandırmasında satış siparişi yaşam döngüsünü kaydetmek için gereken Public View Object’leri (PVO) arayıp ekleyin. FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice ve FscmTopModelAM.ArTopAM.CashReceiptApplication dahil olmak üzere birden fazla PVO eklemeniz gerekir.
- Her PVO’nun sütunlarını yapılandırın: Seçtiğiniz her PVO için Actions menüsüne tıklayın ve Select Columns’ı seçin. HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate ve kullanıcı tanımlayıcıları gibi olay günlüğünü oluşturmak için gereken sütunları dikkatle seçin. Her PVO’dan alınması gereken sütunların ayrıntılı listesi için sorgu manifestine bakın.
- Artımlı yüklemeler için filtre uygulayın: Veri hacmini yönetmek için her PVO’ya LastUpdateDate sütununu temel alan bir filtre uygulayın. İlk çalıştırmada geniş bir tarih aralığı seçebilirsiniz. Sonraki zamanlanmış çalıştırmalarda filtreyi, yalnızca son iş çalıştırmasından bu yana güncellenen kayıtları çıkaracak şekilde yapılandırın.
- Veri çıkarma işini zamanlayın: Manage Schedule bölümüne gidin ve işiniz için yeni bir zamanlama oluşturun. Sistem performansına etkisini azaltmak için işi yoğun olmayan saatlerde, örneğin her gece çalıştırmanız önerilir.
- İşi gönderin ve izleyin: Yapılandırma tamamlandığında işi gönderin. İlerlemesini Manage Extract Jobs ekranından izleyebilirsiniz. İş başarıyla tamamlandığında veri dosyaları, yapılandırdığınız bulut depolama konumunda sıkıştırılmış CSV biçiminde kullanılabilir.
- Ham verileri olay günlüğüne dönüştürün: Çıkarılan CSV dosyalarını indirin. BICC, biçimlendirilmiş bir olay günlüğü değil, ham tablo verileri sağlar. Bu dosyaları işlemek için harici bir araç (Python, veritabanı betiği veya ETL platformu gibi) kullanmanız gerekir. İşlem şunları içerir:
- Farklı dosyalardaki verileri birleştirin (ör. fatura verilerini satış siparişi başlığıyla ilişkilendirin).
- Tarih sütunlarını ayrı etkinlik satırlarına dönüştürün. Örneğin FscmTopModelAM.DooTopAM.Header dosyasındaki CreationDate alanını kullanarak Satış siparişi oluşturuldu etkinliği için bir satır, ClosedDate alanını kullanarak Sipariş kapatıldı etkinliği için başka bir satır oluşturun.
- Durum kodlarını veya işaretlerini Sipariş onaylandı ya da Sipariş iptal edildi gibi belirli etkinliklerle eşleştirin.
- Dönüştürülen tüm verileri gerekli sütunları içeren tek bir dosyada birleştirin: SalesOrder, ActivityName ve EventTime.
- Yükleme için biçimlendirin: Dönüştürülmüş son dosyanın, gerekli ve önerilen özniteliklerle eşleşen sütunlara sahip tek bir CSV olduğundan emin olun. Dosya artık ProcessMind’e yüklenmeye hazırdır.
Yapılandırma
- PVO seçimi: Olay günlüğünün doğruluğu, doğru PVO’ları seçmenize bağlıdır. Temel PVO’lar arasında FscmTopModelAM.DooTopAM.Header (sipariş oluşturma ve kapatma için), FscmTopModelAM.ScmTopAM.ShipmentLine (sevkiyat olayları için) ve FscmTopModelAM.ArTopAM.ReceivableInvoice (faturalama için) bulunur.
- Artımlı veri çıkarma: Yinelenen veri çıkarmalarda her zaman LastUpdateDate filtresini kullanın. Bu, performans açısından önemlidir ve aynı çok gigabaytlık Veri Seti’nin tekrar tekrar çıkarılmasını önler. İlk tam yükleme başlangıç verilerini oluşturmalı, sonraki çalıştırmalar ise yalnızca değişiklikleri almalıdır.
- Tarih aralığı: İlk geçmiş veri yüklemesinde, veri bütünlüğü ile yönetilebilir veri hacmi arasında denge kurmak için son 3 ila 6 ay gibi temsili bir dönemi çıkarın. Sonraki çalıştırmalar artımlı olacaktır.
- Depolama yapılandırması: BICC, verileri Oracle UCM’ye veya OCI Object Storage’a aktarabilir. Toplu veri senaryolarında ve sonraki ETL araçlarıyla daha kolay entegrasyon için genellikle OCI Object Storage önerilir.
- İş zamanlama: Oracle Fusion Financials işlem sisteminde olası performans düşüşlerini önlemek için veri çıkarma işlerini mesai saatleri dışında zamanlayın.
- Ön koşullar: İşi yapılandıran kullanıcıların BICC_ADMINISTRATOR rolüne sahip olması gerekir. Bulut depolama kimlik bilgilerini önceden yapılandırmış ve veri çıkarma sonrasında gereken veri dönüştürme mantığını net biçimde anlamış olmanız gerekir.
Örnek sorgu config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering Başlamaya hazır mısınız?
Veri toplama sürecinizi kolaylaştırmak ve Process Mining çalışmalarınıza başlamak için bu Templateten yararlanın. Siparişten Tahsilata - satış siparişi işleme sürecinizi bugün iyileştirmeye başlayın.
Siparişten Tahsilata - satış siparişi işleme sürecinizi bugün iyileştirin
Darboğazları belirleyin ve Siparişten Tahsilata çevrim süresini kolayca %30 azaltın.
Kredi kartı gerekmez. 14 günlük ücretsiz deneme.