Kayıttan Raporlamaya - Yevmiye kaydı Veri Templateiniz
Kayıttan Raporlamaya - Yevmiye kaydı Veri Templateiniz
- Toplanması önerilen öznitelikler
- İzlenecek temel faaliyetler
- Pratik veri çıkarma önerileri
Kayıttan Raporlamaya - Yevmiye kaydı öznitelikleri
| Ad | Açıklama | ||
|---|---|---|---|
| Faaliyet ActivityName | Yevmiye kaydı sürecinin belirli bir noktasında gerçekleşen iş faaliyetinin adıdır. | ||
| Açıklama Faaliyet, 'Yevmiye kaydı oluşturuldu', 'Yevmiye kaydı inceleme için gönderildi' veya 'Yevmiye kaydı kaydedildi' gibi, yevmiye kaydının yaşam döngüsündeki belirli bir adımı veya olayı ifade eder. Bu faaliyetler genellikle sistemde kaydedilen değişiklik günlüklerinden, durum güncellemelerinden veya işlem kodlarından türetilir. Faaliyetleri analiz etmek, süreç akışını görselleştirmenize, yaygın yolları belirlemenize ve standart prosedürden sapmaları keşfetmenize imkan verir. Faaliyet sıklığı, adımlar arasındaki bekleme süreleri ve uygunluk oranları gibi metrikleri hesaplamak için temel oluşturur. Neden önemli? Süreçteki adımları tanımlar ve süreç haritalarını görselleştirmenizi ve Workflow örüntülerini analiz etmenizi sağlar. Nereden alınır? Başlık ve kalem tablolarındaki durum alanları (örneğin BKPF-BSTAT), değişiklik belgesi günlükleri (CDHDR/CDPOS) ve Workflow günlükleri dahil olmak üzere çeşitli kaynaklardan türetilir. Örnekler Yevmiye kaydı oluşturulduYevmiye kaydı beklemeye alındıYevmiye kaydı inceleme için gönderildiYevmiye kaydı onaylandıYevmiye kaydı kaydedildi | |||
| Olay zamanı EventTime | Belirli bir faaliyetin yevmiye kaydı için ne zaman gerçekleştiğini gösteren zaman damgasıdır. | ||
| Açıklama Olay zamanı, bir iş faaliyetinin gerçekleştirildiği ve sisteme kaydedildiği kesin tarih ve saattir. Bir vakadaki her faaliyetin kendi zaman damgası vardır ve bu zaman damgaları kronolojik bir olay dizisi oluşturur. Bu öznitelik, zamana dayalı tüm süreç analizleri için önemlidir. Döngü sürelerini, faaliyetler arasındaki süreleri ve bekleme zamanlarını hesaplamak ve işlerin zamana göre dağılımını anlamak için kullanılır. Doğru zaman damgaları, güvenilir bir süreç modeli oluşturmak ve Onay Döngüsü Süresi gibi temel performans göstergelerini hesaplamak için gereklidir. Neden önemli? Olayların kronolojik sırasını sağlar. Bu sıra, süreye dayalı tüm metrikleri hesaplamak ve süreç zaman çizelgesini anlamak için gereklidir. Nereden alınır? Değişiklik belgesi günlüklerinden (CDHDR-UDATE, CDHDR-UTIME), Workflow günlüklerinden veya BKPF gibi tablolardaki oluşturma ve giriş zaman damgalarından (CPUDT, CPUTM) alınır. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Yevmiye Kaydı Kimliği JournalEntryId | Finansal bir yevmiye kaydı için benzersiz tanımlayıcıdır ve süreçteki birincil vaka kimliği olarak kullanılır. | ||
| Açıklama Journal Entry ID, SAP S/4HANA içinde oluşturulması sırasında her muhasebe belgesine atanan benzersiz numaradır. Bu tanımlayıcı, yevmiye kaydının oluşturulması veya park edilmesinden onay iş akışlarına, nihai kaydetme işlemine ve olası ters kayıt ya da mahsuplaşmaya kadar tüm yaşam döngüsünü izlemek için gereklidir. Process Mining analizinde bu kimlik, ilgili tüm etkinlikleri tek bir vakaya bağlamak için kullanılır. Etkinlikler ortak bir Journal Entry ID altında gruplandırıldığında analistler uçtan uca süreç akışını yeniden oluşturabilir, çevrim sürelerini ölçebilir ve her finansal işlem için varyasyonları veya darboğazları belirleyebilir. Bu, tüm süreç görünümünü oluşturmanın temel özniteliğidir. Neden önemli? Bu tanımlayıcı, ilgili tüm süreç adımlarını birbirine bağlayarak her yevmiye kaydının uçtan uca yolculuğunu analiz etmeyi mümkün kılar. Nereden alınır? Bu, genellikle Şirket Kodu (BKPF-BUKRS), Belge Numarası (BKPF-BELNR) ve Mali Yıl (BKPF-GJAHR) alanlarının birleştirilmesiyle oluşturulan bileşik bir anahtardır. Örnekler 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Kayıt tarihi PostingDate | Yevmiye kaydının Genel Muhasebeye işlendiği ve mali dönemi etkileyen tarih. | ||
| Açıklama Kayıt tarihi, işlemin mali tablolarda görüneceği mali dönemi belirler. Muhasebe açısından önemli olan bu tarih, belgenin oluşturulduğu veya sisteme girildiği tarihten farklı olabilir. Process Mining kapsamında kayıt tarihi, ay sonu kapanış süreçlerini karşılaştırmak veya farklı mali dönemlerdeki performans eğilimlerini analiz etmek gibi zaman temelli kohort analizlerinde kullanılır. Ayrıca kaydın oluşturulması ile fiilen muhasebeye işlenmesi arasındaki gecikmeleri ölçmek için de kullanılır. Neden önemli? Mali bağlam açısından önemlidir. Ay sonu veya yıl sonu gibi belirli muhasebe dönemlerinde süreç performansını analiz etmenizi sağlar. Nereden alınır? SAP S/4HANA BKPF tablosu, BUDAT alanı (Belgedeki kayıt tarihi). Örnekler 2023-10-312023-11-012024-02-29 | |||
| Oluşturan kullanıcı CreatedByUser | Yevmiye kaydını oluşturan kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, ilk belgeyi oluşturarak yevmiye kaydı sürecini başlatan kullanıcının benzersiz tanımlayıcısını saklar. Bu kişi bir muhasebeci, iş kullanıcısı veya otomatik kayıtlar için bir sistem kimliği olabilir. Süreci oluşturan kişiye göre analiz etmek, belirli kullanıcılar veya ekiplerle ilişkili örüntüleri belirlemeye yardımcı olur. Bazı kullanıcıların ret oranları daha yüksekse eğitim ihtiyaçlarını ortaya çıkarabilir veya yüksek performans gösteren kişileri belirleyebilir. Bu öznitelik, 'User Activity and Throughput' Dashboardı için gereklidir. Neden önemli? Süreç faaliyetlerini belirli kullanıcılarla ilişkilendirerek performans analizine, iş yükü dengelemesine ve eğitim fırsatlarının belirlenmesine imkan verir. Nereden alınır? SAP S/4HANA BKPF tablosu, USNAM alanı (Kullanıcı adı). Örnekler ABROWNCJONESBATCH_USER | |||
| Şirket kodu CompanyCode | Yevmiye kaydının işlendiği şirket veya tüzel kişiye ait benzersiz tanımlayıcı. | ||
| Açıklama Şirket kodu, SAP Financials içindeki temel organizasyon birimlerinden biridir ve mali tabloların oluşturulduğu bağımsız bir tüzel kişiyi temsil eder. Her yevmiye kaydı belirli bir şirket koduna atanır. Bu öznitelik, kuruluşun farklı bölümlerindeki süreç performansını bölümlere ayırmak ve karşılaştırmak için önemlidir. Analistler bunu belirli bir tüzel kişiye ait süreç görünümünü filtrelemek, şirket kodları arasındaki ret oranlarını karşılaştırmak veya bölgeye özgü süreç farklılıklarını belirlemek için kullanabilir. Neden önemli? Kuruluş içindeki farklı tüzel kişiler veya iş birimleri arasında yevmiye kaydı sürecini filtrelemenizi ve karşılaştırmanızı sağlar. Nereden alınır? SAP S/4HANA BKPF tablosu, BUKRS alanı (Şirket kodu). Örnekler 10001710US01 | |||
| Yerel para biriminde tutar AmountInLocalCurrency | Yevmiye kaydının şirket koduna ait yerel para birimi cinsinden toplam değeri. | ||
| Açıklama Bu öznitelik, yevmiye kaydının finansal büyüklüğünü gösterir. Genellikle belgedeki tüm borç veya alacak kalemlerinin mutlak değerlerinin toplamı alınır ve şirket kodunun yerel para birimine çevrilir. Tutar bazında analiz, süreci finansal etkisine göre bölümlere ayırmanızı sağlar. Örneğin yüksek tutarlı kayıtlar, düşük tutarlı kayıtlara göre daha sıkı bir onay sürecinden geçebilir. Bu yaklaşım, süreç iyileştirme çalışmalarını en yüksek finansal riski taşıyan işlemlere önceliklendirmenize yardımcı olur. Neden önemli? Kaydın finansal değerini göstererek süreç davranışının işlem tutarına göre nasıl değiştiğini analiz etmenizi sağlar. Nereden alınır? Belirli bir yevmiye kaydı (BELNR) için BSEG kalem tablosundaki tutarlar (DMBTR alanı) toplanır ve sonuç pozitif değere dönüştürülerek hesaplanır. Örnekler 1500.75125000.0050.20 | |||
| Yevmiye kaydı türü JournalEntryType | Yevmiye kaydını varlık kaydı, tedarikçi faturası veya genel muhasebe kaydı gibi iş amacına göre sınıflandırır. | ||
| Açıklama Journal Entry Type, SAP terminolojisinde Document Type olarak adlandırılır ve muhasebe belgelerini kategorilere ayıran bir anahtardır. Belgeye atanan numara aralığı ve kaydetme işleminde hangi hesap türlerine izin verildiği gibi unsurları kontrol eder. Süreci yevmiye kaydı türüne göre analiz etmek, bağlama özgü davranışları anlamak için önemlidir. Örneğin basit bir tahakkuk kaydı (SA türü) için onay süreci, karmaşık bir varlık edinimi (AA türü) için gerekenden çok daha basit olabilir. Bu boyut, 'Compliance by Entry Type' Dashboardı için temel öneme sahiptir. Neden önemli? Kayıtları iş bağlamına göre kategorilere ayırarak farklı finansal işlem türlerinde süreç farklılıklarını ve performansını analiz etmenizi sağlar. Nereden alınır? SAP S/4HANA BKPF tablosu, BLART alanı (Belge türü). Örnekler SAKRAA | |||
| Belge durumu DocumentStatus | Yevmiye kaydının Park Edildi, Kaydedildi veya Mahsup Edildi gibi mevcut işleme durumu. | ||
| Açıklama Belge durumu, yevmiye kaydının yaşam döngüsündeki konumunu gösterir. Örneğin park edilmiş bir belge kaydedilmiştir ancak henüz Genel Muhasebeye işlenmemiştir. Kaydedilmiş bir belge ise son haline getirilmiştir. Durumu analiz etmek, iş akışını anlamanıza ve darboğazları belirlemenize yardımcı olur. Uzun süre Park Edildi veya Onay Bekliyor durumunda kalan çok sayıda belge, süreçteki verimsizliklere işaret edebilir. Bu alan, süreç faaliyetlerini türetmek için de önemli bir kaynaktır. Neden önemli? Yevmiye kaydının yaşam döngüsündeki konumunu göstererek kuyrukları ve darboğazları belirlemenize yardımcı olur. Nereden alınır? SAP S/4HANA BKPF tablosu, BSTAT alanı (Belge durumu). Örnekler VAB | |||
| Bitiş zamanı EndTime | Faaliyetin tamamlandığı zamanı gösteren zaman damgası. | ||
| Açıklama End Time, bir etkinliğin tamamlandığı zamanı gösterir. Birçok Event Logda bir etkinliğin Start Time ve End Time değerleri aynıdır ve bu durum anlık bir olayı temsil eder. Ancak kullanıcının bir belgeyi etkin biçimde incelemesi gibi ölçülebilir süreye sahip etkinliklerde bu öznitelik süreyi yakalayabilir. Ayrı bir End Time değerinin bulunması, etkinlik işlem sürelerinin bekleme sürelerinden daha hassas biçimde hesaplanmasını sağlar. Böylece bir görevin etkin olarak üzerinde çalışıldığı süre ile kuyrukta boşta beklediği süre birbirinden ayrılabilir. Neden önemli? Faaliyetlerin işleme sürelerini hassas biçimde hesaplamanızı ve aktif çalışma süresini boşta bekleme süresinden ayırmanızı sağlar. Nereden alınır? Atomik olaylarda genellikle StartTime ile aynıdır. Süreye sahip faaliyetlerde Workflow günlüklerinden alınabilir veya sonraki olaylara göre hesaplanabilir. Örnekler 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| İşlem kodu TransactionCode | Yevmiye kaydını oluşturmak veya değiştirmek için kullanılan SAP işlem kodu. | ||
| Açıklama İşlem Kodu (T-Code), SAP içindeki belirli bir işlevi veya programı tanımlayan kısayoldur. Yevmiye kayıtlarında farklı T-Code'lar kaydın nasıl oluşturulduğunu gösterebilir. Örneğin FB01 manuel genel muhasebe kaydı, FV50 park etme veya otomatik bir kod sistem tarafından oluşturulan kayıt anlamına gelebilir. Bu öznitelik, bir faaliyetin kullanıcı tarafından manuel olarak mı yoksa sistem tarafından otomatik olarak mı gerçekleştirildiğini gösteren güçlü bir işarettir. Manuel Kayıt Oranı KPI'ını hesaplamak ve otomasyon fırsatlarını belirlemek için temel oluşturur. Neden önemli? Bir kaydın nasıl işlendiğini, örneğin manuel veya otomatik olarak, gösterir. Bu bilgi otomasyon analizleri ve süreç farklılıklarını anlamak için önemlidir. Nereden alınır? SAP S/4HANA BKPF tablosu, TCODE alanı (İşlem kodu). Örnekler FB01FV50F-02 | |||
| Kaynak sistem SourceSystem | Yevmiye kaydı verilerinin çıkarıldığı kaynak sistemi tanımlar. | ||
| Açıklama Bu öznitelik, yevmiye kaydı verilerinin kaynaklandığı kayıt sistemini belirtir. Birden fazla ERP örneği veya eski ve modern sistemlerin birlikte kullanıldığı şirketlerde veri kaynaklarını ayırt etmeye yardımcı olur. Analizde farklı sistemlerdeki süreç performansını karşılaştırmak veya belirli bir kaynağa ait verileri filtrelemek için kullanılabilir. Veri yönetişimi ve analiz edilen verilerin bağlamının anlaşılması açısından önemlidir. Neden önemli? Verilerin kaynağı hakkında bağlam sağlar. Bu bilgi, doğru süreç analizi ve karşılaştırması için birden fazla sistemin bulunduğu ortamlarda büyük önem taşır. Nereden alınır? Bu genellikle veri çıkarma sırasında eklenen statik bir değerdir ve belirli SAP S/4HANA örneğini, örneğin SID veya mantıksal sistem adını, tanımlar. Örnekler S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Mali yıl FiscalYear | Yevmiye kaydının ait olduğu mali yıl. | ||
| Açıklama Mali yıl, şirket kodu ve belge numarasıyla birlikte yevmiye kaydının benzersiz anahtarının bir parçasıdır. Belgenin geçerli olduğu mali yılı gösterir. Analizde mali yıl, uzun vadeli eğilimleri incelemek ve vaka tanımlayıcısının benzersizliğini sağlamak için kullanılır. Farklı mali yıllardaki süreç metriklerini karşılaştırmak, performansın zaman içinde iyileşip iyileşmediğini veya gerileyip gerilemediğini ortaya çıkarabilir. Neden önemli? Belgeleri benzersiz biçimde tanımlamak için gerekli bir bileşen sağlar ve yıllar arası süreç performansı analizine imkan verir. Nereden alınır? SAP S/4HANA BKPF tablosu, GJAHR alanı (Mali yıl). Örnekler 202320242022 | |||
| Manuel kayıt mı IsManualPosting | Yevmiye kaydının bir kullanıcı tarafından manuel olarak işlenip işlenmediğini gösteren boolean işareti. | ||
| Açıklama Bu öznitelik, sistem işi veya arayüz tarafından otomatik olarak işlenmek yerine kullanıcı müdahalesiyle kaydedilen yevmiye kayıtlarını belirler. Genellikle belgeyi kaydetmek için kullanılan İşlem Kodu'ndan türetilir. Bu işaret, Manuel Kayıt Oranı KPI'ını hesaplamak ve kuruluşların Kayıttan Raporlamaya sürecini otomatikleştirme ilerlemesini izlemek için kullanılır. Analistler manuel kaydedilen kayıtları filtreleyerek hâlâ insan müdahalesi gerektiren senaryoları belirleyebilir ve bunların otomasyon potansiyelini değerlendirebilir. Neden önemli? İnsan ve sistem tarafından yürütülen kayıtları birbirinden ayırarak otomasyon düzeyini ölçmenize ve otomasyon fırsatlarını belirlemenize yardımcı olur. Nereden alınır? Bu, TransactionCode'dan türetilen hesaplanmış bir özniteliktir. Önceden tanımlanmış manuel işlem kodları listesi, örneğin FB01 ve F-02, işareti true olarak ayarlamak için kullanılır. Örnekler truefalse | |||
| Onay çevrim süresi ApprovalCycleTime | Yevmiye kaydının onaya gönderilmesi ile onaylanması veya reddedilmesi arasında geçen süre. | ||
| Açıklama Bu hesaplanan metrik, özellikle onay aşamasının süresine odaklanır. 'Journal Submitted For Review' etkinliği ile sonraki 'Journal Entry Approved' veya 'Journal Entry Rejected' etkinliği arasındaki süreyi ölçer. Bu KPI, onay iş akışındaki darboğazları belirlemek için önemlidir. Yüksek onay çevrim süreleri genel süreci önemli ölçüde geciktirebilir. Bu metriği onaylayana, şirket koduna veya yevmiye kaydı türüne göre analiz etmek, iyileştirme gerektiren belirli alanları ortaya çıkarabilir. Neden önemli? Onay adımının süresini ayrı olarak göstererek inceleme ve onay iş akışındaki darboğazları belirlemenize ve gidermenize yardımcı olur. Nereden alınır? Yevmiye İncelemeye Gönderildi olayı ile Yevmiye Kaydı Onaylandı veya Yevmiye Kaydı Reddedildi olayı arasındaki zaman farkı bulunarak hesaplanır. Örnekler 1 gün 2 saat4 saat 25 dakika5 gün 0 saat | |||
| Onaylayan kullanıcı ApproverUser | Yevmiye kaydını onaylayan veya reddeden kişinin kullanıcı kimliği. | ||
| Açıklama Bu öznitelik, gönderilen bir yevmiye kaydını incelemekten ve hakkında karar vermekten sorumlu kullanıcıyı belirler. Çok düzeyli bir onay iş akışında tek bir yevmiye kaydı için birden fazla onaylayan olabilir. Bu bilgi, onay sürecini ayrıntılı biçimde analiz etmek için gereklidir. Farklı onaylayanların iş yükünü ölçmenize, kişisel onay sürelerini hesaplamanıza ve onay zincirindeki darboğazları belirlemenize yardımcı olur. 'User Activity and Throughput' Dashboardını doğrudan destekler. Neden önemli? Onaydan sorumlu kişiyi belirleyerek onay iş yüklerini, performansını ve darboğazları analiz etmenizi sağlar. Nereden alınır? Onay adımını kimin yürüttüğünü izlemek için Workflow günlüklerinden, örneğin SWW_WI2OBJ ve SWWLOG, veya değişiklik belgesi tablolarından, CDHDR ve CDPOS, alınır. Örnekler DMILLERFWHITEKCHEN | |||
| Son veri güncellemesi LastDataUpdate | Bu kayıt için verilerin kaynak sistemden en son yenilendiği zamanı gösteren zaman damgası. | ||
| Açıklama Bu öznitelik, kaynak sistemden yapılan en son veri çıkarma veya güncelleme işleminin tarih ve saatini kaydeder. Analiz edilen verilerin güncelliği hakkında şeffaflık sağlar. Son güncelleme zamanını bilmek, süreç analizinin ne kadar güncel olduğunu anlamak açısından önemlidir. Kullanıcıların Dashboard ve KPI'ları doğru yorumlamasına yardımcı olur. Böylece neredeyse gerçek zamanlı verilere mi yoksa önceki bir döneme ait anlık görüntüye mi baktıklarını anlayabilirler. Neden önemli? Verilerin güncelliğini göstererek kullanıcıların süreç analizinin ne kadar güncel olduğunu anlamasını sağlar. Nereden alınır? Bu bir meta veri özniteliğidir ve genellikle veri alma hattı sırasında her kayda eklenir ve zaman damgası atanır. Örnekler 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Ters kayıt nedeni ReversalReason | Kaydedilmiş bir yevmiye kaydının neden ters kaydedildiğini gösteren kod. | ||
| Açıklama Kaydedilmiş bir yevmiye kaydı hatalıysa silinemez, yeni bir belgeyle ters kaydedilmesi gerekir. Ters kayıt nedeni kodu, örneğin yanlış kayıt tarihi veya tutar nedeniyle bu işlemin neden yapıldığını açıklar. Ters kayıt nedenlerini analiz etmek, Kayıttan Raporlamaya sürecindeki hataların kök nedenlerini belirlemenize yardımcı olur. Belirli bir nedenin sık görülmesi, yetersiz eğitim veya kontrol eksiklikleri gibi ele alınması gereken sistemik sorunlara işaret edebilir. Böylece ilk seferde doğru işlem oranını artırabilirsiniz. Neden önemli? Ters kayıtlara yol açan hataların kök nedenini belirlemenize, yeniden çalışmayı azaltmanıza ve süreç kalitesini artırmanıza yardımcı olur. Nereden alınır? SAP S/4HANA BKPF tablosu, STGRD alanı (Ters kayıt nedeni). Örnekler 010205 | |||
| Yeniden çalışma var mı IsRework | Yevmiye kaydının ret sonrasında düzeltilmesi gibi bir yeniden çalışma sürecinden geçip geçmediğini gösteren boolean işareti. | ||
| Açıklama Bu hesaplanan öznitelik, ideal süreç akışından sapan yevmiye kayıtlarını işaretler. Vaka içinde Yevmiye Kaydı Reddedildi veya Yevmiye Kaydı Düzeltildi gibi bir faaliyet gerçekleştiğinde genellikle true olarak ayarlanır. Bu işaret, süreç verimliliğini analiz etmeyi kolaylaştırır. Yeniden Çalışma Oranı KPI'ını hızlıca hesaplamanızı ve yeniden çalışma içeren ve içermeyen vakaların çevrim süreleri ile maliyetlerini doğrudan karşılaştırmanızı sağlar. Yeniden çalışmanın nedenlerini belirlemek, birçok süreç iyileştirme çalışmasının temel hedefidir. Neden önemli? Düzeltme veya ek döngü gerektiren vakaları işaretleyerek süreç verimsizliklerini kolayca ölçmenizi ve kök neden analizi yapmanızı sağlar. Nereden alınır? Bu, bir vakadaki faaliyet dizisinden türetilen hesaplanmış bir özniteliktir. Yevmiye Kaydı Reddedildi gibi bir faaliyet mevcutsa true olarak işaretlenir. Örnekler truefalse | |||
Kayıttan Raporlamaya - Yevmiye kaydı faaliyetleri
| Aktivite | Açıklama | ||
|---|---|---|---|
| Yevmiye kaydı inceleme için gönderildi | Yevmiye kaydını oluşturan kişi, belgeyi inceleme ve onay iş akışına resmen gönderir. Bu etkinlik, veri girişinden resmi kontrol sürecine devir teslimi temsil eder ve onay döngüsünü başlatır. | ||
| Neden önemli? Bu adım, onay döngüsü süresinin başlangıcını gösterir. Bu noktadan son onay veya redde kadar geçen süreyi ölçmek, özellikle inceleme ve onay aşamalarındaki darboğazları belirlemenize yardımcı olur. Nereden alınır? Bu bilgi çoğu zaman iş nesnesine bağlı Workflow günlüklerinden (SWW_WIHEAD, SWWLOG) alınır. Ayrıca belge başlığındaki (BKPF) özel bir alanda durum değişikliği olup olmadığı incelenerek de çıkarılabilir. Yakalayın Workflow öğesinin oluşturulma zaman damgası veya durum alanının 'Gönderildi' ya da 'İnceleniyor' olarak değişmesi. Olay türü inferred | |||
| Yevmiye kaydı iptali işlendi | Daha önce kaydedilmiş bir yevmiye kaydı, ters kayıtlar içeren yeni bir belge oluşturularak iptal edilir. Bu işlem, kaydedilmiş belgelerdeki hataları düzeltmek için yapılır ve açıkça izlenebilen bir işlemdir. | ||
| Neden önemli? İptaller, kaydedilmiş bir belgede hata yapıldığını gösterir. Yüksek iptal oranı, onay sürecinde veya veri girişi kalitesinde temel sorunlara işaret eder. Bunları izlemek, ilk seferde doğru işlem yapma oranını artırmaya yardımcı olur. Nereden alınır? İptal, açıkça gerçekleşen bir olaydır. Yeni iptal belgesinin başlığında (BKPF), Ters Kaydı Yapılan Belge No. (STBLG) alanında orijinal belgeye referans bulunur. Yeni belgenin kaydetme tarihi olay zamanıdır. Yakalayın BKPF-STBLG alanı dolu olan belgeleri belirleyin. Olayın zaman damgası, iptal belgesinin kaydetme tarihidir. Olay türü explicit | |||
| Yevmiye kaydı kapatıldı | Yevmiye kaydındaki açık kalem, faturayı kapatan ödeme gibi başka bir kaydetme işlemiyle mahsup edilir. Bu faaliyet, belirli kalemlerin mutabakatını gösterir ve kalemleri fiilen kapatır. | ||
| Neden önemli? Bu faaliyet, özellikle bekleyen veya açık kalem yönetimli hesapları içeren birçok yevmiye kaydı için son mutabakat adımını gösterir. Kaydetme işleminden kapatmaya kadar geçen süreyi analiz etmek, mutabakat verimliliğini ölçmeye yardımcı olur. Nereden alınır? Bu olay, kalem tablosundan (BSEG veya ACDOCA görünümü) çıkarılır. Bir kalem kapatıldığında, o kaleme ait Kapatma Tarihi (AUGDT) ve Kapatma Belgesi (AUGBL) alanları doldurulur. Yakalayın Olayın zaman damgası olarak kalem için kapatma tarihini (BSEG-AUGDT) kullanın. Olay türü inferred | |||
| Yevmiye kaydı kaydedildi | Yevmiye kaydı büyük deftere resmi olarak kaydedilir ve şirketin finansal tablolarını etkiler. Belgenin kalıcı bir finansal kayda dönüştüğü nokta budur. | ||
| Neden önemli? Bu, temel işleme döngüsünün sonunu gösteren birincil başarı kilometre taşıdır. Kaydedilen kayıtların işlem hacmini ve bu aşamaya ulaşma süresini analiz etmek, Process Mining metriklerinin temel unsurlarıdır. Nereden alınır? Bu, BKPF tablosundaki Kaydetme Tarihi (BUDAT) ile işaretlenen açık bir olaydır. Kaydedilmiş bir belgenin belge durumu (BSTAT) boştur; bu özellik belgeyi beklemeye alınmış ('V') veya tutulmuş ('D') belgelerden ayırır. Yakalayın Olayın zaman damgası için Kaydetme Tarihi (BKPF-BUDAT) ve Giriş Tarihi (BKPF-CPUDT) alanlarını kullanın. BKPF-BSTAT alanının boş olması, belgenin kaydedildiğini gösterir. Olay türü explicit | |||
| Yevmiye kaydı oluşturuldu | Bu faaliyet, sistemde bir yevmiye kaydı belgesinin ilk kez oluşturulmasını gösterir. Kayıt başlık tablosunda (BKPF) oluşturulur, ancak henüz büyük deftere kaydedilmemiştir. Bu, yevmiye kaydı yaşam döngüsünün başlangıç noktasıdır. | ||
| Neden önemli? Bu, süreçteki birincil başlangıç olayıdır. Bu olaydan kaydetme işlemine kadar geçen süreyi analiz etmek, genel döngü süresini ölçmek ve ilk veri girişi gecikmelerini belirlemek için önemlidir. Nereden alınır? Bu olay, belirli bir belge numarası (BELNR) için SAP BKPF tablosundaki oluşturma tarihi (CPUDT) ve oluşturma saati (CPUTM) alanlarından açıkça yakalanabilir. Yakalayın Olay zaman damgası için BKPF-CPUDT ve BKPF-CPUTM alanlarını kullanın. Olay türü explicit | |||
| Yevmiye kaydı onaylandı | Yevmiye kaydı, yetkili bir yöneticiden son onayı alır. Bu onay, kaydın geçerli ve doğru olduğunu doğrular. Belgenin büyük deftere kaydedilmesinden önceki son kontrol noktasıdır. | ||
| Neden önemli? Bu, onay döngüsünü tamamlayan önemli bir kilometre taşıdır. Bu adıma ulaşmak için geçen süre, genel süreç süresinin önemli bir bölümünü oluşturur ve onaylayıcı verimliliğinin temel göstergelerinden biridir. Nereden alınır? Bu olay, son onay adımını gösteren bir Workflow günlüğünden veya belgedeki durum değişikliğinden çıkarılır. Onaylayıcının kullanıcı kimliği ve zaman damgası Workflow verilerinden veya değişiklik günlüklerinden alınabilir. Yakalayın Workflow günlüklerinde son onay adımının zaman damgasını veya değişiklik belgelerinde durumun 'Onaylandı' olarak değiştiğini belirleyin. Olay türü inferred | |||
| Destekleyici belge eklendi | Bir kullanıcı, fatura veya elektronik tablo gibi bir ya da daha fazla destekleyici belgeyi yevmiye kaydına ekler. Bu işlem genellikle inceleme ve denetim sırasında finansal işleme kanıt ve bağlam sağlamak için yapılır. | ||
| Neden önemli? İnceleme öncesinde belgelerin eklenmesini sağlamak, uyumluluk ve onay verimliliği açısından önemlidir. Bu faaliyet, belge politikalarına uyumu ve bunun onay döngüsü sürelerine etkisini ölçmeye yardımcı olur. Nereden alınır? Bu durum genellikle Generic Object Services (GOS) üzerinden bağlanan eklerin oluşturulma zaman damgası kontrol edilerek çıkarılır. SRGBTBREL tablosu, iş nesnesini (örneğin BKPF belgesini) eke bağlar. Yakalayın GOS ek tablolarını (örneğin SRGBTBREL) BKPF nesnesine ait bağlantılar için sorgulayın ve ekin oluşturulma zaman damgasını kullanın. Olay türü inferred | |||
| Manuel kaydetme belirlendi | Yevmiye kaydı, otomatik bir arayüz veya toplu iş yerine manuel bir işlem kodu kullanılarak kaydedilmiştir. Bu, zamana bağlı bir olay değil, kaydetme faaliyetinin sınıflandırılmasıdır. | ||
| Neden önemli? Manuel kaydetmeleri belirlemek, otomasyon çalışmaları için önemlidir. Manuel kaydetme oranının yüksek olması, alt sistemleri entegre ederek veya otomatik kaydetme programları kullanarak süreçleri kolaylaştırma fırsatlarına işaret eder. Nereden alınır? Bu bilgi, belge başlık tablosundaki (BKPF) işlem kodu (TCODE) alanı analiz edilerek hesaplanır. Kaydı sınıflandırmak için bilinen manuel işlem kodlarından (örneğin FB01, F-02, FB50) oluşan bir liste kullanılır. Yakalayın Olayı, kaydetme anında BKPF-TCODE değerini önceden tanımlanmış manuel işlem kodları listesine göre sınıflandırın. Olay türü calculated | |||
| Yevmiye kaydı beklemeye alındı | Bir kullanıcı, eksik bir yevmiye kaydını kaydetmeden saklar; böylece kayıt daha sonra tamamlanabilir veya incelenebilir. Bu açık işlem, belge başlığı kaydı oluşturur ve belgeyi beklemede, kaydedilmemiş durumda tutar. | ||
| Neden önemli? Beklemeye alma, gönderimden önce sık kullanılan bir adımdır. Bekleme durumunun süresini izlemek, resmi inceleme ve onay süreci başlamadan önce veri tamamlama ve hazırlık aşamalarındaki gecikmeleri belirlemeye yardımcı olur. Nereden alınır? BKPF tablosunda beklemeye alınmış belge, belge durumu alanının (BSTAT) 'V' değerine sahip olmasıyla belirlenir. Olay zaman damgası oluşturma tarihidir (CPUDT). Yakalayın Oluşturulma anında BKPF-BSTAT = 'V' olan belgeleri filtreleyin. Olay türü explicit | |||
| Yevmiye kaydı düzeltildi | Kullanıcı, reddedildikten veya değişiklik yapılması için geri gönderildikten sonra yevmiye kaydını değiştirir. Bu faaliyet, yeniden gönderimden önce inceleme sırasında belirlenen sorunları gidermek için gereken yeniden çalışma çabasını gösterir. | ||
| Neden önemli? Bu faaliyet, yeniden çalışma döngülerini ölçer. Düzeltmelerin sıklığını ve süresini analiz etmek, verimsizlik kaynaklarını belirlemeye ve eğitim ile süreç açıklığı için fırsatları ortaya çıkarmaya yardımcı olur. Nereden alınır? Bu durum, daha önce 'Reddedildi' durumunda olan bir belge için BKPF tablosundaki 'Son Değiştirilme Tarihi' (AEDAT) alanı izlenerek çıkarılabilir. Değişiklik belgeleri, nelerin değiştirildiğine ilişkin daha ayrıntılı bilgi sağlar. Yakalayın Ret olayından sonra yapılan değişiklikler için değişiklik belgesi başlıklarındaki (CDHDR-UDATE) zaman damgasını kullanın. Olay türü inferred | |||
| Yevmiye kaydı kaydetme sonrasında değiştirildi | Bir kullanıcı, yevmiye kaydı büyük deftere kaydedildikten sonra sınırlı sayıdaki alanı değiştirir. Finansal verilerin çoğu kaydetme sonrasında değiştirilemese de metin veya atama gibi bazı alanlar güncellenebilir. | ||
| Neden önemli? Bu faaliyet, önemli bir uyumluluk göstergesidir. Kaydetme sonrasındaki değişiklikler, kayıtları değiştirme girişimlerine işaret edebilir. Dolandırıcılığı önlemek ve veri bütünlüğünü korumak için yakından izlenmelidir. Nereden alınır? Bu durum, değişiklik belgesi tablolarından (CDHDR ve CDPOS) güvenilir biçimde çıkarılabilir. Belge numarasına ait CDHDR kaydında, kaydetme tarihinden sonraki bir değişiklik tarihi bulunması kaydetme sonrası değişikliğe işaret eder. Yakalayın CDHDR içinde değişiklik zaman damgasının (UDATE/UTIME) belgenin kaydetme tarihinden (BKPF-BUDAT) sonra olduğu kayıtları bulun. Olay türü inferred | |||
| Yevmiye kaydı reddedildi | Bir inceleyici veya onaylayıcı yevmiye kaydını reddeder ve kaydedilmesini engeller. Belge genellikle düzeltme yapılması için oluşturana geri gönderilir ve yeniden çalışma döngüsü başlar. | ||
| Neden önemli? Retleri izlemek, süreç kalitesini anlamak ve yaygın hataları belirlemek için önemlidir. Yüksek ret oranları veri doğruluğu, politika bilgisi veya destekleyici belgelerin yetersizliğiyle ilgili sorunlara işaret eder. Nereden alınır? Bu olay, Workflow günlüğünde veya yevmiye kaydı belgesindeki özel durum alanında gerçekleşen durum değişikliğinden çıkarılır. İlgili durum alanına ait değişiklik belgeleri (CDHDR/CDPOS) zaman damgasını sağlayabilir. Yakalayın Değişiklik belgeleri (CDHDR/CDPOS) veya Workflow günlükleri üzerinden durum alanının 'Reddedildi' olarak değiştiğini belirleyin. Olay türü inferred | |||
Veri çıkarma rehberleri
Adımlar
- Ön koşullar ve erişim: SAP S/4HANA temel veritabanını sorgulamak veya ABAP raporlarını çalıştırmak için gerekli yetkilere sahip bir kullanıcı bulunduğundan emin olun. I_JournalEntry ve I_JournalEntryItem CDS görünümlerine ve CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ ve SWWLOGHIST tablolarına okuma erişiminiz olmalıdır. Erişim genellikle SAP HANA Studio veya DBeaver gibi bir veritabanı istemcisi ya da Eclipse için SAP ABAP Development Tools (ADT) kullanılarak verilir.
- Sisteme özgü yapılandırmaları belirleyin: Sorguyu çalıştırmadan önce yevmiye kaydı onay iş akışınızda kullanılan özel görev kodlarını belirlemelisiniz. Gönderim, ret ve onay etkinliklerine karşılık gelen görev kimliklerini (ör. TS12345678) bulmak için SAP iş akışı yöneticinizle görüşün. Bu kimlikler son sorgudaki yer tutucular için gereklidir.
- SQL sorgusunu hazırlayın:
querybölümünde verilen SQL sorgusunun tamamını seçtiğiniz SQL istemcisine veya geliştirme aracına kopyalayın. - Sorgu parametrelerini ayarlayın: Sorgudaki yer tutucuları bulun ve bunları kendi değerlerinizle değiştirin. Buna
[YourCompanyCode],[StartDate]ve[EndDate]parametrelerinin ayarlanması dahildir. Ayrıca yer tutucu iş akışı görev kimliklerini ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) önceki adımda belirlediğiniz değerlerle değiştirin. - Veri çıkarma sorgusunu çalıştırın: Değiştirilmiş SQL sorgusunu SAP S/4HANA veritabanında çalıştırın. Tarih aralığına ve veri hacmine bağlı olarak sorgunun tamamlanması önemli ölçüde zaman alabilir. Sorgunun yoğun olmayan saatlerde çalıştırılması önerilir.
- İlk sonuçları inceleyin: Sorgu tamamlandığında çıktının ilk birkaç satırını inceleyerek JournalEntryId, ActivityName ve EventTime gibi tüm sütunların beklendiği şekilde doldurulduğundan emin olun. Sonuç kümesi, yevmiye kaydının yaşam döngüsündeki her farklı iş olayı için bir satır içermelidir.
- Verileri CSV olarak dışa aktarın: Sonuç kümesinin tamamını SQL aracınızdan tek bir CSV dosyasına aktarın. Özel karakterlerle ilgili sorunları önlemek için dosyanın UTF-8 kodlamasını kullandığından emin olun.
- Yüklemeye hazırlanın: Bir Process Mining aracına yüklemeden önce CSV dosyasında gerekli başlıkların bulunduğunu doğrulayın. Veriler zaten Event Log olarak yapılandırılmıştır, bu nedenle başka bir dönüştürme veya pivot işlemi gerekmemelidir.
Yapılandırma
- Core Data Services (CDS) görünümleri: Veri çıkarma işlemi, başlık verileri için öncelikle
I_JournalEntry, kalem ve tutar ayrıntıları için iseI_JournalEntryItemgörünümünü kullanır. Bu görünümler, evrensel yevmiye defterine (ACDOCA) basitleştirilmiş ve anlamsal açıdan zengin bir arayüz sağlar. - Destekleyici tablolar: Eksiksiz bir süreç görünümü elde etmek için sorgu ayrıca birkaç standart SAP tablosunu birleştirir:
CDHDRveCDPOS, belgelerdeki değişiklikleri izlemek için kullanılır.SRGBRELveSOOD, Generic Object Services (GOS) aracılığıyla eklerin ne zaman bağlandığını belirlemek için kullanılır.SWW_WI2OBJveSWWLOGHIST, onay iş akışındaki temel etkinlikleri çıkarmak için kullanılır.
- Tarih aralığı filtreleme: Performansı yönetmek için verileri belirli bir tarih aralığına göre filtrelemek önemlidir.
WHEREkoşulundaI_JournalEntry.CreationDateTimealanını kullanın. İlk analiz için 3 ila 6 aylık bir aralık önerilir. - Kuruluş filtreleme: Çıkarma işlemini ilgili tüzel kişilerle sınırlamak için her zaman
CompanyCodealanına göre filtreleyin. Büyük bir sistemde tüm şirket kodlarını tek seferde sorgulamak, yürütme sürelerinin son derece uzamasına yol açabilir. - İş akışı görev kimlikleri: Sorgu, iş akışı görev kimlikleri için yer tutucular içerir (ör.
[Workflow Approved Task ID]). Bunlar her SAP kurulumu için benzersizdir ve iş akışı etkinliklerinin çıkarılması için doğru biçimde yapılandırılmalıdır. Bu kimlikler olmadan gönderim, onay veya ret etkinlikleri yakalanmaz. - Ön koşullar: Sorguyu çalıştıran kullanıcının finans, sistem ve iş akışı tabloları için kapsamlı okuma yetkilerine sahip olması gerekir. Bu izinler standart olarak verilmez ve özel olarak atanmalıdır.
a Örnek sorgu sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Adımlar
- SAP HANA veritabanına doğrudan SQL erişiminin onaylandığını ve veri çıkarma kullanıcısının BKPF ile ACDOCA için okuma yetkisine sahip olduğunu doğrulayın. Ayrıca sisteminizde gereken yapılandırılmış Workflow, ek, değişiklik geçmişi, mahsuplaşma veya ters kayıt kaynakları için de yetki bulunmalıdır. Doğrudan veritabanı erişimi genellikle SAP HANA Database Explorer, SAP HANA Studio veya onaylı bir SQL istemcisiyle gerçekleştirilir. Sisteminiz bu erişimi açıkça desteklemiyorsa veri çıkarma sorgularını bir SAP uygulama işleminde çalıştırmayın.
- İstemci alanı, şirket kodu, mali yıl, belge numarası, belge türü, kayıt tarihi, oluşturma tarihi, oluşturma saati, kullanıcı, yerel para birimi tutarı ve sisteminizin gerektirdiği ters kayıt veya mahsuplaşma alanları dahil olmak üzere BKPF ve ACDOCA'nın fiziksel şemasını doğrulayın. SAP S/4HANA kurulumlarında şema ve alan kullanılabilirliği farklılık gösterebilir. Bu nedenle sorgudaki köşeli parantez içindeki yer tutucuları sisteminizde doğruladığınız alanlarla değiştirin.
- Workflow ve ek olayları için yetkili kaynakları belirleyin. BKPF ve ACDOCA, muhasebe belgesi ve kalem verilerini sağlar, ancak bekletme, gönderim, ret, düzeltme, onay veya ek olaylarının tamamını tek başına güvenilir biçimde göstermez. Köşeli parantez içindeki Workflow ve ek kaynağı yer tutucularını uygulamanızda onaylanmış görünümler veya tablolarla değiştirin. Bir kaynak kullanılamıyorsa olay uydurmayın. İlgili kaynağı belgelenmiş onayla yapılandırın veya aktiviteyi hariç tutun.
- Gerekli tarih aralığı, şirket kodları, belge türleri ve istemci için veri çıkarma parametrelerini ayarlayın. İlk doğrulama için üç ila altı aylık bir aralık önerilir. Üzerinde anlaşılmış süreç kapsamına göre operasyonel olaylar için olay zaman damgası aralığını, muhasebe olayları için ise kayıt tarihi aralığını kullanın.
- Eksiksiz SQL sorgusunu onaylı HANA SQL istemcisinde çalıştırın. Sorgu, açıkça çıkarılan her aktivite için bir olay satırı oluşturur. Muhasebe olayları için BKPF ve ACDOCA'yı, Workflow, ek, değişiklik, mahsuplaşma ve ters kayıt olayları için yapılandırılmış kaynak görünümlerini kullanır. Bir belgenin varlığından hareketle aktivite çıkarımı yapmaz.
- Çıktı şemasını inceleyin. JournalEntryId vaka kimliği, ActivityName aktivite etiketi, EventTime ise olay zaman damgasıdır. Önerilen iş öznitelikleri, kullanılabildikleri durumlarda döndürülür. EventTime alanının zaman damgası olduğunu ve tüm satırlarda boş olmayan JournalEntryId ile ActivityName değerlerinin bulunduğunu doğrulayın.
- Seçilen istemci, şirket kodları, mali yıllar ve tarih aralığı için benzersiz JournalEntryId değerlerini beklenen BKPF kayıtlarıyla karşılaştırarak muhasebe kapsamını mutabık hale getirin. Workflow ve ek kapsamlarını ayrı ayrı mutabık hale getirin, çünkü bunların saklama ve zaman damgası kuralları muhasebe verilerinden farklı olabilir.
- Olay sıralamasını ve yinelenen kayıt davranışını doğrulayın. ACDOCA'daki birden çok kalem, süreç tasarımı özellikle kalem düzeyinde olaylar gerektirmiyorsa yinelenen muhasebe olayları oluşturmamalıdır. Her günlük kaydı ve olay türü için tek bir muhasebe olayı üretmek üzere sorgudaki toplama mantığını kullanın; kullanılabildiği durumlarda yapılandırılmış kaynak olay kimliklerini koruyun.
- Sonucu UTF-8 CSV veya ProcessMind tarafından desteklenen başka bir tablo biçiminde dışa aktarın. JournalEntryId, ActivityName ve EventTime sütun adlarını aynen koruyun. Dosyayı JournalEntryId ve EventTime alanlarına göre sıralayın, ek öznitelikleri sütun olarak koruyun. Dosyayı ProcessMind'e yükleyin ve JournalEntryId'yi vaka kimliği, ActivityName'i aktivite, EventTime'ı ise olay zaman damgası olarak yapılandırın.
Yapılandırma
- Tarih aralığı: Üç ila altı ayla başlayın. Performans testi için daha kısa bir aralık kullanın ve satır sayıları ile olay kapsamını doğruladıktan sonra aralığı genişletin.
- İstemci ve şirket kapsamı: [Client parameter] değerini ayarlayın ve CompanyCode alanını gerekli tüzel kişilerle sınırlandırın. Birden çok istemcili sistemlerde istemci koşulunu atlamayın.
- Muhasebe kapsamı: [Document type filter] değerini ve uygun durumlarda mali yıl ile kayıt tarihi filtrelerini yapılandırın. Seçilen kaynak bunları güvenilir biçimde temsil ediyorsa kaydedilmiş ve kaydedilmemiş belgeleri birlikte dahil edin.
- Workflow kapsamı: Gönderildi, reddedildi, düzeltildi ve onaylandı aktiviteleri için [Workflow event source] kaynağını ve olay türü eşlemelerini yapılandırın. Zaman damgalarının Workflow aksiyonunun oluşturulma, yürütülme veya tamamlanma zamanını gösterip göstermediğini doğrulayın.
- Ek kapsamı: [Attachment event source] kaynağını ve eki Journal Entry'ye bağlayan ilişki alanını yapılandırın. Kaynağın ek oluşturma, değiştirme veya silme işlemlerini kaydedip kaydetmediğini doğrulayın.
- Değişiklik kapsamı: Kayıt sonrası değişiklikler için [Change history source] kaynağını yapılandırın. Kaynağın Journal Entry'yi tanımladığını ve güvenilir bir değişiklik zaman damgası sağladığını doğrulayın.
- Mahsuplaşma kapsamı: [Clearing source] kaynağını ve mahsuplaşan muhasebe belgesiyle mahsuplaşma belgesi arasındaki ilişkiyi yapılandırın. Olayın ilk Journal Entry'ye, mahsuplaşma belgesine veya her ikisine atanacağına karar verin.
- Ters kayıt kapsamı: [Reversal source] kaynağını ve ilk belgeyle ters kayıt belgesi arasındaki ilişkiyi yapılandırın. Bu ilişki mevcut olduğunda sorgu, ters kayıt aktivitesini ilk JournalEntryId'ye atar.
- Manuel kayıt sınıflandırması: [Manual posting source] kaynağını veya doğrulanmış bir kayıt kaynağı alanını yapılandırın. Manual Posting Identified bir sınıflandırma olayıdır ve kayıt zaman damgasını veya onaylanmış başka bir zaman damgasını tutarlı biçimde kullanmalıdır.
- Para birimi tutarı: ACDOCA kalem temellidir. Sorgu, yerel para birimi tutarlarını Journal Entry bazında toplar. İşaret kuralını ve istatistiksel, deftere özgü veya genişletme defteri satırlarının dahil edilip edilmeyeceğini doğrulayın.
- Performans: Yalnızca gerekli sütunları seçin, erken filtre uygulayın, ACDOCA üzerinde sınırsız taramalardan kaçının ve sorguyu onaylanmış raporlama zaman aralığında çalıştırın. Desteklendiği durumlarda istemci, mali yıl, şirket kodu ve kayıt tarihi koşullarıyla bölüm budamadan yararlanın.
- Yinelenen kayıtların işlenmesi: Kullanılabildiği durumlarda kaynak olay kimliklerini kullanın. Bir kaynak yinelenen teknik kayıtlar içerebiliyorsa, gerçekten ayrı Workflow aksiyonlarını birleştirmeden belgelenmiş tekilleştirme kuralını uygulayın.
- Ön koşullar: Gerekli veritabanı yetkileri, onaylı SAP HANA bağlantısı, yapılandırılmış Workflow ve ek kaynaklarına erişim, uygun SAP Financial Accounting ve Workflow yapılandırması ve ProcessMind tarafından desteklenen bir dışa aktarma biçimi.
a Örnek sorgu sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Adımlar
- ABAP programını oluşturun:
SE38işlem kodunu kullanarak ABAP Editor'e erişin. Yeni program için bir ad girin, örneğinZ_PM_JE_EXTRACT, ve 'Create' seçeneğine tıklayın. Uygun bir başlık girin, 'Type' alanını 'Executable Program' olarak ayarlayın ve programı yerel nesne olarak veya bir paket içinde kaydedin. - Seçim ekranını tanımlayın: Programda, kullanıcıların verileri filtrelemesini sağlayacak parametreleri ve select-options değerlerini tanımlayın. Bunlar Journal Entry oluşturma tarihi için bir tarih aralığını (
P_CPUDT_FR,P_CPUDT_TO), Company Code için bir select-option değerini (SO_BUKRS) ve uygulama sunucusundaki çıktı dosyası için bir dosya yolunu (P_FPATH) içermelidir. - Veri yapılarını tanımlayın: Gerekli Event Log biçimiyle eşleşen bir dahili tablo yapısı tanımlayın. Bu yapı nihai çıktıyı tutacaktır. Ayrıca BKPF, ACDOCA, CDHDR, CDPOS ve çeşitli Workflow tabloları gibi verilerin seçileceği SAP tabloları için dahili tablolar ve çalışma alanları tanımlayın.
- Veri seçme mantığını uygulayın: Gerekli 12 aktivitenin her biri için temel ABAP mantığını yazın. Kodu düzenli tutmak için her aktiviteye ayrı alt yordamlar (FORM'lar) oluşturun. Örneğin
get_created_events,get_parked_events,get_workflow_eventsgibi FORM'lar oluşturun. - 'Created' ve 'Posted' olaylarını seçin: Kullanıcının seçim ekranı ölçütlerine göre BKPF tablosunu okuyun. BKPF'deki bir kayıt oluşturma işlemini gösterir.
BSTAT = ' 'durumundaki bir belge kaydedilmiş kabul edilir. Olay zamanı olarak oluşturma zaman damgasını (CPUDT,CPUTM) kullanın. - 'Parked' olaylarını seçin: Bekletilen belge başlıklarını tutan VBKPF tablosunu okuyun. Bu tablodaki oluşturma zaman damgası bekletme olayını temsil eder.
- 'Workflow' olaylarını seçin (Submitted, Approved, Rejected): Journal Entry nesnesini bir Workflow örneğine bağlamak için SWW_WI2OBJ gibi Workflow tablolarını, belirli adımların ayrıntılarını ve zamanlamasını almak için SWWLOGHIST veya SWWIHEAD tablolarını sorgulayın. Sisteminizde gönderim, onay ve ret için kullanılan belirli Workflow görev kimliklerini belirlemeniz gerekir.
- 'Change' ve 'Correction' olaylarını seçin:
OBJECTCLAS = 'BELEG'için değişiklik belgesi tabloları CDHDR (başlık) ve CDPOS'u (kalem) sorgulayın. 'Changed After Posting' için değişiklik zaman damgasının belgenin kayıt tarihinden sonra olduğu kayıtları filtreleyin. 'Corrected' için bekletilen veya reddedilen belgelerdeki değişiklikleri filtreleyin. - 'Reversal' ve 'Cleared' olaylarını seçin: BKPF'deki
STBLGalanı (Ters Kaydedilen Belge No.) dolu olan belgeleri bularak ters kayıtları belirleyin. Ters kayıt olayının zamanı, ters kayıt belgesinin oluşturulma zamanıdır. Belirli bir Journal Entry'nin kalemleri için ACDOCA tablosundaki en son mahsuplaşma tarihini (AUGDT) seçerek mahsuplaşma olaylarını belirleyin. - Verileri birleştirin ve sıralayın: Her aktivitenin verilerini seçtikçe sonuçları nihai ana dahili tabloya ekleyin. Tüm seçimler tamamlandıktan sonra her vakanın kronolojik sırasını sağlamak için ana tabloyu
JournalEntryIdveEventTimealanlarına göre sıralayın. - Çıktı dosyasını oluşturun: Sıralanmış nihai dahili tablonun içeriğini SAP uygulama sunucusunda belirtilen dosya yoluna yazmak için
OPEN DATASET,LOOP AT... TRANSFERveCLOSE DATASETifadelerini kullanın. Dosya, başlık satırı içeren CSV biçiminde olmalıdır. - Çalıştırmayı zamanlayın: Düzenli veri çıkarma işlemleri için
SM36işlem kodunu kullanarak belirli bir takvimde, örneğin haftalık veya aylık çalışan bir arka plan işi oluşturun. Bu işlem, veri dışa aktarma sürecini otomatikleştirir.
Yapılandırma
- Tarih aralığı: Seçim ekranında yevmiye kaydı oluşturma tarihi (
CPUDT) için zorunlu bir tarih aralığı bulunmalıdır. İyi performans sağlamak için verilerin 3-6 aylık dönemler gibi yönetilebilir parçalar halinde çıkarılması önerilir. - Şirket kodu (
BUKRS): Bu, çıkarma işlemini Process Mining analiziyle ilgili belirli tüzel kişilerle sınırlamak için önemli bir filtredir. Tüm şirket kodlarının tek seferde çıkarılması önerilmez. - Belge türü (
BLART): G/L Account Posting için 'SA' veya Vendor Invoices için 'KR' gibi belirli yevmiye kaydı türlerine odaklanmak üzere bu isteğe bağlı filtreyi ekleyebilirsiniz. Bu, veri hacmini azaltabilir ve veri setinin ilgililiğini artırabilir. - Dosya yolu: Program, çıktı dosyasının yazılacağı SAP uygulama sunucusunda mantıksal bir dosya yolu gerektirir. Yolun geçerli olduğundan ve SAP sistem kullanıcısının bu dizin için gerekli yazma yetkilerine sahip olduğundan emin olun. Sunucu dizinlerini yönetmek ve görüntülemek için
AL11işlemini kullanın. - İş akışı görev kimlikleri: İş akışı etkinliklerini (Submitted, Approved, Rejected) çıkarma mantığı, kuruluşunuzun yevmiye kaydı onay iş akışında kullanılan özel görev kimlikleriyle yapılandırılmalıdır. Bunlar çoğu zaman özeldir ve bir iş akışı danışmanı veya geliştirici tarafından belirlenmelidir.
- Ön koşullar: Programı çalıştıran kullanıcı veya sistem hesabı, ABAP programları oluşturmak ve çalıştırmak (
S_DEVELOP) için geliştirici yetkilerine ve finans tablolarına (BKPF, ACDOCA), değişiklik günlüğü tablolarına (CDHDR, CDPOS) ve iş akışı tablolarına (SWW*) geniş okuma erişimine sahip olmalıdır.
a Örnek sorgu abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Başlamaya hazır mısınız?
Verilerinizi güvenle hazırlamak ve Kayıttan Raporlamaya - Yevmiye kaydı süreciniz hakkında önemli içgörüler elde etmek için bu Templatei kullanın. Süreç mükemmelliğine giden yolculuğunuza bugün başlayın.
Record to Report Journal Entry sürecini en yüksek verimlilik için hızlandırın
Sürecinizi dönüştürün ve Record to Report journal entry çevrim süresini %30 azaltın.
Kredi kartı gerekmez. Kurulum birkaç dakika sürer.