Kayıttan raporlamaya - yevmiye kaydı için Veri Templateiniz
Kayıttan raporlamaya - yevmiye kaydı için Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- İzlenecek temel yevmiye kaydı etkinlikleri
- SAP ECC’den veri çıkarmaya yönelik pratik yönergeler
Kayıttan raporlamaya - yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Yevmiye kaydı sürecinin belirli bir noktasında gerçekleşen iş etkinliğinin veya olayın adı. | ||
| Açıklama Etkinlik adı, yevmiye kaydının yaşam döngüsündeki 'Yevmiye kaydı oluşturuldu', 'Yevmiye kaydı onaylandı' veya 'Yevmiye kaydı işlendi' gibi belirli bir adımı tanımlar. Bu öznitelik genellikle SAP’deki işlem kodları (TCODE), değişiklik belgeleri günlükleri (CDHDR ve CDPOS tabloları) ve belge durumu alanları gibi birden fazla kaynaktan türetilir. Etkinlikleri analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç haritalarını görselleştirmenizi, adımlar arasındaki geçiş sürelerini hesaplamanızı ve yeniden çalışma döngülerini (ör. 'Yevmiye kaydı reddedildi' ve ardından 'Yevmiye kaydı düzeltildi') belirlemenizi sağlar. Bu veri, çevrim süreleri, yeniden çalışma oranları ve süreç varyantlarıyla ilgili Dashboardlar için temel oluşturur. Neden önemli? Süreç haritasındaki adımları tanımlar ve yevmiye kaydı iş akışını görselleştirip analiz etmenizi, iyileştirmenizi sağlar. Nereden alınır? BKPF’deki işlem kodları (TCODE), belge durumu, SWW_WI2OBJ gibi tablolardaki iş akışı günlükleri veya CDHDR ve CDPOS tablolarındaki değişiklik belgeleri gibi çeşitli kaynaklardan türetilir. Örnekler Yevmiye kaydı oluşturulduYevmiye kaydı onaylandıYevmiye kaydı reddedildiYevmiye kaydı işlendi | |||
| Olay zamanı EventTime | Yevmiye kaydı için belirli bir etkinliğin veya olayın ne zaman gerçekleştiğini gösteren zaman damgası. | ||
| Açıklama Olay zamanı, yevmiye kaydı sürecindeki her etkinliğin kesin tarih ve saatini gösterir. Çevrim süreleri, işlem süreleri ve adımlar arasındaki gecikmeler gibi zamana dayalı tüm metrikleri hesaplamak için bu veri gereklidir. Zaman damgasının kaynağı etkinliğe göre değişir; belge oluşturma tarihi ve saati (CPUDT/CPUTM) veya günlüklerdeki değişiklik zaman damgaları (CDHDR-UDATE/UTIME) kullanılabilir. Analizde olay zamanı, olayları kronolojik sıraya koymak ve süreç haritasını oluşturmak için kullanılır. Ortalama yevmiye kaydı çevrim süresi, ortalama onay süresi ve onaydan kayda kadar geçen süre gibi zamanla ilgili tüm KPI’ları hesaplamak için gereklidir. Neden önemli? Bu zaman damgası, zamana dayalı tüm analizlerin temelini oluşturur ve çevrim sürelerini, işlem sürelerini ve darboğazları hesaplamayı sağlar. Nereden alınır? Etkinliğe bağlı olarak çeşitli alanlardan alınır. Başlıca kaynaklar, BKPF tablosundaki oluşturulma zaman damgası (CPUDT, CPUTM) veya CDHDR tablosundaki değişiklik belgesi zaman damgalarıdır (UDATE, UTIME). Örnekler 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Yevmiye Kaydı Kimliği JournalEntryId | Şirket kodu, belge numarası ve mali yılı bir araya getiren, finansal muhasebe belgesine ait benzersiz tanımlayıcı. | ||
| Açıklama Yevmiye Kaydı Kimliği, yevmiye kaydının yaşam döngüsünü izlemek için kullanılan temel vaka tanımlayıcısıdır. Genellikle Şirket Kodu (BUKRS), Belge Numarası (BELNR) ve Mali Yıl (GJAHR) alanlarının birleştirilmesiyle oluşturulan bileşik bir anahtardır. Böylece tüm SAP sisteminde benzersiz olması sağlanır. Süreç analizinde bu kimlik; oluşturma, beklemeye alma, gönderme, onaylama, reddetme ve kaydetme gibi ilgili tüm etkinlikleri birbirine bağlar. Kimliği izleyerek her yevmiye kaydının uçtan uca yolculuğunu oluşturabilir, çevrim sürelerini ölçebilir ve belirli kayıtlardaki süreç sapmalarını veya darboğazları tespit edebilirsiniz. Neden önemli? Bu anahtar, yevmiye kaydını oluşturulmasından son kaydına kadar izlemeyi sağlar; uçtan uca süreç analizine ve süreç varyantlarının karşılaştırılmasına olanak tanır. Nereden alınır? Bu, genellikle BKPF tablosundaki Şirket Kodu (BUKRS), Belge Numarası (BELNR) ve Mali Yıl (GJAHR) alanlarının birleştirilmesiyle türetilen bir özniteliktir. Örnekler 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Kaynak sistem SourceSystem | Süreç verilerinin çıkarıldığı sistem. | ||
| Açıklama Bu öznitelik, verilerin kaynağını, bu durumda belirli SAP ECC örneğini tanımlar. Genellikle veri çıkarma sırasında eklenen sabit bir değerdir. Basit görünse de birden fazla ERP veya veri kaynağının bulunduğu ortamlarda önem taşır. Veri kökeninin açıkça izlenmesini sağlar ve analizi kaynak sisteme göre filtrelemeye veya bölümlere ayırmaya olanak tanır. Neden önemli? Veri kökenini açıkça gösterir ve özellikle birden fazla kaynak sistemin bulunduğu ortamlarda veri kalitesini izlemek için gereklidir. Nereden alınır? Bu değer genellikle veri dönüştürme sırasında eklenir ve belirli SAP ECC örneğini tanımlar (ör. 'ECC_PROD_100'). Örnekler SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Son veri güncellemesi LastDataUpdate | Verilerin kaynak sistemden en son ne zaman çıkarıldığını veya yenilendiğini gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, SAP ECC’den en son veri çekme işleminin tarih ve saatini kaydeder. Analiz edilen verilerin ne kadar güncel olduğunu anlamak için gerekli bir meta veri alanıdır. Process Mining Dashboardlarında ve analizlerinde son güncelleme zamanını bilmek, kullanıcıların verilere güvenip bilinçli kararlar almasına yardımcı olur. 'Bu bilgiler ne kadar güncel?' sorusunu yanıtlar. Neden önemli? Verilerin güncelliğini gösterir; kullanıcıların analizin kapsadığı dönemi anlamasına ve sonuçlara güvenmesine yardımcı olur. Nereden alınır? Bu meta veri alanı, veri yenileme sırasında veri çıkarma aracı veya ETL süreci tarafından oluşturulup kaydedilir. Örnekler 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Belge türü DocumentType | Muhasebe belgelerinin nasıl işleneceğini ve saklanacağını belirleyen sınıflandırma. | ||
| Açıklama Belge türü; büyük defter kaydı (SA), tedarikçi faturası (KR) veya varlık kaydı (AA) gibi farklı iş işlemlerini birbirinden ayırır. Sistem yapılandırması sırasında tanımlanır ve her yevmiye kaydına atanır. Bu öznitelik, işlemin niteliğine göre süreçleri bölümlere ayırmayı sağladığı için analiz açısından önemlidir. 'Türe göre yevmiye kaydı işlem hacmi' Dashboardu ve 'Yevmiye kaydı türüne göre ortalama çevrim süresi' KPI’ı doğrudan bu alana bağlıdır. Belirli kayıt türlerinin gecikme, yeniden çalışma veya ters kayıt sorunlarına daha yatkın olup olmadığını ortaya çıkarır. Neden önemli? Analizi işlem türüne göre bölümlere ayırarak süreç sorunlarının belirli yevmiye kaydı türleriyle sınırlı olup olmadığını belirlemeye yardımcı olur. Nereden alınır? BKPF belge başlığı tablosundaki BLART alanında bulunur. Örnekler SAKRREAA | |||
| İşlem kodu TransactionCode | Yevmiye kaydını oluşturmak veya işlemek için kullanılan SAP işlem kodu. | ||
| Açıklama İşlem kodu (T-Code), SAP’de belirli bir işlevi veya programı tanımlayan benzersiz koddur. Yevmiye kayıtlarında kaydın nasıl oluşturulduğunu gösterir; örneğin manuel olarak (FB01, F-02), beklemeye alma yoluyla (FV50) veya otomatik bir arayüz üzerinden. Bu öznitelik, 'Manuel etkinlikleri iyileştirme' Dashboardu için çok değerlidir. T-Code’u analiz ederek manuel ve otomatik etkinlikleri ayırt edebilir, en çok zaman alan manuel süreçleri belirleyebilir ve manuel iş yükünü azaltıp verimliliği artıracak otomasyon fırsatlarını bulabilirsiniz. Neden önemli? Manuel ve otomatik süreçleri ayırt etmeye, otomasyon ve süreç standardizasyonu fırsatlarını belirlemeye yardımcı olur. Nereden alınır? BKPF belge başlığı tablosundaki TCODE alanında bulunur. Örnekler FB01F-02FV50FBD1 | |||
| Kayıt tarihi PostingDate | İşlemin büyük deftere kaydedildiği ve böylece mali dönemi etkilediği tarih. | ||
| Açıklama Kayıt tarihi, yevmiye kaydının hangi mali dönemde muhasebeleştirileceğini belirler. Muhasebe dönemi kapanış takvimlerine ve düzenlemelere uygun olması gerektiğinden finans ve uyumluluk açısından önemli bir tarih alanıdır. Process Mining analizinde bu tarih, uyumluluğu izlemek için kullanılır. 'Uyumluluk takibi' Dashboardu ve 'Uyumluluk oranı' KPI’ı, kayıtların doğru dönem içinde yapılıp yapılmadığını bu öznitelikle kontrol eder. Ayrıca yevmiye kaydı hacmindeki zaman içindeki eğilimleri analiz etmek için de kullanılabilir. Neden önemli? Finansal raporlama ve uyumluluk analizi için gereklidir; kayıtların doğru muhasebe döneminde yapılmasını sağlar. Nereden alınır? BKPF belge başlığı tablosundaki BUDAT alanında bulunur. Örnekler 2023-10-312023-11-302024-01-15 | |||
| Kullanıcı User | Yevmiye kaydını oluşturan veya değiştiren kişinin SAP kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, belge oluşturma, beklemeye alma veya kaydetme gibi bir etkinlikten sorumlu SAP kullanıcı adını kaydeder. Belge başlığından veya değişiklik günlüğü tablolarından doğrudan alınır. Kullanıcı özniteliğini analiz etmek, ekip ve bireysel performansı anlamak açısından önemlidir. Kullanıcı başına etkinlik hacmini ve işlem sürelerini izleyerek Kullanıcı Verimliliği Dashboardunu destekler. Ayrıca yeniden çalışma döngülerinde, ters kayıtlarda veya uyumluluk sapmalarında kimlerin yer aldığını belirlemeye yardımcı olur. Böylece hedefli eğitimler veya süreç iyileştirmeleri planlayabilirsiniz. Neden önemli? Her etkinlikten sorumlu kullanıcıyı belirleyerek kullanıcı performansını, iş yükü dağılımını ve yeniden çalışma örüntülerini analiz etmenizi sağlar. Nereden alınır? Genellikle oluşturan kişi için BKPF tablosundaki USNAM alanından, değişiklik yapan kişi içinse CDHDR tablosundaki USERNAME alanından alınır. Örnekler ABROWNCJONESDSMITH | |||
| Şirket kodu CompanyCode | Finansal tabloların hazırlandığı bağımsız tüzel kişiliği temsil eden organizasyon birimi. | ||
| Açıklama Şirket kodu, SAP Financials içindeki temel organizasyon birimlerinden biridir. Tüzel kişiliği bağımsız bir şirketi temsil eder ve yevmiye kaydı belge başlığındaki önemli alanlardan biridir. Bu öznitelik, süreç analizini tüzel kişiliğe göre bölümlere ayırmak için gereklidir. İşletmenin farklı bölümlerindeki süreç performansını, uyumluluk oranlarını ve KPI sonuçlarını karşılaştırmanızı sağlar. Örneğin, onay gecikmelerinin veya yüksek ters kayıt oranlarının belirli şirket kodlarıyla sınırlı olup olmadığını belirleyebilirsiniz. Neden önemli? Kuruluş içindeki farklı tüzel kişilikler veya iş birimleri arasında süreç performansını filtreleyip karşılaştırmanızı sağlar. Nereden alınır? BKPF belge başlığı tablosundaki BUKRS alanında bulunur. Örnekler 10002000US01DE01 | |||
| Ters kayda alındı mı IsReversed | Yevmiye kaydının ters kayda alınıp alınmadığını gösteren Boole türünde bir işaret. | ||
| Açıklama Bu işaret, başka bir muhasebe belgesiyle sonradan ters kaydı yapılan yevmiye kayıtlarını belirtir. SAP’de ters kayıt belgesi, iptal belgesine bağlanır ve böylece açık bir denetim izi oluşturulur. Bu öznitelik, 'Yevmiye kaydı ters kayıt analizi' Dashboardu ve 'Yevmiye kaydı ters kayıt oranı' KPI’ı için temel niteliktedir. Ters kayıt yapılan kayıtları ayırarak veri giriş hataları veya yanlış muhasebe uygulamaları gibi temel nedenleri incelemenize yardımcı olur. Amaç, ters kayıtların sıklığını azaltmaktır. Neden önemli? Sonradan geri alınan kayıtları işaretleyerek ters kayıt analizini doğrudan destekler. Böylece hataların temel nedenlerini belirlemenize ve veri bütünlüğünü iyileştirmenize yardımcı olur. Nereden alınır? BKPF tablosundaki Ters kayıt belgesi numarası alanından (STBLG) türetilir. STBLG boş değilse işaret true değerini alır. Örnekler truefalse | |||
| Bekletildi mi IsParked | Yevmiye kaydının kaydedilmeden önce bekletilen belge olarak kaydedilip kaydedilmediğini belirten bir boole işareti. | ||
| Açıklama Belgeyi bekletmek, kullanıcının mali bakiyeleri etkilemeden eksik bir yevmiye kaydını kaydetmesine olanak tanır. Kayıt yapılmadan önce başka bir kullanıcı belgeyi tamamlayabilir veya inceleyebilir. Bu işaret, bekletme adımından geçen kayıtları belirler. Bu özniteliği incelemek, bekletme özelliğinin nasıl kullanıldığını anlamanıza yardımcı olur. Bekletmenin gayriresmî bir inceleme adımı olarak kullanıldığını ve gecikmelere yol açabileceğini ortaya çıkarabilir. Ayrıca uçtan uca çevrim süresini incelemeyi ve doğrudan kaydedilen kayıtlarla önce bekletilen kayıtları ayırt etmeyi sağlar. Neden önemli? Bekletme özelliğini kullanan kayıtları belirler. Bu adım gecikmelere yol açabilir veya gayriresmî bir inceleme sürecine işaret edebilir. Nereden alınır? BKPF tablosundaki belge durumu alanından (BSTAT) türetilir. 'V' değeri, belgenin bekletildiğini belirtir. Örnekler truefalse | |||
| Belge toplam tutarı TotalDocumentAmount | Yevmiye kaydının belge para birimi cinsinden toplam değeri. | ||
| Açıklama Bu öznitelik, yevmiye kaydının toplam finansal değerini gösterir. Genellikle belgeyle ilişkili tüm borç veya alacak kalemlerinin mutlak değerleri toplanarak hesaplanır. Süreci finansal değere göre analiz etmek önemli örüntüleri ortaya çıkarabilir. Örneğin, yüksek tutarlı kayıtlar daha farklı ve sıkı bir onay sürecinden geçebilir. Bu öznitelikle analizi filtreleyebilir veya bölümlere ayırarak çevrim sürelerinin, ret oranlarının ya da onay gecikmelerinin kayıt tutarıyla ilişkili olup olmadığını inceleyebilirsiniz. Neden önemli? Yevmiye kayıtlarının parasal değeriyle işlem süreleri veya ret oranları arasındaki ilişkiyi incelemek gibi finansal etki analizleri yapmanızı sağlar. Nereden alınır? Bu hesaplanmış alan, belirli bir yevmiye kaydına ait BSEG tablosundaki tüm kalemlerin tutar alanlarının (WRBTR veya DMBTR) toplanmasıyla elde edilir. Örnekler 1500.0025000.75125.50 | |||
| Masraf yeri CostCenter | Masrafların oluştuğu yeri temsil eden, bir kontrol alanı içindeki organizasyon birimi. | ||
| Açıklama Masraf yeri, genellikle yevmiye kaydının kalem düzeyinde atanan ve Kontrol (CO) modülündeki temel ana veri öğelerinden biridir. Belirli bir departman, işlev veya konumun masraflarını izlemek için kullanılır. Masraf yerini analize dahil etmek, yevmiye kaydı sürecini daha ayrıntılı incelemenizi sağlar. Belirli departmanların daha fazla yeniden çalışmaya yol açıp açmadığını, çevrim sürelerinin daha uzun olup olmadığını veya daha fazla manuel kayıttan sorumlu olup olmadığını belirlemenize yardımcı olabilir. Böylece süreç verimliliğini departman bazında görebilirsiniz. Neden önemli? Süreç performansını departman veya işlev alanına göre incelemenizi ve yerel verimsizlikleri belirlemenizi sağlar. Nereden alınır? Belge kalemleri tablosu BSEG’de, KOSTL alanında bulunur. Örnekler 4100CC_FINANCE_US10010101 | |||
| Onay süresi ApprovalTime | Yevmiye kaydının onaya gönderilmesiyle onaylanması veya reddedilmesi arasında geçen süre. | ||
| Açıklama Bu metrik, genellikle toplam çevrim süresini önemli ölçüde etkileyen onay alt sürecinin süresini ölçer. 'Yevmiye kaydı gönderildi' etkinliğinin zaman damgası ile buna karşılık gelen 'Yevmiye kaydı onaylandı' veya 'Yevmiye kaydı reddedildi' etkinliğinin zaman damgası arasındaki fark hesaplanır. Onay süresi, 'Yevmiye kaydı onay performansı' Dashboardunun ve 'Ortalama yevmiye kaydı onay süresi' KPI’ının temel metriğidir. Bu süreyi incelemek, onay iş akışındaki darboğazları belirlemenize, onay verenlerin performansını ölçmenize ve onay eşiklerini değiştirmek gibi süreç düzenlemelerini gerekçelendirmenize yardımcı olur. Neden önemli? Onay aşamasının süresini ölçerek inceleme ve onay iş akışındaki gecikmeleri belirlemenize ve gidermenize yardımcı olur. Nereden alınır? 'Yevmiye kaydı gönderildi' etkinliğinin zaman damgası, 'Yevmiye kaydı onaylandı' veya 'Yevmiye kaydı reddedildi' etkinliğinin zaman damgasından çıkarılarak hesaplanır. Örnekler P1DT2HPT4H15MP3D | |||
| Para birimi anahtarı CurrencyKey | Yevmiye kaydındaki tutarların para birimi kodu. | ||
| Açıklama Bu öznitelik, yevmiye kaydının para birimini (USD, EUR veya JPY gibi) belirtir. Belgeyle ilişkili mali tutarların doğru yorumlanması için gerekli bağlamı sağlar. Her zaman temel bir analiz boyutu olmasa da parasal değerleri doğru yorumlamak açısından önemlidir. Küresel kuruluşlarda analizleri bölümlere ayırmak ve yabancı para birimiyle yerel para birimindeki kayıtların süreçlerinin farklı olup olmadığını görmek için de kullanılabilir. Neden önemli? Tüm parasal değerler için gerekli bağlamı sağlayarak mali analizlerin ve yorumların doğru yapılmasına yardımcı olur. Nereden alınır? Belge başlık tablosu BKPF’de, WAERS alanında bulunur. Örnekler USDEURGBPJPY | |||
| Ters kayıt nedeni ReversalReason | Bir yevmiye kaydının neden ters kayda konu olduğunu belirten kod. | ||
| Açıklama Bir belge ters kayda konu olduğunda SAP, kullanıcının bir neden kodu belirtmesine olanak tanır. Bu kod, yanlış kayıt tarihi veya veri girişi hatası gibi ters kaydın neden gerekli olduğuna ilişkin yapılandırılmış bilgi sağlar. Bu öznitelik, 'Yevmiye kaydı ters kayıt analizi' Dashboardu için temel girdilerden biridir. Kuruluşlar, en sık görülen ters kayıt nedenlerini inceleyerek süreçlerindeki sistemik sorunları veya eğitim eksiklerini belirleyebilir, gelecekteki hataları önlemek ve ters kayıt oranını düşürmek için hedefli adımlar atabilir. Neden önemli? Ters kayıtların neden yapıldığını doğrudan gösterir. Böylece gelecekteki hataları azaltmak için temel nedenleri hedefli biçimde inceleyebilirsiniz. Nereden alınır? Belge başlık tablosu BKPF’de, STGRD alanında bulunur. Örnekler 010205 | |||
| Yeniden çalışma var mı IsRework | Yevmiye kaydının reddedilip düzeltilmesi gibi bir yeniden çalışma döngüsünden geçip geçmediğini belirten bir boole işareti. | ||
| Açıklama Bu işaret, ideal yoldan saparak düzeltme gerektiren durumları belirler. Belirli bir yevmiye kaydında 'Yevmiye kaydı reddedildi' etkinliğinin ardından 'Yevmiye kaydı düzeltildi' etkinliği görülürse genellikle true değerini alır. Bu öznitelik, 'Yevmiye kaydı yeniden çalışma oranı' KPI’ını hesaplamak ve 'Yeniden çalışma ve ret oranı' Dashboardunda analiz yapmak için gereklidir. Süreçteki verimsizliğin boyutunu ölçmenize ve belirsiz gereksinimler ya da yetersiz dokümantasyon gibi yeniden çalışmanın temel nedenlerini incelemenize yardımcı olur. Neden önemli? Düzeltme gerektiren kayıtları işaretler. Böylece yeniden çalışmayı ölçebilir, temel nedenlerini inceleyebilir ve ilk seferde doğru sonuç alma oranını artırabilirsiniz. Nereden alınır? Bu, bir durumdaki etkinlik sırası incelenerek türetilen hesaplanmış bir özniteliktir. Ret veya düzeltme etkinliği görülürse yeniden çalışma döngüsü belirlenir. Örnekler truefalse | |||
Kayıttan raporlamaya - yevmiye kaydı etkinlikleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Yevmiye kaydı beklemeye alındı | Bu etkinlik, yevmiye kaydının büyük deftere resmen işlenmeden önce taslak olarak oluşturulduğunu gösterir. SAP’de kullanıcı, beklemeye alma işlemiyle belgeyi kaydedip durumunu 'beklemede' olarak belirlediğinde bu adım açıkça kaydedilir. | ||
| Neden önemli? Bu, inceleme ve onay içeren süreçler için önemli bir başlangıç olayıdır. Beklemeye alma ile kayıt arasındaki süreyi analiz ederek kayıt öncesi ve onay aşamalarındaki gecikmeleri belirleyebilirsiniz. Nereden alınır? Bu olay, BKPF belge başlığı tablosundan belirlenir. BKPF-BSTAT = 'V' durumuyla oluşturulan belge beklemeye alınmış sayılır. Olayın zaman damgası, oluşturulma tarihi ve saati olan BKPF-CPUDT ve BKPF-CPUTM alanlarından alınır. Kaydedin BKPF-BSTAT değeri 'V' olan belge oluşturma kaydını belirleyin. Olay türü explicit | |||
| Yevmiye kaydı gönderildi | Bu etkinlik, beklemeye alınan yevmiye kaydının oluşturan kişi tarafından tamamlandığını ve artık inceleme ile onaya hazır olduğunu gösterir. Genellikle beklemeye alınan belgeyle ilişkili bir SAP Business Workflow görevinin başlatılmasıyla kaydedilir. | ||
| Neden önemli? Bu adım, kaydı oluşturan kişiden onaylayana devir teslimi gösterir ve onay çevrim süresi metriklerinin ölçümünü başlatır. Onay iş akışının verimliliğini ölçmek için önemli bir kilometre taşıdır. Nereden alınır? Finansal belge nesnesine bağlı onay iş akışı örneğinin başlangıç zamanından çıkarım yapılır. Bunun için SWW_WI2OBJ gibi iş akışı günlük tabloları incelenerek ilgili şirket kodu, belge numarası ve mali yıl için başlatılan iş akışı bulunmalıdır. Kaydedin Beklemeye alınan belge nesnesi için iş akışının başlangıç olayını belirleyin. Olay türü inferred | |||
| Yevmiye kaydı işlendi | Bu temel etkinlikte yevmiye kaydı büyük deftere resmen işlenir ve finansal tabloları etkiler. Belge durumu 'kaydedildi' olarak ayarlanıp kayıt tarihi verildiğinde bu olay açıkça kaydedilir. | ||
| Neden önemli? Bu, yevmiye kaydının başarıyla işlendiğini gösteren en önemli kilometre taşıdır. Uçtan uca çevrim süresi çoğunlukla bu noktaya kadar ölçülür. Finansal kapanış analizinde de önemli bir olaydır. Nereden alınır? BKPF tablosundaki belgede kayıt tarihi (BKPF-BUDAT) bulunduğunda belirlenir. Beklemeye alınan belgelerde bu, BKPF-BSTAT durumunun 'V' değerinden boş değere geçtiği ana karşılık gelir. Kayıt zaman damgası, giriş tarihi olan BKPF-CPUDT alanından alınır. Kaydedin BKPF-BSTAT değerinin 'V' değerinden boş değere geçtiği anı belirleyin. Doğrudan kayıtlarda ise belge oluşturma olayını kullanın. Olay türü explicit | |||
| Yevmiye kaydı onaylandı | Bu etkinlik, iş akışında yevmiye kaydının son onayını gösterir ve kaydın işlenmesine olanak tanır. İş akışı günlüğünde son 'serbest bırak' veya 'onayla' adımı tamamlandığında kaydedilir. | ||
| Neden önemli? Bu, onay sürecini tamamlayan önemli bir kilometre taşıdır. Bu etkinliğe kadar geçen süre, onay verimliliğini ölçen önemli bir metriktir. Bu olaydan kayda kadar geçen süre ise onay sonrası gecikmeyi gösterir. Nereden alınır? SAP Business Workflow günlüğündeki son onay adımının tamamlanma zaman damgasından çıkarım yapılır. Bu, belge kaydedilmeden veya kayda hazır hâle getirilmeden önceki son onay işlemidir. Kaydedin İş akışı günlüklerinde son 'serbest bırak' veya 'onayla' adımının tamamlandığını belirleyin. Olay türü inferred | |||
| Yevmiye kaydı ters kayda alındı | Bu etkinlik, daha önce kaydedilmiş bir yevmiye kaydının ters kayda alınmasını gösterir. Ters kayıt, ilk kaydı iptal eden yeni bir muhasebe belgesidir. | ||
| Neden önemli? Bu olay, veri kalitesini ve süreç doğruluğunu ölçmek açısından önemlidir. Ters kayıt oranının yüksek olması, ilk veri girişi veya onay aşamalarındaki sistematik sorunlara işaret eder. Her ters kayıt yeniden çalışma anlamına gelir. Nereden alınır? Bu olay, ilk belgenin başlık bilgilerinden (BKPF tablosu) belirlenir. Bir belge ters kayda alındığında SAP, ters kayıt belge numarasını (BKPF-STBLG) ve ters kayıt nedenini (BKPF-STGRD) doldurur. Olayın zaman damgası, yeni ters kayıt belgesinin kayıt tarihidir. Kaydedin İlk belgede BKPF-STBLG alanının doldurulduğu anı belirleyin. Zaman damgası, ters kayıt belgesinin kayıt tarihidir. Olay türü explicit | |||
| Beklemeye alınan yevmiye kaydı silindi | Bu etkinlik, hiç kaydedilmemiş ve beklemeye alınmış bir yevmiye kaydının silinmesini ifade eder. Ret sonrasında veya kayıt yanlışlıkla oluşturulduğunda gerçekleşebilir. | ||
| Neden önemli? Bu etkinlik, sürecin başarısız biçimde sona erdiğini gösterir. Beklemeye alınan belgelerin neden silindiğini analiz etmek, yinelenen kayıtlar veya süreçle ilgili yanlış anlamalar gibi sorunları ortaya çıkarabilir. Nereden alınır? Bu olay, BKPF tablosundaki beklemeye alınmış belgenin durumu değiştirildiğinde kaydedilir. BKPF-BSTAT durum alanı 'Z' (beklemeye alınan belge silindi) olarak güncellenir. Değişiklik zaman damgası, belge değişiklik günlüklerinde (CDHDR) bulunabilir. Kaydedin BKPF-BSTAT değerinin 'Z' olarak güncellendiği anı belirleyin. Olay türü explicit | |||
| Dokümantasyon eklendi | Bu etkinlik, kullanıcının fatura veya elektronik tablo gibi destekleyici belgeleri yevmiye kaydına eklemesini ifade eder. Bu olay standart bir muhasebe olayı olarak açıkça kaydedilmez. Genellikle muhasebe belgesi nesnesine bağlı eklerin oluşturulup oluşturulmadığı kontrol edilerek çıkarım yapılır. | ||
| Neden önemli? Bu etkinliği izlemek, dokümantasyon gerektiren politikalara uyulup uyulmadığını doğrulamaya yardımcı olur. Belgelerin geç eklenmesi, onay döngülerinin uzamasına yol açabilir. Nereden alınır? Bu olayı zaman damgalı bir etkinlik olarak güvenilir biçimde yakalamak zordur. Generic Object Services (GOS) ek tabloları (ör. SOOD) incelenerek ve ekin oluşturulma zaman damgası yevmiye kaydı nesne anahtarıyla ilişkilendirilerek olayın çıkarımı yapılabilir. Kaydedin GOS tablolarındaki (ör. SOOD) bağlantılı nesnelerin oluşturulma zaman damgasından çıkarım yapın. Olay türü inferred | |||
| Manuel giriş belirlendi | Bu etkinlik, yevmiye kaydının otomatik bir arayüz veya toplu işlem yerine çevrimiçi manuel bir işlemle oluşturulup oluşturulmadığını belirler. Bu bir kullanıcı işlemi değil, sistem verilerinden türetilen hesaplanmış bir kayıt özniteliğidir. | ||
| Neden önemli? Manuel ve otomatik kayıtları ayırt etmek, iyileştirme çalışmalarını doğru alanlara yönlendirmek için önemlidir. Standartlaştırma ve otomasyon çalışmaları genellikle manuel süreçlere odaklanır. Nereden alınır? BKPF belge başlığı tablosundaki alanlar incelenerek hesaplanır. 'FB01', 'FB50' veya 'FV50' gibi işlem kodları (BKPF-TCODE) manuel girişi gösterirken diğer T kodları veya belirli toplu giriş adları (BKPF-AWKEY) otomasyona işaret eder. Kaydedin Belge başlığındaki BKPF-TCODE veya kaynak sistemi gösteren diğer alanlardan türetin. Olay türü calculated | |||
| Şirketler arası kayıt belirlendi | Bu hesaplanmış etkinlik, birden fazla şirket kodunu etkileyen yevmiye kayıtlarını işaretler. Tek bir finansal belgenin kalemleri incelenerek belirlenir. | ||
| Neden önemli? Şirketler arası işlemlerin işleme ve onay gereklilikleri daha karmaşık olabilir. Bu kayıtları belirleyerek çevrim sürelerini ve süreç yollarını ayrı ayrı analiz edebilir, kendilerine özgü darboğazları bulabilirsiniz. Nereden alınır? Belirli bir belge numarasına (BELNR) ait BSEG kalem tablosu incelenerek hesaplanır. Kalemlerde birden fazla farklı şirket kodu (BSEG-BUKRS) varsa kayıt şirketler arasıdır. Kaydedin Tek bir BKPF-BELNR için birden fazla benzersiz BSEG-BUKRS değeri olup olmadığını kontrol edin. Olay türü calculated | |||
| Yevmiye kaydı düzeltildi | Bu etkinlik, ilk kaydı oluşturan kişinin değişiklik için geri gönderilen beklemeye alınmış yevmiye kaydını düzenlediğini gösterir. 'Değişiklik istendi' olayından sonra belgede yapılan değişiklikler tespit edilerek çıkarım yapılır. | ||
| Neden önemli? Düzeltmeleri izlemek, yeniden çalışma için harcanan çabayı ölçmeye yardımcı olur. Değişiklik talebiyle düzeltme arasındaki süre, gönderilen kayıtlardaki sorunların çözümünde yaşanan gecikmeleri gösterir. Nereden alınır? Beklemeye alınan belgeye ait değişiklik belgeleri günlükleri (CDHDR ve CDPOS tabloları) incelenerek çıkarım yapılır. İş akışındaki ret olayından sonra kaydedilen bir değişiklik, düzeltme yapıldığını gösterir. Zaman damgası CDHDR tablosundan alınır. Kaydedin Ret olayından sonra CDHDR/CDPOS tablolarında kaydedilen değişikliği belirleyin. Olay türü inferred | |||
| Yevmiye kaydı için değişiklik istendi | Bu etkinlik, onaylayanın yevmiye kaydını inceleyip düzeltme için kaydı oluşturan kişiye geri gönderdiği iş akışı adımını ifade eder. Bu olay, iş akışı günlüklerinde 'reddet' veya 'geri gönder' kullanıcı kararı olarak kaydedilir. | ||
| Neden önemli? Bu etkinlik, verimsizliğin ve süreç sapmalarının başlıca nedenlerinden biri olan yeniden çalışma döngülerini belirlemek için gereklidir. Bu olayın sık yaşanması, kayıt kalitesiyle veya gerekliliklerin açıklığıyla ilgili sorunlara işaret eder. Nereden alınır? Bu olay, SAP Business Workflow günlüğündeki 'reddet' veya 'düzeltme için gönder' işlemiyle eşleşen belirli bir kullanıcı kararı adımının zaman damgasından çıkarılır. Kaydedin İş akışı günlüklerinde 'ret' veya 'yeniden çalışma' kararının zaman damgasını belirleyin. Olay türü inferred | |||
| Yevmiye kaydı kalemi kapatıldı | Bu etkinlik, banka mutabakat hesabı gibi açık kalem yönetimi yapılan bir büyük defter hesabındaki kalemin mutabakatını ifade eder. Bir kalem başka bir kalemle eşleştirilip kapatıldığında gerçekleşir. | ||
| Neden önemli? Banka mutabakatı gibi süreçlerde kalemlerin kapatılma süresi önemli bir metriktir. Bu etkinlik, mutabakat ve ay sonu kapanış işlemlerinin verimliliğini analiz etmeye yardımcı olur. Nereden alınır? Bu olay, BSEG kalem tablosundan alınır. Bir kalem kapatıldığında kapatma tarihi (BSEG-AUGDT) ve kapatma belgesi (BSEG-AUGBL) alanları doldurulur. Olayın zaman damgası kapatma tarihidir. Kaydedin Bir kalemin kapatma tarihi (BSEG-AUGDT) alanının doldurulduğu anı belirleyin. Olay türü explicit | |||
| Yevmiye kaydı oluşturuldu | Bu etkinlik, öncesinde beklemeye alma adımı olmadan doğrudan kaydedilen yevmiye kaydının oluşturulmasını ifade eder. SAP’de doğrudan kayıt işlemiyle belge oluşturulduğunda bu adım kaydedilir. | ||
| Neden önemli? Bu etkinlik, onay iş akışı gerektirmeyen daha basit yevmiye kaydı süreçleri için alternatif bir başlangıç noktasıdır. Basit ve doğrudan kayıtları, daha karmaşık ve beklemeye alınan kayıtlardan ayırmaya yardımcı olur. Nereden alınır? Bu olay, BKPF tablosunda belge durumunun boş (kaydedilmiş) olduğu belge oluşturma kaydına karşılık gelir. Olayın zaman damgası, oluşturulma tarihi olan BKPF-CPUDT alanından alınır. Bu belgelerde 'Oluşturuldu' ve 'Kaydedildi' olayları aynı anda gerçekleşir. Kaydedin BKPF-BSTAT değeri boş olan belge oluşturma kaydını belirleyin. Olay türü explicit | |||
| Yevmiye kaydı reddedildi | Bu etkinlik, yevmiye kaydının kesin olarak reddedildiğini ve artık kaydedilmeyeceğini gösterir. Genellikle onay iş akışının son durumudur ve beklemeye alınan belgenin daha sonra silinmesine yol açar. | ||
| Neden önemli? Retleri izlemek, kalite yönetimi açısından önemlidir. Ret nedenlerini ve sıklığını analiz etmek, yevmiye kayıtlarının ilk seferde doğru hazırlanma oranını artırmaya yardımcı olur. Nereden alınır? Bu sonuç, süreci sonlandıran nihai bir 'reddet' kullanıcı kararını gösterir ve SAP Business Workflow günlüğünden alınır. Beklemeye alınan belge daha sonra silinebilir. Kaydedin Belgeye ait iş akışı günlüğünde süreci sonlandıran 'reddedildi' durumunu belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- ABAP programını oluşturun: SAP sisteminde SE38 işlem koduna (ABAP Editor) gidin. Yeni program için Z_PM_JE_EXTRACTION gibi bir ad girip Oluşturun seçeneğine tıklayın. Uygun bir başlık girin ve program türünü 'Executable Program' olarak ayarlayın.
- Seçim ekranını tanımlayın: Programın kaynak kodunda seçim ekranını tanımlayın. Böylece kullanıcılar veri çıkarma hacmini sınırlamak için belge oluşturma tarih aralığı, şirket kodları ve belge türleri gibi parametreleri belirleyebilir.
- Veri yapılarını tanımlayın: Son olay günlüğü verilerini tutacak bir dahili tablo yapısı tanımlayın. Bu yapıda JournalEntryId, ActivityName, EventTime, SourceSystem ve LastDataUpdate alanları ile User, CompanyCode ve PostingDate gibi önerilen öznitelikler bulunmalıdır.
- Veri seçme mantığını uygulayın: Gerekli 14 etkinliğin her biri için temel ABAP SQL sorgularını yazın. BKPF (başlık) ve BSEG (kalem) gibi ana tablolardan, CDHDR ve CDPOS değişiklik günlüğü tablolarından, SWWLOGHIST gibi iş akışı tablolarından ve BSAS ile BSAK gibi mahsup tablolarından veri seçin.
- Bekletilen ve kaydedilen belgeleri çıkarın: 'Yevmiye kaydı bekletildi' etkinlikleri için BKPF tablosunda belge durumunun (BSTAT) 'V' olduğu kayıtları seçin. 'Yevmiye kaydı oluşturuldu' ve 'Yevmiye kaydı kaydedildi' etkinlikleri için durum alanı boş olan, yani normal şekilde kaydedilmiş belgeleri BKPF tablosundan seçin.
- Değişiklik ve silme etkinliklerini çıkarın: 'Yevmiye kaydı düzeltildi' veya 'Bekletilen yevmiye kaydı silindi' etkinliklerine karşılık gelen değişiklikleri bulmak için CDHDR ve CDPOS değişiklik belgesi tablolarını 'BELEG' nesne sınıfına göre sorgulayın. Belge anahtarına göre filtre uygulayın.
- İş akışı etkinliklerini çıkarın: 'Yevmiye kaydı gönderildi', 'Onaylandı', 'Reddedildi' ve 'Değişiklik istendi' gibi etkinlikleri yakalamak için iş akışı tablolarını sorgulayın. Muhasebe belgesini bir iş akışı örneğine bağlamak için SWW_WI2OBJ tablosunu kullanın, ardından belirli kullanıcı kararlarını veya durum değişikliklerini okumak için SWWLOGHIST tablosuna bakın.
- Hesaplanan etkinlikleri belirleyin: 'Manuel kayıt belirlendi' etkinliği için işlem kodunu (BKPF-TCODE) bilinen manuel kayıt işlem kodları listesiyle karşılaştırın. 'Şirketler arası kayıt belirlendi' etkinliği için belirli bir belgenin BSEG kalemlerini inceleyerek birden fazla şirket kodunun kullanılıp kullanılmadığını kontrol edin.
- Verileri birleştirin ve dönüştürün: Her etkinliğin verilerini seçerken son olay günlüğü yapısına dönüştürün. JournalEntryId oluşturmak için CompanyCode, Document Number ve Fiscal Year alanlarını birleştirin. SAP tarih ve saatlerini tek bir EventTime zaman damgasına dönüştürün. Her sorgunun sonuçlarını son dahili tabloya ekleyin.
- Dosya dışa aktarma işlemini uygulayın: Birleştirilmiş dahili tabloyu SAP uygulama sunucusu dizinindeki CSV veya düz metin dosyasına yazmak için OPEN DATASET, LOOP AT, TRANSFER ve CLOSE DATASET gibi ABAP dosya işleme ifadelerini kullanın. Dosyayı AL11 işlem koduyla görüntüleyebilirsiniz.
- Arka plan işi olarak zamanlayın: SM36 işlem koduna (Define Background Job) gidin. Yeni bir iş oluşturun, ABAP programınızı çalıştıran bir adım tanımlayın ve veri çıkarma işlemini otomatikleştirmek için yoğun olmayan saatlerde her gece veya haftada bir gibi bir zamanlama belirleyin.
- Dosyayı alın ve biçimlendirin: Oluşturulan dosyayı uygulama sunucusundan yerel makinenize indirmek için CG3Y işlem kodunu kullanın veya sistem yöneticinizden yardım alın. Dosya kodlamasının ve biçiminin Process Mining aracınıza yüklemeye uygun olduğundan emin olun.
Yapılandırma
- Tarih aralığı: Performansı yönetmek için bir tarih aralığı belirlemeniz önemlidir. Birincil filtre olarak belge oluşturma tarihini (BKPF-CPUDT) kullanın. İlk analiz için 3 ila 6 aylık bir dönem önerilir. Test sırasında veri içerdiği bilinen birkaç günlük bir aralık kullanın.
- Şirket kodu filtresi: Her zaman şirket koduna (BKPF-BUKRS) göre filtre uygulayın. Tüm şirket kodlarının verilerini aynı anda çıkarmak sistem kaynaklarını yoğun biçimde kullanabilir. Tek bir şirket koduyla veya ilgili küçük bir grupla başlayın.
- Belge türü filtresi: Tüm belge türlerini analiz etmeniz gerekmiyorsa, kapsamı belirli yevmiye kaydı türleriyle sınırlamak için belge türü filtresini (BKPF-BLART) kullanın. Örneğin, G/L belgeleri için 'SA' değerini seçin.
- İş akışı görev kimlikleri: İş akışı etkinliklerini çıkarma mantığı, sisteminizde onay, ret ve gönderim için kullanılan belirli görev kimliklerine bağlıdır. Bu kimlikleri, şirketinizin iş akışı tanımlarına göre programın kaynak kodunda yapılandırmanız gerekir.
- Performansla ilgili noktalar: Program, özellikle CDPOS ve iş akışı geçmişi tabloları olmak üzere büyük tabloları birleştirir. Programı yoğun iş saatlerinde çalıştırmak sistem performansını etkileyebilir. Her zaman yoğun olmayan saatlerde çalışacak bir arka plan işi olarak zamanlayın. Performans sorunu tekrarlanıyorsa ikincil veritabanı dizinleri oluşturmayı değerlendirin.
- Ön koşullar: Bu yöntem için ABAP geliştirme yetkilerine (SE38 için) ve arka plan işleri oluşturup yönetme izinlerine (SM36 için) sahip bir kullanıcı gerekir. Kullanıcının veya işin ilgili tüm mali, iş akışı ve sistem tablolarına (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST vb.) okuma erişimi de olmalıdır.
Örnek sorgu abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Adımlar
- Veritabanı bağlantısını kurun: SAP ECC veritabanı için salt okunur kimlik bilgilerini alın. Veritabanına bağlanmak için DBeaver, SAP HANA Studio veya SQL Server Management Studio gibi standart bir SQL istemcisi kullanın.
- SQL sorgusunu hazırlayın: Bu belgenin 'query' bölümünde verilen SQL sorgusunun tamamını SQL istemcinize kopyalayın.
- Veri çıkarma parametrelerini ayarlayın: Sorguyu çalıştırmadan önce içindeki yer tutucuları yapılandırın. '[START_DATE]' ve '[END_DATE]' değerlerini 'YYYYMMDD' biçiminde istediğiniz tarih aralığıyla değiştirin. '[COMPANY_CODE_1]', '[COMPANY_CODE_2]' değerlerini analiz etmek istediğiniz SAP şirket kodlarıyla değiştirin.
- Kaynak sistemi tanımlayın: Veri kaynağını doğru belirlemek için ana
SELECTifadesindeki '[Your SAP System ID]' yer tutucusunu gerçek SAP System ID (SID) değeriyle değiştirin. - Sorguyu çalıştırın: Yapılandırılmış SQL sorgusunu SAP veritabanında çalıştırın. Çalışma süresi, tarih aralığına ve veritabanı tablolarınızın boyutuna göre değişir.
- İlk sonuçları inceleyin: Sorgu tamamlandığında, verilerin beklendiği gibi geldiğinden emin olmak için dönen satırları kısaca gözden geçirin. Farklı etkinliklerin bulunduğunu ve
JournalEntryIdileEventTimegibi temel alanların boş olmadığını kontrol edin. - Zaman damgalarını işleyin: Sorgu, tarih ve saat alanlarını birleştirerek
YYYYMMDDHHMMSSbiçiminde bir metin oluşturur. Sonraki işlem adımınızın veya hedef sisteminizin bu biçimi ayrıştırabildiğinden emin olun. Veritabanınız destekliyorsa SQLCONCATişleviniYYYY-MM-DDTHH:MI:SSgibi ISO 8601 biçimine göre düzenleyin. - Verileri dışa aktarın: Sonuç kümesinin tamamını SQL istemcinizden CSV dosyasına aktarın. Özel karakterlerle ilgili sorunları önlemek için UTF-8 kodlamasını kullanın.
- Yüklemeye hazırlanın: Process Mining aracına yüklemeden önce sütun başlıklarının gerekli veri şemasıyla eşleştiğini doğrulayın.
JournalEntryId,ActivityNameveEventTimetemel alanlardır.LastDataUpdatesütununu ekleyin ve veri çıkarma işleminin yapıldığı zaman damgasını bu sütuna yazın. - Son doğrulamayı yapın: Analize başlamadan önce çıkarılan verilerin eksiksiz ve doğru olduğundan emin olmak için 'validationSteps' bölümündeki adımları uygulayın.
Yapılandırma
- Veritabanı yetkileri: Veritabanı kullanıcısının şu SAP tablolarına okuma erişimi olmalıdır: BKPF, BSEG, CDHDR, CDPOS, T001 ve V_USERNAME. İş akışıyla ilgili etkinlikler için SWW_WI2OBJ ve SWWLOGHIST tablolarına erişim de gerekir. Bu düzeyde erişim genellikle yalnızca uzman teknik ekiplere verilir.
- Tarih aralığı filtresi: Sorgu performansını korumak için verileri belirli bir tarih aralığına göre filtrelemeniz önemlidir. Sağlanan sorguda başlangıç ve bitiş tarihi için yer tutucular bulunur; bu tarihler belge oluşturma tarihine (
BKPF.CPUDT) uygulanır. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Kuruluş filtresi: Veri hacmini yönetmek ve analizi belirli bir kapsama odaklamak için her zaman şirket koduna (
BKPF.BUKRS) göre filtre uygulayın. Yalnızca ilgili yevmiye kaydı türlerini dahil etmek için belge türüne (BKPF.BLART) göre de filtre uygulayabilirsiniz. Örneğin, G/L belgeleri için 'SA' değerini kullanın; kapsam dışındaysa fatura veya ödeme gibi operasyonel belgeleri hariç tutun. - Performansla ilgili noktalar: BSEG ve CDPOS gibi temel tablolara doğrudan sorgu göndermek sistem kaynaklarını yoğun biçimde kullanabilir. Son kullanıcıların sistem performansının etkilenmemesi için veri çıkarma işlemini yoğun olmayan iş saatlerinde yapmanız önemle önerilir. Tek çalıştırmada bir yıldan uzun süreye ait verileri çıkarmayın.
- İş akışı görev kimlikleri: Sorguda
'[WF_TASK_ID_SUBMIT]'ve'[WF_TASK_ID_APPROVE]'gibi yer tutucular bulunur. Bunları, sisteminizdeki yevmiye kaydı iş akışı yapılandırmasında kullanılan gerçek görev kimlikleriyle değiştirin. Bu kimlikleri bir SAP Workflow uzmanıyla birlikte çalışarak veya PFTC işlem kodundaki teknik iş akışı tanımını inceleyerek bulabilirsiniz.
Örnek sorgu sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Adımlar
- SAP bağlantısını kurun: Üçüncü taraf ETL aracınızda SAP ECC sisteminiz için yeni bir kaynak bağlantısı yapılandırın. Bunun için genellikle uygulama sunucusu bilgileri, istemci, sistem numarası ve gerekli RFC yetkilerine sahip özel bir SAP Kullanıcısı gerekir.
- Veri kaynaklarını tanımlayın: Veri çıkarma projenize gerekli SAP tablolarını veri kaynağı olarak ekleyin. Başlıca tablolar şunlardır: BKPF (Muhasebe Belgesi Başlığı), BSEG (Muhasebe Belgesi Kalemi), VBSEGK (Bekletilen Belge Başlığı), CDHDR (Değişiklik Belgesi Başlığı), CDPOS (Değişiklik Belgesi Kalemleri), SWW_WI2OBJ (İş akışı-nesne bağlantıları), SWWLOGHIST (İş akışı günlüğü) ve SRGBTBREL (GOS ekleri için ilişkiler).
- Temel olayları çıkarın (oluşturuldu ve bekletildi): İlk olayları çıkarmak için ilk veri akışını oluşturun. 'Yevmiye kaydı bekletildi' olayı için kaynak olarak VBSEGK tablosunu kullanın. 'Yevmiye kaydı oluşturuldu' olayı için BKPF tablosunu kullanın; ters kayıt olmayan ve başlangıçta bekletilmemiş belgeleri filtreleyin. Bunu VBSEGK ile anti-join uygulayarak yapabilirsiniz.
- İş akışı olaylarını çıkarın: İş akışı örneği kimliğini bulmak için şirket kodu + belge numarası + mali yıl biçimindeki nesne anahtarını kullanarak BKPF tablosunu SWW_WI2OBJ tablosuyla birleştiren bir veri akışı oluşturun. Ardından bu sonucu SWWLOGHIST tablosuyla birleştirerek günlükte kaydedilen iş akışı görevi sonuçlarına ve kullanıcı kararlarına göre 'Gönderildi', 'Onaylandı', 'Reddedildi' ve 'Değişiklik istendi' gibi olayları çıkarın.
- Değişiklik ve silme olaylarını çıkarın: Değişiklikleri belirlemek için CDHDR ve CDPOS tablolarını kullanın. 'Yevmiye kaydı düzeltildi' olayı için nesne sınıfı 'FIPP' olan bekletilmiş belgelerde yapılan değişiklikleri filtreleyin. 'Bekletilen yevmiye kaydı silindi' olayını bulmak için bekletilmiş belgelere ait değişiklik günlüklerindeki silme işaretlerini arayın.
- Ek olaylarını çıkarın: 'Dokümantasyon eklendi' olayını yakalamak için nesne türü 'BKPF' ve ilişki türü '[Ek ilişki türünüz]' olan BKPF kayıtlarını SRGBTBREL ile birleştirin. Bağlantının oluşturulma tarihi olay zamanı olarak kullanılır.
- Mahsup ve ters kayıt olaylarını çıkarın: 'Yevmiye kaydı kalemi mahsup edildi' olayı için mahsup belgesi alanı (AUGBL) dolu olan BSEG kayıtlarını sorgulayın. Olay zamanı, mahsup belgesinin kayıt tarihidir (AUGDT). 'Yevmiye kaydı ters kaydı işlendi' olayı için ters kaydedilmiş belgeleri, ters kayıtlı belge alanında (STBLG) değer bulunan BKPF kayıtlarını sorgulayın.
- Hesaplanan olayları türetin: Hesaplanan olaylar için ayrı mantık blokları oluşturun. 'Manuel kayıt belirlendi' olayı için BKPF kayıtlarını manuel işlem kodları listesine (ör. FB01, FB50, F-02) göre filtreleyin. 'Şirketler arası kayıt belirlendi' olayı için BSEG tablosunu belge kimliğine göre gruplayın ve birden fazla farklı şirket kodu içeren belgeleri belirleyin.
- Tüm olay akışlarını birleştirin: Tek bir olay günlüğü tablosunda ayrı olay akışlarının (oluşturuldu, bekletildi, onaylandı vb.) çıktılarını birleştirmek için ETL aracınızda UNION dönüşümünü kullanın. Tüm akışlardaki sütun adlarının ve veri türlerinin tutarlı olduğundan emin olun.
- Son şemaya eşleyin: Birleştirilmiş verileri gerekli olay günlüğü yapısına eşleyerek
JournalEntryId,ActivityName,EventTime,Userve gerekli ya da önerilen diğer öznitelikleri oluşturun.SourceSystemgibi sabit sütunlar ekleyin veLastDataUpdateiçin ETL işinin çalıştırılma zamanını kullanın. - Artımlı yüklemeyi yapılandırın: Düzenli veri çıkarımları için artımlı yükleme stratejisi belirleyin. Yalnızca son çalıştırmadan bu yana eklenen veya güncellenen kayıtları almak için son oluşturma ya da değişiklik tarihini (ör. BKPF.CPUDT, CDHDR.UDATE) eşik değer olarak kullanın.
- ProcessMind için dışa aktarın: Veri çıkarma işini zamanlayın ve son çıktı adımını, olay günlüğünü ProcessMind’in erişebileceği bir konuma CSV veya Parquet dosyası olarak kaydedecek şekilde yapılandırın.
Yapılandırma
- Ön koşullar: Özel SAP bağlayıcısı bulunan, lisanslı bir üçüncü taraf ETL aracı (ör. Theobald Xtract Universal, Informatica, Talend). RFC erişimi olan ve finans tablolarını (ör. F_00, F_WF tablo grupları için S_TABU_DIS), iş akışı verilerini ve değişiklik günlüklerini okuma yetkilerine sahip bir SAP kullanıcı hesabı.
- Bağlantı parametreleri: SAP Uygulama Sunucusu IP adresi veya ana bilgisayar adı, Sistem Numarası ve İstemci Kimliği gerekir. SAP kullanıcı adı ve parolası için güvenli kimlik bilgisi yönetimi kullanın.
- Önemli filtreler: Veri hacmini sınırlamak için kaynakta Şirket Kodu (BKPF.BUKRS) ve Mali Yıl (BKPF.GJAHR) filtrelerini mutlaka uygulayın. Belirli bir veri çıkarma dönemi tanımlamak için Belge Oluşturma Tarihi (BKPF.CPUDT) filtresini kullanmanız önemle tavsiye edilir; örneğin son 6 ay.
- Tarih aralığı seçimi: İlk yükleme için 3 ila 6 ay gibi temsil edici bir dönem seçin. Sonraki delta yüklemelerinde yalnızca yeni kayıtları almak için
CPUDTgibi bir zaman damgası alanını eşik değer olarak kullanın. - Performansla ilgili noktalar: BSEG, CDPOS ve iş akışı tablolarındaki birleştirmeler çok yavaş olabilir. Mümkün olduğunda ETL aracınızın filtreleri SAP kaynağında uyguladığından emin olun. Araç destekliyorsa, özellikle geçmiş verilerin büyük hacimli ilk yüklemelerinde verileri daha küçük parçalar veya paketler hâlinde çıkarın.
- İş akışı özelleştirmesi: 'Onaylandı' veya 'Reddedildi' gibi iş akışı etkinliklerini belirleme mantığı, kullandığınız iş akışı şablonlarına büyük ölçüde bağlıdır. Filtrelerde kullanmak üzere sisteminizdeki doğru iş akışı görevi kimliklerini ve kullanıcı karar anahtarlarını belirlemeniz gerekir.
Örnek sorgu sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Başlamaya hazır mısınız?
Kayıttan raporlamaya - yevmiye kaydı için Process Mining çalışmalarınıza bu veri Templateiyle başlayın. Daha derin içgörüler edinin ve mali operasyonlarınızda verimliliği artırın.
Kayıttan raporlamaya - yevmiye kaydı sürecinizi şimdi iyileştirin
Yevmiye kaydı çevrim süresini %30 azaltın ve hatasız raporlama sağlayın.
Kredi kartı gerekmez, iyileştirmeye bugün başlayın.