Record to Report - Yevmiye Kaydı Veri Template'iniz
Record to Report - Yevmiye Kaydı Veri Template'iniz
- Toplanması Önerilen Nitelikler
- Takip Edilmesi Gereken Temel Aktiviteler
- Pratik veri çekme rehberliği
Record to Report - Yevmiye Kaydı Öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Aktivite ActivityName | Yevmiye kaydı sürecinde belirli bir noktada gerçekleşen iş aktivitesinin adı. | ||
| Açıklama Aktivite, bir yevmiye kaydının yaşam döngüsündeki 'Yevmiye Kaydı Oluşturuldu', 'İnceleme İçin Yevmiye Gönderildi' veya 'Yevmiye Kaydı Deftere Nakledildi' gibi belirli bir adımı veya event'i temsil eder. Bu aktiviteler genellikle sistemde kaydedilen değişiklik loglarından, durum güncellemelerinden veya işlem kodlarından türetilir. Aktivitelerin analizi, süreç akışının görselleştirilmesine, yaygın yolların belirlenmesine ve standart prosedürden sapmaların keşfedilmesine olanak tanır. Aktivite sıklığı, adımlar arasındaki bekleme süreleri ve uyumluluk oranları gibi metrikleri hesaplamak için temeldir. Neden önemli Süreçteki adımları tanımlar, bu da süreç haritalarının görselleştirilmesini ve iş akışı kalıplarının analiz edilmesini sağlar. Nereden alınır Başlık/kalem tablolarındaki durum alanları (örn. BKPF-BSTAT), değişiklik belgesi günlükleri (CDHDR/CDPOS) ve iş akışı günlükleri dahil olmak üzere çeşitli kaynaklardan türetilmiştir. Örnekler Yevmiye Kaydı OluşturulduYevmiye Kaydı Park Edildiİnceleme İçin Yevmiye GönderildiYevmiye Kaydı OnaylandıYevmiye Kaydı Deftere Nakledildi | |||
| Olay Zamanı EventTime | Yevmiye kaydı için belirli bir aktivitenin ne zaman gerçekleştiğini gösteren timestamp. | ||
| Açıklama Olay Zamanı, bir iş faaliyetinin sistemde yürütüldüğü ve kaydedildiği kesin tarih ve saattir. Bir vakadaki her faaliyetin kendi zaman damgası vardır, bu da kronolojik bir olay dizisi oluşturur. Bu öznitelik, tüm zaman tabanlı süreç analizleri için kritik öneme sahiptir. Döngü sürelerini, faaliyetler arasındaki süreleri, bekleme sürelerini hesaplamak ve işin zamansal dağılımını anlamak için kullanılır. Doğru zaman damgaları, güvenilir bir süreç modeli oluşturmak ve Onay Döngüsü Süresi gibi temel performans göstergelerini hesaplamak için elzemdir. Neden önemli Olayların kronolojik sırasını sağlar, bu da tüm süreye dayalı metrikleri hesaplamak ve süreç zaman çizelgesini anlamak için elzemdir. Nereden alınır Değişiklik belge kayıtlarından (CDHDR-UDATE, CDHDR-UTIME), workflow kayıtlarından veya BKPF gibi tablolardaki oluşturma/giriş timestamp'lerinden (CPUDT, CPUTM) alınır. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Yevmiye Kaydı Kimliği JournalEntryId | Süreç için birincil case tanımlayıcısı olarak hizmet veren finansal yevmiye kaydı için benzersiz tanımlayıcı. | ||
| Açıklama Yevmiye Kaydı Kimliği, SAP S/4HANA'da oluşturulan her muhasebe belgesine atanan benzersiz bir numaradır. Bu tanımlayıcı, bir yevmiye kaydının başlangıçtaki oluşturulmasından veya park edilmesinden, onay workflow'ları aracılığıyla, nihai deftere nakline ve potansiyel iptaline veya mutabık kılınmasına kadar tüm yaşam döngüsünü izlemek için çok önemlidir. Process Mining analizinde, bu ID tüm ilgili aktiviteleri tek bir case'e bağlamak için kullanılır. Event'leri ortak bir Yevmiye Kaydı Kimliği altında gruplayarak, analistler uçtan uca süreç akışını yeniden yapılandırabilir, döngü sürelerini ölçebilir ve her belirli finansal işlem için varyasyonları veya darboğazları belirleyebilir. Tüm süreç görünümünü oluşturmak için temel özniteliktir. Neden önemli Bu tanımlayıcı, tüm ilgili süreç adımlarını birbirine bağlayarak her yevmiye kaydının uçtan uca yolculuğunu analiz etmeyi mümkün kılar. Nereden alınır Bu, genellikle Şirket Kodu (BKPF-BUKRS), Belge Numarası (BKPF-BELNR) ve Mali Yıl (BKPF-GJAHR) birleştirilerek oluşturulan bileşik bir anahtardır. Örnekler 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Kayıt Tarihi PostingDate | Yevmiye kaydının Genel Deftere kaydedildiği ve finansal dönemi etkilediği tarih. | ||
| Açıklama Deftere Nakil Tarihi, işlemin finansal tablolarda görüneceği mali dönemi belirler. Muhasebe için kritik bir tarihtir ve belgenin oluşturulduğu veya sisteme girildiği tarihten farklılık gösterebilir. Process Mining'de, deftere nakil tarihi, ay sonu kapanış süreçlerini karşılaştırma veya farklı finansal dönemlerdeki performans trendlerini analiz etme gibi zamana dayalı kohort analizi için kullanılır. Aynı zamanda kayıt oluşturma ile gerçek finansal deftere nakil arasındaki gecikmeleri ölçmek için de kullanılır. Neden önemli Finansal bağlam için kritik öneme sahip olup, ay sonu veya yıl sonu gibi belirli muhasebe dönemleri içinde süreç performansını analiz etmeye olanak tanır. Nereden alınır SAP S/4HANA BKPF tablosu, BUDAT alanı (Belgedeki Deftere Nakil Tarihi). Örnekler 2023-10-312023-11-012024-02-29 | |||
| Kullanıcı Tarafından Oluşturuldu CreatedByUser | Yevmiye kaydını oluşturan kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, ilk belgeyi oluşturarak yevmiye kaydı sürecini başlatan kullanıcının benzersiz tanımlayıcısını saklar. Bu bir muhasebeci, bir iş kullanıcısı veya otomatik kayıtlar için bir sistem ID'si olabilir. Süreci oluşturana göre analiz etmek, belirli kullanıcılar veya ekiplerle ilgili kalıpları belirlemeye yardımcı olur. Belirli kullanıcıların daha yüksek reddetme oranlarına sahip olması durumunda eğitim ihtiyaçlarını ortaya çıkarabilir veya yüksek performans gösteren bireyleri vurgulayabilir. 'Kullanıcı Aktivitesi ve Verimlilik' dashboard'u için vazgeçilmezdir. Neden önemli Süreç faaliyetlerini belirli kullanıcılara atayarak performans analizi, iş yükü dengeleme ve eğitim fırsatlarının belirlenmesini sağlar. Nereden alınır SAP S/4HANA BKPF tablosu, USNAM alanı (Kullanıcı Adı). Örnekler ABROWNCJONESBATCH_USER | |||
| Şirket Kodu CompanyCode | Yevmiye kaydının deftere nakledildiği şirket veya tüzel kişilik için benzersiz tanımlayıcı. | ||
| Açıklama Şirket Kodu, SAP Finans'ta finansal tabloların oluşturulduğu bağımsız bir tüzel kişiliği temsil eden temel bir organizasyon birimidir. Her yevmiye kaydı belirli bir şirket koduna atanır. Bu öznitelik, organizasyonun farklı bölümleri arasında süreç performansını segmentlere ayırmak ve karşılaştırmak için kritik öneme sahiptir. Analistler, belirli bir tüzel kişilik için süreç görünümünü filtrelemek, şirket kodları arasındaki reddetme oranlarını karşılaştırmak veya bölgeye özgü süreç varyasyonlarını belirlemek için bunu kullanabilirler. Neden önemli Kuruluş içindeki farklı tüzel kişilikler veya iş birimleri arasında yevmiye kaydı sürecini filtrelemeye ve karşılaştırmaya olanak tanır. Nereden alınır SAP S/4HANA BKPF tablosu, BUKRS alanı (Şirket Kodu). Örnekler 10001710US01 | |||
| Yerel Para Birimiyle Tutar AmountInLocalCurrency | Yevmiye kaydının şirket kodunun yerel para biriminde ifade edilen toplam değeri. | ||
| Açıklama Bu öznitelik, yevmiye kaydının finansal büyüklüğünü temsil eder. Genellikle belgedeki tüm borç veya alacak kalemlerinin mutlak değerlerinin toplamıdır ve şirket kodunun yerel para birimine dönüştürülür. Tutara göre analiz, sürecin finansal etkiye dayalı olarak segmentlere ayrılmasına olanak tanır. Örneğin, yüksek değerli kayıtlar, düşük değerli olanlara göre daha sıkı bir onay sürecinden geçebilir. En yüksek finansal riski oluşturan işlemlerde süreç iyileştirme çabalarını önceliklendirmeye yardımcı olur. Neden önemli Kaydın finansal değerini sağlar, risk altındaki parasal değerle süreç davranışının nasıl değiştiğini analiz etmeyi mümkün kılar. Nereden alınır Belirli bir yevmiye kaydı (BELNR) için satır öğesi tablosu BSEG'den (alan DMBTR) tutarların toplanması ve pozitif bir değere dönüştürülmesiyle hesaplanır. Örnekler 1500.75125000.0050.20 | |||
| Yevmiye Kaydı Türü JournalEntryType | Yevmiye kaydını, bir varlık kaydı, satıcı faturası veya genel muhasebe kaydı gibi iş amacına göre sınıflandırır. | ||
| Açıklama Yevmiye Kaydı Türü veya SAP terminolojisindeki Belge Türü, muhasebe belgelerini kategorize eden bir anahtardır. Belgeye atanan numara aralığı ve hangi hesap türlerinin deftere nakil için izinli olduğu gibi hususları kontrol eder. Süreci yevmiye kaydı türüne göre analiz etmek, bağlama özgü davranışları anlamak için çok önemlidir. Örneğin, basit bir tahakkuk (SA tipi) için onay süreci, karmaşık bir varlık edinimi (AA tipi) için olandan çok daha basit olabilir. Bu boyut, 'Kayda Göre Uyumluluk' dashboard'u için anahtardır. Neden önemli Girişleri iş bağlamına göre kategorize ederek, farklı finansal işlem türleri için süreç varyasyonlarının ve performansının analiz edilmesini sağlar. Nereden alınır SAP S/4HANA BKPF tablosu, BLART alanı (Belge Türü). Örnekler SAKRAA | |||
| Belge Durumu DocumentStatus | Yevmiye kaydının Park Edildi, Deftere Nakledildi veya Mutabık Kılındı gibi mevcut işleme durumu. | ||
| Açıklama Belge Durumu, yevmiye kaydının yaşam döngüsü içindeki durumunu gösterir. Örneğin, 'park edilmiş' bir belge kaydedilmiş ancak henüz Genel Deftere nakledilmemişken, 'deftere nakledilmiş' bir belge tamamlanmıştır. Durumu analiz etmek, iş akışını anlamaya ve darboğazları belirlemeye yardımcı olur. Uzun süreler boyunca 'park edilmiş' veya 'onay bekliyor' durumunda kalan yüksek sayıda belge, süreçteki verimsizliklere işaret edebilir. Aynı zamanda süreç aktivitelerini türetmek için önemli bir kaynaktır. Neden önemli Bir yevmiye kaydının yaşam döngüsünde nerede olduğuna dair bir anlık görüntü sunar, kuyrukları ve darboğazları belirlemeye yardımcı olur. Nereden alınır SAP S/4HANA BKPF tablosu, BSTAT alanı (Belge durumu). Örnekler VAB | |||
| Bitiş Saati EndTime | `Aktivitenin` ne zaman tamamlandığını gösteren `zaman damgası`. | ||
| Açıklama Bitiş Zamanı, bir aktivitenin tamamlandığını işaret eder. Birçok event logunda, bir aktivitenin Başlangıç Zamanı ve Bitiş Zamanı aynıdır ve anlık bir event'i temsil eder. Ancak, bir kullanıcının bir belgeyi aktif olarak incelemesi gibi ölçülebilir bir süreye sahip aktiviteler için bu öznitelik bu süreyi yakalayabilir. Ayrı bir Bitiş Zamanına sahip olmak, aktivite işleme süreleri ile bekleme sürelerinin daha hassas hesaplanmasına olanak tanır. Bir görevin aktif olarak üzerinde çalışıldığı zamanı, kuyrukta boşta kaldığı zamandan ayırt etmeye yardımcı olur. Neden önemli Hassas faaliyet işlem sürelerinin hesaplanmasını sağlayarak aktif çalışma süresini boş bekleme süresinden ayırır. Nereden alınır Genellikle atomik event'ler için StartTime ile aynıdır. Süreli aktiviteler için, workflow loglarından veya sonraki event'lere dayanarak hesaplanabilir. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| İşlem Kodu TransactionCode | Yevmiye kaydını oluşturmak veya değiştirmek için kullanılan SAP işlem kodu. | ||
| Açıklama İşlem Kodu (T-Kodu), SAP'de belirli bir fonksiyonu veya programı tanımlayan bir kısayoldur. Yevmiye kayıtları için, farklı T-Kodları, kaydın nasıl oluşturulduğunu gösterebilir; örneğin, manuel genel muhasebe kaydı için FB01, park etme için FV50 veya sistem tarafından oluşturulan kayıtlar için otomatik bir kod. Bu öznitelik, bir aktivitenin bir kullanıcı tarafından manuel olarak mı yoksa sistem tarafından otomatik olarak mı gerçekleştirildiğine dair güçlü bir göstergedir. Manuel Kayıt Oranı KPI'sını hesaplamak ve otomasyon fırsatlarını belirlemek için anahtardır. Neden önemli Bir kaydın nasıl işlendiğini (örn. manuel vs. otomatik) gösterir, bu da otomasyon analizi ve süreç varyasyonlarını anlamak için anahtardır. Nereden alınır SAP S/4HANA BKPF tablosu, TCODE alanı (İşlem Kodu). Örnekler FB01FV50F-02 | |||
| Kaynak Sistem SourceSystem | Yevmiye kaydı verilerinin hangi kaynak sistemden çekildiğini belirler. | ||
| Açıklama Bu öznitelik, yevmiye kaydı verilerinin kaynaklandığı kayıt sistemini belirtir. Birden fazla ERP örneği veya eski ve modern sistemlerin bir karışımına sahip şirketler için bu, veri kaynaklarını ayırt etmeye yardımcı olur. Analizde, farklı sistemlerdeki süreç performansını karşılaştırmak veya belirli bir kaynak için veri filtrelemek için kullanılabilir. Veri yönetişimi ve veri bağlamının anlaşılmasını sağlamak için önemlidir. Neden önemli Veri kaynağı hakkında bağlam sağlar, bu da çoklu sistem ortamlarında doğru süreç analizi ve karşılaştırması için çok önemlidir. Nereden alınır Bu, genellikle veri çıkarma sırasında eklenen, belirli SAP S/4HANA örneğini (örn. SID veya mantıksal sistem adı) tanımlayan statik bir değerdir. Örnekler S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Mali Yıl FiscalYear | Yevmiye kaydının ait olduğu mali yıl. | ||
| Açıklama Mali Yıl, şirket kodu ve belge numarasıyla birlikte bir yevmiye kaydı için benzersiz anahtarın bir parçasıdır. Belgenin ilgili olduğu finansal yılı temsil eder. Analizde, mali yıl uzun vadeli trend analizi ve case tanımlayıcısının benzersizliğini sağlamak için kullanılır. Farklı mali yıllardaki süreç metriklerini karşılaştırmak, zaman içindeki performans iyileşmelerini veya kötüleşmelerini ortaya çıkarabilir. Neden önemli Belgeleri benzersiz bir şekilde tanımlamak için kritik bir bileşen sağlar ve yıllık bazda süreç performansı analizine olanak tanır. Nereden alınır SAP S/4HANA BKPF tablosu, GJAHR alanı (Mali Yıl). Örnekler 202320242022 | |||
| Manuel Kayıt mı IsManualPosting | Yevmiye kaydının bir kullanıcı tarafından manuel olarak deftere nakledilip nakledilmediğini gösteren bir boolean bayrak. | ||
| Açıklama Bu öznitelik, bir sistem işi veya arayüzü tarafından otomatik olarak deftere nakledilmek yerine, manuel kullanıcı müdahalesiyle deftere nakledilen yevmiye kayıtlarını tanımlar. Genellikle belgeyi deftere nakletmek için kullanılan İşlem Kodundan türetilir. Bu işaret, Manuel Kayıt Oranı KPI'sını hesaplamak için kullanılır ve kuruluşların Record to Report sürecini otomatikleştirmedeki ilerlemelerini izlemelerine yardımcı olur. Manuel olarak deftere nakledilmiş kayıtları filtreleyerek, analistler hala insan dokunuşu gerektiren belirli senaryoları belirleyebilir ve otomasyon potansiyellerini değerlendirebilir. Neden önemli İnsan ve sistem kaynaklı kayıtlar arasında ayrım yapar, bu da otomasyon seviyelerini ölçmek ve otomasyon fırsatlarını belirlemek için kritik öneme sahiptir. Nereden alınır Bu, TransactionCode'dan türetilmiş hesaplanmış bir özniteliktir. Manuel işlem kodlarının önceden tanımlanmış bir listesi (örn. 'FB01', 'F-02') işareti 'doğru' olarak ayarlamak için kullanılır. Örnekler truefalse | |||
| Onay Çevrim Süresi ApprovalCycleTime | Bir yevmiye kaydının onay için gönderildiği andan, onaylandığı veya reddedildiği ana kadar geçen süre. | ||
| Açıklama Bu hesaplanmış metrik, özellikle onay aşamasının süresine odaklanır. 'İnceleme İçin Yevmiye Gönderildi' aktivitesi ile sonraki 'Yevmiye Kaydı Onaylandı' veya 'Yevmiye Kaydı Reddedildi' aktivitesi arasındaki süreyi ölçer. Bu KPI, onay workflow'u içindeki darboğazları belirlemek için kritiktir. Yüksek onay döngüsü süreleri, genel süreci önemli ölçüde geciktirebilir. Bu metriği onaylayana, şirket koduna veya yevmiye kaydı türüne göre analiz etmek, belirli iyileştirme alanlarını ortaya çıkarabilir. Neden önemli Onay adımının süresini izole ederek, inceleme ve onay iş akışındaki darboğazları tespit etmeye ve gidermeye yardımcı olur. Nereden alınır 'İnceleme İçin Gönderilen Yevmiye Kaydı' olayı ile 'Yevmiye Kaydı Onaylandı' veya 'Yevmiye Kaydı Reddedildi' olayı arasındaki zaman farkı bulunarak hesaplanır. Örnekler 1 gün 2 saat4 saat 25 dakika5 gün 0 saat | |||
| Onaylayan Kullanıcı ApproverUser | Yevmiye kaydını onaylayan veya reddeden kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, gönderilen bir yevmiye kaydını incelemekten ve üzerinde karar vermekten sorumlu kullanıcıyı tanımlar. Çok seviyeli bir onay workflow'unda, tek bir yevmiye kaydı için birden fazla onaylayıcı olabilir. Bu bilgi, onay sürecini detaylı olarak analiz etmek için çok önemlidir. Farklı onaylayıcıların iş yükünü ölçmeye, bireysel onay sürelerini hesaplamaya ve onay zincirindeki darboğazları belirlemeye yardımcı olur. Doğrudan 'Kullanıcı Aktivitesi ve Verimlilik' dashboard'unu destekler. Neden önemli Onaydan sorumlu kişiyi belirleyerek, onay iş yüklerinin, performansın ve darboğazların analiz edilmesini sağlar. Nereden alınır Workflow kayıtlarından (örn. SWW_WI2OBJ, SWWLOG) veya onay adımını kimin gerçekleştirdiğini izleyerek değişiklik belge tablolarından (CDHDR/CDPOS) alınır. Örnekler DMILLERFWHITEKCHEN | |||
| 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üncelleme tarihini ve saatini kaydeder. Analiz edilen verilerin güncelliği konusunda şeffaflık sağlar. Son güncelleme zamanını bilmek, süreç analizinin güncelliğini anlamak için önemlidir. Kullanıcıların dashboard'ları ve KPI'ları doğru yorumlamasına yardımcı olur, gerçek zamanlıya yakın verilere mi yoksa önceki bir döneme ait bir anlık görüntüye mi baktıklarını bilmelerini sağlar. Neden önemli Verilerin güncelliğini gösterir, kullanıcıların süreç analizinin ne kadar güncel olduğunun farkında olmasını sağlar. Nereden alınır Bu, genellikle veri alım pipeline'ı sırasında her kayda oluşturulan ve damgalanan bir meta özniteliktir. Örnekler 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Ters Kayıt Nedeni ReversalReason | Deftere nakledilmiş bir yevmiye kaydının neden ters kaydedildiğini gösteren bir kod. | ||
| Açıklama Deftere nakledilmiş bir yevmiye kaydı yanlış olduğunda, silinemez ancak yeni bir belgeyle ters kayıt yapılması gerekir. İptal Nedeni kodu, bu eylemin neden yapıldığını açıklar, örneğin yanlış bir deftere nakil tarihi veya tutar nedeniyle. İptal nedenlerini analiz etmek, Record to Report sürecindeki hataların temel nedenlerini belirlemeye yardımcı olur. Belirli bir nedenin yüksek sıklığı, yetersiz eğitim veya kontrol arızaları gibi sistemik sorunlara işaret edebilir ve ilk seferde kaliteyi iyileştirmek için ele alınması gereken sorunlardır. Neden önemli Ters kayıtlara yol açan hataların temel nedenini teşhis etmeye yardımcı olur, yeniden işleme miktarını azaltmak ve süreç kalitesini artırmak için gereken içgörüleri sağlar. Nereden alınır SAP S/4HANA BKPF tablosu, STGRD alanı (İptal nedeni). Örnekler 010205 | |||
| Toplam Cycle Time TotalCycleTime | Bir yevmiye kaydı için ilk aktivitenin oluşturulmasından son aktivitenin tamamlanmasına kadar geçen toplam süre. | ||
| Açıklama Bu hesaplanmış metrik, her case için yevmiye kaydı sürecinin uçtan uca süresini ölçer. En son gözlemlenen aktivitenin timestamp'i ile en ilk aktivitenin timestamp'i arasındaki farktır. Toplam Döngü Süresi, genel süreç verimliliğini ölçmek için birincil bir KPI'dır. Süreç performansının üst düzey bir görünümünü sağlar ve zaman içindeki trendleri izlemek için dashboard'larda kullanılır. Uzun döngü sürelerinin nedenlerini analiz etmek, süreç iyileştirme için ortak bir başlangıç noktasıdır. Neden önemli Uçtan uca süreç süresini ölçer, genel süreç verimliliği ve hızı için temel bir performans göstergesi sunar. Nereden alınır Her benzersiz JournalEntryId için maksimum EventTime'dan minimum EventTime çıkarılarak hesaplanır. Örnekler 2 gün 4 saat 30 dakika8 saat 15 dakika15 days 2 hours | |||
| Yeniden İşleme mi? IsRework | Yevmiye kaydının, reddedilme sonrası düzeltilmesi gibi, yeniden işleme tabi tutulup tutulmadığını gösteren bir boolean bayrak. | ||
| Açıklama Bu hesaplanmış öznitelik, ideal 'mutlu yol' sürecinden sapan yevmiye kayıtlarını işaretler. Genellikle case içinde 'Yevmiye Kaydı Reddedildi' veya 'Yevmiye Kaydı Düzeltildi' gibi bir aktivite meydana gelirse 'doğru' olarak ayarlanır. Bu işaret, süreç verimliliği analizini basitleştirir. Yeniden İşleme Oranı KPI'sının hızlı bir şekilde hesaplanmasına olanak tanır ve yeniden işleme olan ve olmayan caseler arasında döngü süreleri ve maliyetlerin doğrudan karşılaştırılmasını sağlar. Yeniden işleme nedenlerini belirlemek, birçok süreç iyileştirme girişiminin birincil hedefidir. Neden önemli Düzeltme veya ek döngüler gerektiren vakaları işaretleyerek, süreç verimsizliklerinin kolayca nicelleştirilmesini ve temel neden analizini sağlar. Nereden alınır Bu, bir case'deki aktivite sırasından türetilmiş hesaplanmış bir özniteliktir. 'Yevmiye Kaydı Reddedildi' gibi bir aktivite mevcutsa 'doğru' olarak işaretlenir. Örnekler truefalse | |||
Record to Report - Yevmiye Kaydı Aktiviteleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| İnceleme İçin Yevmiye Gönderildi | Yevmiye kaydını oluşturan kişi, belgeyi inceleme ve onay workflow'u için resmi olarak gönderir. Bu aktivite, veri girişinden resmi kontrol sürecine geçişi temsil eder ve onay döngüsünü başlatır. | ||
| Neden önemli Bu, onay döngüsü süresinin başlangıcını işaret eder. Bu noktadan nihai onaya veya reddetmeye kadar ölçüm yapmak, özellikle inceleme ve onay aşamalarındaki darboğazları izole etmeye yardımcı olur. Nereden alınır Bu genellikle iş nesnesine bağlı workflow loglarından (SWW_WIHEAD, SWWLOG tabloları) yakalanır. Ayrıca belge üstbilgisindeki (BKPF) özel bir alandaki durum değişikliğinden de çıkarılabilir. Yakala Workflow öğesi oluşturma timestamp'i veya bir durum alanının 'Gönderildi' veya 'İncelemede' olarak değişmesi. Event tipi inferred | |||
| Yevmiye Kaydı Deftere Nakledildi | Yevmiye kaydı, şirketin finansal tablolarını etkileyerek resmi olarak genel deftere kaydedilir. Bu, belgenin kalıcı bir finansal kayıt haline geldiği noktadır. | ||
| Neden önemli Bu, temel işleme döngüsünün sonunu işaret eden birincil başarı dönüm noktasıdır. Deftere nakledilen kayıtların verimini ve bu aşamaya ulaşma süresini analiz etmek, temel Process Mining metrikleridir. Nereden alınır Bu, BKPF tablosundaki Deftere Nakil Tarihi (BUDAT) ile işaretlenmiş açık bir event'tir. Deftere nakledilmiş bir belge, park edilmiş ('V') veya bekletilmiş ('D') belgelerden ayıran boş bir belge durumuna (BSTAT) sahiptir. Yakala Event'i timestamp'lemek için Deftere Nakil Tarihi (BKPF-BUDAT) ve Giriş Tarihi (BKPF-CPUDT) kullanın. Boş bir BKPF-BSTAT, deftere nakledilmiş bir belgeyi gösterir. Event tipi explicit | |||
| Yevmiye Kaydı Mutabık Kılındı | Bir yevmiye kaydındaki açık kalem satırı, bir faturayı mahsup eden bir ödeme gibi başka bir kayıtla kapatılır. Bu faaliyet, belirli satır kalemlerinin mutabakatını işaret eder ve onları etkili bir şekilde kapatır. | ||
| Neden önemli Bu aktivite, birçok yevmiye kaydı için, özellikle bekleyen veya açık kalem yönetilen hesapları içerenler için nihai mutabakat adımını temsil eder. Deftere nakilden mutabık kılınmaya kadar geçen süreyi analiz etmek, mutabakat verimliliğini ölçmeye yardımcı olur. Nereden alınır Bu event, kalem tablosundan (BSEG veya ACDOCA görünümü) çıkarılır. Bir kalem mutabık kılındığında, o kalem için Mutabakat Tarihi (AUGDT) ve Mutabakat Belgesi (AUGBL) alanları doldurulur. Yakala Kalem için mutabakat tarihini (BSEG-AUGDT) event için timestamp olarak kullanın. Event tipi inferred | |||
| Yevmiye Kaydı Oluşturuldu | Bu aktivite, sistemde bir yevmiye kaydı belgesinin ilk oluşturulmasını işaret eder. Kayıt üstbilgi tablosunda (BKPF) oluşturulur, ancak henüz genel deftere nakledilmemiştir. Bu, yevmiye kaydı yaşam döngüsünün başlangıç noktasıdır. | ||
| Neden önemli Bu, süreç için birincil başlangıç event'idir. Bu event'ten deftere nakile kadar geçen süreyi analiz etmek, genel döngü süresini ölçmek ve ilk veri giriş gecikmelerini belirlemek için çok önemlidir. Nereden alınır Bu event, belirli bir belge numarası (BELNR) için oluşturma tarihi (CPUDT) ve oluşturma saati (CPUTM) alanları kullanılarak SAP BKPF tablosundan açıkça yakalanabilir. Yakala Event timestamp'i için BKPF-CPUDT ve BKPF-CPUTM'i kullanın. Event tipi explicit | |||
| Yevmiye Kaydı Onaylandı | Yevmiye kaydı, yetkili bir yönetici tarafından son onayı alır, geçerliliğini ve doğruluğunu onaylar. Bu aktivite, belgenin genel deftere nakledilmesinden önceki son geçittir. | ||
| Neden önemli Bu, onay döngüsünü tamamlayan kritik bir dönüm noktasıdır. Bu adıma ulaşmak için geçen süre, genel süreç süresinin önemli bir bileşeni ve onaylayıcı verimliliğinin temel bir göstergesidir. Nereden alınır Bu event, son onay adımını gösteren bir workflow logundan veya belgedeki bir durum değişikliğinden çıkarılır. Onaylayanın kullanıcı ID'si ve timestamp'i workflow verilerinden veya değişiklik loglarından alınabilir. Yakala İş akışı günlüklerinde son onay adımının zaman damgasını veya değişiklik belgelerinde durum değişikliğinin 'Onaylandı' olduğunu belirleyin. Event tipi inferred | |||
| Yevmiye Kaydı Ters Kayıt İşlemi Yapıldı | Daha önce deftere nakledilmiş bir yevmiye kaydı, ters kayıtlarla yeni bir belge oluşturularak tersine çevrilir. Bu eylem, deftere nakledilmiş belgelerdeki hataları düzeltmek için yapılır ve açık, denetlenebilir bir işlemdir. | ||
| Neden önemli İptaller, deftere nakledilmiş bir belgede hata yapıldığını gösterir. Yüksek iptal oranı, onay sürecindeki veya veri giriş kalitesindeki temel sorunları işaret eder ve bunun izlenmesi ilk seferde doğruluğu artırmaya yardımcı olur. Nereden alınır İptal açık bir event'tir. Yeni iptal belgesinin başlığı (BKPF), Ters Kayıt Belge No (STBLG) alanında orijinal belgeye bir referans içerir. Yeni belgenin deftere nakil tarihi event zamanıdır. Yakala BKPF-STBLG'nin dolu olduğu belgeleri belirleyin. Olay zaman damgası, ters kaydı yapan belgenin deftere nakil tarihidir. Event tipi explicit | |||
| Deftere Kayıt Sonrası Yevmiye Kaydı Değiştirildi | Bir kullanıcı, genel deftere zaten nakledilmiş bir yevmiye kaydındaki sınırlı sayıda alanı değiştirir. Finansal verilerin çoğu deftere nakledildikten sonra değiştirilemezken, metin veya atamalar gibi bazı alanlar değiştirilebilir. | ||
| Neden önemli Bu aktivite kritik bir uyumluluk işaretidir. Deftere nakil sonrası değişiklikler, kayıtları değiştirme girişimlerini gösterebilir ve sahtekarlığı önlemek ve veri bütünlüğünü sağlamak için yakından izlenmelidir. Nereden alınır Bu, değişiklik belge tablolarından (CDHDR ve CDPOS) güvenilir bir şekilde çıkarılabilir. Deftere nakil tarihinden sonra bir değişiklik tarihi ile belge numarası için CDHDR'deki bir giriş, deftere nakil sonrası bir değişikliği gösterir. Yakala CDHDR'de, değişiklik zaman damgasının (UDATE/UTIME) belgenin deftere nakil tarihinden (BKPF-BUDAT) sonra olduğu kayıtları bulun. Event tipi inferred | |||
| Destekleyici Belgeler Eklendi | Bir kullanıcı, faturalar veya elektronik tablolar gibi bir veya daha fazla destekleyici belgeyi yevmiye kaydına ekler. Bu genellikle, inceleme ve denetim süreci boyunca finansal işlem için kanıt ve bağlam sağlamak amacıyla yapılır. | ||
| Neden önemli İncelemeden önce belgelerin eklenmiş olmasını sağlamak, uyumluluk ve onay verimliliği için kritik öneme sahiptir. Bu faaliyet, belge politikalarına uyumu ve bunun onay döngüsü süreleri üzerindeki etkisini ölçmeye yardımcı olur. Nereden alınır Bu, genellikle Genel Nesne Hizmetleri (GOS) aracılığıyla bağlı eklerin oluşturma timestamp'i kontrol edilerek çıkarılır. SRGBTBREL tablosu, iş nesnesini (örn. BKPF belgesi) eke bağlar. Yakala BKPF nesnesine bağlantılar için GOS ek tablolarını (örn. SRGBTBREL) sorgulayın ve ek oluşturma timestamp'ini kullanın. Event tipi inferred | |||
| Manuel Kayıt Tespit Edildi | Yevmiye kaydı, otomatik bir arayüz veya toplu iş yerine manuel bir işlem kodu kullanılarak deftere nakledildi. Bu zamansal bir event değil, deftere nakil aktivitesinin bir sınıflandırmasıdır. | ||
| Neden önemli Manuel kayıtları belirlemek otomasyon girişimleri için kritik öneme sahiptir. Yüksek manuel kayıt oranı, alt sistemleri entegre ederek veya otomatik kayıt programları kullanarak süreçleri kolaylaştırma fırsatları olduğunu gösterir. Nereden alınır Bu, belge üstbilgi tablosundaki (BKPF) işlem kodu (TCODE) alanı analiz edilerek hesaplanır. Bilinen manuel T-Kodlarının (örn. FB01, F-02, FB50) bir listesi, kaydı sınıflandırmak için kullanılır. Yakala Olayı, deftere nakil sırasında önceden tanımlanmış manuel işlem kodları listesine göre BKPF-TCODE'ye dayanarak sınıflandırın. Event tipi calculated | |||
| Yevmiye Kaydı Düzeltildi | Kullanıcı, reddedildikten veya değişiklik için geri gönderildikten sonra bir yevmiye kaydını değiştirir. Bu, yeniden gönderilmeden önce inceleme sürecinde tespit edilen sorunları gidermek için gereken yeniden işleme çabasını temsil eder. | ||
| Neden önemli Bu aktivite, yeniden işleme döngülerini nicelendirir. Düzeltmelerin sıklığını ve süresini analiz etmek, verimsizlik kaynaklarını belirlemeye ve eğitim ve süreç açıklığı için fırsatları vurgulamaya yardımcı olur. Nereden alınır Bu, daha önce 'Reddedildi' durumunda olan bir belge için BKPF tablosundaki 'Son Değiştirme Tarihi' (AEDAT) izlenerek çıkarılabilir. Değişiklik belgeleri, neyin değiştirildiği hakkında daha spesifik ayrıntılar sağlar. Yakala Reddetme event'inden sonra yapılan değişiklikler için değişiklik belge üstbilgilerinden (CDHDR-UDATE) timestamp'i kullanın. Event tipi inferred | |||
| Yevmiye Kaydı Park Edildi | Bir kullanıcı, eksik bir yevmiye kaydını deftere nakletmeden kaydeder, bu da daha sonra tamamlanmasına veya incelenmesine olanak tanır. Bu, 'beklemede' durumunda bir belge başlık kaydı oluşturan, onu deftere nakledilmemiş bir durumda tutan açık bir eylemdir. | ||
| Neden önemli Park etme, gönderimden önceki yaygın bir adımdır. Park edilmiş durumun süresini izlemek, resmi inceleme ve onay süreci başlamadan önce veri tamamlama ve hazırlığındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır BKPF tablosunda, beklemedeki bir belge, belge durum alanı (BSTAT) 'V' değerine sahip olarak tanımlanır. Olay zaman damgası oluşturma tarihidir (CPUDT). Yakala Oluşturma anında BKPF-BSTAT = 'V' olan belgeleri filtreleyin. Event tipi explicit | |||
| Yevmiye Kaydı Reddedildi | Bir inceleyen veya onaylayan, yevmiye kaydını reddeder ve deftere nakledilmesini engeller. Belge genellikle düzeltme için oluşturucuya geri gönderilir ve bir yeniden işleme döngüsü başlatır. | ||
| Neden önemli Reddetmeleri izlemek, süreç kalitesini anlamak ve yaygın hataları belirlemek için anahtardır. Yüksek reddetme oranları, veri doğruluğu, politika anlayışı veya yetersiz destekleyici belgelerle ilgili sorunları gösterir. Nereden alınır Bu event, bir workflow logundaki bir durum değişikliğinden veya yevmiye kaydı belgesindeki özel bir durum alanından çıkarılır. İlgili durum alanındaki değişiklik belge logları (CDHDR/CDPOS) timestamp'i sağlayabilir. Yakala Durum alanı değişikliğini 'Reddedildi' olarak, değişiklik belgeleri (CDHDR/CDPOS) veya iş akışı günlükleri aracılığıyla belirleyin. Event tipi inferred | |||
Veri Çekim Kılavuzları
Adımlar
- Ön Koşullar ve Erişim: SAP S/4HANA'nın temel veritabanını sorgulamak veya ABAP raporlarını çalıştırmak için gerekli yetkilere sahip bir kullanıcıya sahip olduğunuzdan emin olun.
I_JournalEntry,I_JournalEntryItemCDS görünümlerine veCDHDR,CDPOS,SRGBREL,SOOD,SWW_WI2OBJ,SWWLOGHISTtablolarına okuma erişiminiz olması gerekecektir. Erişim genellikle SAP HANA Studio, DBeaver gibi bir veritabanı istemcisi veya Eclipse için SAP ABAP Geliştirme Araçları (ADT) kullanılarak sağlanır. - Sisteme Özgü Yapılandırmaları Belirleme: Sorguyu çalıştırmadan önce, yevmiye kaydı onay iş akışınızda kullanılan belirli görev kodlarını tanımlamalısınız. Gönderim, ret ve onay olaylarına karşılık gelen görev kimliklerini (örn. TS12345678) bulmak için SAP iş akışı yöneticinizle görüşün. Bunlar, nihai sorgudaki yer tutucular için gereklidir.
- SQL Sorgusunu Hazırlama:
querybölümünde sağlanan eksiksiz SQL sorgusunu seçtiğiniz SQL istemcisine veya geliştirme aracına kopyalayın. - Sorgu Parametrelerini Ayarlama: Sorgudaki yer tutucuları bulun ve bunları kendi belirli değerlerinizle değiştirin. Bu,
[YourCompanyCode],[StartDate]ve[EndDate]parametrelerini ayarlamayı içerir. Ayrıca, yer tutucu iş akışı görev kimliklerini ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) bir önceki adımda belirlediğiniz değerlerle değiştirmelisiniz. - Veri Çekim Sorgusunu Çalıştırma: Değiştirilmiş SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Tarih aralığına ve veri hacmine bağlı olarak, sorgunun tamamlanması önemli miktarda zaman alabilir. Bunu yoğun olmayan saatlerde çalıştırmanız önerilir.
- İlk Sonuçları İnceleme: Sorgu tamamlandığında, JournalEntryId, ActivityName ve EventTime gibi tüm sütunların beklendiği gibi doldurulduğundan emin olmak için çıktının ilk birkaç satırını inceleyin. Sonuç kümesi, yevmiye kaydı yaşam döngüsündeki her farklı iş olayı için bir satır içermelidir.
- Verileri CSV'ye Aktarma: Tüm sonuç kümesini SQL aracınızdan tek bir CSV dosyasına aktarın. Özel karakterlerle ilgili sorunları önlemek için dosyanın UTF-8 kodlaması kullandığından emin olun.
- Yüklemeye Hazırlık: Bir Process Mining aracına yüklemeden önce, CSV dosyasının gerekli başlıklara sahip olduğunu doğrulayın. Veri zaten bir olay günlüğü olarak yapılandırılmıştır, bu nedenle başka bir dönüşüm veya pivotlama gerekli olmayacaktır.
Konfigürasyon
- Çekirdek Veri Hizmetleri (CDS) Görünümleri: Veri çekimi öncelikli olarak başlık verileri için
I_JournalEntry'yi ve satır öğesi ile tutar detayları içinI_JournalEntryItem'ı kullanır. Bu görünümler, evrensel deftere (ACDOCA) basitleştirilmiş ve semantik açıdan zengin bir arayüz sunar. - Destekleyici Tablolar: Kapsamlı bir süreç görünümü elde etmek için sorgu, ayrıca birkaç standart SAP tablosunu birleştirir:
- Belgelerdeki değişiklikleri izlemek için
CDHDRveCDPOS. - Genel Nesne Hizmetleri (GOS) aracılığıyla eklerin ne zaman bağlandığını belirlemek için
SRGBRELveSOOD. - Onay iş akışından önemli olayları çıkarmak için
SWW_WI2OBJveSWWLOGHIST.
- Belgelerdeki değişiklikleri izlemek için
- Tarih Aralığına Göre Filtreleme: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek kritik öneme sahiptir.
WHEREkoşulundaI_JournalEntry.CreationDateTimealanını kullanın. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Kurumsal Filtreleme: Veri çekimini ilgili tüzel kişiliklerle sınırlamak için her zaman
CompanyCode'a göre filtreleyin. Büyük bir sistemde tüm şirket kodları için aynı anda sorgulama yapmak, son derece uzun yürütme sürelerine yol açabilir. - İş Akışı Görev Kimlikleri: Sorgu, iş akışı görev kimlikleri için yer tutucular (örneğin,
[Workflow Approved Task ID]) içerir. Bunlar her SAP kurulumuna özgüdür ve iş akışı aktivitelerinin çıkarılması için doğru şekilde yapılandırılmalıdır. Bunlar olmadan, hiçbir gönderim, onay veya reddetme olayı yakalanamaz. - Ön Koşullar: Sorguyu yürüten kullanıcının finans, sistem ve iş akışı tablolarına kapsamlı okuma yetkileri olması gerekir. Bu izinler standart değildir ve özel olarak atanmalıdır.
a Örnek Sorgu sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Adımlar
- Ön Koşullar ve Erişim: SAP S/4HANA'nın temel veritabanını sorgulamak veya ABAP raporlarını çalıştırmak için gerekli yetkilere sahip bir kullanıcıya sahip olduğunuzdan emin olun.
I_JournalEntry,I_JournalEntryItemCDS görünümlerine veCDHDR,CDPOS,SRGBREL,SOOD,SWW_WI2OBJ,SWWLOGHISTtablolarına okuma erişiminiz olması gerekecektir. Erişim genellikle SAP HANA Studio, DBeaver gibi bir veritabanı istemcisi veya Eclipse için SAP ABAP Geliştirme Araçları (ADT) kullanılarak sağlanır. - Sisteme Özgü Yapılandırmaları Belirleme: Sorguyu çalıştırmadan önce, yevmiye kaydı onay iş akışınızda kullanılan belirli görev kodlarını tanımlamalısınız. Gönderim, ret ve onay olaylarına karşılık gelen görev kimliklerini (örn. TS12345678) bulmak için SAP iş akışı yöneticinizle görüşün. Bunlar, nihai sorgudaki yer tutucular için gereklidir.
- SQL Sorgusunu Hazırlama:
querybölümünde sağlanan eksiksiz SQL sorgusunu seçtiğiniz SQL istemcisine veya geliştirme aracına kopyalayın. - Sorgu Parametrelerini Ayarlama: Sorgudaki yer tutucuları bulun ve bunları kendi belirli değerlerinizle değiştirin. Bu,
[YourCompanyCode],[StartDate]ve[EndDate]parametrelerini ayarlamayı içerir. Ayrıca, yer tutucu iş akışı görev kimliklerini ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) bir önceki adımda belirlediğiniz değerlerle değiştirmelisiniz. - Veri Çekim Sorgusunu Çalıştırma: Değiştirilmiş SQL sorgusunu SAP S/4HANA veritabanına karşı çalıştırın. Tarih aralığına ve veri hacmine bağlı olarak, sorgunun tamamlanması önemli miktarda zaman alabilir. Bunu yoğun olmayan saatlerde çalıştırmanız önerilir.
- İlk Sonuçları İnceleme: Sorgu tamamlandığında, JournalEntryId, ActivityName ve EventTime gibi tüm sütunların beklendiği gibi doldurulduğundan emin olmak için çıktının ilk birkaç satırını inceleyin. Sonuç kümesi, yevmiye kaydı yaşam döngüsündeki her farklı iş olayı için bir satır içermelidir.
- Verileri CSV'ye Aktarma: Tüm sonuç kümesini SQL aracınızdan tek bir CSV dosyasına aktarın. Özel karakterlerle ilgili sorunları önlemek için dosyanın UTF-8 kodlaması kullandığından emin olun.
- Yüklemeye Hazırlık: Bir Process Mining aracına yüklemeden önce, CSV dosyasının gerekli başlıklara sahip olduğunu doğrulayın. Veri zaten bir olay günlüğü olarak yapılandırılmıştır, bu nedenle başka bir dönüşüm veya pivotlama gerekli olmayacaktır.
Konfigürasyon
- Çekirdek Veri Hizmetleri (CDS) Görünümleri: Veri çekimi öncelikli olarak başlık verileri için
I_JournalEntry'yi ve satır öğesi ile tutar detayları içinI_JournalEntryItem'ı kullanır. Bu görünümler, evrensel deftere (ACDOCA) basitleştirilmiş ve semantik açıdan zengin bir arayüz sunar. - Destekleyici Tablolar: Kapsamlı bir süreç görünümü elde etmek için sorgu, ayrıca birkaç standart SAP tablosunu birleştirir:
- Belgelerdeki değişiklikleri izlemek için
CDHDRveCDPOS. - Genel Nesne Hizmetleri (GOS) aracılığıyla eklerin ne zaman bağlandığını belirlemek için
SRGBRELveSOOD. - Onay iş akışından önemli olayları çıkarmak için
SWW_WI2OBJveSWWLOGHIST.
- Belgelerdeki değişiklikleri izlemek için
- Tarih Aralığına Göre Filtreleme: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek kritik öneme sahiptir.
WHEREkoşulundaI_JournalEntry.CreationDateTimealanını kullanın. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Kurumsal Filtreleme: Veri çekimini ilgili tüzel kişiliklerle sınırlamak için her zaman
CompanyCode'a göre filtreleyin. Büyük bir sistemde tüm şirket kodları için aynı anda sorgulama yapmak, son derece uzun yürütme sürelerine yol açabilir. - İş Akışı Görev Kimlikleri: Sorgu, iş akışı görev kimlikleri için yer tutucular (örneğin,
[Workflow Approved Task ID]) içerir. Bunlar her SAP kurulumuna özgüdür ve iş akışı aktivitelerinin çıkarılması için doğru şekilde yapılandırılmalıdır. Bunlar olmadan, hiçbir gönderim, onay veya reddetme olayı yakalanamaz. - Ön Koşullar: Sorguyu yürüten kullanıcının finans, sistem ve iş akışı tablolarına kapsamlı okuma yetkileri olması gerekir. Bu izinler standart değildir ve özel olarak atanmalıdır.
a Örnek Sorgu sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Adımlar
- ABAP Programını Oluşturma:
SE38işlem kodunu kullanarak ABAP Düzenleyicisine erişin. Yeni program için, örneğinZ_PM_JE_EXTRACTgibi bir ad girin ve 'Oluştur'a tıklayın. Uygun bir başlık verin, 'Tip'i 'Yürütülebilir Program' olarak ayarlayın ve yerel bir nesne olarak veya bir paket içinde kaydedin. - Seçim Ekranını Tanımlama: Programda, kullanıcıların verileri filtrelemesine olanak tanıyacak parametreler ve seçim seçenekleri tanımlayın. Bu, yevmiye kaydı oluşturma tarihi için bir tarih aralığı (
P_CPUDT_FR,P_CPUDT_TO), Şirket Kodu için bir seçim seçeneği (SO_BUKRS) ve uygulama sunucusundaki çıktı için bir dosya yolu (P_FPATH) içermelidir. - Veri Yapılarını Bildirme: Gereken olay günlüğü formatına uygun bir dahili tablo yapısı tanımlayın. Bu yapı nihai çıktıyı tutacaktır. Ayrıca, BKPF, ACDOCA, CDHDR, CDPOS ve çeşitli iş akışı tabloları gibi seçeceğiniz SAP tabloları için dahili tablolar ve çalışma alanları bildirin.
- Veri Seçim Mantığını Uygulama: Gerekli 12 faaliyetin her biri için veri almak üzere çekirdek ABAP mantığını yazın. Kodu düzenli tutmak için her faaliyet için ayrı alt programlar (FORM'lar) oluşturun. Örneğin,
get_created_events,get_parked_events,get_workflow_eventsvb. için bir FORM oluşturun. - 'Oluşturuldu' ve 'Deftere Kaydedildi' Olaylarını Seçme: Kullanıcının seçim ekranı kriterlerine göre BKPF tablosundan okuyun. BKPF'deki bir giriş oluşturmayı belirtir.
BSTAT = ' 'durumuna sahip bir belge deftere kaydedilmiş kabul edilir. Oluşturma zaman damgasını (CPUDT,CPUTM) olay zamanı olarak kullanın. - 'Beklemede' Olaylarını Seçme: Beklemedeki belge başlıklarını depolayan VBKPF tablosundan okuyun. Bu tablodaki oluşturma zaman damgası, bekleme olayını temsil eder.
- 'İş Akışı' Olaylarını (Gönderildi, Onaylandı, Reddedildi) Seçme: Yevmiye kaydı nesnesini bir iş akışı örneğine bağlamak için SWW_WI2OBJ ve belirli adımların detaylarını ve zamanlamasını almak için SWWLOGHIST veya SWWIHEAD gibi iş akışı tablolarını sorgulayın. Sisteminizdeki gönderim, onay ve reddetme olaylarına karşılık gelen belirli iş akışı görev kimliklerini tanımlamanız gerekecektir.
- 'Değişiklik' ve 'Düzeltme' Olaylarını Seçme:
OBJECTCLAS = 'BELEG'için değişiklik belge tabloları CDHDR (başlık) ve CDPOS (satır) sorgulayın. 'Deftere Kayıt Sonrası Değişiklik' için, değişiklik zaman damgasının belgenin deftere nakil tarihinden sonra olduğu değişiklikleri filtreleyin. 'Düzeltildi' için, beklemedeki veya reddedilmiş belgelere yapılan değişiklikleri filtreleyin. - 'Ters Kayıt' ve 'Mahsup Edildi' Olaylarını Seçme: BKPF'deki
STBLGalanı (Ters Kayıt Belge No.) dolu olan belgeleri bularak ters kayıtları tanımlayın. Ters kayıt olayı zamanı, ters kaydı yapan belgenin oluşturulma zamanıdır. Belirli bir yevmiye kaydının satır öğeleri için ACDOCA tablosundan en son mahsup tarihini (AUGDT) seçerek mahsup olaylarını tanımlayın. - Verileri Birleştirme ve Sıralama: Her faaliyetin verileri seçildikçe, sonuçları nihai ana dahili tabloya ekleyin. Tüm seçimler tamamlandıktan sonra, her vaka için kronolojik sırayı sağlamak amacıyla ana tabloyu
JournalEntryIdveEventTime'a göre sıralayın. - Çıktı Dosyasını Oluşturma: Sıralanmış nihai dahili tablonun içeriğini SAP uygulama sunucusundaki belirtilen dosya yoluna yazmak için
OPEN DATASET,LOOP AT... TRANSFERveCLOSE DATASETifadelerini kullanın. Dosya, bir başlık satırı ile CSV formatında olmalıdır. - Çalıştırmayı Planlama: Düzenli veri çekimleri için,
SM36işlem kodunu kullanarakZ_PM_JE_EXTRACTprogramını tanımlanmış bir programa göre, örneğin haftalık veya aylık olarak çalıştıran bir arka plan işi oluşturun. Bu, veri dışa aktarım sürecini otomatikleştirir.
Konfigürasyon
- Tarih Aralığı: Seçim ekranında muhasebe kaydı oluşturma tarihi (
CPUDT) için zorunlu bir tarih aralığı bulunmalıdır. İyi performans sağlamak amacıyla, verileri 3-6 aylık gibi yönetilebilir parçalar halinde çekmeniz önerilir. - Şirket Kodu (
BUKRS): Bu, veri çekimini Process Mining analiziyle ilgili belirli tüzel kişiliklerle sınırlamak için kritik bir filtredir. Tüm şirket kodları için tek seferde veri çekilmesi önerilmez. - Belge Türü (
BLART): Belirli muhasebe kaydı türlerine odaklanmak için bu isteğe bağlı filtreyi ekleyebilirsiniz; örneğin, Genel Muhasebe Kaydı için 'SA' veya Satıcı Faturaları için 'KR' gibi. Bu, veri hacmini azaltmaya ve veri kümesinin alaka düzeyini artırmaya yardımcı olabilir. - Dosya Yolu: Programın, çıktı dosyasının yazılacağı SAP uygulama sunucusu üzerinde mantıksal bir dosya yolu gerektirmesi. Yolun geçerli olduğundan ve SAP sistem kullanıcısının bu dizin için gerekli yazma yetkilerine sahip olduğundan emin olun. Sunucu dizinlerini yönetmek ve görüntülemek için
AL11işlem kodunu kullanın. - İş Akışı Görev Kimlikleri: İş akışı olaylarını (Gönderildi, Onaylandı, Reddedildi) çıkarmak için kullanılan mantığın, kuruluşunuzun muhasebe kaydı onay iş akışında kullanılan belirli görev kimlikleri ile yapılandırılması gerekir. Bunlar genellikle özelleştirilmiştir ve bir iş akışı danışmanı veya geliştiricisi tarafından belirlenmelidir.
- Ön Koşullar: Programı yürüten kullanıcı veya sistem hesabının ABAP programları (
S_DEVELOP) oluşturma ve çalıştırma yetkilerine, ayrıca finansal tablolara (BKPF, ACDOCA), değişiklik günlük tablolarına (CDHDR, CDPOS) ve iş akışı tablolarına (SWW*) geniş okuma erişimine ihtiyacı vardır.
a Örnek Sorgu abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM.