Kayıttan Raporlamaya - yevmiye kaydı Veri Templateiniz
Kayıttan Raporlamaya - yevmiye kaydı Veri Templateiniz
- Ayrıntılı analiz için önerilen öznitelikler
- İzlenecek temel yevmiye kaydı etkinlikleri
- SAP ECC için pratik veri çıkarma yönlendirmeleri
Kayıttan Raporlamaya - Yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Etkinlik adı ActivityName | Journal entry sürecinin belirli bir noktasında gerçekleşen iş etkinliğinin veya olayın adı. | ||
| Açıklama Etkinlik Adı, yevmiye kaydı yaşam döngüsündeki Journal Entry Created, Journal Entry Approved veya Journal Entry Posted gibi belirli bir adımı tanımlar. Bu öznitelik genellikle SAP içindeki birden fazla kaynaktan, örneğin işlem kodlarından (TCODE), değişiklik belgesi günlüklerinden (CDHDR ve CDPOS tabloları) ve belge durum alanlarından elde edilir. Etkinlikleri analiz etmek, Process Mining çalışmalarının temelini oluşturur. Süreç haritalarını görselleştirmenize, adımlar arasındaki geçiş sürelerini hesaplamanıza ve yeniden çalışma döngülerini, örneğin Journal Entry Rejected sonrasında Journal Entry Corrected gelmesini, belirlemenize olanak tanır. 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ştirmenizi, analiz etmenizi ve optimize etmenizi sağlar. Nereden alınır? BKPF içindeki işlem kodları (TCODE), belge durumu ve SWW_WI2OBJ gibi tablolardaki Workflow günlükleri veya CDHDR ve CDPOS içindeki değişiklik belgeleri dahil olmak üzere çeşitli kaynaklardan türetilir. Örnekler Journal Entry oluşturulduJournal Entry onaylandıJournal Entry reddedildiJournal Entry kaydedildi | |||
| Olay zamanı EventTime | Journal entry kaydı için belirli bir etkinliğin veya olayın gerçekleştiği anı gösteren zaman damgası. | ||
| Açıklama Olay Zamanı, journal entry sürecindeki her etkinlik için kesin tarih ve saati sağlar. Bu veri, döngü süreleri, işlem süreleri ve adımlar arasındaki gecikmeler gibi zamana dayalı tüm metrikleri hesaplamak için önemlidir. Bu 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ın temelini oluşturmak için kullanılır. Ortalama Journal Entry Döngü 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ı, zamanla ilgili tüm analizlerin temelini oluşturur ve döngü sürelerini, süreleri ve darboğazları hesaplamanızı sağlar. Nereden alınır? Etkinliğe göre farklı alanlardan, özellikle BKPF içindeki oluşturma zaman damgasından (CPUDT, CPUTM) veya CDHDR içindeki değişiklik belgesi zaman damgalarından (UDATE, UTIME) alınır. Örnekler 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Yevmiye kaydı ID'si JournalEntryId | Şirket kodu, belge numarası ve mali yılı birleştiren, mali muhasebe belgesinin benzersiz tanımlayıcısıdır. | ||
| Açıklama Journal Entry ID, bir journal entry kaydının yaşam döngüsünü izlemek için kullanılan birincil vaka tanımlayıcısıdır. SAP sisteminin tamamında benzersizliği sağlamak için genellikle Şirket Kodu (BUKRS), Belge Numarası (BELNR) ve Mali Yıl (GJAHR) alanlarının birleştirilmesiyle oluşturulan bileşik bir anahtardır. Süreç analizinde bu ID, oluşturma, park etme, gönderme, onay, ret ve kayıt gibi ilgili tüm etkinlikleri birbirine bağlar. Bu tanımlayıcıyı izleyerek her journal entry kaydının uçtan uca yolculuğunu oluşturabilir, döngü sürelerini ölçebilir ve belirli kayıtlar için süreç sapmalarını veya darboğazları belirleyebilirsiniz. Neden önemli? Bu, bir journal entry kaydını oluşturulmasından son kaydına kadar izlemek için gerekli anahtardır. Uçtan uca süreç analizi ve varyant karşılaştırması yapmanızı sağlar. Nereden alınır? Bu, genellikle BKPF tablosundaki Şirket Kodu (BUKRS), Belge Numarası (BELNR) ve Mali Yıl (GJAHR) alanlarının birleştirilmesiyle oluşturulan türetilmiş 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 işlemi sırasında eklenen sabit bir değerdir. Basit görünse de bu öznitelik, birden fazla ERP veya veri kaynağının bulunduğu ortamlarda önemlidir. Veri soyunun net olmasını sağlar ve analizi kaynak sisteme göre filtrelemenize veya bölümlere ayırmanıza imkan verir. Neden önemli? Veri soyunu net biçimde gösterir ve özellikle birden fazla kaynak sistemin bulunduğu ortamlarda veri kalitesini izlemek için gereklidir. Nereden alınır? Bu, genellikle veri dönüştürme işlemi sırasında eklenen ve belirli SAP ECC örneğini (ör. 'ECC_PROD_100') tanımlayan sabit bir değerdir. Ö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 sisteminden en son veri çekiminin tarih ve saatini kaydeder. Analiz edilen verinin güncelliğini anlamak için önemli olan bir meta veri alanıdır. Her Process Mining Dashboardunda veya analizinde son güncelleme zamanını bilmek, kullanıcıların veriye güvenmesi ve bilinçli kararlar alması açısından önemlidir. Bu bilgi, "Bu bilgiler ne kadar güncel?" sorusunu yanıtlamaya yardımcı olur. Neden önemli? Kullanıcılara verilerin güncelliği hakkında bilgi verir. Böylece analiz dönemini anlayabilir ve sonuçlara güvenebilirler. Nereden alınır? Veri yenilendiği sırada veri çıkarma aracı veya ETL süreci tarafından oluşturulan ve saklanan bir meta veri alanıdır. Örnekler 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Belge türü DocumentType | Muhasebe belgelerinin nasıl işlendiğini ve saklandığını belirleyen sınıflandırma. | ||
| Açıklama Belge Türü, genel muhasebe 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, süreci işlemin niteliğine göre bölümlere ayırmanıza olanak tanıdığı için analiz açısından büyük önem taşır. Türüne Göre Yevmiye Kaydı İşlem Hacmi Dashboardu ve Yevmiye Kaydı Türüne Göre Ortalama Çevrim Süresi temel performans göstergesi doğrudan bu alana bağlıdır. Bazı kayıt türlerinin gecikmeye, yeniden çalışmaya veya ters kayda daha yatkın olup olmadığını ortaya çıkarmanıza yardımcı olur. Neden önemli? Analizi işlem türüne göre bölümlendirmenizi ve süreç sorunlarının belirli journal entry türlerine özgü olup olmadığını belirlemenizi sağlar. Nereden alınır? BKPF belge başlığı tablosunda, BLART alanında bulunur. Örnekler SAKRREAA | |||
| İşlem kodu TransactionCode | Journal entry kaydını oluşturmak veya işlemek için kullanılan SAP işlem kodu. | ||
| Açıklama İşlem Kodu (T-Code), SAP içindeki belirli bir işlev veya program için kullanılan benzersiz tanımlayıcıdır. Yevmiye kayıtlarında kaydın nasıl oluşturulduğunu gösterir. Örneğin kayıt manuel olarak (FB01, F-02), park etme yoluyla (FV50) veya otomatik bir arayüz üzerinden oluşturulmuş olabilir. Bu öznitelik, Manuel Etkinlik Optimizasyonu Dashboardu için çok değerlidir. T-Code analiz edilerek manuel ve otomatik etkinlikler birbirinden ayrılabilir, en fazla zaman alan manuel süreçler belirlenebilir ve manuel çabayı azaltıp verimliliği artıracak otomasyon fırsatları ortaya çıkarılabilir. 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ığı tablosunda, TCODE alanında bulunur. Örnekler FB01F-02FV50FBD1 | |||
| Kayıt tarihi PostingDate | İşlemin genel deftere kaydedildiği ve 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ış takvimleri ve mevzuatla uyumlu olması gerektiğinden, finans ve uyumluluk açısından önemli bir tarih alanıdır. Process Mining çalışmalarında bu tarih uyumluluğu izlemek için kullanılır. Uyumluluk Uyum İzleme Dashboardu ve Uyumluluk Uyum Oranı temel performans göstergesi, kayıtların doğru dönem içinde sisteme alınıp alınmadığını kontrol etmek için bu öznitelikten yararlanır. Ayrıca yevmiye kaydı hacimlerindeki zaman içindeki eğilimleri analiz etmek için de kullanılabilir. Neden önemli? Finansal raporlama ve uyumluluk analizi için önemlidir; kayıtların doğru muhasebe döneminde oluşturulmasını sağlar. Nereden alınır? BKPF belge başlığı tablosunda, BUDAT alanında bulunur. Örnekler 2023-10-312023-11-302024-01-15 | |||
| Kullanıcı User | Journal entry kaydını oluşturan veya değiştiren kişinin SAP kullanıcı ID'si. | ||
| Açıklama Bu öznitelik, bir belgeyi oluşturma, park etme veya sisteme alma gibi belirli bir etkinlikten sorumlu SAP kullanıcı adını kaydeder. Bilgi doğrudan belge üst bilgisinden veya değişiklik günlüğü tablolarından alınır. Kullanıcı özniteliğini analiz etmek, ekip ve kişi performansını anlamanın temel yollarından biridir. Kullanıcı Verimliliği Dashboardunu destekleyerek kullanıcı başına etkinlik hacimlerini ve işlem sürelerini izler. Ayrıca yeniden çalışma döngülerine, ters kayıtlara veya uyumluluk sapmalarına kimlerin dahil olduğunu belirlemenize ve hedefli eğitimler ya da süreç iyileştirmeleri planlamanıza yardımcı olur. Neden önemli? Her etkinlikten sorumlu kullanıcıyı belirler ve kullanıcı performansını, iş yükü dağılımını ve yeniden işleme örüntülerini analiz etmenizi sağlar. Nereden alınır? Genellikle oluşturan kişi için BKPF tablosundaki USNAM alanından veya değişikliği yapan kişi için CDHDR tablosundaki USERNAME alanından alınır. Örnekler ABROWNCJONESDSMITH | |||
| Şirket kodu CompanyCode | Finansal tabloların hazırlandığı bağımsız tüzel kişiyi temsil eden organizasyon birimi. | ||
| Açıklama Şirket Kodu, SAP Financials içindeki temel organizasyon birimlerinden biridir. Tüzel olarak bağımsız bir şirketi temsil eder ve journal entry belgesinin başlığındaki temel alanlardan biridir. Bu öznitelik, süreç analizini tüzel kişiye 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ına özgü olup olmadığını ortaya çıkarabilir. Neden önemli? Kuruluş içindeki farklı tüzel kişiler veya iş birimleri arasında süreç performansını filtrelemenizi ve karşılaştırmanızı sağlar. Nereden alınır? BKPF belge başlığı tablosunda, BUKRS alanında bulunur. Örnekler 10002000US01DE01 | |||
| Ters kaydı var mı IsReversed | Journal entry kaydının ters kaydının oluşturulup oluşturulmadığını gösteren boolean işareti. | ||
| Açıklama Bu işaret, daha sonra başka bir muhasebe belgesiyle ters kayda alınan yevmiye kayıtlarını belirler. SAP içinde ters kayda alınan belge, ters kayıt belgesiyle ilişkilendirilir ve açık bir denetim izi oluşturur. Bu öznitelik, Yevmiye Kaydı Ters Kayıt Analizi Dashboardu ve Yevmiye Kaydı Ters Kayıt Oranı temel performans göstergesi için temel oluşturur. Ters kayda alınan 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? Daha sonra geri alınan kayıtları işaretleyerek ters kayıt analizini doğrudan destekler; hata nedenlerini belirlemenize ve veri bütünlüğünü iyileştirmenize yardımcı olur. Nereden alınır? BKPF tablosundaki Ters Kayıt Belge Numarası alanından (STBLG) türetilir. STBLG boş değilse işaretin değeri doğrudur. Örnekler truefalse | |||
| Masraf yeri CostCenter | Maliyetlerin oluştuğu konumu temsil eden ve bir controlling alanı içindeki organizasyon birimidir. | ||
| Açıklama Masraf yeri, Controlling (CO) modülündeki temel ana veri unsurlarından biridir ve genellikle yevmiye kaydının kalem düzeyinde atanır. Belirli bir departman, işlev veya konuma ait maliyetleri izlemek için kullanılır. Masraf yerinin dahil edilmesi, yevmiye kaydı sürecinin daha ayrıntılı analiz edilmesini sağlar. Belirli departmanların daha fazla yeniden işleme oluşturup oluşturmadığını, daha uzun çevrim sürelerine sahip olup olmadığını veya daha fazla manuel kayıt üretip üretmediğini belirlemeye yardımcı olabilir. Böylece süreç verimliliği departman bazında incelenebilir. Neden önemli? Süreç performansının departman veya işlev alanına göre analiz edilmesini sağlar ve yerel verimsizliklerin belirlenmesine yardımcı olur. Nereden alınır? Belge kalem tablosu BSEG'de, KOSTL alanında bulunur. Örnekler 4100CC_FINANCE_US10010101 | |||
| Onay süresi ApprovalTime | Bir yevmiye kaydının onaya gönderilmesiyle onaylanması veya reddedilmesi arasında geçen süredir. | ||
| Açıklama Bu metrik, genellikle toplam çevrim süresine önemli katkıda bulunan onay alt sürecinin süresini ölçer. Journal Entry Submitted etkinliği ile buna karşılık gelen Journal Entry Approved veya Journal Entry Rejected etkinliği arasındaki zaman farkı olarak hesaplanır. Onay Süresi, Yevmiye Kaydı Onay Performansı Dashboardunun ve Ortalama Yevmiye Kaydı Onay Süresi temel performans göstergesinin ana metriğidir. Bu süreyi analiz ederek onay iş akışındaki darboğazları belirleyebilir, onaylayanların performansını ölçebilir ve onay eşiklerini ayarlamak gibi süreç değişikliklerini gerekçelendirebilirsiniz. Neden önemli? Onay aşamasının süresini ölçer ve inceleme ile onay iş akışındaki gecikmeleri belirleyip gidermenize yardımcı olur. Nereden alınır? 'Yevmiye Kaydı Gönderildi' olayının zaman damgası, 'Yevmiye Kaydı Onaylandı' veya 'Yevmiye Kaydı Reddedildi' olayının zaman damgasından çıkarılarak hesaplanır. Örnekler P1DT2HPT4H15MP3D | |||
| Para birimi anahtarı CurrencyKey | Journal entry kaydındaki tutarlar için kullanılan para birimi kodu. | ||
| Açıklama Bu öznitelik, journal entry kaydının para birimini, örneğin USD, EUR veya JPY'yi belirtir. Belgeyle ilişkili finansal tutarlar için bağlam sağlar. Her zaman birincil analiz boyutu olmasa da parasal değerlerin doğru yorumlanması için gereklidir. Ayrıca küresel kuruluşlarda yabancı ve yerel para birimlerindeki kayıtların süreçlerinin farklı olup olmadığını görmek için analizi bölümlere ayırmak amacıyla kullanılabilir. Neden önemli? Tüm parasal değerler için gerekli bağlamı sağlar ve doğru finansal analiz ile yorumlamayı destekler. Nereden alınır? BKPF belge başlığı tablosunda, WAERS alanında bulunur. Örnekler USDEURGBPJPY | |||
| Park edildi mi IsParked | Yevmiye kaydının kaydedilmeden önce park edilmiş belge olarak saklanıp saklanmadığını gösteren boolean işaretidir. | ||
| Açıklama Bir belgenin park edilmesi, kullanıcının tamamlanmamış bir yevmiye kaydını mali bakiyeleri etkilemeden kaydetmesine olanak tanır. Kayıt daha sonra başka bir kullanıcı tarafından tamamlanabilir veya incelenebilir ve ardından post edilebilir. Bu işaret, park etme adımından geçen kayıtları belirler. Bu özniteliğin analizi, park etme özelliğinin nasıl kullanıldığını anlamaya yardımcı olur. Park etmenin gayriresmî bir inceleme adımı olarak kullanılıp kullanılmadığını ve bunun gecikmelere yol açıp açmadığını ortaya çıkarabilir. Uçtan uca çevrim süresinin analizini destekler ve doğrudan post edilen kayıtlarla önce park edilen kayıtları birbirinden ayırır. Neden önemli? Park etme özelliğini kullanan kayıtları belirler. Bu durum gecikme kaynağı olabilir veya gayriresmî bir inceleme sürecine işaret edebilir. Nereden alınır? BKPF tablosundaki belge durum alanından (BSTAT) türetilir. 'V' değeri, park edilmiş belgeyi gösterir. Örnekler truefalse | |||
| Ters kayıt nedeni ReversalReason | Bir journal entry kaydının neden tersine çevrildiğini gösteren kod. | ||
| Açıklama Bir belge ters kayda alındığında SAP, kullanıcının bir neden kodu belirtmesine olanak tanır. Bu kod, ters kaydın neden gerekli olduğuna ilişkin yapılandırılmış bilgi sağlar. Örneğin yanlış kayıt tarihi veya veri giriş hatası gibi nedenler belirtilebilir. Bu öznitelik, Yevmiye Kaydı Ters Kayıt Analizi Dashboardu için önemli bir girdidir. En yaygın ters kayıt nedenlerini analiz ederek süreçlerdeki sistemik sorunları veya eğitim eksiklerini belirleyebilir, gelecekteki hataları önlemek ve ters kayıt oranını azaltmak için hedefli adımlar atabilirsiniz. Neden önemli? Ters kayıtların neden gerçekleştiğine ilişkin doğrudan içgörü sağlar. Böylece gelecekteki hataları azaltmak için hedefli kök neden analizi yapılabilir. Nereden alınır? Belge üst bilgisi tablosu BKPF'de, STGRD alanında bulunur. Örnekler 010205 | |||
| Toplam belge tutarı TotalDocumentAmount | Journal entry kaydının belge para birimindeki toplam değeri. | ||
| Açıklama Bu öznitelik, journal entry 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 farklı ve daha sıkı bir onay yolundan geçebilir. Bu öznitelik, döngü sürelerinin, ret oranlarının veya onay gecikmelerinin kayıt tutarıyla ilişkili olup olmadığını görmek için analizi filtrelemenizi veya bölümlere ayırmanızı sağlar. Neden önemli? İşlem sürelerini veya ret oranlarını journal entry kayıtlarının parasal değeriyle ilişkilendirmek gibi finansal etki analizleri yapmanızı sağlar. Nereden alınır? Bu, belirli bir journal entry kaydı için BSEG tablosundaki tüm kalemlerin tutar alanlarının (WRBTR veya DMBTR) toplanmasıyla elde edilen hesaplanmış bir alandır. Örnekler 1500.0025000.75125.50 | |||
| Yeniden işleme yapıldı mı IsRework | Bir yevmiye kaydının reddedilip düzeltilmesi gibi bir yeniden işleme döngüsünden geçip geçmediğini gösteren boolean işaretidir. | ||
| Açıklama Bu işaret, ideal yoldan sapan ve düzeltici işlem gerektiren vakaları belirler. Belirli bir yevmiye kaydı için Journal Entry Rejected sonrasında Journal Entry Corrected gibi bir etkinlik dizisi gözlemlendiğinde genellikle true olarak ayarlanır. Bu öznitelik, Yevmiye Kaydı Yeniden Çalışma Oranı temel performans göstergesini 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 belgeler gibi yeniden çalışmanın temel nedenlerini incelemenize yardımcı olur. Neden önemli? Düzeltme gerektiren kayıtları işaretler. Böylece yeniden işleme ölçülebilir ve ilk seferde doğru sonuç oranını artırmak için kök nedenler analiz edilebilir. Nereden alınır? Bu, bir vaka için etkinlik dizisinin analiz edilmesiyle türetilen hesaplanmış bir özniteliktir. Bir ret veya düzeltme etkinliği gerçekleştiğinde yeniden işleme döngüsü belirlenir. Örnekler truefalse | |||
Kayıttan Raporlamaya - Yevmiye kaydı faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Journal Entry gönderildi | Bu etkinlik, park edilmiş bir journal entry kaydının oluşturan kişi tarafından tamamlandığını ve artık inceleme ile onaya hazır olduğunu gösterir. Genellikle park edilmiş belgeyle ilişkili bir SAP Business Workflow görevinin başlatılmasıyla kaydedilir. | ||
| Neden önemli? Bu etkinlik, kaydı oluşturan kişi ile onaylayan arasındaki devir teslimi gösterir ve onay çevrim süresi temel performans göstergeleri için süreci başlatır. Onay iş akışının verimliliğini ölçmek açısından önemli bir kilometre taşıdır. Nereden alınır? Mali belge nesnesiyle ilişkili onay Workflow örneğinin başlangıç zamanından çıkarılır. Bunun için SWW_WI2OBJ gibi Workflow günlük tabloları analiz edilerek belirli şirket kodu, belge numarası ve mali yıl için başlatılan Workflow bulunmalıdır. Yakalayın Park edilmiş belge nesnesi için Workflow başlangıç olayını belirleyin. Olay türü inferred | |||
| Journal Entry kaydedildi | Bu, journal entry kaydının genel deftere resmi olarak işlendiği ve finansal tabloları etkilediği temel etkinliktir. Belge durumu 'posted' olarak ayarlandığında ve bir kayıt tarihi atandığında açıkça kaydedilir. | ||
| Neden önemli? Bu, journal entry kaydının başarıyla işlendiğini gösteren en önemli kilometre taşıdır. Uçtan uca döngü süresi çoğu zaman bu noktaya kadar ölçülür ve finansal kapanış analizinde önemli bir olaydır. Nereden alınır? BKPF tablosundaki bir belgede kayıt tarihi, BKPF-BUDAT bulunduğunda belirlenir. Park edilmiş belgelerde bu, BKPF-BSTAT durumunun 'V' değerinden boş değere değiştiği ana karşılık gelir. Kaydın zaman damgası, giriş tarihi olan BKPF-CPUDT alanıdır. Yakalayın BKPF-BSTAT değerinin 'V' değerinden boş değere değiştiği anı veya doğrudan kayıtlar için oluşturma olayını belirleyin. Olay türü explicit | |||
| Journal Entry onaylandı | Bu etkinlik, bir journal entry kaydının Workflow içindeki son onayını gösterir ve kaydın oluşturulmasına uygun hale gelmesini sağlar. Workflow günlüğünde son 'release' veya 'approve' 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ği için önemli bir KPI'dır. Bu olaydan kaydın oluşturulmasına kadar geçen süre ise onay sonrası gecikmeyi ölçer. Nereden alınır? SAP Business Workflow günlüğündeki son onay adımının tamamlanma zaman damgasından çıkarılır. Bu, belge kaydedilmeden veya kayda hazır hale gelmeden önceki son onay işlemidir. Yakalayın Workflow günlüklerinde son 'release' veya 'approve' adımının tamamlanmasını belirleyin. Olay türü inferred | |||
| Journal Entry park edildi | Bu etkinlik, bir journal entry kaydının genel deftere resmi olarak kaydedilmeden önceki ilk ve geçici durumdaki oluşturulmasını gösterir. SAP'te bir kullanıcı, parking işlemi kullanarak belgeyi kaydettiğinde ve belge durumunu 'parked' olarak ayarladığında açıkça kaydedilir. | ||
| Neden önemli? Bu, inceleme ve onay içeren süreçler için önemli bir başlangıç olayıdır. Park etme ile kayıt oluşturma arasındaki süreyi analiz etmek, kayıt öncesi ve onay aşamalarındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? Bu olay, BKPF belge başlığı tablosundan belirlenir. Bir belge, BKPF-BSTAT = 'V' durumuyla oluşturulduğunda park edilmiş kabul edilir. Olayın zaman damgası, oluşturulma tarihi ve saati olan BKPF-CPUDT ve BKPF-CPUTM alanlarından alınır. Yakalayın BKPF-BSTAT değerinin 'V' olduğu BKPF kayıtlarında belge oluşturma olayını belirleyin. Olay türü explicit | |||
| Journal Entry ters kaydı işlendi | Bu etkinlik, daha önce kaydedilmiş bir journal entry kaydının ters kaydını gösterir. Ters kayıt, ilk kaydı iptal eden yeni bir muhasebe belgesidir. | ||
| Neden önemli? Bu, veri kalitesini ve süreç doğruluğunu ölçmek için önemli bir olaydır. Ters kayıt oranının yüksek olması, ilk veri girişi veya onay aşamalarındaki sistemik sorunlara işaret eder. Her ters kayıt, yeniden işleme anlamına gelir. Nereden alınır? Bu olay, ilk belgenin başlığındaki BKPF tablosunda belirlenir. Bir belge için ters kayıt oluşturulduğunda 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. Yakalayın İlk belgede BKPF-STBLG alanının doldurulduğu anı belirleyin. Zaman damgası, ters kayıt belgesinin kayıt tarihidir. Olay türü explicit | |||
| Dokümantasyon eklendi | Bu etkinlik, bir kullanıcının fatura veya hesap tablosu gibi destekleyici belgeleri journal entry kaydına eklemesini gösterir. Bu olay, standart bir muhasebe olayı olarak açıkça kaydedilmez. Genellikle muhasebe belgesi nesnesine bağlı eklerin oluşturulması kontrol edilerek çıkarılır. | ||
| Neden önemli? Bu etkinliği izlemek, dokümantasyon gerektiren politikalara uyumu doğrulamaya yardımcı olur. Belgelerin eklenmesindeki gecikmeler, uzayan onay döngülerinin temel nedenlerinden biri olabilir. Nereden alınır? Bu olayı zaman damgalı bir olay olarak güvenilir biçimde yakalamak zordur. Ek oluşturma zaman damgası, SOOD gibi Generic Object Services (GOS) ek tabloları analiz edilerek ve journal entry nesne anahtarıyla ilişkilendirilerek çıkarılabilir. Yakalayın GOS tablolarındaki (ör. SOOD) bağlı nesnelerin oluşturulma zaman damgasından çıkarın. Olay türü inferred | |||
| Journal Entry değişikliği istendi | Bu olay, bir onaylayanın journal entry kaydını inceleyip düzeltme yapılması için oluşturan kişiye geri gönderdiği Workflow aşamasını gösterir. Workflow günlüklerinde 'rejection' veya 'send back' kullanıcı kararı görüldüğünde kaydedilir. | ||
| Neden önemli? Bu etkinlik, verimsizliğin ve süreç sapmasının başlıca kaynaklarından olan yeniden işleme döngülerini belirlemek için gereklidir. Bu olayın sık görülmesi, kayıt kalitesiyle veya gerekliliklerin net olmamasıyla ilgili sorunlara işaret eder. Nereden alınır? Bu olay, SAP Business Workflow günlüğünde 'reject' veya 'send for correction' işlemine karşılık gelen belirli kullanıcı kararı adımının zaman damgasından çıkarılır. Yakalayın Workflow günlüklerinde 'rejection' veya 'rework' kararının zaman damgasını belirleyin. Olay türü inferred | |||
| Journal Entry düzeltildi | Bu etkinlik, oluşturan kişinin değişiklik yapılması için geri gönderilen park edilmiş journal entry kaydını değiştirdiğini gösterir. 'Changes Requested' olayından sonra belgede yapılan değişiklikler tespit edilerek çıkarılır. | ||
| Neden önemli? Düzeltmeleri izlemek, yeniden işleme için harcanan çabayı ölçmeye yardımcı olur. Değişiklik talebi ile düzeltme arasındaki süre, gönderilen kayıtlardaki sorunların çözümünde yaşanan gecikmeleri gösterir. Nereden alınır? Park edilmiş belgeye ait değişiklik belgesi günlükleri, CDHDR ve CDPOS tabloları analiz edilerek çıkarılır. İş akışındaki bir ret olayından sonra kaydedilen değişiklik, düzeltme yapıldığını gösterir. Zaman damgası CDHDR tablosundan alınır. Yakalayın Ret olayından sonra CDHDR/CDPOS içindeki değişiklik günlüğü kaydını belirleyin. Olay türü inferred | |||
| Journal Entry kalemi kapatıldı | Bu etkinlik, banka takas hesabı gibi açık kalem yönetimli bir G/L hesabı kaleminin mutabakatını gösterir. Bir kalem başka bir kalemle eşleştirildiğinde ve kapatıldığında gerçekleşir. | ||
| Neden önemli? Banka mutabakatı gibi süreçlerde kalemlerin kapatılma süresi önemli bir KPI'dır. Bu etkinlik, mutabakatın 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. Yakalayın Bir kalem için kapatma tarihi (BSEG-AUGDT) alanının doldurulduğu anı belirleyin. Olay türü explicit | |||
| Journal Entry oluşturuldu | Bir parking adımı olmadan doğrudan kaydedilen journal entry kaydının oluşturulmasını gösterir. SAP'te bir belge doğrudan kayıt işlemi kullanılarak oluşturulduğunda 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ıtlarla daha karmaşık park edilmiş kayıtları ayırt etmenize yardımcı olur. Nereden alınır? Bu olay, BKPF tablosunda belge durumu BKPF-BSTAT alanının boş olduğu belge oluşturma işlemine karşılık gelir. Olayın zaman damgası, oluşturulma tarihi olan BKPF-CPUDT alanıdır. Bu belgelerde 'Created' ve 'Posted' olayları aynı anda gerçekleşir. Yakalayın BKPF-BSTAT alanının boş olduğu BKPF kayıtlarında belge oluşturma olayını belirleyin. Olay türü explicit | |||
| Journal Entry reddedildi | Bu etkinlik, bir yevmiye kaydının son kez reddedildiğini gösterir. Bu noktadan sonra kayıt sisteme alınmaz. Genellikle onay iş akışındaki terminal durumdur ve sonunda park edilmiş belgenin silinmesine yol açar. | ||
| Neden önemli? Retleri izlemek kalite yönetimi açısından büyük önem taşır. Ret nedenlerini ve sıklığını analiz etmek, journal entry kayıtlarının ilk seferde doğru olma oranını artırmaya yardımcı olur. Nereden alınır? Bu sonuç, süreci sonlandıran nihai 'reject' kullanıcı kararını temsil eder ve SAP Business Workflow günlüğünden alınır. Park edilmiş belge daha sonra silinebilir. Yakalayın Belge için Workflow günlüğündeki terminal 'reject' durumunu belirleyin. Olay türü inferred | |||
| Manuel giriş belirlendi | Bu etkinlik, bir journal entry kaydının otomatik arayüz veya toplu işlem yerine manuel çevrim içi işlemle oluşturulup oluşturulmadığını belirler. Bu bir kullanıcı işlemi değil, sistem verilerinden türetilen hesaplanmış bir özniteliktir. | ||
| Neden önemli? Manuel ve otomatik kayıtları ayırt etmek, hedefli süreç iyileştirmeleri için önemlidir. Manuel süreçler genellikle standardizasyon ve otomasyon çalışmalarının odağındadır. Nereden alınır? Bu değer, BKPF belge başlığı tablosundaki alanlar analiz edilerek hesaplanır. 'FB01', 'FB50' veya 'FV50' gibi işlem kodları (BKPF-TCODE) manuel girişi gösterirken diğer T-Code değerleri veya belirli toplu giriş adları (BKPF-AWKEY) otomasyona işaret eder. Yakalayın BKPF-TCODE veya belge başlığındaki diğer kaynak sistem göstergelerinden türetin. Olay türü calculated | |||
| Park edilmiş Journal Entry silindi | Hiç kaydedilmemiş park edilmiş bir journal entry kaydının silinmesini gösterir. Bu durum bir ret sonrasında veya kayıt hatalı oluşturulduğunda gerçekleşebilir. | ||
| Neden önemli? Bu etkinlik, sürecin başarısız bir şekilde sona erdiğini gösterir. Park edilmiş 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 park edilmiş belgenin durumu değiştirildiğinde kaydedilir. BKPF-BSTAT durum alanı 'Z' değerine, yani 'Parked document deleted' durumuna güncellenir. Değişiklik zaman damgası belge değişiklik günlüklerinde, CDHDR tablosunda bulunabilir. Yakalayın BKPF-BSTAT alanının 'Z' değerine güncellendiği anı belirleyin. Olay türü explicit | |||
| Şirketler arası kayıt belirlendi | Birden fazla şirket kodunu etkileyen journal entry kaydını işaretleyen hesaplanmış bir etkinliktir. Tek bir mali belgenin kalemleri analiz edilerek belirlenir. | ||
| Neden önemli? Şirketler arası işlemler daha karmaşık işleme ve onay gerekliliklerine sahip olabilir. Bunları belirlemek, benzersiz darboğazları bulmak için döngü sürelerini ve süreç yollarını ayrı ayrı analiz etmenizi sağlar. Nereden alınır? Belirli bir belge numarası (BELNR) için BSEG kalem tablosu incelenerek hesaplanır. Kalemlerde birden fazla farklı şirket kodu (BSEG-BUKRS) varsa kayıt, şirketler arası kayıt olarak kabul edilir. Yakalayın Tek bir BKPF-BELNR için birden fazla benzersiz BSEG-BUKRS değeri olup olmadığını kontrol edin. Olay türü calculated | |||
Çı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 girin ve Create seçeneğine tıklayın. Uygun bir başlık belirtin ve program türünü 'Executable Program' olarak ayarlayın.
- Seçim ekranını tanımlayın: Program kaynak kodunda seçim ekranını tanımlayın. Bu ekran, kullanıcıların veri hacmini sınırlamak için belge oluşturma tarih aralığı, şirket kodları ve belge türleri gibi parametreleri belirtmesine olanak tanır.
- Veri yapılarını bildirin: Nihai Event Log verilerini tutacak bir dahili tablo yapısı tanımlayın. Bu yapı, gerekli tüm alanları, JournalEntryId, ActivityName, EventTime, SourceSystem ve LastDataUpdate ile User, CompanyCode ve PostingDate gibi önerilen öznitelikleri içermelidir.
- Veri seçme mantığını uygulayın: Gerekli 14 etkinliğin her biri için temel ABAP SQL sorgularını yazın. Bu işlem, BKPF (Header) ve BSEG (Line Item) gibi birincil tablolardan, CDHDR ve CDPOS değişiklik günlüğü tablolarından, SWWLOGHIST gibi Workflow tablolarından ve BSAS ile BSAK gibi clearing tablolarından veri seçilmesini içerir.
- Park edilmiş ve post edilmiş belgeleri çıkarın: 'Yevmiye Kaydı Park Edildi' olayları için BSTAT belge durumunun 'V' olduğu BKPF kayıtlarını seçin. 'Yevmiye Kaydı Oluşturuldu' ve 'Yevmiye Kaydı Post Edildi' olayları için durumun boş olduğu, yani normal ve post edilmiş belgeyi gösteren BKPF kayıtlarını seçin.
- Değişiklik ve silme olaylarını çıkarın: 'BELEG' nesne sınıfı için CDHDR ve CDPOS değişiklik belgesi tablolarını sorgulayın. 'Yevmiye Kaydı Düzeltildi' veya 'Park Edilmiş Yevmiye Kaydı Silindi' etkinliklerine karşılık gelen değişiklikleri bulmak için belge anahtarına göre filtre uygulayın.
- Workflow olaylarını çıkarın: 'Yevmiye Kaydı Gönderildi', 'Onaylandı', 'Reddedildi' ve 'Değişiklik İstendi' gibi etkinlikleri yakalamak için Workflow tablolarını sorgulayın. Muhasebe belgesini bir Workflow ö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 tablosunu okuyun.
- Hesaplanmış olayları belirleyin: 'Manuel Kayıt Belirlendi' için işlem kodunu (BKPF-TCODE) bilinen manuel kayıt t-code'ları listesiyle karşılaştırın. 'Şirketler Arası Kayıt Belirlendi' için belirli bir belgenin BSEG kalemlerini analiz ederek birden fazla şirket kodunun dahil olup olmadığını kontrol edin.
- Verileri birleştirin ve dönüştürün: Her etkinliğin verileri seçildikçe bunları nihai Event Log yapısına dönüştürün. JournalEntryId oluşturmak için Company Code, 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ı nihai dahili tabloya ekleyin.
- Dosya dışa aktarmayı uygulayın: Birleştirilmiş dahili tabloyu SAP uygulama sunucusundaki bir CSV veya düz dosyaya yazmak için OPEN DATASET, LOOP AT, TRANSFER ve CLOSE DATASET gibi ABAP dosya işleme ifadelerini kullanın. Dosya, AL11 işlemi üzerinden görüntülenebilir.
- Arka plan işi olarak planlayın: SM36 işlemine (Define Background Job) gidin. Yeni bir iş oluşturun, ABAP programınızı çalıştıran bir adım tanımlayın ve çıkarma işlemini otomatikleştirmek için yoğun olmayan saatlerde, örneğin her gece veya haftada bir, bir plan belirleyin.
- Dosyayı alın ve biçimlendirin: Oluşturulan dosyayı uygulama sunucusundan yerel bilgisayarınıza indirmek için CG3Y işlemini kullanın veya sistem yöneticinizle birlikte ç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ığı tanımlamanız büyük önem taşır. 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 amacıyla 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 tek seferde çıkarmak sistem kaynaklarını yoğun biçimde tüketebilir. Bir şirket koduyla veya ilgili küçük bir şirket kodu grubuyla 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 kullanabilirsiniz.
- Workflow Task ID'leri: Workflow olaylarını çıkarma mantığı, sisteminizde onay, ret ve gönderim için kullanılan belirli Task ID'lerine bağlıdır. Bu ID'ler, şirketinizin Workflow tanımlarına göre programın kaynak kodunda yapılandırılmalıdır.
- Performansla ilgili hususlar: Program, özellikle CDPOS ve Workflow geçmişi tabloları olmak üzere birçok büyük tabloyu birleştirir. Programın yoğun iş saatlerinde çalıştırılması sistem performansını etkileyebilir. Programı her zaman yoğun olmayan saatlerde çalışacak bir arka plan işi olarak planlayın. Performans sorunu tekrarlanıyorsa ikincil veritabanı indeksleri oluşturmayı değerlendirin.
- Ön koşullar: Bu yöntem, ABAP geliştirme yetkilerine (SE38 için) ve arka plan işleri oluşturma ve yönetme izinlerine (SM36 için) sahip bir kullanıcı gerektirir. Kullanıcının veya işin ilgili tüm finans, Workflow ve sistem tablolarına (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST vb.) okuma erişimi de olmalıdır.
a Ö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 edinin. 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 eksiksiz SQL sorgusunu SQL istemcinize kopyalayın.
- Çıkarma parametrelerini ayarlayın: Çalıştırmadan önce sorgudaki yer tutucuları yapılandırmanız gerekir. '[START_DATE]' ve '[END_DATE]' değerlerini 'YYYYMMDD' biçiminde istediğiniz tarih aralığıyla değiştirin. '[COMPANY_CODE_1]' ve '[COMPANY_CODE_2]' değerlerini analiz etmek istediğiniz SAP şirket kodlarıyla değiştirin.
- Kaynak sistemi tanımlayın: Verilerin kaynağını doğru biçimde belirlemek için ana
SELECTifadesindeki '[Your SAP System ID]' yer tutucusunu gerçek SAP System ID (SID) ile 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 doldurulduğundan emin olmak için döndürülen satırları kısaca tarayın. Çeşitli etkinliklerin bulunduğunu ve
JournalEntryIdileEventTimegibi temel alanların boş olmadığını kontrol edin. - Zaman damgalarını işleyin: Sorgu, tarih ve saat alanlarını
YYYYMMDDHHMMSSdizesinde birleştirir. Sonraki işleminizin 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 uyarlayın. - Verileri dışa aktarın: SQL istemcinizdeki sonuç kümesinin tamamını CSV dosyasına aktarın. Özel karakterlerle ilgili sorunları önlemek için UTF-8 kodlamasını kullandığınızdan emin olun.
- Yüklemeye hazırlayın: Bir 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. Çıkarma işleminin gerçekleştirildiği zamanın zaman damgasını içerenLastDataUpdatesütununu ekleyin. - 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ünde açıklanan 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. Workflow ile ilgili etkinlikler için SWW_WI2OBJ ve SWWLOGHIST tablolarına erişim de gereklidir. 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 büyük önem taşır. Sağlanan sorgu, belge oluşturma tarihine (
BKPF.CPUDT) uygulanan başlangıç ve bitiş tarihi yer tutucularını kullanır. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Varlık filtresi: Veri hacmini yönetmek ve analize odaklanmak 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 kullanabilir, kapsam dışındaki fatura veya ödeme gibi operasyonel belgeleri hariç tutabilirsiniz. - Performansla ilgili hususlar: BSEG ve CDPOS gibi temel tablolara yönelik doğrudan sorgular sistem kaynaklarını yoğun biçimde tüketebilir. Son kullanıcıların sistem performansının etkilenmemesi için bu çıkarmayı yoğun olmayan iş saatlerinde çalıştırmanız önemle önerilir. Tek bir çalıştırmada bir yıldan fazla veriyi çıkarmaktan kaçının.
- Workflow Task ID'leri: Sorgu, '[WF_TASK_ID_SUBMIT]' ve '[WF_TASK_ID_APPROVE]' gibi yer tutucular içerir. Bunlar, sisteminizdeki yevmiye kaydı Workflow yapılandırmasında kullanılan gerçek Task ID'leriyle değiştirilmelidir. Bu ID'leri bir SAP Workflow uzmanıyla birlikte çalışarak veya PFTC işlemindeki teknik Workflow tanımını analiz ederek belirleyebilirsiniz.
a Ö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 sisteminize yeni bir kaynak bağlantısı yapılandırın. Bunun için genellikle uygulama sunucusu ayrıntıları, istemci, sistem numarası ve gerekli RFC yetkilerine sahip özel bir SAP kullanıcısı gerekir.
- Veri kaynaklarını tanımlayın: Çıkarma projenizde gerekli SAP tablolarını veri kaynağı olarak ekleyin. Temel tablolar şunlardır: BKPF (Accounting Document Header), BSEG (Accounting Document Segment), VBSEGK (Parked Document Header), CDHDR (Change Document Header), CDPOS (Change Document Items), SWW_WI2OBJ (Workflow to Object Links), SWWLOGHIST (Workflow Log) ve SRGBTBREL (GOS Attachments ilişkileri).
- Temel olayları çıkarın (Created ve Parked): İlk olayları çıkaracak veri akışını oluşturun. 'Journal Entry Parked' için VBSEGKyi kaynak olarak kullanın. 'Journal Entry Created' için BKPFyi kullanın ve ters kayıt olmayan, başlangıçta park edilmemiş belgeleri filtreleyin. Bunu VBSEGK ile anti-join yaparak gerçekleştirebilirsiniz.
- İş akışı olaylarını çıkarın: İş akışı örneği kimliğini bulmak için nesne anahtarını (şirket kodu + belge numarası + mali yıl) kullanarak BKPFyi SWW_WI2OBJ ile birleştiren bir veri akışı oluşturun. İş akışı görev sonuçlarına ve günlükte kaydedilen kullanıcı kararlarına göre 'Submitted', 'Approved', 'Rejected' ve 'Changes Requested' gibi olayları çıkarmak için bu sonucu SWWLOGHIST ile birleştirin.
- Değişiklik ve silme olaylarını çıkarın: Değişiklikleri belirlemek için CDHDR ve CDPOS tablolarını kullanın. 'Journal Entry Corrected' için park edilmiş belgelerde yapılan değişiklikleri, Object Class 'FIPP' olacak şekilde filtreleyin. 'Parked Journal Entry Deleted' için park edilmiş belgelerin değişiklik günlüklerindeki silme işaretlerini arayın.
- Ek olaylarını çıkarın: 'Documentation Attached' olayını yakalamak için BKPFyi, nesne türü 'BKPF' ve ilişkinin '[Your attachment relationship type]' olduğu 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: 'Journal Entry Line Item Cleared' için mahsup belgesi alanı (AUGBL) dolu olan BSEG kayıtlarını sorgulayın. Olay zamanı, mahsup belgesinin kayıt tarihidir (AUGDT). 'Journal Entry Reversal Processed' için ters kayıt olan, yani ters çevrilen belge alanında (STBLG) değer bulunan belgeleri BKPF tablosunda sorgulayın.
- Hesaplanan olayları türetin: Hesaplanan olaylar için ayrı mantık blokları oluşturun. 'Manual Entry Identified' için BKPFyi manuel işlem kodları listesine (ör. FB01, FB50, F-02) göre filtreleyin. 'Cross-Company Posting Identified' 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 tek olay akışlarının (Created, Parked, Approved vb.) çıktılarını tek bir Event Log tablosunda birleştirmek için ETL aracınızdaki UNION dönüşümünü kullanın. Tüm akışlarda sütun adlarının ve veri türlerinin tutarlı olduğundan emin olun.
- Son şemaya eşleyin: Birleştirilmiş verileri gerekli Event Log yapısına eşleyerek
JournalEntryId,ActivityName,EventTime,Kullanıcıve diğer gerekli ve önerilen ö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: Sürekli çıkarmalar için artımlı yükleme stratejisi yapılandırın. Son çalıştırmadan bu yana eklenen veya güncellenen kayıtları almak için son oluşturma veya değişiklik tarihini (ör. BKPF.CPUDT, CDHDR.UDATE) bir eşik değeri olarak kullanın.
- ProcessMind için dışa aktarın: Çıkarma işini zamanlayın ve son çıktı adımını, Event Logu ProcessMind’in yükleme için erişebileceği bir konuma CSV veya Parquet dosyası olarak kaydedecek şekilde yapılandırın.
Yapılandırma
- Ön koşullar: Özel bir SAP bağlayıcısına sahip, lisanslı bir üçüncü taraf ETL aracı, örneğin Theobald Xtract Universal, Informatica veya Talend. Finans tablolarını, örneğin F_00 ve F_WF tablo grupları için S_TABU_DIS yetkisini, iş akışı verilerini ve değişiklik günlüklerini okuma yetkisine sahip bir SAP kullanıcı hesabı.
- Bağlantı parametreleri: SAP Application Server IP adresine veya ana bilgisayar adına, System Number ve Client ID bilgilerine ihtiyacınız olacaktır. SAP kullanıcı adı ve parolası için güvenli kimlik bilgisi yönetimi kullanın.
- Temel filtreler: Veri hacmini sınırlamak için kaynakta her zaman Company Code (BKPF.BUKRS) ve Fiscal Year (BKPF.GJAHR) filtrelerini uygulayın. Belirli bir çıkarma dönemi tanımlamak için Document Creation Date (BKPF.CPUDT) alanına filtre uygulamanız önemle önerilir, örneğin son 6 ay.
- Tarih aralığını seçin: İlk yükleme için 3 ila 6 ay gibi temsili bir dönem seçin. Sonraki delta yüklemelerinde yalnızca yeni kayıtları almak için
CPUDTgibi bir zaman damgası alanında watermark kullanın. - Performansı göz önünde bulundurun: 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ğına ilettiğinden emin olun. Özellikle büyük geçmiş veri yüklemelerinde, araç destekliyorsa verileri daha küçük parçalar veya paketler halinde çıkarın.
- İş akışını özelleştirin: Approved veya Rejected gibi iş akışı etkinliklerini belirleme mantığı, kullandığınız iş akışı Templatelerine büyük ölçüde bağlıdır. Filtrelerde kullanmak üzere sisteminizdeki doğru iş akışı görev kimliklerini ve kullanıcı karar anahtarlarını belirlemeniz gerekir.
a Ö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 yolculuğunuza başlamak üzere bu veri Templateinden yararlanın. Daha derin içgörüler elde edin ve finans operasyonlarınız genelinde verimliliği artırın.
Kayıttan Raporlamaya - Yevmiye Kaydı sürecinizi şimdi optimize edin
Yevmiye kaydı çevrim süresini %30 azaltın ve kusursuz raporlama sağlayın.
Kredi kartı gerekmez, iyileştirmeye bugün başlayın.