Satın Almadan Ödemeye - Talep süreciniz için Veri Templatei
Satın Almadan Ödemeye - Talep süreciniz için Veri Templatei
- Ayrıntılı analiz için toplanması önerilen öznitelikler
- Süreç keşfi için izlenecek temel etkinlikler
- SAP S/4HANA’dan veri çıkarma yönergeleri
Satın Almadan Ödemeye - Talep öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Talep sürecinin belirli bir aşamasında gerçekleşen iş etkinliğinin adı. | ||
| Açıklama Etkinlik adı, satın alma talebinin yaşam döngüsünde gerçekleşen belirli bir olayı veya görevi tanımlar. Değişiklik belgeleri ve iş akışı geçmişi gibi sistem günlüklerinden elde edilen bu etkinlikler; Talep oluşturuldu, Onay adımı başladı veya Satın alma siparişi oluşturuldu gibi önemli süreç aşamalarını gösterir. Bu etkinlikleri analiz ederek süreç akışını görselleştirebilir, darboğazları belirleyebilir ve farklı aşamalarda geçen süreyi ölçebilirsiniz. Talep değiştirildi veya Talep reddedildi gibi etkinliklerin sırasını ve sıklığını anlamak, süreçteki verimsizlikleri ve iyileştirme alanlarını belirlemek açısından önemlidir. Neden önemli? Süreç adımlarını tanımlar, süreç haritasının temelini oluşturur ve süreç akışını, farklılıkları ve darboğazları analiz etmenizi sağlar. Nereden alınır? Bu, genellikle değişiklik belgesi tablolarındaki (CDHDR, CDPOS) ve iş akışı günlüklerindeki (ör. SWWLOGHIST) verilerin yorumlanmasıyla oluşturulan türetilmiş bir özniteliktir. Örnekler Talep oluşturulduOnay adımı tamamlandıTalep onaylandıSatın alma siparişi oluşturuldu | |||
| Olay zamanı EventTime | Belirli bir etkinliğin gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zamanı, bir etkinliğin ne zaman gerçekleştiğini kaydeden zaman damgasıdır. Bir vakadaki olayları kronolojik sıraya koymak için gereklidir ve Process Mining çalışmalarındaki tüm süre ve performans hesaplamalarının temelini oluşturur. Örneğin, Talep onaya gönderildi ve Talep onaylandı olayları arasındaki süre, onay çevrim süresini gösterir. Süreç performansını analiz etmek, gecikmeleri belirlemek ve hizmet seviyesi anlaşmalarına uyumu izlemek için doğru zaman damgaları gerekir. Bu öznitelik; çevrim sürelerini görselleştiren, bekleyen talepleri izleyen ve farklı dönemlerdeki performansı karşılaştıran Dashboardlar oluşturmanızı sağlar. Neden önemli? Bu zaman damgası, olayları sıralamak, çevrim sürelerini hesaplamak ve süreç performansıyla darboğazları analiz etmek için gereklidir. Nereden alınır? Zaman damgaları genellikle değişiklik belgesi başlıklarından (CDHDR-UDATE, CDHDR-UTIME) veya iş akışı olay günlüklerinden alınır. Örnekler 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Satın alma talebi kimliği PurchaseRequisitionId | Satın alma talebi belgesinin benzersiz tanımlayıcısı. | ||
| Açıklama Satın alma talebi kimliği, SAP S/4HANA içindeki mal veya hizmet taleplerini birbirinden ayıran birincil anahtardır. Talebin oluşturulmasından onaylanması, reddedilmesi veya satın alma siparişine dönüştürülmesi gibi son durumuna kadar ilgili tüm etkinlikleri ve değişiklikleri birbirine bağlayan temel vaka kimliğidir. Process Mining çalışmalarında bu öznitelik, her talebin uçtan uca yaşam döngüsünü yeniden oluşturmak için kullanılır. Analistler, ilgili tüm olayları tek bir satın alma talebi kimliği altında gruplayarak çevrim sürelerini doğru biçimde ölçebilir, durum değişikliklerini izleyebilir ve taleplerin onay sürecinde izlediği farklı yolları inceleyebilir. Neden önemli? İlgili tüm süreç adımlarını birbirine bağlayan bu temel vaka kimliği, talep yaşam döngüsünün eksiksiz ve tutarlı biçimde görülmesini sağlar. Nereden alınır? Bu öznitelik, EBAN tablosundaki BANFN alanında bulunan satın alma talebi numarasıdır. Örnekler 100178901001789110017892 | |||
| Departman Department | Talep maliyetlerinin yansıtıldığı departman veya masraf yeri. | ||
| Açıklama SAP’de genellikle masraf yeriyle gösterilen departman özniteliği, talep edilen satın alımdan sorumlu iş birimini belirtir. Talebin kalem düzeyinde atanan bu bilgi, finans ve kuruluş yapısı açısından önemlidir. Process Mining çalışmalarında bu öznitelik, departman performansını analiz etmek için kullanılır. Farklı departmanların çevrim sürelerini, değişiklik oranlarını ve ret oranlarını karşılaştıran Dashboardlar oluşturmanızı sağlar. Böylece uygulamaları başka birimlerde de kullanılabilecek başarılı departmanları ve ek eğitim ya da süreç desteğine ihtiyaç duyabilecek birimleri belirleyebilirsiniz. Neden önemli? İş birimleri arasında performans karşılaştırması yapmanızı sağlar. Çevrim süreleri veya ret oranlarındaki farklılıkları göstererek iyi uygulamaları ve iyileştirme alanlarını belirlemeye yardımcı olur. Nereden alınır? Bu, genellikle hesap tayin tablosu EBKN’deki KOSTL alanında bulunan masraf yeridir. Örnekler FIN-1001IT-2005MKT-3010 | |||
| Kullanıcı kimliği UserId | Talebi oluşturan veya belirli bir etkinliği gerçekleştiren kullanıcının kimliği. | ||
| Açıklama Kullanıcı kimliği, talebin yaşam döngüsündeki belirli bir olaydan sorumlu çalışanı veya sistem kullanıcısını belirtir. Bu kişi talebi oluşturan, onaylayan yönetici ya da talepte değişiklik yapan görevli olabilir. Otomatik adımlarda sistem veya toplu işlem kullanıcısının kimliği yer alabilir. Kullanıcı kimliğine göre analiz yapmak; kullanıcı davranışını, iş yükü dağılımını ve performansı anlamaya yardımcı olur. Eğitim gereksinimlerini belirlemek, yüksek performans gösteren çalışanları fark etmek ve süreçte hesap verebilirliği sağlamak açısından önemlidir. Kullanıcı ana verileriyle birlikte kullanıldığında bölüm performansını analiz etmeyi de sağlar. Neden önemli? Kullanıcı performansını, iş yükü dağılımını ve süreç uyumluluğunu analiz etmenizi sağlar. Eğitim fırsatlarını ve kaynak darboğazlarını belirlemek için önemlidir. Nereden alınır? Talebi oluşturan kullanıcının kimliği EBAN-ERNAM alanında bulunur. Sonraki değişiklikleri yapan kullanıcı CDHDR-USERNAME alanında, onaylayan kullanıcı ise iş akışı günlüklerinde yer alır. Örnekler JSMITHRROEWF-BATCH | |||
| Onaylayıcı kimliği ApproverId | Onay veya ret adımını gerçekleştiren kullanıcının kimliği. | ||
| Açıklama Onaylayıcı kimliği, onay veya ret işlemini tamamlayan kullanıcıyı belirtir. Genel kullanıcı kimliğinden farklı olarak yalnızca onay iş akışındaki karar vericilere odaklanır. Onay sürecini ayrıntılı biçimde analiz edebilmek için bu bilgiyi kaydetmek önemlidir. Bu öznitelik, onay davranışını incelemenizi sağlar. Örneğin, onay süresi uzun olan veya talepleri sık reddeden yöneticileri belirleyebilirsiniz. Onay adımlarının çevrim sürelerine ve iş akışındaki darboğazlara odaklanan Dashboardlar için temel bir veridir; gecikmelere neden olabilecek kişileri veya rolleri ortaya çıkarır. Neden önemli? Onay adımındaki karar vericiyi belirleyerek kişi veya rol bazında onay çevrim sürelerini ve darboğazları ayrıntılı biçimde analiz etmenizi sağlar. Nereden alınır? Bu bilgi genellikle iş kalemlerini tamamlayan kullanıcıyla ilişkilendiren SWW_WI2OBJ ve SWWLOGHIST gibi SAP Business Workflow tablolarından alınır. Örnekler MJOHNSONCWILLIAMSLBLACK | |||
| Talep durumu RequisitionStatus | Satın alma talebinin mevcut işlem veya onay durumu. | ||
| Açıklama Talep durumu, talebin yaşam döngüsündeki mevcut aşamasını gösterir. SAP’de bu durum genellikle serbest bırakma göstergesiyle belirtilir. Gösterge, talebin bloke edildiğini, onay beklediğini, kısmen onaylandığını veya tamamen onaylandığını belirtir. Talep iş akışında ilerledikçe durum değişir. Durumu zaman içinde izlemek, süreç akışını anlamak için gereklidir. Taleplerin nerede ve ne kadar süreyle beklediğini belirlemeye yardımcı olur. Durumlar arasındaki geçişleri inceleyerek onay sürecini ve farklı işleyiş biçimlerini ayrıntılı olarak görebilirsiniz. Neden önemli? Talebin mevcut durumunu gösterir. İlerlemeyi izlemek, darboğazları belirlemek ve süreç akışını analiz etmek için önemlidir. Nereden alınır? Serbest bırakma durumu genellikle EBAN tablosundaki FRGZU alanında bulunan Serbest Bırakma Göstergesiyle belirlenir. Örnekler B1S | |||
| Talep türü RequisitionType | Satın alma talebini standart kalem, hizmet veya sermaye harcaması gibi kategorilere ayıran kod. | ||
| Açıklama SAP’de belge türü olarak da bilinen talep türü, satın alma taleplerini kategorilere ayıran önemli bir yapılandırma alanıdır. Farklı türler farklı onay iş akışlarını ve alan ayarlarını devreye sokabilir. Ayrıca standart stok kalemleri, dış hizmetler veya varlık alımları gibi farklı iş amaçları için kullanılır. Talep türüne göre analiz yapmak, kuruluşların farklı talep kategorilerinin nasıl ele alındığını anlamasını sağlar. Kategoriler arasındaki performansı, çevrim sürelerini ve onay yollarını karşılaştırarak bazı talep türlerinin daha verimli olup olmadığını görebilir ve iyileştirmeleri buna göre planlayabilirsiniz. Neden önemli? Talepleri kategorilere ayırarak karşılaştırmalı analiz yapmanızı sağlar. Böylece farklı talep türlerinin süreç akışlarını, darboğazlarını ve çevrim sürelerini inceleyebilirsiniz. Nereden alınır? Bu, EBAN tablosundaki BSART alanında bulunan Belge Türü alanıdır. Örnekler NBFORV | |||
| Talep tutarı RequisitionAmount | Satın alma talebinin toplam parasal değeri. | ||
| Açıklama Talep tutarı, istenen mal veya hizmetlerin tahmini toplam maliyetini gösterir. Bu değer, onay iş akışının karmaşıklığını ve süresini belirleyen önemli etkenlerden biridir. Tutarı yüksek talepler genellikle daha fazla onay düzeyi gerektirir. Bu özniteliği analiz ederek süreci tutara göre gruplandırabilirsiniz. Örneğin, yüksek tutarlı taleplerin onaylanmasının daha uzun sürüp sürmediğini veya sık reddedilen taleplerin tutarını inceleyebilirsiniz. Süreç verimsizliklerinin finansal etkisini anlamak için önemli bir ölçüttür. Neden önemli? Süreci finansal etkiye göre gruplandırmaya yardımcı olur ve çoğu zaman onay sürecinin karmaşıklığıyla çevrim süresiyle ilişkilidir. Tutar bazında süreç analizi için önemlidir. Nereden alınır? Toplam değer EBAN tablosundaki GFWERT alanında, kalem düzeyindeki değer ise EBAN-PREIS alanında bulunur. Örnekler 1500.0075000.50250.75 | |||
| Aciliyet düzeyi UrgencyLevel | Talebin aciliyetini sınıflandırır ve işlem önceliğini etkileyebilir. | ||
| Açıklama Aciliyet düzeyi, satın alma talebinin önceliğini gösterir. Bu amaç için ayrılmış standart bir alan olmasa da bazı kuruluşlar bu bilgiyi Requirement Tracking Number gibi alanlarda tutar. Böylece talep sahipleri, daha hızlı işleme alınması gerekebilecek önemli ihtiyaçları belirtebilir. Aciliyetin etkisini incelemek, sürecin önemli taleplere gerçekten öncelik verip vermediğini değerlendirmeye yardımcı olur. Aciliyet düzeyinin etkisi Dashboardı, acil ve standart taleplerin çevrim sürelerini ve onay oranlarını karşılaştırır. Böylece öncelikli işlemlerin beklendiği gibi sonuç verip vermediğini görebilirsiniz. Neden önemli? Yüksek öncelikli taleplerde süreç performansının nasıl değiştiğini incelemenizi sağlar ve acil taleplerin gerçekten daha hızlı işleme alınıp alınmadığını değerlendirmenize yardımcı olur. Nereden alınır? Standart bir aciliyet alanı yoktur. Bazı şirketler bu amaçla Requirement Tracking Number (EBAN-BEDAR) alanını kullanır. Özel bir alan da olabilir. Örnekler YüksekOrtaDüşük | |||
| Bitiş zamanı EndTime | Belirli bir etkinliğin tamamlandığı kesin tarih ve saat. | ||
| Açıklama EndTime, bir etkinliğin ne zaman tamamlandığını kaydeden zaman damgasıdır. Sistem tarafından oluşturulan birçok olay anlık gerçekleşir, yani StartTime ile EndTime aynıdır. Onay gibi insan tarafından yürütülen görevlerin ise farklı başlangıç ve bitiş zamanları olabilir. Bu zaman damgası, işin tamamlandığı anı gösterir. Ayrı bir EndTime değeri, etkin işlem süresini bekleme süresinden daha doğru biçimde ayırmanızı sağlar. ProcessingTime metriğini hesaplamak için StartTime ile birlikte kullanılır. Bu ayrıntı, manuel görevlerde kaynak kullanımını ve verimliliği daha iyi incelemenize yardımcı olur. Neden önemli? Bir etkinliğin tamamlandığı zamanı gösterir. Böylece etkin işlem süresini hesaplayabilir ve görev süresini daha ayrıntılı inceleyebilirsiniz. Nereden alınır? Bu bilgi, bir iş öğesinin ne zaman oluşturulduğunu (StartTime) ve tamamlandığını (EndTime) kaydeden iş akışı günlüklerinden elde edilir. Örnekler 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| İhtiyaç tarihi RequiredByDate | Talep sahibinin istenen mal veya hizmetlere ihtiyaç duyduğu tarih. | ||
| Açıklama SAP’de teslimat tarihi olarak adlandırılan ihtiyaç tarihi, talep kalemindeki mal veya hizmetlerin ne zaman gerektiğini belirtir. Bu tarihi talep sahibi belirler ve satın alma sürecinin tamamı için hedef olarak kullanır. Bu öznitelik, Zamanında Tamamlanan Talep Oranı KPI’ını hesaplamak için gereklidir. Kuruluş, ihtiyaç tarihini nihai onay veya satın alma siparişinin oluşturulma tarihiyle karşılaştırarak iç hizmet seviyelerini ve iş gereksinimlerini ne ölçüde karşıladığını ölçebilir. Bu tarihi kaçıran talepleri incelemek, satın alma sürecindeki sistematik gecikmeleri ortaya çıkarabilir. Neden önemli? Talebin hedef tamamlanma tarihini belirler. Böylece zamanında teslimatı ve iç hizmet seviyelerine uyumu ölçebilirsiniz. Nereden alınır? Bu, EBAN tablosunda kalem düzeyinde bulunan LFDAT alanındaki Teslimat Tarihidir. Örnekler 2023-11-152023-12-012024-01-20 | |||
| Kaynak sistem SourceSystem | Verilerin hangi SAP S/4HANA örneğinden çıkarıldığını belirtir. | ||
| Açıklama Kaynak sistem özniteliği, süreç verilerinin oluşturulduğu sistemi gösterir. Geliştirme, kalite güvencesi ve üretim için farklı sistemler ya da farklı bölgeler için ayrı sistemler kullanan kuruluşlarda bu alan, veri yönetişimi ve bağlam açısından önem taşır. Farklı kaynaklardan gelen verilerin ayırt edilmesini sağlayarak yanlış birleştirmeleri önler ve sisteme özel analiz yapılmasına imkân verir. Veri kökenini korumak ve süreç verilerinin izlenebilirliğini sağlamak için bu öznitelik gereklidir. Neden önemli? Özellikle birden fazla sistemin bulunduğu ortamlarda verinin kaynağını ve yönetişimini anlamaya yardımcı olur, verilerin izlenebilirliğini sağlar. Nereden alınır? Bu genellikle sistem değişkenlerinden veya yapılandırma tablolarından alınabilen SAP Sistem Kimliğidir (SID). Örnekler S4PECCS4H_PROD_01 | |||
| Onay adının adı ApprovalStepName | İş akışındaki bir onay adımının adı veya açıklaması. | ||
| Açıklama Onay adımının adı, onay iş akışındaki belirli bir aşamayı 'Yönetici onayı' veya 'Finans başkan yardımcısı onayı' gibi anlaşılır bir ifadeyle tanımlar. Bu, genel nitelikteki 'Onay adımı tamamlandı' etkinliğinden daha açıklayıcıdır. Bu öznitelik, Onay adımı çevrim süresi ve İş akışı darboğaz analizi Dashboardları için önemlidir. Onay sürecini ayrıntılı incelemenizi, en uzun gecikmelere yol açan aşamaları ve işlerin nerede biriktiğini tam olarak belirlemenizi sağlar. Onay zincirini iyileştirmek için hedefli adımlar atarken bu ayrıntıdan yararlanabilirsiniz. Neden önemli? Onay aşamalarını ayrıntılı biçimde göstererek çok kademeli onay iş akışındaki darboğazları tam olarak belirlemenizi sağlar. Nereden alınır? Bu bilgi, iş akışı günlüğünün T528T gibi görev tanımı tablolarıyla ilişkilendirilmesiyle bulunabilen iş akışı görevi açıklamasından elde edilir. Örnekler Yönetici onayıDirektör onayıFinans başkan yardımcısı onayı | |||
| Otomatik mi IsAutomated | Bir etkinliğin insan yerine sistem kullanıcısı tarafından gerçekleştirildiğini belirten gösterge. | ||
| Açıklama Is Automated özniteliği, bir etkinliğin 'WF-BATCH' gibi bir sistem veya toplu işlem kullanıcısı tarafından yürütülüp yürütülmediğini belirten bir boole değeridir. Bu sayede süreçteki manuel ve otomatik adımları ayırt edebilirsiniz. Bu öznitelik, talep sürecindeki otomasyon düzeyini ölçmek ve 'Otomatik onay oranı' KPI’ını hesaplamak için gereklidir. Otomatik veya manuel adımlara göre filtreleme yaparak verimliliği karşılaştırabilir ve işlem sürelerini ve manuel iş yükünü azaltmak için otomasyon fırsatlarını belirleyebilirsiniz. Neden önemli? İnsanlar tarafından yürütülen etkinliklerle sistemlerin yürüttüğü etkinlikleri ayırt eder. Otomasyon oranlarını ölçmek ve manuel görevleri otomatikleştirme fırsatlarını belirlemek için önemlidir. Nereden alınır? Bu, genellikle bir olayın User ID değerinin bilinen sistem veya toplu işlem kullanıcıları listesinde olup olmadığını denetleyen bir kurala dayalı olarak türetilen bir özniteliktir. Örnekler truefalse | |||
| Para birimi Currency | Talep tutarının para birimi kodu. | ||
| Açıklama Bu öznitelik, talep tutarının hangi para biriminde belirtildiğini gösterir; örneğin USD, EUR veya JPY. Özellikle birden fazla para birimiyle çalışan çok uluslu kuruluşlarda talep tutarını doğru yorumlamak için gereklidir. Doğru finansal analiz ve raporlama için para birimini dikkate alın. Talep tutarlarını toplarken veya karşılaştırırken anlamlı sonuçlar elde etmek için tüm tutarları ortak bir para birimine dönüştürün. Bu öznitelik, söz konusu dönüşüm için gerekli bilgiyi sağlar. Neden önemli? Talep tutarının doğru yorumlanması için gerekli bağlamı sağlar ve birden fazla para biriminin kullanıldığı ortamlarda doğru finansal analiz ve karşılaştırma yapmanıza imkân verir. Nereden alınır? Bu bilgi EBAN tablosundaki WAERS alanında bulunur. Örnekler USDEURGBP | |||
| Ret nedeni RejectionReason | Satın alma talebi reddedildiğinde belirtilen neden. | ||
| Açıklama Ret nedeni, onaylayıcının satın alma talebini neden reddettiğini açıklar. Bütçenin aşılması, yanlış bilgi, politikalara uyumsuzluk veya başka bir taleple mükerrerlik olası nedenler arasındadır. Bu bilgi, süreçteki başarısızlıkları anlamak için gerekli bağlamı sağlar. Ret nedenlerini analiz etmek, süreç verimsizliklerinin ve yeniden çalışmanın temel nedenlerini belirlemeye yardımcı olur. Örneğin, Masraf yeri yanlış sık karşılaşılan bir nedense kullanıcı eğitiminin veya sistem doğrulamasının iyileştirilmesi gerekebilir. Bu öznitelik, Talep ret analizi Dashboardunun temelini oluşturur ve hedefli süreç iyileştirmeleri için önemlidir. Neden önemli? Süreçteki başarısızlıkların temel nedenini göstererek yeniden çalışmayı azaltmak ve taleplerin ilk seferde doğru hazırlanma oranını artırmak için hedefli iyileştirmeler yapmanızı sağlar. Nereden alınır? Bu bilgi genellikle standart bir alanda tutulmaz. İş akışı kapsayıcı öğelerinde, taleple ilişkili uzun metinlerde veya özel alanlarda bulunabilir. Örnekler Bütçe aşıldıTedarikçi yanlışMükerrer talep | |||
| Satın alma siparişi numarası PurchaseOrderNumber | Talep üzerinden oluşturulan satın alma siparişinin numarası. | ||
| Açıklama Satın alma siparişi numarası, onaylanmış bir talepten oluşturulan resmî satın alma belgesinin kimliğidir. Satın alma siparişinin oluşturulması, talebin tedarikçiye verilen resmî bir siparişe dönüştüğünü gösterir ve çoğu zaman talep sürecinin başarılı sonucudur. Bu öznitelik, Talep ile Satın Alma Siparişi Arasındaki Süre KPI’ını ve genel dönüşüm oranını ölçmek için önemlidir. Talep sürecini sonraki satın alma adımlarına bağlayarak Satın Almadan Ödemeye döngüsünün tamamını uçtan uca görmenizi sağlar. Neden önemli? Talebi sonraki satın alma belgesine bağlayarak talebin siparişe dönüşüm oranını ve dönüşüm süresini ölçmenizi sağlar. Nereden alınır? Talep kaleminden satın alma siparişi oluşturulduğunda bu bilgi EBAN tablosundaki EBELN alanında bulunur. Örnekler 450001789045000178914500017892 | |||
| Son veri güncellemesi LastDataUpdate | Bu kaydın verilerinin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden yapılan en son veri çıkarma veya güncelleme işleminin tarih ve saatini kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu anlamak için önemli bir meta veridir. Analistler ve iş kullanıcıları, süreç verilerinin operasyonların en güncel durumunu yansıtıp yansıtmadığını bu zaman damgasından takip eder. Süreç analizinde verilerin güncelliğini bilmek, doğru kararlar almak için gereklidir. Bu öznitelik, kullanıcıların beklentilerini yönetmeye ve sonuçların ilgili analiz için gereken güncellikteki verilere dayanmasını sağlamaya yardımcı olur. Neden önemli? Verilerin güncelliğini gösterir. Analize güvenmek ve zamanında iş kararları almak için bu bilgi önemlidir. Nereden alınır? Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) işlemi sırasında oluşturulup eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Yeniden çalışma mı IsRework | Bir etkinliğin, gönderimden sonra yapılan değişiklik gibi yeniden çalışma sayılıp sayılmadığını belirtir. | ||
| Açıklama Is Rework, değer katmayan veya tekrarlanan işleri belirleyen, hesaplanmış bir boole değeridir. Bu süreçte sık görülen bir örnek, talep onaya gönderildikten sonra 'Talep değiştirildi' etkinliğinin gerçekleşmesidir. Bu durumda onay sürecinin baştan başlaması gerekir. Bu öznitelik, süreçteki yeniden çalışma miktarını ve bunun toplam çevrim sürelerine etkisini ölçmek için önemlidir. Talep değişikliği ve yeniden çalışma oranı Dashboardı, süreçteki verimsizlikleri belirlemek için bu değeri kullanır. Yeniden çalışmayı azaltmak, doğrudan zaman ve emek tasarrufu sağladığı için süreç iyileştirme çalışmalarının başlıca hedeflerinden biridir. Neden önemli? Boşa harcanan emeği veya tekrarlanan işleri gösterir. Böylece yeniden çalışma miktarını ve süreç verimliliğine etkisini doğrudan ölçebilirsiniz. Nereden alınır? Bu, hesaplanmış bir özniteliktir. Genellikle ilk 'Talep onaya gönderildi' etkinliğinden sonra gerçekleşen 'Talep değiştirildi' etkinliği yeniden çalışma olarak işaretlenir. Örnekler truefalse | |||
Satın Almadan Ödemeye - Talep etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Onay adımı tamamlandı | Onaylayıcı talep hakkında olumlu karar verdiğinde ve çok düzeyli onay iş akışının bir adımı tamamlandığında gerçekleşir. Talebin serbest bırakma durumundaki değişiklikten çıkarımla belirlenir. | ||
| Neden önemli? Bu etkinlik, her adımda geçen süreyi ölçerek onay iş akışının ayrıntılı biçimde incelenmesini sağlar. Süreci hızlandıran onaylayıcıları ve darboğazları belirlemeye yardımcı olur. Nereden alınır? EBAN tablosuna ait değişiklik belgelerinden (CDHDR/CDPOS) çıkarımla belirlenir. Belirli bir serbest bırakma kodunun durumunun, ilgili alanda (ör. FRGZU) serbest bırakılmamıştan serbest bırakılmışa geçmesi bu olayı gösterir. Kaydedin Stratejide tanımlanan her serbest bırakma kodu için EBAN tablosundaki serbest bırakma durumu alanlarındaki değişiklikleri izleyin. Olay türü inferred | |||
| Satın alma siparişi oluşturuldu | Talep kalemine referans veren bir satın alma siparişinin oluşturulduğunu gösterir. Bu sistem olayı, talebi sonraki satın alma belgesine bağlayarak açıkça kaydedilir. | ||
| Neden önemli? Bu, talep sürecinin önemli bir aşaması ve başarılı sonuçlarından biridir. Talebin onaylanmasıyla satın alma siparişinin oluşturulması arasında geçen süre, satın alma verimliliğini ölçen önemli bir KPI’dır. Nereden alınır? Satın alma siparişi kalemi oluşturulduğunda açıkça kaydedilir. Bağlantı, kaynak talep numarasını (BANFN) ve kalem numarasını (BNFPO) içeren EKPO tablosunda (Satın Alma Siparişi Kalemi) tutulur. Kaydedin EKPO tablosunu talep numarası ve kalem üzerinden EBAN tablosuna bağlayın. Sipariş kaleminin oluşturulma tarihi bu olayı gösterir. Olay türü explicit | |||
| Talep kapatıldı | Talep kaleminin tamamen işleme alındığını ve bu kalemden başka satın alma siparişi oluşturulamayacağını gösterir. Sipariş edilen toplam miktar talep miktarına ulaştığında bu durum genellikle otomatik olarak ayarlanır. | ||
| Neden önemli? Bu etkinlik, talep kaleminin yaşam döngüsünün başarıyla tamamlandığı son aşamayı gösterir. İş ihtiyacının tamamen bir satın alma siparişine dönüştürüldüğünü doğrular. Nereden alınır? EBAN tablosundan çıkarımla belirlenir. Genellikle siparişlerdeki miktar talep miktarına eşit olduğunda Kapalı göstergesi (EBAKZ) ayarlanır. Kaydedin Değişiklik belgelerini kullanarak EBAN tablosundaki Kapalı göstergesinin (EBAKZ) ayarlandığı olayı belirleyin. Olay türü inferred | |||
| Talep oluşturuldu | Satın alma talebi belgesinin sistemde ilk kez oluşturulduğunu gösterir. Kullanıcı yeni talebi ilk kez kaydettiğinde bu olay açıkça kaydedilir ve oluşturma zaman damgası tutulur. | ||
| Neden önemli? Bu etkinlik, talep yaşam döngüsü analizinin başlangıç noktasıdır. İhtiyacın ilk kez belirlenmesinden nihai onaya veya satın alma siparişine dönüştürülmesine kadar geçen toplam çevrim süresini ölçmek için gereklidir. Nereden alınır? Bu olay, EBAN tablosundaki oluşturma tarihi (ERDAT) ve oluşturma saati (ERZEIT) alanları kullanılarak ilgili satın alma talebi numarası (BANFN) için açıkça kaydedilir. Kaydedin Her talep (BANFN) için EBAN tablosundaki oluşturma zaman damgası alanlarını (ERDAT, ERZEIT) kullanın. Olay türü explicit | |||
| Talep onaylandı | Satın alma talebinin tüm onaylardan geçtiğini ve satın alma siparişine dönüştürülebileceğini gösterir. Genel serbest bırakma durumu nihai onay durumuna ulaştığında bu aşama çıkarımla belirlenir. | ||
| Neden önemli? Bu önemli başarı aşaması, çevrim süresi analizinde sık kullanılan bir bitiş noktasıdır. Talebin tüm kontrollerden geçtiğini ve satın alma ekibinin işlem yapmasına hazır olduğunu gösterir. Nereden alınır? EBAN tablosundaki durum değişikliğinden çıkarımla belirlenir. Özellikle genel serbest bırakma göstergesi (FRGZU) veya işlem durumu (PROCSTAT) nihai Onaylandı değerine güncellendiğinde gerçekleşir. Kaydedin Nihai serbest bırakma kodunun uygulandığı veya talebin genel durumunun Onaylandı olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Talep reddedildi | Onaylayıcının satın alma talebini nihai olarak reddettiğini ve süreci durdurduğunu gösterir. Ret kararını belirten özel bir durum güncellemesiyle kaydedilir. | ||
| Neden önemli? Bu etkinlik, sürecin başarısızlıkla sonuçlandığı noktayı gösterir. Ret sıklığını, nedenlerini ve sürecin hangi aşamalarında gerçekleştiğini incelemek; politika uyumluluğu, bütçe veya talep kalitesiyle ilgili sorunları ortaya çıkarabilir. Nereden alınır? EBAN tablosundaki durum değişikliğinden çıkarımla belirlenir. İşlem durumu (PROCSTAT) veya serbest bırakma göstergesi, Reddedildi anlamına gelen bir değere ayarlanır. Kaydedin Değişiklik belgelerini kullanarak EBAN tablosundaki genel durumun Reddedildi olarak güncellendiği zaman damgasını belirleyin. Olay türü inferred | |||
| Onay adımı başladı | Talebin belirli bir onaylayıcının veya onay grubunun işlem yapmasını beklediğini gösterir. Talep durumu belirli bir serbest bırakma kodunun beklendiğine işaret ettiğinde bu olay çıkarımla belirlenir. | ||
| Neden önemli? Bu etkinlik, onay zincirindeki darboğazları belirlemek için gereklidir. Bu durumun ne kadar sürdüğünü incelemek, bekleyen talepleri ve iş yükü fazla olan onaylayıcıları ortaya çıkarır. Nereden alınır? EBAN tablosundaki serbest bırakma durumu alanlarından (ör. FRGZU) ve ilgili serbest bırakma stratejisi yapılandırmasından çıkarımla belirlenir. Belirli bir serbest bırakma kodu sıradaki işlem adımı olduğunda etkinlik başlar. Kaydedin İş akışı günlüklerine veya durum alanlarına bakarak talebin belirli bir serbest bırakma kodu için onay beklemeye başladığı zamanı belirleyin. Olay türü inferred | |||
| Onay sıfırlandı | Talepte önemli bir değişiklik yapılması gibi nedenlerle tüm onay iş akışının sıfırlandığını gösterir. Bu durumda onay süreci ilk düzeyden yeniden başlar. | ||
| Neden önemli? Bu etkinlik, çevrim süresini ciddi ölçüde etkileyen yeniden çalışmaları ortaya çıkarır. Onayın neden sıfırlandığını belirlemek, süreci sadeleştirmek ve gecikmeleri azaltmak açısından önemlidir. Nereden alınır? EBAN tablosuna ait değişiklik belgelerinden (CDHDR/CDPOS) çıkarımla belirlenir. Kısmen veya tamamen doldurulmuş serbest bırakma durumu alanları (FRGKZ veya FRGZU gibi) temizlendiğinde bu olay algılanır. Kaydedin Değişiklik günlüklerinde, serbest bırakılmış durumdan serbest bırakılmamış duruma geçiş olup olmadığını kontrol edin. Olay türü inferred | |||
| Talep değiştirildi | Kullanıcı, talep ilk oluşturulduktan sonra miktar, fiyat veya malzeme gibi önemli bir alanı değiştirdiğinde gerçekleşir. Bu işlem SAP değişiklik belgesi sistemine açıkça kaydedilir. | ||
| Neden önemli? Değişiklikleri izlemek, yeniden çalışma döngülerini ve bunların çevrim sürelerine etkisini belirlemek açısından önemlidir. Sık değişiklik yapılması, veri kalitesiyle veya değişen gereksinimlerle ilgili sorunlara işaret edebilir. Bunlar süreç iyileştirmede ele alınabilecek başlıca konulardır. Nereden alınır? EBAN tablosunda yapılan değişiklikler, SAP değişiklik belgesi tablolarına (CDHDR ve CDPOS) açıkça kaydedilir. İzlenen her alandaki değişiklik yeni bir kayıt oluşturur. Kaydedin Satın alma taleplerine ait nesne sınıfı BANF olan CDHDR/CDPOS kayıtlarından değişiklik olaylarını çıkarın. Olay türü explicit | |||
| Talep geri çekildi | Talep sahibi, talep tamamen işleme alınmadan önce talebi iptal ettiğinde veya sildiğinde gerçekleşir. Bu işlem genellikle talep kalemine silme göstergesi eklenerek açıkça kaydedilir. | ||
| Neden önemli? Geri çekme işlemlerini izlemek, talebin değişkenliğini ve iptal nedenlerini anlamaya yardımcı olur. Bu durum, talebin daha fazla işleme alınmasını engelleyen son aşamadır. Nereden alınır? EBAN tablosundaki talep kalemine silme göstergesi (LOEKZ) eklendiğinde açıkça kaydedilir. Değişiklik CDHDR/CDPOS tablolarına yazılır. Kaydedin EBAN tablosundaki silme göstergesinin (LOEKZ) L olarak ayarlandığı olayı belirleyin. Olay türü explicit | |||
| Talep onaya gönderildi | Talep sahibinin talebi resmen gönderdiği ve onay iş akışını başlattığı anı ifade eder. Bu olay genellikle talebin serbest bırakma stratejisi belirlendiğinde ve durumu Onayda olarak değiştiğinde çıkarımla belirlenir. | ||
| Neden önemli? Bu önemli aşama, onay çevrim süresi KPI’larının ölçümünü başlatır. Oluşturma ile gönderim arasındaki süreyi incelemek, talep hazırlama aşamasındaki gecikmeleri ortaya çıkarabilir. Nereden alınır? EBAN tablosuna ait değişiklik belgelerinden (CDHDR/CDPOS) çıkarımla belirlenir. Özellikle serbest bırakma stratejisi alanlarının (ör. FRGST) doldurulması veya genel durumun (PROCSTAT) onay beklediğini gösterecek şekilde değişmesi dikkate alınır. Kaydedin Onay iş akışının başladığını veya durumun Onayda olarak değiştiğini gösteren ilk değişiklik belgesi kaydını belirleyin. Olay türü inferred | |||
| Tedarik kaynağı atandı | Alıcının onaylanmış bir talep kalemine belirli bir tedarikçi, sözleşme veya bilgi kaydı atamasını ifade eder. Talebi satın alma siparişi oluşturmaya hazırlayan önemli bir adımdır. | ||
| Neden önemli? Bu etkinlik, onay ile sipariş arasındaki aşamayı tamamlar. Tedarik kaynağı atamak için geçen süreyi ölçmek, alıcının iş yükündeki gecikmeleri ve tedarik bulma verimliliğini belirlemeye yardımcı olur. Nereden alınır? EBAN tablosundaki sabit tedarikçi (LIFNR), bilgi kaydı (INFNR) veya sözleşme (KONNR) gibi tedarik kaynağıyla ilgili alanlara değer girilmesinden çıkarımla belirlenir. Kaydedin Değişiklik belgelerini kullanarak EBAN tablosundaki LIFNR, INFNR veya KONNR gibi alanların doldurulmasını izleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar: Gerekli CDS görünümlerine erişmek için SAP S/4HANA’da uygun yetkilere sahip bir kullanıcınız olduğundan emin olun. Genellikle bunun için S_TABU_NAM gibi nesnelere ilişkin izinler ve veri görüntüleme araçlarına erişim gerekir.
- Sisteme erişim yöntemini belirleyin: SQL sorgularını çalıştırmak için SAP S/4HANA veritabanına nasıl bağlanacağınızı belirleyin. SAP HANA Studio, ADT (ABAP Development Tools) içeren Eclipse IDE veya SAP HANA veritabanı istemcisi üzerinden bağlanabilen DBeaver gibi üçüncü taraf SQL istemcileri yaygın seçeneklerdir.
- SQL sorgusunu inceleyin: Sağlanan SQL betiğini gözden geçirin. Betik, farklı etkinliklere ait verileri toplamak için Common Table Expressions (CTE) kullanır ve bunları birleştirerek tek bir Event Log oluşturur.
- Yer tutucuları özelleştirin: Sorgudaki yer tutucuları bulun ve değiştirin. Veri çıkarma dönemi için tarih aralığını (
[YYYY-MM-DD]biçiminde) belirleyin ve kuruluşunuzla ilgili şirket kodlarını ([Your Company Code]) girin. - Sorguyu çalıştırın: Özelleştirilmiş SQL sorgusunun tamamını SAP S/4HANA veritabanında çalıştırın. Veri hacmine ve seçilen tarih aralığına bağlı olarak sorgunun tamamlanması zaman alabilir.
- İlk veri incelemesini yapın: Sorgu tamamlandığında sonuçların ilk birkaç satırını inceleyin. PurchaseRequisitionId, ActivityName ve EventTime gibi tüm sütunların beklendiği gibi dolduğunu ve veri biçimlerinin doğru olduğunu kontrol edin.
- Veri dönüşümünü kontrol edin: Sağlanan sorgu, Process Mining için uygun biçimde veri üretir. Veri türlerinin tutarlı olmasını sağlamak için
CASTveCONCATişlevleri kullanılır. Çalıştırma sonrasında büyük çaplı bir dönüşüm gerekmemelidir. - Event Logu dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Karakter sorunlarını önlemek için dosya kodlamasının UTF-8 olduğundan emin olun.
- Yükleme için hazırlanın: Process Mining aracına yüklemeden önce CSV dosyasının doğru başlıklara (
PurchaseRequisitionId,ActivityName,EventTimevb.) sahip olduğunu ve EventTime için kullanılan tarih ve saat biçiminin tutarlı ve hedef platformda desteklendiğini doğrulayın. - ProcessMind’e yükleyin: Son CSV dosyasını ProcessMind projenize yükleyin. Projeyi yapılandırırken
PurchaseRequisitionIdalanını vaka kimliği,ActivityNamealanını etkinlik veEventTimealanını zaman damgası olarak eşleyin.
Yapılandırma
- Temel CDS görünümleri: Veri çıkarma işlemi, temel talep verileri için ağırlıklı olarak
I_PurchaseRequisitionAPI01görünümünü, değişiklikleri ve durum güncellemelerini izlemek içinI_ChangeDocumentveI_ChangeDocumentItemgörünümlerini, satın alma siparişleriyle bağlantı kurmak içinseI_PurchaseOrderItemAPI01görünümünü kullanır. - Yetkilendirme: Sorguyu çalıştıran kullanıcının yukarıda belirtilen CDS görünümlerine okuma erişimi olmalıdır. Gerekli roller ve yetkiler için SAP güvenlik ekibinize danışın.
- Tarih aralığı filtresi: Veri hacmini sınırlamak için talep oluşturma tarihine (
CreationDate) tarih aralığı filtresi uygulayın. İlk analiz için 3 ila 6 aylık veri önerilir. - Kuruluş filtresi: Doğru iş biriminin sürecini analiz ettiğinizden emin olmak için verileri
CompanyCodealanına göre filtreleyin. Belirli satın alma süreçlerine, örneğin standart mal veya hizmet taleplerine odaklanmak içinPurchaseRequisitionTypealanına göre de filtreleme yapabilirsiniz. - Değişiklik belgesi yapılandırması: 'Talep değiştirildi' ve çeşitli onay adımları gibi etkinliklerin kaydedilmesi, SAP sisteminizde ilgili alanlar için değişiklik belgesi günlüğünün etkin olmasına bağlıdır. Bu olaylar eksikse EBAN tablosunun sistem yapılandırmasını kontrol edin.
- Performans: Milyonlarca talep içeren çok büyük sistemlerde bu sorguyu uzun bir dönem için çalıştırmak sistem performansını etkileyebilir. Sorguyu yoğun olmayan saatlerde veya verileri yakın zamanda yenilenmiş bir üretim dışı ortamda çalıştırmayı değerlendirin.
Örnek sorgu sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Adımlar
- EBAN ve EBKN tablolarını içeren SAP HANA şemasına doğrudan okuma erişiminiz olduğunu doğrulayın. Ayrıca sisteminizde talep değişiklikleri, serbest bırakma işlemleri, kaynak atamaları, satın alma siparişi referansları ve kapatma için kullanılan değişiklik belgesi ve satın alma belgesi nesnelerini belirleyin. Bu nesneler ve alanlar sürüme ve yapılandırmaya göre değişebileceğinden, sorgudaki köşeli parantezli her yer tutucuyu sisteminizdeki ilgili nesne veya alanla değiştirin.
- SAP GUI’de SE16H işlemini veya onaylı bir veritabanı yönetim aracını kullanarak EBAN ve EBKN tablolarını inceleyin. Talep anahtar alanlarını doğrulayın; tarih, saat, kullanıcı, durum, silme, serbest bırakma, hesap atama ve satın alma belgesi referansı alanlarının kullanılabilir olduğunu kontrol edin. Alan tanımlarını doğrulamak için SE11’i veya SAP veri sözlüğünü kullanın. Test sırasında üretim verilerini açığa çıkarmayın.
- Talep değişiklikleri ve onay değişiklikleri için yapılandırılmış değişiklik belgesi kaynağını belirleyin. Sorgu, talep numarası, kalem numarası, değiştirilen alan, eski değer, yeni değer, değişiklik tarihi, değişiklik saati ve kullanıcı alanlarını içeren, [Your requisition change document source] adlı standartlaştırılmış bir değişiklik kaynağı bekler. Çalıştırmadan önce bu kaynağı sisteminizdeki ilgili SAP değişiklik belgesi tablolarına veya CDS görünümüne eşleyin.
- Gönderim, onay sıfırlama, onay adımı başlangıcı, onay adımı tamamlanması, nihai onay ve ret için yapılandırılmış iş akışı veya serbest bırakma kaynağını belirleyin. Sorgu, talep numarası, kalem numarası, olay türü, serbest bırakma kodu veya onay grubu, onaylayan, olay tarihi, olay saati ve durum alanlarını içeren [Your requisition approval event source] kaynağını bekler. Bu kaynağı S/4HANA yapılandırmanızda kullanılan serbest bırakma veya iş akışı verilerine eşleyin.
- Kaynak atama, satın alma siparişi referansı ve kapatma kaynaklarını belirleyin. Sorgu, [Your requisition source assignment source], [Your requisition purchase order reference source] ve [Your requisition closure source] yer tutucularını bekler. Bunları sisteminizdeki onaylı tablolara veya görünümlere eşleyin. Satın alma siparişi oluşturma, başka satın alma etkinliklerinden çıkarım yoluyla değil, satın alma siparişi kalemi ile talep kalemi arasındaki açık bir referansla gösterilmelidir.
- Veri çıkarma aralığını [Start date] ve [End date] değerleriyle belirleyin. İlk çalıştırma için üç ila altı aylık bir aralık önerilir. Veritabanı performansını ve olay hacmini doğruladıktan sonra daha geniş bir aralık kullanın. Sorgu, oluşturulma ve olay tarihlerini filtrelerken talep kimliğini vaka kimliği olarak korur.
- SAP HANA’ya bağlı, onaylı bir SQL istemcisinde sorguyu çalıştırın. Sorgu dışındaki bağlantı bilgilerini, tarih parametrelerini, şirkete özel filtreleri ve açıkça belgelenmiş kaynak ve alan yer tutucularını değiştirin. Çıktı sütunlarının adlarını PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount ve RequisitionStatus olarak aynen koruyun.
- Yinelenen olayları, zaman damgası hassasiyetini, saat dilimi kullanımını ve kalem düzeyindeki ayrıntıyla belge düzeyindeki ayrıntıyı gözden geçirin. Sorgu, belge düzeyinde vaka kimlikleri üretir ve kalem bağlamını kendi içinde içerir. Birden fazla kalem aynı etkinliği aynı zaman damgasıyla oluşturuyorsa ProcessMind tasarımınız özellikle tekilleştirme gerektirmediği sürece satırları ayrı tutun.
- Gerekli her etkinliğin ActivityName değeri olarak bulunduğunu, EventTime alanının dolu ve kronolojik açıdan makul olduğunu, gerekli vaka kimliğinin boş olmadığını doğrulayın. Sayıları aynı tarih aralığına ait SAP raporlarıyla veya onaylı operasyonel veri aktarımlarıyla karşılaştırın.
- Sonuçları UTF-8 CSV veya ProcessMind’in desteklediği başka bir tablo biçiminde dışa aktarın. Başlık satırını ekleyin, ISO uyumlu zaman damgalarını koruyun, boş değerleri boş olarak bırakın ve dosyayı PurchaseRequisitionId vaka kimliği, ActivityName etkinlik sütunu, EventTime ise zaman damgası sütunu olacak şekilde yükleyin.
Yapılandırma
- Vaka kimliği: EBAN tablosundaki satın alma talebi belge numarasını PurchaseRequisitionId olarak kullanın. Süreç kalem düzeyinde yapılandırılmışsa bunun yerine talep numarası ve kalem numarası gibi belgelenmiş bir bileşik anahtar kullanın ve aynı anahtarı her olaya uygulayın.
- Birincil kaynak: EBAN, talep kalemi verileri için kullanılır. EBKN ise hesap ataması ve departman ya da masraf yeri bilgilerini eklemek için kullanılır. Çalıştırmadan önce SAP veri sözlüğünde alan adlarını ve veri türlerini doğrulayın.
- Olay kaynakları: Sorguda değişiklik, onay, kaynak atama, satın alma siparişi referansı ve kapatma kaynakları için bilerek yer tutucular kullanılmıştır. Bu kaynaklar S/4HANA sürümüne, iş akışı tasarımına, serbest bırakma prosedürüne, etkin işlevlere ve müşteri uzantılarına bağlıdır.
- Tarih aralığı: Üç ila altı aylık bir dönemle başlayın. Kullanılabiliyorsa dizinlenmiş veya bölüm budamayı destekleyen tarih alanlarında sınırlı bir aralık kullanın. Artımlı yüklemelerde, geç gelen değişiklikleri yakalamak için veri çıkarma aralıklarını yeterince örtüştürün; ardından vaka, etkinlik, zaman damgası, kalem ve kaynak olay anahtarını kullanarak yinelenen kayıtları tekilleştirin.
- İş filtreleri: [Company code filter], [Document type filter], [Purchasing group filter] ve [Plant filter] alanlarını yalnızca sisteminizde mevcut olduklarında ve iş anlamları doğrulandığında yapılandırın. Amaç tüm yaşam döngüsünü kaydetmekse duruma göre filtreleme yapmayın.
- Durum eşlemesi: Onayda, nihai onaylandı, reddedildi, sıfırlandı, serbest bırakma kodu bekliyor ve kapatıldı değerlerini hedef sistemdeki serbest bırakma stratejisine veya iş akışı yapılandırmasına göre ayarlayın. Tüm SAP istemcilerinde aynı durum kodunun kullanıldığını varsaymayın.
- Değişiklik eşlemesi: Sürecinizin önemli alanları olarak tanımladığı miktar, fiyat, malzeme, teslimat tarihi, hesap ataması ve diğer alanlardaki değişiklikleri ekleyin. Sorguda listelenen önemli alanlar için açık koşullar bulunur; kaynağın değiştirilen alan adını sunması gerekir.
- Zaman damgası kullanımı: Olay tarihini ve saatini veritabanının saat diliminde birleştirin, ardından UTC’ye yapılan dönüşümleri belgeleyin. Kaynakta yalnızca tarih tutuluyorsa, daha kesin bir zaman damgası bulunmadığında gece yarısını kullanın ve bu sınırlamayı kaydedin.
- Performans: İlk veri çıkarma işlemini tarih ve iş kapsamıyla sınırlandırın, yalnızca gerekli sütunları seçin, büyük değişiklik veya iş akışı geçmişlerine sınırsız JOIN uygulamayın ve HANA yürütme planını inceleyin. Veri çıkarma işleminin tekrarlanması gerekiyorsa standartlaştırılmış olay kaynaklarını somutlaştırın veya ara alana alın.
- Yetkiler ve ön koşullar: EBAN, EBKN, yapılandırılmış değişiklik ve iş akışı kaynakları, kaynak atama verileri, satın alma siparişi referans verileri ve kapatma verileri için okuma yetkisi alın. Doğrudan veritabanı erişiminin onaylandığını, ilgili satın alma ve iş akışı işlevlerinin etkin olduğunu, gerekli SAP HANA veritabanı lisansının veya yönetim araçlarının kullanılabildiğini doğrulayın.
- Güvenlik: En az ayrıcalık ilkesini uygulayın, kullanıcı ve onaylayan kimliklerini koruyun, satın alma ve finans bilgilerinin çıkarılmasına ilişkin kuruluş kurallarına uyun.
Örnek sorgu sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Başlamaya hazır mısınız?
Verilerinizi güvenle hazırlamak ve Satın Almadan Ödemeye talep sürecinizde Process Mining potansiyelinden yararlanmak için bu Templatei kullanın. Verimliliği artırmak için bugün çalışmaya başlayın.
Satın Almadan Ödemeye talep sürecindeki gecikmeleri durdurun: iş akışınızı şimdi iyileştirin!
Süreçleri iyileştirin, teslim sürelerini kısaltın ve çevrim süresini %30 azaltın.
Kredi kartı gerekmez, kurulum 5 dakika sürer.