Satın Almadan Ödemeye - Talep Veri Şablonunuz
Satın Almadan Ödemeye - Talep Veri Şablonunuz
- Ayrıntılı analiz için toplanması önerilen öznitelikler
- Süreç keşfi için izlenmesi gereken temel faaliyetler
- SAP S/4HANA'dan veri çıkarma yönergeleri
Satın Almadan Ödemeye - talep öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet adı ActivityName | Talep sürecinin belirli bir noktasında gerçekleşen iş faaliyetinin adı. | ||
| Açıklama Faaliyet adı, satın alma talebinin yaşam döngüsü içinde gerçekleşen belirli bir olayı veya görevi tanımlar. Bu faaliyetler değişiklik belgeleri ve Workflow geçmişleri gibi sistem günlüklerinden türetilir. 'Talep oluşturuldu', 'Onay adımı başladı' veya 'Satın alma siparişi oluşturuldu' gibi önemli süreç kilometre taşlarını temsil eder. Bu faaliyetleri analiz etmek, süreç akışını görselleştirmeyi, darboğazları belirlemeyi ve farklı aşamalarda harcanan süreyi ölçmeyi sağlar. 'Talep değiştirildi' veya 'Talep reddedildi' gibi faaliyetlerin sırasını ve sıklığını anlamak, süreç verimsizliklerini ve iyileştirme alanlarını belirlemek için önemlidir. Neden önemli? Süreçteki adımları tanımlar, süreç haritasının temelini oluşturur ve süreç akışının, varyasyonların ve darboğazların analiz edilmesini sağlar. Nereden alınır? Bu, genellikle değişiklik belgesi tablolarındaki (CDHDR, CDPOS) ve Workflow 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 faaliyetin gerçekleştiği kesin tarih ve saat. | ||
| Açıklama Olay zamanı, bir etkinliğin gerçekleştiği anı kaydeden zaman damgasıdır. Bu veri, bir vaka içindeki olayları kronolojik olarak sıralamak için gereklidir ve Process Mining içindeki tüm süre ve performans hesaplamalarının temelini oluşturur. Örneğin, "Talep gönderildi" ve "Talep onaylandı" olayları arasındaki zaman farkı onay çevrim süresini belirler. Doğru zaman damgaları süreç performansını analiz etmek, gecikmeleri belirlemek ve hizmet düzeyi anlaşmalarına uyumu izlemek için gereklidir. Bu öznitelik, çevrim sürelerini görselleştiren, bekleyen talepleri izleyen ve farklı zaman aralıklarındaki 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ını ve 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 Workflow 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 | Bir satın alma talebi belgesini benzersiz biçimde tanımlayan kimlik. | ||
| Açıklama Satın alma talebi kimliği, SAP S/4HANA içinde mal veya hizmet taleplerinin her birini benzersiz biçimde tanımlayan birincil anahtardır. Oluşturulmasından onaylanmasına, reddedilmesine veya satın alma siparişine dönüştürülmesine kadar belirli bir taleple ilgili tüm faaliyetleri ve değişiklikleri birbirine bağlayan merkezi vaka kimliği olarak görev yapar. Process Mining'de bu öznitelik, her talebin uçtan uca yaşam döngüsünü yeniden oluşturmak için temel niteliktedir. İlgili tüm olayları tek bir Satın alma talebi kimliği altında gruplayarak analistler çevrim sürelerini doğru biçimde ölçebilir, durum değişikliklerini izleyebilir ve bir talebin onay sürecinde izleyebileceği farklı yolları analiz edebilir. Neden önemli? Bu, ilgili tüm süreç adımlarını birbirine bağlayan ve talep yaşam döngüsünün eksiksiz ve tutarlı biçimde görülmesini sağlayan temel vaka kimliğidir. Nereden alınır? Bu öznitelik, EBAN tablosunda BANFN alanında bulunan Satın alma talebi numarasıdır. Örnekler 100178901001789110017892 | |||
| Departman Department | Talep maliyetlerinin yansıtıldığı departman veya maliyet merkezi. | ||
| Açıklama SAP’te genellikle Masraf Yeri ile gösterilen Departman özniteliği, talep edilen satın almadan sorumlu iş birimini tanımlar. Bu, talebin kalem düzeyinde atanan önemli bir finansal ve organizasyonel bilgidir. Process Mining kapsamında bu öznitelik, departman performansını analiz etmek için gereklidir. Farklı departmanların çevrim süresi, değişiklik oranı ve ret oranı gibi temel metriklerini karşılaştıran Dashboardlar oluşturulmasını sağlar. Böylece uygulamaları başka departmanlarda da kullanılabilecek yüksek performanslı departmanlar ve ek eğitim ya da süreç desteğine ihtiyaç duyabilecek departmanlar belirlenebilir. Neden önemli? İş birimleri arasındaki performansı karşılaştırmayı sağlar. Çevrim sürelerindeki veya ret oranlarındaki farklılıkları göstererek iyi uygulamaların ve iyileştirme alanlarının belirlenmesine yardımcı olur. Nereden alınır? Bu, genellikle hesap tayin tablosu EBKN'de KOSTL alanında bulunan Maliyet merkezidir. Örnekler FIN-1001IT-2005MKT-3010 | |||
| Kullanıcı kimliği UserId | Talebi oluşturan veya belirli bir faaliyeti 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ı tanımlar. Bu kişi talebi oluşturan çalışan, talebi onaylayan yönetici veya talebi değiştiren görevli olabilir. Otomatik adımlarda bu kimlik bir sistem ya da toplu işlem kullanıcısına ait olabilir. 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 ihtiyaçlarını belirlemek, yüksek performans gösteren çalışanları tespit etmek ve süreçte hesap verebilirliği sağlamak için önemlidir. Kullanıcı ana verileriyle birlikte kullanıldığında departman performansının analizini de destekler. Neden önemli? Kullanıcı performansının, iş yükü dağılımının ve süreç uyumluluğunun analiz edilmesini sağlar. Eğitim fırsatlarını ve kaynak darboğazlarını belirlemek için önemlidir. Nereden alınır? Oluşturan kullanıcı için EBAN-ERNAM alanında bulunur. Sonraki değişiklikler için CDHDR-USERNAME alanında, onaylar için ise Workflow 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 Onaylayan kimliği, bir onay veya ret etkinliğini tamamlayan kullanıcıyı özel olarak belirler. Bu kimlik, yalnızca onay iş akışındaki karar vericilere odaklandığı için genel Kullanıcı kimliğinden farklıdır. Bu bilgiyi yakalamak, onay sürecini ayrıntılı biçimde analiz etmek için önemlidir. Bu öznitelik, uzun onay sürelerine sahip yöneticileri veya talepleri sık sık reddeden kişileri belirlemek gibi onay davranışlarını analiz etmenizi sağlar. Onay adımı çevrim sürelerine ve iş akışı darboğazlarına odaklanan Dashboardlar için temel bir özniteliktir. Gecikmeye neden olabilecek belirli kişileri veya rolleri belirlemenize yardımcı olur. Neden önemli? Bir onay adımındaki belirli karar vericiyi gösterir ve onay döngüsü sürelerinin ve darboğazların kişi veya role göre ayrıntılı biçimde analiz edilmesini sağlar. Nereden alınır? Bu bilgi genellikle iş öğelerini tamamlayan kullanıcıyla ilişkilendiren SWW_WI2OBJ ve SWWLOGHIST gibi SAP Business Workflow tablolarından çıkarılı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 durumunu gösterir. SAP’te bu durum genellikle Talep Göstergesi ile temsil edilir. Bu gösterge, talebin bloke edildiğini, onayda olduğunu, 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ı anlamanın temel koşullarından biridir. Taleplerin nerede ve ne kadar süreyle beklediğini belirlemeye yardımcı olur. Durumlar arasındaki geçişlerin analiz edilmesi, onay sürecini ve varyantlarını ayrıntılı biçimde gösterir. 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 tablosunda FRGZU alanında bulunan Serbest bırakma göstergesiyle belirlenir. Örnekler B1S | |||
| Talep türü RequisitionType | Satın alma talebini sınıflandıran kod. Örneğin standart kalemler, hizmetler veya sermaye harcamaları için kullanılabilir. | ||
| Açıklama SAP’te Belge Türü olarak da adlandırılan Talep Türü, satın alma taleplerini kategorilere ayıran temel bir yapılandırma alanıdır. Farklı türler farklı onay iş akışlarını tetikleyebilir, alan ayarları değişebilir ve standart stok kalemleri, dış hizmetler veya varlık alımları gibi farklı iş amaçları için kullanılabilir. Süreç Talep Türüne göre analiz edildiğinde kuruluşlar, farklı talep türlerinin nasıl ele alındığını anlayabilir. Bu yaklaşım, kategoriler arasındaki performansı, çevrim sürelerini ve onay yollarını karşılaştırmayı sağlar. Böylece belirli talep türlerinin daha verimli olup olmadığı görülebilir ve süreç iyileştirmeleri buna göre uyarlanabilir. Neden önemli? Talepleri kategorilere ayırarak karşılaştırmalı analiz yapılmasını sağlar. Farklı talep türlerinin farklı süreç akışlarına, darboğazlara veya çevrim sürelerine sahip olup olmadığını anlamaya yardımcı olur. Nereden alınır? Bu, EBAN tablosunda 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 temel unsurlardan biridir. Daha yüksek tutarlı talepler genellikle daha fazla onay düzeyi gerektirir. Bu öznitelik analiz edilerek süreç tutara göre bölümlere ayrılabilir. Örneğin “Yüksek tutarlı taleplerin onaylanması daha mı uzun sürüyor?” veya “Sıkça reddedilen taleplerin tutarı nedir?” soruları yanıtlanabilir. Bu, süreç verimsizliklerinin finansal etkisini anlamak için önemli bir boyuttur. Neden önemli? Süreci finansal etkiye göre segmentlere ayırmaya yardımcı olur ve genellikle onay karmaşıklığı ve çevrim süresiyle ilişkilidir. Değere dayalı süreç analizi için önemlidir. Nereden alınır? Toplam değer EBAN tablosunda GFWERT alanında bulunur. Kalem düzeyindeki değer ise EBAN-PREIS alanındadır. Örnekler 1500.0075000.50250.75 | |||
| Aciliyet düzeyi UrgencyLevel | Talebin aciliyetini sınıflandırır ve işleme önceliğini etkileyebilir. | ||
| Açıklama Aciliyet Düzeyi, satın alma talebinin önceliğini gösterir. Standart ve özel bir alan olmasa da bazı kuruluşlar bu bilgiyi yakalamak için Gereksinim Takip Numarası gibi alanları kullanır. Böylece talep sahipleri, hızlandırılmış işlem gerektiren acil ihtiyaçları işaretleyebilir. Aciliyetin etkisini analiz etmek, sürecin acil taleplere doğru öncelik verip vermediğini değerlendirmek açısından önemlidir. Aciliyet düzeyi etki analizi Dashboardu bu özniteliği kullanarak acil ve standart taleplerin çevrim sürelerini ve onay oranlarını karşılaştırır. Böylece öncelikli işlemenin amaçlandığı gibi çalışıp çalışmadığı belirlenebilir. Neden önemli? Yüksek öncelikli taleplerde süreç performansının nasıl değiştiğini analiz etmenizi ve acil kalemlerin gerçekten hızlandırılıp hızlandırılmadığını doğrulamanızı sağlar. Nereden alınır? Standart bir aciliyet alanı yoktur. Bazı şirketler bu amaçla İhtiyaç Takip Numarası'nı (EBAN-BEDAR) kullanır. Bu bilgi özel bir alanda da tutulabilir. Örnekler YüksekOrtaDüşük | |||
| Bitiş zamanı EndTime | Belirli bir faaliyetin tamamlandığı kesin tarih ve saat. | ||
| Açıklama EndTime, bir faaliyetin 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. Buna karşılık onay gibi insan görevlerinin farklı başlangıç ve bitiş zamanları olabilir. Bu zaman damgası, işin tamamlandığı anı gösterir. Ayrı bir EndTime değerinin bulunması, aktif işlem süresi ile boşta bekleme süresini daha doğru ölçmenizi sağlar. ProcessingTime metriğini hesaplamak için StartTime ile birlikte kullanılır. Bu ayrıntı düzeyi, manuel görevlerde kaynak kullanımını ve verimliliği daha iyi analiz etmenize yardımcı olur. Neden önemli? Bir faaliyetin tamamlandığını gösterir; aktif işlem süresini hesaplamanızı ve görev süresini daha ayrıntılı görmenizi sağlar. Nereden alınır? Bu bilgi, bir iş öğesinin ne zaman oluşturulduğunu (StartTime) ve ne zaman tamamlandığını (EndTime) kaydedebilen Workflow günlüklerinden türetilir. Ö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 İhtiyaç tarihi, SAP'de Teslimat Tarihi olarak da adlandırılır ve talep kalemindeki mal veya hizmetlere ne zaman ihtiyaç duyulduğunu belirtir. Bu tarihi talep sahibi belirler ve tarih, satın alma sürecinin tamamı için hedef olarak kullanılır. Bu öznitelik, Zamanında Talep Tamamlama Oranı KPI'ını hesaplamak için gereklidir. Kuruluş, İhtiyaç Tarihi ile son onay veya satın alma siparişi oluşturma tarihini karşılaştırarak iç hizmet seviyelerini ve iş ihtiyaçlarını karşılama becerisini ölçebilir. Bu tarihi aşan taleplerin incelenmesi, satın alma sürecindeki sistematik gecikmeleri ortaya çıkarabilir. Neden önemli? Bir talep için hedef tamamlanma tarihini tanımlar; zamanında teslimatı ve iç hizmet seviyelerine uyumu ölçmenizi sağlar. Nereden alınır? Bu, EBAN tablosunda kalem düzeyinde LFDAT alanında bulunan Teslimat Tarihidir. Örnekler 2023-11-152023-12-012024-01-20 | |||
| Kaynak sistem SourceSystem | Verilerin hangi SAP S/4HANA örneğinden çıkarıldığını tanımlar. | ||
| Açıklama Kaynak sistem özniteliği, süreç verilerinin üretildiği kaynak sistemi gösterir. Geliştirme, kalite güvence ve üretim için farklı sistemlerin veya farklı bölgeler için ayrı sistemlerin kullanıldığı çoklu SAP örneklerine sahip kuruluşlarda bu alan, veri yönetişimi ve bağlam açısından önemlidir. Farklı kaynaklardan gelen verilerin birbirinden ayrılmasını sağlayarak yanlış toplulaştırmayı önler ve sisteme özel analiz yapılmasına imkan verir. Veri soyunun korunması ve süreç verilerinin izlenebilirliğinin sağlanması için zorunlu bir özniteliktir. Neden önemli? Özellikle birden fazla sistemin bulunduğu ortamlarda veri kaynağı ve yönetişimi için gerekli bağlamı sağlar ve verilerin izlenebilirliğini güvence altına alır. 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ımı adı ApprovalStepName | Workflow içindeki bir onay adımının özel adı veya açıklaması. | ||
| Açıklama Onay Adımı Adı, “Yönetici onayı” veya “Finans Başkan Yardımcısı onayı” gibi belirli bir onay aşamasının kullanıcıların anlayabileceği açıklamasını sunar. Bu ifade, genel bir “Onay adımı tamamlandı” etkinliğinden daha açıklayıcıdır. Bu öznitelik, Onay adımı çevrim süresi ve iş akışı darboğaz analizi Dashboardları için önemlidir. Onay sürecini ayrıntılı biçimde incelemeyi, en uzun gecikmelere neden olan aşamaları ve işlerin biriktiği noktaları tam olarak belirlemeyi sağlar. Bu ayrıntı düzeyi, onay zincirine yönelik hedefli iyileştirmeler yapmak için gereklidir. Neden önemli? Onay aşamalarını ayrıntılı biçimde göstererek çok düzeyli onay iş akışındaki darboğazların kesin olarak belirlenmesini sağlar. Nereden alınır? Bu bilgi, Workflow görev açıklamasından türetilir. Workflow günlüğü T528T gibi görev tanımı tablolarına bağlanarak elde edilebilir. Örnekler Yönetici onayıDirektör onayıFinans Başkan Yardımcısı onayı | |||
| Otomatik mi IsAutomated | Bir faaliyetin insan yerine sistem kullanıcısı tarafından gerçekleştirilip gerçekleştirilmediğini gösteren işaret. | ||
| Açıklama Otomatik mi özniteliği, bir faaliyetin WF-BATCH gibi bir sistem veya toplu işlem kullanıcısı tarafından yürütülmesi durumunda true değerini alan bir boolean işarettir. Bu öznitelik, süreçteki manuel ve otomatik adımları ayırt etmenizi sağlar. Bu öznitelik, talep sürecindeki otomasyon düzeyini ölçmek ve Otomatik Onay Oranı KPI'ını hesaplamak için gereklidir. Analistler, otomatik veya manuel adımlara göre filtreleme yaparak verimliliklerini karşılaştırabilir ve işlem sürelerini ve manuel çabayı azaltacak ek otomasyon fırsatlarını belirleyebilir. Neden önemli? İnsanlar ve sistemler tarafından yürütülen faaliyetleri ayırt eder. Bu ayrım, 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ı listesindeki bir kullanıcıya ait olup olmadığını kontrol eden bir kurala dayanan türetilmiş bir özniteliktir. Örnekler truefalse | |||
| Para birimi Currency | Talep tutarının para birimi kodu. | ||
| Açıklama Bu öznitelik, talep tutarının hangi para birimiyle ifade edildiğini belirtir. Örneğin USD, EUR veya JPY olabilir. Özellikle birden fazla para birimiyle faaliyet gösteren çok uluslu kuruluşlarda Talep tutarı özniteliği için gerekli bağlamı sağlar. Doğru finansal analiz ve raporlama için para biriminin dikkate alınması gerekir. Talep değerleri toplanırken veya karşılaştırılırken anlamlı sonuçlar elde etmek için tüm tutarlar ortak bir para birimine dönüştürülmelidir. Bu öznitelik, söz konusu dönüşümlerin ön koşuludur. Neden önemli? Talep tutarı için gerekli bağlamı sağlar ve çoklu para birimi kullanılan ortamlarda doğru finansal analiz ve karşılaştırma yapılmasına imkan verir. Nereden alınır? EBAN tablosunda WAERS alanında bulunur. Örnekler USDEURGBP | |||
| Ret nedeni RejectionReason | Bir satın alma talebi reddedildiğinde belirtilen neden. | ||
| Açıklama Ret Nedeni, onaylayanın satın alma talebini neden reddettiğini açıklar. Nedenler arasında bütçenin aşılması, yanlış bilgi, politikaya uyumsuzluk veya başka bir talebin tekrarlanması bulunabilir. Bu bilgi, süreçteki başarısızlıkları anlamak için gerekli bağlamı sağlar. Ret nedenlerinin analizi, süreç verimsizliklerinin ve yeniden çalışmanın kök nedenlerini belirlemeye yardımcı olur. Örneğin “Yanlış Masraf Yeri” sık görülen bir nedense, kullanıcı eğitimlerinin veya sistem doğrulamasının iyileştirilmesi gerektiğini gösterir. 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 ortaya çıkarır; yeniden işi azaltmak ve taleplerde ilk seferde doğru sonuç oranını artırmak için hedefli iyileştirmeler yapmanızı sağlar. Nereden alınır? Bu genellikle standart bir alan değildir. Workflow container öğelerinde, taleple ilişkilendirilmiş uzun metinlerde veya özel alanlarda tutulabilir. Örnekler Bütçe aşıldıHatalı tedarikçiYinelenen 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 resmi satın alma belgesinin tanımlayıcısıdır. Satın alma siparişinin oluşturulması, talep için çoğu zaman başarılı son aşamadır. Bu, talebin tedarikçiyle yapılacak resmi bir siparişe dönüştürüldüğünü gösterir. Bu öznitelik, Talep ile Satın Alma Siparişi Arasındaki Çevrim Süresi KPI'ını ve genel dönüşüm oranını ölçmek için önemlidir. Talep oluşturma sürecini sonraki satın alma sürecine 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ğlar; talebin satın alma siparişine dönüşüm oranını ve çevrim süresini ölçmenizi sağlar. Nereden alınır? Talep kaleminden bir satın alma siparişi oluşturulduğunda EBAN tablosundaki EBELN alanında bulunur. Örnekler 450001789045000178914500017892 | |||
| Son veri güncellemesi LastDataUpdate | Bu kayda ait verilerin kaynak sistemden en son ne zaman yenilendiğini gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden yapılan en son veri çıkarma veya güncellemenin tarih ve saatini kaydeder. Analiz edilen verilerin güncelliğini anlamak için önemli bir meta veri unsurudur. Analistler ve iş kullanıcıları, süreç verilerinin operasyonların en güncel durumunu yansıtıp yansıtmadığını bu zaman damgası sayesinde anlayabilir. Her süreç analizinde verilerin güncelliğini bilmek, bilinçli kararlar almak için temel bir gerekliliktir. Bu öznitelik, kullanıcı beklentilerinin yönetilmesine yardımcı olur ve sonuçların ilgili analiz için gereken güncellik düzeyindeki verilere dayanmasını sağlar. Neden önemli? Verilerin güncelliğini gösterir. Bu, analize güvenmek ve zamanında iş kararları almak için önemlidir. Nereden alınır? Bu zaman damgası, veri çıkarma, dönüştürme ve yükleme (ETL) süreci sırasında oluşturulur ve eklenir. Örnekler 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Yeniden iş mi IsRework | Bir faaliyetin, gönderimden sonra yapılan değişiklik gibi yeniden iş oluşturup oluşturmadığını gösteren işaret. | ||
| Açıklama Yeniden çalışma, katma değer sağlamayan veya tekrarlanan işleri temsil eden etkinlikleri belirleyen hesaplanmış bir doğru/yanlış göstergesidir. Bu süreçte yaygın bir örnek, talep onaya gönderildikten sonra gerçekleşen “Talep değiştirildi” etkinliğidir. Bu durumda onay sürecinin yeniden başlatılması gerekir. Bu öznitelik, süreçteki yeniden çalışma miktarını ve bunun toplam çevrim sürelerine etkisini ölçmek için gereklidir. Talep değişikliği ve yeniden çalışma oranı Dashboardu, süreç verimsizliklerini göstermek için bu işarete dayanır. Yeniden çalışmanın azaltılması, 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 çabayı veya tekrarı temsil eden faaliyetleri işaretler; yeniden işi ve bunun süreç verimliliğine etkisini doğrudan ölçmenizi sağlar. Nereden alınır? Bu, hesaplanmış bir özniteliktir. Mantık, ilk Talep Onaya Gönderildi faaliyetinden sonra gerçekleşen Talep Değiştirildi faaliyetlerini genellikle yeniden iş olarak işaretler. Örnekler truefalse | |||
Satın Almadan Ödemeye - talep aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Onay adımı tamamlandı | Onaylayan kişinin bir talep üzerinde olumlu işlem yaparak çok düzeyli onay iş akışındaki bir adımı tamamladığı sırada gerçekleşir. Bu olay, talebin serbest bırakma durumundaki bir değişiklikten çıkarılır. | ||
| Neden önemli? Bu etkinlik, onay iş akışının ayrıntılı analizini ve her bir adım için geçen sürenin ölçülmesini sağlar. Süreçte verimli çalışan onaylayan kişilerle darboğazları belirlemenize yardımcı olur. Nereden alınır? EBAN tablosuna ilişkin değişiklik belgelerinden (CDHDR/CDPOS) çıkarılır. Belirli bir kod için serbest bırakma kodu durumunun (ör. FRGZU alanında) serbest bırakılmamış durumdan serbest bırakılmış duruma geçmesi bu olayı gösterir. Yakalayın 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, talebi sonraki satın alma belgesine bağlayan açık bir sistem olayıdır. | ||
| Neden önemli? Bu, talep sürecinde önemli bir kilometre taşı ve başarılı bir sonuçtur. Talep onayı ile PO oluşturma arasındaki süre, satın alma verimliliğini ölçen önemli bir KPI'dır. Nereden alınır? Bir 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) saklanır. Yakalayın EKPO tablosunu talep numarası ve kalem üzerinden EBAN tablosuna bağlayın. PO kaleminin oluşturulma tarihi olayı gösterir. Olay türü explicit | |||
| Talep kapatıldı | Talep kaleminin tamamen işlendiğini ve bu kalemden başka satın alma siparişi oluşturulamayacağını gösterir. Bu durum, genellikle sipariş edilen toplam miktar talep miktarına eşit olduğunda otomatik olarak ayarlanır. | ||
| Neden önemli? Bu faaliyet, talep kaleminin yaşam döngüsünün nihai ve başarılı şekilde tamamlandığını 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ılır. 'Kapalı' göstergesi (EBAKZ) ayarlandığında gerçekleşir. Bu genellikle PO'larda sipariş edilen miktar talep miktarına eşit olduğunda olur. Yakalayın Değişiklik belgeleri aracılığıyla 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şturulmasını ifade eder. Kullanıcı yeni bir talebi ilk kez kaydettiğinde bu olay açıkça yakalanır ve oluşturma zaman damgası kaydedilir. | ||
| Neden önemli? Bu faaliyet, talep yaşam döngüsü analizinin temel başlangıç noktasıdır. İlk ihtiyacın belirlenmesinden nihai onaya veya satın alma siparişine dönüştürülmesine kadar uçtan uca çevrim süresini ölçmek için gereklidir. Nereden alınır? Bu, EBAN tablosundan açıkça yakalanan bir olaydır. Belirli satın alma talebi numarası (BANFN) için oluşturma tarihi (ERDAT) ve oluşturma saati (ERZEIT) alanları kullanılır. Yakalayın 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 nihai ve eksiksiz onayını gösterir. Bu onay, talebin satın alma siparişine dönüştürülebilmesini sağlar. Bu kilometre taşı, genel serbest bırakma durumu nihai onay durumuna ulaştığında çıkarılır. | ||
| Neden önemli? Bu, önemli bir başarı kilometre taşı ve çevrim süresi analizinde yaygın bir bitiş noktasıdır. Talebin tüm kontrollerden geçtiğini ve satın alma departmanının işlem yapmasına hazır olduğunu gösterir. Nereden alınır? EBAN tablosundaki durum değişikliğinden çıkarılır. Özellikle genel serbest bırakma göstergesi (FRGZU) veya işlem durumu (PROCSTAT) nihai 'Onaylandı' değerine güncellendiğinde oluşur. Yakalayın Nihai serbest bırakma kodunun uygulandığı veya genel talep durumunun 'Onaylandı' olarak değiştiği zaman damgasını belirleyin. Olay türü inferred | |||
| Talep reddedildi | Bir onaylayıcının satın alma talebini nihai olarak reddetmesini ve süreci durdurmasını ifade eder. Bu durum, reddedilmeyi gösteren belirli bir durum güncellemesiyle yakalanır. | ||
| Neden önemli? Bu faaliyet, önemli bir başarısızlık bitiş noktasıdır. Ret sıklığını, nedenlerini ve sürecin hangi noktalarında gerçekleştiğini analiz etmek; politika uyumluluğu, bütçe veya talep kalitesiyle ilgili sorunları belirlemeye yardımcı olur. Nereden alınır? EBAN tablosundaki durum değişikliğinden çıkarılır. İşlem durumu (PROCSTAT) veya serbest bırakma göstergesi, açıkça 'Reddedildi' anlamına gelen bir değere ayarlanır. Yakalayın Değişiklik belgeleri aracılığıyla EBAN'daki genel durumun 'Reddedildi' durumuna güncellendiği zaman damgasını belirleyin. Olay türü inferred | |||
| Onay adımı başladı | Bir talebin belirli bir onaylayıcıdan veya onay grubundan işlem beklediğini gösterir. Talep durumu belirli bir serbest bırakma kodunun beklemede olduğunu gösterdiğinde bu olay çıkarılır. | ||
| Neden önemli? Bu faaliyet, onay zincirindeki darboğazları belirlemek için gereklidir. Bu durumun ne kadar sürdüğünü analiz etmek, bekleyen talepleri ve iş yükü yüksek 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ılır. Belirli bir serbest bırakma kodu işlenecek sıradaki kod olduğunda olay başlar. Yakalayın İş akışı günlüklerine veya durum alanlarına göre bir talebin belirli bir serbest bırakma kodu için onay bekleyen duruma geçtiği zamanı belirleyin. Olay türü inferred | |||
| Onay sıfırlandı | Genellikle talepte önemli bir değişiklik yapılması nedeniyle tüm onay iş akışının sıfırlandığı olayı temsil eder. Bu işlem, onay sürecinin ilk düzeyden yeniden başlamasına neden olur. | ||
| Neden önemli? Bu faaliyet, çevrim süresini ciddi biçimde etkileyen önemli bir yeniden çalışmayı gösterir. Onay sıfırlamalarının nedenlerini belirlemek, süreci sadeleştirmek ve gecikmeleri azaltmak için önemlidir. Nereden alınır? EBAN tablosundaki değişiklik belgelerinden (CDHDR/CDPOS) çıkarılır. Serbest bırakma durumu alanlarının (FRGKZ veya FRGZU gibi), kısmen ya da tamamen ayarlanmış durumdayken temizlendiği tespit edildiğinde bu olay oluşturulur. Yakalayın Değişiklik günlüklerinde serbest bırakma durumunun serbest bırakılmış durumdan yeniden serbest bırakılmamış duruma geçtiği kaydı arayın. 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'nin 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 için önemlidir. Değişikliklerin sık görülmesi, veri kalitesi veya değişen gereksinimlerle ilgili sorunlara işaret eder. Bunlar süreç iyileştirmesi için önemli alanlardır. Nereden alınır? EBAN tablosunda yapılan değişiklikler için SAP değişiklik belgesi tablolarına (CDHDR ve CDPOS) açıkça kaydedilir. İzlenen her alandaki değişiklik bir kayıt oluşturur. Yakalayın Satın alma talepleri için nesne sınıfının BANF olduğu CDHDR/CDPOS kayıtlarından değişiklik olaylarını çıkarın. Olay türü explicit | |||
| Talep geri çekildi | Asıl talep sahibi, talep tamamen işlenmeden önce talebi iptal ettiğinde veya sildiğinde gerçekleşir. Bu işlem genellikle talep kalemi üzerinde silme göstergesini ayarlayan açık bir eylemdir. | ||
| Neden önemli? Geri çekmeleri izlemek, talep dalgalanmalarını ve iptal nedenlerini anlamaya yardımcı olur. Bu durum, talep için terminal durumdur ve sonraki işlemleri engeller. Nereden alınır? EBAN tablosundaki silme göstergesi (LOEKZ) alanı bir talep kalemi için ayarlandığında açıkça yakalanır. Değişiklik CDHDR/CDPOS kayıtlarına yazılır. Yakalayın EBAN tablosundaki silme göstergesinin (LOEKZ) 'L' olarak ayarlandığı olayı belirleyin. Olay türü explicit | |||
| Talep onaya gönderildi | Talep sahibinin talebi resmi olarak gönderdiği ve onay iş akışını tetiklediği anı temsil eder. Bu olay genellikle talebin serbest bırakma stratejisi belirlendiğinde ve durum "Onayda" olarak değiştiğinde çıkarılır. | ||
| Neden önemli? Bu, onay döngüsü süresi Metrikleri için sürenin başlatıldığı önemli bir kilometre taşıdır. Oluşturma ile gönderim arasındaki süreyi analiz etmek, talebin hazırlanma aşamasındaki gecikmeleri ortaya çıkarabilir. Nereden alınır? EBAN tablosuna ilişkin değişiklik belgelerinden (CDHDR/CDPOS) çıkarılır. Özellikle serbest bırakma stratejisi alanlarının (ör. FRGST) doldurulması veya genel durumun (PROCSTAT) onay sürecini gösteren bir duruma değişmesi dikkate alınır. Yakalayın 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ı | Bir satın alma uzmanının onaylanmış talep kalemine belirli bir tedarikçi, sözleşme veya bilgi kaydı atamasını ifade eder. Bu, talebi satın alma siparişi oluşturmaya hazırlayan önemli bir adımdır. | ||
| Neden önemli? Bu faaliyet, onay ile sipariş verme arasındaki boşluğu kapatır. Kaynak atama süresini ölçmek, satın alma uzmanının iş yükündeki ve tedarik verimliliğindeki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? EBAN tablosundaki tedarik kaynağıyla ilgili alanlara sabit tedarikçi (LIFNR), bilgi kaydı (INFNR) veya sözleşme (KONNR) gibi bir değer girildiğinde çıkarılır. Yakalayın EBAN tablosunda LIFNR, INFNR veya KONNR gibi alanların doldurulmasını değişiklik belgeleri üzerinden 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ı hesabınız olduğundan emin olun. Bu genellikle S_TABU_NAM gibi nesneler için izinleri ve veri görüntüleme araçlarına erişimi kapsar.
- Sistem erişim yöntemini belirleyin: SQL sorgularını çalıştırmak üzere SAP S/4HANA veritabanına nasıl bağlanacağınızı belirleyin. Yaygın araçlar arasında 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 bulunur.
- SQL sorgusunu inceleyin: Sağlanan SQL betiğini tanıyın. 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. Çıkarma dönemi için tarih aralığını (
[YYYY-MM-DD]biçiminde) ayarlamanız ve kuruluşunuzla ilgili şirket kodlarını ([Your Company Code]) belirtmeniz gerekir. - Sorguyu çalıştırın: Tamamlanmış ve özelleştirilmiş SQL sorgusunu SAP S/4HANA veritabanında çalıştırın. Veri hacmine ve seçilen tarih aralığına bağlı olarak sorgunun tamamlanması biraz zaman alabilir.
- İlk veri incelemesini yapın: Sorgu tamamlandığında çıktının ilk birkaç satırını inceleyin. PurchaseRequisitionId, ActivityName ve EventTime gibi tüm sütunların beklendiği şekilde doldurulduğunu ve veri biçimlerinin doğru olduğunu kontrol edin.
- Veri dönüşümünü değerlendirin: Sağlanan sorgu, Process Mining için hazır bir biçimde veri üretmek üzere tasarlanmıştır. Veri türlerinin tutarlı olmasını sağlamak için
CASTveCONCATişlevleri kullanılır. Çalıştırma sonrasında büyük bir dönüşüm yapılması gerekmemelidir. - Event Logu dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden bir CSV dosyasına aktarın. Karakter sorunlarını önlemek için dosya kodlamasının UTF-8 olduğundan emin olun.
- Yüklemeye hazırlanın: Bir Process Mining aracına yüklemeden önce CSV dosyasında doğru başlıkların (
PurchaseRequisitionId,ActivityName,EventTimevb.) bulunduğunu ve EventTime için tarih ve saat biçiminin tutarlı olup hedef platform tarafından desteklendiğini doğrulayın. - ProcessMind’e yükleyin: Son CSV dosyasını ProcessMind projenize yükleyin. PurchaseRequisitionId alanını Vaka kimliği, ActivityName alanını Etkinlik ve EventTime alanını zaman damgası olarak eşleyerek projeyi yapılandırın.
Yapılandırma
- Temel CDS View'lar: Veri çıkarma işlemi temel olarak ana talep verileri için
I_PurchaseRequisitionAPI01, değişiklikleri ve durum güncellemelerini izlemek içinI_ChangeDocumentveI_ChangeDocumentItem, satın alma siparişlerine bağlantı kurmak için deI_PurchaseOrderItemAPI01kullanır. - Yetkilendirme: Sorguyu çalıştıran kullanıcının yukarıda belirtilen CDS View'lar için okuma erişimi olmalıdır. Gerekli rol 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 uygulamak büyük önem taşır. İlk analiz için 3 ila 6 aylık veri önerilir. - Kuruluş filtresi: Doğru tüzel kişilik için analiz yaptığınızdan emin olmak üzere verileri
CompanyCodealanına göre filtreleyin. Belirli satın alma süreçlerine, örneğin standart mal ve hizmet süreçlerine 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 faaliyetlerin yakalanması, 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 yakın zamanda yenilenmiş verilerin bulunduğu üretim dışı bir ortamda çalıştırmayı değerlendirin.
a Ö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şiminizin olduğunu doğrulayın. Talep değişiklikleri, serbest bırakma işlemleri, kaynak atama, satın alma siparişi referansları ve kapatma için sisteminizde 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 karşılık gelen 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 ve kullanılabilir tarih, saat, kullanıcı, durum, silme, serbest bırakma, hesap tayini ve satın alma belgesi referans alanlarını 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, [Your requisition change document source] adlı normalleştirilmiş bir değişiklik kaynağı ve 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ı bekler. Çalıştırmadan önce bu kaynağı sisteminizdeki ilgili SAP değişiklik belgesi tablolarına veya CDS View'a eşleyin.
- Gönderim, onay sıfırlama, onay adımı başlangıcı, onay adımı tamamlanması, son onay ve ret için yapılandırılmış Workflow veya serbest bırakma kaynağını belirleyin. Sorgu, durum veya serbest bırakma geçişi başına bir satır içeren [Your requisition approval event source] kaynağını ve talep numarası, kalem numarası, olay türü, serbest bırakma kodu veya onay grubu, onaylayan, olay tarihi, olay saati ve durum alanlarını bekler. Bu kaynağı S/4HANA yapılandırmanızda kullanılan serbest bırakma veya Workflow kalıcılık katmanına 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. Bu yer tutucuları sisteminizdeki onaylı tablolara veya View'lara eşleyin. Satın alma siparişi oluşturma, ilgisiz satın alma faaliyetlerinden çıkarılmamalı; satın alma siparişi kaleminden talep kalemine açık bir referansla gösterilmelidir.
- Çıkarma aralığını [Start date] ve [End date] değerlerini kullanarak belirleyin. İlk çalıştırma için üç ila altı aylık bir aralık önerilir. Daha geniş bir aralığı yalnızca veritabanı performansını ve olay hacmini doğruladıktan sonra kullanın. Sorgu oluşturma ve olay tarihlerini filtrelerken talep tanımlayıcısını Case ID olarak korur.
- Sorguyu SAP HANA'ya bağlı onaylı bir SQL istemcisinde ç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ütun adlarını tam olarak PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount ve RequisitionStatus olarak koruyun.
- Yinelenen olayları, zaman damgası hassasiyetini, saat dilimi işlemlerini ve kalem düzeyi ile belge düzeyi ayrımını inceleyin. Sorgu, belge düzeyinde Case ID'ler üretir ve kalem bağlamını dahili olarak içerir. Birden fazla kalem aynı faaliyet ve zaman damgasını oluşturuyorsa ProcessMind tasarımınız özellikle tekilleştirme gerektirmediği sürece ayrı satırları koruyun.
- Gerekli her faaliyetin ActivityName değeri olarak bulunduğunu, EventTime alanının dolu ve kronolojik açıdan makul olduğunu ve gerekli Case ID'nin null olmadığını doğrulayın. Aynı tarih aralığı için SAP raporları veya onaylı operasyonel veri aktarımlarıyla kayıt sayılarını karşılaştırın.
- Sonucu UTF-8 CSV veya ProcessMind tarafından desteklenen başka bir tablo biçiminde dışa aktarın. Başlık satırı ekleyin, ISO uyumlu zaman damgalarını koruyun, null değerleri boş bırakın ve dosyayı PurchaseRequisitionId Case ID, ActivityName faaliyet sütunu ve EventTime zaman damgası sütunu olacak şekilde yükleyin.
Yapılandırma
- Case ID: EBAN'daki 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, hesap tayini ve departman veya masraf merkezi zenginleştirmesi için kullanılır. Çalıştırmadan önce kesin alan adlarını ve veri türlerini SAP veri sözlüğünde doğrulayın.
- Olay kaynakları: Sorgu, değişiklik, onay, kaynak atama, satın alma siparişi referansı ve kapatma kaynakları için bilinçli olarak açıklayıcı yer tutucular kullanır. Bunun nedeni, bu kaynakların S/4HANA sürümüne, Workflow tasarımına, serbest bırakma prosedürüne, etkinleştirilmiş işlevlere ve müşteri uzantılarına bağlı olmasıdır.
- Tarih aralığı: Üç ila altı ayla başlayın. Kullanılabildiği durumlarda dizinlenen veya bölüm budamasına olanak veren tarih alanlarında sınırlı bir aralık kullanın. Artımlı yüklemelerde geç gelen değişiklikleri yakalamak için çıkarma aralıklarını yeterince üst üste bindirin, ardından Case ID, faaliyet, zaman damgası, kalem ve kaynak olay anahtarını kullanarak tekilleştirin.
- İş filtreleri: [Company code filter], [Document type filter], [Purchasing group filter] ve [Plant filter] filtrelerini yalnızca bu alanlar mevcutsa ve iş anlamları doğrulanmışsa yapılandırın. Amaç tüm yaşam döngüsünü yakalamaksa durum alanına göre filtreleme yapmaktan kaçının.
- Durum eşleme: In Approval, final approved, rejected, reset, pending release code ve closed değerlerini hedef sistemdeki serbest bırakma stratejisine veya Workflow yapılandırmasına göre yapılandırın. Tüm SAP istemcilerinde tek bir durum kodunun geçerli olduğunu varsaymayın.
- Değişiklik eşleme: Miktar, fiyat, malzeme, teslimat tarihi, hesap tayini ve sürecinizin temel alan olarak tanımladığı diğer alanlardaki değişiklikleri dahil edin. Sorgu, listelenen temel alanlar için açık koşullar içerir ve kaynağın değiştirilen alan adını sunmasını gerektirir.
- Zaman damgası işlemleri: Olay tarihi ve saatini veritabanı saat diliminde birleştirin, ardından UTC'ye yapılan dönüşümü belgeleyin. Bir kaynak yalnızca tarih tutuyorsa 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ırlayın, yalnızca gerekli sütunları seçin, büyük değişiklik veya Workflow geçmişlerine sınırsız birleştirmeler uygulamayın ve HANA yürütme planını inceleyin. Tekrarlanan veri çıkarma gerekiyorsa normalleştirilmiş olay kaynaklarını somutlaştırın veya hazırlama alanında tutun.
- Yetkilendirmeler ve ön koşullar: EBAN, EBKN, yapılandırılmış değişiklik ve Workflow 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 Workflow işlevlerinin etkin olduğunu ve 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 tanımlayıcılarını koruyun ve satın alma ve finans bilgilerini dışa aktarmaya ilişkin kuruluş kurallarına uyun.
a Ö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üreciniz için Process Mining potansiyelinden tam olarak yararlanmak üzere bu Templatei kullanın. Verimliliği artırmaya bugün başlayın!
Satın Almadan Ödemeye taleplerindeki gecikmeleri durdurun: İş akışınızı şimdi optimize edin!
Süreçleri daha akıcı hale getirin, çevrim sürelerini kısaltın ve çevrim süresini %30'a kadar azaltın.
Kredi kartı gerekmez, kurulum 5 dakika sürer.