Siparişten Tahsilata, satış siparişi işleme Veri Şablonunuz
Siparişten Tahsilata, satış siparişi işleme Veri Şablonunuz
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Pratik veri çıkarma yönlendirmeleri
Siparişten Tahsilata - Satış Siparişi İşleme Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Satış siparişi SalesOrder | Siparişten Tahsilata sürecindeki ana case olarak kullanılan satış siparişinin benzersiz tanımlayıcısıdır. | ||
| Açıklama Sales Order numarası, her müşteri siparişini yaşam döngüsü boyunca benzersiz şekilde tanımlar. İlk oluşturma ve onaydan karşılama, faturalandırma ve son ödemeye kadar ilgili tüm faaliyetleri birbirine bağlayan merkezi bir iz görevi görür. Process Mining'de bu öznitelik, ilgili tüm olayları tek bir case altında gruplamak için gereklidir. Süreci Sales Order bazında analiz etmek, uçtan uca tam bir görünüm sağlar; toplam çevrim sürelerinin hesaplanmasına, tek tek siparişlerin süreç varyantlarının belirlenmesine ve siparişin farklı departmanlar ile sistemlerdeki yolculuğunun izlenmesine imkan verir. Neden önemli? Bu, Case ID'dir. Tüm süreç olaylarını birbirine bağlayarak tek bir müşteri siparişinin uçtan uca yolculuğunun izlenmesini sağlar. Nereden alınır? Bu tanımlayıcı genellikle Oracle Fusion'daki satış siparişleri başlık tablosunda, örneğin DOO_HEADERS_ALL içinde bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler SO-100567SO-100568SO-100569 | |||
| Faaliyet 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 oluşturuldu', 'Ürünler sevk edildi' veya 'Ödeme alındı' gibi belirli bir zamanda satış siparişi için yürütülen adımı açıklar. Bu faaliyetlerin sırası, her case için süreç akışını oluşturur. ActivityName'i analiz etmek Process Mining için temel öneme sahiptir. Süreç haritasının görselleştirilmesini, farklı süreç varyantlarının keşfedilmesini ve case'lerin biriktiği darboğazların belirlenmesini sağlar. Adımlar arasındaki geçiş sürelerinin hesaplanması ve Siparişten Tahsilata sürecinin operasyonel sırasının anlaşılması için temel oluşturur. Neden önemli? Bu öznitelik, süreç haritasındaki adımları tanımlayarak süreç akışının görselleştirilmesini ve analiz edilmesini sağlar. Nereden alınır? Bu, çeşitli Oracle Fusion tablolarındaki işlem durumları veya olay türlerinin, standartlaştırılmış faaliyet adları listesiyle eşleştirilmesiyle oluşturulan türetilmiş bir özniteliktir. Örnekler Satış siparişi oluşturulduÜrünler sevk edildiFatura oluşturulduÖdeme alındı | |||
| Olay zamanı EventTime | Belirli bir faaliyet veya olayın satış siparişi için gerçekleştiği anı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, süreçteki her etkinlik için tarih ve saati sağlayarak olayların kronolojik sırasını oluşturur. Süreç analizinin zamansal temelidir ve her adımın tam olarak ne zaman gerçekleştiğini kaydeder. Process Mining içinde EventTime, çevrim sürelerini, etkinlikler arasındaki süreleri ve genel vaka teslim sürelerini hesaplamak için kritik öneme sahiptir. Performans analizini, bekleme sürelerine dayalı darboğaz tespitini ve zamanlamayla ilgili 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 dayanır. Neden önemli? Bu zaman damgası, olayları kronolojik sıraya koymak ve çevrim süreleri ile süreler gibi zamana dayalı tüm metrikleri hesaplamak için gereklidir. Nereden alınır? Bu, sipariş oluşturma tarihi, sevkiyat tarihi, fatura tarihi ve ödeme tarihi gibi farklı Oracle Fusion tablolarındaki çeşitli zaman damgası alanlarından alınan türetilmiş bir özniteliktir. Ö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, sipariş karşılamanın tamamlandığı tarihi gösteren son teslimat tarihini kaydeder. Planlanan veya talep edilen tarihlerin karşılaştırıldığı gerçek sonucu ifade eder. Bu tarih, zamanında teslimat performansını hesaplamak için RequestedDeliveryDate ile karşılaştırılır. Lojistik ve tedarik zinciri etkililiğini net biçimde ölçen 'On-Time Delivery Rate' KPI değeri ve 'Delivery SLA' Dashboardu için önemli bir girdidir. Neden önemli? Zamanında teslimat oranlarını hesaplamak ve karşılama performansını müşteri taleplerine göre değerlendirmek için kullanılan gerçek sonuç tarihidir. Nereden alınır? Oracle Fusion'daki 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 | Faaliyeti gerçekleştiren kullanıcının adı veya kimliği. | ||
| Açıklama Bu öznitelik, belirli bir süreç adımını yürütmekten sorumlu çalışanı veya sistem kullanıcısını tanımlar. Kullanıcı düzeyinde performansı, iş yükü dağılımını ve standart prosedürlere uyumu analiz etmek için kullanılabilir. Kullanıcı bazında analiz yapmak, eğitim ihtiyaçlarını belirlemeye, yüksek performans gösteren kişi veya ekipleri tanımaya ve belirli kullanıcıların neden olduğu sapmaları incelemeye yardımcı olur. Hangi işlemleri kimin gerçekleştirdiğini izlemek için uyumluluk ve denetim amaçlarıyla da değerlidir. Neden önemli? Kullanıcı bazında performans ve iş yükü dağılımı analizini, ayrıca kişilere bağlı manuel yeniden işleme kalıplarının 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şkilendirilmiş müşteri hesabının yasal adını tanımlar. Süreci müşteri odaklı bir bakışla segmentlere ayırmak ve analiz etmek için temel boyutlardan biridir. Müşteri bazında analiz yapmak, belirli müşterilerin daha uzun çevrim süreleri, daha fazla yeniden işleme veya kendilerine özgü süreç sapmaları yaşayıp yaşamadığını belirlemeye yardımcı olur. Bu içgörü, müşteri hizmetlerini iyileştirmek, önemli hesaplara uygun süreçler tasarlamak ve müşteri memnuniyetini etkileyen sorunları incelemek 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 sağlar. Nereden alınır? Müşteri ana veri tablolarından, örneğin HZ_PARTIES'den alınır ve müşteri kimliği üzerinden satış siparişiyle ilişkilendirilir. Örnekler Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Ödeme vadesi PaymentDueDate | Müşterinin fatura ödemesini yapması gereken son tarih. | ||
| Açıklama Ödeme vadesi, fatura tarihi ve müşteriyle üzerinde anlaşmaya varılan ödeme koşullarına göre hesaplanır. Zamanında tahsilat için son tarihi belirler. Bu öznitelik, 'Zamanında Ödeme Tahsilat Oranı' KPI'ı için gereklidir. Sistem, PaymentDueDate ile gerçek ödeme alma tarihini karşılaştırarak ödemenin zamanında mı yoksa geç mi yapıldığını belirleyebilir. Böylece alacak hesapları performansını izlemeye ve nakit akışını yönetmeye yardımcı olur. Neden önemli? Nakit akışı verimliliğinin temel ölçütlerinden biri olan zamanında ödeme oranlarını hesaplamak için son tarih olarak kullanılır. Nereden alınır? Oracle Fusion içindeki alacak hesapları veya fatura tablolarında, örneğin AR_PAYMENT_SCHEDULES_ALL içinde bulunur. Örnekler 2023-06-192023-07-012023-06-25 | |||
| Otomatik mi IsAutomated | Bir faaliyetin sistem tarafından otomatik olarak mı yoksa kullanıcı tarafından manuel olarak mı gerçekleştirildiğini gösteren işaret. | ||
| Açıklama Bu boolean öznitelik, sistem tarafından yürütülen olaylarla, örneğin otomatik kredi kontrolü veya sistem tarafından oluşturulan fatura ile manuel kullanıcı işlemlerini birbirinden ayırır. Genellikle bir faaliyetle ilişkilendirilmiş kullanıcı adına göre türetilir; genel bir sistem kimliği otomasyonu gösterir. Bu özniteliği analiz etmek, süreçteki otomasyon düzeyini ölçmeye yardımcı olur ve 'Manuel Yeniden İşlenen Siparişler Yüzdesi' KPI'ı için doğrudan girdi sağlar. En fazla zaman alan veya hataya en açık manuel adımları göstererek daha fazla 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 dayanan türetilmiş 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 'Web', 'Direct Sales', 'Partner' veya 'EDI' gibi kaynağını sınıflandırır. Siparişin kuruluşa nasıl girdiği hakkında bağlam sağlar. Süreci satış kanalına göre bölümlere ayırmak, 'Sales Channel Performance Overview' Dashboardu için büyük önem taşır. Farklı kanalların verimliliğini, çevrim sürelerini ve hata oranlarını karşılaştırmanıza yardımcı olur. Böylece en etkili kanalları ve süreç iyileştirmesi ya da daha fazla otomasyon gerektirebilecek kanalları belirleyebilirsiniz. Neden önemli? Kanal bazında performans analizini destekleyerek sipariş işlemede en verimli ve en az verimli kanalları belirlemeye yardımcı olur. Nereden alınır? Bu bilgi, satış siparişi başlığındaki özel bir alanda saklanabilir. Oracle Fusion Financials belgelerine başvurun. Örnekler Doğrudan satışWeb PortalıEDIBayi | |||
| Satış siparişi 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ı ifade eder. İndirimler uygulanmadan önce tüm kalemlerin, vergilerin ve diğer ücretlerin toplamını içerir. Süreç analizinde bu öznitelik, değer bazlı Process Mining için gereklidir. Siparişleri değerlerine göre, örneğin yüksek ve düşük değerli siparişler olarak segmentlere ayırarak farklı süreç yolları veya çevrim süreleri izleyip izlemediklerini görmenizi sağlar. Ayrıca süreç iyileştirme çalışmalarını finansal açıdan en önemli case'lere önceliklendirmenize yardımcı olur. Neden önemli? Finansal etki analizini mümkün kılar; yüksek değerli siparişlerde süreç iyileştirmelerine öncelik vermeye ve maliyet etkenlerini anlamaya yardımcı olur. Nereden alınır? Genellikle Oracle Fusion'daki 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 talep ettiği sipariş teslimat tarihi. | ||
| Açıklama Bu öznitelik, müşterinin ürünleri teslim almak istediği tarihi yakalar. Siparişten Tahsilata sürecinin sipariş karşılama bölümü için önemli bir performans hedefidir. Bu tarih, 'On-Time Delivery Rate' KPI değerini hesaplamak ve 'Delivery Service Level Agreement (SLA)' Dashboardunu desteklemek için gereklidir. Kuruluş, bu tarihi ActualDeliveryDate ile karşılaştırarak müşteri beklentilerini karşılama becerisini ölçebilir ve teslimat gecikmelerinin temel nedenlerini belirleyebilir. Neden önemli? Zamanında teslimat performansını ve müşteri hizmet seviyesi anlaşmasına (SLA) uyumluluğu ölçmek için temel alınır. Nereden alınır? Genellikle Oracle Fusion'daki satış siparişi satır kalemi tablolarında bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler 2023-05-202023-06-012023-05-25 | |||
| Fatura düzeltildi mi IsInvoiceCorrected | Bir faturanın ilk oluşturulmasından sonra düzeltilip düzeltilmediğini gösteren işaret. | ||
| Açıklama Bu boolean öznitelik, bir faturanın 'Invoice Corrected' etkinliğinin varlığıyla gösterilen bir düzeltme döngüsünden geçmesi durumunda true değerini alır. Faturalama aşamasında yeniden çalışma içeren vakaları işaretler. Bu, 'Invoice Accuracy & Rework Analysis' Dashboardu ve 'Invoice Rework Rate' KPI değeri için önemli bir girdidir. Faturalama hatalarının kapsamını ölçmenize, düzeltmelerin neden gerektiğini belirlemek üzere temel neden analizi yapmanıza ve manuel çalışmayı ve ödeme gecikmelerini azaltmanıza yardımcı olur. Neden önemli? Fatura yeniden işlemelerini belirler. Bu, süreç verimsizliğinin, veri kalitesi sorunlarının ve olası ödeme gecikmelerinin önemli bir göstergesidir. Nereden alınır? Bu, hesaplanmış bir alandır. Genellikle bir vakanın olay günlüğünde Invoice Corrected faaliyeti varsa true olarak ayarlanı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 sipariş karşılama etkinliklerini sürecin finansal mutabakat bölümüne bağlar. Sales Order birincil vaka kimliği olsa da Invoice Number, faturalama ve ödeme alt süreçlerini analiz etmek için önemlidir. Fatura düzeltmelerini, anlaşmazlıkları ve ödeme durumunu izlemek için gereklidir ve 'Invoice Accuracy & Rework Analysis' gibi Dashboardları destekler. Neden önemli? Borçlar muhasebesi süreciyle önemli bir bağlantı kurar ve fatura yeniden işleme ile ödeme çevrimlerini analiz etmek için gereklidir. Nereden alınır? Oracle Fusion içindeki RA_CUSTOMER_TRX_ALL gibi borçlar muhasebesi işlem tablolarında bulunur. Örnekler INV-93485INV-93486INV-93487 | |||
| İş birimi BusinessUnitName | Satış siparişinden sorumlu iç iş biriminin adı. | ||
| Açıklama Bu öznitelik, şirket içinde işlemin sahibi olan belirli bölümü veya operasyon birimini ifade eder. Kuruluşun farklı bölümleri arasında performans karşılaştırması yapmanızı sağlar. Süreci iş birimine göre segmentlere ayırmak, şirket genelinde verimlilik, maliyet ve uyumluluk farklılıklarını belirlemeye yardımcı olur. Bu analiz, yüksek performans gösteren birimlerdeki iyi uygulamaların paylaşılmasını sağlayabilir veya hedefli süreç iyileştirmeleri gerektiren düşük performanslı birimleri ortaya çıkarabilir. Neden önemli? Farklı organizasyon birimleri arasında performans kıyaslaması ve süreç tutarlılığı analizi yapılmasını sağlar. Nereden alınır? Genellikle satış siparişi başlığında bulunur ve Oracle Fusion'da tanımlanan organizasyon yapısıyla ilişkilendirilir. Örnekler BU-Kuzey AmerikaBU-EMEAGlobal Services | |||
| Kaynak sistem SourceSystemIdentifier | Olay verilerinin çıkarıldığı kaynak sistemi tanımlar. | ||
| Açıklama Bu öznitelik, verinin kaynağını belirtir ve birden fazla sistemin Siparişten Tahsilata sürecine dahil olduğu ortamlarda özellikle yararlıdır. Örneğin sipariş verileri Oracle Fusion'dan, sevkiyat verileri ise üçüncü taraf bir lojistik sisteminden gelebilir. Analizde bu bilgi, veri soyunun anlaşılmasına 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ı belirlemek için önemlidir. Neden önemli? Veri yönetişimi ve çok sistemli ortamlarda sorun giderme için önemli olan veri kaynağı hakkında bağlam sağlar. Nereden alınır? Bu, genellikle veri çıkarma ve dönüştürme sürecinde Veri Seti'nin kaynağını belirtmek için eklenen statik 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 önemli bir boyuttur. Süreci ülkeye göre segmentlere ayırmak, süreç performansı, çevrim süreleri veya ödeme davranışındaki bölgesel farklılıkları ortaya çıkarabilir. Bu bilgi, yerel düzenlemelerin, lojistik zorlukların ve piyasa koşullarının Siparişten Tahsilata süreci üzerindeki etkisini anlamanıza 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 yapılmasını sağlar. Nereden alınır? Satış siparişiyle ilişkilendirilmiş müşteri ana veri tablolarından (HZ_LOCATIONS, HZ_PARTY_SITES) alınır. Örnekler USAAlmanyaJaponya | |||
| Ödeme gecikmiş mi IsLatePayment | Ödeme, vade tarihinden sonra alındığında true olan hesaplanmış bir işaret. | ||
| Açıklama Bu boolean öznitelik, gerçek ödeme alınma tarihi ile PaymentDueDate karşılaştırılarak türetilir. Bir faturanın zamanında ödenip ödenmediğini açıkça gösterir. Bu öznitelik, On-Time Payment Rate KPI'ını hesaplamak için kullanılır. Zamanında yapılan ve geciken ödemeleri kolayca segmentlere ayırmanızı sağlar. Böylece geç ödeme yapan müşterilerin özelliklerini, gecikmelerin yaygın nedenlerini ve işletme sermayesi üzerindeki finansal etkileri analiz edebilirsiniz. Neden önemli? Tahsilat etkinliğini doğrudan ölçer ve vadesi geçmiş ödemelerin analizini kolaylaştırır. Nereden alınır? Bu, hesaplanmış bir alandır. Mantık şöyledir: PaymentReceivedDate > PaymentDueDate. Örnekler falsetrue | |||
| Ödeme koşulları PaymentTerms | Müşterinin ödeme yapması için üzerinde anlaşmaya varılan koşullar. | ||
| Açıklama Bu öznitelik, müşterinin faturasını hangi koşullarda ödemesi gerektiğini belirtir. Örneğin Net 30 veya Net 60. Bu koşullar PaymentDueDate hesaplamasının temelini oluşturur. Analizde ödeme koşullarına göre segmentasyon yapmak, ödeme çevrim sürelerindeki farklılıkları açıklamaya yardımcı olabilir. Farklı koşullar doğal olarak farklı ödeme davranışlarına yol açtığı için On-Time Payment Rate KPI'ı için bağlam sağlar. Bu bilgiler kredi politikasını ve nakit akışı tahminlerini şekillendirebilir. Neden önemli? Ödeme davranışını analiz etmek 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 içinde satış siparişi veya müşteri hesabı düzeyinde bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler 30 gün vade60 gün vadeMakbuzda ö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 'Ground Freight', 'Air Express' ya da 'Local Courier seçeneklerini ayrıntılı olarak belirtir. Bu bilgi, 'Shipping Method Delivery Compliance' Dashboardu için gereklidir. Farklı yöntemler ve taşıyıcılar arasındaki zamanında teslimat performansını ve sevkiyat maliyetlerini karşılaştırmanıza yardımcı olur. Böylece lojistik stratejinizi ve tedarikçi seçiminizi optimize edebilirsiniz. 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 sipariş karşılama tablolarında bulunur. Oracle Fusion Financials belgelerine başvurun. Örnekler FedEx GroundUPS Next Day AirDHL International | |||
| Sipariş türü OrderType | Satış siparişinin Standard Order veya Return Order gibi sınıflandırması. | ||
| Açıklama Sipariş Türü, satış siparişlerini iş amaçlarına göre kategorilere ayırmak için kullanılır. Yaygın türler arasında standart satışlar, hizmet siparişleri, iade malzeme yetkilendirmeleri (RMA) ve dahili siparişler bulunur. Süreci sipariş türüne göre analiz etmek önemlidir; çünkü farklı türlerin genellikle kendine özgü süreç akışları ve performans hedefleri vardır. Bu segmentasyon, kasıtlı ve beklenen süreç farklılıklarını anlamanıza yardımcı olur ve bunların sapma olarak yorumlanmasını önler. Neden önemli? Adil ve doğru bir analiz için farklı, geçerli süreç akışlarını, örneğin standart siparişler ile iadeleri, segmentlere ayırmanızı sağlar. Nereden alınır? Genellikle Oracle Fusion içindeki 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'nde en son ne zaman çıkarıldığını veya güncellendiğini kaydeder. Analiz edilen verilerin güncelliği hakkında şeffaflık sağlar. Bu bilgi, kullanıcıların süreç analizinin ne kadar güncel olduğunu anlaması için önemlidir. Verilerin güncelliğiyle ilgili beklentileri yönetmeye, veri yenileme planlarını oluşturmaya ve izlemeye yardımcı olur. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizlerinin ne kadar güncel olduğunu bilmesini 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 zaman damgasıyla işlenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Teslimat zamanında mı IsOnTimeDelivery | Gerçek teslimat, talep edilen teslimat tarihinde veya daha önce gerçekleştiğinde true olan hesaplanmış bir işaret. | ||
| Açıklama Bu boolean öznitelik, ActualDeliveryDate ile RequestedDeliveryDate karşılaştırılarak türetilir. Teslimat performansını vaka düzeyinde gösteren basit bir ölçü sağlar. Bu işaret, toplam On-Time Delivery Rate KPI'ının hesaplanmasının temelini oluşturur. Filtreleme ve analizi kolaylaştırarak geciken tüm siparişleri hızlıca ayırmanıza ve gecikmelere yol açan etkenler için kök neden analizi yapmanıza imkan verir. Neden önemli? Sipariş karşılama 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 | |||
| Ürün adı ProductName | Satılan ürünün veya hizmetin adı. | ||
| Açıklama Bu öznitelik, satış siparişi satırındaki ürünü tanımlar. Siparişte birden fazla satır varsa case, satır kalemi düzeyinde analiz edilebilir veya bu öznitelik başlık düzeyinde toplulaştırılabilir. Ürün bazında analiz yapmak, belirli ürünlerin sık teslimat gecikmeleri veya ödeme sorunları gibi daha karmaşık ya da sorunlu süreç akışlarıyla ilişkili olup olmadığını anlamaya yardımcı olur. Bu bilgi, ürün yönetimi ve tedarik zinciri stratejilerine yön verebilir. Neden önemli? Farklı ürünler için süreç performansının analiz edilmesini ve karmaşık karşılama veya faturalandırma yolları izleyebilecek ürünlerin belirlenmesini sağlar. Nereden alınır? Satış siparişi satır kalemi 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 | |||
Siparişten Tahsilata - Satış Siparişi İşleme Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura oluşturuldu | Bu faaliyet, genellikle sevkiyat onayı olayı tarafından başlatılan Accounts Receivable modülündeki müşteri faturasının oluşturulmasını ifade eder. Benzersiz numarası ve oluşturulma tarihi bulunan bir fatura kaydı oluşturulur. | ||
| Neden önemli? Tahsilat döngüsünün resmi başlangıcını gösterir. 'Faturadan Ödemeye Kadar Geçen Süre'nin ve genel nakit akışı verimliliğinin ölçülmesi için temel oluşturur. Nereden alınır? Oracle Accounts Receivable (AR) içinde açıkça kaydedilen bir olaydır. İşlem tarihi bulunan fatura kaydı RA_CUSTOMER_TRX_ALL tablosunda oluşturulur. Yakalayın AR modülündeki fatura işleminin oluşturulma tarihinden alınır. Olay türü explicit | |||
| Ödeme alındı | Bu faaliyet, müşterinin ödemesinin alındığını ve Accounts Receivable içinde faturaya mahsup edildiğini gösterir. Nakit tahsilat mahsup kaydı işlendiğinde kaydedilir. | ||
| Neden önemli? Bu önemli kilometre taşı, 'Genel Siparişten Tahsilata Çevrim Süresi' ve 'Zamanında Ödeme Oranı'nı ölçmek için kullanılır. Satışın nakde dönüşmesini gösterir. 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 kaydedilir. Yakalayın AR içindeki nakit tahsilat mahsup kaydının 'mahsup tarihi' zaman damgasından alınır. Olay türü explicit | |||
| Satış siparişi oluşturuldu | Bu faaliyet, Oracle Fusion içine yeni bir satış siparişinin girildiği anı göstererek satış siparişi sürecinin başlangıcını belirtir. Kullanıcı Sipariş Yönetimi modülünde yeni sipariş kaydını kaydettiğinde bu olay genellikle açıkça kaydedilir. | ||
| Neden önemli? Sürecin başlangıcını gösteren bu faaliyet, genel Siparişten Tahsilata çevrim süresini ölçmek ve alınan sipariş hacmini analiz etmek için gereklidir. Nereden alınır? Sales Order kaydının Order Management Cloud içinde oluşturulmasıyla açıkça kaydedilir. DOO_HEADERS_ALL tablosundaki oluşturma zaman damgalarını kontrol edin. Yakalayın Sales Order başlık kaydının oluşturulma zaman damgasından alınır. Olay türü explicit | |||
| Sipariş kapatıldı | Süreçteki son faaliyettir. Satış siparişindeki tüm satırların karşılandığını, faturalandırıldığını ve kapatıldığını gösterir. Sipariş başlığının durumu 'Kapalı' olarak güncellenir. | ||
| Neden önemli? Bu faaliyet, 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 zombi siparişleri belirlemek için gereklidir. Nereden alınır? DOO_HEADERS_ALL tablosunda satış siparişi başlığının durumu 'Kapalı' olarak değiştiğinde çıkarılır. Bu son durum değişikliğinin zaman damgası olay zamanı olarak kullanılır. Yakalayın Satış siparişi başlığındaki durumun 'Kapalı' olarak değiştiği zaman damgasından elde edilir. Olay türü inferred | |||
| Sipariş onaylandı | Bu önemli kilometre taşı, satış siparişinin kredi onayı dahil tüm ilk kontrolleri geçtiğini ve artık karşılanmak üzere taahhüt edildiğini gösterir. Genellikle sipariş durumu 'Sevkiyat Bekleniyor' veya 'Planlandı' gibi bir duruma ilerlediğinde çıkarılır. | ||
| Neden önemli? Bu faaliyet, 'Ortalama Sipariş Onaylama Süresi'ni hesaplamak için önemli bir kilometre taşıdır ve sipariş girişinden karşılama sürecine geçişi gösterir. Nereden alınır? Sales Order başlığının veya satırının durumu, siparişin karşılanmaya hazır olduğunu gösteren bir değere, örneğin 'Sevkiyat Bekleniyor' durumuna değiştiğinde çıkarılır. DOO_HEADERS_ALL veya DOO_FULFILL_LINES_ALL tablolarındaki durum sütunlarını kontrol edin. Yakalayın Sipariş durumunun onaylandı veya planlandı durumuna değiştiği zaman damgasından elde edilir. Olay türü inferred | |||
| Ürünler sevk edildi | Bu faaliyet, ürünlerin depodan gönderildiği ve müşteriye doğru yolda olduğu anı gösterir. Oracle Shipping içinde sevkiyat onayı işlemi yürütüldüğünde kaydedilir. | ||
| Neden önemli? Bu önemli kilometre taşı, 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 içinde açıkça kaydedilen bir olaydır. Sevkiyat onayı işlemi, WSH_DELIVERY_DETAILS gibi sevkiyat tablolarında sevkiyat tarihi bulunan bir kayıt oluşturur. Yakalayın 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 | |||
| Fatura düzeltildi | Daha önce oluşturulmuş bir fatura hatalar veya müşteri itirazları nedeniyle değiştirildiğinde, yeniden düzenlendiğinde ya da alacaklandırıldığında gerçekleşir. Genellikle alacak dekontu veya faturanın yeni bir sürümü oluşturularak kaydedilir. | ||
| Neden önemli? Fatura düzeltmelerini izlemek, 'Fatura Yeniden İşleme Oranı' KPI'ı için önemlidir. Bu, ödemeleri geciktirebilecek ve idari maliyetleri artırabilecek faturalandırma süreci sorunlarını ortaya çıkarır. Nereden alınır? Orijinal faturayla ilişkilendirilmiş bir alacak dekontunun veya RA_CUSTOMER_TRX_ALL tablosunda aynı faturanın sonraki bir sürümünün oluşturulmasından çıkarılır. Yakalayın Önceki bir fatura işlemine referans veren alacak dekontları veya faturalar belirlenerek elde edilir. Olay türü inferred | |||
| Kredi bekletmesi uygulandı | Bu faaliyet, başarısız bir kredi kontrolü veya krediyle ilgili başka bir sorun nedeniyle satış siparişinin otomatik ya da manuel olarak bekletmeye alınmasıyla gerçekleşir. Genellikle sistemdeki sipariş bekletme durumunun değişmesiyle kaydedilir. | ||
| Neden önemli? Kredi bekletmelerini izlemek, sipariş işleme gecikmelerinin nedenlerini belirlemek ve kredi bekletmesini kaldırma sürecinin verimliliğini ölçmek için önemlidir. Nereden alınır? Sales Order üzerine bekletme uygulanmasından çıkarılır. Bu bilgi genellikle satış siparişiyle ilişkilendirilmiş DOO_HOLDS_ALL gibi bekletmeyle ilgili tablolara kaydedilir. Yakalayın Bekletme tablosunda 'Credit' türünde bir kayıt oluşturulmasından çıkarılır. Olay türü inferred | |||
| Kredi kontrolü gerçekleştirildi | Müşterinin kredi değerliliğini değerlendirmek için hesabına yönelik kredi kontrolünün gerçekleştirilmesini ifade eder. Bu, sipariş işleme iş akışındaki otomatik veya manuel bir adım olabilir ve tamamlanması genellikle bir durum güncellemesi veya tamamlanmış bir Task olarak kaydedilir. | ||
| Neden önemli? Kredi kontrollerinin ne kadar sürdüğünü analiz etmek, sipariş onayındaki darboğazları belirlemeye yardımcı olur. Bu metrik, 'Kredi Kontrolünden Onaya Kadar Geçen Süre' KPI'ı için gereklidir. Nereden alınır? Sales Order üzerindeki durum değişikliklerinden, örneğin 'Kredi Onayı Bekleniyor' durumuna geçişten veya kredi yönetimi işlevindeki açık bir Event Log kaydından çıkarılabilir. Yakalayın Sipariş durumu değişikliklerinden veya kredi inceleme görevleriyle ilişkili zaman damgalarından çıkarılır. Olay türü inferred | |||
| Sipariş iptal edildi | Satış siparişinin tamamen sevk edilmeden önce iptal edilmesini ifade eder. Bu durum çeşitli nedenlerle gerçekleşebilir ve son durum 'İptal Edildi' olur. | ||
| Neden önemli? Bu, önemli bir istisna yoludur. İptal edilen siparişleri analiz etmek, stok tükenmesi, fiyatlandırma sorunları veya müşterinin fikrini değiştirmesi gibi temel nedenleri belirlemeye yardımcı olur ve süreç iyileştirmelerine yön verir. Nereden alınır? Satış siparişi başlığının veya satırının durumu 'İptal Edildi' durumuna değiştiğinde çıkarılır. Bu durum değişikliğinin zaman damgası olayı kaydetmek için kullanılır. Yakalayın Sipariş başlığında veya satırında durumun 'İptal Edildi' olarak değiştiği zaman damgasından elde edilir. Olay türü inferred | |||
| Sipariş satırı kapatıldı | Tek bir satış siparişi satırının tamamen kapatıldığını, tamamen sevk edildiğini ve faturalandırıldığını, başka işlem beklenmediğini gösterir. Sistem satır durumunu 'Kapalı' olarak günceller. | ||
| Neden önemli? Sipariş satırlarının kapatılması, ilgili ürün için tüm sözleşme yükümlülüklerinin tamamlandığını gösterir. Bu bilgiyi analiz etmek, karşılama ve ödeme tamamlandıktan uzun süre sonra hâlâ açık kalan siparişleri belirlemeye yardımcı olur. Nereden alınır? DOO_FULFILL_LINES_ALL tablosunda karşılama satırı durumunun 'Kapalı' olarak değişmesinden çıkarılır. Bu durum değişikliğinin zaman damgası olayı belirtir. Yakalayın Karşılama satırındaki durumun 'Kapalı' olarak değiştiği zaman damgasından elde edilir. Olay türü inferred | |||
| Stok rezerve edildi | Bu faaliyet, satış siparişi satırını karşılamak için fiziksel stokun tahsis edilmesini veya rezerve edilmesini ifade eder. Sistem belirli stokları ayırarak sipariş toplanmaya hazır olduğunda bunların kullanılabilir olmasını sağlar. | ||
| Neden önemli? Bu bilgiyi izlemek, 'Stok Tahsis Teslim Süresi' KPI'ını analiz etmeye ve sipariş onayıyla ürünlerin güvence altına alınması arasındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? Bu olay genellikle stok veya tedarik zinciri yürütme modüllerinde kaydedilir. Karşılama satırındaki durum güncellemelerinden, stokun ayrıntılandırıldığını veya rezerve edildiğini gösteren değişikliklerden çıkarılabilir. Yakalayın Stok rezervasyonu veya planlamayla ilgili karşılama satırı durumu değişikliklerinden çıkarılır. Olay türü inferred | |||
| Ürünler teslim edildi | Müşterinin gönderiyi teslim aldığını gösterir. Bu bilgi genellikle harici taşıyıcıdan gelir ve Oracle Fusion'a aktarılır veya sevkiyat tarihine standart taşıma süresi eklenerek çıkarılır. | ||
| Neden önemli? Bu faaliyet, 'Zamanında Teslimat Oranı' KPI'ını doğru hesaplamak ve müşteri hizmeti seviyelerini ölçmek için gereklidir. Nereden alınır? Bu genellikle Oracle'a özgü bir olay değildir. Taşıyıcı entegrasyonu varsa kaydedilebilir veya 'Ürünler Sevk Edildi' tarihine standart taşıma süresi eklenerek hesaplanabilir. Sistem analizi gerektirir. Yakalayın 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 | |||
| Ürünler toplandı | Siparişi karşılamak için ürünlerin depodan fiziksel olarak toplanmasını ifade eder. Bu, lojistik sürecinin önemli bir adımıdır ve genellikle depo yönetimi veya sevkiyat modülünde kaydedilir. | ||
| Neden önemli? Bu faaliyet, depo operasyonlarını görünür kılar. Stok rezervasyonu ile toplama arasındaki gecikmeler, depodaki kaynak veya süreç darboğazlarına işaret edebilir. Nereden alınır? Oracle Fusion Cloud SCM (Supply Chain Management) modüllerinde kaydedilir. Satış siparişi satırıyla ilişkili toplama dalgası veya toplama fişinin durum değişikliğinden çıkarılabilir. Yakalayın SCM modüllerindeki toplama işleminin tamamlanma zaman damgasından çıkarılır. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Oracle BI Publisher'a erişin: BI Administrator veya BI Author yetkilerine sahip bir kullanıcıyla Oracle Fusion ortamınıza giriş yapın. Navigator menüsünden Tools > Reports and Analytics yolunu izleyin. Business Intelligence Catalog'u açmak için 'Browse Catalog' düğmesine tıklayın.
- Yeni bir Veri Modeli oluşturun: BI Catalog içinde uygun bir klasöre, örneğin Shared Folders > Custom yoluna gidin. 'New' açılır menüsüne tıklayın ve 'Data Model' seçeneğini belirleyin.
- SQL Query Veri Seti tanımlayın: Data Model düzenleyicisinde yeni bir Veri Seti oluşturmak için '+' simgesine tıklayın ve 'SQL Query' seçeneğini belirleyin. Bir iletişim kutusu açılır. Veri Seti'ne bir ad verin, örneğin 'OrderToCash_EventLog', Data Source olarak 'Oracle BI EE'yi ve SQL türü olarak 'Standard SQL'i seçin.
- SQL Query'yi girin: Bu belgenin 'query' bölümünde verilen SQL Query'nin tamamını kopyalayın ve SQL Query metin alanına yapıştırın. Query, BI Publisher tarafından otomatik olarak tanınacak başlangıç ve bitiş tarihi parametrelerini (:p_start_date ve :p_end_date) içerir.
- Veri Modeli özelliklerini yapılandırın: Query'yi yapıştırdıktan sonra 'OK' düğmesine 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 Modeli'ni görüntüleyin ve kaydedin: 'Data' sekmesine tıklayın. Tarih parametreleri için değer girmeniz istenebilir. Test amacıyla kısa bir tarih aralığı girin. Örnek verileri görmek için 'View' düğmesine tıklayın. Veriler doğru görünüyorsa kaydetme simgesine tıklayarak Veri Modeli'ni açıklayıcı bir adla kaydedin, örneğin 'OrderToCash_EventLog_DM'.
- Veri Modeli'nden rapor oluşturun: Veri Modeli kaydedildikten 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österecektir. Basit bir CSV dışa aktarımı için 'Table' düzenini seçebilirsiniz. Tüm sütunları sürükleyip tabloya bırakın. 'Next' düğmesine tıklayın, ardından 'Show Grand Totals Row' seçeneğinin işaretini kaldırın. Raporu kaydetmek için 'Finish' düğmesine tıklayın. Rapora 'OrderToCash_EventLog_Report' gibi bir ad verin.
- Raporu çalıştırın: Yeni oluşturduğunuz raporu açın. Veri çıkarma işlemi 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 farklı bir görünüm seçin. Ardından 'Export' bağlantısını veya simgesini bulun ve dışa aktarma biçimi olarak 'CSV'yi seçin. Böylece olay günlüğü dosyası indirilir.
- Yükleme için hazırlayı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 Administrator' veya 'BI Author' gibi BI Publisher Veri Modeli ve rapor oluşturma yetkilerine sahip bir role sahip olmanız gerekir.
- Veri kaynağı: Query, işlemsel 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: Query, 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 önemle önerilir.
- İş birimi filtresi: Veri çıkarma kapsamını daraltmak için Query içindeki BaseOrders CTE'ye belirli bir İş Birimi kimliğine göre filtre uygulayan bir WHERE koşulu ekleyebilirsiniz, örneğin AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Sipariş türü filtresi: BaseOrders CTE içinde 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 Query yaklaşımı yavaş çalışabilir. İşlemi yoğun olmayan saatlerde çalıştırmayı veya veri çıkarma işlemini daha küçük, aylık gruplara bölmeyi düşünün. Karmaşık UNION Query'lerini etkileyebileceği için Veri Modeli'nde 'Enable SQL Pruning' özelliğinin seçili olmadığından emin olun.
a Ö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 Console'a erişin: BICC_ADMINISTRATOR rolüne sahip bir kullanıcıyla Oracle Fusion Applications örneğinize giriş yapın. Tools menüsüne gidin ve Business Intelligence Cloud Connector'ı seçin.
- Yeni bir Offering oluşturun: BICC Console içinde hedef konumunuzu ayarlamak için Configure External Storage seçeneğine tıklayın. 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 Extract Job başlatın: Manage Extract Jobs bölümüne gidin. Yeni bir iş oluşturmak için + simgesine tıklayın. İşe açıklayıcı bir ad verin, örneğin ProcessMind_O2C_SalesOrder_Extract.
- 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'lar) 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 için sütunları yapılandırın: Seçtiğiniz her PVO için Actions menüsüne tıklayın ve Select Columns seçeneğini belirleyin. 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 için gerekli sütunların ayrıntılı listesi için Query manifestosuna bakın.
- Artımlı yüklemeler için filtre uygulayın: Veri hacmini yönetmek için her PVO'ya LastUpdateDate sütununa göre filtre uygulayın. İlk çalıştırmada geniş bir tarih aralığı seçebilirsiniz. Sonraki planlı çalıştırmalarda bu filtre, yalnızca son iş çalıştırmasından bu yana güncellenen kayıtları çıkaracak şekilde yapılandırılmalıdır.
- Veri çıkarma işini planlayın: Manage Schedule bölümüne gidin. İş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. İlerlemeyi 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 Python, veritabanı betiği veya ETL platformu gibi harici bir araç kullanmanız gerekir. Bu işlem şunları içerir:
- Farklı dosyalardaki verileri birleştirme, örneğin fatura verilerini satış siparişi başlığına bağlama.
- Tarih sütunlarını ayrı aktivite satırlarına dönüştürme. Örneğin FscmTopModelAM.DooTopAM.Header dosyasından CreationDate alanını kullanarak Sales Order Created, ClosedDate alanını kullanarak da Order Closed için birer satır oluşturun.
- Durum kodlarını veya işaretlerini Order Confirmed ya da Order Cancelled gibi belirli aktivitelere eşleme.
- Dönüştürülen tüm verileri gerekli sütunları içeren tek bir dosyada birleştirme: SalesOrder, ActivityName ve EventTime.
- Yükleme için biçimlendirin: Son dönüştürülmüş 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 tamamen doğru PVO'ların seçilmesine 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: Tekrarlanan veri çıkarma işlemlerinde 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 bir temel oluşturmalı, sonraki çalıştırmalar yalnızca değişiklikleri almalıdır.
- Tarih aralığı: İlk geçmiş veri yüklemesinde, eksiksizlik ile yönetilebilir veri hacmi arasında denge kurmak için son 3 ila 6 aylık veriler gibi temsil niteliğinde bir dönem çıkarın. Sonraki çalıştırmalar artımlı olacaktır.
- Depolama yapılandırması: BICC, Oracle'ın UCM'sine veya OCI Object Storage'a dışa aktarım yapabilir. Toplu veri senaryolarında ve sonraki ETL araçlarıyla daha kolay entegrasyon için genellikle OCI Object Storage kullanılması önerilir.
- İş zamanlaması: Oracle Fusion Financials işlemsel sisteminde olası performans düşüşlerini önlemek için veri çıkarma işlerini mesai dışı saatlere planlayın.
- Ön koşullar: İşi yapılandıran kullanıcıların BICC_ADMINISTRATOR rolüne sahip olması gerekir. Önceden yapılandırılmış bulut depolama kimlik bilgilerine ve veri çıkarma sonrasında gereken veri dönüştürme mantığına ilişkin net bir anlayışa sahip olmalısınız.
a Ö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 yolculuğunuza başlamak için bu şablondan yararlanın. Siparişten Tahsilata, satış siparişi işleme sürecinizi bugün optimize etmeye başlayın.
Siparişten Tahsilata - Satış Siparişi İşleme sürecinizi bugün optimize edin
Darboğazları belirleyin ve Siparişten Tahsilata çevrim süresini kolayca %30 azaltın.
Kredi kartı gerekmez, 14 günlük ücretsiz deneme.