Satın Almadan Ödemeye - Talep Veri Template'inuz
Satın Almadan Ödemeye - Talep Veri Template'inuz
- Ayrıntılı analiz için toplanması önerilen nitelikler
- Süreç keşfi için izlenecek temel aktiviteler
- SAP S/4HANA'dan `veri` veri çekme kılavuzu
Satın Almadan Ödemeye - Talep Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite Adı ActivityName | Talep sürecinde belirli bir noktada gerçekleşen iş aktivitesinin adı. | ||
| Açıklama Activity Adı, bir satın alma talebinin süreç döngüsü içinde gerçekleşen belirli bir olayı veya görevi tanımlar. Bu activity'ler, değişim dokümanları ve workflow geçmişleri gibi sistem log'larından türetilir ve 'Satın Alma Talebi Oluşturuldu', 'Onay Adımı Başlatıldı' veya 'Satınalma Siparişi Oluşturuldu' gibi önemli süreç dönüm noktaları.nı temsil eder. Bu aktiviteleri analiz etmek, süreç akışının görselleştirilmesine, darboğazların belirlenmesine ve farklı aşamalarda harcanan zamanın ölçülmesine sunar. 'Satın Alma Talebi Değiştirildi' veya 'Satın Alma Talebi Reddedildi' gibi aktivitelerin sırasını ve sıklığını anlamak, süreç verimsizliklerini ve iyileştirme alanlarını belirlemek için büyük önem taşır. Neden Önemli?dir? Süreçteki adımları tanımlar, süreç haritasının temelini oluşturur ve süreç akışının, varyasyonların ve Nereden Alınır?? Bu, genellikle değişim dokümanı tablolarından (CDHDR, CDPOS) ve workflow log'larından (örn. SWWLOGHIST) veri yorumlayarak oluşturulan türetilmiş bir niteliktir. Örnekler::::::: Talep OluşturulduOnay Adımı TamamlandıTalep OnaylandıSatınalma Siparişi Oluşturuldu | |||
| Olay Zamanı EventTime | Belirli bir etkinliğin meydana geldiği tam tarih ve saat. | ||
| Açıklama Event Time (Olay Zamanı), bir faaliyetin ne zaman gerçekleştiğini kaydeden zaman damgası (zaman damgası)dır. Bu Doğru zaman damgaları, süreç performansını analiz etmek, gecikmeleri belirlemek ve hizmet seviyesi anlaşmalarına uyumu izlemek için büyük önem taşır. Bu nitelik, döngü sürelerini görselleştiren, bekleyen talepleri izleyen ve farklı zaman dilimlerindeki performansı karşılaştıran Neden Önemli?dir? Bu zaman damgası (zaman damgası), olayları sıralamak, çevrim sürelerini hesaplamak ve süreç performansını ve darboğazları analiz etmek için büyük önem taşır. Nereden Alınır?? zaman damgası (zaman damgası)'lar genellikle değişim dokümanı başlıklarından (CDHDR-UDATE, CDHDR-UTIME) veya workflow event log'larından alınır. Örnekler::::::: 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Satın Alma İsteği Kimliği PurchaseRequisitionId | Bir purchase requisition document'ı için unique tanımlayıcı. | ||
| Açıklama Satın Alma Talebi Kimliği, SAP S/4HANA içinde her mal veya hizmet talebini benzersiz şekilde tanımlayan birincil key'dir. Oluşturulmasından onay, ret veya satın alma siparişine dönüştürülmesi gibi nihai durumuna kadar belirli bir taleple ilgili tüm aktiviteleri ve değişiklikleri birbirine bağlayan merkezi vaka tanımlayıcısı olarak olarak kullanılır. Process Mining'de bu nitelik, her talebin uçtan uca süreç döngüsünü yeniden yapılandırmak için büyük önem taşır. Tüm ilgili olayları tek bir Satın Alma Talebi Kimliği altında gruplayarak, analistler döngü sürelerini doğru bir şekilde ölçebilir, durum değişikliklerini izleyebilir ve bir talebin onay sürecinde izleyebileceği farklı yolları analiz edebilirler. Neden Önemli?dir? Bu, tüm ilgili süreç adımlarını bağlayan, talep süreç döngüsünün eksiksiz ve tutarlı bir görünümünü sağlayan temel vaka tanımlayıcısıdır. Nereden Alınır?? Bu nitelik, EBAN tablosunda, BANFN alanında bulunan Satın Alma Talebi Numarasıdır. Örnekler::::::: 100178901001789110017892 | |||
| Bölüm Department | Talebin maliyetlerinin yüklendiği departman veya maliyet merkezi. | ||
| Açıklama Departman niteliği, SAP'de genellikle Maliyet Merkezi ile temsil edilir, istenen satın almadan sorumlu iş birimini tanımlar. Bu, bir talebin kalem seviyesinde atanan kritik bir finansal ve organizasyonel bilgidir. Process Mining'de bu nitelik, departman performansı analizi için büyük önem taşır. Farklı departmanlar arasında döngü süresi, düzeltme oranları ve ret oranları gibi temel metrikleri karşılaştıran kontrol paneli'lar sunar. Bu, uygulamaları başka yerlerde benimsenebilecek yüksek performanslı departmanları ve ek eğitime veya süreç desteğine ihtiyaç duyabilecek departmanları belirlemeye yardımcı olur. Neden Önemli?dir? İş birimleri arasında performans karşılaştırmasını sunar, döngü sürelerindeki veya ret oranlarındaki varyasyonları vurgulayarak en iyi uygulamaları ve iyileştirme alanlarını belirlemeye yardımcı olur. Nereden Alınır?? Bu, genellikle hesap atama tablosu EBKN'de, KOSTL alanında bulunan Maliyet Merkezi'dir. Örnekler::::::: FIN-1001IT-2005MKT-3010 | |||
| Kullanıcı Kimliği UserId | Talebi oluşturan veya belirli bir aktiviteyi gerçekleştiren kullanıcının kimliğidir. | ||
| Açıklama Kullanıcı Kimliği, talebin süreç döngüsündeki belirli bir event'ten sorumlu çalışanı veya sistem kullanıcısını tanımlar. Bu, talebi oluşturan kişi, onu onaylayan yönetici veya düzelten aracı olabilir. Otomatik adımlarda bu, bir sistem veya batch kullanıcı kimliği olabilir. Kullanıcı Kimliği'ne göre analiz yapmak, kullanıcıya özgü davranışları, iş yükü dağılımını ve performansı anlamaya yardımcı olur. Eğitim ihtiyaçlarını belirlemek, yüksek performanslı bireyleri tanımak ve süreç içinde hesap verebilirliği güçlüak için temel rol oynar. Ayrıca kullanıcı ana verileriyle birleştirildiğinde departman performans analizini de destekler. Neden Önemli?dir? Kullanıcı performansı, iş yükü dağıtımı ve süreç Nereden Alınır?? Oluşturan için EBAN-ERNAM'da bulunur. Sonraki değişiklikler için CDHDR-USERNAME'dedir. Onaylar için Örnekler::::::: JSMITHRROEWF-BATCH | |||
| Onaylayıcı Kimliği ApproverId | Onay veya ret adımını gerçekleştiren kullanıcının kimliğidir. | ||
| Açıklama Onaylayan Kimliği, bir onay veya reddetme activity'sini tamamlayan kullanıcıyı özel olarak tanımlar. Bu, onay iş akışını (workflow)ndaki yalnızca karar vericilere odaklandığı için genel Kullanıcı Kimliği'nden farklıdır. Bu bilgiyi yakalamak, onay sürecini ayrıntılı olarak analiz etmek için büyük önem taşır. Bu nitelik, uzun onay sürelerine sahip yöneticileri veya talepleri sıkça reddedenleri belirlemek gibi onay davranışlarının analizine sunar. Onay adımı döngü sürelerine ve workflow darboğaz analiz panellerina odaklanan kontrol paneli'lar için temel olup, gecikmelere neden olabilecek belirli kişileri veya rolleri belirlemeye yardımcı olur. Neden Önemli?dir? Bir onay adımındaki belirli karar vericiyi belirler, birey veya role göre onay döngü sürelerinin ve Nereden Alınır?? Bu bilgi genellikle iş öğelerini tamamlayan kullanıcıya bağlayan SWW_WI2OBJ ve SWWLOGHIST gibi SAP Business Workflow tablolarından çıkarılır. Örnekler::::::: MJOHNSONCWILLIAMSLBLACK | |||
| Talep Durumu RequisitionStatus | Satın alma talebinin mevcut işleme veya onay durumu. | ||
| Açıklama Talep Durumu, talebin süreç döngüsü içindeki mevcut durumunu gösterir. SAP'de bu, genellikle bir talebin bloke edilip edilmediğini, onayda olup olmadığını, kısmen onaylanıp onaylanmadığını veya tamamen onaylanıp onaylanmadığını gösteren Serbest Bırakma Göstergesi ile temsil edilir. Bu durum, talep workflow'da ilerledikçe değişir. Durumu zaman içinde izlemek, süreç akışını anlamak için büyük önem taşır. Taleplerin nerede ve ne kadar süreyle takılı kaldığını belirlemeye yardımcı olur. Durumlar arasındaki geçişleri analiz etmek, onay sürecinin ve varyantlarının ayrıntılı bir görünümünü sunar. Neden Önemli?dir? Bir talebin mevcut durumunu gösterir; bu, ilerlemeyi izlemek, Nereden Alınır?? Serbest bırakma durumu genellikle EBAN tablosunda, FRGZU alanında bulunan Serbest Bırakma Göstergesi ile belirlenir. Örnekler::::::: B1S | |||
| Talep Türü RequisitionType | Satın alma talebini, örneğin standart kalemler, hizmetler veya sermaye harcamaları için sınıflandıran bir kod. | ||
| Açıklama Talep Tipi, SAP'de Belge Tipi olarak da bilinir, satın alma taleplerini kategorize eden önemli bir yapılandırma alanıdır. Farklı tipler farklı onay iş akışlarınını tetikleyebilir, farklı alan ayarlarına sahip olabilir ve standart stok kalemleri, dış hizmetler veya varlık alımları gibi farklı iş amaçları için kullanılabilir. Süreci Talep Tipine göre analiz ederek, kuruluşlar farklı istek türlerinin nasıl ele alındığını anlayabilir. Bu, performans, döngü süreleri ve onay yollarını kategoriler arasında karşılaştırmaya sunar; bu da belirli talep tiplerinin daha verimli olup olmadığını ortaya çıkarabilir ve süreç iyileştirmelerini kişiselleştirmeye yardımcı olabilir. Neden Önemli?dir? Talepleri karşılaştırmalı analize olanak tanıyacak şekilde kategorize eder, farklı talep türlerinin farklı süreç akışlarına, Nereden Alınır?? Bu, EBAN tablosunda, BSART alanında bulunan Belge Tipi alanıdır. Örnekler::::::: NBFORV | |||
| Talep Tutarı RequisitionAmount | Satın alma talebinin toplam parasal değeri. | ||
| Açıklama Satın Alma Talebi Tutarı, istenen mal veya hizmetlerin toplam tahmini maliyetini temsil eder. Bu değer, genellikle onay iş akışını (workflow)nun karmaşıklığını ve uzunluğunu belirlemede önemli bir faktördür; daha yüksek değerli talepler genellikle daha fazla onay seviyesi gerektirir. Bu niteliği analiz etmek, süreci değere göre bölümlere ayırmayı sunar. 'Yüksek değerli taleplerin onaylanması daha mı uzun sürüyor?' veya 'Sıkça reddedilen taleplerin değeri nedir?' gibi sorulara yanıt bulmaya yardımcı olabilir. Süreç verimsizliklerinin finansal etkisini anlamak için önemli bir boyuttur. Neden Önemli?dir? Süreci finansal etkiye göre bölümlere ayırmaya yardımcı olur, genellikle onay karmaşıklığı ve döngü süresiyle ilişkilidir. Değer tabanlı süreç analizi için büyük önem taşır. Nereden Alınır?? Toplam değer EBAN tablosunda, GFWERT alanında bulunabilir. Kalem seviyesi değeri EBAN-PREIS'tedir. Örnekler::::::: 1500.0075000.50250.75 | |||
| `Teslim Edilmesi Gereken Tarih` RequiredByDate | Talep edenin istenen mal veya hizmetlere ihtiyaç duyduğu tarih. | ||
| Açıklama İstenen Teslim Tarihi veya SAP'deki Teslim Tarihi, talep kalemindeki mal veya hizmetlere ne zaman ihtiyaç duyulduğunu belirtir. Bu tarih talep eden tarafından belirlenir ve tüm tedarik süreci için bir hedef görevi görür. Bu nitelik, 'Zamanında Talep Tamamlama Oranı' KPI'ını hesaplamak için büyük önem taşır. İstenen Teslim Tarihi'ni nihai onay veya Satınalma Siparişi oluşturma tarihiyle karşılaştırarak, kuruluş iç hizmet seviyelerini ve iş ihtiyaçlarını karşılama yeteneğini ölçebilir. Bu tarihi kaçıran talepleri analiz etmek, tedarik sürecindeki sistemik gecikmeleri vurgulayabilir. Neden Önemli?dir? Bir talep için hedef tamamlama tarihini tanımlayarak, zamanında teslimatın ve dahili hizmet seviyelerine uyumun ölçülmesine sunar. Nereden Alınır?? Bu, EBAN tablosunda, kalem seviyesinde bulunan Teslim Tarihi'dir, LFDAT alanı. Örnekler::::::: 2023-11-152023-12-012024-01-20 | |||
| Aciliyet Seviyesi UrgencyLevel | Talebin aciliyetinin bir sınıflandırmasıdır; bu, işleme önceliğini etkileyebilir. | ||
| Açıklama Aciliyet Seviyesi, satın alma isteğinin önceliğini gösterir. Standart özel bir alan olmamakla birlikte, bazı kuruluşlar bu bilgiyi yakalamak için Talep Takip Numarası gibi alanları kullanır. Bu, talep edenlerin hızlandırılmış işlem gerektirebilecek kritik ihtiyaçları işaretlemesine sunar. Aciliyetin etkisini analiz etmek, sürecin kritik istekleri etkili bir şekilde önceliklendirip önceliklendirmediğini değerlendirmek için önemlidir. Aciliyet Seviyesi Etki Analizi kontrol paneli'u, bu niteliği kullanarak acil ve standart talepler için döngü sürelerini ve onay oranlarını karşılaştırır ve önceliklendirmenin amaçlandığı gibi çalışıp çalışmadığını belirlemeye yardımcı olur. Neden Önemli?dir? Yüksek öncelikli talepler için süreç performansının nasıl farklılaştığını analiz etmeye sunar, acil kalemlerin gerçekten hızlandırılıp hızlandırılmadığını doğrulamaya yardımcı olur. Nereden Alınır?? Standart bir aciliyet alanı yoktur. Bazı şirketler bu amaçla Talep Takip Numarasını (EBAN-BEDAR) kullanır. Ayrıca özel bir alan da olabilir. Örnekler::::::: YüksekOrtaDüşük | |||
| Bitiş Zamanı EndTime | Belirli bir faaliyetin tamamlandığı tam tarih ve saat. | ||
| Açıklama EndTime, bir faaliyetin ne zaman tamamlandığını kaydeden zaman damgası (zaman damgası)dır. Birçok sistem tarafından oluşturulan olay anlık olsa da (StartTime'ın EndTime'a eşit olması), onaylar gibi insan görevlerinin ayrı bir başlangıcı ve sonu olabilir. Bu zaman damgası (zaman damgası), o işin tamamlandığını işaretler. Ayrı bir EndTime'a sahip olmak, aktif işlem süresini boşta bekleme süresine göre daha doğru ölçmeye sunar. İşlem Süresi (ProcessingTime) metriğini hesaplamak için StartTime ile birlikte kullanılır. Bu ayrıntı seviyesi, manuel görevler için kaynak kullanımının ve verimliliğinin analizini geliştirir. Neden Önemli?dir? Bir faaliyetin tamamlanmasını işaretler, aktif işlem süresinin hesaplanmasına ve görev süresinin daha ayrıntılı bir görünümünü güçlüasına sunar. Nereden Alınır?? Bu, bir iş öğesinin ne zaman oluşturulduğunu (Başlangıç Zamanı) ve ne zaman tamamlandığını (Bitiş Zamanı) yakalayabilen workflow log'larından türetilmiştir. Örnekler::::::: 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Kaynak Sistem SourceSystem | `Veri`lerin çıkarıldığı belirli SAP S/4HANA örneğini tanımlar. | ||
| Açıklama Kaynak Sistem niteliği, süreç verisinin oluşturulduğu kaynak sistemi belirtir. Geliştirme, kalite güvencesi ve üretim için farklı sistemler veya farklı bölgeler için ayrı sistemler gibi birden fazla SAP örneğine sahip kuruluşlarda, bu alan veri yönetimi ve bağlam için büyük önem taşır. Farklı kaynaklardan gelen verilerin ayırt edilmesini sağlayarak yanlış toplulaştırmayı önler ve sisteme özgü analizi sunar. Veri izlenebilirliğinu korumak ve süreç verisinin izlenebilirliğini güçlüak için zorunlu bir niteliktir. Neden Önemli?dir? Özellikle birden fazla sistemin bulunduğu ortamlarda Nereden Alınır?? Bu, genellikle sistem değişkenlerinden veya yapılandırma tablolarından alınabilen SAP Sistem Kimliği (SID)'dir. Örnekler::::::: S4PECCS4H_PROD_01 | |||
| Onay Adımı Adı ApprovalStepName | Workflow'daki bir onay adımının belirli adı veya açıklaması. | ||
| Açıklama Onay Adımı Adı, 'Yönetici Onayı' veya 'Finans Başkan Yardımcısı Onayı' gibi onay iş akışını (workflow)ndaki belirli bir aşamanın insan tarafından okunabilir bir açıklamasını sunar. Bu, genel bir 'Onay Adımı Tamamlandı' activity'sinden daha açıklayıcıdır. Bu nitelik, Onay Adımı Döngü Süresi ve Workflow Darboğaz Analizi panelleri için büyük önem taşır. Onay sürecinin ayrıntılı bir görünümünü sağlayarak, hangi onay aşamalarının en önemli gecikmelere neden olduğunu ve işin nerede biriktiğini tam olarak belirlemeyi sunar. Bu detay seviyesi, onay zincirini verimli hale getirmek için hedefe yönelik müdahaleler için gereklidir. Neden Önemli?dir? Onay aşamaları hakkında ayrıntılı bilgi sağlayarak, çok seviyeli onay Nereden Alınır?? Bu bilgi, workflow log'unun T528T gibi görev tanımı tablolarına bağlanmasıyla bulunabilen workflow görev açıklamasından türetilmiştir. Örnekler::::::: Yönetici OnayıDirektör OnayıFinans Başkan Yardımcısı Onayı | |||
| Otomatikleştirildi mi? IsAutomated | Bir etkinliğin bir sistem kullanıcısı tarafından mı yoksa insan tarafından mı gerçekleştirildiğini gösteren bir bayrak. | ||
| Açıklama Otomatikleştirildi niteliği, bir faaliyetin 'WF-BATCH' gibi bir sistem veya batch kullanıcısı tarafından yürütülüp yürütülmediğini gösteren bir boolean flag'idir. Bu, süreçteki manuel ve otomatik adımları ayırt etmeye yardımcı olur. Bu nitelik, talep sürecindeki otomasyon seviyesini ölçmek ve 'Otomatik Onay Oranı' KPI'ını hesaplamak için büyük önem taşır. Otomatik veya manuel adımları filtreleyerek analistler verimliliklerini karşılaştırabilir ve işlem sürelerini ve manuel çabayı azaltmak için daha fazla otomasyon fırsatları belirleyebilirler. Neden Önemli?dir? İnsan ve sistem tarafından yürütülen faaliyetler arasında ayrım yapar; bu, otomasyon oranlarını ölçmek ve manuel görevleri otomatikleştirmek için temel rol oynar. Nereden Alınır?? Bu, genellikle bir event için Kullanıcı Kimliğinin bilinen sistem veya batch kullanıcıları listesine ait olup olmadığını kontrol eden bir kurala dayanan türetilmiş bir niteliktir. Örnekler::::::: truefalse | |||
| Para Birimi Currency | Talep tutarı için para birimi kodu. | ||
| Açıklama Bu nitelik, talep tutarının ifade edildiği para birimini (örneğin USD, EUR veya JPY) belirtir. Özellikle birden fazla para birimiyle çalışan çok uluslu kuruluşlarda, Talep Tutarı niteliği için gerekli bağlamı sunar. Doğru finansal analiz ve raporlama için para birimini dikkate almak büyük önem taşır. Talep değerlerini 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ülmelidir. Bu nitelik, bu tür dönüşümler için bir ön koşuldur. Neden Önemli?dir? Talep Tutarı için temel bağlam sunar, çoklu para birimi ortamlarında doğru finansal analiz ve karşılaştırmalara sunar. Nereden Alınır?? Bu, EBAN tablosunda, WAERS alanında bulunur. Örnekler::::::: USDEURGBP | |||
| Purchase Order Number PurchaseOrderNumber | Talepten oluşturulan satın alma siparişinin numarası. | ||
| Açıklama Satın Alma Sipariş Numarası, onaylanmış bir talepten oluşturulan resmi satın alma belgesinin tanımlayıcısıdır. Bir satın alma siparişinin oluşturulması genellikle bir talep için nihai, başarılı bir sonuçtur ve isteğin bir tedarikçi ile resmi bir siparişe dönüştürüldüğünü gösterir. Bu nitelik, Talepten Satınalma Siparişi Teslim Süresi KPI'ını ve genel dönüşüm oranını ölçmek için büyük önem taşır. Talep sürecini aşağı akış tedarik süreciyle ilişkilendirerek, tüm Satın Alma'dan Ödemeye döngüsünün daha geniş, uçtan uca görmenizi sunar. Neden Önemli?dir? Talebi sonraki tedarik belgesine bağlar, talepten Satınalma Siparişine dönüşüm oranının ve teslim süresinin ölçülmesini sunar. Nereden Alınır?? Bir Satınalma Siparişi (PO) talep kaleminden oluşturulduktan sonra EBAN tablosunda, EBELN alanında bulunur. Örnekler::::::: 450001789045000178914500017892 | |||
| Ret Nedeni RejectionReason | Bir satın alma talebi reddedildiğinde belirtilen neden. | ||
| Açıklama Ret Nedeni, bir onaylayıcının neden bir satın alma talebini reddettiğini açıklar. Nedenler arasında bütçe aşımı, yanlış bilgi, politikaya uyumsuzluk veya başka bir talebin tekrarlanması yer alabilir. Bu bilgi, süreç hatalarını anlamak için önemli bir bağlam sunar. Ret nedenlerini analiz etmek, süreç verimsizliklerinin ve yeniden işleme ihtiyacının temel nedenlerini belirlemeye yardımcı olur. Örneğin, 'Yanlış Maliyet Merkezi' yaygın bir neden ise, bu durum daha iyi kullanıcı eğitimi veya sistem doğrulaması ihtiyacına işaret eder. Bu nitelik, Talep Ret Analizi kontrol paneli'unun anahtarıdır ve hedefe yönelik süreç iyileştirmesi için büyük önem taşır. Neden Önemli?dir? Süreç hatalarının temel nedenini sunar, yeniden işlemeyi azaltmak ve taleplerin ilk seferde doğru oranını artırmak için hedeflenmiş iyileştirmelere sunar. Nereden Alınır?? Bu genellikle standart bir alan değildir. Workflow container öğelerinde, taleple ilişkili uzun metinde veya özel alanlarda yakalanabilir. Örnekler::::::: Bütçeyi aşıyorYanlış tedarikçiYinelenen talep | |||
| Son Veri Güncellemesi LastDataUpdate | Bu kayda ait verilerin kaynak sistemden en son ne zaman güncellendiğini gösteren zaman damgası (zaman damgası)dır. | ||
| Açıklama Bu nitelik, kaynak sistemden yapılan en son veri çıkarma veya güncelleme tarih ve saatini kaydeder. Analiz edilen verinin güncelliğini anlamak için kritik bir meta veri parçasıdır. Analistler ve iş kullanıcıları, süreç verisinin operasyonların en güncel durumunu yansıtıp yansıtmadığını bilmek için bu zaman damgası (zaman damgası)'e güvenirler. Herhangi bir süreç analizinde, verinin güncelliğini bilmek bilinçli kararlar almak için büyük önem taşır. Bu nitelik, kullanıcı beklentilerini yönetmeye yardımcı olur ve sonuçların belirli analiz için gerektiği kadar güncel verilerden elde edilmesini sunar. Neden Önemli?dir? Verilerin güncelliğini gösterir; bu, analize güvenmek ve zamanında iş kararları almak için büyük önem taşır. Nereden Alınır?? Bu zaman damgası (zaman damgası), veri çıkarma, dönüştürme ve yükleme ( Örnekler::::::: 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Yeniden İşleme mi? IsRework | Bir etkinliğin, gönderildikten sonraki bir düzeltme gibi, yeniden işleme (rework) teşkil edip etmediğini gösteren bir bayrak. | ||
| Açıklama
Bu nitelik, süreçteki yeniden işleme miktarını ve bunun genel döngü süreleri üzerindeki etkisini ölçmek için büyük önem taşır. Talep Düzeltme ve Yeniden İşleme Oranı Neden Önemli?dir? Boşa harcanan çaba veya tekrarı temsil eden faaliyetleri işaretler, yeniden işleme miktarının ve bunun süreç verimliliği üzerindeki etkisinin doğrudan ölçülmesini sunar. Nereden Alınır?? Bu hesaplanmış bir niteliktir. Mantık, ilk 'Onay İçin Gönderilen Talep' activity'sinden sonra gerçekleşen herhangi bir 'Değiştirilen Talep' activity'sini yeniden işleme olarak işaretleyecektir. Örnekler::::::: truefalse | |||
Satın Almadan Ödemeye - Talep Faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Onay Adımı Tamamlandı | Bir onaylayıcının bir talep üzerinde olumlu bir işlem yapması, çok seviyeli onay `iş akışı`ndaki bir adımı tamamlamasıyla meydana gelir. Bu, talebin serbest bırakma durumundaki bir değişiklikten çıkarılır. | ||
| Neden Önemli?dir? Bu activity, onay iş akışını (workflow)nun ayrıntılı analizine sunar ve her bir adımda harcanan süreyi ölçer. Süreçteki verimli onaylayıcıları darboğazlardan ayırmaya yardımcı olur. Nereden Alınır?? EBAN tablosu için değişiklik belgelerinden (CDHDR/CDPOS) çıkarılır. Belirli bir kod için serbest bırakma kodu durumundaki (örn. FRGZU alanında) serbest bırakılmamış durumdan serbest bırakılmış duruma bir değişiklik bu Yakala EBAN'daki serbest bırakma durumu alanlarındaki değişiklikleri, stratejide tanımlanan her serbest bırakma kodu için izleyin. Event tipi inferred | |||
| Satınalma Siparişi Oluşturuldu | Talep kalemine atıfta bulunarak bir satın alma siparişinin oluşturulduğunu gösterir. Bu, talebi sonraki bir tedarik belgesine bağlayan açık bir sistem `event`'idir. | ||
| Neden Önemli?dir? Bu, talep süreci için önemli bir kilometre taşı ve başarılı bir sonuçtur. Talep onayı ile Satınalma Siparişi oluşturma arasındaki süre, tedarik verimliliğini ölçmek için kritik 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ınalma Siparişi Kalemi) saklanır. Yakala EKPO tablosunu talep numarası ve kalemi üzerinden EBAN'a geri birleştirin. Satınalma Siparişi (PO) kaleminin oluşturulma tarihi Event tipi explicit | |||
| Talep Kapatıldı | Talep kaleminin tamamen işlenmiş olduğunu ve ondan başka satın alma siparişinin oluşturulamayacağını gösterir. Bu durum genellikle tam miktar sipariş edildiğinde otomatik olarak ayarlanır. | ||
| Neden Önemli?dir? Bu activity, talep kaleminin süreç döngüsünün nihai, başarılı tamamlanmasını temsil eder. İş ihtiyacının tamamen bir tedarik siparişine dönüştürüldüğünü doğrular. Nereden Alınır?? EBAN tablosundan çıkarılır. Bu, 'Kapalı' göstergesi (EBAKZ) ayarlandığında meydana gelir, bu da genellikle Satın Alma Siparişlerindeki (PO) sipariş edilen miktarın talep miktarına eşit olmasıyla olur. Yakala EBAN tablosunda 'Kapalı' göstergesinin (EBAKZ) değişiklik belgeleri aracılığıyla ayarlandığı Event tipi inferred | |||
| Talep Oluşturuldu | Sistemde satın alma talebi belgesinin ilk oluşturulmasını işaretler. Bu `event`, bir kullanıcı yeni bir talebi ilk kez kaydettiğinde, oluşturma zaman damgası (zaman damgası)ini kaydederek açıkça yakalanır. | ||
| Neden Önemli?dir? Bu activity, talep süreç döngüsü analizinin birincil başlangıç noktası olarak olarak kullanılır. İlk ihtiyaç belirlemeden nihai onaya veya satın alma siparişine dönüştürmeye kadar uçtan uca döngü süresini ölçmek için büyük önem taşır. Nereden Alınır?? Bu, EBAN tablosundan, belirli satın alma talebi numarası (BANFN) için oluşturma tarihi (ERDAT) ve oluşturma saati (ERZEIT) alanları kullanılarak yakalanan açık bir event'tir. Yakala Her talep (BANFN) için EBAN tablosundan oluşturma zaman damgası (zaman damgası) alanlarını (ERDAT, ERZEIT) kullanın. Event tipi explicit | |||
| Talep Onaylandı | Satın alma talebinin nihai ve tam onayını işaretler, onu bir satın alma siparişine dönüştürmeye uygun hale getirir. Bu dönüm noktası, genel serbest bırakma durumu nihai onaylanmış durumuna ulaştığında çıkarılır. | ||
| Neden Önemli?dir? Bu, kritik bir başarı kilometre taşı ve döngü süresi analizi için yaygın bir bitiş noktasıdır. Talebin tüm kontrolleri geçtiğini ve tedarik departmanının harekete geçmeye hazır olduğunu gösterir. Nereden Alınır?? EBAN tablosundaki bir durum değişikliğinden, özellikle genel serbest bırakma göstergesinin (FRGZU) veya işleme durumunun (PROCSTAT) nihai 'Onaylandı' değerine güncellenmesinden çıkarılır. Yakala Nihai serbest bırakma kodunun uygulandığı veya genel talep durumunun 'Onaylandı' olarak değiştiği zaman damgası (zaman damgası)'i belirleyin. Event tipi inferred | |||
| Talep Reddedildi | Bir onaylayıcı tarafından satın alma talebinin nihai reddini temsil eder, süreci durdurur. Bu, reddi gösteren belirli bir durum güncellemesiyle yakalanır. | ||
| Neden Önemli?dir? Bu activity, kritik bir hata bitiş noktasıdır. Ret sıklığını, nedenlerini ve süreçteki noktalarını analiz etmek, politika uyumluluğu, bütçe veya talep kalitesiyle ilgili sorunları belirlemeye yardımcı olur. Nereden Alınır?? EBAN tablosundaki bir durum değişikliğinden çıkarılır. İşleme durumu (PROCSTAT) veya bir serbest bırakma göstergesi, açıkça 'Reddedildi' anlamına gelen bir değere ayarlanır. Yakala EBAN'daki genel durumun değişiklik belgeleri aracılığıyla 'Reddedildi' durumuna güncellendiği zaman damgası (zaman damgası)'i belirleyin. Event tipi inferred | |||
| Onay Adımı Başlatıldı | Bir talebin belirli bir onaylayıcıdan veya onay grubundan işlem beklediğini gösterir. Bu, talebin durumunun belirli bir serbest bırakma kodunu beklediğini gösterdiğinde çıkarılır. | ||
| Neden Önemli?dir? Bu activity, onay zincirindeki darboğazları belirlemek için büyük önem taşır. Bu durumun süresini analiz etmek, takılı kalmış talepleri ve aşırı yüklenmiş onaylayıcıları belirlemeye yardımcı olur. Nereden Alınır?? EBAN tablosunun serbest bırakma durum alanlarından (örn. FRGZU) ve temel serbest bırakma stratejisi yapılandırmasından çıkarılır. Yakala Bir talebin, Event tipi inferred | |||
| Onay Sıfırlandı | Talebe yapılan önemli bir düzeltme nedeniyle tüm onay `iş akışı`nın sıfırlandığı bir `event`i temsil eder. Bu, onay sürecinin ilk seviyeden yeniden başlamasına neden olur. | ||
| Neden Önemli?dir? Bu activity, döngü süresini ciddi şekilde etkileyen önemli yeniden işleme ihtiyacını vurgular. Onay sıfırlamalarının nedenlerini belirlemek, süreci optimize etmek ve gecikmeleri azaltmak için temel rol oynar. Nereden Alınır?? EBAN tablosundaki değişiklik belgelerinden (CDHDR/CDPOS) çıkarılır. Bu Yakala Değişiklik günlüklerinde serbest bırakma durumunda serbest bırakılmış bir durumdan tekrar serbest bırakılmamış bir duruma bir değişiklik arayın. Event tipi inferred | |||
| Satın Alma Talebi Onay İçin Gönderildi | Talep sahibinin talebi resmi olarak gönderdiği anı temsil eder ve onay `iş akışı`nı tetikler. Bu, genellikle talebin serbest bırakma stratejisi belirlendiğinde ve durum 'Onay Sürecinde' olarak değiştiğinde çıkarılır. | ||
| Neden Önemli?dir? Bu, onay döngü süresi KPI'ları için saati başlatan kritik bir kilometre taşıdır. Oluşturma ve gönderme arasındaki süreyi analiz etmek, talep hazırlık aşamasındaki gecikmeleri ortaya çıkarabilir. Nereden Alınır?? EBAN tablosu için değişiklik belgelerinden (CDHDR/CDPOS), özellikle serbest bırakma stratejisi alanları (örn. FRGST) doldurulduğunda veya genel durum (PROCSTAT) bir onay sürecinde olduğunu yansıtacak şekilde değiştiğinde çıkarılır. Yakala Onay Event tipi inferred | |||
| Talep Değiştirildi | Bir kullanıcı, talebin ilk oluşturulmasından sonra miktar, fiyat veya malzeme gibi temel bir alanı değiştirdiğinde meydana gelir. Bu eylem, SAP'nin değişiklik belgesi sistemine açıkça kaydedilir. | ||
| Neden Önemli?dir? Düzeltmeleri izlemek, yeniden işleme döngülerini ve bunların döngü süreleri üzerindeki etkilerini belirlemek için büyük önem taşır. Yüksek düzeltme sıklığı, veri kalitesi veya değişen gereksinimlerle ilgili sorunlara işaret eder ki bunlar süreç iyileştirmesi için temel 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. Takip edilen bir alandaki her değişiklik bir giriş oluşturur. Yakala Nesne sınıfı satın alma talepleri için BANF olan CDHDR/CDPOS'tan değişiklik Event tipi explicit | |||
| Talep Geri Çekildi | Orijinal talep sahibinin talebi tam olarak işlenmeden önce iptal etmesi veya silmesiyle meydana gelir. Bu genellikle, talep kaleminde bir silme işareti ayarlayan açık bir eylemdir. | ||
| Neden Önemli?dir? Geri çekmeleri izlemek, talep oynaklığını ve iptal nedenlerini anlamaya yardımcı olur. Bu, talep için nihai bir durumu temsil eder ve daha fazla işlemenin önüne geçer. 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'a kaydedilir. Yakala EBAN tablosundaki silme göstergesinin (LOEKZ) 'L' olarak ayarlandığı Event tipi explicit | |||
| Tedarik Kaynağı Atandı | Bir alıcının onaylanmış bir talep kalemine belirli bir tedarikçi, sözleşme veya bilgi kaydı atama eylemini temsil eder. Bu, talebi satın alma siparişi oluşturmaya hazırlamada önemli bir adımdır. | ||
| Neden Önemli?dir? Bu activity, onay ile sipariş arasındaki boşluğu kapatır. Bir kaynak atama süresini ölçmek, alıcının iş yükündeki ve kaynak bulma verimliliğindeki gecikmeleri 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 bir değer girilmesinden çıkarılır. Yakala EBAN tablosundaki LIFNR, INFNR veya KONNR gibi alanların değişim dokümanları aracılığıyla doldurulmasını izleyin. Event tipi inferred | |||
Veri Çıkarma Kılavuzları
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. Bu genellikle S_TABU_NAM gibi nesneler için izinleri ve veri görüntüleme araçlarına erişimi içerir.
- Sistem Erişim Yöntemini Belirleyin: SQL sorgularını yürütmek için 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) ile Eclipse IDE veya SAP HANA veritabanı istemcisi aracılığıyla bağlanabilen DBeaver gibi üçüncü taraf SQL istemcileri bulunur.
- SQL Sorgusunu İnceleyin: Sağlanan SQL betiğine aşina olun. Farklı faaliyetler için
veritoplamak üzere Ortak Tablo İfadeleri (CTE'ler) kullanır ve birleşik bir event log oluşturmak için bunları birleştirir. - Yer Tutucuları Özelleştirin: Sorgudaki yer tutucuları bulun ve değiştirin. Veri çıkarma dönemi için tarih aralığını (
[YYYY-MM-DD]formatında) ayarlamanız ve kuruluşunuz için ilgili şirket kodlarını ([Your Company Code]) belirtmeniz gerekecektir. - Sorguyu Yürütün: Tam, özelleştirilmiş SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Veri hacmine ve seçilen tarih aralığına bağlı olarak, bu sorgunun yürütülmesi biraz zaman alabilir.
- İlk Veri İncelemesi: Sorgu tamamlandığında, çıktının ilk birkaç satırını inceleyin. PurchaseRequisitionId, (ActivityName) ve (EventTime) gibi tüm sütunların beklendiği gibi doldurulduğunu ve veri formatlarının doğru olduğunu kontrol edin.
- Veri Dönüşümünü Ele Alın: Sağlanan sorgu,
process miningiçin hazır bir formattaveriçıkarmak üzere tasarlanmıştır.CASTveCONCATfonksiyonları,veritürlerinin tutarlı olmasını güçlüak için kullanılır. Büyük bir yürütme sonrası dönüşüm gerekli olmamalıdır. - Olay Günlüğünü Dışa Aktarın: SQL istemcinizden tüm sonuç kümesini bir CSV dosyasına dışa aktarın. Karakter sorunlarını önlemek için dosya kodlamasının UTF-8 olarak ayarlandığından emin olun.
- Yüklemeye Hazırlanın: Bir
process miningaracına yüklemeden önce, CSV dosyasının doğru başlıklara (PurchaseRequisitionId,(ActivityName),(EventTime)vb.) sahip olduğunu ve(EventTime)için tarih ve saat formatının hedef platform tarafından tutarlı ve desteklendiğini doğrulayın. - ProcessMind'e Yükleyin: Nihai CSV dosyasını ProcessMind projenize yükleyin.
PurchaseRequisitionId'ı Vaka Kimliği,(ActivityName)'i Aktivite ve(EventTime)'ı Zaman Damgası olarak eşleştirerek projeyi yapılandırın.
Konfigürasyon
- Temel CDS Görünümleri: Veri çıkarma işlemi, ana talep verileri için öncelikli olarak
I_PurchaseRequisitionAPI01'i, değişiklikleri ve durum güncellemelerini takip etmek içinI_ChangeDocumentveI_ChangeDocumentItem'ı ve satın alma siparişlerine bağlantı içinI_PurchaseOrderItemAPI01'i kullanır. - Yetkilendirme: Sorguyu çalıştıran kullanıcının yukarıda bahsedilen CDS görünümlerine okuma erişimi olması gerekir. Gerekli roller ve yetkilendirmeler için SAP güvenlik ekibinizle iletişime geçin.
- Tarih Aralığı Filtrelemesi: Veri hacmini sınırlamak için talep oluşturma tarihi (
CreationDate) üzerinde bir tarih aralığı filtresi uygulamak büyük önem taşır. İlk analiz için 3 ila 6 aylık bir veri aralığı önerilir. - Organizasyonel Filtreleme: Doğru iş birimi için süreci analiz ettiğinizden emin olmak için verileri
CompanyCode'a göre filtreleyin. Ayrıca, belirli tedarik süreçlerine (örneğin, standart mallar veya hizmetler) odaklanmak içinPurchaseRequisitionType'a göre filtreleme yapmayı da düşünebilirsiniz. - Değişiklik Belgesi Yapılandırması: 'Talep Düzeltildi' gibi faaliyetlerin ve çeşitli onay adımlarının yakalanması, SAP sisteminizdeki ilgili alanlar için değişiklik belgesi kaydının etkin olmasına bağlıdır. Bu olaylar eksikse, EBAN tablosu için sistem yapılandırmasını kontrol edin.
- Performans: Milyonlarca talebi olan çok büyük sistemler için, bu sorguyu uzun bir süre boyunca çalıştırmak sistem performansını etkileyebilir. Sorguyu yoğun olmayan saatlerde veya yakın zamanda yenilenmiş verilere sahip bir üretim dışı ortamda çalıştırmayı düşünün.
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
- Ö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. Bu genellikle S_TABU_NAM gibi nesneler için izinleri ve veri görüntüleme araçlarına erişimi içerir.
- Sistem Erişim Yöntemini Belirleyin: SQL sorgularını yürütmek için 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) ile Eclipse IDE veya SAP HANA veritabanı istemcisi aracılığıyla bağlanabilen DBeaver gibi üçüncü taraf SQL istemcileri bulunur.
- SQL Sorgusunu İnceleyin: Sağlanan SQL betiğine aşina olun. Farklı faaliyetler için
veritoplamak üzere Ortak Tablo İfadeleri (CTE'ler) kullanır ve birleşik bir event log oluşturmak için bunları birleştirir. - Yer Tutucuları Özelleştirin: Sorgudaki yer tutucuları bulun ve değiştirin. Veri çıkarma dönemi için tarih aralığını (
[YYYY-MM-DD]formatında) ayarlamanız ve kuruluşunuz için ilgili şirket kodlarını ([Your Company Code]) belirtmeniz gerekecektir. - Sorguyu Yürütün: Tam, özelleştirilmiş SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Veri hacmine ve seçilen tarih aralığına bağlı olarak, bu sorgunun yürütülmesi biraz zaman alabilir.
- İlk Veri İncelemesi: Sorgu tamamlandığında, çıktının ilk birkaç satırını inceleyin. PurchaseRequisitionId, (ActivityName) ve (EventTime) gibi tüm sütunların beklendiği gibi doldurulduğunu ve veri formatlarının doğru olduğunu kontrol edin.
- Veri Dönüşümünü Ele Alın: Sağlanan sorgu,
process miningiçin hazır bir formattaveriçıkarmak üzere tasarlanmıştır.CASTveCONCATfonksiyonları,veritürlerinin tutarlı olmasını güçlüak için kullanılır. Büyük bir yürütme sonrası dönüşüm gerekli olmamalıdır. - Olay Günlüğünü Dışa Aktarın: SQL istemcinizden tüm sonuç kümesini bir CSV dosyasına dışa aktarın. Karakter sorunlarını önlemek için dosya kodlamasının UTF-8 olarak ayarlandığından emin olun.
- Yüklemeye Hazırlanın: Bir
process miningaracına yüklemeden önce, CSV dosyasının doğru başlıklara (PurchaseRequisitionId,(ActivityName),(EventTime)vb.) sahip olduğunu ve(EventTime)için tarih ve saat formatının hedef platform tarafından tutarlı ve desteklendiğini doğrulayın. - ProcessMind'e Yükleyin: Nihai CSV dosyasını ProcessMind projenize yükleyin.
PurchaseRequisitionId'ı Vaka Kimliği,(ActivityName)'i Aktivite ve(EventTime)'ı Zaman Damgası olarak eşleştirerek projeyi yapılandırın.
Konfigürasyon
- Temel CDS Görünümleri: Veri çıkarma işlemi, ana talep verileri için öncelikli olarak
I_PurchaseRequisitionAPI01'i, değişiklikleri ve durum güncellemelerini takip etmek içinI_ChangeDocumentveI_ChangeDocumentItem'ı ve satın alma siparişlerine bağlantı içinI_PurchaseOrderItemAPI01'i kullanır. - Yetkilendirme: Sorguyu çalıştıran kullanıcının yukarıda bahsedilen CDS görünümlerine okuma erişimi olması gerekir. Gerekli roller ve yetkilendirmeler için SAP güvenlik ekibinizle iletişime geçin.
- Tarih Aralığı Filtrelemesi: Veri hacmini sınırlamak için talep oluşturma tarihi (
CreationDate) üzerinde bir tarih aralığı filtresi uygulamak büyük önem taşır. İlk analiz için 3 ila 6 aylık bir veri aralığı önerilir. - Organizasyonel Filtreleme: Doğru iş birimi için süreci analiz ettiğinizden emin olmak için verileri
CompanyCode'a göre filtreleyin. Ayrıca, belirli tedarik süreçlerine (örneğin, standart mallar veya hizmetler) odaklanmak içinPurchaseRequisitionType'a göre filtreleme yapmayı da düşünebilirsiniz. - Değişiklik Belgesi Yapılandırması: 'Talep Düzeltildi' gibi faaliyetlerin ve çeşitli onay adımlarının yakalanması, SAP sisteminizdeki ilgili alanlar için değişiklik belgesi kaydının etkin olmasına bağlıdır. Bu olaylar eksikse, EBAN tablosu için sistem yapılandırmasını kontrol edin.
- Performans: Milyonlarca talebi olan çok büyük sistemler için, bu sorguyu uzun bir süre boyunca çalıştırmak sistem performansını etkileyebilir. Sorguyu yoğun olmayan saatlerde veya yakın zamanda yenilenmiş verilere sahip bir üretim dışı ortamda çalıştırmayı düşünün.
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'