Order to Cash - Satış Siparişi Süreci Veri Template'inuz
Order to Cash - Satış Siparişi Süreci Veri Template'inuz
- Önerilen Öznitelikler
- İzlenecek Temel Etkinlikler
- Pratik veri veri çekme kılavuzu
Siparişten Nakde - Satış Siparişi Süreci Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Satış Siparişi SalesOrder | Satış siparişi için benzersiz tanımlayıcı, Siparişten Tahsilata sürecinin birincil vakası olarak olarak kullanılır. | ||
| Açıklama Satış Siparişi numarası, her müşteri siparişini süreç döngüsü boyunca benzersiz bir şekilde tanımlar. İlk oluşturma ve onaydan yerine getirme, faturalandırma ve nihai ödemeye kadar tüm ilgili etkinlikleri birbirine bağlayan merkezi bir bağlantı görevi görür. Process Mining'de bu öznitelik, tüm ilgili olayları tek bir vaka altında gruplandırmak için gereklidir. Süreci Satış Siparişine göre analiz etmek, toplam döngü sürelerinin hesaplanmasına, bireysel siparişler için süreç varyantlarının belirlenmesine ve bir siparişin farklı departmanlar ve sistemler aracılığıyla yolculuğunun izlenmesine olanak tanıyan eksiksiz bir uçtan uca görünüm sunar. Neden Önemli?dir? Bu, Vaka Kimliğidir. Tüm süreç olaylarını birbirine bağlayarak tek bir müşteri siparişinin tüm sürecini izlemeyi sunar. Nereden Alınır?? Bu tanımlayıcı genellikle Oracle Fusion'daki satış siparişlerinin üst tablosunda (örneğin DOO_HEADERS_ALL) bulunur. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: SO-100567SO-100568SO-100569 | |||
| Aktivite Adı ActivityName | Satış siparişi sürecinde meydana gelen belirli iş olayı veya görevinin adı. | ||
| Açıklama Bu öznitelik, bir satış siparişi için belirli bir zamanda yürütülen adımı açıklar; örneğin 'Satış Siparişi Oluşturuldu', 'Mallar Sevk Edildi' veya 'Ödeme Alındı'. Bu etkinliklerin sırası, her vaka için süreç akışını oluşturur. Aktivite Adı'nı analiz etmek Process Mining için büyük önem taşır. Süreç haritasının görselleştirilmesine, farklı süreç varyantlarının keşfedilmesine ve vakaların biriktiği darboğazların belirlenmesine sunar. Adımlar arasındaki geçiş sürelerini hesaplamak ve Siparişten Tahsilata sürecinin operasyonel dizisini anlamak için temel teşkil eder. Neden Önemli?dir? Bu öznitelik, süreç haritasındaki adımları tanımlayarak süreç akışının görselleştirilmesine ve analizine sunar. Nereden Alınır?? Bu, çeşitli Oracle Fusion tablolarındaki (örneğin, sipariş durumu, sevkiyat durumu, fatura durumu) işlem durumlarını veya olay türlerini standartlaştırılmış bir etkinlik adları listesine eşleyerek oluşturulan türetilmiş bir özniteliktir. Örnekler::::::: Satış Siparişi OluşturulduMallar Sevk EdildiFatura OluşturulduÖ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ı (zaman damgası)dır. | ||
| Açıklama Bu öznitelik, süreçteki her etkinlik için tarih ve saat sunar ve olayların kronolojik sırasını belirler. Süreç analizinin temel zaman referansıdır, her adımın tam olarak ne zaman gerçekleştiğini kaydeder. Process Mining'de, (EventTime) döngü sürelerini, etkinlikler arasındaki süreleri ve genel vaka teslim sürelerini hesaplamak için büyük önem taşır. Performans analizine, bekleme sürelerine dayalı darboğaz tespitine ve zamanlılıkla ilgili hizmet seviyesi anlaşmalarına (SLA'lar) uyumluluğun izlenmesine sunar. Tüm zaman tabanlı KPI'lar ve kontrol panelleri bu özniteliğin doğruluğuna dayanır. Neden Önemli?dir? Bu zaman damgası (zaman damgası), olayları kronolojik olarak sıralamak ve döngü süreleri ve süreler gibi tüm zaman tabanlı 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ı (zaman damgası) alanlarından türetilmiş bir özniteliktir. Örnekler::::::: 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Gerçek Teslim Tarihi ActualDeliveryDate | Malların müşteriye fiilen teslim edildiği tarih. | ||
| Açıklama Bu öznitelik, sürecin yerine getirme bölümünün tamamlandığını işaret eden nihai teslimat tarihini kaydeder. Planlanan veya talep edilen tarihlere karşı ölçülen fiili sonuçtur. Bu tarih, zamanında teslimat performansını hesaplamak için Talep Edilen Teslim Tarihi ile karşılaştırılır. 'Zamanında Teslimat Oranı (OTD) KPI'ı'ı ve 'Teslimat SLA' kontrol paneli için kritik bir girdidir, lojistik ve tedarik zinciri etkinliğinin net bir ölçüsünü sunar. Neden Önemli?dir? Zamanında teslimat oranlarını hesaplamak ve müşteri taleplerine karşı yerine getirme performansını değerlendirmek için kullanılan fiili sonuç tarihidir. Nereden Alınır?? Oracle Fusion'daki nakliye ve teslimat işlem tablolarından alınır. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: 2023-05-202023-06-032023-05-25 | |||
| Kullanıcı Adı UserName | Aktiviteyi 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ı ve standart prosedürlere uyumu analiz etmek için kullanılabilir. Kullanıcıya göre analiz, eğitim ihtiyaçlarını belirlemeye, yüksek performans gösteren bireyleri veya ekipleri tanımaya ve belirli kullanıcıların neden olduğu sapmaları araştırmaya yardımcı olur. Ayrıca, kimin hangi eylemleri gerçekleştirdiğini izlemek için uyumluluk ve denetim amaçları için de değerlidir. Neden Önemli?dir? Kullanıcıya göre performans analizi, iş yükü dağılımı ve bireylere bağlı manuel yeniden işleme kalıplarının belirlenmesini sunar. Nereden Alınır?? Genellikle Oracle Fusion işlem tablolarındaki CREATED_BY veya LAST_UPDATED_BY gibi alanlardan alınır, sıklıkla FND_USER gibi bir kullanıcı ana tablosuna bağlıdır. Ö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ı bir bakış açısıyla segmentlere ayırmak ve analiz etmek için temel bir boyuttur. Müşteriye göre analiz, belirli müşterilerin daha uzun döngü süreleri, daha fazla yeniden işleme veya belirli süreç sapmaları yaşayıp yaşamadığını belirlemeye yardımcı olur. Bu önemli bilgi, müşteri hizmetlerini iyileştirmek, önemli hesaplar için süreçleri uyarlamak ve müşteri memnuniyetini etkileyen sorunları araştırmak için kullanılabilir. Neden Önemli?dir? Belirli müşterileri etkileyen süreç sorunlarını belirlemek ve müşteri odaklı analizi sunar. Nereden Alınır?? Müşteri ana veri tablolarından (örneğin, HZ_PARTIES) alınır ve bir müşteri kimliği aracılığıyla satış siparişine bağlanır. Örnekler::::::: Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Otomatikleştirildi mi? IsAutomated | Bir aktivitenin sistem tarafından `otomatik` mi yoksa bir kullanıcı tarafından `manuel` mi gerçekleştirildiğini gösteren bir göstergedir. | ||
| Açıklama Bu boolean öznitelik, sistem odaklı olaylar (örneğin, otomatik kredi kontrolü, sistem tarafından oluşturulan fatura) ile manuel kullanıcı eylemlerini birbirinden ayırır. Genellikle bir etkinlikle ilişkili kullanıcı adına göre türetilir, burada genel bir sistem kimliği otomasyonu gösterir. Bu özniteliği analiz etmek, süreçteki otomasyon seviyesini ölçmeye yardımcı olur ve 'Manuel Yeniden İşlenen Siparişler Yüzdesi' KPI'ı için doğrudan bir girdidir. Hangi manuel adımların en çok zaman alan veya hataya açık olduğunu göstererek daha fazla otomasyon fırsatlarını vurgulayabilir. Neden Önemli?dir? Süreçteki otomasyon seviyesini ölçmeye ve maliyetli manuel müdahaleleri azaltma fırsatlarını belirlemeye yardımcı olur. Nereden Alınır?? Bu, genellikle KullanıcıAdı özniteliğine uygulanan bir kurala dayalı türetilmiş bir alandır. Örneğin, kullanıcı 'Sistem' veya 'TOPLU' ise, bu alan 'true' olarak belirlenir. Örnekler::::::: truefalse | |||
| Satış Kanalı SalesChannel | Satış siparişinin alındığı kanal. | ||
| Açıklama Bu öznitelik, satış siparişinin kökenini 'Web', 'Doğrudan Satış', 'Ortak' veya 'EDI' gibi kategorize eder. Siparişin kuruluşa nasıl girdiğine dair bağlam sunar. Süreci satış kanalına göre segmentlere ayırmak, 'Satış Kanalı Performans Genel Bakışı' kontrol paneli için büyük önem taşır. Farklı kanalların verimliliğini, döngü sürelerini ve hata oranlarını karşılaştırarak hangilerinin en etkili olduğunu ve hangilerinin süreç iyileştirmeleri veya daha fazla otomasyon gerektirebileceğini belirlemeye yardımcı olur. Neden Önemli?dir? Kanal bazında performans analizini destekler, sipariş işleme için en verimli ve en az verimli kanalları belirlemeye yardımcı olur. Nereden Alınır?? Bu bilgi, satış siparişi başlığında özel bir alanda saklanabilir. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: Doğrudan SatışWeb PortalEDIBayi | |||
| Satış Siparişi Toplam Tutarı SalesOrderTotalAmount | Satış siparişinin toplam parasal değeri. | ||
| Açıklama Bu öznitelik, tüm satış siparişi için müşteriye yansıtılan toplam tutarı temsil eder. Tüm kalemlerin, vergilerin ve diğer ücretlerin toplamını, herhangi bir indirim uygulanmadan önce içerir. Süreç analizinde bu öznitelik, değer tabanlı Process Mining için büyük önem taşır. Siparişleri değere göre segmentlere ayırmaya (örneğin, yüksek değerliye karşı düşük değerli siparişler) olanak tanıyarak farklı süreç yollarını izleyip izlemediklerini veya farklı döngü sürelerine sahip olup olmadıklarını görmeyi sunar. Ayrıca, finansal olarak en önemli vakalara süreç iyileştirme çabalarını önceliklendirmeye yardımcı olur. Neden Önemli?dir? Finansal etki analizine sunar, yüksek değerli siparişlerde süreç iyileştirmelerine öncelik verilmesine ve maliyet faktörlerinin anlaşılmasına yardımcı olur. Nereden Alınır?? Genellikle Oracle Fusion'daki satış siparişi başlık tablolarında bulunur. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: 5250.00125000.75980.50 | |||
| Son Ödeme Tarihi PaymentDueDate | Müşterinin fatura için ödeme yapması gereken tarih. | ||
| Açıklama Son Ödeme Tarihi, fatura tarihi ve müşteriyle üzerinde anlaşılan ödeme koşullarına göre hesaplanır. Zamanında ödeme tahsilatı için son tarihi belirler. Bu öznitelik, 'Zamanında Ödeme Tahsilat Oranı' KPI'ı için büyük önem taşır. Sistem, Son Ödeme Tarihi ile fiili ödeme tahsilat tarihini karşılaştırarak bir ödemenin zamanında mı yoksa gecikmeli mi olduğunu belirleyebilir, bu da alacak hesapları performansını izlemeye ve nakit akışını yönetmeye yardımcı olur. Neden Önemli?dir? Nakit akışı verimliliğinin temel bir ölçüsü olan zamanında ödeme oranlarını hesaplamak için son tarih görevi görür. Nereden Alınır?? AR_PAYMENT_SCHEDULES_ALL gibi Oracle Fusion'daki alacak hesapları veya fatura tablolarında bulunur. Örnekler::::::: 2023-06-192023-07-012023-06-25 | |||
| Talep Edilen Teslimat Tarihi RequestedDeliveryDate | Müşteri tarafından talep edilen siparişin teslimat tarihi. | ||
| Açıklama Bu öznitelik, müşterinin ürünleri almak istediği tarihi kaydeder. Siparişten Tahsilata sürecinin yerine getirme bölümü için temel bir performans hedefi görevi görür. Bu tarih, 'Zamanında Teslimat Oranı (OTD) KPI'ı'ını hesaplamak ve 'Teslimat Hizmet Seviyesi Anlaşması (SLA)' kontrol panelini desteklemek için gereklidir. Bu tarihi Gerçek Teslimat Tarihi ile karşılaştırarak, kuruluş müşteri beklentilerini karşılama yeteneğini ölçebilir ve teslimat gecikmelerinin temel nedenlerini belirleyebilir. Neden Önemli?dir? Zamanında teslimat performansını ve müşteri hizmet seviyesi anlaşması (SLA) uyumluluğunu ölçmek için bir temel görevi görür. Nereden Alınır?? Genellikle Oracle Fusion'daki satış siparişi kalem tablolarında bulunur. Oracle Fusion Financials dokümantasyonuna bakın. Ö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 bir bayrak. | ||
| Açıklama Bu boolean öznitelik, faturanın 'Fatura Düzeltildi' etkinliğinin varlığıyla belirtilen bir düzeltme döngüsünden geçmesi durumunda doğrudur. Faturalandırma aşamasında yeniden işleme içeren vakaları işaretler. Bu, 'Fatura Doğruluğu ve Yeniden İşleme Analizi' kontrol paneli ve 'Fatura Yeniden İşleme Oranı' KPI'ı için önemli bir girdidir. Faturalandırma hatalarının boyutunu belirlemeye yardımcı olur ve neden düzeltmelerin gerekli olduğunu tespit etmek için kök neden analizi yapılmasına olanak tanıyarak manuel iş yükünü ve ödeme gecikmelerini azaltmayı hedefler. Neden Önemli?dir? Süreç verimsizliğinin, veri kalitesi sorunlarının ve olası ödeme gecikmelerinin temel göstergesi olan fatura yeniden işlenmesini tanımlar. Nereden Alınır?? Bu, event lognde 'Fatura Düzeltildi' etkinliği varsa bir vaka için genellikle doğru olarak ayarlanan hesaplanmış bir alandır. Örnekler::::::: falsetrue | |||
| Fatura Numarası InvoiceNumber | Müşteri faturasının benzersiz kimliği. | ||
| Açıklama Bu öznitelik, satış siparişinden oluşturulan faturaya atanan benzersiz numaradır. Satış ve yerine getirme etkinliklerini sürecin finansal mutabakat kısmına bağlar. Satış Siparişi birincil Vaka Kimliği (Case ID) olsa da, Fatura Numarası faturalandırma ve ödeme alt süreçlerini analiz etmek için büyük önem taşır. Fatura düzeltmelerini, anlaşmazlıkları ve ödeme durumunu izlemek için gereklidir ve 'Fatura Doğruluğu ve Yeniden İşleme Analizi' gibi kontrol panellerini destekler. Neden Önemli?dir? Alacak hesapları sürecine kritik bir bağlantı sunar ve fatura yeniden işleme ile ödeme döngülerini analiz etmek için gereklidir. Nereden Alınır?? RA_CUSTOMER_TRX_ALL gibi Oracle Fusion'daki alacak hesapları işlem tablolarında mevcuttur. Örnekler::::::: INV-93485INV-93486INV-93487 | |||
| Gecikmiş Ödeme mi? IsLatePayment | Ödemenin vade tarihinden sonra alındığını gösteren hesaplanmış bir bayrak. | ||
| Açıklama Bu boolean öznitelik, fiili ödeme tahsilat tarihinin Son Ödeme Tarihi ile karşılaştırılmasıyla türetilir. Bir faturanın zamanında ödenip ödenmediğine dair net bir gösterge sunar. Bu öznitelik, 'Zamanında Ödeme Oranı' KPI'ını hesaplamak için kullanılır. Zamanında yapılan ödemeleri gecikmeli ödemelerden kolayca ayırarak, geç ödeme yapan müşterilerin özelliklerini, gecikmelerin yaygın nedenlerini ve işletme sermayesi üzerindeki finansal etkisini analiz etmeye sunar. Neden Önemli?dir? Ödeme tahsilat etkinliğini doğrudan ölçer ve gecikmiş ödemelerin analizini basitleştirir. Nereden Alınır?? Bu hesaplanmış bir alandır. Mantık şudur: ÖdemeAlındıTarihi > ÖdemeVadeTarihi. Örnekler::::::: falsetrue | |||
| İş Birimi BusinessUnitName | Satış siparişinden sorumlu dahili iş biriminin adı. | ||
| Açıklama Bu öznitelik, şirkette işlemi yöneten belirli bölümü veya operasyonel birimi temsil eder. Kuruluşun farklı bölümleri arasında performans karşılaştırmasına sunar. Süreci iş birimine göre segmentlere ayırmak, şirket genelinde verimlilik, maliyet ve uyumluluktaki varyasyonları belirlemeye yardımcı olur. Bu analiz, yüksek performans gösteren birimlerde paylaşılabilecek en iyi uygulamaları ortaya çıkarabilir veya hedeflenen süreç iyileştirmeleri gerektiren düşük performans gösteren birimleri vurgulayabilir. Neden Önemli?dir? Farklı organizasyonel birimler arasında performans kıyaslaması ve süreç tutarlılığı analizi yapılmasını sunar. Nereden Alınır?? Genellikle satış siparişi başlığında bulunur ve Oracle Fusion'da tanımlanan organizasyon yapısına bağlıdır. Örnekler::::::: BU-Kuzey AmerikaBU-EMEAKüresel Enerji ve Altyapı | |||
| Kaynak Sistem SourceSystemIdentifier | Olay verilerinin çıkarıldığı kaynak sistemi tanımlar. | ||
| Açıklama Bu öznitelik, verinin kaynağını belirtir; bu da özellikle Siparişten Tahsilata sürecinde birden fazla sistemin yer aldığı ortamlarda kullanışlıdır. Örneğin, sipariş verileri Oracle Fusion'dan gelirken, sevkiyat verileri üçüncü taraf bir lojistik sisteminden kaynaklanabilir. Analizde, bu, veri soyunu anlamaya yardımcı olur ve belirli sistemlerden gelen olaylar için süreç görünümünü filtrelemek için kullanılabilir. Veri doğrulama ve farklı BT altyapıları arasındaki süreç parçalanmasını belirlemek için büyük önem taşır. Neden Önemli?dir? Veri kaynağı hakkında bağlam sunar; bu da çok sistemli ortamlarda veri yönetişimi ve sorun giderme için büyük önem taşır. Nereden Alınır?? Bu genellikle veri çıkarma ve dönüştürme süreci sırasında veri setinin kaynağını etiketlemek 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 sevk veya fatura adresinden ülkeyi sunar. Coğrafi analiz için önemli bir boyuttur. Süreci ülkeye göre segmentlere ayırmak, süreç performansı, döngü süreleri veya ödeme davranışı açısından bölgesel farklılıkları ortaya çıkarabilir. Bu, yerel düzenlemelerin, lojistik zorlukların ve piyasa koşullarının Siparişten Tahsilata süreci üzerindeki etkisini anlamak için değerlidir. Neden Önemli?dir? Süreç verimliliği, uyumluluk ve müşteri davranışındaki bölgesel farklılıkları belirlemek için coğrafi analizi sunar. Nereden Alınır?? Satış siparişine bağlı müşteri ana veri tablolarından (HZ_LOCATIONS, HZ_PARTY_SITES) alınır. Örnekler::::::: USAAlmanyaJaponya | |||
| Ödeme Koşulları PaymentTerms | Müşteri ödemesi için üzerinde anlaşılan şartlar. | ||
| Açıklama Bu öznitelik, müşterinin faturasını hangi koşullar altında ödemesi gerektiğini belirtir; örneğin 'Net 30' veya 'Net 60'. Bu koşullar, Son Ödeme Tarihini hesaplamak için temel oluşturur. Analizde, ödeme koşullarına göre segmentlere ayırmak, ödeme döngüsü sürelerindeki varyasyonları açıklamaya yardımcı olabilir. Farklı koşullar doğal olarak farklı ödeme davranışlarına yol açtığı için 'Zamanında Ödeme Oranı' KPI'ı için bağlam sunar. Bu, kredi politikasını ve nakit akışı tahminini bilgilendirebilir. Neden Önemli?dir? Ödeme davranışı analizi için önemli bir bağlam sunar ve faturadan ödemeye döngü sürelerindeki varyasyonları açıklamaya yardımcı olur. Nereden Alınır?? Oracle Fusion içindeki satış siparişi veya müşteri hesabı düzeyinde mevcuttur. Oracle Fusion Financials belgelerine başvurun. Örnekler::::::: Net 30 GünNet 60 GünMakbuzda Vadesi Gelen | |||
| Sevkiyat Yöntemi ShippingMethod | Ürünleri müşteriye göndermek için kullanılan yöntem veya taşıyıcı. | ||
| Açıklama Bu öznitelik, teslimat için kullanılan lojistik taşıyıcıyı veya hizmet seviyesini detaylandırır; örneğin 'Kara Taşımacılığı', 'Hava Ekspres' veya 'Yerel Kurye'. Bu bilgi, 'Nakliye Yöntemi Teslimat Uyumluluğu' kontrol paneli için büyük önem taşır. Farklı yöntemler ve taşıyıcılar arasındaki zamanında teslimat performansının ve nakliye maliyetlerinin karşılaştırılmasına olanak tanıyarak lojistik stratejisini ve tedarikçi seçimini optimize etmeye yardımcı olur. Neden Önemli?dir? Farklı sevkiyat taşıyıcılarının ve yöntemlerinin performans karşılaştırmasına izin vererek lojistik analizini doğrudan destekler. Nereden Alınır?? Oracle Fusion içindeki sevkiyat ve karşılama tablolarında mevcuttur. Oracle Fusion Financials belgelerine başvurun. Örnekler::::::: FedEx GroundUPS Next Day AirDHL International | |||
| Sipariş Türü OrderType | Satış siparişi için 'Standart Sipariş' veya 'İade Siparişi' gibi bir sınıflandırma. | ||
| Açıklama Sipariş Türü, satış siparişlerini iş amaçlarına göre kategorize etmek için kullanılır. Yaygın türler arasında standart satışlar, hizmet siparişleri, iade malzeme yetkilendirmeleri (RMA'lar) ve dahili siparişler bulunur. Süreci sipariş türüne göre analiz etmek önemlidir çünkü farklı türler genellikle farklı süreç akışlarına ve performans hedeflerine sahiptir. Bu segmentasyon, kasıtlı ve beklenen süreç varyasyonlarını anlamaya yardımcı olur, bunların sapma olarak yanlış yorumlanmasını önler. Neden Önemli?dir? Adil ve doğru bir analiz güçlüak için farklı, meşru süreç akışlarının (örn. standart ve iade) segmentasyonuna sunar. Nereden Alınır?? Genellikle Oracle Fusion'daki satış siparişi başlık tablosunda bir alan olarak mevcuttur. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: Standart Satış Siparişiİade YetkilendirmesiHizmet Siparişi | |||
| Son Veri Güncellemesi LastUpdateDate | Bu olay için verinin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Bu öznitelik, verilerin Process Mining veri setinde en son ne zaman çıkarıldığını veya güncellendiğini kaydeder. Analiz edilen verilerin güncelliği hakkında netlik kazandırır. Bu bilgi, kullanıcıların süreç analizinin ne kadar güncel olduğunu anlaması için büyük önem taşır. Verilerin zamanında olmasıyla ilgili beklentileri yönetmeye yardımcı olur ve veri yenileme programlarını ayarlamak ve izlemek için önemlidir. Neden Önemli?dir? Verinin güncelliğini gösterir, kullanıcıların süreç analizlerinin ne kadar güncel olduğunun farkında olmasını sunar. Nereden Alınır?? Bu değer, her veri çıkarma ve dönüştürme döngüsü sırasında veri setine oluşturulur ve damgalanır. Örnekler::::::: 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Ürün Adı ProductName | Satılan ürün veya hizmetin adı. | ||
| Açıklama Bu öznitelik, satış siparişi satırındaki kalemi belirtir. Bir siparişin birden fazla satırı varsa, vaka satır kalemi düzeyinde analiz edilebilir veya bu öznitelik başlık düzeyinde toplanabilir. Ürüne göre analiz, belirli ürünlerin sık teslimat gecikmeleri veya ödeme sorunları gibi daha karmaşık veya sorunlu süreç akışlarıyla ilişkili olup olmadığını anlamaya yardımcı olur. Bu, ürün yönetimi ve tedarik zinciri stratejilerini bilgilendirebilir. Neden Önemli?dir? Farklı ürünler için süreç performansının analiz edilmesini sağlayarak, karmaşık sipariş karşılama veya faturalandırma yolları olabilecek ürünleri vurgular. Nereden Alınır?? Satış siparişi kalem tablolarından alınır ve bir ürün ana tablosuyla birleştirilir. Oracle Fusion Financials dokümantasyonuna bakın. Örnekler::::::: Standard Widget X1Premium Hizmet PaketiComponent Y2-B | |||
| Zamanında Teslimat Yapıldı mı IsOnTimeDelivery | Gerçek teslimatın talep edilen teslimat tarihinde veya öncesinde yapıldığını gösteren hesaplanmış bir bayrak. | ||
| Açıklama Bu boolean öznitelik, Gerçek Teslimat Tarihinin Talep Edilen Teslim Tarihi ile karşılaştırılmasıyla türetilir. Teslimat performansının basit, vaka düzeyinde bir göstergesini sunar. Bu işaret, toplu 'Zamanında Teslimat Oranı (OTD) KPI'ı'ını hesaplanmasında temel rol oynar. Filtrelemeyi ve analizi basitleştirerek, kullanıcıların gecikmelere katkıda bulunan faktörler üzerinde kök neden analizi yapmak için tüm gecikmiş siparişleri hızla izole etmelerine sunar. Neden Önemli?dir? Sipariş karşılama performansını müşteri beklentilerine göre doğrudan ölçer ve geç kalan siparişlerin analizini basitleştirir. Nereden Alınır?? Bu hesaplanmış bir alandır. Mantık şudur: GerçekTeslimatTarihi <= TalepEdilenTeslimatTarihi. Örnekler::::::: truefalse | |||
Siparişten Nakde - Satış Siparişi Süreci Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Fatura Oluşturuldu | Bu etkinlik, genellikle sevkiyat onay olayı tarafından tetiklenen, Ticari Alacaklar modülünde müşteri faturasının oluşturulmasını temsil eder. Benzersiz bir numara ve oluşturma tarihi ile bir fatura kaydı oluşturulur. | ||
| Neden Önemli?dir? Ödeme tahsilat döngüsünün resmi başlangıcını işaretler. 'Faturadan Ödemeye Süresi' ve genel nakit akışı verimliliğini ölçmek için büyük önem taşır. Nereden Alınır?? Bu, Oracle Ticari Alacaklar (AR) sisteminde açık bir olaydır. RA_CUSTOMER_TRX_ALL tablosunda işlem tarihi ile bir fatura kaydı oluşturulur. Yakala AR modülündeki fatura işleminin oluşturulma tarihinden yakalanır. Event tipi explicit | |||
| Mallar Sevk Edildi | Bu etkinlik, malların depodan sevk edildiği ve müşteriye doğru yolda olduğu noktayı işaret eder. Oracle Shipping'de bir sevkiyat onay işlemi gerçekleştirildiğinde yakalanır. | ||
| Neden Önemli?dir? Bu, sürecin yerine getirme kısmının tamamlandığını gösteren ve faturalandırmayı tetikleyen kritik bir dönüm noktasıdır. Zamanında sevkiyat ve teslimat sürelerini ölçmek için gereklidir. Nereden Alınır?? Bu, Oracle Nakliye Yürütme'de kaydedilen açık bir olaydır. Sevkiyat onay işlemi, WSH_DELIVERY_DETAILS gibi nakliye tablolarında bir sevkiyat tarihi ile bir kayıt oluşturur. Yakala Sipariş satırıyla ilişkili teslimat detayı kaydındaki 'gerçek sevkiyat tarihi' zaman damgası (zaman damgası)ndan yakalanır. Event tipi explicit | |||
| Ödeme Alındı | Bu etkinlik, müşterinin ödemesinin Ticari Alacaklar'nda alındığını ve faturaya uygulandığını gösterir. Bir nakit tahsilat uygulaması kaydedildiğinde yakalanır. | ||
| Neden Önemli?dir? Bu, 'Genel Siparişten Tahsilata Döngü Süresi' ve 'Zamanında Ödeme Oranı'nı ölçmek için kritik bir dönüm noktasıdır. Satışın nakde dönüşümünü temsil eder. Nereden Alınır?? Bu, Oracle Ticari Alacaklar'nda açık bir olaydır. Bir tahsilat faturaya uygulandığında AR_RECEIVABLE_APPLICATIONS_ALL gibi nakit tahsilat tablolarına kaydedilir. Yakala AR'daki nakit makbuzu uygulama kaydının 'uygulama tarihi' zaman damgası (zaman damgası)ndan yakalanır. Event tipi explicit | |||
| Satış Siparişi Oluşturuldu | Bu etkinlik, satış siparişi sürecinin başlangıcını işaret eder ve Oracle Fusion'a yeni bir satış siparişinin girildiği anı temsil eder. Bu olay, genellikle bir kullanıcı Sipariş Yönetimi modülünde yeni bir sipariş kaydını kaydettiğinde açıkça yakalanır. | ||
| Neden Önemli?dir? Süreç başlangıcı olarak, bu aktivite genel Siparişten Tahsilata döngü süresini ölçmek ve sipariş alım hacimlerini analiz etmek için büyük önem taşır. Nereden Alınır?? Satış siparişi kaydının Sipariş Yönetimi Cloud'da oluşturulmasıyla açıkça kaydedilir. DOO_HEADERS_ALL tablosundaki oluşturma zaman damgalarına bakın. Yakala Satış siparişi başlık kaydının oluşturulma zaman damgası (zaman damgası)ndan yakalanır. Event tipi explicit | |||
| Sipariş Kapatıldı | Süreçteki son etkinlik olup, satış siparişindeki tüm kalemlerin yerine getirildiğini, faturalandırıldığını ve kapatıldığını gösterir. Sipariş başlığı durumu 'Kapalı' olarak güncellenir. | ||
| Neden Önemli?dir? Bu etkinlik, satış siparişi süreç döngüsünün başarılı sonunu işaret eder. Uçtan uca süreç sürelerini hesaplamak ve asla kapanmayan "zombi" siparişleri belirlemek için gereklidir. Nereden Alınır?? DOO_HEADERS_ALL tablosunda satış siparişi başlık durumunun 'Kapalı' olarak değişmesinden çıkarılır. Bu son durum değişikliğinin zaman damgası (zaman damgası) olay zamanı olarak olarak kullanılır. Yakala Satış siparişi başlığında durumun 'Kapalı' olarak değiştiği zaman damgası (zaman damgası)ndan türetilir. Event tipi inferred | |||
| Sipariş Onaylandı | Bu temel dönüm noktası, satış siparişinin kredi onayı da dahil olmak üzere tüm ilk kontrollerden geçtiğini ve artık yerine getirilmek üzere taahhüt edildiğini gösterir. Genellikle sipariş durumu 'Sevkiyat Bekleniyor' veya 'Planlandı' gibi bir duruma ilerlediğinde çıkarım yapılır. | ||
| Neden Önemli?dir? Bu etkinlik, 'Ortalama Sipariş Onay Süresi'ni hesaplamak için kritik bir dönüm noktasıdır ve sipariş girişinden yerine getirme sürecine devri işaret eder. Nereden Alınır?? Satış siparişi başlığı veya satır durumunun, karşılamaya hazır olduğunu gösteren bir değere ('Sevkiyat Bekleniyor' gibi) değişmesinden çıkarılır. DOO_HEADERS_ALL veya DOO_FULFILL_LINES_ALL tablolarındaki durum sütunlarını kontrol edin. Yakala Sipariş durumunun onaylanmış veya planlanmış bir duruma değiştiği zaman damgası (zaman damgası)ndan türetilir. Event tipi inferred | |||
| Envanter Ayrıldı | Bu etkinlik, satış siparişi kalemini yerine getirmek için fiziksel envanterin tahsisini veya rezerve edilmesini temsil eder. Sistem, siparişin toplanmaya hazır olduğunda mevcut olmasını sağlayarak belirli stoğu ayırır. | ||
| Neden Önemli?dir? Bunu takip etmek, 'Envanter Tahsis Süresi' KPI'ını analiz etmeye yardımcı olur ve sipariş onayı ile malların temin edilmesi arasındaki gecikmeleri belirler. Nereden Alınır?? Bu olay genellikle envanter veya tedarik zinciri yürütme modüllerinde yakalanır. Envanterin detaylandırıldığını veya rezerve edildiğini gösteren yerine getirme hattındaki durum güncellemelerinden çıkarılabilir. Yakala Envanter rezervasyonu veya planlamasıyla ilgili karşılama satırı durumu değişikliklerinden çıkarılır. Event tipi inferred | |||
| Fatura Düzeltildi | Daha önce oluşturulmuş bir faturanın hatalar veya müşteri anlaşmazlıkları nedeniyle değiştirilmesi, yeniden düzenlenmesi veya alacak kaydı yapılması durumunda ortaya çıkar. Bu durum genellikle bir kredi notu veya faturanın yeni bir versiyonunun oluşturulmasıyla kaydedilir. | ||
| Neden Önemli?dir? Fatura düzeltmelerini takip etmek, ödemeleri geciktirebilecek ve idari maliyetleri artırabilecek faturalandırma sürecindeki sorunları vurgulayan 'Fatura Yeniden İşleme Oranı' KPI'ı için temel rol oynar. Nereden Alınır?? RA_CUSTOMER_TRX_ALL tablosunda bir kredi notu (orijinal faturaya bağlı) veya aynı faturanın sonraki bir sürümünün oluşturulmasıyla çıkarılır. Yakala Önceki bir fatura işlemine atıfta bulunan kredi notları veya faturalar belirlenerek türetilir. Event tipi inferred | |||
| Kredi Bekletme Uygulandı | Bu etkinlik, bir satış siparişinin başarısız bir kredi kontrolü veya diğer krediyle ilgili bir sorun nedeniyle otomatik veya manuel olarak beklemeye alınmasıyla gerçekleşir. Bu durum genellikle siparişin sistem içindeki bekletme durumundaki bir değişiklikle yakalanır. | ||
| Neden Önemli?dir? Kredi bekletmelerini takip etmek, sipariş işleme gecikmelerinin arkasındaki nedenleri belirlemek ve kredi bekletme kaldırma sürecinin verimliliğini ölçmek için büyük önem taşır. Nereden Alınır?? Satış siparişine bir blokaj uygulanmasından çıkarılır. Bu genellikle DOO_HOLDS_ALL gibi blokajla ilgili tablolarda, satış siparişine bağlı olarak kaydedilir. Yakala Sipariş blokaj tablosunda 'Kredi' blokaj türü ile bir kayıt oluşturulmasından çıkarılır. Event tipi inferred | |||
| Kredi Kontrolü Yapıldı | Müşterinin hesabına karşı kredi değerliliğini değerlendirmek için yapılan bir kredi kontrolünün yürütülmesini temsil eder. Bu genellikle sipariş işleme iş akışında otomatik veya manuel bir adımdır ve tamamlanması tipik olarak bir durum güncellemesi veya tamamlanmış bir görev olarak kaydedilir. | ||
| Neden Önemli?dir? Kredi kontrolü için harcanan sürenin analizi, sipariş onayındaki darboğazları belirlemeye yardımcı olur. Bu, 'Kredi Kontrolünden Onay Süresi' KPI'sı için büyük önem taşır. Nereden Alınır?? Satış siparişindeki durum değişikliklerinden, örneğin 'Kredi Onayı Bekleniyor' durumuna geçişten veya kredi yönetimi işlevselliğindeki açık bir event lognden çıkarılabilir. Yakala Kredi inceleme görevleriyle ilişkili sipariş durumu değişikliklerinden veya zaman damgalarından çıkarılır. Event tipi inferred | |||
| Mallar Teslim Edildi | Müşterinin sevkiyatı aldığını gösterir. Bu bilgi genellikle harici bir taşıyıcıdan gelir ve Oracle Fusion'a geri güncellenir veya sevkiyat tarihinden itibaren standart bir transit süreye göre çıkarılabilir. | ||
| Neden Önemli?dir? Bu etkinlik, 'Zamanında Teslimat Oranı (OTD) KPI'ı'ını hesaplamak ve müşteri hizmet seviyelerini doğru bir şekilde ölçmek için büyük önem taşır. Nereden Alınır?? Bu genellikle yerel bir Oracle olayı değildir. Taşıyıcı entegrasyonu mevcutsa yakalanabilir veya 'Mallar Sevk Edildi' tarihine standart bir geçiş süresi eklenerek hesaplanabilir. Sistem analizi gerektirir. Yakala Taşıyıcı veri akışlarından veya sevkiyat tarihi artı ortalama transit süreye göre hesaplanarak çıkarılır. Event tipi inferred | |||
| Sipariş İptal Edildi | Bir satış siparişinin tam olarak sevk edilmeden önce iptal edilmesini temsil eder. Bu durum çeşitli nedenlerle ortaya çıkabilir ve 'İptal Edildi' nihai durumuyla sonuçlanır. | ||
| Neden Önemli?dir? Bu, kritik bir istisna yoludur. İptal edilen siparişleri analiz etmek, stok tükenmeleri, fiyatlandırma sorunları veya müşteri fikir değişikliği gibi temel nedenleri belirlemeye yardımcı olur ve süreç iyileştirmelerini bilgilendirebilir. Nereden Alınır?? Satış siparişi başlığı veya satır durumunun 'İptal Edildi' durumuna değişmesinden çıkarılır. Bu durum değişikliğinin zaman damgası (zaman damgası) olayı kaydetmek için kullanılır. Yakala Sipariş başlığında veya satırında durumun 'İptal Edildi' olarak değiştiği zaman damgası (zaman damgası)ndan türetilir. Event tipi inferred | |||
| Sipariş Kalemi Kapatıldı | Bireysel bir satış siparişi satırının tam olarak sevk edildiğini, faturalandırıldığını ve başka işlem beklenmediğini gösteren nihai kapanışını temsil eder. Sistem, satır durumunu 'Kapalı' olarak günceller. | ||
| Neden Önemli?dir? Sipariş satırlarının kapatılması, ilgili öğe için tüm sözleşmeden doğan yükümlülüklerin tamamlandığını gösterir. Bunun analizi, sipariş karşılandıktan ve ödeme yapıldıktan sonra uzun süre 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ı (zaman damgası) olayı işaretler. Yakala Karşılama satırında durumun 'Kapalı' olarak değiştiği zaman damgası (zaman damgası)ndan türetilir. Event tipi inferred | |||
| Ürünler Toplandı | Siparişi yerine getirmek için ürünlerin depodan fiziksel olarak toplanmasını temsil eder. Bu, lojistik sürecinde önemli bir adımdır ve genellikle depo yönetimi veya nakliye modülünde kaydedilir. | ||
| Neden Önemli?dir? Bu etkinlik, depo operasyonlarına görünürlük sunar. Envanter rezervasyonu ile toplama arasındaki gecikmeler, depodaki kaynak veya süreç darboğazlarını gösterebilir. Nereden Alınır?? Oracle Fusion Cloud SCM (Tedarik Zinciri Yönetimi) modülleri içinde yakalanır. Satış siparişi satırı ile ilişkili bir toplama dalgası veya toplama fişinin durum değişikliğinden çıkarılabilir. Yakala SCM modüllerindeki toplama işleminin tamamlanma zaman damgası (zaman damgası)ndan çıkarılır. Event tipi inferred | |||
Veri Çıkarma Kılavuzları
Adımlar
- Oracle BI Publisher'a Gidin: BI Yönetici veya BI Yazar ayrıcalıklarına sahip bir kullanıcıyla Oracle Fusion ortamınıza giriş yapın. Gezgin menüsünü kullanarak Araçlar > Raporlar ve Analitik'e gidin. İş Zekası Kataloğunu açmak için 'Kataloğa Göz At' düğmesine tıklayın.
- Yeni Bir Veri Modeli Oluşturun: BI Kataloğunda, uygun bir klasöre gidin (örn. Paylaşılan Klasörler > Özel). 'Yeni' açılır menüsüne tıklayın ve 'Veri Modeli'ni seçin.
- SQL Sorgu Veri Kümesini Tanımlayın: Veri Modeli düzenleyicisinde, yeni bir veri kümesi oluşturmak için '+' simgesine tıklayın ve 'SQL Sorgusu'nu seçin. Bir iletişim kutusu görünecektir. Veri kümesine bir ad verin (örn. 'OrderToCash_EventLog'), Veri Kaynağı olarak 'Oracle BI EE'yi seçin ve SQL türü olarak 'Standart SQL'yi seçin.
- SQL Sorgusunu Girin: Bu belgenin 'sorgu' bölümünde verilen tam SQL sorgusunu kopyalayın ve SQL Sorgu metin alanına yapıştırın. Sorgu, başlangıç ve bitiş tarihi için ( :p_start_date ve :p_end_date ) parametrelerini içerir ve bu parametreler BI Publisher tarafından otomatik olarak tanınacaktır.
- Veri Modeli Özelliklerini Yapılandırın: Sorguyu yapıştırdıktan sonra 'Tamam'a tıklayın. Veri modeli düzenleyicisinin sol bölmesindeki 'Özellikler' bölümüne gidin. 'Parametre Etiketlerini Dahil Et'in işaretli olduğundan emin olun. İstenirse tarih parametreleri için varsayılan değerler de ayarlayabilirsiniz.
- Veri Modelini Görüntüleyin ve Kaydedin: 'Veri' sekmesine tıklayın. Tarih parametreleri için değerler girmeniz istenebilir. Test etmek için küçük bir tarih aralığı girin. Verilerin bir örneğini görmek için 'Görüntüle'ye tıklayın. Veriler doğru görünüyorsa, kaydetme simgesine tıklayarak ve açıklayıcı bir ad vererek (örn. 'OrderToCash_EventLog_DM') veri modelini kaydedin.
- Veri Modelinden Rapor Oluşturun: Veri modeli kaydedildikten sonra, sağ üst köşedeki 'Rapor Oluştur' düğmesine tıklayın. Bu, rapor oluşturma sihirbazını açacaktır.
- Raporu Yapılandırın: Sihirbazda, 'Veri Modelini Kullan' seçeneğini seçin. Sihirbaz, düzen ayarları boyunca size rehberlik. edecektir. Basit bir CSV dışa aktarımı için 'Tablo' düzenini seçebilirsiniz. Tüm sütunları tabloya sürükleyip bırakın. 'İleri'ye tıklayın ve ardından 'Genel Toplamlar Satırını Göster' seçimini kaldırın. Raporu kaydetmek için 'Bitir'e tıklayın. 'OrderToCash_EventLog_Report' gibi bir ad verin.
- Raporu Çalışanştırın: Yeni oluşturulan raporu açın. Çıkarma için başlangıç ve bitiş tarihlerini girmeniz istenecektir. İstenen tarih aralığını sağlayın.
- Verileri Dışa Aktarın: Rapor çalıştıktan sonra, 'Görünüm' açılır menüsüne tıklayın ve 'Raporu Görüntüle' gibi farklı bir görünüm seçeneği belirleyin. Ardından, 'Dışa Aktar' bağlantısını veya simgesini bulun ve dışa aktarma formatı olarak 'CSV'yi seçin. Bu, event log dosyasını indirecektir.
- Yükleme İçin Hazırlık: İndirilen CSV dosyasını açın. Sütun başlıklarının gerekli niteliklerle eşleştiğini doğrulayın: SalesOrder, (ActivityName), (EventTime), UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate ve IsAutomated. Dosya artık süreç madenciliği aracına yüklenmeye hazırdır.
Konfigürasyon
- Kullanıcı Yetkileri: 'BI Yöneticisi' veya 'BI Yazarı' gibi BI Publisher veri modeli ve rapor oluşturma yetkilerine sahip bir role sahip olmalısınız.
- Veri Kaynağı: Sorgu, işlem veritabanına (Fusion Uygulamaları) bağlanan standart 'Oracle BI EE' uygulama veri kaynağı için optimize edilmiştir. Genellikle özel bir yapılandırmaya ihtiyaç duyulmaz.
- Tarih Aralığı Parametreleri: Sorgu, verileri filtrelemek için :p_start_date ve :p_end_date olmak üzere iki parametre kullanır. Rapor zaman aşımlarını ve performans sorunlarını önlemek için verileri yönetilebilir partiler halinde (örneğin, bir seferde 3 ila 6 aylık) çıkarmanız şiddetle tavsiye edilir.
- İş Birimi Filtreleme: Çıkarma kapsamını sınırlamak için, sorgudaki BaseOrders CTE'ye belirli bir İş Birimi Kimliğine göre filtrelemek için bir WHERE yan tümcesi ekleyebilirsiniz (örn. AND dhead.SUBMITTING_BU_ID IN ([Sizin İş Birimi Kimliğiniz])).
- Sipariş Türü Filtreleme: BaseOrders CTE'de dhead.SOURCE_ORDER_TYPE_CODE üzerinde bir koşul ekleyerek belirli satış siparişi türleri için de filtreleme yapabilirsiniz.
- Performans: Birkaç yıla yayılan çok büyük veri kümeleri için bu tek sorgulu yaklaşım yavaş olabilir. Mesai dışı saatlerde çalıştırmayı veya çıkarmayı daha küçük, aylık partilere bölmeyi düşünün. Veri Modelinde 'SQL Pruning' özelliğinin seçili olmadığından emin olun, çünkü karmaşık UNION sorgularıyla çakışabilir.
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 Konsoluna Erişin: BICC_ADMINISTRATOR rolüne sahip bir kullanıcıyla Oracle Fusion Uygulamaları örneğinize giriş yapın. Araçlar'a gidin ve menüden Business Intelligence Cloud Connector'ı seçin.
- Yeni Bir Sunum Oluşturun: BICC konsolunda, hedef konumunuzu ayarlamak için Harici Depolamayı Yapılandır'a tıklayın; bu, Oracle Universal Content Management (UCM) veya bir OCI Object Storage bucket olabilir. Bağlantı detaylarınızın ve kimlik bilgilerinizin doğru olduğundan emin olun.
- Yeni Bir Çıkarma İşi Başlatın: Çıkarma İşlerini Yönet bölümüne gidin. Yeni bir iş oluşturmak için + simgesine tıklayın. ProcessMind_O2C_SalesOrder_Extract gibi açıklayıcı bir ad verin.
- Veri Depolarını (PVO'lar) Seçin: İş yapılandırmasında, satış siparişi süreç döngüsünü yakalamak için gereken Public View Object'lerini (PVO'lar) arayın ve 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 gerekecektir.
- Her PVO İçin Sütunları Yapılandırın: Seçilen her PVO için, Eylemler menüsüne tıklayın ve Sütunları Seç'i seçin. Olay günlüğünü oluşturmak için gereken sütunları (HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate ve kullanıcı tanımlayıcıları gibi) dikkatlice seçin. Her PVO'dan gerekli sütunların detaylı listesi için sorgu manifestine bakın.
- Artımlı Yüklemeler İçin Filtreler Uygulayın: Veri hacmini yönetmek için, her PVO'ya LastUpdateDate sütununa dayalı bir filtre uygulayın. İlk çalıştırma için geniş bir tarih aralığı seçebilirsiniz. Sonraki planlanmış çalıştırmalar için, bu filtre yalnızca son iş yürütmesinden bu yana güncellenen kayıtları çıkaracak şekilde yapılandırılmalıdır.
- Çıkarma İşini Zamanlayın: Zamanlamayı Yönet bölümüne gidin. İşiniz için yeni bir zamanlama oluşturun. Sistem performansına etkisini en aza indirmek için işi mesai saatleri dışında, örneğin günlük olarak gece boyunca çalıştırmanız önerilir.
- İşi Gönderin ve İzleyin: Yapılandırıldıktan sonra işi gönderin. İlerlemesini Çıkarma İşlerini Yönet ekranından izleyebilirsiniz. Başarılı bir şekilde tamamlandıktan sonra, veri dosyaları yapılandırılmış bulut depolama konumunuzda sıkıştırılmış CSV formatında mevcut olacaktır.
- Ham Veriyi Bir Olay Günlüğüne Dönüştürün: Çıkarılan CSV dosyalarını indirin. BICC, formatlanmış bir event log değil, ham tablo verileri sunar. Bu dosyaları işlemek için harici bir araç (Python, bir veritabanı betiği veya bir ETL platformu gibi) kullanmalısınız. Bu şunları içerir:
- Farklı dosyalardaki verileri birleştirme (örn. fatura verilerini satış siparişi başlığına geri bağlama).
- Tarih sütunlarını ayrı aktivite satırlarına dönüştürme. Örneğin, FscmTopModelAM.DooTopAM.Header dosyasından, CreationDate kullanarak Satış Siparişi Oluşturuldu için bir satır ve ClosedDate kullanarak Sipariş Kapandı için başka bir satır oluşturun.
- Durum kodlarını veya bayrakları Sipariş Onaylandı veya Sipariş İptal Edildi gibi belirli aktivitelere eşleştirme.
- Dönüştürülmüş tüm verileri gerekli sütunlarla tek bir dosyada birleştirme: SalesOrder, (ActivityName) ve (EventTime).
- Yükleme İçin Formatlama: Son dönüştürülen dosyanın, gerekli ve önerilen niteliklerle eşleşen sütunlara sahip tek bir CSV olduğundan emin olun. Dosya artık ProcessMind'e yüklenmeye hazırdır.
Konfigürasyon
- PVO Seçimi: Olay günlüğünün doğruluğu tamamen doğru PVO'ların seçimine bağlıdır. Ana PVO'lar arasında FscmTopModelAM.DooTopAM.Header (sipariş oluşturma, kapatma için), FscmTopModelAM.ScmTopAM.ShipmentLine (sevkiyat olayları için) ve FscmTopModelAM.ArTopAM.ReceivableInvoice (faturalama için) bulunur.
- Artımlı Çıkarma (Incremental Extraction): Tekrarlayan çıkarmalar için her zaman LastUpdateDate filtresini kullanın. Bu, performans açısından büyük önem taşır ve aynı çok gigabaytlık veri kümesinin tekrar tekrar çıkarılmasını önler. Başlangıçtaki tam yükleme bir temel oluşturmalı, sonraki çalıştırmalar yalnızca değişiklikleri yakalamalıdır.
- Tarih Aralığı: İlk geçmiş yüklemesi için, eksiksizliği yönetilebilir veri hacmiyle dengelemek amacıyla son 3 ila 6 aylık veri gibi temsili 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ı ve alt akış ETL araçlarıyla daha kolay entegrasyon için genellikle OCI Object Storage kullanılması önerilir.
- İş Zamanlaması: Oracle Fusion Financials işlem sistemindeki olası performans düşüşlerini önlemek için çıkarma işlerini mesai saatleri dışında planlayın.
- Önkoş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 çıkarma sonrası gereken veri dönüştürme mantığına dair 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